Nginx集群配置的核心不是负载均衡算法，而是高可用与会话一致性
在业务规模增长到单台Nginx无法支撑时,配置Nginx集群是必然选择，但多数人误以为只要把多台Nginx用 upstream 指向上游服务器就完成了集群。真正的Nginx集群必须同时解决三个问题：负载均衡、故障转移、会话一致性，缺了任何一个，集群都会在真实流量冲击下出现致命问题，下文将按照从架构设计到落地配置的顺序，给出可直接复用的专业方案。
先明确集群拓扑：Keepalived + Nginx 双机主备是性价比最高的起点
Nginx本身是无状态的,所以集群的关键在于让多个Nginx节点对外表现为一个虚拟IP，最成熟、最轻量的方案是 Keepalived 实现 VIP 漂移。
- 主节点（Master）持有VIP，正常处理请求
- 备节点（Backup）空闲，通过 VRRP 协议监听主节点心跳
- 主节点宕机或 Nginx 进程异常时，VIP 自动漂移到备节点
推荐架构：
用户 → VIP（192.168.1.100） → Nginx Master + Nginx Backup → 后端Web服务器集群
配置要点：
- 两台 Nginx 配置完全一致，包括 upstream 和后端 server 列表
- Keepalived 的
vrrp_script监控 Nginx 进程，而不是只监控网卡 - 必须设置
nopreempt模式，避免主节点恢复后反复切换导致抖动
# 主节点 keepalived.conf 关键片段
vrrp_script chk_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2
weight -20
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
virtual_ipaddress {
192.168.1.100/24
}
track_script {
chk_nginx
}
}
# /etc/keepalived/check_nginx.sh 脚本内容
#!/bin/bash
if [ "$(ps -ef | grep nginx | grep -v grep | wc -l)" -eq 0 ]; then
systemctl stop keepalived
exit 1
fi
经验案例： 酷番云在为某电商客户部署 Nginx 集群时，最初只使用了 Keepalived 默认心跳检测，没有监控 Nginx 进程，结果 Nginx 进程假死（CPU 100%但端口仍监听），VIP 不漂移，导致业务中断 15 分钟，后来加入 check_nginx.sh 脚本，并在脚本中增加主动探测本机 80 端口响应时间，超过 3 秒即视为异常，整改后，故障切换时间从分钟级缩短到 5 秒内，建议使用云服务器的用户，同时开启酷番云的安全组防火墙，避免 VRRP 协议被外部恶意干扰。
负载均衡：upstream 配置必须考虑后端真实健康状态
集群的 Nginx 节点之间是主备关系，而每个 Nginx 节点面对后端服务器时需要配置 upstream。不要使用默认的轮询方式，要使用 least_conn + 健康检查。
upstream backend_pool {
least_conn;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.13:8080 backup; # 备用节点
keepalive 32;
}
关键参数解释：
max_fails=3和fail_timeout=30s表示：30秒内失败3次，该后端被剔除30秒keepalive 32开启长连接，减少 TCP 握手开销，大幅提升吞吐量
进阶优化： 如果你的后端是 PHP-FPM，建议使用 fair 模块按响应时间分配请求，如果是微服务架构，可以搭配 Consul 或 Nginx Plus 的动态解析。
会话一致性：生产环境必须用 ip_hash 或 sticky 模块
很多初学者配置集群后,发现用户登录状态频繁丢失，因为不同请求被分发到不同后端，而 Session 保存在单台服务器内存中。
解决方案有三种：
- 最简单： upstream 开启
ip_hash
- 推荐： 使用
sticky_cookie模块，在 Cookie 中记录后端 ID - 架构级： 将 Session 迁移到 Redis 或 Memcached，推荐使用酷番云的云缓存产品，天然支持高可用集群
注意：
ip_hash仅适用于 IPv4，且会在后端扩容时产生大量重新哈希，生产环境更推荐第三方模块nginx-sticky-module。
# 使用 sticky 模块（需重新编译Nginx）
upstream backend_pool {
sticky name=route;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
集群配置中的隐藏坑：日志、监控与配置同步
双机集群要求两台 Nginx 的配置完全一致，但手动同步容易出错。必须建立配置发布流程。
- 使用 Git 管理 nginx.conf 和 conf.d 下的所有配置
- 通过 Ansible 或脚本将配置推送到所有节点
- 推送后执行
nginx -t校验，然后执行nginx -s reload
监控指标至少包括：
- Nginx 连接数（
nginx_connections_active） - 后端响应时间
- VIP 是否在线
- Keepalived 主备状态
酷番云实践： 我们内部推荐客户使用云监控服务，对 Nginx 的 accepts、handled、requests 三个计数器做环比告警，当 requests 在 5 分钟内下降超过 80% 且 handled 等于 accepts 时，大概率是 VIP 漂移失败，立即通知运维介入。
独立见解：不要盲目上多活集群
很多业务刚上两台 Nginx 就宣称“多活”，但实际上对于单机 QPS 不到 5000 的场景，双机主备完全够用，真正的多活集群需要引入 DNS 轮询、LVS 或云 SLB，且要解决跨机房延迟，Nginx 集群的价值在于高可用，而不是无限扩展，扩展后端应用服务器才是提升性能的正途。
强烈建议在 Nginx 前面再加一层云负载均衡（如酷番云的 CLB），由 CLB 负责 DDoS 防护和 TLS 卸载，Nginx 专注七层路由，这样即使整台 Nginx 物理机宕机，CLB 也能快速将流量切到备机，实现公网入口到应用的全链路高可用。
相关问答
问1：Nginx 集群中，Keepalived 的 VIP 在主备节点间漂移时，已建立的 TCP 连接会断开吗？
会断开,因为 TCP 连接是基于源 IP 和端口四元组的，VIP 漂移后，新请求会走备机，但旧的连接还在老节点上，如果要保持长连接不中断，需要在 OSI 第四层做连接级同步（如 TCP 转发），一般情况下，Web 短连接业务直接接受 1-2 秒的闪断即可，但支付、WebSocket 业务建议使用 Redis 会话共享并实现客户端自动重连。
问2：有三台后端服务器，其中一台性能很强，如何在 Nginx upstream 中按权重分配？
使用 weight 参数即可，例如性能强的服务器权重设为 5，其他两台为 1：
upstream backend_pool {
server 10.0.1.11:8080 weight=5;
server 10.0.1.12:8080 weight=1;
server 10.0.1.13:8080 weight=1;
}
注意：权重的计算是基于轮询次数的，weight=5 表示每 7 次请求中有 5 次发给该服务器，如果该服务器配置了 max_fails 健康检查，一旦被剔除，权重自动失效。
互动环节： 你在配置 Nginx 集群时遇到过什么诡异问题？是“裂脑”导致两边同时持有 VIP，还是日志刷屏但请求 502？欢迎在评论区留言，我会逐一排查思路和配置示例，并挑选典型问题在下期文章中详解，如果你正在选型云服务器，也可以参考酷番云的高可用解决方案，我们会为集群节点提供免费的内网互通和安全组策略建议。
图片来源于AI模型，如侵权请联系管理员。作者：酷小编，如若转载，请注明出处：https://www.kufanyun.com/ask/754836.html
