更换 API 固定出口 IP 时，如果先切网络、再通知合作方加白，中间一定会出现拒绝窗口。比较稳妥的顺序是先让新出口获得权限，在新旧 IP 并存期间验证和灰度，再切换全部流量，最后撤销旧地址。这个过程通常被称为双白名单切换，但它能否实现，取决于合作方是否支持同时允许两个来源。
变更前先摸清所有依赖
同一个固定出口可能被多个 API、数据库、SaaS 和文件传输服务信任。除了在线应用，还要检查定时任务、批处理、灾备环境、Webhook 接收后的回调、运维脚本和第三方测试接口。只迁移主服务，夜间任务仍从旧 IP 出站，是常见遗漏。
资产表中应记录旧新 IP、NAT 或代理资源、区域、使用系统、合作方联系人、白名单工单、计划时间和回滚条件。新出口必须是可控且稳定的资源，不能拿动态地址做长期替换。
双白名单切换的标准顺序
- 准备新出口。完成路由、NAT、防火墙、DNS、监控和容量配置，暂不承载生产流量。
- 提交白名单申请。向每个依赖方提供新 IP、用途、环境、验证窗口和旧 IP 预计撤销时间。
- 验证最小请求。从新出口调用服务方提供的测试接口或低风险查询，记录请求 ID。
- 灰度流量。选择少量实例、任务或低风险业务切到新出口，观察认证、状态码和延迟。
- 完成切换。分批迁移剩余流量，同时保持旧路径可回滚。
- 观察并撤旧。确认旧出口无业务请求、所有依赖更新后，通知合作方删除旧 IP。
白名单工单显示“完成”不等于新路径可用。必须从真实运行环境发起授权测试，并让对方按请求 ID 确认其看到的来源地址。
怎样做灰度，不必一次切完
若应用有多个实例，可以先让一台或一个小流量组使用新 NAT；若是定时任务，可选择一个可安全重跑的低风险任务；若客户端支持按目标路由，可只迁移一个合作方接口。灰度期间比较新旧出口的成功率、错误码、P95 延迟、TLS 和重试情况。
不要通过伪造源地址或未经许可的接口压测来验证。测试范围、频率和数据应符合双方授权。
观察期要同时统计新旧 IP
| 指标 | 目的 |
|---|---|
| 按出口 IP 的请求量 | 确认流量是否按计划迁移 |
| 成功率与状态码 | 发现白名单、认证或限流差异 |
| 延迟与超时 | 判断新网络路径质量 |
| 任务与实例覆盖 | 找到仍使用旧配置的节点 |
| 合作方请求 ID | 让双方对齐同一次调用证据 |
观察时间应覆盖实际业务周期。只观察十分钟，可能看不到每天一次的结算任务；只观察白天，也可能遗漏夜间批处理。
合作方只允许一个 IP 怎么办
如果对方系统技术上只能保存一条白名单，就无法做到真正的新旧并行。应协调维护窗口，预先完成新出口的内部测试，准备双方在线联系人，并把白名单修改与路由切换安排在同一窗口。旧配置和旧出口保持可快速恢复，出现异常立即按约定回滚。
也可以询问对方是否有测试环境、临时验证接口或短时变更机制，但不能假设一定支持。风险和可能停机时间要提前通知业务负责人。
回滚不是把路由改回去这么简单
回滚前确认合作方仍保留旧 IP，旧 NAT、凭据和路由没有被释放。数据库写入或队列任务如果已经在新路径执行，网络回滚不能造成重复业务。变更单应写清由谁决策、哪些指标触发回滚、回滚后怎样验证。
旧 IP 何时才能删除
满足以下条件后再撤销：主要与低频任务均已迁移；新出口经过约定观察期；日志中旧地址不再出现合法请求；监控、灾备和文档已更新；合作方确认删除工单。撤销后进行一次受控失败验证，确认旧路径确实失效。
不要因为担心遗漏而永久保留旧白名单。旧公网 IP 释放后可能分配给其他主体，继续被信任会形成隐患。双白名单的价值就在于提供有限的迁移窗口，而不是扩大永久授权面。
变更结束后的交付记录
保存新旧出口、各合作方工单、测试请求 ID、灰度时间、监控结果、异常与处理、旧 IP 撤销时间。这样下一次更换固定公网 IP 时，团队可以复用经过验证的依赖清单和步骤，不必再次靠群聊寻找历史。
