要突破单机并发瓶颈，需使worker_rlimit_nofile、系统ulimit和内核限制形成闭环；否则即使配置高worker_connections，也会因文件描述符不足报Too many open files或502错误。
要真正突破单机并发连接瓶颈，worker_rlimit_nofile 不能单独设置，它必须和系统级 ulimit、内核资源限制形成闭环。否则 Nginx worker 进程最多只能打开 1024 个文件描述符，哪怕配置了很高的 worker_connections，也会在高并发时频繁报 Too many open files 或返回 502 错误。
确认当前系统限制并设为合理值
先查当前生效的软硬限制：
ulimit -Sn # 软限制 ulimit -Hn # 硬限制
默认多为 1024/65535，这对万级并发远远不够。建议目标值统一设为 65535（兼顾兼容性与性能），或更高如 1048576（需内核支持）。
修改方式有两种：
- 临时生效（仅当前会话）：
ulimit -n 65535 - 永久生效（推荐）：编辑
/etc/security/limits.conf，追加（注意用户名或通配符）：* soft nofile 65535<br>* hard nofile 65535
若 Nginx 以特定用户（如www-data或nginx）运行，应明确写该用户，而非用*。
⚠️ 注意：修改后需重新登录或重启 systemd 服务才能使 limits 生效；对 systemd 管理的 Nginx，还需额外配置 service 文件（见下文）。
在 nginx.conf 主块中设置 worker_rlimit_nofile
该指令必须放在 events 块**之外**、全局 main 上下文中（即配置文件最外层）：
user nginx;
worker_processes auto;
worker_rlimit_nofile 65535; # ← 关键：值 ≤ 系统硬限制，建议等于 ulimit -Hn
<p>events {<br />
use epoll;<br />
worker_connections 65535;<br />
}关键点：
- 值不能超过
ulimit -Hn，否则启动时报错或静默降级； - 建议设为和
ulimit -Hn相同，避免负载不均导致某 worker 触达上限； - 它作用于每个 worker 进程，不是全局总数；
- 修改后必须
nginx -s reload或systemctl restart nginx才能生效。
systemd 用户需额外配置 LimitNOFILE
如果 Nginx 由 systemd 管理（绝大多数现代发行版默认如此），/etc/security/limits.conf 的设置可能被忽略——因为 systemd 启动的服务不读取该文件。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
正确做法是覆盖 systemd service 配置：
sudo systemctl edit nginx
填入：
[Service] LimitNOFILE=65535
然后重载并重启：
sudo systemctl daemon-reload sudo systemctl restart nginx
验证是否生效：找一个 worker 进程 PID，执行
cat /proc/<PID>/limits | grep "Max open files"
输出中 Soft Limit 和 Hard Limit 应均为你设定的值（如 65535）。
关联配置：worker_connections 与进程数要匹配
worker_connections 是单个 worker 能处理的最大并发连接数，它受两个硬约束限制：
- 操作系统允许该进程打开的文件数（即
worker_rlimit_nofile）； - 实际可用 CPU 核心数（
worker_processes）。
例如：4 核机器，设 worker_processes 4，worker_rlimit_nofile 65535，则理论最大并发 ≈ 4 × 65535 = 262140。但实际应留余量，worker_connections 可设为 65535（单 worker 满负荷）或保守些设 32768。
别忘了检查：worker_connections × worker_processes ≤ worker_rlimit_nofile × worker_processes —— 这个不等式恒成立，真正瓶颈在于前者不能超过后者中的单进程上限。
