容器代理IP NetworkPolicy阻断外部域名：先分清 DNS、出口和策略层

容器里的代理进程能启动，却访问不了外部域名，或者只能访问少数地址，常见原因不是代理账号失效，而是 NetworkPolicy、DNS 出口和 egress 路由在不同层同时生效。先把域名解析、TCP 建连和代理转发拆开，才能知道是哪一层在阻断。

先确认请求经过哪几个网络层

容器访问外部接口通常要经过：应用进程 → 容器网络命名空间 → DNS 解析 → NetworkPolicy egress → 节点路由或网关 → 代理入口 → 目标域名。代理入口可达，不代表目标域名的解析和后续连接都被允许。

先画出实际链路，记录代理地址、端口、命名空间、出口网关和目标域名。不要一开始就改策略，否则很难判断究竟是容器不能解析，还是解析后连接被拒绝。

把 DNS 测试和代理测试分开

在容器内先测试 DNS：

getent hosts api.example.com

如果镜像没有 getent，可使用环境中已有的 DNS 工具。解析失败时，先检查 CoreDNS、/etc/resolv.conf 和 NetworkPolicy 是否允许访问集群 DNS 服务；这一步还没有进入代理链路。

解析成功后，再测试到代理入口的 TCP 连接，并用最小请求验证代理握手。若代理使用域名作为入口，也要区分“解析代理入口”和“解析目标域名”分别由哪一方完成。

NetworkPolicy 要允许正确的 egress 目标

NetworkPolicy 通常按命名空间、标签、端口和 IP 段控制出口。常见误区是只允许代理端口，却忘记允许 DNS；或者只放行某个固定 IP，但目标域名背后的地址会变化。

检查策略时核对四项：

不要为了排障直接放开整个公网。可以先限定测试命名空间和代理服务，再逐步收窄到实际端口和目标范围。

域名策略和 IP 策略不是一回事

许多 NetworkPolicy 实现主要按 IP 和端口匹配，不能直接理解“允许某个域名”。如果策略先按域名解析结果生成 IP 白名单，CDN 或多区域解析变化后，旧地址可能失效。更稳妥的做法是让容器只连接受控代理入口，由代理侧按授权目标处理域名访问。

同时要留意 IPv6：容器可能优先解析出 AAAA 记录，而策略只放行 IPv4，表现为偶发超时。测试时分别记录 A、AAAA 和实际连接地址，不要只看域名能否解析。

最后再看代理参数和回包路径

如果 DNS、策略和代理入口都正常，才检查代理协议、认证、超时和目标接口权限。NetworkPolicy 放行出站不等于目标接口会接受请求；401、403 或 429 说明请求已经到达更高一层，应按接口规则处理。

调整策略后一次只改一个条件，并保留命名空间、策略版本、代理入口、解析结果和响应码。容器代理只应服务于已获授权的系统，确认链路稳定后再推广到其他工作负载，避免把临时排障权限长期留在生产环境。