IP 白名单对接：到底哪个代理地址必须固定？

对接方要求“把 IP 加入白名单”时，第一步是确认：规则在哪一层执行，它实际检查的是哪个源地址。如果规则部署在对接方的公网入口，通常需要确认到达该入口的连接使用了哪个公网出口。它未必是你的电脑地址，也未必是连接代理时填写的网关地址，更不是随意写进请求头的 IP。与此同时，代理商可能另有一份白名单，用来允许你的任务机器接入代理。这是两道不同的检查。

本文面向正在对接授权合作方 API 或其他获准服务的开发者，提供地址与责任人核对方法，以及可在本机运行的离线规则练习。如果已有直连线路就能提供对方认可的稳定出口，增加代理未必解决新问题，反而可能增加成本和排查环节。

先画出两道关口，再选产品

下面全部是文档示例地址，不是真实服务器，也不是实测的 IPHTML 地址。代理服务的接入与出口可以由不同设施承担，图中不表示它们是一一绑定关系。

任务机器 → 自身公网出口 A → 代理接入 B → 代理出口 C → 合作方入口
           192.0.2.10       203.0.113.40  198.51.100.20

关口 1：若采用源 IP 认证，代理商检查来源 A
关口 2：若在公网入口限制源 IP，合作方检查来源 C

直连方案：任务机器 → 已获批准的公网出口 A → 合作方入口

代理网关域名固定，只能说明你连接了一个接入服务，不能证明它的出口固定。会话连续性测试解决的是“一段工作流程在测试期间是否保持身份”；合作方的 IP 规则却可能持续生效更久。前一个问题可阅读粘性与轮换代理的会话验收方法，后一个问题需要本文的地址核对与变更约定。

让合作方说清规则位置，尤其是 CDN 和网关

请合作方明确受保护的域名、协议与端口、测试或生产环境、规则负责人，以及规则读取的地址字段。如果服务前面还有反向代理或 CDN，源站连接看到的可能是这个中间节点；应用层规则也可能读取由可信中间节点恢复的客户端地址。需要记录这种信任配置，不能把源站日志里任意一个 IP 字段，都当成公网入口实际判定的地址。

客户端自己填写的 Forwarded 或 X-Forwarded-For 不能证明来源身份。RFC 7239 第 8.1 节说明了这类转发地址信息的完整性限制。修改请求头不会改变连接的传输层源地址。下文练习只模拟源地址规则，不模拟可信 CDN 的请求头判定逻辑。

官方文档也说明了为什么必须问清范围。MongoDB Atlas把集群访问列表与管理界面访问列表区分开来；这只是规则范围的例子，并非建议把数据库流量交给 HTTP 代理，协议支持仍需单独核实。AWS 的 NAT 网关说明则指出，公有 NAT 网关经过同一 VPC 的互联网网关时使用关联的弹性 IP；其他路径可能呈现私有地址。因此，“我们有固定 IP”还不足以完成对接，必须同时确认实际路由。

用 11 个离线案例，检查自己有没有认错地址

下载 Python 离线练习，阅读脚本后，用 Python 3.9 或更高版本执行。它只使用标准库，不发起网络请求，不修改任何配置。所有地址和结果都是假设数据，用来检查两道规则的判定逻辑；它不会发现你的真实出口，也没有实现代理或测试任何服务商。

python3 ip-allowlist-egress-check.py

初始条件是代理入口允许 192.0.2.10/32，目标入口允许 198.51.100.20/32。各案例独立修改表中所列条件。/32 表示一个 IPv4 地址，/128 表示一个 IPv6 地址；脚本不会扩大线上白名单。

预期输出为：4 个案例具备试用条件，4 个被目标规则拒绝，1 个被代理入口拒绝，2 个等待证据。另有 3 项反例检查：更改接入地址或不可信请求头，不能证明出口已经获准；撤去备用地址的批准后，备用线路应不通过。“具备试用条件”只代表假设中的地址规则匹配，不代表目标登录、TLS、协议行为或业务结果已经验收。

把规则练习变成有边界的真实验收

1. 列出实际任务。记录任务运行环境、主线路与恢复线路、域名、协议和端口，以及涉及的 IPv4/IPv6 路径。如果终端能用、程序却不通，先按curl 与 Python 的实际路由检查核对客户端配置。笔记本测试不能替代生产定时任务的验收。
2. 确认批准的地址集合。取得合作方负责人认可的单个地址或有限集合、适用范围和生效时间。向线路供应方确认分配方式、保持期限、重连或重启后的行为、维护更换条件及通知流程。“独享”“粘性”这些名称本身不能回答完整问题。
3. 关联一条获准请求。使用无副作用且获得授权的请求，并设置不含敏感信息的请求编号。让相关负责人提供时间、环境、线路、规则检查的源地址、放行结果与业务结果。独立查 IP 接口只能辅助诊断，因为不同目的地址可能走不同路由。记录表中不放令牌或密码。
4. 覆盖真正影响使用的变化。在约定测试窗口内检查正常请求、新建连接、任务进程重启以及每条拟采用的恢复路径；若涉及地址族切换或会话到期，也应纳入范围。变更白名单时，请合作方确认新连接的行为，不能仅凭原有连接仍可使用就下结论。
5. 给出范围明确的结论。只有已测试路径都使用批准的来源，并得到正确业务结果，才接受该测试范围。来源变化无法解释或日志缺失时，暂缓上线。保留已批准的回退线路；尚未覆盖的维护、更换场景应列为剩余风险，并指定负责人，不能据此宣称长期稳定。

记录表可以采用：时间｜任务环境｜线路｜地址族｜检查关口｜判定源地址｜规则版本｜请求编号｜网络结果｜业务结果，保存在自己受控的项目记录中。更完整的工作负载验收可参考代表性代理试用方法；如果问题发生在代理认证关口，可参考407 认证排查。单看一个 HTTP 状态码，不能确定是哪条地址规则导致了失败。

选择满足约定、维护负担最小的线路

已有合格直连就保留直连。前提是其出口及恢复方式符合合作方要求。多个来源不断变化的任务，需要统一且获准的出口，而团队又无法可靠运维这条线路时，再评估托管的固定出口方案。购买前核实协议支持、目标访问许可、地址分配与变更条款、容量和总成本。这些是采购问题，不是本文已经证实的 IPHTML 产品能力。

对方只允许一个地址时，不应直接选用变化的出口池。除非合作方明确支持对应地址集合与变更流程。如果主线路和备用线路使用不同出口，而对方只批准了一个，那么备用方案还没有真正成立。不要通过放开很大的地址范围来掩盖需求冲突。若目标只能经过批准的私有连接访问，应与负责人评估该架构，不能默认公网代理适用。

如果授权任务还确实需要某个地区的住宅网络，可以按这个独立条件查看住宅代理选项。针对白名单需求，则应在试用前向 IPHTML 确认出口与协议条款：说明允许几个源地址、运行环境、协议、所需地区及维护限制，不提供密码。本文尚未验证固定分配、独享性、故障切换行为或服务性能；关键条件没有得到回答时，就应保持采购待定。