用 curl 做第一轮 HTTP 探测
命令行 HTTP 请求提供一个范围较小、容易检查的服务视角：不用经过浏览器渲染，就能看到状态、响应头、正文和耗时。开始之前先明确问题，是检查原地址是否正确跳转、最终页面能否读取，还是某种请求方法是否被接受。不同问题需要不同探测方式。一条 curl 命令成功，只能说明这次请求满足了对应条件，不能证明网站所有功能都正常，也不能直接代替用户实际访问路径的验证。 分开保存四类证据 默认情况下，curl 输出响应正文，即使 HTTP 表达错误，进程也可能成功退出。命令退出状态描述传输工具的结果，HTTP 状态则描述已经收到的响应，两者都应该保留。收到正文为“missing”的四零四响应，与根本没有取得 HTTP 响应的连接失败，并不是同一种故障。监控脚本需要明确判断自己关心的响应契约，不能只靠 shell 有没有返回非零状态。 -D 用于保存响应头，-o 指定传输输出去哪里，-w 则单独打印选定的元数据。-sS 隐藏进度条，同时保留错误信息；--max-time 限制传输时间，跟随跳转的探测还应限制最多跳转次数。保存结果时记录所用选项，之后比较才知道方法、地址和请求头是否相同。把这些维度混在一起，往往会把客户端条件变化误认为服务器行为变化。 耗时指标也受连接复用、代理路径和跳转影响。复用连接可能根本不发起新的 DNS 查询；对比之前应保证条件相当，不能因为查询时间一项下降，就判断 DNS 服务性能已经改善。 坏掉的样子 一开始就加 -L，可能让健康的最终页面掩盖错误的第一跳。排查路由时先看原始状态和 Location，验证目标内容时再明确选择跟随。跳转循环、意外的目标主机或方法变化，都可能有问题，即便链条后面某个页面返回二百。不能把“总是跟随跳转”当作所有探测都适用的成功定义；跳转行为本身有时就是要验证的契约。 -I 发送的是 HEAD，不是 curl 发出 GET 后简单丢弃正文。服务器、代理和授权规则可能对这两种方法处理不同。HEAD 失败、GET 成功时，应先检查方法差异，不要立即判定资源不可用。同样，修改 User-Agent 请求头，也不会让 curl 自动具备浏览器的 JavaScript、排版、Cookie 规则或 CORS 执行能力。这些行为仍需要在对应环境里分别检查。 ...