这个问题我之前帮好几个开发者处理过——临时敲ulimit -n 8192确实能立刻消除警告，但重启系统或者新开终端后就会打回原形，所以得做永久生效的配置，我给你几个靠谱的方案，按需选择就行：

方案1：针对当前用户持久化配置 #

如果只是想让当前登录用户的会话生效（比如你用普通用户跑Caddy），可以修改shell的配置文件：

• 如果你用的是bash，编辑~/.bashrc或者~/.profile文件，在末尾添加一行：

  ulimit -n 8192
  

• 如果你用的是zsh，编辑~/.zshrc文件，同样添加上面那行。

保存后，执行source ~/.bashrc（对应你的shell配置文件）让配置立刻生效，或者重新登录系统也可以。

方案2：全局系统级配置（影响所有用户和进程） #

如果想让整个系统的所有进程都用上更高的文件描述符限制，修改系统的limits配置：

1. 编辑/etc/security/limits.conf文件，在末尾添加两行：

   * soft nofile 8192
   * hard nofile 8192
   

   • soft是警告阈值，当进程使用的文件描述符接近这个数时会收到警告；
   • hard是绝对上限，进程无法超过这个值。
2. 确保/etc/pam.d/common-session文件中有这一行（没有的话加上）：

   session required pam_limits.so
   

3. 重启系统，配置就会全局生效。

方案3：单独给Caddy服务配置（推荐） #

如果你的Caddy是用systemd管理的（现在绝大多数Linux发行版都是这种方式），更推荐只给Caddy进程单独配置，不影响其他进程：

1. 编辑Caddy的systemd服务文件，通常路径是/etc/systemd/system/caddy.service或者/lib/systemd/system/caddy.service；
2. 在[Service]段落里添加一行：

   LimitNOFILE=8192
   

3. 重新加载systemd配置并重启Caddy：

   systemctl daemon-reload
   systemctl restart caddy
   

验证配置是否生效 #

• 查看当前用户的限制：执行ulimit -n，应该返回8192；
• 查看Caddy进程的实际限制：执行cat /proc/$(pidof caddy)/limits，找到Max open files那一行，确认值是8192。

内容的提问来源于stack exchange，提问作者Chris