nginx 正确配置 cache-control 需结合响应头、后端交互与代理控制：no-cache 允许缓存但强制验证，no-store 禁止任何缓存；须配 must-revalidate 和 max-age=0，并在 php 场景禁用 fastcgi_ignore_headers，在反向代理中启用 proxy_no_cache 和 proxy_cache_bypass，最后通过浏览器 network 标签及 curl 验证实际生效。
要让 Nginx 正确配置 Cache-Control: no-cache 或 no-store，关键不是只加响应头，而是结合缓存行为、后端交互和代理层控制，确保浏览器和中间环节都按预期不复用旧内容。
区分 no-cache 和 no-store 的实际效果
no-cache 允许浏览器暂存资源，但每次使用前必须向服务器发起验证请求（带 If-None-Match 或 If-Modified-Since），服务器返回 304 表示未变、200 表示更新。适合内容常变但可接受轻量验证的场景。
no-store 是最严格指令：浏览器不得保存任何副本，所有请求都必须走完整 HTTP 流程，响应也禁止被中间代理缓存。适用于含敏感信息的页面（如登录后仪表盘、交易确认页）。
两者都应搭配 must-revalidate 和 max-age=0 使用，避免因兼容性或旧缓存残留导致失效。
基础配置写法与常见陷阱
在对应 location 块中添加如下指令：
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";add_header Pragma "no-cache";add_header Expires "0";
⚠️ 注意：若后端是 PHP（FastCGI），默认会忽略你设置的 Cache-Control 头。必须显式禁用忽略行为：
fastcgi_ignore_headers Cache-Control; → 改为 fastcgi_ignore_headers ""; 或直接删掉该行。
否则 PHP 脚本返回的头（比如 Laravel、WordPress 自动设的 public, max-age=31536000）会覆盖你的配置。
反向代理场景下必须额外处理
如果 Nginx 同时作反向代理并启用了 proxy_cache，仅靠响应头无法阻止代理层缓存：
- 在敏感 location 中加入：
proxy_no_cache 1;和proxy_cache_bypass 1; - 检查是否屏蔽了后端返回的缓存头：
proxy_ignore_headers Cache-Control Expires;这类配置需移除或调整 - 若响应依赖用户身份（如带
Cookie或Authorization），确保proxy_cache_key包含$http_cookie，防止不同用户命中同一缓存
验证是否真正生效
别只看响应头是否存在，重点观察行为：
- 打开浏览器开发者工具 → Network 标签 → 刷新页面，状态码应始终为 200（不是 304），Size 显示 from network（非 from memory/disk cache）
- 尝试 Ctrl+R（普通刷新）和 Ctrl+Shift+R（强制清缓存重载），两者都应触发新请求
- 用 curl 验证：
curl -I https://yoursite.com/sensitive-page，确认响应头含完整指令且无冲突值 - 已缓存的老资源不会自动清除，上线后建议配合 URL 版本化（如
/profile?v=20261001）或引导用户硬刷新
