SocketTimeoutException不是错误而是预期内的网络信号，需区分connect超时（应快速失败）与read超时（可重试+退避），按依赖等级分层设置超时值，并仅对幂等操作启用有限重试。
SocketTimeoutException 不是程序故障，而是网络通信中必须面对的现实信号。关键不在于“消灭”它，而在于理解它在什么环节出现、代表什么含义，并据此做分层响应。
区分 connect 超时和 read 超时
两者行为和应对策略完全不同：
- connect 超时：发生在 TCP 三次握手阶段。常见于服务器宕机、端口未监听、防火墙拦截或 DNS 解析失败。此时加长超时无意义，应快速失败，配合服务发现机制切换地址，或触发告警
- read 超时：连接已建立，但服务端迟迟不返回数据。可能源于慢 SQL、GC 停顿、锁竞争或上游依赖卡顿。这类超时才适合重试+退避，但前提是操作幂等
Java 中必须分开设置：setConnectTimeout() 控制前者，setReadTimeout()（HttpURLConnection）或 setSoTimeout()（原生 Socket）控制后者。混用或只设一个，会导致误判。
按依赖等级分层设超时值
全局统一设 30 秒看似稳妥，实则掩盖问题、拖慢故障发现。合理做法是依据调用方与被调用方的关系设定：
- 同机房内部服务：connectTimeout=1000ms，readTimeout=2000ms
- 跨机房 HTTP 接口：connectTimeout=3000ms，readTimeout=5000ms
- 第三方支付/短信回调：connectTimeout=5000ms，readTimeout=15000ms，且必须搭配熔断器（如 Hystrix 或 resilience4j）
注意：Tomcat 的 connectionTimeout 是 accept 队列等待超时，不影响应用层 socket 读写，别和它混淆。
重试必须带条件和节制
不是所有超时都该重试：
- 仅对幂等读操作启用重试（例如查订单状态、获取配置）
- 非幂等操作（如支付扣款、库存扣减）必须直接失败，交由业务层决定是否人工介入
- 重试需配合指数退避：1s → 2s → 4s，且最大重试次数建议 ≤2 次
- 若上游已限流（如 HTTP 429）、或下游明显夯住（如 DB 死锁），重试只会放大雪崩风险
排查底层真实瓶颈
很多“超时”表象背后是系统级问题：
- Linux 大量 TIME_WAIT 状态耗尽本地端口，表现为“连不上”，而非“读超时”。可调大
net.ipv4.ip_local_port_range或启用net.ipv4.tcp_tw_reuse - JDK 8u291 之前版本中
getSoTimeout()返回值不准，影响超时诊断 - 使用 OkHttp 或 Apache HttpClient 时，其内置超时配置优先级高于原生 Socket 设置，务必确认最终生效的是哪一层
真正可靠的容错，靠的不是堆参数，而是把 SocketTimeoutException 当作一个可观测信号——记录指标、关联链路、分析分布，再反向优化依赖和服务。
