ulimit -n 临时设置仅作用于当前shell会话及子进程，退出即失效；需通过/etc/security/limits.conf（配软硬限+PAM启用+重新登录）或systemd服务单独配置LimitNOFILE并重载生效。
临时执行 ulimit -n 65536 看似生效，但服务一重启或换终端就退回 1024，根本不是命令写错了，而是没搞清它只作用于当前 shell 及其子进程——它不改系统、不改用户、更不进 systemd 的配置体系。
临时修改：快但极有限制
仅对当前终端会话及其启动的进程有效，退出即失效。非 root 用户无法突破当前硬限制（ulimit -Hn 查），强行设高会静默失败。
- 查看当前软/硬限制：
ulimit -n（软限）、ulimit -Hn（硬限） - 临时提硬限需 root：
sudo sh -c "ulimit -Hn 65536; exec bash"（注意：仅该 shell 生效） -
su - user不等于重新登录，PAM session 不完整，limits 很可能不加载
/etc/security/limits.conf 配置必须满足的三个前提
写了 ≠ 生效。这个文件靠 PAM 加载，且只在完整登录流程中触发（如 SSH 登录、图形界面登录），不是“全局配置文件”。
- PAM 模块必须启用：检查
/etc/pam.d/common-session（Debian/Ubuntu）或/etc/pam.d/system-auth（RHEL/CentOS）中存在session required pam_limits.so - 软硬限制必须成对写全：
username soft nofile 65536和username hard nofile 65536缺一不可；*不覆盖 root，root 必须单独配 - 必须重新登录：SSH 断开重连、console 重新登录；
sudo -u user cmd或systemctl start完全绕过此机制
systemd 服务必须单独设 LimitNOFILE
从 systemd v219 起，默认忽略 limits.conf。nginx、redis、java 应用等只要由 systemctl 启动，就完全不受该文件影响。
- 编辑服务 unit：
sudo systemctl edit nginx.service，在[Service]下添加：LimitNOFILE=65536 - 若需区分软硬限（部分版本支持）：
LimitNOFILESoft=65536+LimitNOFILEHard=65536 - 改完必做两步：
sudo systemctl daemon-reload→sudo systemctl restart nginx
验证是否真正生效，别只看 ulimit -n
查当前 shell 的输出毫无意义。要确认目标进程实际拿到的限制，得直接读它的 /proc 视图。
- 查进程 PID：
pgrep -f "your-app"或ps aux | grep your-app - 查真实限制：
cat /proc/PID/limits | grep "Max open files"，输出应为类似65536 65536 files - 顺手看看系统总上限：
cat /proc/sys/fs/file-max，若它远低于单进程设置，整体仍会瓶颈
