公网IP变化后的排查顺序：域名、回调与白名单逐项核对

📡 公网IP变化后的排查顺序：覆盖域名、回调与白名单

公网IP变化影响的范围往往超过网站入口。A记录可能仍指向旧地址，第三方回调可能登记着旧目标，出站访问还可能经过独立NAT地址。先区分入站和出站，再用实际连接验证每条依赖，能快速解释“网页可用但集成失败”这一类现象。

🌐 入口路径：域名、负载均衡与源站

列出根域名、子域名、API和回调域名，查询其A记录或别名链。使用dig example.test A比较权威答案和递归答案，注意TTL以及是否存在多地址或线路差异。随后对新入口以正确Host发起请求，检查状态码、证书、虚拟主机和后端健康状态。DNS指向新IP不代表服务已经在该IP上正确绑定。

如果域名前有负载均衡或反向代理，域名通常应指向该入口，而非直接指向某台实例。核对监听器、后端池和健康检查；确认旧IP是否还承担其他域名、监控或管理用途。🔎

🔁 出站白名单与入站回调分开查

第三方向你的服务发送Webhook，是入站连接：对端需要知道新的目标地址，且你的边界策略允许其来源访问对应端口。你的应用调用第三方，则是出站连接：对方白名单通常匹配它观察到的源地址。该地址可能是NAT网关、代理或出口负载均衡的公网IP，不一定等于实例网卡地址。不要用入口地址推断出口地址。

分别记录连接方向、源地址、目的地址、协议端口、DNS名称和负责人。查看边界日志或对端连接记录，确认实际使用的地址；如需验证，可由对端提供其观测结果，避免在生产环境随意向公网回显服务暴露信息。📋

🧾 按依赖清单推进变更

1. 盘点所有公开域名、回调目标、合作方白名单和监控探针。
2. 确认新入口与新出口地址的归属，分别标记入站和出站用途。
3. 先验证新服务监听、证书和应用路由，再更新DNS与可控配置。
4. 通知合作方更新目标或来源白名单，并为DNS缓存及协作留出过渡期。
5. 记录每项变更时间、旧值、新值、负责人和验证结果。

回调系统可能还缓存DNS结果或重复投递失败事件；测试时查看对端投递状态与本地应用日志，区分网络拒绝、TLS错误、HTTP错误和业务校验失败。⚙️

✅ 验收：证明两个方向都恢复

从外部触发一次受控回调，确认对端请求抵达新入口、应用返回预期状态并记录事件；再由应用发起对第三方的请求，确认对端看到的源IP符合白名单。对域名从多个解析环境复查新答案，并观察回调成功率、出站连接错误和边界拒绝日志。入站与出站分别通过，且旧地址依赖已明确处置，才算迁移闭环。✅