第三方回调白名单更新

网站搬家后支付突然失败，多数时候不是代码问题，而是第三方回调白名单没更新。这类故障切换当晚就会冒出来，提前梳理一遍能全部避免。 哪些白名单要动 三类最常见。支付类：支付网关的异步通知地址如果换了域名，配置要改；平台限制服务器来源 IP 的，要把新机 IP 加进白名单。登录类：第三方登录的回调域名，在对应开放平台的后台修改，漏改的表现是登录跳转后报 redirect_uri 错误。消息类：短信、验证码、告警推送这些服务，不少按源 IP 限制调用方，新 IP 不在名单里，调用直接失败。顺手核对一遍密钥：有的平台按应用密钥绑定环境，迁移后密钥文件路径变了，配置也要同步改。 排查三板斧 第一板斧，看新机的访问日志，搜第三方服务商的域名或已知回调路径，没有请求进来，说明回调根本没打到新机。第二板斧，登第三方后台核对配置，逐项检查域名和 IP。第三板斧，用 curl 模拟回调请求打一遍接口，确认新机功能本身正常，把故障范围锁定在白名单上，找平台改配置才有底气。对日志时注意时区：新机系统时区跟老机不一致，时间对不上会误判成回调没来，date 命令先确认两边一致。 一张表管到底 迁移前列一张三列表：服务名称、后台入口、要改的项目。切换当天按表逐项过，改完一项勾一项，这张表下次迁移还能复用。把它放进运维文档里打版本，下次迁移直接照抄。 补充一个反向情况：不只是你调用别人，还有别人调用你。如果有合作方限制了只接受来自老机 IP 的请求，要提前通知对方更新，这类外部联络要留出两三天的提前量。 白名单更新没有任何技术难度，纯粹是细心活。故障的代价和梳理的成本完全不成比例，值得花一个下午老老实实对表。