接口超时，先分清是哪一段超时

调接口报超时，第一反应常常是把超时时间调大。调大之前，先分清超时发生在连接、握手还是等响应这三段里，调错地方等于没调。

连接超时，是 TCP 握手没完成。常见原因有三个：对方地址不通，或者端口没放行，或者路由不通。curl 上看，time_connect 一直涨不到数字，请求根本没发出去。这时调大读超时没有用，要先确认地址和端口通不通。

TLS 握手超时，卡在证书交换这一步。time_appconnect 迟迟出不来，可能是证书链不完整，也可能是协议版本对不上，还可能是中间设备拦截了握手。抓包能看到 ClientHello 发出去之后没有 ServerHello 回来，就往这个方向查。

读超时，是连接建好了、请求发出去了，等响应等不到。time_starttransfer 是关键数字，它是从请求发出到收到第一个字节的时间。这个数字大，说明服务端处理慢，或者响应在半路被某个环节卡住。服务端日志里有没有收到请求，是区分两边的直接证据：服务端没收到，查中间链路；服务端收到了但处理慢，查服务端内部。

写超时比较少见，请求体发不出去。上传大文件时容易遇到，原因是接收方读得慢、发送缓冲区满了。表现是请求发到一半卡住，服务端可能只收到半截 body。

排查顺序可以固定下来。先用 curl -w 把几个时间数字打出来：time_connect 看握手，time_appconnect 看证书交换，time_starttransfer 看首字节，time_total 看全程。看卡在哪一段，一眼就能对上。再对照服务端日志，确认请求到没到。最后才动超时配置，而且只动卡住的那一段。

超时时间不是越大越好。读超时设得过大，一个慢请求会把连接池和线程占很久，别的请求跟着排队。合理的做法是分段设：连接超时短一点，读超时按接口正常耗时留两到三倍余量，超过就让它快点失败，失败了再看日志，而不是一直等。