nginx在docker中实现动态服务发现需结合自定义bridge网络（支持服务名dns解析）、confd/docker-gen自动配置生成、proxy_next_upstream健康探测三者协同，缺一不可。
在 Docker 容器化环境中，Nginx 的 upstream 无法靠写死 IP 或 localhost 实现服务发现——因为容器网络隔离，且 IP 动态变化。真正的“动态发现”意味着：后端容器增减时，Nginx 不重启就能自动感知并更新可用节点列表。这需要跳出静态配置思维，依赖服务发现机制与配置生成协同工作。
用 docker-gen + confd 自动生成 upstream 配置（推荐）
这是生产环境最成熟、轻量且兼容性强的方式。它不修改 Nginx 源码，也不依赖商业版功能，还能和宝塔面板、Docker Compose 无缝集成。
- 给每个后端服务容器打标签，例如
--label role=backend --label service_name=api - 运行一个
confd容器，挂载共享卷（如/etc/nginx/conf.d/）和 Docker socket（/var/run/docker.sock） - 提供 Go 模板文件，遍历所有带
role=backend标签的容器，生成类似这样的 upstream 块：upstream api_backend {<br> server container-name-1:8080 weight=3;<br> server container-name-2:8080 weight=3;<br>} - confd 检测到容器变化后，自动重写配置并执行
nginx -s reload
用自定义 bridge 网络 + Docker 内置 DNS 解析服务名
这是动态发现的基础设施前提，不是完整方案，但必须做对——否则上面所有动态机制都会失效。
- 创建专用自定义网络：
docker network create --driver bridge --subnet 172.19.0.0/16 app-net - 在
docker-compose.yml中让所有服务加入该网络，并**不暴露宿主机端口** - Nginx 配置中直接写服务名：
server backend-api:3000;——Docker 会通过内置 DNS（127.0.0.11）自动解析为当前活跃容器的 IP - 注意：仅靠此步不能实现“自动增删节点”，它只解决“能连谁”的问题；要实现“连哪些”，仍需配合 confd 或 Lua 脚本
启用健康检查，避免流量打到故障节点
即使 upstream 列表实时更新，若 Nginx 不主动剔除宕机实例，动态就只是表面功夫。
- 每个后端服务必须提供
/healthz或类似健康接口（返回 200 即可） - 在 Nginx 配置中开启失败转移：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 更进一步可配
max_fails=2 fail_timeout=10s，让 Nginx 主动标记不可用节点并临时摘除 - 开源版 Nginx 不支持原生
health_check指令（那是 Plus 版），所以依赖后端健康接口 + proxy_next_upstream 是通用做法
避免常见错误：localhost、桥接网关、host 网络
这些写法看似能通，但违背容器设计原则，也不支持真正动态伸缩。
-
server localhost:3000→ 容器内 localhost 是自己，永远连不通其他容器 -
server 172.17.0.1:3000→ 指向 Docker 默认 bridge 的宿主机网关，仅适用于后端跑在宿主机的开发场景，无法跨容器发现 -
--network=host→ 共享宿主机网络栈，失去隔离性，且服务名解析失效，Docker Compose 中几乎不可用
