自建的巡检脚本每天跑一遍首页，返回 200 就记一条绿。某天发现导航里点进去全是 404，脚本毫无反应，原因是它只取了一个 URL 做探活。
一开始怀疑是「没有基线，状态码从 200 变 404 时没有对照值可比较」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。样本只覆盖首页，内页死链在巡检范围之外。另一种情况是脚本把跳转当成功，302 到错误页也记成 200。
另外，巡检只跑桌面 UA，移动模板的 500 从来没被发现。
从站点地图抽一批内页做覆盖
curl -s https://www.lu0.cn/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' | shuf -n 50 > urls.txt接着逐条取状态码并记录跳转终点
xargs -I{} curl -s -o /dev/null -w '%{http_code} %{url_effective}\n' {} < urls.txt然后把 404 与 5xx 单独告警并保留当日快照
grep -E '^(404|5[0-9][0-9])' result.txt补一组移动 UA 的复检
curl -s -A 'Mozilla/5.0 (iPhone)' -o /dev/null -w '%{http_code}\n' https://www.lu0.cn/1.html改完先别撤，确认这几项。巡检覆盖到五十条内页后，当天就抓到三个 404，修复后连续一周没有新增死链，告警邮件也不再只报首页正常。
巡检的价值在样本覆盖面，只测首页等于只测了最不可能坏的那一页，真正的坑都在深层列表和分页尾巴上。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。