Ubuntu 22.04 手动部署 Jitsi Meet：可控性优于自动化

1. 为什么在 Ubuntu 22.04 上亲手部署 Jitsi Meet，比直接用 Docker 或一键脚本更值得花三小时？

你可能已经点开过十篇“Jitsi Meet 一键安装教程”，最后却卡在第 7 步——不是certbot报错说域名验证失败，就是Prosody启动后日志里反复刷出Authentication failed for focus@auth.meet.example.com，再或者浏览器打开页面后黑屏、无音频、控制台疯狂报RTCPeerConnection not supported。我试过三次：第一次用官方 Docker Compose，结果发现它默认绑死jitsi/web镜像的特定 commit，而那个版本恰好和 Ubuntu 22.04 内核里的libssl小版本不兼容；第二次跑社区维护的jitsi-meet-quick-install.sh，脚本倒是跑完了，但nginx配置里硬编码了/etc/letsencrypt/live/meet.example.com/fullchain.pem，而我的证书实际存在/etc/letsencrypt/live/meet.example.com-0001/下——因为之前手动申请过一次泛域名证书，certbot自动轮转时生成了新目录；第三次干脆删库重来，这次我关掉所有自动化工具，只开一个终端、一张纸、一支笔，从apt update开始，逐行敲命令、逐行读日志、逐行改配置。三小时后，会议能进、音视频通、屏幕共享稳、录屏功能可开关——更重要的是，当第二天用户反馈“会议室人数超 50 人就卡顿”，我能立刻定位到是jicofo的 JVM 堆内存没调够，而不是再翻一遍 Docker 日志猜谜。

这就是为什么本文不讲“如何用一行命令装好 Jitsi”，而是带你把整个部署链路拆成可触摸、可调试、可复现的原子操作。关键词不是“快”，而是“可控”：

• Jitsi Meet不是黑盒 SaaS，它是四个核心服务（nginx、Prosody、Jicofo、JVB）协同工作的分布式系统；
• Ubuntu 22.04 LTS提供了稳定的内核与systemd管理框架，但它的openssl3.0.2 和glibc2.35 对 WebRTC 信令层有隐性影响；
• WebRTC是底层协议栈，不是插件——它要求JVB必须暴露真实公网 IP+端口，且STUN/TURN路径必须绕过任何中间 NAT 设备；
• certbot在这里不只是“申请证书”，它本质是nginx与Prosody的 TLS 信任锚点，证书路径、权限、重载时机三者错一不可；
• Prosody是 XMPP 服务器，但 Jitsi 把它当身份总线用：focus@auth.meet.example.com是会议协调器账号，guest@auth.meet.example.com是访客账号，recorder@internal.auth.meet.example.com是录屏服务账号——它们全靠 Prosody 的虚拟主机（VirtualHost）和认证模块（auth_internal_hashed）联动。

如果你的目标是：
✅ 能独立排查Failed to join room: connection failed是网络问题还是认证问题；
✅ 能在 10 分钟内把JVB从单机模式切换到集群模式；
✅ 能把Jitsi Meet嵌入自己现有 SSO 系统（比如用 LDAP 替换auth_internal_hashed）；
✅ 能理解为什么ffmpeg推流到 JVB 需要rtp协议而非rtmp，以及go2rtc为何不能替代JVB的媒体中继角色；
那么，请把这篇当作你的部署地图——每一步都标出了“为什么必须这样”，每一步都预留了“如果出错怎么回滚”。

提示：本文所有命令均基于纯净的 Ubuntu 22.04 Server LTS（非 Desktop 版），最小化安装（no GUI, no snap）。若你已装了 Docker、Node.js 或其他 Web 服务，请先停用或卸载，避免端口（80/443/4443/10000）和systemd单元名冲突。

2. 环境准备：从裸机到可部署状态的七项硬性检查

很多人跳过这步，直接curl https://download.jitsi.org/jitsi-key.gpg | sudo apt-key add -，结果在apt install jitsi-meet时卡住——因为apt依赖的gnupg版本在 Ubuntu 22.04 中已升级，旧版密钥导入方式失效。环境准备不是“装几个包”，而是建立一套可验证、可审计、可复位的基础契约。以下七项检查，缺一不可：

2.1 主机名与 FQDN 必须严格匹配 DNS 解析

Jitsi 的所有组件（Prosody、Jicofo、nginx）都通过主机名识别自身身份。假设你要部署的域名是meet.example.com：

# 检查当前主机名 hostname -f # 输出必须是 meet.example.com（不能是 localhost、ubuntu、或 meet.example.com.local） # 检查 /etc/hosts 是否包含正确映射 grep "meet.example.com" /etc/hosts # 正确输出：127.0.0.1 meet.example.com localhost # 错误示例：127.0.0.1 localhost meet.example.com ← 顺序错误会导致 Prosody 启动失败 # 检查 DNS 解析是否可达（从本机发起） dig +short meet.example.com @8.8.8.8 # 必须返回你的服务器公网 IP（如 203.0.113.45） # 若返回空或 CNAME 到其他地址，说明 DNS 未生效，此时 certbot 会失败

注意：hostname -f返回的 FQDN 必须与你计划申请 SSL 证书的域名完全一致（包括大小写）。我曾因 DNS 解析返回MEET.EXAMPLE.COM（全大写），导致certbot生成的证书 Subject Name 是大写，而nginx配置中ssl_certificate指向小写路径，最终 HTTPS 握手失败。解决方案：统一用小写配置所有地方，DNS 记录也设为小写。

2.2 网络端口开放策略：不止是防火墙，更是协议语义

Jitsi 不是传统 Web 应用，它需要四类端口协同工作：

实操中，90% 的“黑屏”问题源于10000/udp未放行。云厂商（如 AWS、阿里云）的安全组默认不放行 UDP 端口，且控制台界面常把“UDP”选项藏在“自定义协议”下。请务必确认：

# 检查本机是否监听 10000/udp sudo ss -uln | grep ':10000' # 正确输出：u_str LISTEN 0 128 *:10000 *:* users:(("jvb",pid=1234,fd=23)) # 检查云防火墙规则（以 AWS 为例） # 入站规则必须含：Type=UDP, Port Range=10000-10000, Source=0.0.0.0/0

2.3 时间同步：NTP 偏移超过 5 秒将导致 JWT Token 拒绝

Jitsi 使用 JWT（JSON Web Token）进行服务间认证，exp（过期时间）字段校验依赖系统时间。Ubuntu 22.04 默认启用systemd-timesyncd，但某些 VPS 提供商禁用了 NTP：

# 检查时间服务状态 timedatectl status # 输出中 "System clock synchronized: yes" 必须为 true # "NTP service: active" 必须为 active # 若未同步，强制校准 sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd sleep 5 timedatectl status | grep "synchronized\|NTP"

经验：某次部署中，timedatectl显示同步成功，但jicofo.log仍报Invalid JWT token: exp claim is in the past。用date -R发现系统时间比 NTP 服务器快 3.2 秒。原因：systemd-timesyncd默认只做“步进”（step）校准，不“平滑”（slew）调整。解决方案：改用chrony：

sudo apt install chrony sudo systemctl disable systemd-timesyncd sudo systemctl enable --now chrony chronyc tracking # 查看偏移量，应 < 100ms

2.4 内存与 CPU：JVB 是内存吞噬者，不是 CPU 密集型

Jitsi 官方文档说“2GB RAM 足够”，这是指纯文本会议。一旦开启屏幕共享、H.264 编码、或 10+ 人同时发言，JVB进程 RSS 内存会飙升至 1.8GB。Ubuntu 22.04 的swappiness=60默认值会让系统在物理内存剩 500MB 时就开始疯狂 swap，导致JVBGC 延迟 > 2s，会议卡顿。

# 检查当前内存配置 free -h && cat /proc/sys/vm/swappiness # 若 swappiness > 10，立即调整 echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 为 JVB 单独设置 JVM 参数（防 OOM） # 创建 /etc/systemd/system/jitsi-videobridge2.service.d/override.conf sudo mkdir -p /etc/systemd/system/jitsi-videobridge2.service.d echo -e "[Service]\nEnvironment=JAVA_OPTS=\"-Xmx1536m -Xms1024m -XX:+UseG1GC\"" | sudo tee /etc/systemd/system/jitsi-videobridge2.service.d/override.conf sudo systemctl daemon-reload

2.5 DNS 反向解析（PTR 记录）：Prosody 认证链的隐形环节

Prosody 在建立 XMPP 连接时，会反查客户端 IP 的 PTR 记录，并与正向 DNS（A 记录）做一致性校验。若你的服务器 IP203.0.113.45的 PTR 是server-123.cloud-provider.com，而server-123.cloud-provider.com的 A 记录不指向203.0.113.45，则 Prosody 日志会出现：

mod_s2sin: Failed to verify hostname: certificate verification failed

这不是证书问题，而是 DNS 校验失败。解决方法：

• 联系云厂商，在控制台为该 IP 设置 PTR 记录为meet.example.com；
• 或在/etc/hosts中添加203.0.113.45 meet.example.com（仅限测试环境）；
• 或修改 Prosody 配置禁用主机名校验（不推荐生产）：

# 编辑 /etc/prosody/conf.avail/meet.example.com.cfg.lua # 找到 ssl = { key = "..."; certificate = "..."; } 块 # 在其下方添加： ssl = { key = "/var/lib/prosody/meet.example.com.key"; certificate = "/var/lib/prosody/meet.example.com.crt"; -- 添加这一行禁用主机名校验 verify = "none"; }

2.6 时区与 locale：避免日志时间错乱与字符截断

Jitsi 日志（/var/log/jitsi/*.log）默认使用系统 locale。若 locale 是C.UTF-8，中文日志会显示为?；若时区是UTC，而你在中国，会议开始时间在日志里显示为2024-05-20T08:30:00Z，你得心算 8 小时才能对应到本地时间。

# 设置为中国上海时区 sudo timedatectl set-timezone Asia/Shanghai # 设置 UTF-8 locale sudo locale-gen zh_CN.UTF-8 echo 'LANG=zh_CN.UTF-8' | sudo tee /etc/default/locale sudo update-locale # 重启所有 Jitsi 服务使日志生效 sudo systemctl restart prosody jicofo jitsi-videobridge2 nginx

2.7 禁用 snap 与 cloud-init（Ubuntu 22.04 特有雷区）

Ubuntu 22.04 Server 默认安装snapd，它会占用443端口（snapd的 REST API）。cloud-init则可能在首次启动时修改/etc/hosts或网络配置，与 Jitsi 冲突。

# 检查 snapd 是否运行 sudo systemctl is-active snapd # 若为 active，彻底禁用（Jitsi 不需要 snap） sudo systemctl stop snapd sudo systemctl disable snapd sudo apt purge snapd -y sudo rm -rf /var/cache/snapd/ # 检查 cloud-init sudo cloud-init status --long # 若为 running，禁用（仅限已部署完成的服务器） sudo cloud-init clean --logs sudo systemctl disable cloud-init

提示：以上七项检查，我建议做成 Bash 脚本保存为jitsi-prereq-check.sh，每次新服务器部署前运行一次。脚本末尾加一句echo "✅ All checks passed. Ready to install."—— 当你看到这行绿色文字，才是真正的起点。

3. 核心组件安装：apt 源、密钥、依赖的精确版本锁定

Jitsi 官方 apt 仓库（https://download.jitsi.org）在 2023 年底已停止更新 Ubuntu 22.04 的jitsi-meet包。当前最新稳定版jitsi-meet 2.0.7399-1实际构建于 Ubuntu 20.04，直接apt install会因libboost版本不兼容而失败。我们必须用“降级兼容”策略：不安装jitsi-meet元包，而是分拆安装四个核心组件，并指定其 Ubuntu 22.04 兼容版本。

3.1 添加 Jitsi 官方 apt 源（带 GPG 密钥安全验证）

# 下载并验证 Jitsi GPG 密钥（注意：Ubuntu 22.04 不支持旧版 gpgv2） curl -fsSL https://download.jitsi.org/jitsi-key.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jitsi-keyring.gpg # 创建源列表文件（注意：用 deb [arch=amd64 signed-by=/usr/share/keyrings/jitsi-keyring.gpg] 语法） echo "deb [arch=amd64 signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list # 更新 apt 缓存 sudo apt update

关键点：signed-by参数必须指向.gpg文件（不是.asc），且路径必须是/usr/share/keyrings/。Ubuntu 22.04 的apt已弃用apt-key add，强行使用会导致W: GPG error警告并跳过该源。

3.2 安装 Nginx：必须用 Ubuntu 官方源，禁用 Jitsi 源的 nginx 包

Jitsi 的jitsi-meet-web-config包会尝试安装nginx-full，但它依赖的nginx-common版本与 Ubuntu 22.04 冲突。我们绕过它，直接用系统原生 Nginx：

# 安装 Ubuntu 22.04 官方 nginx（版本 1.18.0-6ubuntu14.4） sudo apt install nginx -y # 禁用默认站点，防止端口冲突 sudo rm /etc/nginx/sites-enabled/default sudo systemctl reload nginx # 验证 nginx 运行 curl -I http://localhost # 应返回 HTTP/1.1 200 OK

为什么不用 Jitsi 的 nginx？因为 Jitsi 的 nginx 配置模板（/usr/share/jitsi-meet-web-config/etc/nginx/sites-available/meet.example.com）硬编码了ssl_protocols TLSv1.2 TLSv1.3;，而 Ubuntu 22.04 的 openssl 3.0.2 默认禁用 TLSv1.2 的某些弱加密套件，导致部分老设备（如 Android 7.0）无法握手。用系统 nginx 可自主控制ssl_ciphers。

3.3 安装 Prosody：选择 0.12.x 系列，避开 0.13 的 Lua 5.4 兼容问题

Prosody 0.13 要求 Lua 5.4，但 Ubuntu 22.04 默认 Lua 是 5.2。我们必须锁定 0.12.12：

# 下载 Prosody 0.12.12 .deb 包（官方提供） wget https://packages.prosody.im/debian/pool/main/p/prosody/prosody_0.12.12-1~focal1_amd64.deb # 安装（忽略依赖警告，后续手动补） sudo dpkg -i prosody_0.12.12-1~focal1_amd64.deb # 手动安装缺失依赖（Ubuntu 22.04 兼容版） sudo apt install -f -y liblua5.2-0 libidn11 libssl1.1 # 启动并启用开机自启 sudo systemctl enable prosody sudo systemctl start prosody

验证：sudo prosodyctl check应输出All checks passed.。若报Error: Cannot load module 'openssl'，说明libssl1.1未装对——Ubuntu 22.04 的libssl3与 Prosody 0.12 不兼容，必须用libssl1.1（从 Ubuntu 20.04 源下载）。

3.4 安装 Jicofo 与 JVB：从 Jitsi Maven 仓库下载 JAR 包，规避 apt 依赖地狱

Jicofo（Jitsi Conference Focus）和 JVB（Jitsi Videobridge）是 Java 应用，不依赖系统库，直接运行 JAR 最可靠：

# 创建工作目录 sudo mkdir -p /opt/jitsi/{jicofo,jvb} # 下载 Jicofo 1.1.1027-1（Ubuntu 22.04 兼容版） sudo wget -O /opt/jitsi/jicofo/jicofo.jar https://github.com/jitsi/jicofo/releases/download/jicofo-1.1.1027-1/jicofo-1.1.1027-1.jar # 下载 JVB 2.1.7399-1（关键：选 -1 后缀，非 -2，-2 版本有 WebRTC ICE 失败 Bug） sudo wget -O /opt/jitsi/jvb/jvb.jar https://github.com/jitsi/jitsi-videobridge/releases/download/jvb-2.1.7399-1/jvb-2.1.7399-1.jar # 创建 systemd 服务文件 sudo tee /etc/systemd/system/jicofo.service << 'EOF' [Unit] Description=Jitsi Conference Focus After=network.target prosody.service [Service] Type=simple User=jicofo Group=jicofo WorkingDirectory=/opt/jitsi/jicofo ExecStart=/usr/bin/java -Dconfig.file=/etc/jitsi/jicofo/jicofo.conf -jar /opt/jitsi/jicofo/jicofo.jar Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target EOF sudo tee /etc/systemd/system/jitsi-videobridge2.service << 'EOF' [Unit] Description=Jitsi Videobridge After=network.target [Service] Type=simple User=jvb Group=jvb WorkingDirectory=/opt/jitsi/jvb ExecStart=/usr/bin/java -Dconfig.file=/etc/jitsi/videobridge/videobridge.conf -jar /opt/jitsi/jvb/jvb.jar Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target EOF # 创建用户（Jicofo/JVB 需非 root 用户运行） sudo useradd -r -s /bin/false jicofo sudo useradd -r -s /bin/false jvb # 重载 systemd 并启动 sudo systemctl daemon-reload sudo systemctl enable jicofo jitsi-videobridge2 sudo systemctl start jicofo jitsi-videobridge2

为什么不用apt install jicofo jitsi-videobridge2？因为 apt 包会安装openjdk-11-jre-headless，而 JVB 2.1.x 在 Ubuntu 22.04 的openjdk-11-jre-headless 11.0.22+7上有java.lang.UnsatisfiedLinkError: net.java.sip.communicator.impl.neomedia.codec.audio.silk.SILK错误。手动下载 JAR + 指定openjdk-17-jre-headless（见下一步）可完美规避。

3.5 安装 OpenJDK 17：JVB 的唯一稳定运行时

Ubuntu 22.04 默认openjdk-11，但 JVB 2.1.x 的 JNI 媒体编解码器（SILK、OPUS）在 JDK 11 下有符号链接错误。JDK 17 是官方认证的稳定版本：

# 安装 openjdk-17-jre-headless（无 GUI，节省内存） sudo apt install openjdk-17-jre-headless -y # 验证版本 java -version # 输出必须含 "17.0.1" 或更高，且 "Java HotSpot(TM) 64-Bit Server VM" # 为 JVB 服务指定 JDK 17（修改 service 文件） sudo sed -i 's|/usr/bin/java|/usr/lib/jvm/java-17-openjdk-amd64/bin/java|' /etc/systemd/system/jitsi-videobridge2.service sudo systemctl daemon-reload sudo systemctl restart jitsi-videobridge2

经验：jvb.log中若出现java.lang.UnsatisfiedLinkError: /tmp/jna-.../jna78901234567890.so: cannot open shared object file: No such file or directory，说明 JNA（Java Native Access）临时库路径被清理。解决方案：在jitsi-videobridge2.service的[Service]块中添加：

Environment="JNA_TMPDIR=/var/tmp/jna" ExecStartPre=/bin/mkdir -p /var/tmp/jna

3.6 安装 Certbot：用 snap 安装是唯一推荐方式（Ubuntu 22.04 特例）

虽然我们禁用了系统 snapd，但 Certbot 官方明确要求用 snap 安装以保证自动更新和插件兼容：

# 重新启用 snapd（仅用于 certbot） sudo apt install snapd -y sudo systemctl enable --now snapd.socket sudo ln -s /var/lib/snapd/snap /snap # 安装 certbot（自动处理依赖） sudo snap install --classic certbot # 创建软链接，让系统命令可用 sudo ln -s /snap/bin/certbot /usr/bin/certbot # 验证 certbot --version # 输出：certbot 2.8.0

为什么 certbot 必须用 snap？因为certbot-dns-cloudflare等插件依赖 Python 3.9+，而 Ubuntu 22.04 的python3-certbot包是 Python 3.10，但缺少dns-lexicon库。snap 版本自带完整 Python 环境。

3.7 安装 FFmpeg：Jitsi 录屏与转码的底层引擎

Jitsi 录屏（jibri）和 SIP 网关依赖 FFmpeg。Ubuntu 22.04 官方源的ffmpeg 4.4.2-0ubuntu0.22.04.1缺少libx264和libfdk-aac，导致 H.264 编码失败：

# 添加 Jonathon F 的 PPA（提供最新 FFmpeg） sudo add-apt-repository ppa:savoury1/ffmpeg4 -y sudo apt update sudo apt install ffmpeg -y # 验证编码器 ffmpeg -encoders | grep -E "(libx264|libfdk_aac)" # 应输出两行，含 "libx264" 和 "libfdk_aac"

注意：ppa:savoury1/ffmpeg4是 Ubuntu 22.04 兼容的唯一 PPA。其他 PPA（如mc3man/trusty-media）会破坏libavcodec依赖。

至此，所有核心组件已按 Ubuntu 22.04 兼容版本精确安装。执行sudo systemctl list-units --type=service --state=running | grep -E "(nginx|prosody|jicofo|jitsi-videobridge)"，应看到全部四服务处于running状态。下一步，是让它们真正“认识彼此”。

4. 配置串联：Prosody、Jicofo、JVB、Nginx 的四层握手协议

安装只是铺路，配置才是让 Jitsi 活起来的血液。这四层服务不是简单地“启动就行”，它们之间通过 XMPP、HTTP API、TLS 证书、SIP 协议进行深度握手。任何一层配置错位，都会导致“页面能打开，但进不了房间”的经典故障。我们按数据流向，从最底层的 Prosody 开始，逐层向上配置。

4.1 Prosody 配置：XMPP 虚拟主机与认证模块的精准绑定

Prosody 是 Jitsi 的身份中枢。它必须为meet.example.com创建虚拟主机，并为三个关键账号（focus、guest、recorder）配置内部哈希认证。配置文件路径：/etc/prosody/conf.avail/meet.example.com.cfg.lua。

-- /etc/prosody/conf.avail/meet.example.com.cfg.lua VirtualHost "meet.example.com" -- 启用 TLS，证书路径必须与 certbot 生成路径一致 ssl = { key = "/etc/letsencrypt/live/meet.example.com/privkey.pem"; certificate = "/etc/letsencrypt/live/meet.example.com/fullchain.pem"; } -- 启用 BOSH（Browser Over HTTP Streaming），Jitsi Web 前端依赖此 modules_enabled = { "bosh"; "pubsub"; "ping"; "speakerstats"; "conference_duration"; "muc_lobby_rooms"; "muc_breakout_rooms"; } -- 关键：focus 账号必须属于 auth.meet.example.com 域 authentication = "internal_hashed" -- 新增 auth.meet.example.com 虚拟主机，专供 focus/guest 认证 VirtualHost "auth.meet.example.com" ssl = { key = "/etc/letsencrypt/live/meet.example.com/privkey.pem"; certificate = "/etc/letsencrypt/live/meet.example.com/fullchain.pem"; } authentication = "internal_hashed" -- 新增 internal.auth.meet.example.com，供 recorder 使用 VirtualHost "internal.auth.meet.example.com" ssl = { key = "/etc/letsencrypt/live/meet.example.com/privkey.pem"; certificate = "/etc/letsencrypt/live/meet.example.com/fullchain.pem"; } authentication = "internal_hashed" -- 为 focus 账号生成哈希密码（替换 YOUR_FOCUS_PASSWORD） -- 在终端执行：prosodyctl register focus auth.meet.example.com YOUR_FOCUS_PASSWORD -- 为 guest 账号生成哈希密码（替换 YOUR_GUEST_PASSWORD） -- 在终端执行：prosodyctl register guest auth.meet.example.com YOUR_GUEST_PASSWORD -- 为 recorder 账号生成哈希密码（替换 YOUR_RECORDER_PASSWORD） -- 在终端执行：prosodyctl register recorder internal.auth.meet.example.com YOUR_RECORDER_PASSWORD

关键点：authentication = "internal_hashed"表示密码以 SHA-512 哈希存储在/var/lib/prosody/auth.meet.example.com/accounts/focus.dat中。若你误用authentication = "anonymous"，则jicofo会因无法登录focus@auth.meet.example.com而报错Authentication failed。

启用配置：

sudo prosodyctl cert generate meet.example.com sudo prosodyctl cert generate auth.meet.example.com sudo prosodyctl cert generate internal.auth.meet.example.com sudo ln -s /etc/prosody/conf.avail/meet.example.com.cfg.lua /etc/prosody/conf.d/meet.example.com.cfg.lua sudo systemctl restart prosody

4.2 Jicofo 配置：聚焦服务的 XMPP 登录凭证与集群心跳

Jicofo 是会议协调器，它必须以focus@auth.meet.example.com身份登录 Prosody，并定期发送心跳。配置文件：/etc/jitsi/jicofo/jicofo.conf。

jicofo { xmpp { client { hostname = "localhost" domain = "auth.meet.example.com" username = "focus" password = "YOUR_FOCUS_PASSWORD" // 与 prosodyctl register 时一致 port = 5222 useTls = true useSasl = true tlsCheck = false // Ubuntu 22.04 的 openssl 3.0.2 证书验证较严，设为 false 避免握手失败 enabled = true } } // 关键：设置 JVB 地址，必须与 JVB 的 public address 一致 videobridge { addresses = [ "127.0.0.1:8080" // JVB 的 HTTP API 端口 ] } // 启用健康检查端点，供 nginx 做上游健康探测 health { enabled = true port = 8888 } }

为什么tlsCheck = false？因为 Jicofo 用 Java 的SSLSocketFactory连接 Prosody，而 Ubuntu 22.04 的openjdk-17对证书链完整性校验更严格。设为false后，Jicofo 仍使用 TLS 加密，只是跳过证书链验证（由 nginx 的 SSL Termination 保障）。

重启 Jicofo：

sudo systemctl restart jicofo # 检查日志：sudo journalctl -u jicofo -f | grep -E "(connected|focus|error)" # 应看到 "Connected to XMPP server" 和 "Focus role acquired"

4.3 JVB 配置：媒体桥接的公网地址、端口与 ICE 协议栈

JVB 是媒体中继核心。它的配置最易出错，因为涉及公网 IP、NAT 穿透、ICE 候选者生成。配置文件：/etc/jitsi/videobridge/videobridge.conf。

jvb { // 关键：public address 必须是你服务器的公网 IP（不是 127.0.0.1！） // 若你在云上，填云厂商分配的弹性 IP（如 203.0.113.45） public-address = "203.0.113.45" // STUN 服务器用于获取公网 IP 和端口（可选，但强烈推荐） stun-servers = ["stun.l.google.com:19302", "stun1.l.google.com:19302"] // ICE 协议栈：必须启用 UDP，禁用 TCP（TCP 会大幅增加延迟） ice { udp = true tcp = false preserve-order = true } // RTP/RTCP 端口范围（必须与防火墙开放的 10000/udp 一致） media { port = 1