浏览器强缓存未生效主因是响应头未发出或浏览器未遵守，需从Nginx是否真发送Cache-Control/Expires头、及浏览器是否接收并信任该头两层面排查。
浏览器强缓存未生效，通常不是 Nginx 没配，而是响应头没正确发出、或浏览器根本没机会用它。排查要从“Nginx 是否真发出了强缓存头”和“浏览器是否真收到了、且愿意遵守”两个层面入手。
确认响应头是否实际发出
强缓存依赖 Cache-Control: max-age=N 或 Expires，但这两个头必须真实出现在 HTTP 响应中，且仅对特定状态码生效（如 200、301、302 等）。常见漏点：
- 配置写在了错误的 location 块里——比如把
expires 1y;放在location /api下，但 JS 文件走的是location ~* \.js$，结果完全不匹配 - 后端返回了
Cache-Control: no-store或Set-Cookie，Nginx 默认不会覆盖，导致自己的add_header Cache-Control被忽略（尤其 proxy_pass 场景） - 用了
expires指令，但后端返回的是 404 或 502，这类状态码 Nginx 不会自动加 expires 头 - 配置中存在
add_header覆盖冲突：多个 add_header 写同一个头，只有最后一个生效；或者被 upstream 的头优先级压制
验证浏览器是否真正接收并信任该头
即使响应头存在，浏览器也可能跳过强缓存。关键看请求发起方式和响应语义：
- 开发者工具 Network 面板勾选了 Disable cache —— 这是最常被忽略的本地调试干扰项
- 用户按 Ctrl+F5 或 Cmd+Shift+R 强制刷新，浏览器会带
Cache-Control: no-cache请求头，服务端返回 304 或 200，但不走强缓存路径 - 地址栏输入 URL 回车、或点击超链接跳转，才触发真正的强缓存逻辑；SPA 中路由变化（如 /dashboard）若由前端 JS 控制，不发新请求，自然不校验缓存
- localhost 或 file:// 协议下，Safari、Firefox 对缓存更保守，建议用
127.0.0.1或真实域名测试
检查配置是否被绕过或覆盖
Nginx 层面的隐性拦截，会让强缓存形同虚设：
-
proxy_cache_bypass或proxy_no_cache被设为非空值（如$cookie_auth），而测试请求恰好带该 Cookie，直接 bypass 缓存 - location 中用了
if或rewrite，意外改变了请求变量，导致后续expires指令未执行 - SSL/TLS 环境下未处理好
Strict-Transport-Security或混合内容警告，部分浏览器降级处理缓存策略 - CDN 或中间代理（如公司网关）提前截获响应，修改或删除了 Cache-Control 头
快速验证与定位方法
别猜，用工具直击关键证据：
- 用
curl -I https://example.com/app.js查看原始响应头，确认状态码是 200 且含Cache-Control或Expires - 在 Nginx 配置中加一行：
add_header X-Cache-Debug "$upstream_cache_status $sent_http_cache_control";，观察响应头是否输出预期值 - 打开 Chrome DevTools → Application → Cache Storage，清空所有缓存后重载页面，再看 Resources → Headers 是否有
from disk cache或from memory cache - 对比本地
nginx -t语法检测 +nginx -s reload是否成功，避免配置根本没加载
