WebRTC引发FreeSWITCH服务中断问题的排查方案咨询

针对你遇到的WebRTC集群（B）单节点周期性出现新呼叫/注册失败、大量CLOSE_WAIT连接堆积，但现有呼叫不受影响的问题，结合TCP集群（A）无此异常的对比，以下是具体排查步骤：

一、定位CLOSE_WAIT连接的核心特征 #

• 用系统命令统计连接详情：

  # 筛选FreeSWITCH相关的CLOSE_WAIT连接
  netstat -anp | grep CLOSE_WAIT | grep freeswitch
  # 或用ss工具更高效过滤WebRTC常用端口（WS/WSS/SIP）
  ss -tp state close-wait '( sport = :5060 or sport = :443 or sport = :8080 )'
  

  重点观察远端IP/端口是否集中在特定坐席端，判断是普遍现象还是个别客户端导致的问题。
• 关联FreeSWITCH日志：搜索上述远端IP对应的SIP注册、呼叫日志，检查连接断开时是否存在异常（如客户端未发送SIP BYE、WebSocket Close帧，或服务器端未收到断开信号）。
• 核对SIP/WebSocket超时配置：检查FreeSWITCH SIP profile中的session-timeout、ws-keep-alive、ws-keep-alive-interval参数，确认超时机制是否正常生效，避免服务器端长期持有无效连接。

二、排查文件描述符与TCP资源耗尽问题 #

• 监控文件描述符使用：问题发生前后执行lsof -p <freeswitch_pid> | wc -l，对比系统文件描述符上限（ulimit -n）。CLOSE_WAIT状态的连接会占用文件描述符，耗尽后将无法建立新连接（与你观察到的新呼叫/注册失败症状匹配）。
• 临时优化系统TCP参数（缓解症状，需配合应用层修复）：
  修改/etc/sysctl.conf添加以下配置：

  net.ipv4.tcp_fin_timeout = 30
  net.ipv4.tcp_max_tw_buckets = 5000
  net.ipv4.tcp_tw_reuse = 1
  net.ipv4.tcp_keepalive_time = 600
  net.ipv4.tcp_keepalive_probes = 3
  net.ipv4.tcp_keepalive_intvl = 10
  

  执行sysctl -p生效，加速无效连接的回收。

三、验证jsSIP客户端与服务器的交互异常 #

• 收集坐席端jsSIP日志：重点检查客户端断开（如网络波动、进程崩溃、页面关闭）时是否正常发送WebSocket Close帧或SIP注销消息，判断是否因客户端异常断开导致服务器端连接未被释放。
• 核对jsSIP配置：检查register参数中的expires值是否合理，避免注册超时后未触发重注册逻辑；验证客户端是否开启了WebSocket心跳机制，确保服务器能及时检测到无效连接。
• 模拟异常场景：手动断开坐席端网络、强杀jsSIP进程，观察FreeSWITCH是否能在超时后自动释放对应的连接资源。

四、FreeSWITCH模块与配置深度排查 #

• 检查WebRTC相关SIP Profile配置：
  确认conf/sip_profiles/external.xml（或对应WebRTC profile）中的WebSocket参数配置正确：

  <param name="ws-binding" value="0.0.0.0:8080"/>
  <param name="wss-binding" value="0.0.0.0:443"/>
  <param name="ws-keep-alive" value="true"/>
  <param name="ws-keep-alive-interval" value="30"/>
  <param name="session-timeout" value="120"/>
  

• 启用详细日志：问题发生前执行fs_cli -x "loglevel 7"，收集freeswitch.log中的WebSocket、SIP信令日志，重点排查ERROR、WARNING级别的报错，尤其是连接释放阶段的异常信息。
• 排查第三方模块冲突：如果加载了自定义业务模块或非官方媒体模块，尝试临时禁用，验证是否因模块干扰导致连接资源泄漏。

五、版本升级验证 #

• FreeSWITCH 1.10.9存在已知的WebSocket连接管理bug，建议升级到1.10.x分支的最新稳定版（如1.10.10及以上），或测试1.11.x版本，验证是否已修复CLOSE_WAIT连接泄漏问题。
• 同步升级jsSIP到最新稳定版，排除客户端与服务器端的协议交互兼容性问题。

六、长期监控与预警 #

• 编写定时监控脚本：定期检查CLOSE_WAIT连接数，当超过阈值（如500）时触发告警，并自动收集当前的FreeSWITCH日志、进程状态、网络连接信息，便于快速定位根因。
• 建立指标基线：监控FreeSWITCH的文件描述符使用量、注册数、会话数等核心指标，对比正常状态与异常状态的差异，提前发现潜在问题。

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