Spring Boot 应用中配置了 ConnectTimeout=30s 和 SoTimeout=4s，但实际连接仍在 10 秒后中断——根本原因常是服务网格（如 Istio）的全局 connectTimeout 覆盖了客户端设置。
spring boot 应用中配置了 `connecttimeout=30s` 和 `sotimeout=4s`，但实际连接仍在 10 秒后中断——根本原因常是服务网格（如 istio）的全局 `connecttimeout` 覆盖了客户端设置。
在微服务架构中，即使你已在 CloseableHttpClient 中精确配置了所有超时参数（setConnectTimeout、setSocketTimeout、setConnectionRequestTimeout，甚至 SocketConfig.setSoTimeout），仍可能观察到连接请求在 固定 10 秒后失败，且错误日志明确提示 Connection timed out（非 Read timed out）。此时，问题极大概率不在应用层代码，而在于基础设施层的网络治理策略。
? 根本原因：Istio MeshConfig 的默认连接超时
Istio 1.12+ 版本中，MeshConfig.connectTimeout 的默认值为 10s（即 10s），该配置会作用于 Sidecar 代理（Envoy）发起的所有出站连接请求。无论上游客户端（如 HttpClient）设置多长的 connectTimeout，Envoy 都会在 10 秒后主动终止 TCP 握手过程，返回 connection refused 或 timeout —— 这正是你看到“配置无效”的真实原因。
✅ 验证方式：检查集群中 istio-system 命名空间下的 istio ConfigMap（或 mesh CRD），执行：
kubectl -n istio-system get configmap istio -o yaml | grep -A 5 "connectTimeout" # 或（Istio 1.17+）： kubectl get meshconfig istio-system -o yaml | grep connectTimeout
? 解决方案：同步调整 Istio 层超时
你需要在 Istio 控制平面显式提升该值，使其 ≥ 应用层配置（推荐略大于，如设为 35s）：
方式一：修改 MeshConfig（全局生效）
# mesh-config-patch.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
connectTimeout: 35s # ← 关键：覆盖默认 10s应用后重启相关 Pod（Sidecar 会自动热加载）：
istioctl install -f mesh-config-patch.yaml --skip-confirmation
方式二：通过 DestinationRule 为特定服务定制（推荐用于生产分级控制）
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: google-external
spec:
host: google.com
trafficPolicy:
connectionPool:
tcp:
connectTimeout: 35s # 仅对 google.com 生效⚠️ 注意事项与最佳实践
- 优先级顺序：DestinationRule > MeshConfig > 客户端配置。Istio 层超时永远优先于 HttpClient 设置。
- 端口敏感性：你提到调用 google.com:81 —— 请确认该端口是否在 Istio 的 ServiceEntry 中被正确定义并启用 mTLS/超时策略；非标准端口（如 81）易被默认策略忽略或拦截。
-
调试技巧：启用 Envoy 访问日志，观察 upstream_connect_timeout 指标：
kubectl exec -it <pod-name> -c istio-proxy -- curl -s localhost:15000/stats | grep upstream_cx_connect_timeout
-
代码优化建议：虽然客户端超时无法突破 Istio 限制，但仍建议统一配置以保持语义清晰：
RequestConfig config = RequestConfig.custom() .setConnectTimeout(30_000) // ← 保持与 Istio 一致（如 30s） .setSocketTimeout(30_000) // ← 读超时，独立生效 .setConnectionRequestTimeout(30_000) .build(); // SocketConfig.setSoTimeout() 在 HTTP/1.1 场景下通常被 RequestConfig 覆盖，可省略
✅ 总结
HttpClient 的 connectTimeout 不生效，99% 是因为服务网格（尤其是 Istio）的 MeshConfig.connectTimeout 强制截断。解决路径明确：定位基础设施层超时配置 → 显式调大 → 验证生效。切勿在应用层反复调优无果后归咎于代码，这是典型的“栈式超时覆盖”陷阱。
