直接修改/etc/systemd/system.conf中defaultlimitnofile=65535:65535并执行sudo systemctl daemon-reload可全局生效，但需重启各服务才能应用新限制，且须确保fs.file-max内核总上限足够，/etc/security/limits.conf对systemd服务无效。
直接改 /etc/systemd/system.conf 的 DefaultLimitNOFILE 行就行
全局生效的最简路径就是编辑 /etc/systemd/system.conf，取消注释并设值。默认该行是注释掉的，且 soft 和 hard 值可能不一致（比如 DefaultLimitNOFILE=1024:524288），但多数服务只认 soft 部分，所以建议显式写成等值形式，避免歧义。
- 用
sudo vi /etc/systemd/system.conf打开文件 - 找到以
#DefaultLimitNOFILE=开头的行，去掉#，改成类似：DefaultLimitNOFILE=65535:65535 - 如果想更保守或适配压测场景，可设为
DefaultLimitNOFILE=1048576:1048576 - 保存退出后，必须立即执行：
sudo systemctl daemon-reload（不是 reload 服务，是重载 systemd 自身配置）
改完不生效？大概率漏了 daemon-reload 或服务没重启
DefaultLimitNOFILE 是 systemd 启动新服务时的默认模板，它不会热更新到已运行的服务进程里。也就是说，改完 conf 文件、执行 daemon-reload 后，旧的 nginx、redis 等进程仍保持原来的限制，必须手动重启它们才生效。
- 验证是否加载成功：
systemctl show --property=DefaultLimitNOFILE应输出你设的值 - 查某个服务当前实际限制：
systemctl show nginx | grep LimitNOFILE（注意不是 ulimit -n） - 确认进程真实上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，这里显示的是 soft:hard 两列数值 - 常见错觉：改完就跑
ulimit -n，结果还是 1024 —— 因为 ulimit 查的是当前 shell 会话，跟 systemd 服务完全无关
别忘了 fs.file-max 这个系统级总池子
单个服务设到 65535 没用，如果内核允许打开的文件总数太小（fs.file-max），多个服务一起开句柄，系统层面先报 Too many open files。
Yuanfang Design System
下载
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
- 查当前值：
cat /proc/sys/fs/file-max - 临时调高：
sudo sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf追加一行fs.file-max = 1048576，再运行sudo sysctl -p - 这个值建议至少是单服务
LimitNOFILE的 2–3 倍，比如你设了 10 个服务各 65535，那fs.file-max至少得 100 万
和 /etc/security/limits.conf 的关系别搞混
/etc/systemd/system.conf 只管 systemd 启动的服务；/etc/security/limits.conf 只管 PAM 登录用户（比如 SSH 登录后手动起的 python app.py）。两者互不覆盖，但容易误判失效原因。
- 如果你用
systemctl start nginx，limits.conf里的* soft nofile完全无效 - 如果你用
ssh user@host登录后直接运行java -jar server.jar，那limits.conf生效，system.conf不生效 - 运维排查时，先确认进程是谁启的：
ps -o pid,ppid,comm -p $(pgrep nginx)，看 parent PID 是不是 systemd（PID 1）
实际修改时最容易被忽略的点是：改了 system.conf 忘记 daemon-reload，或者 reload 了但没重启具体服务。systemd 不会把新 DefaultLimitNOFILE “注入”到正在运行的 service 进程里，它只影响下一次 systemctl start 的行为。
