curl 一直超时？先分清是 DNS、网络还是服务端

curl 一直超时，很多人第一反应是服务端挂了，其实超时只说明在规定时间内没有拿到完整响应，原因可能在 DNS、本地网络、中间链路，也可能在服务端。先分清在哪一层卡住，再动手修，效率最高。

第一步：先看超时发生在哪个阶段。用 curl -w 查看各阶段耗时：time_namelookup 是 DNS 解析耗时，time_connect 是 TCP 建连耗时，time_starttransfer 是服务端首字节耗时。如果 DNS 阶段就很长或直接失败，先查 DNS；如果 TCP 建连卡住，先查网络和端口；如果建连很快、首字节很慢，先查服务端。

第二步：判断是不是 DNS 问题。执行 nslookup 域名或 dig 域名，看是否能解析出 IP、解析是否很慢。再换一个 DNS 对照，例如用 curl --resolve 把域名强制指向已知 IP 测试：如果指定 IP 后立刻通，问题大概率在 DNS 解析或本地 hosts、DNS 缓存；如果指定 IP 仍超时，就不是单纯 DNS 问题。

第三步：判断是不是网络问题。用 ping 看丢包和延迟，用 traceroute 或 mtr 看在哪一跳开始丢包或延迟突增；用 curl -v 看是否卡在 Connecting 或 TLS 握手阶段。如果只有某一台机器、某一个网络超时，而换网络或换机器就正常，先查本地防火墙、代理、出口 NAT 和安全组放行情况，而不是改服务端代码。

第四步：判断是不是服务端问题。如果 DNS 正常、TCP 能建连，但首字节很慢或一直等不到响应，查服务端日志、慢请求、连接池、数据库慢查询和 CPU、内存、磁盘 IO 是否打满；再用 curl --max-time 设一个合理上限，避免无限等待，并用 -v 保留请求头和响应头作为排查证据。

一个实用的排查顺序是：先 DNS，再 TCP 连通性，再 TLS，再首字节耗时。按这个顺序，每一步都有明确的通过或失败标准，就不会在错误的方向上反复试错。最后提醒：不要一超时就盲目加大超时时间或反复重试，超时时间只是容忍度，不是修复手段；先定位层级，再针对性修复。