这个现象在 Istio 环境里非常典型通常不是业务代码的问题而是连接空闲idle后被某一层网络设备回收而 Envoy 仍然认为连接可用导致的。你的现象可以总结为服务长时间无流量 → 第一次请求失败Connection Reset / Connection Closed / Upstream Connect Error→ 重试后恢复正常这几乎就是「空闲连接失效」的标准特征。原理分析在注入 Sidecar 后请求链路变成Client ↓ Envoy Sidecar ↓ Service ↓ Envoy Sidecar ↓ Application实际上业务流量走的是App → Envoy → Envoy → App因此会产生大量长连接池Connection Pool。场景1HTTP 长连接问题Istio 默认大量使用HTTP/2 gRPCHTTP/2 本身是长连接复用。例如Client Envoy ↓ Server Envoy保持一个连接2小时期间没流量。某层LBidle timeout350s连接被干掉。Envoy没察觉。下一次请求stream creation直接RST_STREAM GOAWAY Connection reset然后自动重建。场景2DestinationRule 的连接池配置不合理很多项目会配置trafficPolicy:connectionPool:tcp:maxConnections:100但没有配置idleTimeout导致连接无限长期保留数小时不释放。最后被中间设备干掉Envoy却继续使用。推荐解决方案方案1配置 TCP KeepAlive最推荐在 DestinationRule 中apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:name:xxxspec:host:xxxtrafficPolicy:connectionPool:tcp:tcpKeepalive:time:300sinterval:30s效果每5分钟发送KeepAlive这是生产环境最常见的解决方案。方案2设置 idleTimeouttrafficPolicy:connectionPool:tcp:idleTimeout:300s意思5分钟不用 直接关闭连接下一次请求重新建连。避免使用失效连接。例如trafficPolicy:connectionPool:tcp:idleTimeout:5m方案3开启重试推荐同时配置apiVersion:networking.istio.io/v1beta1kind:VirtualServicespec:http:-retries:attempts:3perTryTimeout:2sretryOn:connect-failure,reset,gateway-error当出现Connection ResetEnvoy自动重试。用户无感知。很多生产环境都会开启。方案4缩短连接生命周期trafficPolicy:connectionPool:tcp:maxConnectionDuration:30m定期重建连接。避免连接活几个小时当然也可以组合配置例如先配置连接池trafficPolicy:connectionPool:tcp:idleTimeout:5mtcpKeepalive:time:300sinterval:30s再配合重试retries:attempts:3retryOn:connect-failure,reset这样基本可以彻底解决「长时间无访问首次请求失败第二次恢复」的问题。