Nginx 中 fastcgi_cache_revalidate 减少后端交互频率-Nginx-PHP中文网

fastcgi_cache_revalidate 通过缓存过期后发起轻量条件请求实现软过渡更新，需php输出准确etag/last-modified、nginx正确配置cache_key与ignore_headers，并启用updating兜底。

nginx 中 fastcgi_cache_revalidate 减少后端交互频率

Nginx 的 fastcgi_cache_revalidate 确实能显著降低 PHP-FPM 的无效调用，但它不是“自动校验”，而是在缓存过期后、仍尝试复用旧内容的前提下，由 Nginx 主动发起一次轻量条件请求，让后端决定是否更新——这比直接丢弃缓存再全量重刷更高效。

关键在于：它把“缓存失效即重执行”的硬切换，变成“缓存到期先确认再更新”的软过渡。

✅ 正确启用 revalidate 的必要条件

PHP 必须输出稳定、语义准确的 ETag 或 Last-Modified
- ETag 值需真实反映内容变更（如 "prod-123-202606281430"），不能是随机数或固定字符串
- 同一资源不同时刻内容不变 → ETag 不变；内容变了 → ETag 必须变
- 避免输出 Cache-Control: no-cache、Pragma: no-cache 等禁止缓存的响应头

Nginx 缓存配置必须协同生效

fastcgi_cache_valid 200 301 302 10m;      # 设基础有效期（如 10 分钟）
fastcgi_cache_revalidate on;               # 启用再验证机制
fastcgi_cache_use_stale updating error timeout http_500;  # 允许 stale 状态兜底
fastcgi_cache_key "$scheme$request_method$host$request_uri";  # key 稳定，不含时间戳等动态变量

确保响应头未被忽略
检查配置中没有 fastcgi_ignore_headers Last-Modified ETag; —— 否则 Nginx 根本不会缓存这些关键头，revalidate 就无从谈起。

? revalidate 实际工作流程

假设缓存原始有效期为 10 分钟：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

请求发生在第 9 分 50 秒 → 缓存未过期 → 直接返回，不触达 PHP
请求发生在第 10 分 05 秒 → 缓存已过期 → Nginx 携带 If-None-Match: "xxx" 向 PHP-FPM 发起请求
- 若 PHP 返回 304 Not Modified → Nginx 延长该缓存有效期（默认延长原时长的一半，即 +5 分钟）
- 若 PHP 返回 200 OK + 新内容 + 新 ETag → Nginx 更新缓存并返回新内容

这个过程绕过了脚本解析、数据库查询、模板渲染等整套 PHP 执行链，只做一次轻量头比对。

⚠️ 常见失效原因（排查重点）

PHP 输出了 Cache-Control: private 或 Vary: Cookie 且未在 fastcgi_cache_key 中体现 → 导致缓存 key 分裂，revalidate 无法命中旧缓存
fastcgi_cache_key 包含 $args 或 $time_iso8601 等动态变量 → 每次请求 key 都不同，缓存无法复用
后端返回的 ETag 在内容未变时发生变化（比如基于当前时间生成）→ 总是触发 200，revalidate 形同虚设
fastcgi_cache_use_stale 未包含 updating → 当后台正在刷新缓存时，新请求可能直接穿透到 PHP，失去 revalidate 意义

? 补充建议：加个调试头看效果

在 location 块中加入：

add_header X-Cache $upstream_cache_status;

观察响应头：

HIT：缓存命中，直接返回
STALE：缓存过期但正用旧内容+后台刷新（updating 生效）
REVALIDATED：revalidate 成功，收到 304 并延长缓存
MISS：完全未命中，PHP 全量执行

这样能快速验证 revalidate 是否真正介入。

不复杂但容易忽略