Nginx反向代理性能调优：worker进程模型与高并发连接配置实战

Nginx反向代理是DevOps实践和SRE稳定性工程中的核心组件。在高并发场景下，Nginx默认配置往往无法发挥硬件性能，需要围绕worker进程模型、连接数参数和upstream策略进行系统调优。本文从内核参数到Nginx配置层面，给出可落地的性能调优方案。

Nginx worker进程模型与CPU亲和性配置

Nginx采用多进程架构，master进程管理多个worker进程，每个worker独立处理请求。worker进程数应与CPU核心数匹配，避免过多进程导致的上下文切换开销：

# nginx.conf 主配置
worker_processes auto;          # 自动匹配CPU核心数
worker_rlimit_nofile 65535;     # worker进程最大文件描述符

events {
    worker_connections 10240;   # 每个worker最大连接数
    use epoll;                  # Linux使用epoll事件模型
    multi_accept on;            # 一次接受多个连接
}

对于CPU亲和性（CPU Affinity），将worker进程绑定到特定CPU核心，减少L1/L2缓存失效：

# 绑定worker到CPU核心（8核服务器）
worker_cpu_affinity 00000001 00000010 00000100 00001000 \
                     00010000 00100000 01000000 1000000;

开启multi_accept后，worker在epoll_wait返回时一次性接受所有就绪连接，适合高并发短连接场景。但在长连接为主的场景下，关闭此选项反而能减少一次性接受过多连接导致的内存压力。

连接数参数调优与内核配合

Nginx的最大并发连接数等于worker_processes × worker_connections。作为反向代理时，每个客户端连接会同时占用一个到upstream的连接，因此有效并发数为该值的一半。调优时需要同步修改内核参数：

# /etc/sysctl.conf 内核网络参数
# 增加文件描述符上限
fs.file-max = 1048576

# TCP连接相关
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# keepalive相关
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 生效
sysctl -p

同时需要调整/etc/security/limits.conf中的用户级限制：

# /etc/security/limits.conf
nginx soft nofile 65535
nginx hard nofile 65535
nginx soft nproc 65535
nginx hard nproc 65535

反向代理upstream健康检查与负载均衡策略

Nginx开源版不带主动健康检查，被动健康检查通过max_fails和fail_timeout实现：

# nginx.conf http块
upstream backend {
    # 负载均衡策略
    least_conn;                    # 最少连接数策略
    
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 max_fails=3 fail_timeout=30s backup;
    
    # 长连接复用
    keepalive 32;                  # 保持32个空闲连接
    keepalive_requests 1000;       # 每连接最大请求数
    keepalive_timeout 60s;         # 空闲超时
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";  # 清除Connection头以复用keepalive
        
        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
        
        proxy_buffering on;
        proxy_buffer_size 16k;
        proxy_buffers 8 32k;
        proxy_busy_buffers_size 64k;
    }
}

least_conn策略将请求分发到当前连接数最少的服务器，比默认的轮询（round-robin）更适合请求处理时间差异大的场景。对于需要会话保持的应用，使用ip_hash按客户端IP哈希分配。

keepalive长连接复用降低TCP握手开销

Nginx到upstream的连接如果每次都新建TCP连接，握手开销在高QPS下不可忽视。上述配置中keepalive 32维护了一个连接池，配合proxy_http_version 1.1和proxy_set_header Connection ""启用HTTP/1.1长连接。

验证keepalive是否生效，可以在upstream服务器上检查连接数：

# 在后端服务器上查看来自Nginx的ESTABLISHED连接数
ss -tn | grep :8080 | grep ESTAB | wc -l

# 如果远小于Nginx的worker_processes × upstream keepalive值，说明长连接复用正常
# 如果连接数持续增长，说明长连接未复用，检查proxy_http_version和Connection头设置

压测验证与性能瓶颈定位

使用wrk或ab进行压力测试，验证调优效果：

# wrk压测命令
wrk -t8 -c1000 -d60s --latency http://nginx-server/

# 参数说明：
# -t8: 8个线程
# -c1000: 1000个并发连接
# -d60s: 持续60秒

# 关键指标：
# Requests/sec: 每秒请求数（QPS）
# Latency Distribution: 延迟分布
# Transfer/sec: 每秒传输数据量

定位瓶颈时，通过nginx -V确认编译参数是否包含--with-http_stub_status_module，开启状态监控：

# nginx.conf
location /nginx_status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
}

# 访问 /nginx_status 输出：
# Active connections: 15
# server accepts handled requests
# 8456 8456 32891
# Reading: 0 Writing: 3 Waiting: 12
# 
# Active connections: 当前活跃连接数
# Waiting: 空闲等待中的连接数（越高说明keepalive复用越好）
# Reading: 正在读取请求头的连接数

当Waiting连接数偏低而Reading+Writing偏高时，说明短连接占比大，检查upstream keepalive配置。当活跃连接数接近worker_processes×worker_connections时，需要增大连接数配置或增加服务器节点。结合Prometheus采集nginx_exporter指标，可以建立完整的监控告警体系，对连接池利用率、upstream响应时间等关键指标设置阈值告警。