这类问题我又碰上了一次。巡检脚本把非 200 一律算故障，CDN 对单 IP 限速后返回 429，凌晨那一轮跑完报告里三百条 URL 全红，值班的人以为源站挂了。
第一反应是「429 没有单独归类，和 5xx 混在一起统计」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。脚本只判断状态码是否等于 200；巡检出口 IP 固定，请求密集触发 CDN 限速；重试策略缺失，第一次 429 就直接记失败。
第一件事是看一轮巡检里 429 的占比
grep -c ' 429 ' check.log随后把 429 单列并加指数退避重试
python check_site.py --retry 3 --backoff 2 --treat-429 retry给巡检加请求间隔和随机 UA
python check_site.py --qps 2 --random-ua末了确认报告里故障数与真实 5xx 一致
grep -cE ' 5[0-9]{2} ' check.log报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
怎么算真的好了，看的是同一批现象。429 被重试消化后不再计入故障，报告里的红色条目只剩真实的 5xx，值班误报明显减少。
限速是正常响应，不是故障，巡检脚本对 3xx、4xx、5xx 要分别定义处理方式。这类问题最好一次改到位，反复小改反而容易把原因搅混。