Nginx 默认不覆盖后端已设置的 Cache-Control 头，需用 proxy_hide_header Cache-Control 隐藏后端头，再通过 add_header 统一注入；该操作必须在 location 块中、proxy_pass 后配置，且仅对 2xx/3xx 响应生效。
当 Nginx 本应控制缓存行为（比如通过 add_header Cache-Control），但浏览器最终收到的却是后端程序（如 PHP、Node.js、Python 应用）返回的 Cache-Control，说明该头部被后端覆盖了——Nginx 默认不会覆盖已存在的响应头，这是关键前提。
确认 Nginx 是否真的没生效
Nginx 的 add_header 指令只在响应状态码为 2xx 或 3xx 时生效，且不会覆盖已存在的同名头部。如果后端已经写了 Cache-Control，Nginx 就不会“强行替换”。可通过以下方式验证：
- 用
curl -I http://your-domain/path查看原始响应头，确认Cache-Control内容是否来自后端 - 临时在 Nginx 配置中加一条明显不同的头，例如
add_header X-Debug-Header "nginx-set"，再 curl 看是否出现——若出现，说明 Nginx 头部机制正常；若不出现，可能是 location 匹配错误或状态码非 2xx/3xx - 检查后端日志或代码，确认是否显式设置了
Cache-Control（如 PHP 中的header('Cache-Control: ...')）
用 proxy_hide_header + proxy_set_header 组合接管控制权
如果必须由 Nginx 统一管理缓存策略，可先隐藏后端发来的 Cache-Control，再由 Nginx 重新注入：
- 在
location块或 upstream 上游配置中添加：proxy_hide_header Cache-Control; - 紧接着用
add_header或更稳妥的proxy_set_header（注意：后者用于请求头，不适用）——正确做法是继续用add_header，但确保它在proxy_hide_header之后且 location 作用域内生效 - 示例片段：
location /api/ {<br> proxy_pass http://backend;<br> proxy_hide_header Cache-Control;<br> add_header Cache-Control "public, max-age=3600";<br>}
检查后端框架是否自动注入缓存头
很多现代框架（如 Express、Django、Laravel、Spring Boot）会在无显式设置时自动添加默认 Cache-Control: no-cache 或类似值。这类行为常被忽略：
- Express 中
res.set('Cache-Control', ...)或中间件（如helmet()）可能介入 - Django 的
CacheMiddleware或视图装饰器（@cache_control）会写头 - PHP-FPM 场景下，检查
fastcgi_hide_header（对应 FastCGI 协议）而非proxy_hide_header：fastcgi_hide_header Cache-Control;
验证与调试小技巧
快速定位问题源头：
- 绕过 Nginx 直连后端（如用
curl http://127.0.0.1:8000/xxx），对比响应头差异 - 在 Nginx 配置中开启
log_format记录$upstream_http_cache_control变量，查看后端实际返回了什么 - 使用
curl -v查看完整响应流程，注意后紧跟着的头是否含后端原始值 - 若用 Lua（OpenResty），可用
ngx.header["Cache-Control"] = "..."强制覆盖，但属于进阶方案
