nginx配置负载均衡

nginx配置负载均衡

Nginx 作为高性能的反向代理服务器，常被用来将流量分发到多台后端服务器，以此提升服务的并发能力与可用性。本文介绍如何通过 Nginx 实现基础的 HTTP 负载均衡，并覆盖常见配置项与验证方法。

一、负载均衡的基本概念

负载均衡可以理解为“流量调度员”。当用户请求到达 Nginx 时，Nginx 根据预设策略，将请求转发给一组后端服务器中的某一台。通过将压力分散到多台机器，可以避免单点过载，也能在一台后端故障时自动切换流量，提高整体稳定性。 Nginx 的负载均衡功能主要通过 `upstream` 块与 `proxy_pass` 配合实现。`upstream` 定义后端服务器组，`proxy_pass` 指定将请求转发到该组。

二、最小可用配置

假设您有两台后端服务器，IP 分别为 `192.168.1.10` 与 `192.168.1.11`，均运行在 80 端口。以下配置将全部外部请求轮询转发到这两台服务器。 nginx http { upstream backend { server 192.168.1.10:80; server 192.168.1.11:80; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; 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`：定义后端服务器组，组名可自定义。
• `server` 指令：列出具体的后端地址，可加端口。
• `proxy_set_header`：将客户端原始地址和主机名传递给后端，便于后端记录日志或做访问控制。

三、常用负载均衡策略

#### 轮询（默认） 上述示例即是轮询，请求按顺序依次发给后端服务器。当服务器性能近似时，轮询简单有效。 #### 加权轮询 如果某台服务器性能较强，可以设置更高的权重，让更多请求落到它上面。 nginx upstream backend { server 192.168.1.10:80 weight=3; server 192.168.1.11:80 weight=1; } 此时大约 3/4 的请求会分发到第一台服务器。 #### 最少连接 将请求优先转发给当前活跃连接数最少的服务器，适合处理长连接或请求处理时间差异大的场景。 nginx upstream backend { least_conn; server 192.168.1.10:80; server 192.168.1.11:80; } #### IP 哈希 根据客户端 IP 计算哈希值，使同一 IP 的请求固定转发到同一台后端。适用于需要保持会话（Session）的场景，但若后端宕机，该 IP 的请求会失败，需要配合备用服务器使用。 nginx upstream backend { ip_hash; server 192.168.1.10:80; server 192.168.1.11:80; server 192.168.1.12:80 down; # 手动标记不可用 server 192.168.1.13:80 backup; # 备份服务器，仅当其他服务器都不可用时才使用 }

四、健康检查与故障转移

Nginx 默认在转发请求时才会探测后端是否可用。如果某台后端拒绝连接或超时，Nginx 会将其标记为不可用，并在一定时间后再次尝试。您可以通过参数控制探测行为。 nginx upstream backend { server 192.168.1.10:80 max_fails=3 fail_timeout=30s; server 192.168.1.11:80 max_fails=3 fail_timeout=30s; } 含义：如果 30 秒内与后端通信失败达到 3 次，则将该后端标记为不可用，并停止向其转发请求，30 秒后重新尝试。 Nginx 官方原生的健康检查依赖被动探测。如果您需要主动周期性健康检查（例如探测 `/health` 路径），则需要使用开源版 Nginx Plus 或编译时加入 `nginx_upstream_check_module` 第三方模块。该模块需要重新编译 Nginx，且升级时需同步，请根据您的运维能力与风险承受能力谨慎选择。

五、代理常用参数调优

为提高稳定性和性能，可以在 `location` 中补充以下参数： nginx location / { proxy_pass http://backend; proxy_connect_timeout 5s; # 与后端建立连接的超时时间 proxy_read_timeout 10s; # 后端响应超时时间 proxy_send_timeout 10s; # 向后端发送请求的超时时间 proxy_next_upstream error timeout; # 后端错误或超时时，尝试下一台 proxy_next_upstream_tries 2; # 最多尝试 2 次（含首次） proxy_http_version 1.1; proxy_set_header Connection ""; }

• 设置合理的超时时间，避免长时间等待无响应的后端。
• `proxy_next_upstream` 允许在故障时自动切换到下一台服务器，提高可用性。
• 如果后端支持 HTTP/1.1，建议启用 1.1 协议并清空 `Connection` 头，以充分利用 keepalive，降低资源消耗。

如需启用 Nginx 与后端之间的 keepalive，可以在 `upstream` 中增加： nginx upstream backend { server 192.168.1.10:80; server 192.168.1.11:80; keepalive 32; # 为每个 worker 进程保留最多 32 个空闲连接 } 同时，上述 `location` 中必须保留 `proxy_http_version 1.1;` 和 `proxy_set_header Connection "";`。

六、完整配置示例

结合以上内容，一个面向生产的基本配置如下： nginx http { upstream backend { least_conn; server 192.168.1.10:80 max_fails=3 fail_timeout=30s; server 192.168.1.11:80 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 80; server_name api.example.com; location / { proxy_pass http://backend; proxy_http_version 1.1; 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_set_header Connection ""; proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 10s; proxy_next_upstream error timeout; proxy_next_upstream_tries 2; } } }

七、验证与重载配置

修改配置文件后，先执行语法检查，再平滑重载： bash nginx -t 若输出 `syntax is ok` 且 `test is successful`，则执行： bash nginx -s reload `reload` 不会中断现有连接，只会让新的 worker 进程加载新配置，属于平滑操作。

八、注意事项与回滚

• 修改 `upstream` 中后端服务器列表时，务必确认地址及端口可访问，否则会导致部分请求失败。
• 如果业务要求 HTTPS，请将 `listen 80` 改为 `listen 443 ssl`，并配置证书路径，同时增加 `proxy_set_header X-Forwarded-Proto $scheme;` 以便后端识别协议。
• 健康检查参数应结合业务容忍度。不建议将 `max_fails` 设得过大，也不建议将 `fail_time