网站404处理：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6e662ce1fee5.html
📄
网站404处理：源站正常而边缘节点异常时应保留哪些证据
先给有条件的结论：如果源站对同一路径返回的确实是404，而边缘节点返回的却是200、301或5xx，那么你应当优先保留边缘侧与源站侧的对照证据，而不是急着改源站配置。只有当边缘异常是持续、可复现，并且能排除回源路径、缓存键和请求头差异之后，才适合把它当作边缘节点问题来处理。否则，你保留的证据会把排查方向带偏。
先分清两类404：源站决定的和边缘改写的
源站正常而边缘异常，通常不是“404页面变了”，而是同一条URL在两层之间得到了不同结论。对你有用的证据，必须能回答一个具体问题：这个404是谁产生的。
- 源站侧证据：源站访问日志中该路径的状态码、时间戳、请求方法、User-Agent、回源IP。它证明源站是否真的返回了404。
- 边缘侧证据：边缘节点返回给客户端的完整响应头，尤其是状态码、
Cache-Control、Age、X-Cache一类缓存命中标识，以及响应体开头若干字节。 - 对照证据：同一时刻、同一路径、同一请求方法，分别直连源站和经过边缘节点各请求一次，把两组响应并排保存。
这三类证据里，对照证据最关键。只有单侧日志时，你无法判断差异来自边缘改写，还是来自源站在两次请求之间本来就变了。
边缘异常时，先保留这五类可复查材料
假设一个场景：某商品详情页在源站返回404，但经过边缘节点后返回200并展示旧内容。此时应保留的材料是：
- 完整响应头，包括边缘节点返回的和源站返回的两份，不要只截状态码一行。
- 请求标识，例如边缘节点生成的请求ID、回源请求ID。没有它，后续无法把客户端请求和源站日志对上。
- 时间对齐的日志片段，边缘访问日志与源站访问日志取同一时间窗口，精确到秒或毫秒。
- 缓存状态证据，说明该响应是命中缓存还是回源生成。缓存命中时，源站当前返回什么并不直接决定客户端看到什么。
- 可复现的最小请求，例如用
curl固定请求方法、Host和路径，记录命令与输出，方便他人重放。
这里有一个实际动作及其影响：先固定请求头重放一次，再改变一个变量重放一次，例如去掉某个可能影响回源的请求头。如果去掉后边缘返回404，说明差异与请求头相关，下一步应查边缘的请求改写规则，而不是查源站路由。如果两次结果相同，才继续查缓存键和回源配置。
什么情况下“边缘异常”这个判断会失效
反例是：源站日志显示404，但那是源站对回源请求返回的404，而客户端请求的路径在边缘已经被重写。此时你看到的“源站正常”只是回源路径正常，不是用户请求路径正常。两边路径不同，对照证据就不成立，结论自然失效。
另一个会让结论失效的条件是缓存。边缘命中旧缓存时，源站现在返回404并不能证明边缘行为异常；它只说明缓存还没过期或被清除。此时应保留缓存键、过期时间和清除记录，先判断这是缓存生命周期问题，还是边缘逻辑问题。
还需要注意，抓取量或某个统计归零，不能单独证明404处理正确。它也可能是抓取预算转移、站点地图未被读取、或访问日志采样导致的。要结合响应码分布和实际请求样本一起看。
证据齐了之后，下一步怎么走
如果对照证据显示：同路径、同方法、同请求头下，源站404而边缘200，且能排除缓存命中，那么下一步是核对边缘的回源与响应改写规则，并把最小复现请求交给能改边缘配置的人。如果排除不了缓存，下一步是先确认缓存状态和清除条件，再决定是否改源站。如果连请求ID都对不上，下一步不是改配置，而是先补齐日志关联字段，否则任何修改都无法验证。
另外，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些手段不能替代对404本身的证据保留。把边缘与源站的响应并排存档，才是让后续判断可复查的基础。
