Docker-Jitsi-Meet部署中的WebSocket连接问题分析与解决

问题背景

在私有网络环境下部署Docker-Jitsi-Meet时，用户遇到了两个典型问题：

1. 初始连接时出现"Websocket closed unexpectedly"错误
2. 多人加入会议室后音视频无法正常传输

核心问题分析

WebSocket连接失败

当使用IP地址直接访问时，系统默认配置无法正确处理非域名形式的访问请求。这会导致XMPP通信使用的WebSocket连接异常中断，表现为1001错误码（端点主动关闭连接）。

根本原因在于Prosody（XMPP服务器）的配置中缺少对IP地址形式的域名支持，且浏览器安全策略对非标准域名的WebSocket连接有限制。

ICE协商失败

多人会议中的音视频传输问题通常与NAT穿透失败有关。控制台显示的"ICE failed"错误表明STUN/TURN服务器配置不完整，导致P2P连接无法建立。

解决方案

基础配置修正

1. 在.env配置文件中明确设置：

PUBLIC_URL=https://192.168.142.131/
ENABLE_HTTP_REDIRECT=1

2. 确保所有容器使用相同的网络配置

NAT穿透增强配置

1. 补充STUN服务器配置：

STUN_SERVERS=stun.l.google.com:19302

2. 对于复杂网络环境，建议配置TURN服务器

高级调试建议

1. 检查Docker端口映射是否正确：
   • 确保TCP/4443和UDP/10000端口开放
2. 验证Prosody的虚拟主机配置：

   VirtualHost "192.168.142.131"
        authentication = "anonymous"
        ssl = {
            key = "/config/certs/192.168.142.131.key";
            certificate = "/config/certs/192.168.142.131.crt";
        }
   

实施效果验证

1. 单用户应能正常进入会议室
2. 多用户加入时应能看到彼此视频流
3. 控制台不再出现WebSocket 1001错误和ICE失败提示

技术原理补充

Jitsi-Meet的架构中，WebSocket用于信令传输（XMPP协议），而媒体流则依赖WebRTC。当使用IP地址直接访问时，浏览器会认为这是不安全上下文，需要特殊配置才能允许媒体设备访问和网络连接。

通过正确配置PUBLIC_URL，系统会自动调整以下关键参数：

• XMPP域名验证
• Cookie安全策略
• CORS设置
• WebSocket连接URL

对于企业内网部署，建议额外考虑：

1. 使用自签名证书时的浏览器信任处理
2. 网络设备的UDP流量优化
3. 防火墙对JVB媒体端口的放行