Spring Boot 应用中配置了 HttpClient 的 connectTimeout 为 30 秒，但实际仍触发 10 秒连接超时，根本原因常是服务网格（如 Istio）在底层网络层强制设定了更严格的默认连接超时（MeshConfig 中 connectTimeout: 10s），覆盖了应用层配置。
spring boot 应用中配置了 httpclient 的 connecttimeout 为 30 秒，但实际仍触发 10 秒连接超时，根本原因常是服务网格（如 istio）在底层网络层强制设定了更严格的默认连接超时（meshconfig 中 `connecttimeout: 10s`），覆盖了应用层配置。
在基于 Spring Web Services 的微服务架构中，即使你严谨地通过 RequestConfig 和 SocketConfig 显式设置了连接超时（setConnectTimeout(30_000)）和 socket 超时（setSoTimeout(4000)），仍可能观察到固定 10 秒连接失败——这通常不是 HttpClient 或 Spring WS 的行为，而是基础设施层（尤其是服务网格）介入的结果。
? 根本原因：Istio MeshConfig 的全局连接超时
Istio 自 v1.10 起，默认 MeshConfig.connectTimeout 为 10 秒（见 Istio v1.12 官方文档）。该配置作用于 Envoy Sidecar 的上游连接建立阶段，发生在 TCP 握手层面，早于 HttpClient 的 connectTimeout 生效时机。因此，无论你在应用中设置多长的 connectTimeout，只要底层 Envoy 在 10 秒内未能完成与目标（如 google.com:81）的 TCP 连接，就会直接中断并返回 Connection refused 或 Connect timeout，应用层超时配置完全失效。
✅ 验证方法：
- 检查集群中 istioctl proxy-config cluster <pod-name> 是否存在目标服务条目；
- 执行 kubectl get mesh -o yaml 查看 spec.connectTimeout 值；
- 在非 Istio 环境（如本地 Docker 或裸机）复现相同调用，确认是否仍为 10 秒超时。
✅ 解决方案：同步调整 Istio 层超时
需在 Istio 控制平面显式延长连接超时，而非仅修改应用代码：
# istio-mesh-config.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
connectTimeout: 30s # ⚠️ 必须 ≥ 应用层 connectTimeout应用后重启受影响 Pod（Sidecar 会自动 reload）：
istioctl install -f istio-mesh-config.yaml --skip-confirmation kubectl rollout restart deployment/<your-app-deployment>
? 补充建议与注意事项
- 端口合理性检查：你示例中调用 google.com:81 —— Google 官方不监听 81 端口（HTTP 默认为 80/443），该请求本身会因无服务响应而快速失败（RST），但若经 Istio 转发，仍受 connectTimeout 约束。建议先用 curl -v http://google.com:80 或 telnet google.com 80 验证连通性。
-
超时层级关系：
Istio connectTimeout（网络层） < HttpClient.setConnectTimeout()（TCP 连接建立） < HttpClient.setSocketTimeout()（数据读取）
应用层超时必须小于等于基础设施层，否则无效。 - Spring Boot 2.7+ 兼容性：httpclient:4.5.13 与 spring-ws-core:3.1.3 组合无已知超时覆盖缺陷，可排除版本兼容性问题。
✅ 总结
当 HttpClient 连接超时“不生效”且稳定卡在 10 秒，优先排查服务网格（Istio / Linkerd）的全局连接策略。应用层配置是必要但不充分条件；真正的连接控制权在基础设施层。统一协调 MeshConfig.connectTimeout 与 RequestConfig.setConnectTimeout() 的数值，并确保目标服务端口真实可达，才是可靠解决路径。
