这个坑值得记一笔。源站前面加了限流，Googlebot 的请求里有三成拿到 429，GSC 抓取统计曲线跟着往下掉。第一反应是限流阈值设小了，把 rate 从 5r/s 调到 20r/s 跑了一晚，429 的比例只从 31% 降到 27%，日志里能看到吞吐上来了但失败数没少。服务器是 2 核 4G 的轻量实例，Nginx 1.24 加 PHP-FPM，配置是半年前交接时留下的。
刚开始盯着「回源只放行一个出口 IP 边缘节点共用配额 单节点超限牵连整条链路」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。限流按连接数而不是按请求数计算 蜘蛛并发一高就撞在 burst 上限；深夜定时备份与图片裁剪任务抢 CPU 响应时间被拉长进入限流窗口；限流触发后返回 429 且不带 Retry-After 蜘蛛按固定节奏重试越堆越多。
第一件事是按十分钟切片统计各时段被拒次数
awk '{print substr($4,14,4)}' access.log | cut -c1-3 | sort | uniq -c | sort -rn | head -20单独抽出 429 的请求行看落在哪个目录
grep ' 429 ' access.log | awk '{print $7}' | cut -d? -f1 | sort | uniq -c | sort -rn | head然后确认本机有没有在整点跑备份任务
crontab -l | grep -E 'backup|dump|tar'给限流补上 Retry-After 让重试有个间隔
add_header Retry-After 120 always;怎么算真的好了，看的是同一批现象。调整后同一份日志里 429 占比从三成降到 2% 以内，抓取成功段集中在 01 点到 05 点，凌晨那条吞吐曲线反而比白天更平稳。
提醒一点。限流参数只解决峰值，真正决定蜘蛛能不能顺畅抓取的是凌晨那段时间源站还剩多少余量，备份窗口最好和抓取高峰错开。报错文案容易误导，真正的原因往往在相邻那一层的日志里。