OkHttp3 4.9.0的connectTimeout/callTimeout未生效，请求提前结束

你遇到的“请求远早于设定超时阈值完成、配置看似不生效”的情况，是对OkHttp超时运行逻辑的认知偏差，并非库的行为异常。

超时配置的实际运行规则 #

OkHttp中connectTimeout的定义是：从发起TCP连接请求开始，到连接成功建立完成的 最长允许等待上限，绝非“无论流程状态如何都必须硬等满设定时长才结束”的固定计时器。
如果在等待过程中，底层网络栈提前返回了明确的连接错误，OkHttp会立刻将错误向上抛出，不会为了凑够剩余等待时间强行阻塞流程。

你的测试场景为什么触发不了4秒连接超时 #

你用于测试的“不存在的非托管服务器地址”，在Android模拟器网络环境中属于两类会快速返回错误的场景，完全走不到等待超时的分支：

• 地址属于系统判定的不可路由网段：网络栈会直接返回ENETUNREACH（网络不可达）错误，全流程仅耗时数毫秒
• 地址网络可达，但对应端口无服务监听：目标网络栈收到TCP连接请求后，会直接返回RST包终止流程，抛出ECONNREFUSED（连接被拒绝）错误，全流程仅耗时数十毫秒
  两类场景的错误返回速度远快于你配置的4秒超时阈值，因此会给你“超时配置完全没生效”的错觉。

如何正确验证超时配置生效 #

如果要复现真实的连接超时场景，需要选择符合“TCP黑洞”特征的测试目标：即目标网络可以收到你发出的SYN连接包，但既不返回SYN-ACK完成握手，也不返回RST包拒绝连接，直接将请求包静默丢弃。
只有在这种丢包场景下，系统网络栈不会主动返回连接错误，流程才会一直等待到你配置的超时阈值到达，抛出SocketTimeoutException: connect timed out的超时错误，此时才能证明超时配置是正常生效的。

容易踩的认知误区 #

很多开发者会误把超时值当成固定等待时长，这是非常常见的认知偏差。超时本质是兜底的上限阈值：只要流程可以快速完成——不管是成功建立连接，还是快速返回明确的连接错误，都会立刻结束，不会刻意卡到超时时间点。

内容的提问来源于stack exchange，提问作者hannes ach