Nginx 中 fastcgi?cache?revalidate 实现缓存内容核实

fastcgi_cache_revalidate 用于优化缓存验证，使 Nginx 在缓存即将过期时发起条件请求（If-Modified-Since/If-None-Match）确认内容有效性，避免无效回源；需启用指令、后端支持 ETag/Last-Modified、缓存含验证头且未禁用复用。

fastcgi_cache_revalidate 是 Nginx 中用于优化 FastCGI 缓存验证行为的一个指令，它让 Nginx 在缓存条目即将过期时，**不直接丢弃旧缓存，而是向后端发起条件请求（如 If-Modified-Since 或 If-None-Match）来核实内容是否仍有效**。若后端返回 304 Not Modified，Nginx 会延长该缓存的有效期并继续使用；否则用新响应更新缓存。

它解决什么问题？

默认情况下，一旦缓存过期（fastcgi_cache_valid 时间到），Nginx 会直接回源请求完整响应，哪怕后端内容根本没变。这带来不必要的带宽消耗和后端压力。
fastcgi_cache_revalidate 启用后，Nginx 利用 HTTP 条件请求机制，仅传输“是否变化”的判断信息（通常几字节），大幅降低回源开销。

如何启用并生效？

需同时满足以下条件：

• 在 http 或 server 块中启用：fastcgi_cache_revalidate on;
• 后端（如 PHP-FPM）必须正确响应 ETag 或 Last-Modified 头（Nginx 会自动提取并带上 If-None-Match/If-Modified-Since）
• 缓存项本身需已包含 ETag 或 Last-Modified（即首次响应必须带这些头）
• 缓存未被标记为不可验证（例如未设置 Cache-Control: no-cache 或 must-revalidate 等禁止复用的指令）

实际效果与注意事项

启用后，Nginx 日志中可见类似这样的回源请求：

GET /api/data HTTP/1.1
Host: example.com
If-None-Match: “abc123”
If-Modified-Since: Wed, 01 Jan 2025 00:00:00 GMT

关键点：

• 只对即将过期的缓存触发（不是每次访问都验证）
• 不改变缓存命中逻辑：命中时仍直接返回，不发验证请求
• 若后端不支持 304（比如忽略 If-* 头或总返回 200），则验证失效，仍会取完整响应
• 它不替代 fastcgi_cache_lock，高并发下多个请求同时触发验证时，建议配合使用以避免“缓存击穿”

配合使用的推荐配置片段

示例（精简）：

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=mycache:10m inactive=60m;
fastcgi_cache_key “$scheme$request_method$host$request_uri”;
fastcgi_cache_valid 200 302 10m;
fastcgi_cache_revalidate on;
fastcgi_cache_lock on;
fastcgi_cache_lock_timeout 5s;

其中 inactive=60m 控制缓存最大空闲时间，而 fastcgi_cache_valid 定义初始有效期；revalidate 在此有效期快结束时介入。