Docker本身不提供Nginx集群功能，仅运行单个容器；所谓集群需多个Nginx实例+外部负载均衡（如SLB、HAProxy或另一层Nginx）实现，且Django须无状态、静态文件剥离、DB/缓存独立。
直接说结论：Docker 本身不提供“Nginx 集群”功能，它只负责运行单个 Nginx 容器；所谓集群，必须靠多个 Nginx 实例 + 外部负载均衡（如云厂商 SLB、HAProxy 或另一层 Nginx）实现。Django 应用倒是可以横向扩缩，但前提是它本身无状态、静态文件已剥离、数据库和缓存独立。
为什么不能只靠 docker-compose up 就算集群
很多人误以为写几个 nginx service 就是集群——其实只是多个相同配置的容器并行启动，彼此不感知、不协同、不共享会话或健康状态。真实集群需要：
- 服务发现机制（比如通过
docker network+ DNS 名解析到后端 Django 容器） - 健康检查（Nginx 自身不主动探活，需配合
health_check指令或外部工具） - 上游动态更新（Docker Compose 启动顺序固定，但容器重启后 IP 可能变，硬编码
proxy_pass http://172.20.0.3:8000必崩）
所以，docker-compose.yml 里写 3 个 nginx 实例 ≠ 集群，只是冗余副本；没外部调度，它们之间不会自动分担流量或故障转移。
如何让 Nginx 容器真正反向代理多个 Django 实例
关键不是堆 Nginx，而是让它能识别并轮询多个 Django 后端。Django 侧必须做成无状态、可水平扩展的单元：
立即学习“Python免费学习笔记（深入）”；
- 所有 session 存 Redis，禁用
django.contrib.sessions.backends.cache以外的本地存储 -
STATIC_ROOT和MEDIA_ROOT必须指向共享存储（如 S3、MinIO 或 NFS），不能依赖单机文件系统 - 数据库连接走连接池（如
pgbouncer），避免每个 Django 实例都建满连接 - Django 容器启动命令必须用
gunicorn --bind 0.0.0.0:8000 --workers 4 --preload，别用runserver
Nginx 配置中 upstream 要用服务名（Docker 内置 DNS）而非 IP：
upstream django_backend {
server app1:8000 weight=3;
server app2:8000;
server app3:8000 backup;
}
对应 docker-compose.yml 中要定义 app1、app2、app3 三个服务，并共用同一个网络。
暴露给公网时，真正的瓶颈在哪儿
本地用 docker-compose 跑三套 nginx + django 看起来很“集群”，但对外只暴露一个端口（比如 80），所有流量先打到第一个 Nginx，它再转发——这时第一个 Nginx 就成了单点瓶颈和故障点。
- 若用
host网络模式，可让每个 Nginx 绑定不同宿主机端口（8081、8082、8083），再由云负载均衡器做四层分发 - 若坚持单端口，就得在最外层加一层 L4 负载（如腾讯云 CLB、阿里云 SLB），把
80流量分到三台 ECS 的不同端口，每台 ECS 上跑一个 Nginx+Django 组合 - 别尝试在单机上用多个 Nginx 容器监听
:80——端口冲突，Docker 不允许
也就是说：Docker 能帮你快速复制服务单元，但不能替代架构设计。集群的复杂度不在容器编排，而在数据一致性、会话管理、动静分离和边界流量调度。
最容易被忽略的一点：Django 的 ALLOWED_HOSTS 必须包含最终用户访问的域名，而不是容器名或 localhost；而 Nginx 的 proxy_set_header Host 如果没透传原始 Host，Django 生成的绝对 URL（如密码重置链接）就会出错。
