如何配置 proxy_cache_revalidate 开启基于 ETag 的条件请求优化带宽-Nginx-PHP中文网

nginx 不存在 proxy_cache_revalidate 指令，它是被误传的伪指令；实际缓存验证依赖后端正确返回 etag/last-modified、nginx 内置协商逻辑及合理缓存配置协同实现。

如何配置 proxy_cache_revalidate 开启基于 etag 的条件请求优化带宽

Nginx 没有 proxy_cache_revalidate 这个合法配置指令。它在官方文档、源码及所有稳定版本中均不存在，属于长期被误传的“伪指令”。

你看到的所谓“开启 ETag 条件请求”效果，并非来自这个虚构指令，而是 Nginx 内置的标准缓存行为：只要后端响应中包含有效的 ETag（或 Last-Modified），且该缓存条目已过期，Nginx 在回源时会自动带上 If-None-Match（对应 ETag）或 If-Modified-Since 头，无需任何额外开关。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

真正起作用的是以下三个要素的协同：

后端必须正确输出并响应 ETag

响应头中需含带引号的 ETag: "abc123"（强校验），不能是固定值、时间戳或无引号格式
同一资源内容不变时，ETag 必须完全一致；内容变更时，ETag 必须改变（推荐用内容哈希生成）
收到 If-None-Match 时，严格比对值：匹配则返回 304 Not Modified，不带响应体、不设 Content-Length、不重复输出 ETag

Nginx 缓存配置要支持协商验证

确保启用缓存区域和基础策略：

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=1h;

设置合理缓存有效期（让缓存有机会“过期后验证”）：
```
proxy_cache_valid 200 302 10m;  # 例如 10 分钟后进入可验证状态
```

配合稳定性机制，避免并发击穿：

proxy_cache_lock on;                 # 同一 key 只允许一个请求回源验证
proxy_cache_lock_timeout 200ms;      # 锁超时后允许另一个请求尝试
proxy_cache_use_stale updating;      # 正在后台验证时，仍可返回旧缓存
proxy_cache_background_update on;    # 异步刷新，不影响用户响应

验证是否真实生效

用 curl -I 观察响应头：
- 首次访问：X-Cache: MISS + ETag 头存在
- 缓存过期后再次访问：若看到 X-Cache: STALE 或 X-Cache: HIT（配合 use_stale），且上游日志中对应请求返回 304，说明协商成功

日志中加入 $upstream_cache_status 和 $upstream_http_etag：

log_format cache_log '$remote_addr - $upstream_cache_status "$request" $status $upstream_http_etag';

不复杂但容易忽略：ETag 的价值不在“配什么指令”，而在于后端是否真正把它当成内容指纹来用——配得再全，源站返回 200 或乱生成 ETag，Nginx 就永远发不出有效的 If-None-Match，也收不到 304。