没有真正意义上的“一键诊断脚本”，但可通过三步精准定位浏览器缓存异常：第一步用curl绕过浏览器直查服务端响应；第二步用chrome devtools禁用缓存对比行为；第三步通过nginx添加调试头验证缓存控制是否生效。

没有真正意义上的“一键诊断脚本”能全自动覆盖所有浏览器缓存异常场景，但你可以用一组轻量、可复用的命令组合，实现**三步定位核心问题**：确认是否缓存导致、区分是 301/302 缓存还是资源响应被缓存、验证 Nginx 是否已禁用不当缓存。关键不在“一键”，而在“精准触发+快速比对”。

第一步：用 curl 快速绕过浏览器，直击服务端真实响应

这是最可靠的起点，完全规避浏览器自身缓存逻辑：

• 检查重定向行为：curl -I http://your-domain.com/old-path，看返回状态码和 Location 头是否符合预期；若仍是旧地址，说明 Nginx 配置未生效或被覆盖
• 检查资源缓存头：curl -I https://your-domain.com/static/app.js，重点看 Cache-Control、Expires、ETag 和 Last-Modified
• 强制不走任何缓存：curl -H "Cache-Control: no-cache" -H "Pragma: no-cache" -I https://your-domain.com/api/data，对比有无该头时响应内容是否一致

第二步：用 Chrome DevTools 精准捕获浏览器实际行为

不是清缓存，而是“观察缓存是否在起作用”：

page-agent 浏览器控制（CDP）

使用 page-agent CLI（CDP）控制浏览器；CLI只能通过 GitHub Release 的 .tgz 安装，npm 官方包暂未发布。

下载

• 打开开发者工具 → Network 标签页 → 勾选 Disable cache
• 刷新页面，观察所有请求的状态码和响应头；若禁用后正常，启用后异常，基本锁定是浏览器缓存问题
• 特别关注 301 请求：右键某条 301 记录 → Copy → Copy as cURL，再粘贴到终端执行，确认是否仍跳转——这能排除 HSTS 或本地策略干扰

第三步：快速验证 Nginx 缓存控制是否生效

别只信配置文件，要看它是否真写进了响应头：

• 在对应 location 块中加一句：add_header X-Cache-Debug "$upstream_cache_status|$sent_http_cache_control";
• 重启 Nginx 后，用 curl 查看响应头：curl -I https://your-domain.com/path | grep X-Cache-Debug
• 输出类似 X-Cache-Debug: MISS|no-store, max-age=0，说明缓存已禁用且指令生效；若为空或显示 HIT + public，说明配置未命中或被覆盖

不复杂但容易忽略：真正卡住排查进度的，往往不是不会配，而是没分清“是浏览器记住了 301”“是 CDN 缓存了响应头”还是“Nginx 自己把 302 当静态规则缓存了”。用这三步组合，5 分钟内就能划清责任边界。