关键在于四层文件描述符限制必须全部对齐：系统fs.file-max、用户limits.conf（含pam启用）、systemd limitnofile及nginx.conf中worker_rlimit_nofile与worker_connections配比，缺一不可；需查进程实际limit值验证，worker_connections应≤worker_rlimit_nofile×0.7并启用open_file_cache。
要让 Nginx 稳定处理千万级小文件，关键不是堆高 worker_connections，而是确保每个 worker 进程能合法拿到足够多的文件描述符（FD），且整条限制链路不中断——系统、用户、服务、Nginx 配置四层必须全部对齐，缺一不可。
先确认真实瓶颈在哪一层
别凭配置文件判断，直接查运行中的进程：
- 查 Nginx worker 实际生效的 FD 上限：
cat /proc/$(pgrep -f "nginx: worker" | head -n1)/limits | grep "Max open files"
输出中 Soft Limit 必须是你设定的目标值（如 131072），否则后续全无效 - 查系统全局上限：
cat /proc/sys/fs/file-max
建议 ≥ 所有 worker 总需求的 2 倍（例如 16 个 worker × 131072 ≈ 209 万 → fs.file-max ≥ 4194304） - 查当前 shell 的 ulimit：
ulimit -n
这个只影响手动启停，不能代表 Nginx 实际继承值
四层限制必须同步放开
Linux 下这四层像节流阀，任一关紧都会卡住：
-
/etc/security/limits.conf：指定运行用户（如 nginx 或 www-data）的软硬限制
示例：nginx soft nofile 131072nginx hard nofile 131072 -
PAM 启用：确保
/etc/pam.d/common-session包含session required pam_limits.so -
systemd 服务限制（主流启动方式）：
执行sudo systemctl edit nginx，写入：[Service]LimitNOFILE=131072 -
Nginx 主配置（在
events和http块之外）：worker_rlimit_nofile 131072;
该值必须 ≤ hard nofile，建议取其 90%
关联参数要合理配比，留足余量
小文件场景下，open/close 频繁、日志刷盘、SSL 缓存、upstream socket 都会额外吃 FD，不能把数字拉满：
-
worker_connections应 ≤worker_rlimit_nofile × 0.7
例如设 131072，则推荐 ≤ 90000 - 启用
open_file_cache减少重复开销：open_file_cache max=65536 inactive=60s;open_file_cache_valid 60s;open_file_cache_min_uses 2; - 避免日志频繁刷盘占用 FD：
加buffer=64k flush=5s到access_log指令中
验证与持续观察
改完必须验证，不是重启就完事：
- 重启后立即检查：
cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files" - 压测时用
ss -s观察timewait是否堆积，高位说明连接回收慢 - 监控
nginx_stub_status中 Active connections 接近worker_connections时，就要回查 FD 是否真的够用
