为何绑定AWS Route53后域名访问旧站、IP访问新部署版本且HTTPS异常？

一、域名访问展示旧版本、弹性IP访问展示新版本的排查与修复 #

核心根因定位 #

• 多维度缓存不匹配：两层Nginx配置的无缓存规则仅作用于Nginx进程本身，浏览器、运营商、云边缘节点会基于域名维度缓存旧的静态资源响应；直接访问弹性IP属于首次直连，无旧缓存命中，因此能正常展示新版本内容。
• 手动配置upstream的逻辑缺陷：手动查询、填写Docker网络网关IP的方式存在天然不稳定性。Docker Compose每次重建项目网络时网关IP会动态变动，一旦填入的IP和实际新网络的网关IP不匹配，宿主机Nginx的请求会被路由到残留的旧容器链路，返回旧版本内容。
• Nginx重载后的连接池残留：执行sudo nginx -s reload仅会加载新配置，但进程内保留的旧upstream长连接不会被立刻切断，会持续复用旧连接请求旧后端服务。

修复步骤 #

• 使用无痕窗口打开域名地址验证是否为本地浏览器缓存导致的旧内容展示，强制刷新（Ctrl+Shift+R）清除本地缓存后复测。
• 弃用手动填写Docker网络网关IP的配置方式：由于docker-compose已将nginx-blue服务的8080端口映射到宿主机网络，upstream直接写server 127.0.0.1:8080即可，完全不需要查询、填写Docker网桥的动态网关IP，从根源避免多套残留Docker网络网桥IP冲突导致的路由错位。
• 每次修改Nginx配置后先执行sudo nginx -t校验配置语法合法性，再重载配置；如果长连接残留问题明显，重启宿主机Nginx服务清空旧连接池。
• 在EC2本地执行curl -H "Host: example.com" http://127.0.0.1校验返回内容：如果返回旧版本内容，说明Nginx路由指向错误；如果返回新版本内容，说明故障出在外部缓存链路。

二、HTTPS协议无法正常访问的排查与修复 #

核心根因定位 #

• SSL流量链路错位：当前配置中443端口的加密流量被直接转发给后端Docker内的Nginx服务，而该服务仅配置了普通HTTP监听，无SSL证书解密能力，会直接导致TLS握手失败。
• 安全组规则缺失：AWS EC2绑定的安全组若仅放通80端口入站流量，未放通443端口的TCP流量，外部HTTPS请求会被安全组直接拦截，无法到达Nginx进程。
• Server块匹配逻辑缺失：当前server块未配置server_name字段，服务器上若存在其他旧Nginx配置块，443端口的请求会被默认匹配到其他server块，不会走到配置了Let's Encrypt证书的当前配置。

修复步骤 #

• 在宿主机Nginx的server块中添加明确的域名匹配规则：

  server_name example.com www.example.com;
  

• 调整监听端口的处理逻辑：在80端口的server块配置301跳转规则，将所有HTTP请求自动跳转至HTTPS地址；由宿主机Nginx统一完成SSL证书的解密流程，再将解密后的普通HTTP流量转发给后端Docker网络内的服务，避免SSL流量透传至无证书的后端容器。
• 检查EC2绑定的安全组入站规则，确认同时放通80、443端口的TCP流量，来源配置为0.0.0.0/0。
• 执行命令检查Let's Encrypt证书的有效期、匹配域名范围，确认证书覆盖当前实际访问的域名、未过期：

  sudo certbot certificates
  

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