用 curl 一条命令分清“服务挂了”还是“网络慢

什么情况下会撞上它

浏览器打开页面一直转圈，或 DSH 定时任务该投递提示词却没收到消息。第一反应常是“服务挂了”，但真实原因可能是 DNS 慢、TLS 握手卡住或链路丢包，服务本身活着。两者处置完全不同：前者查进程和日志，后者查链路和解析。

怎么做

先只看响应头：

curl -I -L https://example.com/health

-I 发 HEAD 请求，-L 跟随重定向，避免 301/302 被误读成异常。

再打耗时：

curl -I -L -o /dev/null -s \
  -w '%{http_code} %{time_namelookup} %{time_connect} %{time_appconnect} %{time_total}\n' \
  https://example.com/health

四个时间点累加：time_namelookup 是 DNS 耗时，time_connect 是 TCP 建连完成，time_appconnect 是 TLS 握手完成，time_total 是总耗时。看差值比绝对值有用：time_total 大而 time_connect 小，慢在服务端处理或传输；time_namelookup 占比高就是解析问题。

再查 DSH 本机投递接口，排除外网因素：

curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
  -X POST http://127.0.0.1:3080/api/dsh-im/delivery/messages \
  -H 'Content-Type: application/json' \
  -d '{"botId":"demo","targetId":"demo-target","text":"ping","format":"plain"}'

返回 200 且毫秒级，说明投递链路本身通。format 只接受 plain 或 markdown，传别的值不会返回 {"sent": true}。把这条命令放进 DSH 的 schedule 能力定时跑，结果经本地投递接口发回会话，就是一条低成本巡检记录。投递目标写在 /integrations/dsh-<渠道>/workspaces.json 的 deliveryTargets 里。

为什么有效

状态码回答“服务是否可达并正确响应”，耗时回答“慢在哪一段”。000 通常表示连接没建立（DNS 失败、拒绝连接、超时），5xx 表示服务在但处理出错，2xx/3xx 配大 time_total 则是链路或后端处理慢。

怎么确认成了 / 哪一步失败

• 000：连接层失败，先看 time_namelookup 是否异常大，再确认端口是否监听。
• 502/503/504：服务在但上游不可用，查 DSH 进程与 /sessions/ 下 session.v4.jsonl.zstd 的写入。
• 200 但 time_total 超预期：对比 time_connect 与 time_total，判断建连慢还是响应慢。
• 投递接口返回非 {"sent": true}：检查 botId、targetId 是否在 deliveryTargets 中，以及 format 取值。

边界

-I 发 HEAD，部分服务对 HEAD 响应不同甚至返回 405，改用 -X GET -o /dev/null。-L 会跟随重定向，关心原始跳转时去掉。-w 时间字段只反映本次请求，不代表并发表现；带鉴权的接口需额外加头，否则拿到 401 而非真实状态。插件配置在 /integrations/dsh-im/，具体字段以当前版本为准。