接口超时先别急着重启：用 curl 四段定位到底卡在哪一步

调用接口超时，第一反应往往是重启服务。但重启只能掩盖问题：如果是 DNS 慢、证书过期、后端 SQL 慢，重启后照样超时。curl 自带的分段计时，能把一次请求拆成 DNS 解析、TCP 建连、TLS 握手、服务端处理四段，哪段慢就修哪段。
先用一条命令拿到分段耗时：curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}' https://example.com/api/health
五个数字分别对应：DNS 解析耗时、TCP 建连耗时、TLS 握手完成耗时、首字节耗时、总耗时。对比它们，就能定位。
第一段：DNS 慢。time_namelookup 就很大，比如超过 1 秒。先用 dig +trace 或 nslookup 看解析走哪台服务器，再检查本机 /etc/resolv.conf 是不是指向了响应慢的 DNS。内网服务更常见的是写错了域名后缀，或者 hosts 里残留了旧 IP。修 DNS 配置，别在应用层加重试硬扛。
第二段：TCP 建连慢。time_connect 大，说明包到了对方门口却握手慢。先确认对方端口确实在监听：ss -tlnp | grep 端口。再看防火墙和安全组：云服务器上最常见的就是安全组没放行，或者本机 iptables 规则把出方向拦住了。用 telnet IP 端口或 nc -vz IP 端口做一次裸连测试，能通说明网络没问题，问题在上层。
第三段：TLS 握手慢或失败。time_appconnect 明显大于 time_connect，或者直接报证书错误。先用 curl -v 看握手停在哪一步，再用 openssl s_client -connect 域名:443 -servername 域名检查证书链是否完整、是否过期、有没有混用旧 TLS 版本。自签证书、中间证书缺失、证书过期，这三类问题在浏览器里可能只显示一个含糊的报错，在 openssl 输出里却一目了然。
第四段：服务端处理慢。前面三段都很快，只有 time_starttransfer 大，说明请求已经进了服务端，是后端处理慢。这时别再折腾网络，去看服务端日志和慢查询：接口是不是没走索引、是不是在循环里调了外部接口、有没有锁表。可以在服务端加一行耗时日志，把“收到请求”和“返回响应”两个时间点打出来，和 curl 的 TTFB 对上，责任立刻分清。
还有一类容易误判的情况：总耗时刚好卡在超时阈值上，比如应用设了 5 秒超时，而接口平时 4.8 秒。平时能跑、偶尔超时，根因往往是偶发的慢查询或 GC 停顿。把超时阈值调大只是把报错往后推，正确做法是先修慢的那一段，再根据 P95 耗时定一个留有余量的阈值。
排查顺序建议固定下来：先跑分段计时定段，再按段用对应工具验证，最后只改确认有问题的那一处。改完再跑一次同样的 curl 命令，对比五个数字，确认慢的那段真的降下来了，再收工。这样下次再遇到超时，不用凭感觉重启，一条命令就能说清卡在哪一步。