现场是这样的。WAF 的方法白名单只放了 GET 和 POST，HEAD 请求被 403。蜘蛛先用 HEAD 探测状态，拿到 403 后就降低抓取频率，日志里 GET 正常但整站抓取量在掉。
中间走过弯路，把「CDN 对 HEAD 和 GET 的缓存策略不同，问题只在探测时出现」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。HEAD 被 WAF 当成异常方法拦截，返回 403；蜘蛛用 HEAD 判断页面可用性，403 会被记成抓取错误；部分监控脚本也用 HEAD，报警一直误报。
直接发一个 HEAD 请求
curl -sI https://www.example.com/post/1/ | head -3随后对比 GET 的状态码
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/post/1/然后在 WAF 里放行 HEAD
SecRule REQUEST_METHOD "@streq HEAD" "id:1001,phase:1,pass,nolog"复核日志里的方法分布
awk '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head同一份数据我导出了两份，一份留底，一份拿来试。
这类问题以前遇到过，但这次的触发条件和上次不一样。
恢复的判定其实很直接。HEAD 恢复 200 且响应头与 GET 一致，Search Console 的抓取错误停止增长，抓取量一周后回升。
HEAD 不返回正文，但它是蜘蛛的成本最低的探测手段，挡掉它等于让蜘蛛每次都用 GET 试错。这类问题最好一次改到位，反复小改反而容易把原因搅混。