nginx 稳定扛百亿级请求需精准配置负载均衡与内存协同优化：合理设置 worker_processes（如16核以上设8或12）和 worker_connections（按峰值×1.2），启用 multi_accept on 和 epoll，上游使用 keepalive 连接池，分层收紧缓冲区，关闭非必需日志与模块。
Nginx 要稳定扛住百亿级请求，光靠堆机器不行，关键在负载均衡配置与内存协同优化——既要让流量分得准、切得稳，又要让每个 worker 进程不因缓冲区膨胀或连接堆积而吃光内存。
worker 进程与连接数需精准匹配硬件能力
每个 worker 进程默认会为每个连接分配独立的内存上下文（含读写缓冲、SSL 状态、header 存储等）。若 worker_processes auto 在 64 核服务器上启了 64 个进程，再配 worker_connections 4096，理论最大连接数达 26 万，但实际内存开销可能超 8GB（仅连接结构体+默认缓冲就占 30–50KB/连接）。
建议：
- CPU 核心数 ≥ 16 时，显式设
worker_processes 8或12，避免进程过多导致上下文切换开销和内存碎片 -
worker_connections按单机预期并发连接峰值 × 1.2 设置，例如单机承载 3 万活跃长连接，设为32768即可，不必盲目拉到 65536 - 必须启用
multi_accept on和use epoll，确保单次事件循环尽可能多收连接，减少唤醒次数
upstream 连接池必须显式管控
默认情况下，Nginx 与后端建立的是“每请求一连接”的短连接模式，百亿请求意味着百亿次 TCP 握手 + TIME_WAIT 堆积，既耗内核资源，也放大内存压力（每个连接至少占用 4–8KB 内核 socket 缓冲 + 用户态 proxy buffer）。
正确做法：
- 在
upstream块中启用长连接池：keepalive 200;（建议值 100–300，视后端吞吐能力调整） -
server块中强制使用 HTTP/1.1 并清理 connection 头：proxy_http_version 1.1; proxy_set_header Connection "";
- 配合后端 keepalive timeout（如 Tomcat 的
connectionTimeout=60000），将proxy_read_timeout 55s，避免 Nginx 主动断连引发后端连接泄漏
缓冲区不能“一刀切”，要分层收缩
默认 client_body_buffer_size 8k、proxy_buffer_size 4k 看似小，但在百亿请求场景下，若 10 万并发各持有一个未刷新的 4KB 缓冲，仅此一项就吃掉 400MB。更危险的是 large_client_header_buffers 4 8k —— 恶意构造超长 header 可瞬间触发大量内存分配。
建议收紧：
-
client_header_buffer_size 1k;（普通域名+基础 UA 完全够用） -
large_client_header_buffers 2 2k;（限制 header 总量 ≤ 4KB，防攻击） -
client_body_buffer_size 512k;（仅对需上传的 location 单独提升，根 location 保持128k） -
proxy_buffers 8 16k; proxy_buffer_size 4k;（响应体缓冲按后端平均响应大小 × 1.5 设，避免频繁 flush）
日志与模块：关掉一切非必需的内存消耗点
access log 默认每行写入都触发 libc 缓冲+系统调用，高并发下日志缓冲区本身就会占几十 MB；gzip 若开启但没配 gzip_min_length，小响应也被压缩，徒增 CPU 和临时 buffer 开销。
务必检查：
- 生产环境禁用
access_log，或改用buffer=64k flush=1s异步刷盘 - 关闭未使用的模块（如
ngx_http_autoindex_module、ngx_http_geo_module），编译时用--without-http_autoindex_module精简 -
gzip_min_length 1024;，且只对text/css application/javascript application/json等明确受益类型开启
不复杂但容易忽略。
