Nginx 反代 Docker 容器：容器重建后刷新 502，一行配置根治摘要：本文深入分析了Nginx反向代理Docker容器时，容器重建后出现502 Bad Gateway错误的根本原因——Nginx对静态upstream主机名只在启动时进行一次DNS解析并永久缓存IP。当Docker容器重建获得新IP后，Nginx仍使用旧IP导致连接失败。解决方案是通过添加resolver 127.0.0.11 valid=5s ipv6=off;配置和使用变量形式的proxy_pass，强制Nginx在运行时动态解析容器名，实现容器IP变更后自动恢复，无需手动reload。文章详细介绍了配置方法、原理分析、常见踩坑点以及适用场景。场景：Docker Compose 自动部署的微前端架构，前端子应用以独立容器运行，Nginx 作为统一入口做反向代理。每次子应用镜像更新、容器重建后，页面刷新直接502 Bad Gateway，必须手动nginx -s reload（甚至重启容器）才能恢复。本文记录在内部环境（微前端架构）上排查并根治这个问题的全过程。一、问题现象架构大致如下（qiankun 微前端，主应用 + 多个子应用各跑一个容器）：浏览器 ──443── edge-nginx (nginx:1.23.1)
【总结】Nginx 反代 Docker 容器：容器重建后刷新 502，一行配置根治
Nginx 反代 Docker 容器：容器重建后刷新 502，一行配置根治摘要：本文深入分析了Nginx反向代理Docker容器时，容器重建后出现502 Bad Gateway错误的根本原因——Nginx对静态upstream主机名只在启动时进行一次DNS解析并永久缓存IP。当Docker容器重建获得新IP后，Nginx仍使用旧IP导致连接失败。解决方案是通过添加resolver 127.0.0.11 valid=5s ipv6=off;配置和使用变量形式的proxy_pass，强制Nginx在运行时动态解析容器名，实现容器IP变更后自动恢复，无需手动reload。文章详细介绍了配置方法、原理分析、常见踩坑点以及适用场景。场景：Docker Compose 自动部署的微前端架构，前端子应用以独立容器运行，Nginx 作为统一入口做反向代理。每次子应用镜像更新、容器重建后，页面刷新直接502 Bad Gateway，必须手动nginx -s reload（甚至重启容器）才能恢复。本文记录在内部环境（微前端架构）上排查并根治这个问题的全过程。一、问题现象架构大致如下（qiankun 微前端，主应用 + 多个子应用各跑一个容器）：浏览器 ──443── edge-nginx (nginx:1.23.1)
