Nginx 不预测硬件需求，但通过 stub_status 的 Active、Waiting、Reading+Writing 三项指标可反推当前瓶颈：Active 接近上限需查内存；Waiting >90% 表明内存和文件句柄压力大；Reading+Writing 持续偏高则指向网络或磁盘 I/O 瓶颈。
性能容量预估不是靠猜，而是看当前运行状态反推资源余量。Nginx 本身不预测未来负载，但它的实时指标能清楚告诉你：现在哪块快撑不住了——是内存、文件句柄、CPU，还是网络带宽。
盯紧 stub_status 的三个数字
启用 stub_status 后访问 /nginx_status，输出类似：
Active connections: 18423
server accepts handled requests
2456789 2456789 19876542
Reading: 42 Writing: 156 Waiting: 18225
-
Active connections 接近
worker_connections × worker_processes上限时（例如设为 2048×4=8192，却常达 7800+），说明连接池吃紧，优先查内存是否够用——每个空闲 keepalive 连接约占 128KB～256KB -
Waiting 占 Active 比例长期超 90%（如 18225/18423 ≈ 99%），代表大量长连接空闲挂起，I/O 压力低、CPU 几乎不忙，但内存和文件描述符消耗高——这时要调高
worker_rlimit_nofile，并确认系统级ulimit -n是否足够 - Reading + Writing 持续偏高（比如合计常超 500），且响应时间同步上升，往往指向网络带宽打满或磁盘 I/O 拖累（尤其开了 proxy_cache 却没配 SSD 缓存盘）
结合自定义日志定位瓶颈根因
仅看连接数不够，得知道“慢在哪”。在 nginx.conf 中加一段日志格式：
log_format perf '$remote_addr [$time_local] "$request" $status $body_bytes_sent $request_time $upstream_response_time $upstream_cache_status';
- 若
$request_time大、但$upstream_response_time小 → 瓶颈在 Nginx 本体：可能是 SSL 握手慢（单核 CPU 利用率持续 >80%）、Gzip 压缩太重、或正则匹配复杂 → 换更高主频 CPU 更有效 - 若两者都大，且
$upstream_cache_status长期为MISSED→ 缓存失效严重，可能keys_zone内存不足，或后端响应慢 → 加内存比加 CPU 更关键 - 若大量请求
$request_time聚集在 60s 左右整数倍 → 很可能是后端超时或客户端断连，和 Nginx 硬件无关
内存与文件描述符必须核查到位
这是最常被忽略的“隐形瓶颈”：
- 检查系统级限制：
ulimit -n；检查 Nginx 进程实际可用值：cat /proc/$(pgrep nginx)/limits | grep "open files" - 在
/etc/security/limits.conf中为运行用户设硬限制，例如：www-data hard nofile 65535 - Nginx 配置中同步设置：
worker_rlimit_nofile 65535;，并在events块中设worker_connections 20480; - 临时端口范围影响反向代理能力：
sysctl net.ipv4.ip_local_port_range应设为1024 65000，避免高并发下端口耗尽
参考典型硬件配置区间
预估不是拍脑袋，可对照业务规模找基准：
- 中小型网站（1k–5k 并发）：4–8 核 CPU、8–16GB 内存、SSD 存储
- 电商 API 网关（5k–20k 并发）：16–32 核 CPU、32–64GB 内存
- 16 核 32GB 服务器，用于负载均衡场景，实测可稳定支撑 4–6 万并发，前提是文件描述符、内核参数、Nginx worker 分配全部调优到位
