nginx负载均衡配置详解

nginx负载均衡配置详解

负载均衡是nginx最常用的功能之一，适用于多台后端服务器协同提供服务的场景。通过nginx将客户端请求分摊到不同服务器，既能提升系统整体吞吐量，也能在单台服务器故障时自动切流，保障服务连续。以下从基础配置入手，分别介绍几种常见策略与注意事项。

什么是nginx负载均衡

简单理解，nginx扮演“调度员”角色，维护一份后端服务器名单。当请求到达时，nginx按预设规则选择一台后端服务器转发。对客户端而言，它们始终只访问nginx的地址，后端服务器细节被隐藏，便于后续扩缩容。

基础配置结构

配置负载均衡需要两步：先用`upstream`定义一组后端服务器，再在`location`或`server`块中通过`proxy_pass`将请求转交给这个组。 示例：搭建一个名为`backend`的服务器组，包含两台应用服务器。 nginx http { upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; } 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; } } } 以上配置将`example.com`的请求轮流分发给两台服务器。`proxy_set_header`用于传递客户端原始IP和协议信息，避免后端应用误将nginx当作客户端来源。

常见负载均衡策略

nginx默认采用轮询方式，另外还提供多种策略，您可根据业务特点选用。 | 策略 | 配置关键词 | 适用场景 | | --- | --- | --- | | 轮询（默认） | 无 | 各节点配置相同、处理能力相近 | | 加权轮询 | `weight` | 服务器性能差异明显 | | IP哈希 | `ip_hash` | 需要同一用户固定访问同一台服务器（如本地会话） | | 最少连接 | `least_conn` | 请求处理时长差异较大 | | 一致性哈希 | `hash $request_uri` | 基于URL或参数定向分发，适合缓存层 | #### 加权轮询示例 nginx upstream backend { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080 weight=1; } 上述配置表示10.10服务器每接收3个请求，10.11接收1个，适合一台机器配置较高的情况。 #### IP哈希示例 nginx upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; } 按客户端IP计算哈希值，来源相同的请求始终发往同一台后端。优点是可解决部分会话保持问题，缺点是若某台服务器宕机，其对应IP段请求会受影响，需结合健康检查模块使用。 #### 最少连接示例 nginx upstream backend { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; } nginx会将新请求转发给当前活跃连接数最少的服务器，适合长任务或计算密集接口，避免忙闲不均。

健康检查与故障转移

nginx默认仅做TCP连接检测，并不主动探测应用健康状态。若某台后端直接停机，nginx会将其标记为不可用并停止转发，但若后端服务进程存在却对外返回500等错误，nginx不会自动摘除该节点。 更精准的检查需借助商业版`nginx plus`或开源模块`nginx_upstream_check_module`（需编译安装）。若不便引入额外模块，可简单利用`max_fails`和`fail_timeout`做被动检查： nginx upstream backend { server 192.168.1.10:8080 max_fails=2 fail_timeout=30s; server 192.168.1.11:8080 max_fails=2 fail_timeout=30s; } 含义：30秒内请求该服务器失败达到2次，nginx在接下来的30秒内不再转发请求给它。此参数不能覆盖所有异常场景，但仍能有效缓解单点故障造成的连锁超时。

调优与安全建议

1. 合理设置超时时间

在`location`块中增加以下指令，避免后端响应慢时长时间占用nginx连接： nginx proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 10s;

1. 启用连接复用

在`upstream`级别配置`keepalive`，减少nginx与后端之间反复建立TCP连接的开销： nginx upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; keepalive 32; } 同时需将请求头中的`Connection`设为空值： nginx proxy_http_version 1.1; proxy_set_header Connection "";

1. 限制上游服务器数量

不要在一个`upstream`中堆叠过多节点，建议保持在10台以内，否则nginx轮询与健康检查的开销会明显增加。若节点超过10台，可拆分为多个`upstream`按业务线隔离。

1. 避免暴露后端地址

`proxy_pass`后面不要直接写公网IP或带明文端口的内网地址，推荐使用内网域名或仅内网可达的IP，并在`server`块中禁用`server_tokens off;`隐藏nginx版本号。

验证与重载

修改配置后，务必先检查语法，再平滑重载： bash nginx -t nginx -s reload 若`nginx -t`输出`syntax is ok`，说明配置语法正确。重载不会中断现有连接，会以新配置启动新的worker进程。

常见误区

• 忘记配置`proxy_set_header`，导致后端获取不到客户端真实IP，影响日志分析或访问控制。
• 依赖默认轮询不考虑节点权重，可能让性能较弱的服务器成为瓶颈。
• 把`upstream`写在`server`内部，nginx只允许在`http`块内定义`upstream`，否则会报错。
• 没有设置任何超时，后端应用假死时nginx连接被长期占用，最终耗尽worker连接数。

如您在多级代理、HTTPS证书卸载或WebSocket负载均衡等场景需要进一步细化配置，可提供当前nginx版本与业务形态，我们可以针对具体参数继续调整。