如何使用 Nginx 实现容器流量分流？多种方案与实战配置详解

当应用被拆成多个容器实例之后，最先要解决的问题就是流量入口。总不能让用户自己去访问某一个容器的 IP，更不能在某个容器挂掉之后手动改配置。Nginx 作为反向代理界的常青树，配合 Docker 提供的网络能力，可以很优雅地完成流量分流这件事：请求统一打到 Nginx，再由它按照一定策略转发给后端的多个容器实例。这篇文章就来把这件事讲透，从原理到配置，一步步搭建出可用的方案。

一、容器流量分流的基本原理

首先要理解 Nginx 和容器在网络层面是如何协作的。默认情况下，Docker 会为每个容器分配一个内部 IP，比如 172.17.0.2、172.17.0.3。如果 Nginx 本身也跑在容器里，并且和后端应用容器在同一个自定义网络中，那么 Nginx 可以直接通过容器名访问它们——这是 Docker 内置 DNS 提供的能力。这一点非常关键，因为容器的 IP 在重启后会变化，直接写 IP 的配置很快就会失效。

具体做法是创建一个自定义桥接网络，让 Nginx 容器和应用容器都加入这个网络：

docker network create app-net

# 启动三个后端应用容器
docker run -d --name web1 --network app-net myapp:latest
docker run -d --name web2 --network app-net myapp:latest
docker run -d --name web3 --network app-net myapp:latest

# 启动 Nginx 容器
docker run -d --name nginx --network app-net -p 80:80 nginx:stable

这样在 Nginx 的配置里，web1、web2、web3 就是可以直接解析的域名。需要特别注意，不要使用 Docker 默认的 bridge 网络，因为默认网络不提供容器名 DNS 解析功能，只有自定义网络才有。

另一个思路是利用 Docker Compose 的缩容扩容能力。Compose 中同名的服务通过 scale 参数（或新版 deploy 配置）启动多个实例时，服务名对应的域名会在 DNS 层面自动轮询解析到所有实例 IP，Nginx 只需把服务名写进 upstream，再配合 resolver 指令，就能一定程度上实现动态发现。这个方案的细节在后面第三节展开。

二、upstream 分流策略详解

Nginx 的分流核心在 upstream 块里，不同算法适合不同场景。先看一个完整的配置示例：

upstream backend {
    server web1:8080 weight=3 max_fails=2 fail_timeout=10s;
    server web2:8080 weight=1;
    server web3:8080 backup;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 长连接，减少与后端容器频繁建连的开销
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

默认策略是轮询（round-robin），请求依次分给每个后端。weight 参数可以调整权重，上面配置中 web1 会拿到大约 75% 的流量，这在后端机器配置不均时很有用。max_fails 和 fail_timeout 组合实现了被动健康检查：10 秒内失败 2 次，Nginx 就会把该节点摘除 10 秒。注意这是被动检查，只有真实流量触发了失败才会剔除节点，如果希望主动探测，需要用商业版的 health_check 指令，或者改用开源的 Nginx Plus 替代方案如 OpenResty 加第三方模块。

backup 标记的节点平时不接流量，只有当其他所有节点都不可用时才启用，适合做兜底。除了轮询，还有两种常用算法值得了解：

• ip_hash：根据客户端 IP 做哈希，同一客户端总是落到同一后端，解决会话粘性问题。但在容器环境里要慎重，因为后端数量变化会导致哈希重分布，大量用户的会话会失效。
• least_conn：把请求分给当前连接数最少的后端，适合请求处理时长差异大的场景，比如有些接口要跑几秒钟的长任务，轮询会造成某些容器积压。

顺带一提，如果你用的是无状态服务加 JWT 鉴权的架构，就不要用 ip_hash 了，直接轮询或 least_conn 即可，会话粘性反而会限制横向扩容的效果。

三、动态发现：让 Nginx 自动感知容器变化

静态 upstream 最大的痛点是容器扩缩容后配置不会自动更新。解决思路有两条：一是让 Nginx 每次解析时都重新查 DNS，二是用工具自动重写配置并 reload。

第一种方案借助 resolver 和变量形式的 proxy_pass。Nginx 有个特性：只有把 upstream 地址写成变量，DNS 解析才会遵循 resolver 的有效期设置，否则只在启动时解析一次。示例配置如下：

resolver 127.0.0.11 valid=10s ipv6=off;
resolver_timeout 5s;

server {
    listen 80;
    location / {
        set $backend_upstream http://myapp:8080;
        proxy_pass $backend_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

127.0.0.11 是 Docker 内嵌 DNS 服务器的固定地址，valid=10s 表示 DNS 结果缓存 10 秒。配合 Compose 的多实例服务，myapp 这个域名会解析到多个容器 IP，Nginx 在解析结果中做轮询，扩容后的新容器 IP 会在最多 10 秒内被感知。这个方案轻量好用，缺点是拿不到细粒度的权重控制，DNS 轮询是 Nginx 自身的行为，健康检查也不可控。

第二种方案是使用配置生成工具，比如 Docker 官方 Nginx 镜像自带的 docker-gen 思路，或者社区里流行的 nginxproxy/nginx-proxy 镜像。它监听 Docker 事件（容器启动、停止），自动生成 upstream 配置并触发 reload。这种方式控制粒度最细，支持 per-container 的自定义参数，代价是多了一个组件要维护。

如果流量规模到了跨主机阶段，更合理的做法是把服务发现交给专门的系统：单机用 Docker DNS 就够，跨主机可以考虑 Traefik（原生支持 Docker 标签自动发现），或者上 Kubernetes 之后直接用 Ingress + Endpoints 机制，Nginx Ingress Controller 本质上就是自动化的 Nginx 配置管理器。

四、实战中的注意事项与排错

配置跑起来只是第一步，线上环境还有几个坑要提前踩明白。

第一是后端日志里的客户端 IP 丢失问题。容器内的应用拿到的 Remote IP 是 Nginx 容器的 IP。要在 Nginx 侧传递 X-Real-IP 和 X-Forwarded-For 头（前面配置已有），同时应用侧要信任并解析这些头，否则风控、审计都会拿到错误数据。

第二是健康检查的误判。有些应用启动慢，容器还在但进程没就绪，被动健康检查会让流量先失败一波。建议给后端实现一个轻量的健康检查接口，配合容器的 HEALTHCHECK 指令，让 Docker 层面先把未就绪的容器标记为 unhealthy，编排工具自动重启它，Nginx 层面靠 max_fails 兜底。

第三是连接风暴。Nginx 到后端默认不保持长连接，高 QPS 下每个请求都要新建 TCP 连接，容器内进程的文件描述符很快耗尽。务必加上 proxy_http_version 1.1 和 proxy_set_header Connection "" 这两行，必要时还要调大后端容器内核的 somaxconn。

排错时常用的命令整理如下：

# 进入 Nginx 容器检查配置语法
docker exec nginx nginx -t

# 平滑重载配置，不断开现有连接
docker exec nginx nginx -s reload

# 在 Nginx 容器内验证后端容器名能否解析
docker exec nginx nslookup web1

# 查看真实分流情况，给响应头打上后端标记录
# 需要在 location 中配置 add_header X-Upstream $upstream_addr;

其中 $upstream_addr 这个变量非常实用，把它塞进响应头或日志，压测时一眼就能看出流量是不是按预期比例分发到了各个容器。日志层面可以在 log_format 里加入 $upstream_response_time，用来定位哪个容器响应偏慢，为权重调整提供数据依据。

总结一下，容器流量分流的关键在于三点：用自定义网络加容器名摆脱 IP 依赖，用 upstream 算法和健康检查保证分发合理与故障自愈，用 resolver 或配置生成工具应对实例动态变化。把这三层做扎实，Nginx 完全可以胜任中小规模容器化应用的流量入口角色。

Nginx容器分流Docker流量分发反向代理负载均衡修改时间：2026-09-04 12:06:52