蜘蛛爬行优化：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9418edfa9284.html
📄
蜘蛛爬行优化：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常、边缘节点异常时，优先保留能证明“同一个URL在不同节点返回不同结果”的原始证据，而不是先改robots.txt或提交删除。只有当你确认异常节点返回的是错误状态码、错误内容或阻断抓取，且源站无法通过回源覆盖时，才进入节点侧修复流程；否则应保留证据并推动CDN或边缘服务商处理。
两种做法成立的条件不同
第一种做法是先在源站加规则，让异常节点回源时被强制纠正。它成立的条件是：你拥有源站配置权限，且异常只影响缓存层，回源请求能拿到正确响应。代价是可能掩盖节点侧的真实故障，后续同一节点再次异常时缺少对照。
第二种做法是先冻结证据，再交给边缘服务商或运维处理。它成立的条件是：异常节点不在你直接控制范围内，或你无法确认回源是否稳定。代价是修复周期可能变长，期间抓取请求仍可能命中异常节点。
判断依据不是“哪个更快”，而是异常是否可复现、是否与节点绑定。如果同一URL在A节点正常、B节点异常，且重复请求结果稳定，优先走第二种；如果所有节点都异常而源站正常，才考虑第一种。
必须保留的证据类型
证据要能回答三个问题：请求了什么、从哪个节点返回、返回了什么。以下内容按优先级保留。
- 原始响应头与状态码：包括HTTP状态码、Content-Type、Cache-Control、Age、Via、X-Cache等字段。它们能区分是节点缓存命中、回源失败还是节点自身返回错误。
- 响应体片段：不要只截图，保留可检索的文本或HTML片段。若返回的是验证页、错误页或空内容，片段本身就能说明节点行为。
- 请求时间与节点标识：同一URL在不同时间、不同节点各请求一次，记录时间戳和节点IP或节点编号。没有节点标识，后续无法证明异常与节点相关。
- DNS解析记录：保留异常发生时的解析结果。若解析到多个IP，逐个请求并记录哪个IP返回异常，这比笼统说“CDN有问题”更有用。
- 源站对照记录：用同样的URL、同样的请求头直接请求源站，保留状态码和响应体。这是证明“源站正常”的唯一依据。
一个可执行的取证顺序
假设你发现某栏目页在部分地区返回503，源站直接访问正常。按以下顺序操作。
- 用
curl -I分别请求源站和异常节点，保存完整响应头。不要只记录状态码。 - 对异常节点重复请求三次，间隔数秒，确认是稳定异常还是偶发。稳定异常才值得进入节点侧处理。
- 用
curl -H "Host: 你的域名" http://节点IP/路径绕过DNS直接请求节点，排除解析干扰。 - 把源站对照、节点响应、时间戳整理成一份可复现记录，再提交给边缘服务商或运维。
这个动作的结果会直接影响下一步：如果绕过DNS后节点仍异常，问题在节点本身；如果绕过DNS后正常，问题在解析或调度层，证据重点应转向DNS记录和调度配置。
哪些证据容易被误用
抓取量下降、日志里蜘蛛请求变少，不能单独证明节点异常。它还可能来自抓取配额调整、站点整体流量变化或日志采样问题。保留节点响应证据，比只看抓取量更可靠。
robots.txt限制抓取不等于索引移除，站点地图也不保证收录。边缘节点异常时，不要用提交删除或改robots.txt来“止损”，那会引入新的不可逆状态。若异常节点返回的是错误内容而非错误状态码，还要分别核查不同搜索引擎的抓取表现，因为各引擎对错误内容的处理并不一致。
例外与交接条件
如果异常节点只影响非关键静态资源，且源站可回源覆盖，可以先在源站加短期回源规则，同时保留节点证据。若异常涉及HTML主文档或返回错误状态码，不要先改源站规则，应先冻结证据并通知节点侧。交接时附上可复现命令、时间戳和节点标识，比描述“部分地区打不开”更容易推动修复。修复后重新请求同一节点，确认返回与源站一致，再把该节点重新纳入观察，而不是立即关闭全部监控。
