百度蜘蛛持续拿 503 抓取频次掉到最低

这个坑值得记一笔。百度搜索资源平台的抓取频次从每天八万降到六千，抓取诊断里大量请求返回 503，源站日志显示是 PHP-FPM 进程池打满，重启后半小时又出现。

刚开始盯着「503 时没有返回 Retry-After，百度按失败直接降频」，折腾了半个多小时，排掉了。

排查方向其实有限，先把可能性排一排。PHP-FPM 的 pm.max_children 太小，并发一高就排队超时；蜘蛛抓取的列表页有慢查询，单请求占用进程十几秒；监控只盯 5xx 总量，没按 UA 拆分看。

第一件事是按 UA 统计 503 的比例

awk '$9==503 {print $12}' access.log | sort | uniq -c | sort -rn | head

随后看进程池的排队情况

curl -s http://127.0.0.1/status?full | grep -E 'active|listen queue'

调大进程数并给慢查询加索引

pm.max_children = 64

503 响应补上重试提示

add_header Retry-After 60 always;

改完先别撤，确认这几项。蜘蛛请求的 503 比例降到 1% 以下，百度抓取频次两周后回升，列表页平均响应时间回到 300ms 内。

容易忽略的是，503 对抓取频次的影响比 404 大得多，蜘蛛会把它当成站点不可用，宁可先限流也别让进程池打满。报错文案容易误导，真正的原因往往在相邻那一层的日志里。