蜘蛛抓取页面时，遇到 404 通常只是放弃当前地址；遇到 5xx 或请求超时，情况会不太一样：它拿不到有效内容，还可能反复重试。如果错误集中在某些栏目或某些时段，抓取预算会被浪费在等响应上。这篇文章整理一套偏运维和运营结合的自查思路。
为什么 5xx 比 404 更容易拖住抓取
404 表达的是“这个地址不存在”，蜘蛛记录后一般会降低对该地址的访问。5xx 表达的是“服务器暂时无法处理”，蜘蛛通常理解为临时故障，可能过一段时间再来。问题在于，如果同一个地址持续 5xx，或者大量地址同时超时，蜘蛛会降低对站点的整体信任：它不知道下一次来能不能拿到内容，抓取频率和覆盖范围都可能受到影响。
把 5xx 当成“临时”来处理是对的，但前提是它真的短暂。如果连续几天都是同一批 URL 报错，对蜘蛛来说就不再是临时故障。
先分清错误类型，再找原因
不同状态码指向的问题不一样，混在一起看容易误判。
- 500 Internal Server Error：应用代码异常、数据库连接失败、配置错误，通常需要看应用日志。
- 502 Bad Gateway：网关或代理连不上后端，常见于 PHP-FPM 进程不够、后端服务挂掉、CDN 回源失败。
- 503 Service Unavailable：服务主动拒绝请求，可能是限流、维护、连接池耗尽。
- 504 Gateway Timeout：后端处理超时，常见于慢查询、外部接口卡住、脚本执行时间过长。
如果日志里 5xx 的 URL 高度集中，比如都落在搜索页、筛选页或某个详情接口，优先排查这些页面的查询逻辑；如果分散在全站，更可能是服务器资源或网络层的问题。
从日志里定位的四个角度
- 按时间看：错误是突增还是持续？突增通常和发布、活动、爬虫集中访问或攻击有关。
- 按 URL 看：是个别栏目还是全站？带参数的 URL 是否更容易超时？
- 按 UA 看：蜘蛛请求和用户请求是否都报错？如果只有蜘蛛报错，可能是限流规则或 WAF 误拦。
- 按上游看：数据库、缓存、队列、第三方接口，哪一层先出现异常。
不要只看错误数量。一次发布后静态资源 404 和一次数据库故障 500，处理优先级完全不同。
日常自查清单
- 服务器 CPU、内存、磁盘 IO 是否有长期高位，是否有进程被 OOM 杀掉。
- PHP-FPM、应用线程池、数据库连接池是否够用，队列是否堆积。
- Nginx、网关、CDN 的超时时间是否设置合理，回源是否稳定。
- 是否对蜘蛛做了过于严格的频率限制，导致大量 429 或 503。
- 监控是否覆盖 5xx 比例、响应时间、抓取失败率，而不只是服务器在线状态。
- 发布、迁移、改配置后，是否观察过一段时间的错误日志。
维护窗口别直接返回 200 空页面
计划维护时，比较稳妥的做法是返回 503，并带上 Retry-After 头，告诉蜘蛛稍后再来。直接返回 200 但内容为空，容易被当成低质页面；返回 404 又会让蜘蛛误以为地址失效。两者都不如明确告诉对方“现在不可用，稍后恢复”。
如果只是部分功能维护，尽量保证内容页可访问，把维护限制在后台或接口层，减少对抓取的影响。
把降级和重试分开处理
遇到突发流量或依赖故障时，可以提前准备降级方案：缓存旧内容、关闭非核心功能、限制复杂查询。但降级不等于把错误页返回给蜘蛛。能返回缓存内容就返回缓存，不能返回时用 503 加 Retry-After，比让蜘蛛一直等超时更友好。
最后，别等蜘蛛抓取量掉了才看服务器错误。把 5xx 和超时纳入日常监控，结合日志按 URL、时间、UA 做简单分组，很多问题在影响抓取之前就能发现。