Nginx 中怎么排查 Cache-Control 头部被后端程序覆盖故障-Nginx-PHP中文网

nginx 默认不覆盖后端已设置的 cache-control 头，需用 proxy_hide_header cache-control 隐藏后端头，再通过 add_header 统一注入；该操作必须在 location 块中、proxy_pass 后配置，且仅对 2xx/3xx 响应生效。

nginx 中怎么排查 cache-control 头部被后端程序覆盖故障

当 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 重新注入：

Nginx Hosting

通过服务器本地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;