要支撑10万并发连接，必须满足三重硬约束：文件描述符上限（ulimit、worker_rlimit_nofile、fs.file-max）、内存水位（https单连接约15–30kb）、连接语义折损（反代场景实际承载仅约3–5万客户端请求），缺一不可。
能，但“10万并发连接”不是默认配置开箱即用的结果，而是经过系统级、内核层、Nginx配置三重对齐后的工程结果。关键不在数字本身，而在是否踩准了三个硬约束：文件描述符上限、内存水位、连接语义折损。
一、系统级前提必须拉满
worker_connections 是单个 worker 进程的连接上限，真实并发能力 = worker_processes × worker_connections。要达到 10 万连接，常见组合是 4 核配 4 个 worker，每个设为 25600；或 8 核配 8 个 worker，每个设为 12800——但这些值毫无意义，除非以下三项全部达标：
- ulimit -n ≥ worker_processes × worker_connections（建议设为 65535 或更高，写入 /etc/security/limits.conf）
- worker_rlimit_nofile 必须显式声明且 ≥ 上述乘积（Nginx 不会自动继承 ulimit，必须在 main 块中配置）
- /proc/sys/fs/file-max ≥ 该乘积 × 1.3～1.5（预留 TIME_WAIT、SSL 缓存、日志句柄等系统开销）
二、内存不是无限的，得算清楚单连接开销
每条连接不是只占几个字节。实际内存占用取决于业务类型：
- 纯 HTTP 转发：约 4–8 KB（含 socket 缓冲 + 结构体）
- HTTPS 反向代理：15–30 KB（含 SSL 会话上下文、OCSP stapling 等）
- 带 Gzip + proxy_buffer 的反代：50 KB 以上
一台 16GB 内存服务器，按 50% 安全水位留 8GB 给 Nginx，再扣掉 1GB 系统保命内存，剩下约 7GB 可用。若走 HTTPS 反代，按均值 20KB/连接算，最多支撑约 35 万连接——理论可行；但若误按 1KB 估算，就会严重高估容量。
三、反向代理场景要打“对折甚至三折”
面试常忽略的关键点：Nginx 做反向代理时，1 个客户端请求 = 2 个连接（client ↔ nginx + nginx ↔ upstream）。所以对外宣称的“10 万并发连接”，实际仅能服务约 5 万客户端请求。
更严苛的情况：
- 后端有重试机制（如超时重试 2 次），连接数可能翻倍
- 上游也用长连接，连接复用率低，实际并发压力更大
- HTTP/2 多路复用虽节省连接，但单连接内存开销更高
因此，生产环境做反代时，建议按 worker_processes × worker_connections ÷ 3～÷ 4 来评估真实客户端承载力。
四、验证比配置更重要
调完参数不等于万事大吉。必须靠运行时指标反推是否真撑得住：
- 访问
/nginx_status，看 Active connections 是否长期 >90% 理论上限 - 执行
ss -s | grep "tcp:"，关注 orphans 数量——大量 orphaned sockets 表示连接异常中断或 TIME_WAIT 回收慢 - 查 error.log 是否频繁出现 accept() failed (24: Too many open files)，这是 fd 耗尽的铁证
- 观察 Waiting / Active 比例：Waiting 长期超 90%，说明大量空闲长连接挂起，需检查 keepalive_timeout 和内存是否充足
