pam模块未加载或systemd绕过是nginx文件句柄限制失效的主因；需验证pam_limits.so是否在对应pam配置中启用、limits.conf匹配顺序是否正确，并为systemd服务单独配置limitnofile，最终以/proc/pid/limits中soft limit值为准。
Linux系统中PAM模块配置失效，是Nginx文件句柄限制长期不生效的隐蔽主因。它不会报错，也不会提示，只是让/etc/security/limits.conf形同虚设——你改了、重登了、ulimit -n也显示正常，但Nginx worker进程实际打开数仍卡在1024或4096。
确认PAM limits模块是否真正加载
PAM必须主动加载pam_limits.so，否则limits.conf完全被忽略。不能只看文件是否存在，要验证是否被调用：
- 检查
/etc/pam.d/common-session（Debian/Ubuntu系）是否有未注释行：session required pam_limits.so - 检查
/etc/pam.d/system-auth（RHEL/CentOS/Fedora系）同样位置，该文件优先级更高，若存在同名session行且顺序靠前，可能覆盖common-session - 若使用SSH登录，还需确认
/etc/pam.d/sshd是否包含session optional pam_limits.so或继承自其他配置 - 修改后无需重启PAM服务，但必须**全新登录会话**：关闭所有终端、重新SSH连接，或图形界面完全登出再登入
排查PAM匹配逻辑错误
limits.conf按**从上到下第一匹配原则**生效，通配符*和具体用户名（如nginx）共存时极易误覆盖：
- 例如文件中先有
* soft nofile 1024，后面又有nginx soft nofile 65536——Nginx用户仍被*匹配，软限永远是1024 - 应删除或注释掉全局
*规则，仅保留明确用户行：nginx soft nofile 65536nginx hard nofile 65536 - 验证当前用户实际生效值：
sudo -u nginx bash -c 'ulimit -Sn'—— 这比ulimit -n更真实，模拟Nginx启动环境
区分PAM路径与systemd服务绕过行为
Nginx若由systemctl start nginx启动，则**完全不走PAM登录流程**，limits.conf对其无效：
- 此时即使PAM配置完美，
ulimit -n查的是你的登录shell限制，不是Nginx进程的真实限制 - 必须通过systemd单独设限：
创建/etc/systemd/system/nginx.service.d/override.conf，写入：[Service]LimitNOFILE=65536 - 执行
sudo systemctl daemon-reload && sudo systemctl restart nginx后，用cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"直接查worker进程实际值
验证是否真正落地到Nginx worker进程
最终判断标准不是配置文件或命令输出，而是运行中worker进程的/proc接口：
- 获取任一worker PID：
pgrep -f "nginx: worker" - 查看其实际限制：
cat /proc/PID/limits | grep "Max open files"（替换PID） - 输出中
Soft Limit值必须等于你设定的worker_rlimit_nofile值，且≤系统为nginx用户设置的hard nofile - 若仍为1024，说明PAM未生效或systemd未正确加载LimitNOFILE，需回溯前两步
