高收录域名，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7298f6450d86.html
📄
高收录域名，源站正常而边缘节点异常时应保留哪些证据
如果源站返回正常、边缘节点却给爬虫或用户返回异常，先不要急着改源站配置。应保留的证据是能把“源站响应”和“边缘响应”分开对照的一组原始记录，包括同一 URL 在两个位置的响应头、状态码、响应体片段、时间戳和请求标识。只有这些证据能稳定复现，才适合把问题交给 CDN 或边缘服务方处理。
先确认哪些证据能把源站和边缘分开
判断边缘异常，核心不是看某一次抓取失败，而是看同一时刻、同一 URL、同一请求方法下，源站与边缘的返回是否分叉。假设某个页面源站返回 200 和完整正文，边缘节点却返回 403、502，或者返回一段缓存下来的旧页面，这就属于典型的响应分叉。
需要保留的第一组证据是响应头。重点看状态码、Age、Cache-Control、Via、X-Cache、Server 这类字段。它们能说明响应是来自边缘缓存、回源失败，还是被边缘规则拦截。第二组是响应体：边缘返回的正文是什么，是错误页、旧版本，还是被截断的 HTML。第三组是时间与请求标识：请求发出的时间、边缘节点返回的时间、请求 ID 或 trace ID，用来和源站日志对齐。
实际操作上，可以先用带请求头的抓取分别打源站地址和边缘地址，把两次响应保存为原始文本，而不是只截图。保存原始文本的好处是后续能比对头部顺序、状态码和正文差异，避免只凭印象判断。
哪些现象看起来像边缘异常，其实另有解释
一个反例是：边缘返回旧内容，并不一定是边缘节点故障。它也可能是源站本身在回源时返回了旧版本，或者源站与边缘之间的缓存层按规则继续提供旧副本。此时如果只保留边缘响应，就会把责任错误地推给边缘。
另一个容易误判的情况是 DNS 解析到了不同节点。同一域名在不同地区、不同网络下可能命中不同边缘节点，某个节点异常不代表全部节点异常。若只在一个网络环境里抓取一次，证据不足以说明范围。
还有一类情况是 robots.txt 或安全策略在边缘被单独执行。robots.txt 的抓取限制不等于可靠的索引移除，边缘拦截也不等于搜索引擎一定按你的预期处理。遇到这类现象，应把边缘返回的 robots.txt 内容与源站内容一起保留，而不是只记录“抓取失败”这个结论。
证据清单要围绕可复现，而不是越多越好
下面这组证据适合在发现异常后的第一时间保留，前提是你能访问源站日志和边缘配置的只读视图：
- 同一 URL 在源站与边缘的完整响应头，包含状态码和缓存相关字段。
- 两次请求的原始响应体，至少保留出错页和正常页各一份。
- 请求时间、请求方法、完整 URL、请求 ID 或 trace ID。
- 源站访问日志中对应时间段的记录，用来确认是否收到回源请求。
- 边缘侧返回的错误码或规则命中标识，如果控制台能看到。
- 不同网络或不同节点各一次的对照结果，用来判断是个别节点还是普遍现象。
这些证据的作用是让下一步动作有依据。如果源站日志显示根本没有收到回源请求，而边缘返回了错误，那么优先排查边缘缓存或边缘规则；如果源站日志显示收到了请求但返回了异常，那问题可能仍在源站或源站到边缘的链路上。动作不同，后续验证方式也不同。
保留证据之后，下一步该做什么
拿到对照证据后，先做一次最小化复现：用同一个 URL、同一个请求方法，在相同网络条件下再请求一次，确认异常是否稳定出现。如果稳定出现，把源站与边缘的响应差异整理成一条时间线，再提交给边缘服务方或内部运维。如果不稳定，先记录出现频率和网络条件，不要急着下结论。
修复后不要只看边缘是否恢复 200。应再次保留修复后的源站与边缘响应，确认状态码、正文和缓存字段都回到预期，并观察一段时间内是否再次分叉。只有修复前后的证据能对应上，才能判断这次处理是否真正解决了边缘异常，而不是被缓存刷新或节点切换暂时掩盖。
