现场是这样的。巡检脚本每次先拉 robots.txt，超时后按默认值处理成允许全站。线上 robots 里其实有 Disallow: /admin/，脚本因此把后台地址也扫了一遍，触发 WAF 告警。
中间走过弯路，把「脚本没有重试，单次失败就下结论」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。超时分支没有区分「拿不到」和「允许全部」；默认值按 5xx 处理，但这里只是网络超时；巡检目标没有排除后台路径。
手工测 robots 的响应时间
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/robots.txt给巡检加三次重试
curl -s --retry 3 --retry-delay 2 https://www.example.com/robots.txt | head -5超时按拒绝处理并告警
python inspect.py --on-timeout deny末了把后台路径加入排除名单
python inspect.py --exclude /admin/同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
恢复的判定其实很直接。超时不再被当成全站放开，后台路径不再出现在巡检名单，WAF 误报归零。
这里还有个坑。robots 拉取失败有两种含义，4xx 是允许、5xx 是禁止，超时应该停下来告警。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。