公司动态 · 发布时间：
高防IP更换期间第三方回调地址与客户端白名单更新，关键不是只替换一个地址，而是确认每条连接的发起方、接收方和允许访问的地址范围。若回调平台仍访问旧地址，或客户端的出口地址未加入对端白名单，都可能出现超时、拒绝连接或重复通知。以下五项操作可按顺序执行，不依赖特定行业。
1. 先画清连接方向与配置位置
建立一张变更清单，逐项记录系统名称、连接方向、配置入口、端口、负责人和验证方式。将“第三方向我方发送回调”与“我方客户端调用第三方接口”分开：前者涉及回调目标地址及我方接入规则；后者要确认对方限制的是我方客户端的出站源地址，还是我方限制了对端地址。
还要区分回调地址是域名还是直接填写地址。若配置使用域名，通常应核对解析结果和缓存影响；若填写的是具体地址，则需在第三方平台直接修改。不要把目标地址和出站源地址混为一谈，也不要未经确认就放宽整个防火墙白名单。
2. 切换前准备新地址与回退条件
在正式变更前，确认新入口已能接收所需协议与端口，应用路由、证书和访问控制配置均已就绪。对外仍使用原有域名时，检查证书对应的主机名及服务路径；证书通常校验域名而非单独校验入口地址，但实际行为取决于客户端的校验方式。
记录旧配置、计划切换时间、负责人与回退步骤。能并行保留新旧入口时，先安排短暂重叠期；无法并行时，至少准备好恢复原配置的权限和操作步骤。回退标准应具体，例如关键回调持续失败、客户端连接被拒绝，或业务确认数据未正常入账。
3. 更新第三方回调地址并核对签名设置
登录第三方服务的管理控制台，找到 webhook 或回调配置，核对目标域名、路径、请求方法及鉴权参数。只有回调配置填入了旧的直连地址时，才需要把它改成新地址；若填写的是保持不变的域名，则重点检查该域名是否已指向新入口以及第三方是否缓存了解析结果。
保存后记录变更时间，并使用平台提供的测试投递功能（如 GitHub 仓库设置中的 Webhooks 页面可查看投递记录）检查响应状态和服务端日志。若系统启用签名校验，更新地址时不要顺手更换密钥；确需轮换密钥，应单独安排并同步两端配置。
4. 双向核对白名单，而非只改一侧
向第三方确认其白名单限制的对象究竟是回调接收地址，还是调用方的出站源地址。前者应允许新入口按需接收连接；后者则需把实际发起请求的客户端出口地址提交给对方。如果客户端经由固定出口网关访问，白名单应以该出口为准，而不是填写用户电脑或应用服务器的内网地址。
同时检查我方防火墙白名单是否限制第三方回调来源。应从可信配置或服务商提供的资料核实来源范围，按最小必要原则添加；不要为了省事开放任意来源。变更后请业务、网络和第三方联系人分别确认配置生效，并保留原规则，直到验证完成。
5. 分批验证、观察重试并明确回滚
- 先做连通性检查：从实际客户端发起一次请求，确认目标端口可达；再由第三方触发一条测试回调，核对服务端是否收到。
- 核对业务结果：检查响应码、请求时间、签名校验和业务记录，不能仅凭网络连通就判定成功。
- 观察回调重试：部分平台会在失败后重试，具体间隔和次数依平台规则而异。为避免重复处理，接收端应依据事件编号等稳定标识实现幂等处理。
- 保留切换记录：记录成功与失败样本、白名单变更、回调配置及回退决定。确认观察期内无异常后，再清理旧地址和过期规则。
完成高防IP更换期间第三方回调地址与客户端白名单更新后，复核清单中的每一条连接是否都有验证结果和责任人。新旧入口的切换时间、回调投递记录和白名单变更记录应能相互对应，便于定位延迟出现的问题。
常见问题
回调使用域名时，还要改第三方平台里的地址吗？
如果域名和路径保持不变，通常不必改回调 URL，但应确认解析已指向新入口，并检查缓存或平台侧解析机制。
白名单应填写高防入口还是源站地址？
取决于白名单控制的是哪一段连接。回调接入通常关注对外入口；客户端访问第三方时，通常要确认实际出站源地址。先向规则维护方核实方向。
切换后收到重复回调怎么办？
先检查第三方的重试记录与本地处理日志，再用事件标识去重。不要仅因重复通知就关闭重试，以免遗漏此前未成功处理的事件。
何时可以删除旧白名单规则？
在新入口验证通过、观察期内关键调用正常，并确认没有仍依赖旧地址的客户端后再删除。观察期长短应结合业务频率和第三方重试策略确定。
