Nginx 的 65535 为什么没生效：从 limits.conf 查到 systemd

这次给服务器调整文件描述符限制时，我先修改了 limits.conf，却发现 Nginx 进程没有按预期变化。最后真正解决问题的是 systemd 的服务覆盖配置。

文件描述符到底是什么

Linux 用文件描述符表示进程打开的文件、连接等资源。Nginx 接收连接、打开日志和静态文件，都可能使用它。65535 是单个进程的资源上限，不是网站保证能承受的并发人数；CPU、内存、带宽和后端处理能力仍然会限制性能。

为什么改了 limits.conf 还不够

/etc/security/limits.conf 常通过 PAM 为登录会话设置限制。由 systemd 启动的服务有自己的资源限制，不能用当前终端的 ulimit 输出代替 Nginx 进程的实际值。先看服务配置：

systemctl cat nginx
systemctl show nginx -p LimitNOFILE -p LimitNOFILESoft

第一条展示服务单元及覆盖文件，第二条展示 systemd 为服务设置的软、硬限制。软限制是当前生效值，硬限制是允许提高到的边界。

这次实际采用的配置

执行 systemctl edit nginx，在编辑器上方可保存区域写入：

[Service]
LimitNOFILE=65535

保存位置是 /etc/systemd/system/nginx.service.d/override.conf。编辑器里“Lines below this comment will be discarded”以下是参考内容，写在那里会被丢弃。这也是第一次退出时提示临时文件为空的原因。

先检查 Nginx，再选择维护时机重新启动，使新进程继承限制：

nginx -t
systemctl daemon-reload
systemctl restart nginx

daemon-reload 让 systemd 重新读服务定义；restart 会重新创建 Nginx 进程，有短暂影响，不能把它当成每次改网站配置都必须做的动作。普通 Nginx 配置变更通常先检查再 reload。

怎样证明这次生效了

systemctl show nginx -p LimitNOFILE -p LimitNOFILESoft
grep 'Max open files' /proc/$(pgrep -o nginx)/limits

现场两项都显示 65535，主进程的 Max open files 软、硬值也都是 65535。还可以使用 pgrep -a nginx 找出 worker PID，分别检查对应的 /proc/PID/limits，尤其要留意 worker_rlimit_nofile 是否另有设置。

这次记住的是验证方法：配置文件写对、服务加载成功、运行进程实际生效，是三个不同的检查点。以后调整资源限制，我会把这三步一起留下记录。

软件限制与容量规划分开

LimitNOFILE 只是进程可打开资源的上限；worker_connections、worker 数量、上游连接和内存共同影响容量。反向代理请求通常还需上游连接，不能把 nofile 数值直接当在线人数。软硬限制调整后记录进程 PID 与 /proc/PID/limits，worker 也要检查；不要根据一台实验机的数字推导所有服务器的最佳配置。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。