永久重定向方法，移动端与桌面端怎样检查差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /617f213e80da.html
📄
永久重定向方法，移动端与桌面端怎样检查差异
结论先说：永久重定向（301 或 308）在移动端和桌面端应指向同一个目标地址，差异检查的核心不是“看页面能不能打开”，而是用同一套请求条件分别抓取两端，对比状态码、Location 响应头和最终落地页。发现不一致时，优先怀疑服务端按 User-Agent、CDN 边缘规则或移动站独立配置做了分流。
为什么要分别检查，而不是只看浏览器
手机浏览器和桌面浏览器发出的请求头不同，部分服务器、CDN 或反向代理会据此返回不同结果。常见表现是：桌面端正常 301 到新地址，移动端却停在旧地址、返回 302，甚至直接 200 打开旧页面。多人协作时，如果只由一人在桌面端验收，移动端问题会被带到上线后，返工成本更高。
适用前提：你已经配置好永久重定向，需要在上线前或迁移后做交付验收。判断依据是 HTTP 响应，而不是页面视觉。页面看起来一样，不代表重定向链路一致。
用命令行分别模拟两端请求
最直接的办法是发送不同的 User-Agent，观察响应。下面命令中的 UA 仅为示例，可替换为你要核对的真实设备标识：
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://example.com/old-page
curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/old-page
重点看三项：第一行状态码是否为 301 或 308；是否有 Location 头；Location 的值在两端是否完全一致。如果移动端返回 302，说明它不是永久重定向，搜索引擎可能继续保留旧地址。如果移动端没有 Location，说明请求被其他规则拦截或直接返回了内容。
注意加 -I 只发 HEAD 请求，有些服务器对 HEAD 和 GET 处理不同。更稳妥的做法是去掉 -I，加上 -o /dev/null -s -w "%{http_code} %{redirect_url}\n"，用 GET 再核对一次。
检查重定向链，而不只是第一跳
两端可能都返回 301，但跳转次数和目标不同。例如桌面端一跳到位，移动端先跳到移动站再跳一次，形成链式重定向。链越长，越容易出现中间环节失效或指向错误。
执行步骤：对两端分别加上 -L 跟随跳转，并输出每一跳的地址与状态码。逐跳记录后横向对比。验收信号是：两端跳转次数相同，最终落地页的协议、主机名和路径一致，且全程没有出现 302、303 或 307 混入永久跳转链。
如果发现移动端多一跳，检查服务器配置、CDN 规则和移动站子目录的独立重定向文件，确认是否有两处规则同时生效。
容易忽略的三类差异来源
- CDN 或边缘规则：边缘节点可能按设备类型改写响应。核对时要在不同网络下各测一次，排除单节点缓存造成的假象。
- 缓存：旧的重定向结果可能被浏览器或中间层缓存。用带随机查询参数的地址测试，或清理缓存后复测，避免把缓存当成配置结果。
- 移动站独立配置：如果移动站是单独目录或子域名，它的重定向规则往往和主站分开维护，最容易与桌面端不一致。
需要区分“可能原因”和“已经定位的原因”。两端结果不同只说明存在差异，具体是 UA 分流、缓存还是配置冲突，要靠逐项关闭或逐跳抓取来确认，不要凭现象直接下结论。
交付时留下可复核的记录
多人协作减少返工的关键是把检查结果写成可复核的清单：被测 URL、两端使用的 UA、每跳状态码、Location 值、最终落地页、测试时间与网络环境。这样下一环节的人能直接复现，而不是重新猜。
验收信号可以定为：同一旧地址在移动端与桌面端均返回 301 或 308；Location 指向同一目标；跳转链不超过一跳（有充分理由时可放宽）；最终页面返回 200。任一项不满足就退回修改，不进入下一步。
下一步：挑一个已上线的旧地址，按上面的命令分别跑移动端和桌面端，把两端的 Location 值贴进同一份交付记录里对比。若不一致，先查 CDN 与移动站配置，再复测。
