Spring WebService 中 HttpClient 连接超时未按配置生效（如设为 4s 却始终等待 10s），通常并非代码或 Spring 配置问题，而是底层服务网格（如 Istio）的全局 connectTimeout 限制所致。
spring webservice 中 httpclient 连接超时未按配置生效（如设为 4s 却始终等待 10s），通常并非代码或 spring 配置问题，而是底层服务网格（如 istio）的全局 `connecttimeout` 限制所致。
在您提供的配置中，RequestConfig.setConnectTimeout(30_000) 和 SocketConfig.setSoTimeout(4000) 均已正确定义——前者控制 TCP 连接建立阶段的超时（即“connection timeout”），后者控制数据读取阶段的 socket 级超时（即“read timeout”）。然而，实际观测到稳定 10 秒连接中断，且该值恰好与 Istio MeshConfig 的默认 connectTimeout 一致（v1.12 及之前版本默认为 10s），这强烈表明：请求在到达您的应用前，已被 Istio Sidecar（Envoy）代理强制终止。
Istio 的 connectTimeout 是一个网络层硬性限制，作用于 Envoy 出站连接池发起下游连接（如访问 google.com:81）时的建连阶段。它独立于应用层 HttpClient 配置，且具有更高优先级——即使您在代码中设置 connectTimeout=4000，Envoy 仍会在 10 秒后主动关闭连接尝试，导致应用层抛出 java.net.ConnectException: Connection timed out 或类似异常。
✅ 验证方法：
- 检查集群是否启用 Istio：kubectl get pods -n istio-system
- 查看当前 MeshConfig：
kubectl get meshconfig -n istio-system istio -o yaml | grep -A 5 "connectTimeout"
输出示例：
connectTimeout: 10s
✅ 解决方案（按推荐顺序）：
-
调整 Istio MeshConfig（全局生效）
编辑 MeshConfig，将 connectTimeout 提升至合理值（如 30s）：apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: meshConfig: connectTimeout: 30s执行 istioctl install -f your-operator.yaml 并重启受影响 Pod。
-
使用 DestinationRule 覆盖特定服务（推荐用于生产）
若仅对 google.com 或某外部服务放宽限制，定义 DestinationRule：apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: external-google namespace: default spec: host: google.com trafficPolicy: connectionPool: tcp: connectTimeout: 30s
⚠️ 重要注意事项：
- SocketConfig.setSoTimeout(4000) 设置的是 SO_TIMEOUT（即 socket.read() 阻塞超时），影响读操作，不影响连接建立；而 RequestConfig.setConnectTimeout() 控制 Socket.connect() 超时，但会被 Istio 的 connectTimeout 截断。
- 访问 google.com:81 属于外部服务调用，在 Istio 中需配合 ServiceEntry + DestinationRule 显式声明，否则可能被默认策略拦截或限流。
- Spring Boot 2.7.x + httpclient 4.5.13 本身无此 10s 限制，可本地绕过 Istio（如 curl -v http://google.com:81）验证是否仍超时，以排除 DNS、防火墙等其他因素。
? 总结：当 HttpClient 连接超时表现“不听配置”，请优先排查基础设施层（Istio/Envoy、Kubernetes NetworkPolicy、云厂商 SLB）的网络超时策略——应用层配置永远无法突破底层代理设定的硬性边界。
