爬虫日志分析：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /768fa938cba8.html
📄
爬虫日志分析：源站正常而边缘节点异常时应保留哪些证据
当源站日志显示抓取请求被正常响应，而边缘节点的日志或监控却出现错误、超时或状态码不一致时，不要先改源站配置。第一步应当是保留边缘侧证据，尤其是能区分“请求到达源站前被改变”和“请求到达源站后被改变”的记录。因为个别样本可能只是临时抖动，规模化后才会暴露节点、缓存或回源策略的差异，所以证据要能支持后续按节点、时间段和URL分组复核。
先固定时间窗口和请求标识，而不是先看状态码总数
边缘节点异常最常见的误导是：只看错误率上升，就直接判断源站故障。实际上，边缘侧的错误可能来自回源超时、节点缓存命中异常、TLS握手失败、请求头被改写或节点本地限流。要区分这些原因，必须先把同一批抓取请求在源站和边缘两侧对齐。
假设你手头有一份边缘节点的访问日志，以及一份源站的访问日志。先做三件事：
- 取一个固定时间窗口，例如边缘节点开始出现异常的整点前后各30分钟，不要跨天混算。
- 找出两侧都有的请求标识。如果边缘日志记录了回源请求ID、trace ID或上游请求头中的唯一值，优先用它对齐；如果没有，就用“时间戳+客户端IP+URL+User-Agent”做近似匹配，并明确这只是近似。
- 把边缘侧的状态码、响应时间、回源耗时、缓存命中状态、节点标识单独导出，不要和源站日志合并后再去重。
这一步的实际动作是：先导出边缘侧原始日志的只读副本，再在副本上按请求标识分组。这样做的结果是，你能看到同一请求在边缘侧是“直接返回错误”还是“回源后拿到正常响应但边缘改写为错误”。如果边缘侧根本没有回源记录，问题更可能在节点接入、缓存或限流层，而不是源站应用层。
保留边缘侧的回源请求与响应快照，别只留聚合指标
聚合指标能告诉你异常在变大，但不能告诉你异常发生在哪一层。对爬虫日志分析来说，边缘节点异常时最有价值的证据是回源请求和回源响应的原始快照。具体包括：
- 边缘节点向源站发出的请求行、Host、路径、查询串、关键请求头，尤其是User-Agent、Accept-Encoding、If-Modified-Since、Range等可能被边缘改写的字段。
- 源站返回给边缘节点的状态码、响应头中的Cache-Control、Vary、Content-Encoding、Content-Length，以及响应体的前若干字节或校验值。
- 边缘节点最终返回给爬虫的状态码、响应头和响应体长度。若边缘返回与源站返回不一致，这个差异本身就是证据。
- 边缘节点的节点标识、回源目标IP或回源组、连接建立时间、首字节时间、总耗时。不要只保留平均耗时，要保留单条请求的耗时分布。
这些记录的作用是判断“源站正常”是否真的成立。源站日志显示200，不等于边缘节点收到的就是200。如果边缘侧回源请求被改写了路径或请求头，源站可能对另一个URL返回200，而爬虫实际请求的URL在边缘侧仍然异常。保留请求快照后，你可以把边缘侧回源请求与源站收到的请求逐字段比对。若Host、路径或请求头不一致，下一步应检查边缘节点的回源改写规则，而不是继续在源站应用日志里找错误。
用一组可区分原因的证据，排除“源站正常”的假象
源站正常而边缘节点异常，通常有几种可区分的原因。下面这组证据可以帮助你判断该往哪个方向处理：
- 边缘有回源记录，源站也有对应记录，但状态码不同。 这指向边缘节点对响应的改写、缓存策略或响应头处理。此时应保留边缘侧最终响应和源站原始响应，比较状态码、响应头和响应体长度。
- 边缘没有回源记录，源站也没有对应记录。 这指向请求未到达回源层，可能是节点本地限流、缓存直接命中错误、TLS或连接层失败。此时应保留边缘节点的连接日志、限流计数和缓存命中记录。
- 边缘有回源记录，源站没有对应记录。 这指向回源请求在到达源站前被丢弃或路由到了其他后端。此时应保留边缘侧回源目标地址、连接结果和源站接入层的拒绝记录。
- 边缘和源站都有记录，状态码也一致，但爬虫侧仍然异常。 这指向爬虫与边缘之间的网络、DNS或客户端行为差异。此时应保留边缘侧看到的客户端IP、TLS指纹或协议版本，并与爬虫侧实际发出的请求参数核对。
这组证据的关键不是数量，而是可区分性。如果只保留“错误率从1%升到5%”这类聚合值，你无法判断是缓存问题、回源问题还是客户端问题。相反，只要保留少量带请求标识的完整样本，再按上述四类分组，就能把处理顺序定下来。
规模化后出现例外时，先确认样本边界再决定是否推广
个别样本成立，不代表规模化后仍然成立。边缘节点异常经常在单个请求上看起来像源站问题，但放大到一批请求后，才会发现只有某个节点、某个回源组或某个缓存键组合出现异常。因此，在把单个样本的结论推广到全站之前，先确认边界：
- 异常是否集中在少数边缘节点。如果只有部分节点异常，优先检查这些节点的本地配置、缓存状态和回源链路，而不是全站回源策略。
- 异常是否集中在特定URL模式或查询串。如果只有带特定参数的URL异常，优先检查边缘缓存键和Vary响应头，而不是源站路由。
- 异常是否集中在特定时间段。如果异常只在流量高峰出现，优先检查节点限流、连接池和回源超时设置，而不是源站应用逻辑。
- 异常是否与请求头有关。如果只有特定User-Agent或Accept-Encoding的请求异常，优先检查边缘节点对请求头的改写和压缩处理。
一个可执行的动作是：从边缘日志中按节点和URL模式各取一组正常样本和异常样本，分别与源站日志对齐。如果异常样本全部落在某个节点或某个缓存键上，就把处理范围缩小到该节点或该缓存规则；如果异常样本分散在所有节点，再回头检查源站回源接口和全局配置。这个动作的结果会直接决定下一步是改边缘配置、改缓存规则，还是继续查源站。
保留证据时的最小清单与常见误区
为了后续可复查，边缘节点异常时应至少保留以下内容：
- 边缘侧原始访问日志的只读副本，包含时间戳、节点标识、客户端IP、URL、状态码、响应时间、回源耗时、缓存命中状态。
- 边缘侧回源请求和回源响应的完整快照，至少保留请求头、响应头和响应体长度。
- 源站侧对应时间窗口的访问日志，包含请求ID、Host、路径、状态码和响应时间。
- 边缘节点的配置版本或变更记录，尤其是回源规则、缓存规则和请求头改写规则。
- 爬虫侧实际发出的请求参数，包括User-Agent、Accept-Encoding、协议版本和请求频率。
常见误区是只保留错误日志，不保留正常请求的对照样本。没有正常样本，就无法判断异常是边缘节点独有还是全链路都有。另一个误区是把robots.txt的抓取限制当成索引移除手段，或者认为站点地图提交后就会保证收录。这些与边缘节点异常不是同一层问题，不应混在同一份证据里判断。边缘节点异常的证据要能回答“请求在边缘侧发生了什么”，而不是“搜索引擎最终是否收录”。
当你按上述方式保留证据后，下一步的处理顺序通常会更清楚：先确认异常是否集中在边缘侧，再确认边缘侧是否改写了回源请求或响应，最后才决定是否调整源站配置。如果证据显示边缘侧没有回源记录，就不要继续在源站应用日志里找原因；如果证据显示边缘侧回源请求与源站收到的请求不一致，就优先检查边缘节点的改写规则和缓存键。这样，爬虫日志分析才能从“看到异常”推进到“知道该改哪一层”。
