容器代理IP无法访问互联网：先确认容器出网路径，再判断代理参数

容器里配置了代理 IP，却出现域名解析失败、连接超时或“没有互联网”，不一定是代理资源失效。容器请求还要经过 Pod 或容器网络、节点出口、NAT 或 EIP、子网 ACL、主机防火墙和代理握手；其中任一层没有回程或出站权限，应用都会把不同故障显示成同一句网络错误。

本文只讨论自有集群、云主机和获授权的网络测试。不要为了验证而把节点或容器端口暴露到公网，也不要把完整代理账号、密码或 Token 写进镜像、环境变量截图和日志。生产规则应按最小权限和变更审批执行。

先画出容器真正的出网链路

从容器发出一个代理请求，通常要经过：

应用 → 容器代理变量 → Pod/容器网卡 → 节点路由 → NAT 或节点 EIP → 上游代理入口 → 目标服务

这条链路和“节点能打开网页”不是一回事。节点可能拥有公网 EIP，但容器所在子网没有可用默认路由；集群也可能通过 NAT 统一出网，容器看到的源地址并不是节点地址。先确定出网方式，再判断代理主机、端口和认证是否正确。

用三次测试分离 DNS、网络和代理握手

在一个测试容器中固定同一目标，关闭自动重试，每次只改变一个变量。

第一次：只测容器 DNS

查看容器实际使用的解析器和搜索域，解析一个自有测试域名或上游代理域名。若容器内失败而节点成功，优先检查 CoreDNS、容器 DNS 配置、网络策略和子网解析；此时还没有进入代理握手，换 IP 没有意义。

容器能解析域名，也不代表能访问解析出的地址。保留解析时间和结果的脱敏摘要，避免将真实业务域名和内部地址写入公开工单。

第二次：从容器测试到上游入口的连接

使用服务商交付的入口和端口，在容器网络命名空间内做一次受控 TCP 测试。结果可这样分层：

• 解析失败：查容器 DNS、CoreDNS 或上游域名状态；
• 连接超时：查 Pod 到节点的路由、NAT/EIP、子网 ACL、安全组和主机防火墙；
• 连接被拒绝：确认目标端口、出口路径和服务端是否接受该协议；
• TCP 可达但握手失败：核对 HTTP、HTTPS、SOCKS5 与认证字段。

节点本机成功而容器失败，说明测试路径不同，不能用节点结果替代容器结果。相反，容器能完成代理握手但目标返回 403、429 或验证码，已经越过容器出网问题，应按目标方规则停止重试。

第三次：从实际应用验证环境变量是否生效

不同语言运行时和应用对 HTTP_PROXY、HTTPS_PROXY、NO_PROXY 的读取方式不同；有的只在启动时读取，有的内置独立连接池。让应用访问一个自有健康接口，并在代理程序或回显服务端用临时请求编号核对来源。浏览器或调试容器成功，不证明业务容器真的采用了相同代理设置。

容器出网故障的四个高频边界

节点有 EIP，但 Pod 没有可用出口

检查 Pod 所在子网的默认路由和 NAT 设计。若集群要求通过 NAT 网关出网，确认 NAT 绑定的子网、路由表和配额；若由节点 EIP 做 SNAT，确认网络插件和节点安全策略允许该流量。不要仅给容器添加一个公网地址就绕过既有网络架构。

子网 ACL 或安全组只放行了入方向

容器接收服务端口与主动连接上游是两个方向。确认出方向目标、端口和回程临时端口是否被允许，并同时检查节点主机防火墙。临时放行用于定位后应及时回收，不要用“全端口、全地址”作为长期配置。

CoreDNS 正常，但应用仍提示代理无网络

先在容器内确认应用实际解析的是代理入口，而不是 NO_PROXY 绕过列表中的域名。再查看连接池是否继承旧配置、是否在启动时缓存了失效地址。若只有一个应用失败，优先查它的网络库和证书策略，不要批量更换出口。

代理握手成功，目标服务仍拒绝

如果上游日志能够对应到请求，容器已经完成出网。此时 401、403、429、地区限制或验证码属于账号、请求行为或目标服务策略，应核对授权与频率，不能通过轮换 IP 继续重放。

一个可回滚的排障顺序

1. 在测试容器记录 DNS、路由和代理变量的脱敏快照；
2. 只用一个上游入口完成解析和 TCP 对照；
3. 查 Pod 到节点、节点到 NAT/EIP、NAT 到公网的路由与 ACL；
4. 完成代理握手后，再用实际应用做一条低频请求；
5. 对照容器、节点和上游三处时间线；
6. 删除临时规则，保存最终网络策略和镜像配置版本。

容器代理IP无法访问互联网时，先证明容器是否具备 DNS、路由和公网出口，再检查协议与认证。把“节点能上网”“容器能握手”“应用走了代理”分别验收，才能准确知道该查 CoreDNS、NAT/安全组，还是代理资源本身。