1. 现象与影响
1.1 具体表现
当反向代理设置了固定的缓存有效期时，1小时缓存时间到期后理论上应重新向源站获取最新内容，但现实中会出现1小时过期仍未更新的现象，导致终端用户看到旧数据。Age头字段往往显示缓存时间，而非源站的新内容，造成页面展示与最新状态不同步的情况。缓存层的写入与刷新策略之间的差异，是造成此现象的一个核心原因。
在实际部署中，Nginx、Varnish、或其他反向代理的默认行为可能并非严格按照单次过期就刷新，而是根据命中情况、变体、或后端响应头进行再验证。这就会让“1小时过期”成为一个门槛，而不是严格的刷新点，从而出现“过期但仍缓存”的情形。缓存命中与失效的边界条件成为排查重点。
1.2 影响与业务场景
对用户体验的直接影响是页面内容、价格、库存等动态信息的滞后展示，尤其在电商、资讯和数据密集型应用中尤为明显。用户感知的时效性下降会降低转化率和信任度。与此同时，运维侧也会面临更多重复请求、后端压力变化以及缓存击穿的风险，因此理解并定位“1小时过期仍未更新”的根因成为日常巡检的重要环节。部署一致性与缓存策略的对齐是保障系统正确性的关键。
在跨区域缓存或多层代理架构中，这种现象还可能被放大：各个节点的缓存策略不统一、变体不一致，最终导致部分节点仍显示旧内容而其他节点已更新。多级缓存协同工作原理的理解，有助于快速定位异步刷新与跨节点一致性的问题点。
2. 可能的原因
2.1 Origin 响应头配置
如果源站返回的 Cache-Control、Expires、以及 Vary 等头信息未与反向代理的缓存策略匹配，1小时的过期后代理可能仍按旧策略缓存或错过刷新时机。Cache-Control: max-age 指定的时间与 s-maxage 的覆盖顺序，直接决定了代理端的可缓存时长。Expires 头若与 max-age 冲突，也会造成过期后的刷新错位。
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
Expires: Wed, 21 Aug 2024 12:00:00 GMT
ETag: "abc123"
在上述场景中，如果后端后续更新但未改变 ETag/Last-Modified，反向代理可能仍按 1 小时的缓存时间处理，从而出现“1小时过期仍未更新”的现象。源站返回头与代理缓存时间的错配是常见的根因之一。
2.2 缓存键与变体
缓存键如果没有覆盖所有变体（如 Accept-Encoding、Accept-Language、Cookie 影响的变体等），则一个资源可能在代理层被拆成多个变体缓存。当其中某个变体到期时，其他变体仍可能保持旧数据，这就容易让人觉得“缓存没有统一更新”。Vary 头和 Cache Key 的设计直接决定了这一点。
例如，若一个页面对 gzip 与 br 编码产生不同变体，但缓存键未将 Accept-Encoding 纳入计算，某些变体过期而其它变体仍可能使用旧内容，导致表面上看起来像是缓存没有正确刷新。变体管理是排查的重点之一。
2.3 代理层策略与延迟
一些反向代理支持 stale-while-revalidate 或 grace 期概念，在过期后仍允许返回过期内容同时在后台刷新。这种设计会造成“过期但仍可用”的现象，尤其在高并发场景下更容易让人误以为缓存失效。再验证策略与刷新时序的配置，会显著影响 1 小时的过期后内容是否会立即更新。
此外，不同代理之间的策略可能不一致，比如 Nginx 与 Varnish 对于 1h 的处理差异，或是在多级缓存体系中，第一级缓存已经过期但后续层尚未拉取新内容，造成表面上的“1小时已到但未更新”的错觉。层间一致性与刷新节拍需要被同时关注。
3. 核心排查要点
3.1 查看响应头与 Age 字段
排查时第一步是确认真实返回的响应头与代理端缓存状态。通过 curl 等工具可以快速查看 Cache-Control、Expires、Age、以及 X-Cache-Status 等字段。Age 表示缓存内容在代理中的存活时长，可能揭示过期时间与实际更新之间的错配。
curl -I https://example.com/resource
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
Expires: Wed, 21 Aug 2024 12:00:00 GMT
Age: 1800
X-Cache-Status: HIT通过对比 Age 与 Cache-Control 指定的 max-age，能迅速发现是否存在“1小时过期仍未更新”的矛盾点。X-Cache-Status 的值也能直接提示缓存是命中还是回源刷新。
3.2 查看代理日志与缓存命中状态
日志是定位问题的关键证据。Nginx 的 access.log、Varnish 的 cache 时序日志，以及后端的响应时间分布，能够揭示缓存击穿、再验证、以及跨区域同步等问题。hit/miss 与 miss by header 的模式尤为重要。
组合使用如下命令，能快速追踪问题：
tail -f /var/log/nginx/access.log | grep -i '/resource'
varnishtop | grep resource
通过分析日志中的命中类型、后端响应头以及时序，可以明确是源头头信息问题还是缓存策略问题导致的“1小时过期仍未更新”。日志对比分析是排查的基础方法。
3.3 重现步骤与分段测试
在排查过程中，建议通过分步测试来触发不同路径的刷新行为：先改变后台资源但保持相同的 ETag，再验证 If-Modified-Since/If-None-Match 的协商结果；再修改缓存策略后观察代理端的新缓存命中情况。可重复性测试帮助确认是否因 TTL、缓存键、或变体导致的问题。
可执行的分步测试要点包括：逐步缩短缓存有效期、清空某个节点缓存、对特定变体进行独立测试、并在不同区域进行对比。分段测试与对照对比能快速定位问题根因。
4. 实践示例与配置片段
4.1 Nginx 反向代理配置
在 Nginx 的反向代理场景中，合理设置 proxy_cache_path、proxy_cache 与 proxy_cache_valid，是确保 1 小时缓存期望行为的关键。以下示例展示了一个基本的缓存配置，以及对 200 状态的缓存时长设定。
# 缓存区域与路径
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;server {listen 80;server_name example.com;location /resource/ {proxy_pass http://backend;proxy_cache my_cache;# 对 200/302 等响应缓存 1 小时proxy_cache_valid 200 302 1h;}
}
注意事项：缓存键设计需要覆盖 URL、查询参数以及必要的请求头（如 Accept-Encoding）的变体；不同状态码的缓存时长应单独配置，避免错误缓存了错误响应。通过监控 X-Cache-Status 与 Age 的变化，可以判断是否像预期那样刷新。
4.2 Varnish 配置片段
在 Varnish 环境中，TTL 与 Grace 的设置决定了资源过期后的行为。以下 VCL 片段演示了如何将后端响应的 ttl 固定为 1 小时，同时启用一定的赃值时间以应对突发流量。
vcl 4.0;backend default { .host = "127.0.0.1"; .port = "8080"; }sub vcl_backend_response {if (beresp.ttl >= 0s) {set beresp.ttl = 1h;set beresp.grace = 1h;}
}
这段配置确保即使在过期时，Varnish 也会在一定的 grace 期内继续提供旧内容，并在后台刷新。这种策略在面对“1小时过期仍未更新”的场景时尤为常用，但也需要配合前端的缓存策略与后端的响应头一致性来避免出现不可控的过期行为。Grace 时间与后端刷新节奏的配合，是保持一致性的关键。
4.3 触发更新与一致性策略
为了确保过期内容能够尽快更新，常用的做法是结合实体内容的变更号（ETag）与校验请求（If-Modified-Since、If-None-Match）。当源站在缓存过期后返回 304 Not Modified 时，代理端可以以更高的确定性刷新缓存。ETag/Last-Modified 的正确应用，是避免“1小时过期仍未更新”的核心手段。
GET /resource HTTP/1.1
Host: example.com
If-Modified-Since: Tue, 01 Aug 2023 12:00:00 GMT
If-None-Match: "abc123"通过以上交互，代理可以在源站内容变化时获得即时通知，从而触发缓存刷新，减少长时间保留旧内容的概率。条件请求与缓存刷新机制的协同，是提升缓存命中准确性的有效方式。
本篇文章聚焦于“反向代理缓存失效：1小时过期仍未更新的原因与排查要点”这一主题，讨论了从响应头、缓存键、代理层策略到具体配置的多维排查路径。通过对关键字段、日志、与实际配置的逐层核对，可以系统性地定位问题根因并对症下药。
