云服务器换了公网 IP，改完域名解析后首页已经能打开，数据库连接、支付通知或邮件发送却仍然报错。这类问题常见的原因，是站点只更新了入口地址，遗漏了源站配置或依赖旧地址的访问限制。
更换 IP 前，先列清三个地址：用户访问服务的入口 IP、CDN 访问源站的 IP，以及服务器向第三方发起请求时的出口 IP。它们可能相同，也可能分别属于负载均衡、云服务器和 NAT 网关。只有确认实际链路，才能知道哪些配置需要改。
本文适用于自己管理的云服务器或 VPS。示例没有在你的生产环境运行，不包含实际 IP、账户或密钥。涉及解绑地址、修改白名单和业务切换时，应使用管理控制台保留的应急入口，并安排维护窗口。
先确认：变的是入口，还是出口
查看云控制台中的公网地址、网卡绑定、弹性公网 IP、负载均衡和 NAT 网关配置。不要只执行 ip addr 就下结论：一些云平台通过地址映射提供公网访问，操作系统里显示的是私网地址。
如果用户一直通过负载均衡访问网站，换后端机器未必需要改域名。若服务器通过 NAT 网关访问外部 API，第三方看到的可能是网关绑定的公网地址，而不是实例的公网地址。AWS 的公共 NAT 网关文档说明了这种出口地址转换；其他平台应核对各自的网络设计。[1][2]
弹性公网 IP 通常用于保留或迁移稳定的公网入口，但是否能跨地域、跨网络或跨账户移动取决于平台限制。即使产品支持重新绑定，也应提前核对权限、费用和操作条件，不能假定所有 VPS 都提供同样的能力。[1]
记录旧地址、新地址、绑定对象、计划切换时间和回滚条件。旧 IP 一旦释放，可能无法重新取回；要回滚，必须事先确认旧地址和旧服务仍然受你控制。
DNS：逐个检查 A、AAAA 与子域名
梳理主域名、www、API、下载站及业务子域名。直接指向旧 IPv4 的 A 记录需要更新；启用了 IPv6 时，还要确认 AAAA 是否仍指向可用的 IPv6 服务。只改 A 记录、保留失效的 AAAA，可能让部分双栈客户端继续访问错误节点。
使用 CNAME 的域名，应沿着目标检查，不能见到 CNAME 就认为不受影响。DNS 查询可以在安装了 dig 的终端执行：
# example.com 仅为示例，请替换成自己管理的域名
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME
必要时分别检查权威 DNS 和实际使用的递归解析器。DNS 有缓存，修改后不会让所有客户端立即切换；变更前可在允许的范围内降低 TTL，并等待旧 TTL 对应的缓存窗口。切换当天才调低 TTL，不能缩短已经缓存的旧记录寿命。
开启 CDN 代理后，解析结果可能是边缘节点地址。Cloudflare 的代理记录文档明确区分了代理记录与仅 DNS 记录的返回行为。此时应检查控制台里的源站目标和实际回源结果，不要要求 dig 必须显示新服务器 IP。[3]
CDN 与负载均衡：同步源站目标和健康检查
DNS 对外没有改变，不代表 CDN 仍能找到源站。检查源站池、回源地址、负载均衡目标组和备用节点是否保留旧 IP。多源站部署尤其容易只更新主节点，遗漏某个地区或备用入口。
同时核对：
- 回源使用 HTTP 还是 HTTPS，端口是否正确。
- Host 请求头、SNI 和源站虚拟主机是否匹配。
- 健康检查的路径、状态码和请求头是否仍能通过。
- 新源站的安全组与防火墙是否允许实际回源节点访问。
域名没变时，公网 IP 变更通常不要求重新申请域名证书，但新服务器必须装好对应证书和完整证书链。使用 CDN 严格校验模式时，还要满足该平台对源站证书有效期、信任和主机名的要求；不能靠降低校验强度掩盖部署遗漏。[4]
切换前可以用 curl 指定新地址，同时保留 URL 中的域名：
# 203.0.113.10 为文档示例地址，请替换为真实的新源站地址
curl --resolve example.com:443:203.0.113.10 \
-sS -D - -o /dev/null 'https://example.com/'
--resolve 用于指定主机与端口对应的解析地址，不需要改公共 DNS。使用域名 URL 也能让测试按该域名发起 HTTPS 连接。[5]
不要加 -k 绕过证书校验。若源站证书仅供 CDN 信任，普通客户端可能没有对应信任链；应使用经过核验的 CA 文件或平台提供的健康检查方式。源站只允许 CDN 回源时，也不要为测试临时对所有互联网地址开放服务。
访问白名单：区分谁访问谁
服务器公网 IP 变更后，需要检查远端数据库、Redis、对象存储、合作方 API、备份系统和监控系统的访问限制。修改哪一侧的规则，取决于发起连接的一方。
例如，服务器向第三方 API 发起请求时，对方的 IP 白名单通常检查你的出口地址。服务器接收 CDN 请求时，本机入站规则应允许 CDN 的来源地址。不能把新服务器 IP 填进所有安全组规则，认为这样就完成了迁移。
推荐在旧服务仍受控的切换窗口内，先添加准确的新地址或新身份规则，完成业务验证后再移除旧规则。如果平台支持按安全组身份授权，可评估这种方式是否符合网络范围要求，减少对易变化地址的依赖。
单个 IPv4 白名单通常使用 /32，单个 IPv6 使用 /128；具体字段仍需按产品格式填写。不要为排除故障把管理端口、数据库或缓存端口开放到 0.0.0.0/0。规则放宽后暂时能连通，只能说明访问控制影响了链路，不能当作修复完成。
实际出口地址最好通过受控的外部服务日志、合作方请求日志或已有监控确认。不要把携带认证令牌的业务请求发给随意找到的公网 IP 查询服务。
回调地址：域名不变，也要验证请求能到达
检查支付通知、OAuth 回调、Webhook、消息推送及合作方配置。若它们使用稳定域名，域名和路径都没有变，通常不用把回调 URL 改成 IP；需要更新的是域名背后的入口以及新节点的接收能力。
如果旧回调地址直接写了 IP，或第三方额外维护了源站地址、IP 白名单，就必须按该平台要求更新。不能把 OAuth 回调、支付异步通知和 API 出口白名单混为同一项配置。
登录第三方平台核对当前登记值，用其测试或重试机制发起一次通知，再检查新服务器日志和业务处理结果。页面返回 200，只证明这次 HTTP 请求完成，不证明订单已经正确入库，也不证明异步任务执行成功。
有签名校验的回调要保留原有校验流程。迁移后出现验签错误时，应核对时间、原始请求体、转发头与密钥配置，不要为了让测试通过临时关闭签名验证。
邮件、脚本与监控：搜索仍然依赖旧地址的配置
直接从服务器向外发送邮件的站点，需要检查实际 SMTP 出口 IP、PTR 反向解析、SMTP 主机名和 SPF 授权范围。使用第三方 SMTP 中继时，收件方看到的最终投递地址通常属于中继服务，应按实际邮件头和发送方式判断，不要机械地把新服务器地址加到所有邮件记录里。
PTR 一般由公网地址提供方管理。若新地址用于自建邮件服务，应确认服务商是否允许配置反向解析，以及投递信誉是否需要重新评估。DKIM 密钥和 DMARC 策略也不能因为换 IP 就随意重置。
搜索部署文件、环境变量、备份任务、监控目标和自动化脚本里的旧 IP，特别是数据库连接、上游服务地址与定时同步任务。只在自己管理的明确配置目录中查找，避免扫描整个文件系统或在报告中输出密码和令牌。
SSH 连接新节点时，如果提示主机密钥变化，应通过云控制台等可信渠道核验主机身份，再处理本机记录。不要直接删除告警并继续连接，因为地址变更和主机身份变更需要分别确认。
用业务链路验收，而不是只打开首页
切换后至少检查以下业务，保留时间和结果，日志中不记录密钥、会话 Cookie 或真实客户资料：
- 分别测试主域名和业务子域名，确认 A、AAAA 与代理回源路径符合预期。
- 验证 HTTPS、登录、静态资源、上传及下载，不仅检查首页状态码。
- 确认数据库、缓存和外部 API 能正常连接，核对第三方实际看到的出口地址。
- 触发一次安全的回调测试，检查业务落库及后台任务结果。
- 验证备份、监控告警和邮件发送，观察是否仍有请求到达旧节点。
涉及有状态服务时，旧节点不能与新节点随意同时接受写入，否则会产生数据分叉。必要的双运行应建立在明确的共享数据层或迁移方案上，不能把“同时保留两个入口”当作通用回滚策略。
观察窗口结束、确认没有遗留依赖后，再移除旧白名单、监控目标和不再使用的入口。若旧 IP 将被释放，应清理自己能控制的所有旧指向，避免地址被重新分配后流量落到他人服务。
下次变更前，保留一份依赖清单
清单至少记录域名、源站目标、出口地址、第三方白名单负责人、回调平台及验证方法。常用外部服务优先使用稳定域名；确实必须固定地址的系统，可评估弹性公网 IP、固定 NAT 出口等设计，并核对平台限制与成本。
这份清单的验收标准很具体：新入口能接流量，真实出口获得授权，第三方通知能完成业务处理，旧地址不再留在配置里。首页能打开只是其中一步。
官方参考资料
资料核验日期：2026 年 10 月 9 日。以下平台文档用于解释相关机制，不表示各云厂商的产品限制完全相同。
[1] AWS：Associate Elastic IP addresses with resources in your VPC — https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html
[2] AWS：NAT gateways — https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
[3] Cloudflare：Proxy status — https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/
[4] Cloudflare：Full (strict) — https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/
[5] curl：Name resolving — https://everything.curl.dev/usingcurl/connections/name.html