U=https://www.example.com
curl -s -o /tmp/p -w '%{http_code} %{size_download}\n' $U
grep -c '首页标识文案' /tmp/p
巡检脚本对所有站点发一次 GET，状态码 200 就算通过，那天站点挂着维护页，一天下来一条告警都没有，交接时才被发现。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，只看 HTTP 状态码，维护页和自定义错误页都是 200 返回，脚本没有比对任何页面内容，这套健康检查基本等于没做，出了事也拦不住。
这次卡住的地方就在「巡检脚本误判 200」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
处理上按这个顺序：加一个必须出现的关键字，或者给响应长度设个下限；维护页干脆直接返回 503，不要再拿 200 假装站点一切正常；巡检时带上关键接口，不能只探一个首页就算完。
改完只确认一件事：切到维护页后巡检立刻判失败并告警，正常页面的关键字校验稳定通过。