第三方已经把云服务器的公网 IP 加入白名单，应用调用 API 仍然返回 403，问题很可能在于“入站公网 IP”和“真实出站公网 IP”不是同一个地址。私网实例、容器和无服务器任务经常通过 NAT 网关、企业代理或统一防火墙出站；多可用区部署还可能使用不止一个出口。必须从实际运行应用的环境确认路径，不能只看控制台上实例绑定的地址。
先画清请求实际经过哪里
一条常见链路可能是：容器 Pod → 集群节点或 CNI → 私网路由 → NAT 网关 → 企业防火墙 → 第三方 API。也可能在应用环境变量里配置 HTTP/SOCKS 代理，流量绕过默认 NAT。入站负载均衡器的公网地址只负责接收请求，通常与服务器对外调用使用的源地址无关。
| 运行方式 | 常见出站来源 | 需要核对 |
|---|---|---|
| 带公网 IP 的虚拟机 | 实例地址或云平台转换后的地址 | 路由、SNAT 和代理设置 |
| 私网虚拟机 | NAT 网关、统一防火墙 | 子网路由与可用区 |
| Kubernetes 容器 | 节点、NAT 网关或 Egress 网关 | CNI、网络策略和服务网格 |
| 函数/无服务器任务 | 平台共享出口或绑定 VPC 的 NAT | 是否提供固定出口能力 |
| 企业办公应用 | 代理、防火墙或 SD-WAN 出口 | 主备线路和策略路由 |
从实际进程环境做一次最小查询
应进入真正运行该服务的实例、容器或任务环境，使用企业批准的诊断接口查询公网出口。极跃圈收录的IP 查询入口可用于辅助观察，但生产判断还应结合云 NAT 流日志、防火墙会话和路由配置。
如果主机查询与应用结果不同，检查应用是否设置了 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY，以及客户端库是否有独立代理配置。服务网格 sidecar、透明代理和安全客户端也可能改变出站路径。
容器里查到的结果为什么可能不稳定
Pod 重建后可能调度到不同节点，不同子网或可用区又可能绑定不同 NAT 网关。一次查询只能证明该任务当时走了某个出口，不能证明整个集群只有一个 IP。应在所有实际运行区域各取样本，并在扩缩容、故障切换后复测。
若第三方只允许少量固定 IP，可为工作负载设计专用 Egress/NAT 网关，并通过路由和网络策略确保目标 API 走该出口。不能只在文档中写“固定出口”，却让部分任务仍使用平台默认共享地址。
403 不一定就是白名单
真实出站地址正确后，仍要查看第三方返回的错误码、响应体和请求 ID。403 还可能来自账号权限、API 密钥、签名时间、Host、接口范围、地区策略或 WAF。若请求根本没有到达第三方应用，可能表现为超时、TLS 失败或代理认证错误。
- 确认 DNS 解析到预期环境，HTTPS 证书和 SNI 正常；
- 核对 API 密钥对应的环境、接口和有效期；
- 检查系统时间，避免签名因时钟偏差失效；
- 让第三方按请求 ID 查询其看到的来源 IP 和拒绝规则；
- 比较成功环境与失败环境的请求头和网络路径，不泄露秘密。
主备出口如何加入白名单
如果业务在故障时会切换到第二个 NAT 网关，应把主备地址、用途和切换条件提前告知第三方。能否同时加入，取决于双方安全策略。预先允许备用 IP 可以缩短恢复时间，但地址必须稳定、有人负责并定期复核；停用后及时撤销。
多区域应用还应区分生产、测试和灾备，避免把所有环境出口都加入同一个生产接口白名单。白名单与应用账号仍要共同实施最小权限。
把出口 IP 纳入资产和变更流程
资产表至少记录公网 IP、NAT 或代理资源编号、云账号、区域、关联子网、使用应用、第三方白名单、负责人、到期与最近验证日期。释放 NAT、切换线路或迁移集群前，先反查所有外部依赖。
监控可以定期从每个区域发起低频授权请求，记录实际出口变化；发现不在批准列表的地址立即告警。不要用频繁调用第三方生产 API 的方式探测，可以优先使用自有诊断端点或服务方提供的健康接口。
一条可复查的排查结论
不要只写“白名单有问题”，而应记录：“应用运行在私网容器，路由经某 NAT 网关出站；诊断接口与 NAT 流日志均显示地址 A，第三方只允许实例入站地址 B，因此请求被拒绝。已提交地址 A，并验证请求 ID 对应成功。”条件、证据和处理结果都清楚，后续扩容时才不会重复踩坑。
