启动 Nginx 遇 too many open files 错误需协同调整系统级和进程级文件描述符限制：先通过 /proc//limits 确认实际限制，再依启动方式修改 limits.conf 或 systemd unit 文件，并在 nginx.conf 中配置 worker_rlimit_nofile 和 worker_connections。
启动 Nginx 时若遇到 too many open files 错误，本质是系统对单个进程能打开的文件描述符数量做了限制（即 ulimit -n），而 Nginx 在高并发场景下需要大量连接、日志文件、SSL 会话缓存等资源，容易触达默认限制（通常为 1024）。必须从系统级和 Nginx 进程级两个层面协同调整，否则仅改配置无效。
确认当前限制并定位瓶颈
先检查 Nginx 主进程实际生效的 limits：
- 运行
ps -eo pid,comm | grep nginx获取 master 进程 PID - 执行
cat /proc/，查看 Soft Limit 和 Hard Limit/limits | grep "Max open files" - 注意：Nginx worker 进程继承 master 的 limits，但若用 systemd 启动，可能被 unit 文件覆盖，此时需优先看 systemd 配置
永久修改系统级 ulimit（适用于 SysV init 或手动启动）
编辑 /etc/security/limits.conf，添加以下两行（替换 nginx 为实际运行用户，如 www-data 或 nginx）：
nginx soft nofile 65535nginx hard nofile 65535
确保 pam_limits.so 已启用：检查 /etc/pam.d/common-session（Debian/Ubuntu）或 /etc/pam.d/login（CentOS）中是否包含 session required pam_limits.so。修改后需重新登录或重启用户会话才生效。
适配 systemd 启动方式（推荐，现代发行版默认）
若使用 systemctl start nginx，limits.conf 不生效。应直接修改 Nginx 的 systemd unit 文件：
- 执行
sudo systemctl edit nginx（推荐，避免覆盖升级） - 写入：
[Service] LimitNOFILE=65535
保存后运行 sudo systemctl daemon-reload && sudo systemctl restart nginx。验证方式同上，查 /proc/
在 Nginx 配置中合理设置工作参数
ulimit 只是上限，还需让 Nginx 主动使用它：
- 在
nginx.conf的main块中显式设置：worker_rlimit_nofile 65535; - 配合调整
events { use epoll; worker_connections 65535; }（注意：worker_connections ≤ ulimit 值） - 避免盲目设高：若机器内存有限，每个连接约占用几 KB，过高可能导致 OOM；建议按预估并发连接数 × 1.2 设置
不复杂但容易忽略：systemd 场景下只改 limits.conf 是无效的，必须通过 systemd unit 控制；同时 Nginx 配置里的 worker_rlimit_nofile 是触发内核应用新限制的关键开关。
