Nginx反向代理感知下游容器存活变动需依赖外部机制：通过自定义Docker网络+DNS动态解析（resolver 127.0.0.11 valid=5s）、nginx-proxy自动配置热重载，及被动健康检查实现准实时服务发现与故障转移。
要让 nginx 反向代理层“感知”下游容器的存活变动，关键不在于让 nginx 主动探测，而在于构建一套能自动响应服务拓扑变化的机制——nginx 本身不具备原生服务发现能力，必须借助外部协同或配置动态化手段实现“准实时”感知。
使用自定义 Docker 网络 + DNS 名称解析
Docker bridge 网络默认支持容器间通过服务名互相访问，且内置 DNS 会随容器启停自动更新 A 记录。只要确保 Nginx 和后端服务处于同一自定义网络，就能利用这个特性实现基础级感知：
- 创建专用网络：
docker network create app-net - 启动后端服务时指定网络和名称：
docker run -d --name api-service --network app-net my-api:latest - Nginx 配置中直接用服务名作为 upstream 地址：
proxy_pass http://api-service:8080; - 当容器重启或销毁，Docker DNS 会在几秒内刷新记录，Nginx 下次请求将自动尝试新 IP（配合
resolver指令可强制定期重查）
启用 resolver 动态解析并控制缓存时效
默认情况下，Nginx 在启动时解析一次 upstream 域名并缓存结果。要让它“感知变动”，需显式启用运行时 DNS 解析：
- 在
http或server块中添加：resolver 127.0.0.11 valid=5s;（Docker 内置 DNS 地址为 127.0.0.11） - upstream 中改用域名而非固定 IP：
server api-service:8080 resolve;（注意resolve参数） - 搭配
valid=5s表示每 5 秒重新查询 DNS，从而及时发现容器 IP 变更或下线 - 避免使用
upstream块硬编码 IP；否则即使 DNS 更新，Nginx 仍会持续向旧地址发包直到 reload
接入自动化配置生成工具（如 nginx-proxy）
对生产环境而言，纯靠 DNS 刷新存在延迟与失败风险。推荐引入专为容器设计的反向代理方案：
-
nginx-proxy容器监听 Docker socket，一旦检测到容器 start/stop 事件，立即生成并热重载 Nginx 配置 - 后端服务只需声明环境变量
VIRTUAL_HOST=api.example.com，无需手动改 Nginx 文件 - 整个过程毫秒级生效，真正实现“容器一上线，路由即就绪”
- 支持多租户、HTTPS 自动签发（配合 letsencrypt-companion），适合中大型部署
补充：被动健康检查 + 快速故障转移
即便配置了动态解析，Nginx 仍可能把请求发给刚启动但尚未 ready 的容器。这时需叠加被动健康检查提升鲁棒性：
- 在 upstream 中设置容错参数：
server api-service:8080 max_fails=1 fail_timeout=10s; - 配合
proxy_next_upstream error timeout http_502 http_503;，遇到错误自动换节点 - 注意：这不是主动探活，而是靠真实请求失败触发切换，适合配合 readiness probe 使用
- 若需主动心跳检测，需编译第三方模块
nginx_upstream_check_module，但会增加维护复杂度
