问题出现得很突然，日志倒是留得挺全。必应抓取统计里 5xx 占比到了三成七，Nginx 日志同一时段全是 upstream timed out，可白天用浏览器打开同样的页面返回 200，只有夜里十一点以后偶发。
刚开始盯着「蜘蛛抓的是带筛选参数的列表页，模板里多了一层全表统计，慢在 SQL 上」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。回源接口在夜里跑批，数据库连接池被打满，PHP 请求等不到句柄。也可能是Nginx 的 fastcgi_read_timeout 只有 30 秒，慢查询一卡就切给蜘蛛 504。
不容易想到的是，页面里调用的第三方接口夜间限流，前端等不到数据，后端拼接时就抛异常。
先按状态码统计夜间抓取失败
awk '$9>=500 {print $9}' access.log | sort | uniq -c拉出慢请求的 URL 与耗时
awk '$9>=500 {print $7, $request_time}' access.log | sort -k2 -nr | head -20随后把抓取请求与慢查询日志按秒对齐
grep 'bot' access.log | grep -c 'upstream timed out'给详情页加一层页面级缓存兜住夜间抓取
别只看报错消失，验证要多做一步。第三天必应抓取统计里 5xx 条数降到个位数，抓取成功率回到九成五以上，夜间接口超时告警不再触发。
补一句。别急着调大超时时间，蜘蛛的等待上限比浏览器短，超时调大只会把慢请求堆在队列里，问题会以 499 的形式再出现一次。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。