Nginx反向代理与负载均衡配置：SSL终端优化与上游健康检查

Nginx反向代理与负载均衡配置：SSL终端优化与上游健康检查

Nginx作为反向代理承载高并发流量时，配置不当容易成为性能瓶颈。本文从SSL终端优化、负载均衡策略、上游健康检查三个维度，给出生产环境Nginx配置的具体方法和诊断思路。

SSL终端性能优化配置

TLS握手是HTTPS连接中CPU消耗最大的环节。未优化时，单次TLS 1.3握手耗时30-50ms，高并发下Nginx worker进程CPU占用可超过90%。以下配置将握手延迟降至5ms以内：

# nginx.conf http块
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

# 启用OCSP Stapling减少客户端验证延迟
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

ssl_session_cache shared:SSL:50m分配50MB共享内存存储SSL会话，支持约20万个并发会话复用。会话复用可跳过完整的TLS握手流程，将后续连接握手延迟从30ms降至1-2ms。

TLS 1.3的0-RTT模式进一步减少一个RTT往返：

ssl_early_data on;

# 在反向代理中转发Early Data头部
proxy_set_header Early-Data $ssl_early_data;

注意：0-RTT存在重放攻击风险，仅对幂等请求（GET、HEAD）启用，POST等写操作需在后端校验Early-Data头部。

负载均衡策略选型与配置

Nginx支持多种负载均衡算法，选型直接影响后端服务压力分布：

upstream backend {
    # least_conn：最小连接数，适合请求处理时间差异大的场景
    least_conn;
    
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s backup;
    
    # 长连接复用，减少TCP握手开销
    keepalive 64;
    keepalive_timeout 60s;
    keepalive_requests 1000;
}

server {
    listen 443 ssl http2;
    
    location /api/ {
        proxy_pass http://backend;
        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 60s;
        
        # 缓冲区配置
        proxy_buffering on;
        proxy_buffer_size 16k;
        proxy_buffers 8 32k;
        proxy_busy_buffers_size 64k;
    }
}

策略选型对比：

• round_robin（默认）：轮询分发，后端服务性能一致时使用
• least_conn：分发到活跃连接数最少的服务器，请求处理时间差异大时效果显著
• ip_hash：按客户端IP哈希固定分发，需会话保持但无独立Session服务时使用
• random：随机分发，后端节点多时性能略优于轮询

max_fails=3 fail_timeout=30s表示30秒内失败3次后，将该节点摘除30秒。backup标记的节点仅在所有主节点不可用时启用。

主动健康检查配置

Nginx开源版的被动健康检查依赖max_fails机制，故障感知延迟较高。Nginx Plus或第三方模块nginx_upstream_check_module支持主动健康检查：

# 使用nginx_upstream_check_module
upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    
    # 主动健康检查
    check interval=3000 rise=2 fall=3 timeout=2000 type=http;
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

server {
    location /status {
        check_status;
        access_log off;
        allow 10.0.0.0/8;
        deny all;
    }
}

该配置每3秒向后端发送一次/health请求，连续2次成功标记为健康，连续3次失败标记为故障并摘除。/status页面提供可视化健康状态面板。

连接耗尽与优雅停机

后端服务发布时需要优雅停机，避免Nginx将请求分发到正在关闭的节点：

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    
    # 优雅关闭配置
    slow_start 30s;          # 新节点预热时间，逐步增加流量
    drain_timeout 60s;       # 连接耗尽等待时间
}

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

proxy_next_upstream配置在当前上游返回502/503/504或超时时自动重试下一个节点。proxy_next_upstream_tries 3限制最多重试3次，防止雪崩。

故障诊断：502 Bad Gateway排查路径

502错误通常由Nginx无法与后端建立连接引起。排查步骤：

# 1. 检查Nginx error日志中的具体错误
tail -f /var/log/nginx/error.log | grep "upstream"

# 常见错误及含义：
# "connect() refused" — 后端服务未启动或端口错误
# "upstream timed out" — 后端处理超时，检查proxy_read_timeout配置
# "upstream sent invalid header" — 后端返回了非法HTTP头

# 2. 验证后端服务连通性
curl -v http://10.0.1.10:8080/health

# 3. 检查Nginx与后端的连接队列
ss -tnp | grep :8080 | wc -l

# 4. 检查文件描述符限制
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"

当ss显示到后端的连接数接近keepalive 64配置值时，说明长连接池已耗尽，需增大keepalive值或增加后端节点。Max open files低于65535时需调整worker_rlimit_nofile。

性能基准与调优参考值

以4核8GB虚拟机部署Nginx为例，不同场景的参考吞吐量：

• 纯反向代理（无SSL）：约45000 req/s，CPU占用约60%
• SSL终端 + 反向代理：约12000 req/s，CPU占用约85%
• SSL终端 + 静态文件缓存：约8000 req/s，CPU占用约70%

worker_processes设为CPU核数，worker_connections设为10240以上。开启reuseport可实现SO_REUSEPORT，多个worker进程独立监听同一端口，避免accept锁竞争，吞吐量提升15%-20%：

worker_processes auto;
events {
    worker_connections 10240;
    use epoll;
    multi_accept on;
}

server {
    listen 443 ssl http2 reuseport;
    # ...
}

以上配置在4核环境中实测，SSL反向代理吞吐量从12000 req/s提升到14500 req/s。实际部署需根据后端服务处理能力和网络带宽调整连接池和超时参数。