Jitsi Meet 是一套开源视频会议系统，适合团队会议、在线教学、远程面试和客户沟通。它不要求参会者安装账号系统，浏览器打开链接即可进入会议，也可以通过认证限制只有内部成员能创建房间。
本文使用官方 docker-jitsi-meet 稳定版在 Ubuntu VPS 上部署 Jitsi Meet，覆盖服务器配置、域名 HTTPS、10000/UDP 媒体端口、房间认证、TURN、备份、升级和常见故障排查。2026 年 9 月 1 日的官方最新稳定版为 stable-11146-2。
| 场景 | 是否适合 | 说明 |
|---|---|---|
| 小团队内部会议 | 适合 | 可限制只有认证用户创建房间 |
| 在线课程、公开分享 | 适合 | 支持等候室、举手、聊天和屏幕共享 |
| 客户远程沟通 | 适合 | 使用域名即可加入，不强制安装客户端 |
| 大规模直播 | 不应只用单台 Jitsi | 需要 Jibri、CDN 或专门直播平台 |
| 强合规录制和长期归档 | 需要额外设计 | 录制、存储、权限和保留策略要单独规划 |
Jitsi 的视频流主要由 Jitsi Videobridge 转发。它不是普通网页应用：CPU、内存很重要，但公网带宽、丢包、抖动、UDP 可达性和参会者所在地区往往更直接影响体验。
以下配置是保守起点，不是固定并发保证。开启高清、屏幕共享、录制或大量摄像头后，资源需求会明显增加。
| 使用方式 | 建议配置 | 说明 |
|---|---|---|
| 测试和 2-4 人会议 | 2 核 2GB、30GB SSD | 适合功能验证，不建议长期压满 |
| 小团队日常会议 | 4 核 8GB、50GB+ NVMe | 给 JVB、Jicofo、Prosody 和 Docker 留余量 |
| 多个会议同时进行 | 8 核 16GB 起 | 需要压测上行带宽、丢包和区域延迟 |
| 录制或直播 | 单独规划 Jibri | 浏览器渲染、编码和文件写入消耗较高 |
优先选择：
- 端口速率 1Gbps 或更高、月流量充足的 VPS；
- 距主要参会者较近的机房；
- 公网 IPv4、可开放 UDP、安全组规则清晰；
- CPU 性能稳定，不严重超售；
- 支持快照和控制台救援。
如果仍在 2 核 2GB 和 4 核 8GB 之间选择，可以参考 VPS 配置怎么选。视频会议更应优先保证网络质量和内存余量，而不是只看硬盘大小。
准备以下内容：
- 全新的 Ubuntu 24.04 LTS VPS；
- root 或 sudo SSH 权限；
- 一个域名，例如
meet.example.com； - 可接收证书通知的邮箱；
- 会议用户主要地区和基本并发预估。
添加 DNS A 记录：
meet.example.com A 203.0.113.10
确认域名和公网 IP：
dig +short meet.example.com A
curl -4 ifconfig.me
两个结果应一致。如果 VPS 还没有配置 IPv6，不要添加指向错误地址的 AAAA 记录。
Jitsi 官方 Docker 文档要求开放：
| 端口 | 协议 | 用途 |
|---|---|---|
| 22 | TCP | SSH 管理 |
| 80 | TCP | HTTP 跳转和证书验证 |
| 443 | TCP | HTTPS、WebSocket 和网页访问 |
| 10000 | UDP | Jitsi Videobridge 音视频媒体 |
使用 UFW 时先放行 SSH，再启用防火墙：
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw enable
sudo ufw status numbered
还要在云厂商安全组中配置相同规则。只改 UFW 或只改安全组都不够。操作前可先阅读 UFW 导致 SSH 失联的恢复方法，避免把当前 SSH 会话锁在外面。
10000/UDP 是最容易漏掉的端口。网页能打开但多人会议没有声音、画面卡住或几秒后断开，通常先检查它。
更新系统并安装 Docker、Compose、解压工具：
sudo apt update
sudo apt upgrade -y
sudo apt install -y docker.io docker-compose-v2 unzip curl ca-certificates
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version
如果系统仓库没有 docker-compose-v2，应改用 Docker 官方仓库安装 Compose Plugin，不要退回多年未维护的 Python docker-compose v1。
不要直接克隆 master 用于生产环境。官方说明 master 配合每日 unstable 镜像，生产部署应下载 Release。
本文固定使用 stable-11146-2：
cd /opt
sudo curl -fL https://github.com/jitsi/docker-jitsi-meet/archive/refs/tags/stable-11146-2.zip -o jitsi.zip
sudo unzip jitsi.zip
sudo mv docker-jitsi-meet-stable-11146-2 jitsi-meet
sudo chown -R "$USER":"$USER" /opt/jitsi-meet
cd /opt/jitsi-meet
cp env.example .env
该版本开始使用非 root、只读文件系统容器。配置、持久化数据和运行目录的结构与旧版不同，升级旧实例时不能只替换镜像标签。
生成 Jicofo、JVB、Jigasi 和 Jibri 的内部 XMPP 密码：
cd /opt/jitsi-meet
./gen-passwords.sh
脚本会修改 .env 并保留 .env.bak。这些密码用于组件之间通信，不能留空，也不要手动重复使用同一个密码。
创建 stable-11146 及以后版本要求的目录：
sudo mkdir -p /opt/jitsi-meet-cfg/{web,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri,transcriber}
sudo mkdir -p /opt/jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
sudo mkdir -p /opt/jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}
sudo chmod 777 /opt/jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
sudo chmod 777 /opt/jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}
官方当前容器以 UID/GID 1000 的非特权用户运行，需要写入的 storage 和 tmp 目录必须可写。目录缺失或权限错误时，容器会直接拒绝启动。
编辑 .env：
nano /opt/jitsi-meet/.env
至少修改或添加：
CONFIG=/opt/jitsi-meet-cfg
HTTP_PORT=80
HTTPS_PORT=443
TZ=Asia/Shanghai
PUBLIC_URL=https://meet.example.com
JVB_ADVERTISE_IPS=203.0.113.10
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
[email protected]
LETSENCRYPT_ACME_SERVER=letsencrypt
ENABLE_HTTP_REDIRECT=1
ENABLE_PREJOIN_PAGE=1
ENABLE_LOBBY=1
ENABLE_REQUIRE_DISPLAY_NAME=1
RESTART_POLICY=unless-stopped
JVB_ADVERTISE_IPS 必须填写客户端真正能访问的公网 IP。VPS 位于 NAT 后、拥有多个网卡或迁移 IP 后，这个字段错误会导致信令正常但媒体失败。
不要删除 gen-passwords.sh 生成的密码行。保存后先检查关键变量：
cd /opt/jitsi-meet
grep -E '^(CONFIG|PUBLIC_URL|JVB_ADVERTISE_IPS|HTTP_PORT|HTTPS_PORT|ENABLE_LETSENCRYPT|LETSENCRYPT_DOMAIN)=' .env
不要把完整 .env 输出到工单、截图或公开仓库，因为其中包含内部密码。
拉取镜像并启动：
cd /opt/jitsi-meet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
观察首次启动日志：
sudo docker compose logs -f --tail=100 web prosody jicofo jvb
确认没有持续重启后按 Ctrl+C 退出日志，再测试：
curl -I http://meet.example.com
curl -I https://meet.example.com
sudo ss -lntup | grep -E ':(80|443|10000)\b'
浏览器打开 https://meet.example.com，创建一个随机房间。至少用两个不同网络的设备测试，例如电脑使用宽带、手机关闭 Wi-Fi 使用移动网络。
Jitsi 的连接大致分为两部分：
- 浏览器通过 443/TCP 访问网页、BOSH 或 WebSocket 信令；
- 音视频优先通过 10000/UDP 与 Jitsi Videobridge 通信。
因此首页和房间页面能打开，只能证明 HTTPS 基本正常，不能证明媒体链路正常。排查时运行：
sudo ufw status verbose
sudo ss -lunp | grep ':10000'
sudo docker compose logs --tail=200 jvb
还要确认云安全组、宿主机防火墙、运营商 UDP 策略和 JVB_ADVERTISE_IPS。Cloudflare 普通代理不会转发 Jitsi 的 10000/UDP 媒体流量。
最简单稳定的方案是将 meet.example.com 保持 DNS Only，让 HTTPS 和 UDP 都直接到 VPS。首次签发证书时也建议使用 DNS Only，减少 ACME 验证变量。
Cloudflare 橙云可以代理网页和 WebSocket，但不会代替 JVB 的 UDP 媒体转发，也不能隐藏媒体服务器源站 IP。错误地认为“开了橙云就不需要开放 10000/UDP”，会造成能进房间却无法正常通话。
如果确实要代理 Web 层，应单独验证：
/xmpp-websocketWebSocket 是否正常；- 浏览器拿到的 JVB Candidate 是否为正确公网 IP；
- 10000/UDP 是否直接可达；
- HTTPS 模式是否为 Full (strict)，而不是 Flexible。
默认匿名部署允许任何访问者创建房间，公开到互联网后可能被滥用。小团队可以启用 Docker 配置中现有的内部认证：
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal
应用配置：
cd /opt/jitsi-meet
sudo docker compose up -d
创建主持人账号：
sudo docker compose exec prosody \
prosodyctl --config /config/prosody.cfg.lua \
register host meet.jitsi 'replace-with-a-strong-password'
启用后，认证用户负责创建房间，访客可以在主持人允许后加入。用一个无痕浏览器和一个普通浏览器分别测试主持人与访客流程。
内部认证适合少量固定主持人。需要企业 SSO、细粒度权限或由业务系统签发会议身份时，应使用 JWT/OIDC 方案。官方已将旧式手工 Secure Domain 流程标记为弃用，新系统不要照搬过时的 Prosody 配置教程。
部分公司网络、酒店 Wi-Fi 和严格防火墙会阻断 UDP 或点对点连接。此时可以部署 Coturn，让一对一连接在无法直连时通过 TURN 中继。
Jitsi 官方 TURN 文档使用：
3478/UDP：普通 TURN；5349/TCP：TLS TURN；- 特别严格的网络可规划 TLS 443，但需要与 Web HTTPS 做 SNI 分流或使用独立服务器。
不要把静态 TURN 用户名和密码直接写进前端配置。浏览器可以看到这些凭据，其他人可能盗用你的中继流量。更稳妥的方案是使用短期凭据，并通过 Prosody 的外部服务模块下发。
TURN 不是 10000/UDP 的替代品，也不能把一台低带宽 VPS 变成高并发会议平台。它主要解决受限网络下的连接兜底，并会增加服务器出口流量。
服务端录制与直播使用 Jibri。Jibri 会启动浏览器、渲染会议、采集音视频并编码，资源消耗明显高于基础 Jitsi 组件。
不要在 2 核 2GB 的会议主机上直接启用 Jibri。生产环境应为录制单独准备主机或至少预留独立 CPU、内存和磁盘，并规划：
- 录制文件保存目录和容量；
- 用户是否被明确告知正在录制；
- 文件访问权限与保留周期；
- 上传对象存储失败时的本地积压；
- 多场会议同时录制的并发限制。
只需要个人临时保存时，可先评估浏览器本地录制，而不是立即部署完整 Jibri。
基础 Jitsi 不会像数据库应用一样保存每次会议内容，但以下文件决定能否快速重建：
/opt/jitsi-meet/.env
/opt/jitsi-meet/docker-compose.yml
/opt/jitsi-meet-cfg/
备份前记录当前版本和容器状态：
cd /opt/jitsi-meet
grep -m1 -o 'stable-[0-9-]*' docker-compose.yml
sudo docker compose ps
cd /
sudo tar \
--exclude='opt/jitsi-meet-cfg/tmp' \
-czf /root/jitsi-backup-$(date +%F).tar.gz \
opt/jitsi-meet/.env \
opt/jitsi-meet/docker-compose.yml \
opt/jitsi-meet-cfg
将备份复制到对象存储或另一台服务器，不要只留在同一块系统盘。.env 含密码，备份文件需要加密并限制权限。可以结合 VPS 备份恢复演练教程验证恢复流程。
官方建议重新下载最新 Release，而不是把生产目录切到 master。更新前先创建 VPS 快照和配置备份，然后阅读 Release Notes。
从 stable-11146 开始，容器改为非 root 和只读文件系统，并新增 storage、tmp 目录。旧版升级时必须先按官方文档创建和授权这些目录。
常规更新流程：
- 下载并解压新 Release 到新目录；
- 对比新旧
env.example和 Compose 文件； - 复制现有
.env，补充新版本需要的变量； - 保留
/opt/jitsi-meet-cfg持久化目录； - 拉取新镜像并执行
docker compose up -d； - 用两个外部网络重新测试音视频。
不要仅执行 docker compose pull 就认为完成跨版本升级，因为 Compose 结构、目录和环境变量也可能变化。
cd /opt/jitsi-meet
sudo docker compose ps
sudo docker compose logs --tail=200 web prosody jicofo jvb
stable-11146 以后优先检查 storage、tmp 目录是否存在且 UID 1000 可写，其次检查内部密码是否为空。
dig +short meet.example.com A
sudo ss -lntp | grep -E ':(80|443)\b'
sudo docker compose logs --tail=200 web
检查 DNS、错误 AAAA 记录、80/443 安全组、Cloudflare 代理和证书申请频率。反复删除 /opt/jitsi-meet-cfg/storage/web 会丢失已有证书，并可能触发 ACME 限制。
一对一可能使用 P2P，加入第三人后会切换到 JVB。重点检查 10000/UDP、JVB 日志、JVB_ADVERTISE_IPS 和云安全组。
检查 Prosody、Jicofo 和 WebSocket：
sudo docker compose logs --since=10m prosody jicofo web
curl -I https://meet.example.com/xmpp-websocket
反向代理或 CDN 必须支持 WebSocket Upgrade。时间不同步也可能影响认证和证书，使用 timedatectl status 检查 NTP。
自签名证书和 HTTP 页面不满足浏览器安全上下文要求。必须使用有效 HTTPS，并确认手机访问的域名与证书一致。Jitsi 官方也明确说明移动应用不能使用默认自签名证书。
先区分服务器资源和网络问题：
docker stats --no-stream
free -h
df -h
sudo ss -s
sudo docker compose logs --since=10m jvb
观察 VPS 出口带宽、丢包、CPU Steal、客户端地区和 UDP 可达性。单纯增加内存不能修复跨洲高延迟或高峰期线路拥堵。
- 使用官方稳定 Release，不使用
master和unstable -
PUBLIC_URL与真实 HTTPS 域名一致 -
JVB_ADVERTISE_IPS是正确公网 IP - 80/TCP、443/TCP、10000/UDP 在安全组和 UFW 都已开放
- Let's Encrypt 证书有效，HTTP 自动跳转 HTTPS
- 两个不同网络的设备已完成音视频与屏幕共享测试
- 陌生人不能随意创建或滥用会议房间
-
.env和配置目录已加密异地备份 - 升级前有快照，并记录当前稳定版本
- 需要受限网络兼容时已测试 TURN，而不是只确认端口开放
Jitsi Meet 部署成功的判断标准不是“首页能打开”，而是外部网络能通过正确的 HTTPS、WebSocket 和 UDP 媒体链路完成多人会议。先把 PUBLIC_URL、JVB_ADVERTISE_IPS、10000/UDP 和房间创建权限做对，再考虑录制、直播、SSO 和多 Videobridge 扩展。