nginx高并发需调优文件描述符限制：先提升系统ulimit（soft/hard均设65536），再在nginx.conf中配置worker_rlimit_nofile 65536；合理设置worker_processes与worker_connections（建议后者为系统限制的70%～90%），并减少日志、upstream等fd冗余占用。
Nginx 采用多进程模型（一个 master 进程 + 多个 worker 进程），每个 worker 进程独立处理请求，因此系统级的文件描述符（file descriptor，即“句柄”）限制会直接影响并发连接能力。若未合理配置，容易出现 too many open files 错误，导致连接被拒绝。
确认并提升系统级最大打开文件数限制
Linux 系统对每个进程默认限制（如 ulimit -n）通常为 1024，远低于高并发场景需求。需同时调整 soft limit 和 hard limit：
- 临时生效：在启动 Nginx 前执行
ulimit -n 65536（需在 same shell 中运行 nginx） - 永久生效：编辑
/etc/security/limits.conf，添加两行：nginx soft nofile 65536nginx hard nofile 65536
（注意：若用 systemd 启动，还需额外配置 service 文件中的LimitNOFILE=65536） - 验证：用
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"查看 worker 进程实际生效值
在 Nginx 配置中显式设置 worker_rlimit_nofile
该指令用于告诉 master 进程为每个 worker 子进程预设最大可打开文件数，必须 ≤ 系统 ulimit 设置，否则启动失败：
- 在
nginx.conf的全局块（main context）中添加：worker_rlimit_nofile 65536; - 它不改变系统限制，但让 Nginx 主动调用
setrlimit()，避免 worker 启动后才触发限制报错 - 若省略此配置，Nginx 默认继承启动时的 ulimit 值，易因环境差异导致行为不一致
合理设置 worker_processes 和 worker_connections
总并发连接数 ≈ worker_processes × worker_connections，但不能盲目堆高，需匹配硬件与系统资源：
-
worker_processes auto;一般推荐，自动匹配 CPU 核心数；若为 IO 密集型（如静态文件服务），可设为2×CPU核心数 -
worker_connections建议设为系统允许单进程打开文件数的 70%～90%，留出空间给日志、上游连接、临时文件等，例如：events { worker_connections 50000; } - 注意：每个 TCP 连接至少占用 2 个 fd（客户端 socket + 日志文件句柄等），HTTPS 还需 SSL session cache、OCSP stapling 等额外开销
检查并减少不必要的 fd 占用
即使上限调高，若存在泄漏或冗余使用，仍可能耗尽句柄：
- 关闭未使用的日志：注释掉
access_log off;或使用buffer和flush减少写入频率 - 限制 upstream 连接复用：在
upstream块中启用keepalive并设合理池大小，避免频繁建连 - 禁用不需要的模块：如未用 WebDAV、perl、lua 等，编译时剔除，减少内部 fd 管理开销
- 监控实时使用量：用
lsof -p $(pgrep nginx | head -1) | wc -l查看单个 worker 当前打开的 fd 数
