Node.js WebSocket连接超1.4万时客户端SocketException原因排查求助

针对你遇到的WebSocket连接数达到1.4万后新连接被主动拒绝的问题，结合你已经排除端口数量限制的前提，我整理了几个关键排查方向，帮你定位问题根源：

• 检查进程文件描述符（FD）上限
  每个WebSocket连接都会占用一个文件描述符，而操作系统对单个进程能打开的FD数量有默认限制（比如Linux默认通常是1024或4096，Windows的进程句柄默认上限也远低于1.4万）。当进程耗尽FD时，内核会直接拒绝新的连接请求，恰好会表现为你看到的"主动拒绝"错误。

  • Linux下可以用ulimit -n查看当前会话的FD上限，用cat /proc/<你的Node.js进程PID>/limits查看目标进程的具体限制；
  • Windows下打开任务管理器→切换到"详细信息"标签→右键你的Node.js进程→选择"属性"，查看"句柄计数"，再对比系统的进程句柄上限（可通过组策略或注册表调整）。
    你需要确认Node.js进程的FD/句柄上限是否足够支撑1.5万+连接，必要时调整系统和进程的限制值。

• 核查Node.js自身的连接配置
  Node.js有几个关键参数会影响最大并发连接能力：

  • 启动Node.js时，可通过--max-open-files参数设置进程允许打开的最大文件数，确保这个值高于你的目标连接数；
  • 检查WebSocket服务器创建时的backlog参数（比如http.createServer({ backlog: 1024 })），backlog是TCP监听队列的长度，当新连接请求的数量超过队列长度时，内核会直接拒绝后续连接。默认值可能偏小，可尝试调大到1024或2048试试。

• 检查操作系统TCP内核参数
  操作系统的TCP栈参数可能限制了并发连接的处理能力：

  • Linux下，net.ipv4.tcp_max_syn_backlog控制TCP三次握手阶段的SYN队列长度，net.core.somaxconn限制监听套接字的最大队列长度，这两个值如果设置过小，会导致新连接请求被内核直接拒绝；
  • Windows下，可检查注册表中的TcpMaxSynBackLog项，确保队列长度足够容纳新的连接请求。

• 排查防火墙/安全组的连接限制
  很多本地防火墙（比如iptables、Windows防火墙）或云服务商的安全组会设置单IP/单端口的最大并发连接数限制，当达到阈值后会直接拦截新连接，表现为服务器主动拒绝的错误。你需要检查这些安全规则，确认是否有连接数或速率限制的配置。

• 检查Node.js进程的资源状态
  虽然你提到服务器应该能承载1.5万连接，但还是要确认两个关键点：

  • Node.js进程的内存使用情况：是否存在内存泄漏导致进程资源耗尽，无法处理新连接请求；
  • 事件循环是否阻塞：可以用process.nextTick配合计时检测事件循环延迟，或者用clinic.js这类工具分析，如果事件循环长时间阻塞，服务器无法及时响应新的连接请求，内核会主动拒绝后续连接。

• 验证TIME_WAIT连接占用情况
  虽然你认为端口数量足够，但服务器端大量的TIME_WAIT连接可能占用系统资源，间接导致无法处理新连接。可以用netstat -anp | grep TIME_WAIT（Linux）或netstat -ano | findstr TIME_WAIT（Windows）查看TIME_WAIT连接数，若数量过大，可调整tcp_tw_reuse（Linux）或TcpTimedWaitDelay（Windows）参数来加速连接回收。

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