用 Nginx 配置负载均衡的步骤与后端健康检查验证

知识分享

2026-11-14 14:40

16 阅读

先确认你的场景适合用哪种负载均衡

配置负载均衡之前，要先确认流量入口在哪里。
常见做法是找一台独立服务器或云负载均衡实例作为入口，把请求分发给后面的多台后端服务器。
如果只有一台后端机器，配置负载均衡意义不大；
如果后端已经有多台，且希望按权重或健康状态分流，Nginx 的七层负载均衡是最容易落地的方式。

本文以 Nginx 为例，假设入口机器已安装 Nginx，后端有两台提供相同服务的服务器，监听 8080 端口。
你需要准备：

入口服务器能通过内网或公网访问后端 IP 和端口
后端服务在两台机器上都已启动且返回一致内容
入口服务器已放行对外服务端口，云安全组和系统防火墙都要检查
修改配置前备份 /etc/nginx/nginx.conf 或站点配置文件

用 upstream 定义后端服务器组

Nginx 的负载均衡逻辑写在 upstream 块里，proxy_pass 再把请求交给这个组。
下面是最小可用配置，可放在 http 块内或站点配置文件的 server 块外：

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

默认是轮询，两台机器依次接收请求。
如果两台机器配置不同，可以加权重：

upstream backend_pool {
    server 192.168.1.11:8080 weight=3;
    server 192.168.1.12:8080 weight=1;
}

然后在站点 server 块里转发：

server {
    listen 80;
    server_name example.internal;

    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;
    }
}

注意 proxy_pass 后面写的是 upstream 名称，不是某台后端 IP。
这样后续增删后端只需改 upstream 块。

加上被动健康检查，避免请求打到故障机器

Nginx 开源版自带被动健康检查：某台后端连续失败达到阈值后，会被暂时标记为不可用，过一段时间再尝试恢复。
可以在 server 行追加参数：

upstream backend_pool {
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;
}

含义是 30 秒内失败 3 次就摘除该后端，30 秒后再试探。
这里要区分：这不是主动探测，只有真实请求失败才会触发。
如果希望主动探测，需要商业版或第三方模块，不要误以为加了这几个参数就能定时心跳检测。

另外一个常见坑是超时时间。
后端处理慢时，Nginx 默认等待时间可能不够，可以按业务调整：

proxy_connect_timeout 5s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

超时设置过短会把正常慢请求判为失败，导致后端被误摘除；
设置过长又会让故障感知变慢。
建议先用真实请求压测，再定数值。

检查配置并验证分发结果

改完配置先做语法检查，不要直接重载：

nginx -t

输出 syntax is ok 和 test is successful 才说明配置可加载。
然后平滑重载：

nginx -s reload

验证分两步。
第一步确认入口能访问：

curl -I http://入口IP/

第二步确认请求确实分发到不同后端。
如果两台后端返回内容带主机标识，连续请求几次观察结果：

for i in 1 2 3 4; do curl -s http://入口IP/ | grep -i host; done

也可以直接查看 Nginx 访问日志和后端访问日志的对应关系。
若所有请求都只打到一台，优先检查 upstream 里是否只写了一台、proxy_pass 是否误写成固定 IP，以及权重是否差距过大。

后端宕机时怎么判断负载均衡是否生效

最直接的验证方式是停掉其中一台后端服务，然后持续访问入口。
预期结果是请求仍能返回，只是全部落到剩余机器。
如果停掉一台后入口直接报 502 或 504，说明健康检查没有及时摘除故障节点，或者超时配置不合理。

排查顺序建议固定下来：

从入口机器 curl 后端 IP 和端口，确认网络和端口本身通不通
查看 Nginx 错误日志，常见路径是 /var/log/nginx/error.log，重点看 connect() failed 或 upstream timed out
确认后端应用是否正常监听，而不是只看到进程存在
检查云安全组是否只放行了入口端口，没有放行入口到后端的端口
确认 fail_timeout 和 max_fails 没有被设得过大

恢复后端后，Nginx 会在 fail_timeout 过后重新把节点加入。
如果业务要求快速恢复，可以适当缩短该值，但不要过小，否则容易在偶发失败时频繁摘除节点。

几个容易踩的细节

proxy_pass 结尾带不带斜杠会影响路径拼接。proxy_pass http://backend_pool; 会保留原始 URI，而 proxy_pass http://backend_pool/; 会把匹配到的 location 前缀替换掉。
改动前先确认后端路由规则，否则可能出现 404。

会话保持也是常见需求。
默认轮询下同一用户的请求会落到不同后端，如果后端把登录态存在本机内存，就会出现登录后掉线。
此时要么把会话外置到 Redis 等共享存储，要么使用 ip_hash 按客户端 IP 固定后端，但 ip_hash 在大量用户走同一出口 IP 时容易分布不均，需要权衡。

最后，负载均衡入口本身也可能成为单点。
生产环境如果要求高可用，入口层通常需要两台 Nginx 加虚拟 IP 或云负载均衡，而不是只配一台。
配置完成后，建议把 nginx -t、重载命令和回滚方式写进变更记录，下次调整参数时能快速核对。

负载均衡有没有必要？从单机瓶颈到高可用的判断方法