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 中加一段日志格式：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

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 分配全部调优到位