Nginx 负载均衡器配置教程：从零到生效验证

知识分享

2026-10-13 13:00

12 阅读

如果你有 2 台以上服务器提供同一项 Web 服务，想用 Nginx 把请求分发到它们，这篇负载均衡器配置教程可以直接照做。
下面全部以 Nginx 的 HTTP 七层负载均衡为例，假设系统是常见的 Linux 发行版，你已经能用 nginx -v 查到版本，并且拥有 root 或 sudo 权限。

先确认环境，再动手改配置

Nginx 的负载均衡核心是 upstream 块，它定义一组后端服务器，proxy_pass 再把请求转发到这个组。
操作前先确认三件事：

Nginx 已安装并能正常启动，执行 nginx -t 应返回 syntax is ok。
后端服务真实可访问，先在 Nginx 机器上 curl http://后端IP:端口 验证，避免把后端本身的问题误判成负载均衡问题。
主配置文件位置通常是 /etc/nginx/nginx.conf，站点配置在 /etc/nginx/conf.d/ 下。改之前先备份：cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak。

写一个最小的负载均衡配置

在 /etc/nginx/conf.d/ 下新建 lb.conf，内容如下：

upstream backend_pool {
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

server {
    listen 80;
    server_name example.local;

    location / {
        proxy_pass http://backend_pool;
        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_pool 要和 proxy_pass 里的一致，否则启动会报 unknown upstream。
默认调度是轮询（round-robin），请求依次发往后端。
proxy_set_header 这几行是把真实客户端 IP 传给后端，缺少它们后端日志里只会看到 Nginx 的 IP。
保存后执行 nginx -t 检查语法，通过再 nginx -s reload 让配置生效。

调整分发策略和健康检查

默认轮询不区分后端性能。
如果两台机器配置不同，可以给性能好的加权重，或者用其他调度方式：

upstream backend_pool {
    least_conn;
    server 192.168.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.13:8080 backup;
}

least_conn 按当前连接数最少的后端优先分发，适合请求处理时间差异较大的场景。
weight 设置权重，数值越大分到的请求越多。
max_fails 和 fail_timeout 是简单的被动健康检查：在 fail_timeout 时间内失败达到 max_fails 次，就暂时把该后端摘除，超时后再尝试恢复。
backup 标记备用节点，只有主节点全部不可用才会启用。

需要主动健康检查（比如定期探测 /health）时，开源版 Nginx 的 upstream 本身不直接支持，通常借助 nginx_upstream_check_module 或改用 OpenResty、HAProxy 等方案。
不确定自己版本是否带该模块时，用 nginx -V 2>&1 | grep -o check 查看，不要照抄未经验证的模块配置。

常见报错怎么定位

配置改完后最常见的两类问题：

访问出现 502 Bad Gateway：说明 Nginx 能收到请求，但连不上后端。先看错误日志 tail -f /var/log/nginx/error.log，常见原因包括后端端口写错、后端服务没启动、防火墙拦截。在 Nginx 机器上用 curl http://后端IP:8080 复现，能直接区分是网络问题还是 Nginx 配置问题。
一直转到同一台后端：检查是否只配了一个 server，或某台被 max_fails 摘除后还没到 fail_timeout 恢复时间。

另外，修改 upstream 后一定要 reload 而不是 restart，reload 不会中断已有连接，影响更小。

验证负载均衡是否真的生效

不要只看配置语法通过就结束，用下面方法确认分发行为：

在后端机器上分别把返回内容改成可区分的主机标识，例如在各自页面上输出主机名。
在客户端连续请求：for i in $(seq 1 6); do curl -s http://example.local; done，观察返回是否在不同后端之间轮换。
同时查看两台后端的访问日志，确认请求确实被分发过去，而不是全部落在同一台。
检查后端收到的 X-Real-IP 是否为真实客户端 IP，验证转发头配置正确。

如果轮询结果符合预期、日志也显示请求分流，说明负载均衡器配置已经生效。

几个容易踩的坑

只改了配置没 reload，访问行为没变化，先执行 nginx -s reload 再测试。
proxy_pass 末尾带不带 / 会影响路径拼接：proxy_pass http://backend_pool/ 会替换掉 location 匹配的前缀，不带则保留原路径，不确定时先用不带斜杠的写法并观察后端收到的路径。
后端和 Nginx 不在同一内网时，注意安全组和防火墙只放行必要端口，不要把后端端口直接暴露到公网。
涉及重启或 reload 前保留配置备份，出现异常可以用备份文件快速回滚。

这套配置适用于 HTTP 七层转发。
如果你的服务是数据库、长连接等四层场景，需要改用 stream 模块或专门的四层负载均衡方案，配置思路不同，不要直接套用本文的 upstream 写法。

DNS解析故障排查：从现象到修复的完整命令清单

Nginx SSL证书配置：从申请到HTTPS生效的完整步骤