404notfound：源站正常边缘异常时该留哪些证据
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /73acccc453ec.html
📄
404notfound：源站正常边缘异常时该留哪些证据
先给结论：源站返回正常而边缘节点返回 404notfound，最该保留的不是“404 这个结果”，而是能证明请求在哪一层被改写的证据——同一 URL 在源站与边缘的响应头、边缘节点的缓存与回源记录、请求 ID 与时间戳的对应关系。缺少这些，后续只能靠猜，无法判断该改缓存规则、回源配置还是发布流程。
假设情境：一次边缘节点 404 的排查
假设某站点源站直连返回 200，但通过边缘节点访问时返回 404notfound。运维先刷新缓存，结果部分 URL 恢复、部分仍然 404。这个结果本身就说明：不是源站内容消失，而是边缘节点对某些请求做了不同处理。此时如果只截图“404 页面”，无法定位是缓存键、回源路径还是重写规则的问题。
假设该站当天做过一次路径前缀调整，例如把 /old-path/ 迁移到 /new-path/。那么需先区分两种情况：源站是否仍接受旧路径；边缘节点是否把旧路径改写后回源。若源站接受旧路径而边缘仍 404，问题在边缘；若源站也 404，问题在源站或发布，二者决策完全不同。
必须保留的三类原始证据
第一类是同一 URL 的双侧响应头。分别记录源站直连和边缘节点返回的状态码、cache-control、age、x-cache、via、server 以及任何请求 ID。重点不是头字段多，而是两侧差异：边缘是否命中缓存、是否回源、回源时用的 Host 和路径是否与源站预期一致。
第二类是边缘节点的请求日志与回源日志。至少保留时间戳、请求 ID、客户端 IP、请求方法、原始 URI、改写后 URI、回源状态码、缓存命中状态。若日志里只有“404”而没有改写后 URI，就无法判断边缘把请求发到了哪里。
第三类是配置变更记录。包括缓存键规则、重写规则、回源 Host、发布记录和生效时间。证据要能回答：变更前后，同一请求的改写路径是否不同。若没有变更记录，至少要保留当前配置快照和抓取时间。
如何用证据区分边缘问题与源站问题
一个可操作的判断顺序是：先固定一个具体 URL，分别用源站直连和边缘节点请求，保存完整响应；再在边缘日志中按请求 ID 找到同一次请求，核对回源 URI 和回源状态码。若回源状态码是 200 而边缘对外是 404，说明边缘在回源后改写了响应；若回源状态码本身就是 404，说明边缘把请求发到了源站不存在的路径。
这个动作的结果会直接决定下一步：前者应查边缘的响应改写或缓存规则；后者应查回源路径、Host 或重写规则。若跳过这一步直接清缓存，可能暂时恢复，但无法防止下次发布再次触发。
哪些证据容易误导决策
- 只保留 404 页面截图：无法证明是缓存、重写还是源站问题。
- 只保留状态码聚合：404 数量上升可能来自爬虫扫描、旧链接自然失效或边缘异常，不能单独归因。
- 只保留边缘日志：缺少源站侧对照，无法判断回源是否成功。
- 只保留变更记录：没有请求级证据，无法确认变更是否真的影响了该 URL。
需要说明的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些与边缘 404 排查不是同一层问题，不应混在同一份证据里判断。
保留证据后的下一步动作
把上述证据按“同一请求 ID”归档，并注明抓取时间、请求工具和假设前提。若确认是边缘改写导致，下一步应修改对应规则并重新用同一 URL 验证；若确认是源站路径不存在，下一步应回到发布流程核对文件是否上传。每次只改一个变量，再用同一组 URL 复测，才能把“这次恢复”与“规则已修正”区分开。
假设情境下的最终判断标准是：源站直连与边缘节点对同一 URL 的响应头、回源 URI、回源状态码能一一对应，且变更记录能解释差异来源。做到这一点，404notfound 才从模糊现象变成可复查的决策依据。
