nginx代理websocket时fd泄漏主因是配置失当、后端未close连接及系统资源未调优三者叠加；需重点检查proxy_read_timeout过大、upgrade头透传缺失、proxy_buffering开启及ulimit和内核参数限制。
WebSocket 长连接在 Nginx 代理下出现文件描述符（fd）泄漏，通常不是 Nginx 自身代码级内存/句柄泄漏，而是配置失当 + 后端未正确释放连接 + 系统资源未调优，三者叠加导致 fd 持续累积、耗尽。真凶往往藏在“看似正常”的链路中——Nginx 本身不持有业务连接，但它若错误地提前关闭、重复接管或无法透传状态，就会诱发后端连接堆积；而一旦后端（如 Go/Node.js 服务）因心跳超时未 close、重连不清理旧 conn，fd 就会雪球式增长。
看 Nginx 主进程和 worker 进程的 fd 实际占用
Nginx 的主进程（master）只做管理，真正处理连接的是 worker 进程。泄漏通常发生在 worker 上：
- 先查 worker 进程 PID：
ps aux | grep "nginx: worker" | grep -v grep - 对每个 worker PID 执行：
ls -l /proc/<pid>/fd/ 2>/dev/null | wc -l</pid> - 正常负载下，单个 worker 的 fd 数应在几百到几千之间；若持续稳定在 5000+，尤其接近
ulimit -n值（如 65535），就已进入高风险区 - 注意：不要只看主进程 —— 它的 fd 数恒定很低（几十个），无诊断价值
抓取上游后端连接堆积证据（关键突破口）
Nginx 不会“泄漏”fd，但会把未及时关闭的连接长期挂在 worker 上（尤其 proxy_read_timeout 过长 + 后端卡住时）。此时真正泄漏源是后端服务，而 Nginx 是“放大器”：
- 用
lsof -iTCP -sTCP:ESTABLISHED | grep :8080（替换为你的后端端口）查看 ESTABLISHED 连接数是否远超预期 - 结合
ss -tn state established '( dport = :8080 )' | wc -l验证 - 若连接数持续上涨且不回落，再登录后端机器执行：
lsof -p <backend_pid> | grep socket | wc -l</backend_pid>—— 若该值同步飙升，说明泄漏根因在后端未 close Conn
检查 Nginx 是否因配置缺陷“拖住”连接不放
以下配置失误会让 Nginx 把本该由后端管理的连接“扣留”在自己手里，间接加剧 fd 压力：
-
proxy_read_timeout设为 3600s（1小时）？若后端心跳间隔仅 30s，这个值应设为 90–120s。过大 → Nginx 在后端已断开后仍维持 fd 等待响应 - 漏配
proxy_http_version 1.1或proxy_set_header Connection "upgrade"→ 握手失败，客户端反复重连，大量半开连接堆积在 Nginx 的 listen socket 队列或 TIME_WAIT 中 - 启用
proxy_buffering on（默认）→ Nginx 会缓存后端响应，若后端发送不完整帧或阻塞，worker 可能长期 hold fd 等待更多数据 - 没配
keepalive 32（upstream 内）→ 后端复用连接能力失效，每次请求都新建 TCP 连接，加速 fd 消耗
交叉验证系统级 fd 限制与真实水位
别只信 ulimit，要看内核实际分配能力是否被挤占：
- 查当前系统最大 fd：
sysctl fs.file-max（例如 8388608） - 查 Nginx 所有进程总 fd 占用：
lsof -u www-data | wc -l（假设 Nginx 以 www-data 运行） - 查全系统已用 fd：
cat /proc/sys/fs/file-nr→ 输出三列，重点关注第二列（已分配未释放 fd 数） - 若第二列 > 80% of fs.file-max，且
lsof -u www-data占比超 40%，基本可锁定 Nginx 关联进程（含 worker + 后端）是主要消耗方
