源站重定向已经改成新地址，运维测试也正常，部分用户却仍被送到旧页面。此时先查“哪一跳返回了旧 Location”，别急着再次修改规则。永久重定向可能保存在浏览器或 CDN 中，用户未必重新请求了已经更新的源站。
本文针对网站迁移、路径调整和 CDN 规则变更后的旧跳转问题，与反复跳转的重定向循环不同。示例域名与 IP 需替换，命令用于诊断，不代表已在你的生产环境实测。
保留原始入口，逐跳看响应
记录用户输入的完整 URL，包括协议、主机名、路径与查询参数。先不跟随重定向，用 GET 查看第一跳：
curl -sS -D - -o /dev/null https://www.example.com/old-path
关注状态码、Location、Cache-Control、Expires、Age，以及供应商的缓存状态头。随后查看完整跳转链：
curl -sS -L --max-redirs 10 -D redirect-chain.txt -o /dev/null \ https://www.example.com/old-path
头文件可能包含多段响应，要找出第一处偏离预期的 Location。旧入口先跳到规范域名、规范域名再跳业务路径，是不同规则，不能只看最后的 200。curl 不执行页面 JavaScript 或 meta refresh；若 HTTP 链路正确，浏览器仍跳转，还要检查页面代码与 Service Worker。
不要对生产支付、删除或其他有副作用的接口随意重放请求。上面示例只适用于可安全 GET 的公开页面，也不要把 Cookie、授权头或带签名的完整 URL 放进公开工单。
301 与 308 都可能留下持久影响
301 和 308 表示永久重定向，均可被启发式缓存；实际保留时间还受缓存控制、实现与 CDN 规则影响，不能笼统写成“固定缓存一天”或“永远清不掉”。308 保留请求方法和请求体，而 301 在历史兼容行为下可能把 POST 改为 GET，选型时要考虑客户端及接口语义。[1][2]
302 与 307 表示临时重定向，但“临时”也不等于绝不缓存；显式缓存控制和边缘规则仍需检查。307 适用于需要保留方法的临时跳转。不要为修复一个网页路径，直接改变所有 API 的跳转状态码。
新规则处于验证阶段时，可以评估临时状态码与短缓存或禁止存储策略。等跳转目标、业务兼容性及 SEO 影响确认后，再采用永久迁移方案。状态码、缓存期与搜索引擎迁移策略应分别决策。
对比 CDN 与源站，确认旧响应在哪里产生
若 curl 通过 CDN 取得旧 Location，在获准访问源站的环境下对比：
curl -sS --resolve www.example.com:443:203.0.113.10 \ -D - -o /dev/null https://www.example.com/old-path
示例 IP 是文档地址。--resolve 指定连接目标，同时保留 URL 主机名用于 Host、TLS SNI 与证书校验。源站只允许 CDN 时，使用批准的诊断入口，勿临时开放公网，也不要加 -k 跳过验证。
若源站返回新目标、边缘返回旧目标，继续检查两类情况：缓存对象仍保存旧响应，或 CDN 自身的跳转规则仍命中旧配置。刷新对象不会修复错误的边缘规则；修改规则也未必立即使已缓存对象失效。
检查规则优先级、发布范围、主机名与路径匹配，以及是否还有负载均衡、Web 服务器、应用框架或插件在返回跳转。多个源站实例也可能配置不一致。
Age 和缓存命中头可作为线索，但不能单独证明内容正确或排除缓存。它们的具体含义应查所用服务商文档。请求头中的 Cache-Control: no-cache 可用于对照重新验证行为，但不是全局刷新指令，边缘是否遵循还取决于配置。[3]
刷新的是旧入口对象，不只是落地页
浏览器先请求 /old-path，获得 Location 后才请求新地址。若只刷新目标页面，旧入口的缓存重定向仍可能有效。
按照实际缓存键核对协议、域名、尾斜杠和查询参数。某些配置会忽略查询参数，另一些会形成独立缓存对象。追加随机参数未必绕过缓存，还可能制造更多对象，不宜当成长期解决办法。
先精准刷新已确认的旧入口，重新验证第一跳和完整链，再扩大到必要范围。全站刷新可能增加回源负载，应评估容量、避开高峰并保留停止操作的方案。保存刷新任务结果，但最终仍以用户实际收到的响应为准。
浏览器仍旧跳转时，服务器可能没有收到入口请求
如果终端和新浏览器环境都正常，旧浏览器仍跳旧目标，检查 Network 并保留日志。开发者工具开启时禁用缓存可用于诊断，但不同浏览器的处理范围不同，不能把一次刷新作为所有永久跳转缓存已清理的证明。
用干净的浏览器配置或另一设备做对照，同时观察服务器是否收到入口请求。隐私窗口也不能作为对所有网络状态完全隔离的绝对保证。
修改服务器返回的缓存头，只会影响后续收到这些响应的客户端。它无法主动召回浏览器已保存且仍会直接使用的旧重定向。若浏览器根本不再请求原地址，新加的 no-store 头也无从生效。[3]
必要时，在用户知情的情况下定向清理该站点缓存。清理站点数据可能影响登录、离线内容和未同步草稿，勿默认让用户清空所有浏览器数据。若旧目标仍受控，可评估在旧目标提供安全的迁移提示或受控跳转，但要检查是否与原入口形成循环。
保留旧域名、证书与必要兼容路径通常比立即下线更稳妥。可直接到达的新入口也能作为临时支持路径，但不要随意创建长期重复页面而不评估规范链接与 SEO。
区分 HTTP 跳转、HSTS 升级与应用导航
浏览器将 HTTP 升级到 HTTPS，不一定来自当前服务器返回的 301。HSTS、本地策略或浏览器行为也可能影响导航。以实际响应、浏览器提示及服务端日志交叉判断，不要为了一个路径故障贸然清除或削弱 HSTS。
若页面加载后才改地址，检查 JavaScript、meta refresh、前端路由与 Service Worker。CDN 刷新无法修改客户端代码保留的所有状态。搜索结果中的旧链接和浏览器自动补全，也不等于服务器正在返回错误的 Location。
灰度修改后验证完整链，并准备配套回滚
修改前备份源站与 CDN 规则、状态码、目标地址及缓存设置。先选低风险路径或测试域名验证，明确哪些客户端可能仍保留旧响应。
验收至少覆盖：
原始入口的第一跳状态与 Location 正确，后续链路没有多余跳转或循环。
CDN 和源站行为一致，不同源站实例没有旧规则。
新会话、既有浏览器和关键地区的反馈经过复查。
涉及表单或接口时，方法、请求体和鉴权行为保持预期。
回滚时恢复上一份已验证配置，并再次处理受影响的缓存对象。此前已发出的永久跳转可能仍存在客户端，恢复服务器配置不代表所有用户立即回到原状态。保留兼容入口和支持说明，避免来回切换永久规则造成更复杂的缓存链。
在工单中留下原始入口、首个错误跳转、产生响应的层级和修复后的完整链。这样就能判断下一次故障需要改规则、刷入口缓存，还是处理客户端遗留状态。
参考资料
资料核验日期：2026 年 10 月 26 日。示例需结合实际 CDN 与浏览器行为调整。
