EC2实例公网DNS变更后Nginx反向代理仍正常工作的原因排查

这个现象是Nginx DNS缓存特性 + AWS EC2内网解析逻辑共同作用的结果，拆解如下：

1. Nginx默认会缓存DNS解析结果 #

Nginx在启动或者重载配置（nginx -s reload）时，会一次性解析配置文件里写的所有域名（也就是你配置的instance2旧Public DNS），并把解析得到的IP地址缓存到内存里。后续所有转发请求都会直接用这个缓存的IP，不会每次请求都重新查询DNS。所以哪怕instance2重启后Public DNS指向的公网IP变了，只要Nginx没重启/重载，它就还在使用之前缓存的IP。

2. EC2内网IP的稳定性 #

EC2实例停止再启动后，同一个子网内的实例私有IP是会保留的（除非你手动释放或者实例被销毁重建）。而AWS的Public DNS（比如ec2-xx-xx-xx-xx.region.compute.amazonaws.com）会优先给同VPC内的实例返回内网私有IP，而不是公网IP。

也就是说，你配置的旧Public DNS，在instance1上解析出来的其实是instance2的内网IP——这个IP在instance2重启后并没有改变，所以Nginx用缓存的内网IP依然能正常转发请求到instance2，这就是为什么服务没受影响的原因。

要确认当前系统状态正常，可以做这几步：

• 登录instance1，执行dig <旧的Public DNS>或者nslookup <旧的Public DNS>，查看解析结果，应该能看到instance2的内网私有IP（通常是172.x.x.x、10.x.x.x或者192.168.x.x段）。
• 在instance1上执行curl -I http://<旧的Public DNS>，如果返回200等正常状态码，说明内网访问通路没问题。
• 查看Nginx的访问日志（默认路径是/var/log/nginx/access.log），检查转发的请求是否都有成功响应（没有大量5xx错误）。

虽然现在服务正常，但这个状态是有隐患的——如果instance2因为某种原因（比如子网变更、实例销毁重建）导致内网IP改变，Nginx的缓存IP失效后，转发就会突然中断。建议做这些优化：

• 改用内网标识访问：不要用Public DNS，直接用instance2的内网私有IP或者AWS提供的内网DNS（格式是ip-xxx-xxx-xxx-xxx.ec2.internal），这样不管公网IP怎么变，内网访问都不受影响。
• 配置Nginx自动刷新DNS：如果必须用域名，在Nginx配置里添加resolver指令，指定AWS VPC内置DNS服务器（169.254.169.253），并设置缓存有效期，让Nginx定期重新解析域名。示例配置：

  server {
      listen 80;
      server_name subdomain.example.com;
  
      resolver 169.254.169.253 valid=30s;
      set $instance2_addr "subdomain.example.com";
      proxy_pass http://$instance2_addr;
  }
  

  配置后执行nginx -s reload生效，Nginx会每隔30秒重新解析一次域名，避免缓存过期后失效。
• 绑定Elastic IP：给instance2绑定一个Elastic IP，这样哪怕实例重启，公网IP和对应的Public DNS都不会改变，从根源上解决DNS变更的问题。

内容的提问来源于stack exchange，提问作者NeoSennin