先给有条件的结论:如果源站返回正常而边缘节点返回异常,最该保留的不是“异常截图”本身,而是能证明差异发生在哪一层、持续多久、影响哪些URL的证据链。缺少完整日志或CDN后台权限时,仍可用命令行响应头、状态码对比和带时间戳的抓取记录完成最小取证,但这些材料只能说明边缘层存在不一致,不能直接推断搜索引擎一定不收录,也不能证明源站配置完全正确。
核心动作是同一URL、同一时刻、同一请求方式分别打源站和边缘节点,保存完整响应。缺少权限时,可用curl -I获取响应头,用curl -s -o /dev/null -w "%{http_code} %{time_total}"记录状态码与耗时,并把输出重定向到带日期的文件。重点保留:请求URL、请求时间(含时区)、源站IP或回源地址、边缘节点返回的状态码、Cache-Control、Age、X-Cache一类缓存标识、Content-Length以及响应体前若干字节的哈希。若边缘返回200但内容为空或为旧版本,单看状态码会误判,必须同时保留响应体摘要。
这一步的结果决定下一步:如果源站与边缘的状态码或响应体哈希不一致,问题可定位到边缘缓存或回源链路;如果两者一致但抓取工具仍报错,则应转向DNS解析、TLS握手或抓取端IP被封等方向,而不是继续在源站配置上反复修改。
单次异常截图无法说明是偶发还是持续。最小可行做法是每隔固定间隔(例如5分钟)对同一组代表性URL执行一次探测,把状态码、响应时间和缓存命中标识追加写入同一文件,持续至少数小时。选取的URL应覆盖:首页、一个栏目页、一个深层内容页、一个静态资源。这样做的价值在于区分三种情况:边缘节点整体故障、单个节点或单个POP异常、仅特定URL因缓存键设置而异常。
需要说明的是,探测频率和样本量本身不构成因果证据。请求量下降、抓取量归零或某个状态码集中出现,都可能有多种解释,例如抓取端自身调度变化、robots.txt被临时修改、DNS解析波动。不能仅凭探测结果就断定边缘节点是唯一原因,也不能因为源站探测正常就排除源站某些路径的偶发问题。
搜索引擎抓取器看到的边缘响应,可能与运维本机看到的不同,因为解析到的节点、请求头、UA和地理位置都可能不一样。在权限有限时,可保留以下证据:抓取工具返回的原始响应头与状态码、抓取时间、使用的UA、解析到的IP。若站点有搜索引擎后台的抓取统计或URL检查结果,导出或截图时保留时间范围和具体URL,不要只保留汇总数字。站点地图提交记录、robots.txt历史版本也应一并留存,因为robots.txt的抓取限制不等于可靠的索引移除,它只能阻止抓取,不能保证已收录页面从结果中消失。
一个假设例子:某URL在源站返回200且内容完整,边缘节点在高峰期返回200但内容为上一次发布的旧版本,Age值很大。此时保留的应是同一URL在两个时间点的响应体哈希和Age变化,而不是“页面看起来不对”的描述。若后续清除缓存后哈希恢复一致,只能说明该次缓存异常被消除,不能据此推断所有节点都已恢复,仍需继续观察时间序列。
最需要警惕的反例是:边缘异常只出现在特定请求头或特定UA下。运维本机用浏览器访问正常,但抓取器UA请求时边缘返回403或空内容。此时前面基于普通请求的对照证据会得出“边缘正常”的错误结论。因此取证时必须保留请求头原文,并用至少两种UA各探测一次。另一个反例是异常发生在TLS握手或DNS解析阶段,响应头根本拿不到,此时应保留curl -v的连接过程输出和解析结果,而不是只记录HTTP状态码。
此外,HTTPS可用不代表链路无问题,它既不保证安全无漏洞,也不保证排名;不同搜索引擎对边缘异常的处理和支持情况须分别核查,不能把一家抓取器的表现直接套用到另一家。
保留证据后,按差异类型决定动作:若源站与边缘响应体哈希不一致且Age偏大,优先核查缓存键与缓存规则,清除后继续记录时间序列确认是否复发;若仅特定UA被拒,核查边缘的UA规则与WAF日志;若连接阶段就失败,核查DNS与证书链。每次动作后重新执行同一组探测并追加记录,用“动作前后同一URL的响应是否一致”判断是否收敛。若证据只能证明边缘层不一致而无法取得节点日志,应把结论限定为“边缘层存在可复现的响应差异”,并说明尚不能确定根因,避免把未验证的推断写成处理结论。