/etc/security/limits.d/*.conf 按文件名 ASCII 升序加载，后加载者覆盖同名用户/组的同一限制项；建议用数字前缀（如 01-nginx.conf）统一控制顺序，避免因命名导致加载顺序异常。
在 Linux 系统中，/etc/security/limits.d/*.conf 文件的加载顺序和优先级，直接影响 Nginx 启动后实际生效的资源限制（如 nofile、nproc），尤其当多个配置文件存在冲突时，容易导致 ulimit 值未按预期提升，引发 Nginx 报错“too many open files”或连接拒绝。
limits.d/ 下配置文件按字母序加载，后加载者覆盖前者
系统先读取 /etc/security/limits.conf，再按**文件名 ASCII 升序**依次加载 /etc/security/limits.d/*.conf 中所有以 .conf 结尾的文件（例如：01-nginx.conf → 10-default.conf → 99-override.conf）。同名用户/组的同一项限制（如 nginx soft nofile），后加载的配置会完全覆盖前面的值，不合并、不累加。
- 若
limits.d/20-app.conf设nginx hard nofile 65535，而limits.d/90-nginx.conf设nginx hard nofile 1000000，则最终生效的是1000000 - 文件名含非数字前缀（如
nginx.conf）会排在01-*.conf之前，因其 ASCII 值更小；建议统一用数字前缀控制顺序 - 空格、点号、连字符均参与排序：
a.confaa.conf ab.conf
Nginx 进程是否真正应用了 limits 配置？关键看启动方式
limits 设置仅对**新创建的登录会话或 PAM-aware 进程**生效。Nginx 若以 systemd 方式启动，默认不经过 PAM limits 模块，limits.d/ 配置可能被忽略。
- 确认
/etc/pam.d/system-auth或/etc/pam.d/common-session（取决于发行版）包含：session required pam_limits.so - systemd 服务需显式启用 PAM：检查
/usr/lib/systemd/system/nginx.service或/etc/systemd/system/nginx.service是否有：PAMName=login或LimitNOFILE=直接设置（后者优先级更高） - 若使用
systemctl start nginx，应重载 systemd 配置：sudo systemctl daemon-reload，再重启服务
验证 Nginx 实际运行时的 ulimit 值
不能只看 ulimit -a 在当前 shell 的输出，必须查 Nginx worker 进程本身的限制。
- 获取任一 worker 进程 PID：
ps -eo pid,comm | grep 'nginx: worker' - 查看该进程的 limits：
cat /proc/<PID>/limits | grep "Max open files" - 对比输出中的
Soft Limit和Hard Limit是否与预期一致 - 若仍为 1024，说明 PAM limits 未生效，或 systemd 服务定义中
LimitNOFILE覆盖了 limits.d 配置
推荐 Nginx 专用配置实践
为避免混淆，建议将 Nginx 专属限制集中管理，并与 systemd 机制协同。
- 新建
/etc/security/limits.d/50-nginx.conf，内容明确限定用户：nginx soft nofile 1048576nginx hard nofile 1048576 - 在
nginx.service中补充：[Service]LimitNOFILE=1048576
（此方式绕过 PAM，更可靠，且 systemd 会自动传递给所有子进程） - 同时确保
nginx.conf中设置了worker_rlimit_nofile 1048576，使 Nginx 主进程主动调用setrlimit()
