先看现象。巡检脚本用 HEAD 探测，CDN 对 HEAD 返回 405，报告里 1.2 万条 URL 全被标成故障。值班的人按报告排查了两天，发现页面用 GET 打开都正常。
原因不止一个，得分开看。巡检只发 HEAD，CDN 规则不允许该方法。另一种情况是脚本没区分 405 与真实故障。
还有一种情况，探测结果没有抽样用 GET 复核。
另外，故障阈值没有设置，全量上报。
上来先用 HEAD 和 GET 各测一次
curl -sI https://www.example.com/p/1 | head -1 && curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/p/1再往下确认 CDN 对 HEAD 的策略
curl -sI https://www.example.com/p/1 | grep -i allow巡检改成 GET 只读首字节
curl -s -r 0-1024 https://www.example.com/p/1 -o /dev/null -w '%{http_code}\n'剩下的就是对 405 单独归类不上报故障
python inspect.py --method GET --ignore 405手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
改完先别撤，确认这几项。报告里的故障数从 1.2 万降到真实的几十条，值班不再被误报淹没。
HEAD 省流量但兼容性差，巡检用 GET 加 Range 更接近真实抓取。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。