最直接可靠的方式是查/proc/[pid]/fd目录，它实时映射内核中进程实际分配的每个文件描述符，不依赖权限、不靠估算，也不受lsof权限限制影响。
最直接、最可靠的方式是查 /proc/[pid]/fd 目录——它实时映射内核中该进程实际分配的每个文件描述符，不依赖权限、不靠估算，也不受 lsof 权限限制影响。
查单个 worker 进程的 fd 数量
先获取 worker 进程 PID：
-
pgrep -f "nginx: worker process"（推荐，精准匹配 worker） - 或
ps aux | grep 'nginx: worker'手动确认
再统计其 fd 目录下的数字条目数：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
ls /proc/12345/fd | grep -E '^[0-9]+$' | wc -w（替换 12345 为实际 PID） - 该命令只计纯数字 fd（如 3、7、102），排除
cwd、root等伪条目 - 结果就是当前真实打开的 fd 总数（含 socket、日志文件、临时文件等）
批量查看所有 worker 进程的 fd 使用情况
用一行命令逐个输出每个 worker 的 fd 数：
for pid in $(pgrep -f "nginx: worker process"); do echo "worker $pid: $(ls /proc/$pid/fd | grep -E '^[0-9]+$' | wc -w)"; done- 输出示例：
worker 12881: 1021，便于快速识别哪个 worker 接近上限 - 注意：0、1、2 是标准输入输出错误，始终存在，不算泄漏
对比上限，判断是否存在风险
光看数量不够，必须和该进程允许的最大值比对：
- 查软硬限制：
cat /proc/$(pgrep -f "nginx: master process")/limits | grep "Max open files" - 若某 worker 当前 fd 数 > 90% 的 Max open files（例如限制 65536，已用 > 59000），就存在连接拒绝或 “too many open files” 风险
- 同时检查系统级是否吃紧：
cat /proc/sys/fs/file-nr，第一列接近第三列（file-max）也要预警
为什么不用 lsof 或 /proc/[pid]/status？
它们各有短板：
-
lsof -p PID | wc -l包含表头、空行、eventpoll/inotify 等非业务 fd，容易虚高；非 root 用户还可能因权限漏项 -
cat /proc/[pid]/status | grep FDs中的 FDs 是内核缓存值，不是实时精确数，高并发下易滞后 - 只有
/proc/[pid]/fd是内核实时维护的符号链接集合，每个数字项 = 一个真实分配且未 close 的 fd
