Docker-Jitsi-Meet 部署中反向代理配置问题解析

问题现象

在使用 Docker-Jitsi-Meet 进行部署时，当服务位于反向代理（Reverse Proxy）后方时，用户可能会遇到连接问题。具体表现为：用户能够通过公网域名访问 Jitsi 前端界面并创建会议室，但在尝试加入会议时会出现"已断开连接"的错误提示，无法继续操作。

错误分析

从技术日志中可以观察到以下关键错误信息：

Websocket closed unexcectedly Websocket closed unexcectedly
Firefox ne peut établir de connexion avec le serveur à l'adresse wss://10.99.0.201:8443/xmpp-websocket?room=testsirh

这表明 WebSocket 连接尝试失败，特别是 XMPP over WebSocket (wss) 的连接无法建立。错误指向了内部 IP 地址 10.99.0.201，这明显是一个配置问题。

根本原因

问题的核心在于 PUBLIC_URL 环境变量的配置不当。在反向代理场景下，常见的配置误区包括：

1. 将 PUBLIC_URL 设置为服务器内部 IP 地址而非公网域名
2. 在反向代理和后端服务上同时启用 HTTPS，造成双重加密
3. WebSocket 代理配置不完整或不正确

解决方案

正确的环境变量配置

在 .env 文件中，应将 PUBLIC_URL 设置为公网可访问的域名，而非服务器内部 IP。例如：

# 错误配置
PUBLIC_URL=https://serverip:8443

# 正确配置
PUBLIC_URL=https://jitsi.my-domain.fr

反向代理最佳实践

1. 端口配置：反向代理应代理到 Jitsi 的 HTTP 端口 8000，而非 HTTPS 端口 8443。避免在反向代理和后端都进行 HTTPS 加密。

2. WebSocket 支持：确保反向代理正确配置了 WebSocket 支持。对于 Nginx，需要包含以下配置：

   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "upgrade";
   

3. 证书管理：建议在反向代理处统一管理 SSL 证书，后端服务使用 HTTP。

防火墙配置

确保防火墙允许以下流量：

• 外部到反向代理的 80 (HTTP) 和 443 (HTTPS) 端口
• 反向代理到 Jitsi 服务的 8000 (HTTP) 端口
• 如果需要直接访问，可开放 10000 (JVB) 端口

配置验证

部署后可通过以下方式验证配置是否正确：

1. 检查浏览器开发者工具中的网络请求，确认所有 WebSocket (wss) 连接都指向公网域名而非内部 IP
2. 测试音视频功能是否正常工作
3. 检查各服务日志是否有错误信息

总结

Docker-Jitsi-Meet 在反向代理环境下的部署关键在于正确配置 PUBLIC_URL 环境变量和代理设置。理解服务间的通信流程（特别是 WebSocket 连接）对于排查此类问题至关重要。遵循上述最佳实践可以避免常见的连接问题，确保视频会议服务的稳定运行。

对于初次部署的用户，建议先在不使用反向代理的环境下测试基本功能，然后再逐步添加代理层，这样可以更清晰地定位问题来源。