批量 URL 巡检的思路
上线后巡检一组页面或接口，用 curl 逐个取 HTTP 状态码与耗时，输出成清单，异常项一眼可见；URL 多时用 xargs -P 并行提速。这套做法最大的价值是可留档、可比对：固定时间跑一次并保留历史结果，两份日志一 diff 就能看出服务是否退化，比人工反复点页面可靠得多。
基本信息
| 适用平台 | 任意装有 curl 的 Linux（并行依赖 findutils 的 xargs） |
|---|---|
| 核心参数 | curl -w 自定义输出、-o /dev/null 丢弃正文、--max-time 超时 |
| 并行写法 | xargs -P N -I {} sh -c ... |
| 结果字段 | http_code、time_total、time_connect、time_starttransfer |
| 留档建议 | 结果带日期落盘并保留历史，便于逐日对比 |
典型使用场景
- 发版后批量验证关键页面与接口可用性
- 每日巡检对外服务与合作伙伴接口
- 迁移或切流后对比前后状态码分布
- 补充监控盲区：核心 URL 的外部拨测
- 归档为工单材料，批量取证
顺序与并行巡检
顺序与并行巡检
while read -r url; do
read -r code time < <(curl -sS -o /dev/null --max-time 10 -w '%{http_code} %{time_total}' "$url")
echo "$code $time $url"
done < urls.txt | awk '$1 != 200 {print "NG:", $0} $1 == 200 {print "OK:", $0}'
cat urls.txt | xargs -P5 -I{} sh -c 'code=$(curl -sS -o /dev/null --max-time 10 -w "%{http_code}" "{}"); echo "$code {}"'
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer TOKEN' https://api.example.com/health
bash check.sh > /var/log/urlcheck-$(date +%F).log 2>&1
diff /var/log/urlcheck-2026-10-12.log /var/log/urlcheck-2026-10-13.log | headcurl 输出字段怎么读
| 字段 | 含义 | 常见异常 |
|---|---|---|
| http_code | HTTP 状态码 | 502/503 上游故障；401/403 鉴权；404 路由或域名配错 |
| time_total | 整体耗时（秒） | 明显变长说明链路或后端退化 |
| time_connect / time_appconnect | TCP 与 TLS 握手耗时 | 偏高说明 TLS 或网络层有问题 |
| time_starttransfer | 首字节时间 | 反映后端处理速度 |
| exit code | curl 自身退出码 | 非 0 表示连不上、超时或证书错误，与状态码不是一回事 |
巡检结果落盘留档、固定时间执行并与前一天对比：状态码分布的变化，往往比单个错误更早暴露问题。
需要鉴权或只接受 POST 的接口不能裸 GET 巡检：否则会得到一片 405/401，那是巡检方法的问题而不是服务故障，结论会误导决策。
把 URL 清单与脚本一起纳入版本管理：谁新增了哪些条目一目了然，失效条目及时删除，避免长期误报把大家对告警的敏感度磨掉。
想要更完整的证据就把 -w 输出写成 CSV 再分析：按耗时排序能直接找出最慢的页面，比只看状态码更容易发现性能退化。
区分冷启动与复用连接的耗时：首次请求的 time_connect 与 time_total 天然偏高，连续巡检同一 URL 时数值下降属于正常现象，不要据此判定服务退化。