RestTemplate超时配置不生效问题排查求助

1. 验证配置是否实际生效 #

• 在配置完成后，打印HttpComponentsClientHttpRequestFactory的实际参数值（比如factory.getReadTimeout()、factory.getConnectTimeout()），确认代码设置的300000毫秒是否真正生效，避免被其他逻辑覆盖。
• 注意：RestTemplateBuilder设置的超时会被后续替换的RequestFactory覆盖，最终生效的是HttpComponentsClientHttpRequestFactory中的配置，需重点确认这部分。

2. 排查上游服务的超时限制 #

• 直接用curl、Postman等工具调用目标接口，模拟长耗时请求，观察是否同样在30秒后超时。如果是，说明超时限制来自上游服务本身，需协调上游调整。

3. 检查中间代理/网关的超时设置 #

• 若请求经过Nginx、网关或负载均衡器，这些组件可能自带超时配置（比如Nginx的proxy_read_timeout）。确认这些中间件的超时参数是否被设置为30秒，导致请求被提前截断。

4. 排查局部请求的超时覆盖 #

• 检查业务代码中是否存在针对特定接口的局部超时配置，比如部分请求通过RequestCallback单独设置了超时，或者某些方法硬编码了30秒超时，覆盖了全局配置。

5. 连接池相关配置检查 #

• 若使用连接池，确认连接池的等待超时参数（比如连接池的maxWait）是否过短。虽然已设置connectionRequestTimeout，但需确保连接池配置与该参数匹配，避免因获取连接超时触发30秒限制。

6. 系统/JVM层面的全局超时 #

• 检查JVM系统属性：sun.net.client.defaultConnectTimeout、sun.net.client.defaultReadTimeout是否被设置为30秒，这些全局属性会优先于代码配置生效，可通过System.getProperty()打印验证。
• 排查操作系统TCP层的超时参数（如tcp_keepalive_time），这类情况概率较低，但可作为补充排查点。

简化配置测试（排除冗余干扰） #

可以先简化配置逻辑，避免重复设置可能引发的覆盖问题，测试是否仍出现30秒超时：

private static final Duration CUSTOM_TIMEOUT = Duration.ofMinutes(5);

// 直接构建带超时的请求工厂
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(CUSTOM_TIMEOUT.toMillisPart());
factory.setReadTimeout(CUSTOM_TIMEOUT.toMillisPart());
factory.setConnectionRequestTimeout(CUSTOM_TIMEOUT.toMillisPart());

// 构建RestTemplate时直接绑定请求工厂
RestTemplate restTemplate = new RestTemplateBuilder()
        .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
        .errorHandler(new RestTemplateResponseErrorHandler())
        .requestFactory(() -> factory)
        .build();

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