Nginx 代理缓存中怎么配置 proxy_cache_revalidate 使用条件请求减少网络带宽-Nginx-PHP中文网

nginx 没有 proxy_cache_revalidate 这个合法配置指令，它是长期误传的伪指令；实际缓存更新依赖后端正确返回 etag 或 last-modified、nginx 内置协商逻辑（缓存过期后自动发起 if-none-match/if-modified-since 请求）及 proxy_cache_valid、proxy_cache_lock、proxy_cache_use_stale updating 等真实配置协同实现。

nginx 代理缓存中怎么配置 proxy_cache_revalidate 使用条件请求减少网络带宽

Nginx 没有 proxy_cache_revalidate 这个合法配置指令。它从未出现在 Nginx 官方文档、源码或任何稳定版本中，属于长期误传的“伪指令”。

你真正需要的，不是启用某个开关，而是让 Nginx 与后端协同工作，利用 HTTP 标准的条件请求机制（If-None-Match / If-Modified-Since）在缓存过期后复用旧内容——仅传输响应头（约 200–500 字节），从而显著减少回源带宽。

下面分三块说清楚怎么做：

后端必须正确提供并响应缓存标识

这是整个机制生效的前提。Nginx 不会主动“要求”验证，只依赖后端返回的头和行为：

静态资源（.js/.css/.png）由 Nginx 或 Apache 托管时，默认已启用 Last-Modified，通常天然支持 304；如需更高精度，可开启 etag on;
动态接口（PHP/Node.js/Python）必须自行实现：
- 首次响应输出带英文双引号的强 ETag，例如：ETag: "d41d8cd98f00b204e9800998ecf8427e"（推荐用内容 MD5）
- 收到 If-None-Match 后严格比对值；匹配则返回 HTTP/1.1 304 Not Modified，响应体为空，不设 Content-Length，不带 Transfer-Encoding
禁止使用固定值、毫秒时间戳或无引号格式的 ETag，否则协商必然失败

Nginx 缓存配置要支持协商复用

不需要虚构指令，但基础链路必须完整：

定义缓存区并启用清理机制：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=1h;
在 location 中启用缓存并设明确有效期（让缓存有机会“过期后验证”）：
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
防并发击穿（避免多个请求同时触发验证）：
proxy_cache_lock on;
proxy_cache_lock_timeout 200ms;

CPA Update - Secure CLI Proxy API Maintenance
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载
提升用户体验（前台返回旧缓存，后台异步刷新）：
proxy_cache_use_stale updating;
proxy_cache_background_update on;

如何验证条件请求是否真实生效

不能只看配置写了没，要观察真实行为：

在 log_format 中加入关键变量：
log_format cache_log '$remote_addr - $upstream_cache_status "$request" $status $upstream_http_etag';
access_log /var/log/nginx/cache.log cache_log;
日志中出现 revalidated + 304，表示缓存已过期、Nginx 发起条件请求并成功复用
用 curl -I 观察：首次访问应有 ETag 和 Cache-Control；缓存过期后再次访问，若返回 304 且无 Content-Length，说明协商成功
注意区分：客户端主动刷新（如浏览器 F5）也会返回 304，但 $upstream_cache_status 显示的是 Nginx 到后端的行为，这才是关键

不复杂但容易忽略