报错是这么冒出来的。巡检和监控脚本大量用 HEAD 探活 日志里 HEAD 占三成 做抓取分析时把这些也当成蜘蛛访问 得出蜘蛛一天来 20 万次的结论 实际 GET 只有 6 万 差点因为误判去扩容
中间走过弯路，把「部分 CDN 把 HEAD 也记成一次请求」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。分析脚本没有区分请求方法。另一种情况是监控探活和蜘蛛抓取共用同一份日志。
不容易想到的是，统计口径没写清楚 看的人默认全是抓取。
先按请求方法拆开统计
awk '{print $6}' access.log | sort | uniq -c只统计 GET 的蜘蛛请求
awk '$6~/GET/ && $0~/Baiduspider/' access.log | wc -l接着把监控探活挪到独立 server 块
location = /health { access_log off; return 200; }等前面都确认过，再对比 GET 条数与抓取后台
python crawl_stat.py --method GET别只看报错消失，验证要多做一步。GET 统计量与抓取后台吻合 HEAD 不再混入 扩容决策基于真实数字。
日志统计第一步永远是按方法过滤 不区分 GET 和 HEAD 的曲线只能当噪音看。报错文案容易误导，真正的原因往往在相邻那一层的日志里。