upstream connect error 表明Envoy无法建立上游连接，未必是Pod未就绪；需排查端口监听、网络连通性、Endpoint同步、TLS证书及资源限制五大原因。
如果您在Envoy日志中观察到upstream connect error，该错误并不必然意味着目标Pod未处于Ready状态，而是表明Envoy无法成功建立到上游服务的连接。以下是多种可能原因及对应排查方法：
一、检查目标Pod是否真正就绪
Pod的Ready状态仅反映其容器已启动并通过readiness probe，但不保证服务端口实际可被Envoy访问。需确认Pod不仅状态为Running且Ready，其监听端口也确实在运行并接受连接。
1、登录容器服务控制台，在集群列表中单击目标集群名称。
2、在左侧导航栏选择工作负载 > 无状态，设置命名空间为目标服务所在命名空间。
3、在目标应用右侧操作列单击详情，切换至“事件”页签，查看是否存在Readiness probe failed等事件。
4、切换至“日志”页签，选择istio-proxy或业务容器，确认应用进程已启动并监听预期端口（如：Listening on :9080）。
二、验证服务端口可达性与网络连通性
Envoy作为Sidecar，依赖底层网络将流量转发至目标Pod IP和端口。若网络路径中断或端口被拦截，将直接触发upstream connect error。
1、在目标Pod所在节点上执行命令：curl -v http://
2、若使用Terway网络插件，确认eni-config中eniip_virtual_type配置未误禁用datapathv2加速路径，避免service流量异常绕行。
3、检查目标Pod所在节点的安全组规则，确保允许来自网关或同集群其他节点的入向流量，端口范围需覆盖服务实际监听端口。
三、审查服务发现与Endpoint状态
Envoy通过xDS从控制平面获取上游Endpoint列表。若Endpoint未同步或为空，Envoy将无法路由请求，导致连接失败。
1、执行命令：kubectl get endpoints
2、若ENDPOINTS为空，检查Service selector是否与Pod labels完全匹配，包括大小写与键值对。
3、在ASM控制台网格管理页面，进入目标实例，查看“服务发现”页签中该服务的Endpoint数量与健康状态是否一致。
四、排查TLS/证书握手失败
当启用mTLS时，upstream connect error常伴随reset reason: TLS error或CERTIFICATE_VERIFY_FAILED，表明证书链校验未通过，而非Pod就绪问题。
1、检查Consul或Istio CA是否已初始化，是否存在日志提示“CA is uninitialized and unable to sign certificates yet”。
2、确认目标Pod中istio-proxy容器的证书文件（/etc/certs/）存在且权限正确，mtls模式下需有cert-chain.pem、key.pem、root-cert.pem。
3、在Envoy日志中搜索“ssl.connection_error”或“TLS error”，定位具体失败阶段（如SNI不匹配、过期、签名算法不支持）。
五、确认上游服务资源限制与健康度
即使Pod Ready且端口开放，若服务进程因OOMKilled、CPU节流或主动拒绝连接（如连接数满），Envoy仍会收到connection refused或reset before headers。
1、执行命令：kubectl describe pod
2、查看Pod资源指标：kubectl top pod
3、在目标服务代码中确认是否设置了最大连接数限制（如Netty的maxConnections、Tomcat的maxThreads），并检查当前活跃连接数。
