Nginx负载均衡配置实战：从单机到多后端的完整步骤
Nginx 负载均衡配置的核心，是在 http 块里定义一个 upstream 组，把多台后端服务器写进去，再用 proxy_pass 把请求转发到这个组。
只要后端服务本身可访问、Nginx 配置语法正确，通常重载后就能生效。
下面按零基础也能照做的顺序，把准备、配置、避坑和验证讲清楚。
开始前需要确认的环境和文件位置
先确认 Nginx 已经安装并能正常启动。
不同系统配置文件位置不同，常见路径如下：
- Debian/Ubuntu：主配置
/etc/nginx/nginx.conf，站点配置常在/etc/nginx/sites-available/或/etc/nginx/conf.d/ - CentOS/RHEL：主配置
/etc/nginx/nginx.conf，自定义配置常放/etc/nginx/conf.d/ - 宝塔面板：网站配置一般在
/www/server/panel/vhost/nginx/，也可以在面板「网站」中直接编辑
检查 Nginx 是否运行：
nginx -v
systemctl status nginx同时确认后端服务已经能单独访问。
例如两台后端分别是 192.168.1.10:8080 和 192.168.1.11:8080，先在 Nginx 所在机器上执行：
curl -I http://192.168.1.10:8080
curl -I http://192.168.1.11:8080如果这里就失败，先解决后端服务或防火墙问题，不要急着改负载均衡配置。
写一个可用的 upstream 负载均衡配置
在 http 块内、server 块外定义后端组。
下面是最常见的轮询写法：
upstream backend_servers {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}关键点解释：
upstream backend_servers是自定义组名，proxy_pass里的名字必须和它一致- 默认策略是轮询，请求会依次分发到各后端
proxy_set_header用于把真实客户端信息传给后端，缺少时后端日志可能只看到 Nginx 的 IP- 修改后先测试语法，再重载：
nginx -t
systemctl reload nginxnginx -t 返回 syntax is ok 和 test is successful 才算通过。
按权重分发和健康检查的常见写法
如果两台后端配置不同，可以用 weight 控制流量比例：
upstream backend_servers {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
}表示前者大约承担四分之三的请求。
Nginx 开源版默认带被动健康检查：当某台后端连续失败达到阈值时，会暂时把它标记为不可用，过一段时间再尝试。
也可以手动标记：
upstream backend_servers {
server 192.168.1.10:8080;
server 192.168.1.11:8080 down;
}down 表示暂时不参与分发，适合维护某台机器时使用。
如果业务需要更主动的健康检查，通常要结合 Nginx Plus 或第三方模块，开源版不要想当然认为它会定时探测。
容易踩坑的几个地方
第一，后端返回 502。
优先看后端服务是否监听在正确端口、Nginx 所在机器能否 curl 通，以及 SELinux 或防火墙是否拦截。
命令示例：
tail -f /var/log/nginx/error.log
ss -lntp | grep 8080第二，请求都打到同一台后端。
检查是否误用了 ip_hash，或者客户端经过多层代理导致来源 IP 相同。
轮询模式下可以临时把其中一台 down 掉，观察流量是否切换。
第三，改了配置没生效。
确认改的是当前加载的配置文件，执行 nginx -T 可以看到最终合并后的完整配置。
重载用 reload，不要直接 restart 中断连接。
第四，后端拿不到真实 IP。
除了 proxy_set_header，后端应用也要按对应字段读取，例如 PHP 中关注 HTTP_X_FORWARDED_FOR。
验证负载均衡是否真的在工作
最直接的方法是在两台后端返回不同标识，然后多次请求入口。
例如后端分别返回 server A 和 server B，执行：
for i in $(seq 1 6); do curl -s http://example.com; echo; done如果输出交替出现 A 和 B，说明轮询生效。
再结合日志确认：
tail -f /var/log/nginx/access.log把其中一台后端停掉，继续请求，如果服务仍可用且错误日志里出现上游连接失败的记录，说明故障转移在起作用。
几个常见疑问
Nginx 负载均衡需要装额外模块吗？ 基础的 HTTP 负载均衡是 Nginx 内置功能，不需要额外安装模块，直接写 upstream 即可。
upstream 里能写域名吗？ 可以，但域名解析发生在 Nginx 启动或重载时。
如果后端 IP 经常变化，需要配合解析器或改用其他方案，否则可能一直转发到旧地址。
压测时应该注意什么？ 先确认后端单机扛得住，再逐步加压，观察 Nginx 错误日志和后端连接数。
不要一上来就把并发拉满，容易把后端打挂而误判为负载均衡问题。
配置改错了怎么回滚？ 修改前备份原文件，
例如 cp nginx.conf nginx.conf.bak，
出错时恢复备份并再次执行 nginx -t && systemctl reload nginx。
整体思路就是：先保证后端可访问，再写 upstream 和 proxy_pass，测试语法后重载，最后用多次请求和日志验证分发效果。
按这个顺序排查，大部分 Nginx 负载均衡配置问题都能定位到具体环节。
