Nginx日志里的Age字段是判断缓存命中与否最直观的信号。Age是一个标准的HTTP响应头，用来表示响应自源站生成以来经过了多少秒。对于启用了proxy_cache的Nginx，或者前面挂了CDN的架构，理解Age的计算方式和日志表现，对排查回源异常、统计缓存命中率非常有价值。很多工程师只关注HIT和MISS，却不知道Age里藏着更细粒度的信息。
Age响应头的计算原理与Nginx行为
按照RFC 7234的定义，Age的值等于响应生成时间到当前时刻的近似秒数，再加上缓存节点收到的Age值。也就是说，缓存服务器第一次从源站拿到响应时，Age通常是0或很小；之后每次命中缓存返回这个响应，Age都会相应增长。当缓存过期重新回源时，Age又会归零重新开始计时。
Nginx开启proxy_cache后，如果配置了add_header Cache-Control和缓存有效期，命中缓存时会自动输出X-Cache-Status以及对应的Age头。可以在日志格式中把Age记录下来，方便后续分析：
log_format cache_log '$remote_addr - [$time_local] '
'"$request" $status $body_bytes_sent '
'cache_status:$upstream_cache_status '
'age:$upstream_http_age '
'request_time:$request_time';需要注意，$upstream_http_age取的是上游返回的Age头。如果是Nginx自身作为缓存层直接响应，那么客户端看到的Age由Nginx计算，日志里可以通过$sent_http_age拿到实际下发的值。两者混用是排障时最常见的失误之一。
Age为0与Age持续增长分别说明什么
Age为0基本可以判定这次请求经历了回源。要么缓存里根本没有这个资源（MISS），要么缓存已经过期（EXPIRED），Nginx都会向源站发起新请求，拿到新鲜响应后Age从头计算。如果你在日志里看到大量Age为0的记录，同时$upstream_cache_status为MISS，说明缓存覆盖很差，回源压力会直接传导到源站。
反过来，Age持续增长且小于配置的缓存有效期，配合X-Cache-Status为HIT，说明缓存工作正常。比如缓存有效期设置的是600秒，日志中Age的值在0到600之间递增，这就是健康的生命周期曲线。如果发现Age超过了有效期却还在命中，那就要检查是否使用了proxy_cache_valid与源站Cache-Control并存导致优先级混乱的问题——Nginx默认优先遵循源站的Cache-Control，除非显式配置proxy_ignore_headers Cache-Control。
还有一种容易被误判的情况：STALE状态。当缓存过期但源站不可达时，Nginx配置了proxy_cache_use_stale会返回旧缓存，此时Age可能已经超过有效期，属于容降策略而非故障，要结合上下文判断。
多级缓存下的Age叠加与回源链路分析
真实架构往往是CDN加Nginx加源站的多级结构，Age会逐级累加。CDN边缘节点命中时下发的Age是它自己的缓存年龄；当它回源到你的Nginx时，你的Nginx如果又命中本地缓存，返回给CDN的Age是Nginx缓存的真实年龄。CDN再透传或叠加后给客户端，最终看到的Age反映的是整条链路上最老的那份缓存。
排查内容更新不及时的问题时，可以沿着链路逐层看Age。假设客户端拿到的Age是1800秒，而你本地Nginx日志显示缓存只存在了300秒，说明中间某层CDN还缓存着一份更老的副本， purge的清理范围不够。这时要么在CDN侧配置purge接口批量刷新，要么通过版本化URL（例如在路径中加入版本号hash）强制让各级缓存当作新资源处理。
利用Age字段统计命中率与定位异常
把Age和缓存状态一起写入日志后，可以很方便地做统计。下面是一条简单的awk命令，统计各缓存状态的比例以及Age为0的请求数量：
awk -F'cache_status:|age:|request_time:' '
{
split($2, a, " "); status=a[1];
split($3, b, " "); age=b[1];
count[status]++;
if (age == 0 || age == "-") zero++;
total++
}
END {
for (s in count) printf "%s: %.2f%%\n", s, count[s]*100/total;
printf "age为0或缺失占比: %.2f%%\n", zero*100/total;
}' /var/log/nginx/access.log如果HIT率长期低于预期，先看MISS的请求是否集中在同一批URL，常见原因是proxy_cache_key设计不合理，把查询参数全部纳入了key，导致同一资源产生无数个缓存条目。可以按需裁剪key：
# 只保留id参数参与缓存key，忽略其他追踪参数
proxy_cache_key $scheme$host$uri$is_args$args;
# 或者更精细地控制
map $args $cache_args {
default $args;
~^(id=\d+) $1;
}
proxy_cache_key $scheme$host$uri?$cache_args;另外要警惕PURGE之后的短暂回源风暴，清理缓存后所有请求都会Age归零回源，源站要预留足够余量。掌握Age的解读方法后，配合$upstream_cache_status和$request_time，基本可以把缓存链路的健康状况看得一清二楚。