Kubernetes Pod内访问代理出现Connection reset by peer错误如何解决

• 先验证集群节点层面连通性：直接登录K8S工作节点执行相同的curl代理请求，若节点上也报错，说明是云厂商VPC、安全组或出口防火墙限制了对代理地址端口的访问；若节点上请求正常，说明问题出在K8S集群内部网络栈。
• 检查集群网络策略与插件配置：确认集群是否配置了NetworkPolicy限制Pod出口访问，是否存在针对15624端口的拦截规则；若集群部署了Istio等服务网格，检查是否开启了sidecar自动注入，sidecar的流量拦截逻辑可能对HTTP代理协议支持异常。
• 验证MTU配置匹配：K8S Pod默认MTU一般为1450（CNI封装占用额外字节），若代理服务端MTU为1500，两端不匹配会导致TCP握手成功但传输数据时连接被重置。可在Pod中执行命令curl --mtu 1400 -x http://5.188.62.223:15624 -L http://google.com测试，若请求成功即可定位为MTU问题。
• 排查出口SNAT策略：托管K8S集群默认会将Pod出口流量SNAT到节点公网IP，若代理服务端配置了同源IP访问频率限制，同一节点多Pod共享公网IP访问时可能被服务端主动重置连接。可将测试Pod调度到其他可用区的节点后重试，验证是否为源IP限制问题。
• 校验端口拦截规则：检查kube-proxy的iptables/ipvs规则，确认是否有错误配置拦截了15624端口的流量。可在Pod中执行nc -zv 5.188.62.223 15624测试TCP端口连通性，进一步定位问题在TCP层还是HTTP层。

• 若为节点出口被限制：调整云厂商VPC安全组、网络ACL的出站规则，放行到5.188.62.223:15624的TCP访问请求。
• 若为网络策略/服务网格拦截：新增NetworkPolicy规则允许测试Pod的出口访问，或直接临时放开对应命名空间的所有出口限制；若为sidecar拦截导致，给Pod添加标签sidecar.istio.io/inject: "false"豁免sidecar注入后重试。
• 若为MTU不匹配：调整CNI插件的MTU配置，使其与公网出口MTU一致，也可在Pod的启动脚本中添加命令调低网卡MTU值临时修复。
• 若为SNAT源IP被代理端拦截：为Pod配置独立的公网出口IP（如Azure Public IP per Pod、Digital Ocean保留IP绑定），或调整代理服务端的源IP访问限制规则。

内容的提问来源于stack exchange，提问作者Jack Klimov