现场是这样的。站点跑在一台 8 核 32G 的机器上，GPU 显存占用 78%，GSC 抓取统计连续三天提示主机负载错误，CPU 使用率其实只有 20%。
中间走过弯路，把「Nginx 的 fastcgi_read_timeout 只有 30 秒又被上游连续重试」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。主机负载错误看的是响应时间与超时率，不是 CPU 使用率；图片站点用 Python 做实时缩略图，单次请求要 6 秒以上；同一 IP 上还有别的业务占带宽，出口被打满导致响应变慢。
第一件事是统计慢请求的耗时分布
awk '$10>3{print $7}' access.log | sort | uniq -c | sort -rn | head再往下用 curl 分段测 TTFB 与总耗时
curl -o /dev/null -s -w 'dns=%{time_namelookup} ttfb=%{time_starttransfer} total=%{time_total}\n' https://www.example.com/随后把图片实时处理改成异步生成
systemctl restart thumb-worker && ls /var/cache/thumbs | wc -l等前面都确认过，再确认出口带宽是否被打满
sar -n DEV 1 5 | grep -E 'eth0|eth1'恢复的判定其实很直接。缩略图改成预生成后，图片请求的平均耗时从 6 秒降到 200ms，主机负载错误的提示在第四天消失。
这个提示不指向硬件性能，指的是蜘蛛访问时站点没能稳定按时响应，先查慢接口比加机器更有效。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。