亚马逊云返点 为什么 EC2 实例重启后公网 IP 变了？固定 IP 与 DNS 解析陷阱排查

遇到EC2实例重启后公网IP变了，先不要急着改域名或重装系统。多数线上问题不是“IP随机跳了”，而是你看到的并不是一次真正的重启，或者入口本来就没做固定化。对需要白名单、回调地址、远程登录、对外发布的业务来说，这类问题会直接影响上线节奏。

亚马逊云返点 EC2实例重启后公网IP变了，先确认是不是“真重启”

在AWS里，真正的实例重启和停止后再启动，结果完全不是一回事。实际排查时，先看控制台里的实例状态、最近操作记录和事件，不要只看系统里点了“重启”按钮。

• 如果只是操作系统层面的重启，公网IP通常不会变。
• 如果发生过停止再启动，默认公网IPv4一般会重新分配。
• 如果实例被替换、重建、迁移到新实例，IP也会变。
• 如果你用的是自动伸缩、镜像重建、故障切换流程，看到的新IP未必还是同一台机器。

很多人以为自己在“重启”，实际上是先停机、再启动，或者由脚本/平台把实例重建了一次。只要路径不对，后面绑DNS也没用。

固定IP怎么做，别把“实例公网IP”当长期地址

如果你的业务需要稳定入口，应该把“临时公网IP”和“固定对外入口”分开看。最常见的做法，是把固定公网IP绑定到合适的网络接口或入口组件上，而不是直接记住实例当前那一个地址。

亚马逊云返点 如果你只是给一个临时环境做验证，可以接受地址变化；但只要涉及客户、支付、Webhook、邮件回调、API白名单，就不要赌实例公网IP不会变。

一个实用判断：你到底要“固定IP”还是“固定访问入口”

• 远程运维、单机临时访问：固定IP优先级一般没那么高。
• 第三方做IP白名单：需要固定IP，且最好把变更流程也写出来。
• 对外服务：通常更应该固定域名和入口，而不是把业务绑死在某台EC2上。
• 出站访问需要被对方识别：要确认的是出口IP，不是实例本身的私网地址。

如果你的业务一旦换IP就要人工通知客户，那说明当前入口设计已经不适合长期运行了。

DNS解析陷阱：IP已经改了，访问还是不通

很多现场排查会卡在这一层：控制台里IP已经更新，域名也改了，但外部还是访问老地址。通常不是云服务没生效，而是DNS缓存、TTL、代理层或本地解析没刷新。

• 本机缓存没清：浏览器、系统、DNS客户端都可能还记着旧记录。
• TTL太长：旧记录在递归解析器里还没过期。
• 改的是A记录，但前面还有CNAME、CDN或反向代理。
• 业务其实走的是负载均衡地址，不是你以为的EC2公网IP。

排查时别只在自己电脑上看解析结果，最好换不同网络、不同地区、不同终端做一次验证。常见做法是先查域名最终解析到哪里，再确认流量是否真的到了那台实例上。

建议的排查顺序

1. 确认实例当前公网IP。
2. 确认域名最终解析结果。
3. 确认安全组、系统防火墙和应用端口是否放行。
4. 亚马逊云返点 确认访问链路中是否还有CDN、负载均衡、反向代理。
5. 确认第三方白名单是否同步更新。

账号、实名认证、企业认证、支付方式，为什么会影响这类问题

很多用户只盯着技术层面的IP变化，却忽略了账号侧的问题。尤其是新账号、代开账号、企业主体账号，常见卡点往往出现在支付审核、资源配额和风控上。

• 账号购买/开通：如果账号不是自己从一开始就掌握，先确认账单管理员、根邮箱、找回方式都在你手里。只拿到登录权限，后面申请资源会很被动。
• 实名认证/企业认证：国际云站点通常更看重账单资料、持卡人信息、公司主体一致性。公司名、地址、税务信息、联系人信息不一致，容易触发审核。
• 支付方式：信用卡、借记卡、企业付款资料是否可用，决定你能不能顺利创建资源和续费。新卡、虚拟卡、账单地址不一致，常见会被拦。
• 风控审核：新注册账号、短时间批量开资源、频繁切换地区或大额操作，都可能被要求补充验证。
• 资源限制：很多账号默认配额不高，尤其是公网地址、EIP、实例数量、vCPU额度，申请前最好先看配额页。

如果你的EC2实例涉及对外发布，最好在上线前把账号状态、支付状态、配额和联系人信息一次性理顺。否则技术修好了，资源申请又被卡住，业务还是会上不去。

成本控制：固定IP不是越多越好

固定IP能解决变更问题，但也会带来额外成本。很多人一开始为了省事，给每台测试机都保留公网地址，最后发现账单里最不容易注意的就是这些零散资源。

• 测试环境不用长期占着公网地址，临时用完就释放。
• 只给真正对外的入口保留固定IP，不要每台机器都暴露公网。
• 能走内网访问的管理场景，尽量放到堡垒机、VPN或私网里。
• 如果只是切换域名，不要同时保留多套老地址和老入口。

对于需要长期稳定访问的业务，固定入口的成本通常是可以接受的；但如果你只是做临时联调，长期挂着空闲地址，后面很容易变成账单浪费。

常见错误：为什么明明改了，还是不通

• 把“重启”当成“停机再启动”，没先确认实例生命周期。
• 以为改了DNS就等于改了所有访问入口，忽略了缓存和中间层。
• 只改公网IP，没同步更新安全组、系统防火墙、白名单和回调地址。
• 绑定了固定IP，但实际业务走的是另一个网卡、另一个实例或另一个负载均衡。
• 账号还在风控或账单异常状态，却先去排查网络问题，白白绕路。

怎么选：按业务场景做决策

如果你的业务未来要扩到多台机器，单台EC2的公网IP就不应该作为核心设计。入口应该是可替换的，IP只是实现手段，不是业务本身。

FAQ

亚马逊云返点 Q1：EC2真正重启后，公网IP一定会变吗？

不一定。真正的重启通常不会改公网IP；如果你看到IP变了，优先检查是不是发生了停止再启动、实例替换或入口切换。

Q2：绑定了固定IP，为什么域名还是访问旧地址？

常见原因是DNS缓存、TTL未过期、前面还有CNAME/CDN/代理层，或者你改的是入口之一，不是最终流量入口。

Q3：新账号申请固定IP或更多资源总被卡，先看什么？

先看支付方式是否正常、账单资料是否一致、账号是否处于风控、配额是否足够，再去看网络配置。

Q4：做海外业务时，账号资料要注意什么？

公司主体、账单地址、联系人、付款卡信息尽量保持一致；如果是代开账号，务必先拿到完整控制权和恢复权限。

如果你现在正卡在“EC2实例重启后公网IP变了”这一步，正确顺序不是先改十个配置，而是先判断实例生命周期，再确认固定入口、DNS和账号状态。把这三层分开看，问题通常很快就能定位。