先给结论:源站正常、边缘异常时,最该保留的不是“访问失败”这一句话,而是能区分回源链路、边缘缓存、边缘到用户链路三层的成对证据。保留证据的目标不是证明谁对谁错,而是让运维、SEO、业务三方拿同一批可核对材料决定:继续观察、改写配置,还是把该节点摘掉。若只保留一张截图,分歧几乎必然升级为互相指责。
源站正常通常指直接访问源站 IP 或回源地址能拿到正确响应,而边缘异常指经由 CDN 或反向代理节点访问时结果不同。这两件事可以同时成立,因为中间多了一层缓存和转发。可保留的证据按层划分:
三层缺一层,判断就会偏。只有用户层截图,运维会说“我这边正常”;只有源站日志,SEO 会说“我看到的页面就是错的”。
不是所有材料都有同等价值。判断标准是:它能否被另一个人独立复核。能被复核的留,只能自证的放过。
一个可执行的判断动作:把上述优先项整理成一条时间线,若异常起点与某次边缘配置变更或缓存规则调整重合,下一步应优先回滚或缩小该变更范围,而不是先去改源站。
多角色争论时,分歧往往不在事实,而在各自观察的层面不同。可把争议拆成几个可判定的问题,每个问题配一条证据:
假设一个场景:某页面在部分地区显示旧内容,源站日志显示边缘近期没有回源该路径。此时合理推断是边缘缓存未按预期失效,而不是源站发布失败。这个推断仍需用响应头中的缓存状态佐证;若响应头显示未命中缓存却仍是旧内容,则要把怀疑转向回源请求本身或上游代理。注意,请求量或回源量下降本身不能单独证明缓存正常,它也可能是流量整体下降、监控口径变化或采集延迟造成的。
证据齐了,决策才有依据。三种处理各有前提,不必强行凑齐:
需要提醒的是,robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录。这些与边缘异常不是同一层问题,不要用抓取配置去解释边缘返回错误内容。若异常页面同时涉及抓取与索引表现,应分别核查,而不是把两件事合并成一个结论。
停止收集的条件不是“问题看起来好了”,而是异常样本与正常样本能在同一维度上被解释。例如:同一 URL 在异常节点与正常节点上的响应头差异,能对应到一条已确认的配置差异。此时可以把证据归档,进入验证阶段。
验证阶段的动作是:在确认修复后,用与异常时相同的测试路径、相同的解析器和相同的请求头再取一次响应,与归档样本逐项对比。若差异消失且源站日志与边缘响应一致,才可认为该异常闭环。若只凭一次“现在能打开了”就结案,同类问题很可能在下一个节点或下一次发布时重现。