案例复盘：一起草打不开先别慌：缓存清理按这几步排查，别再被跳转绕晕

案例复盘：一起草打不开先别慌——缓存清理按这几步排查，别再被跳转绕晕

引子 一次线上工单：用户反馈访问“一起草”页面打不开，浏览器不断跳转或显示旧页面。现场最常见的原因并不是服务器出问题，而是“缓存与跳转规则”在不同层级叠加导致的混淆。下面用一个实战化的排查流程，把可能性分层排清楚，既方便工程师快速定位，也方便产品/客服给用户指导步骤。

先确认：先把范围缩小 1) 是所有用户都遇到，还是个别用户/设备？ 2) 是网页端、移动端浏览器还是 App 内置 WebView？ 3) 是否刚刚发布了变更（比如重写了 redirect、cookie 策略、域名或 CDN 配置）？

按这条线索可以快速判断是客户端缓存、浏览器行为、应用缓存、CDN/DNS 还是服务器端重写规则引起的。

快速排查步骤（用户侧优先） A. 简单试验（用户可操作）

• 打开隐身/无痕窗口访问：能打开则可能是浏览器缓存、cookie、扩展或 service worker 问题。
• 换一台设备或换网络（手机切换蜂窝网络或用手机热点）：如果能打开，问题偏向本机 DNS 或缓存。
• 尝试其他浏览器：同样可用于区分浏览器特有的问题。

B. 清缓存与强制刷新

• Windows/Linux 浏览器：Ctrl+F5 或 Shift+刷新 按钮。
• macOS Safari：Shift+刷新 或 清除 Safari 的历史与网站数据（设置 -> Safari -> 清除历史记录与网站数据）。
• Chrome 清缓存：设置 -> 隐私与安全 -> 清除浏览数据，选择“缓存图片和文件”和“Cookie”。
• 移动端 Chrome：设置 -> 隐私 -> 清除浏览数据。
• App 内 WebView：清除应用缓存（设置 -> 应用 -> 目标 App -> 存储 -> 清除缓存）。

C. Service Worker

• 如果页面使用 PWA 或 Service Worker，在 DevTools -> Application -> Service Workers 卸载或更新 service worker，或在浏览器中打开无痕窗口测试。

更深层的排查（工程师侧） 1) 用 cURL 或命令行检查跳转与头信息

• 跟随重定向并查看响应头： curl -I -L https://example.com/path 关注返回的状态码（301/302/307/308/200/4xx/5xx）、Location 头、Cache-Control、Expires、Set-Cookie、Vary、Strict-Transport-Security。
• 若存在跳转循环，curl -I -L 会显示多次重定向链，逐步分析 Location 指向哪里。

2) 判断是否是 CDN 缓存或边缘节点问题

• 直接绕过 CDN 请求源站（hosts 暂时指向源站 IP，或使用源站域名）
• 在 CDN 控制台执行缓存清理（purge），并确认是否对带有 query string 的 URL 也清理。
• 检查 CDN 缓存规则：是否基于 Cookie、Query、Header 做缓存分流，是否错误配置 Vary 导致缓存污染。

3) 检查 DNS 和 HSTS

• 本地 DNS 缓存清理：
• Windows: ipconfig /flushdns
• macOS: sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches
• 若修改了域名解析或新增别名，确认 TTL 已过或使用低 TTL测试。
• HSTS：若启用了 HSTS，浏览器会强制 HTTPS，可能导致重定向行为。Chrome 可通过 chrome://net-internals/#hsts 查询/删除。

4) 检查应用服务器/反向代理的重写规则（常见陷阱）

• Nginx 典型错误示例：重复 rewrite 导致循环 错误： location / { if ($request_uri !~ /index.html$) { rewrite ^(.*)$ /index.html; } } 可能在某些条件下反复触发。
• 推荐用 tryfiles 或精确匹配替代复杂的 if 判断： location / { tryfiles $uri $uri/ /index.html; }
• 检查 https->http 或域名之间的互相重定向，或带/不带 www 的互相跳转。

5) Cookie 与 SameSite、认证相关跳转

• 登录/会话逻辑如果依赖 Cookie，而 Cookie 设置了严格的 SameSite、Domain、Path，可能在某些请求上失效，导致应用把用户重定向到登录页再回跳，从而形成看似“打不开”的行为。查看 Set-Cookie 头确认 domain 与 secure、SameSite 是否合理。

6) 缓存控制头（Cache-Control、ETag、Last-Modified）

• 后端若错误地返回长期缓存且未处理变更，用户会看见旧页面。对静态资源建议使用带版本号的文件名（content-hash）+ 长缓存。对动态页面确保 Cache-Control: no-cache 或适当策略，并在发布后触发 CDN 清理。

实战诊断流程（简化决策树）

1. 单用户问题？ -> 让用户先用隐身模式 & 清缓存 & 换网络测试。
2. 多用户问题？ -> 用 curl -I -L 检查跳转链和头部。
3. 跳转链异常？ -> 检查 nginx/apache 重写规则、应用层重定向（登录、域名）与 HSTS。
4. 内容是旧的但状态码正确？ -> 检查 CDN 缓存并 purge、检查 Cache-Control。
5. 仅部分地域/节点异常？ -> 关注 CDN 边缘节点与 DNS 解析。
6. PWA/Service Worker 老旧？ -> 卸载或更新 service worker。

常用快速修复清单

• 先在浏览器做一次强刷新或清缓存。
• 让用户切换到隐身窗口测试。
• 在服务器端执行 CDN 缓存清理（purge），并确认生效。
• 检查并修正重写/重定向规则，优先使用 try_files 或框架推荐的重定向实现。
• 在发布静态资源时使用版本化文件名以避免浏览器缓存问题。
• 若涉及登录跳转，核对 Cookie 的 Domain/Path/SameSite 与 HTTPS 配置。
• 若使用 Service Worker，推送新版本并在客户端使用 skipWaiting/clients.claim 或指导用户清除站点数据。

结语（操作要点） 遇到“打不开/跳转乱”的问题，按层级逐步排查能显著缩短定位时间：先确认影响范围、用隐身窗口与不同网络排除客户端临时缓存，再用 curl/DevTools 抓取完整跳转链与响应头定位问题层级，最后针对 CDN、DNS、服务器重写或 Service Worker 执行针对性清理或修复。把每一步的结果记录下来，方便回溯与复盘，避免重复发版带来的二次污染。