要稳定支撑数万并发，需系统资源、内核参数与Nginx配置三层对齐：调高file-max/somaxconn/ulimit，启用epoll、worker_processes auto、worker_cpu_affinity auto、worker_connections 65535，并优化keepalive、sendfile及后端超时。
要让 Nginx 稳定支撑数万并发（比如 3 万～8 万），关键不是堆高单个参数，而是让系统资源、内核行为和 Nginx 配置三层对齐。很多团队卡在 2 万连接就上不去，问题通常出在系统默认限制或事件调度没调对，而不是 Nginx 本身不行。
系统级资源必须先放开
不改系统限制，Nginx 再怎么配也白搭。以下操作需在宿主机（或容器宿主）执行：
- 编辑 /etc/sysctl.conf，加入并运行 sysctl -p 生效：
fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1 - 编辑 /etc/security/limits.conf，确保 Nginx 启动用户能打开足够多文件：
* soft nofile 1048576
* hard nofile 1048576 - 确认启动环境生效：用 ulimit -n 检查，值应 ≥ 1048576；若用 systemd 启动，还需在 service 文件中加 LimitNOFILE=1048576
Nginx 进程与连接模型要匹配硬件
worker 数量不是越多越好，重点是减少上下文切换和缓存抖动：
- worker_processes auto; —— 推荐自动识别逻辑 CPU 数，比硬写数字更健壮
- worker_cpu_affinity auto; —— Nginx 1.12+ 支持，自动绑定到独立核心，提升 L1/L2 缓存命中率
- worker_rlimit_nofile 1048576; —— 必须 ≥ worker_connections × 安全冗余系数（建议 1.2 倍），否则静默降级
events 块必须启用高性能事件机制
Linux 下不用 epoll，就谈不上真正高并发：
- use epoll; —— 显式声明，避免自动探测失败
- worker_connections 65535; —— 单 worker 并发上限；8 核机器配此值，理论可达 52 万连接，实际数万场景已绰绰有余
- multi_accept on; —— 单次事件循环尽可能多地 accept 新连接，降低延迟
- accept_mutex on; —— 防“惊群”，尤其在连接建立频繁的短连接场景下建议开启
HTTP 层配合连接复用与轻量响应
光接得住连接还不够，得让连接快速流转、不滞留：
- keepalive_timeout 30; 和 keepalive_requests 1000; —— 复用 TCP 连接，减少握手开销
- sendfile on; + tcp_nopush on; —— 启用零拷贝，合并小包发送
- tcp_nodelay on; —— 关闭 Nagle 算法，适合 API 类低延迟场景
- 后端超时务必收紧：proxy_connect_timeout 3s;、proxy_read_timeout 10s;，避免 worker 被慢后端拖住
