📍 WDQWDWQD987AAAAA:216.73.217.162
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8dc17c7692dd.html
📄

404状态码：测试环境与线上怎样对照

对照测试环境与线上的404状态码，核心不是比较“有没有返回404”，而是比较同一路径在两边是否都返回404、返回的响应头是否一致、以及测试环境的404是否被错误地当成了真实缺失。建议按路径、响应头、来源日志三列做逐项比对，先确认测试环境返回404的原因与线上是否相同。下面从一个假设的例子展开。

假设场景：改版后测试环境返回404，线上仍是200

假设某站点把/old-page重定向到/new-page，在测试环境访问/old-page得到404，而线上访问同一路径仍是200。此时不能直接判定线上配置有误，因为两边返回码不同可能来自三层差异：服务器配置、应用路由、缓存。需要先收集证据，再判断原因。

第一步：固定对照条件

• 使用同一路径、同一请求方法（通常为GET）、同一协议（http与https分别测）。
• 关闭浏览器缓存或用无痕窗口，避免本地缓存掩盖真实响应。
• 用命令行查看响应头，而不是只看页面内容。例如curl -I https://example.com/old-page，重点看第一行状态码和Location头。
• 测试环境若需要登录或带特定Host头，先补齐这些条件，否则404可能只是访问控制造成的假象。

第二步：逐项比对三类信息

1. 状态码本身：两边是否都返回404，还是测试环境404、线上200或301。若线上是301，说明重定向已生效，404只是测试环境未同步规则。
2. 响应头：对比Location、Cache-Control、X-Robots-Tag等。测试环境若缺少Location，说明重定向规则没有加载。
3. 来源日志：查看两边服务器访问日志中该路径的命中记录。测试环境404可能来自应用层抛出的异常，而线上200来自静态文件或CDN缓存。

第三步：区分常见错误

一种常见错误是只对比页面文字。测试环境可能返回自定义404页面，状态码却是200，这种“软404”在线上也可能存在，不能因为页面显示“未找到”就认定状态码正确。另一种错误是把测试环境的404直接当成线上也应404：如果测试环境尚未同步重定向规则，404只是配置缺失的结果，不代表线上路径真的应该消失。

还要注意：robots.txt中的抓取限制不等于可靠的索引移除，测试环境用robots.txt挡住爬虫，并不能替代对404状态码本身的验证。站点地图不保证收录，也不能用来判断某个路径是否应该返回404。

第四步：形成可执行的判断结果

对照完成后，按以下条件判断：

• 两边同一路径都返回404，且响应头一致：说明该路径确实已移除，可继续检查是否有内链或外链仍指向它。
• 测试环境404、线上301：说明重定向规则只在线上生效，应把规则同步到测试环境后再复测。
• 测试环境404、线上200：先确认线上200来自缓存还是真实文件。清除缓存后复测，若仍为200，说明线上路径仍存在，测试环境的404是配置差异。
• 两边都返回200但页面显示“未找到”：属于软404，需要修正应用层状态码输出。

下一步：选取一个具体路径，用命令行分别请求测试环境和线上，记录状态码与响应头，再对照服务器日志确认404的产生位置。只有两边条件一致时，对照结果才可用于定位原因。