Nginx反向代理配置实战：负载均衡与健康检查机制详解

Nginx反向代理与负载均衡核心配置

Nginx作为反向代理服务器在生产环境中承担流量分发、SSL终结、静态资源缓存等关键职责。负载均衡配置的核心在于upstream模块，它定义了后端服务器池和流量分配策略。一个典型的反向代理配置包含upstream定义、server块监听、location规则匹配三个部分。

以下是一个完整的Nginx反向代理负载均衡配置示例，使用加权轮询策略，后端挂载三台应用服务器：

# /etc/nginx/conf.d/load-balancer.conf

upstream backend_api {
    # 加权轮询，weight值越大分配的请求越多
    server 192.168.1.101:8080 weight=3;
    server 192.168.1.102:8080 weight=2;
    server 192.168.1.103:8080 weight=1;

    # 备用服务器，主服务器全部不可用时启用
    server 192.168.1.104:8080 backup;

    # 保持长连接，减少TCP握手开销
    keepalive 32;
    keepalive_timeout 60s;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # SSL配置
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    location /api/ {
        proxy_pass http://backend_api;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # 传递真实客户端信息
        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 X-Forwarded-Proto $scheme;

        # 超时设置
        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
    }
}

配置中的keepalive指令启用了到后端服务器的长连接复用。Nginx与后端之间保持32个空闲连接，新请求直接复用已有连接，避免每次请求都进行TCP三次握手。在高并发场景下，这一配置可以降低约15-20%的延迟。

负载均衡策略选择与调优

Nginx支持四种负载均衡策略，选择合适的策略直接影响系统的稳定性和性能：

# 1. 轮询（默认）：按顺序依次分配
upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

# 2. 加权轮询：按weight比例分配
upstream backend {
    server 192.168.1.101:8080 weight=3;
    server 192.168.1.102:8080 weight=1;
}

# 3. IP哈希：相同客户端IP固定访问同一后端
upstream backend {
    ip_hash;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

# 4. 最少连接数：优先分配给当前连接数最少的后端
upstream backend {
    least_conn;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

# 5. 一致性哈希（需ngx_http_upstream_consistent_hash模块）
upstream backend {
    consistent_hash $request_uri;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

IP哈希策略适用于需要会话保持的场景，但存在后端服务器扩缩容时缓存命中率骤降的问题。一致性哈希通过虚拟节点解决了这个问题，当后端服务器数量变化时，只有约1/N的请求会被重新分配（N为服务器数量）。对于有状态服务，一致性哈希是更优选择。

主动健康检查机制配置

Nginx开源版默认只支持被动健康检查——当请求转发失败时才标记服务器为不可用。主动健康检查需要依赖nginx_upstream_check_module模块或使用Nginx Plus。以下是开源方案的配置：

# 编译安装nginx_upstream_check_module后
upstream backend_api {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    server 192.168.1.103:8080;

    # 主动健康检查配置
    check interval=3000 rise=2 fall=3 timeout=2000 type=http;
    check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

# 健康检查状态页面
server {
    listen 8088;
    server_name localhost;

    location /status {
        check_status;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}

配置参数含义：interval=3000表示每3秒检查一次；rise=2表示连续2次检查成功才标记为可用；fall=3表示连续3次检查失败才标记为不可用；timeout=2000设置检查超时为2秒。健康检查接口/health应返回HTTP 200状态码，且响应时间控制在50ms以内。

对于不安装第三方模块的场景，可以通过Nginx原生配置实现简单的故障转移：

upstream backend_api {
    server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.103:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        proxy_pass http://backend_api;
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;
        proxy_next_upstream_timeout 10s;
    }
}

max_fails=3 fail_timeout=30s表示30秒内失败3次后，将该服务器标记为不可用30秒。proxy_next_upstream配置定义了触发重试的条件和次数限制，当后端返回502、503、504或超时时，自动转发到下一台服务器。

Keepalived+Nginx高可用架构

单台Nginx存在单点故障风险。Keepalived通过VRRP协议实现Nginx的高可用，两台Nginx服务器一主一备，主节点故障时备节点自动接管VIP（虚拟IP）。

# /etc/keepalived/keepalived.conf - 主节点配置
global_defs {
    router_id NGINX_MASTER
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass YourPassword123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_nginx
    }
}

健康检查脚本check_nginx.sh检测Nginx进程是否存活：

#!/bin/bash
# /etc/keepalived/check_nginx.sh
if [ -f /var/run/nginx.pid ]; then
    nginx_pid=$(cat /var/run/nginx.pid)
    if kill -0 $nginx_pid 2>/dev/null; then
        exit 0
    fi
fi
# Nginx进程不存在，尝试重启
systemctl restart nginx
sleep 2
if kill -0 $(cat /var/run/nginx.pid 2>/dev/null) 2>/dev/null; then
    exit 0
fi
exit 1

备节点配置将state改为BACKUP，priority设为90。当主节点的check_nginx脚本返回失败时，priority降低20变为80，低于备节点的90，VRRP协议触发VIP漂移到备节点。整个切换过程通常在2-4秒内完成。

性能调优与常见问题诊断

Nginx反向代理的性能瓶颈通常出现在worker进程数、连接数限制和缓冲区配置三个方面。worker_processes应设置为CPU核心数，worker_connections根据并发量调整：

# /etc/nginx/nginx.conf
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 16384;
    use epoll;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 缓冲区配置
    proxy_buffering on;
    proxy_buffer_size 4k;
    proxy_buffers 8 4k;
    proxy_busy_buffers_size 8k;

    # 文件缓存
    open_file_cache max=10000 inactive=60s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
}

诊断Nginx反向代理问题的常用方法：通过access_log分析请求转发情况，error_log排查后端连接错误，stub_status模块监控Nginx自身连接状态。当遇到502 Bad Gateway时，首先检查后端服务是否正常运行，其次检查Nginx与后端之间的网络连通性，最后检查proxy_read_timeout是否设置过短。