怎么优化 Nginx 处理大规模 API 请求的配置组合-Nginx-PHP中文网

nginx 处理大规模 api 请求的关键在于精准匹配业务特征的配置组合，而非盲目调堆参数；需先通过 stub_status、系统命令和错误日志定位瓶颈，再针对性优化 worker 层、连接传输、proxy 层和缓存层配置，并关闭无关功能。

怎么优化 nginx 处理大规模 api 请求的配置组合

Nginx 处理大规模 API 请求时，真正起作用的不是堆参数，而是精准匹配业务特征的配置组合。重点不在“全开”，而在“该开哪几项、开多少、怎么协同”。

一、先确认瓶颈在哪，再动配置

别凭感觉调优，用数据定位真实卡点：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

启用 stub_status 模块（编译需含 --with-http_stub_status_module），访问 /nginx_status 查看：
- Active connections 高但 Waiting 持续远超 Active → 后端响应慢或连接未释放
- Reading/Writing 占比异常高 → 请求头/体过大或客户端网络差
系统级检查：
- top 看 nginx worker 进程 CPU 是否长期 >80%
- ss -s | grep estab 看 ESTABLISHED 连接数是否逼近 net.core.somaxconn 或 ulimit -n
- free -h 和 /proc/meminfo 观察内存是否吃紧
压测时加 error_log /var/log/nginx/api_error.log info;，重点关注 upstream timed out、no live upstreams、connect() failed 类日志

二、API 场景关键配置组合（精简有效）

✅ worker 层：稳住并发底座

worker_processes auto;  
worker_cpu_affinity auto;  
worker_rlimit_nofile 65535;  
events {  
    use epoll;  
    worker_connections 16384;  
    multi_accept on;  
    accept_mutex off;  
}

worker_processes auto + worker_cpu_affinity auto 让每个 worker 绑定独立 CPU 核，减少调度开销
worker_connections 16384 配合系统 ulimit -n 65535 和内核 net.core.somaxconn = 65535，支撑万级并发
multi_accept on + accept_mutex off 允许单次事件循环接收多个新连接，提升吞吐

✅ 连接与传输：适配 API 特性

http {  
    sendfile on;  
    tcp_nopush on;  
    tcp_nodelay on;  
    keepalive_timeout 30;  
    keepalive_requests 1000;  
    client_header_timeout 10;  
    client_body_timeout 10;  
    send_timeout 10;  
}

tcp_nodelay on 关闭 Nagle 算法，避免小包延迟，对 JSON/REST API 更友好
keepalive_timeout 30 足够复用连接，又不长期占资源；keepalive_requests 1000 防止单连接请求过多导致内存累积
sendfile on + tcp_nopush on 加速静态响应（如 Swagger UI、健康检查页）

✅ proxy 层：加速后端转发链路

upstream api_backend {  
    zone api_backend 64k;  
    server 192.168.1.10:8080 weight=5;  
    server 192.168.1.11:8080 weight=5;  
    keepalive 32;  
    # 轻量健康检查  
    health_check interval=3 fails=2 passes=2;  
}  

location /api/ {  
    proxy_pass http://api_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;  

    # 超时必须收紧（API 不同于页面加载）  
    proxy_connect_timeout 3s;  
    proxy_read_timeout 15s;  
    proxy_send_timeout 10s;  

    # 启用代理响应压缩（关键！默认不压缩后端返回）  
    gzip_proxied any;  
    proxy_set_header Accept-Encoding "";  
}

keepalive 32 + proxy_http_version 1.1 + Connection '' 实现后端长连接复用，省掉反复建连开销
gzip_proxied any 是让 Nginx 对后端返回的 JSON 等内容也做压缩，带宽节省明显（尤其大 payload）
Accept-Encoding "" 清除客户端原始头，强制 Nginx 自主压缩，避免后端误判

✅ 缓存层：对可缓存接口立竿见影

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:100m max_size=1g inactive=60m use_temp_path=off;

location /api/v1/products/ {  
    proxy_cache api_cache;  
    proxy_cache_valid 200 302 10m;  
    proxy_cache_valid 404 1m;  
    proxy_cache_use_stale error timeout updating;  
    add_header X-Cache-Status $upstream_cache_status;  
    proxy_pass http://api_backend/;  
}