必须同步调高fs.file-max、nofile软硬限制、LimitNOFILE三处，且ulimit -Sn不能超-ulimit -Hn；limits.conf需配软硬两行并确保pam_limits.so加载；systemd服务须单独设LimitNOFILE；漏任一环节均会报Too many open files。
单靠 ulimit -n 改不了系统最大文件句柄数，它只管当前 shell 子进程；真正生效必须同步调高三个地方：fs.file-max（系统总池）、nofile 软硬限制（用户级单进程上限）、LimitNOFILE（systemd 服务专用），漏一个都会继续报 Too many open files。
为什么 ulimit -n 65535 设置后还是 1024
不是命令输错了，而是软限制被硬限制卡死了。普通用户执行 ulimit -Sn 65535 时，如果 ulimit -Hn 输出是 4096 或更低，该命令会被静默截断——软限永远不能超过硬限。
- 临时验证：先跑
ulimit -Hn，若 ≤ 4096，ulimit -Sn 65535必然无效 - 临时提硬限（仅当前会话）：
sudo ulimit -Hn 65535，但子进程不自动继承新硬限 - 永久生效必须改
/etc/security/limits.conf并重新登录：SSH 断开重连，或图形界面登出再进，不是新开终端窗口 -
/etc/security/limits.conf必须同时写两行，空格分隔（禁用 Tab）：* soft nofile 65535和* hard nofile 65535
/etc/security/limits.conf 配了却没生效的常见原因
写了配置但 ulimit -n 仍是 1024，大概率是 PAM 没加载或顺序被覆盖。
- 检查
/etc/pam.d/common-session（Debian/Ubuntu）或/etc/pam.d/system-auth（RHEL/CentOS），确认有未注释行：session required pam_limits.so - 避免混用通配符和具体用户名：比如
*和www-data同时存在时，PAM 按文件顺序取第一个匹配项，后者可能被前者盖掉 - 验证是否真以目标用户身份运行：
ps -o pid,uid,comm -u $(whoami)，防止误用 root 或其他用户启动进程
systemd 服务的 LimitNOFILE 必须单独设
/etc/security/limits.conf 对 systemctl start 启的服务完全无效，因为 systemd 不走 PAM 登录流程。
- 单个服务生效：编辑其 unit 文件，如
/etc/systemd/system/nginx.service，在[Service]段下加：LimitNOFILE=65535 - 全局生效（影响所有新启 service）：改
/etc/systemd/system.conf，在[Manager]下加：DefaultLimitNOFILE=65535 - 改完必须执行：
sudo systemctl daemon-reload，再sudo systemctl restart nginx - 验证方式：
systemctl show nginx | grep LimitNOFILE或cat /proc/$(pgrep nginx)/limits | grep "Max open files"
fs.file-max 必须同步调高，否则系统总池先耗尽
单个进程开到 65535 没用，如果 /proc/sys/fs/file-max 太小（比如默认 32768），多个进程一起开句柄，系统总池先撑爆，照样报错。
- 查看当前值：
cat /proc/sys/fs/file-max - 临时生效：
sudo sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf追加fs.file-max = 1048576，再运行sudo sysctl -p - 别设太高——超过 200 万可能引发内核内存压力；一般 100 万足够支撑千并发 HTTP 服务
- 顺手检查使用量：
cat /proc/sys/fs/file-nr，输出三列，第三列是file-max，第二列是已用数
最容易被忽略的是：systemd 服务压根不读 limits.conf，而很多人调完 ulimit 就以为万事大吉；还有人只改了软限、忘了硬限，或者改了用户级就跳过 fs.file-max——这四个点任意一个漏掉，Too many open files 就照常报。
