1. 为什么在 Ubuntu 22.04 上亲手部署 Jitsi Meet比直接用 Docker 或一键脚本更值得花三小时你可能已经点开过十篇“Jitsi Meet 一键安装教程”最后却卡在第 7 步——不是certbot报错说域名验证失败就是Prosody启动后日志里反复刷出Authentication failed for focusauth.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 把它当身份总线用focusauth.meet.example.com是会议协调器账号guestauth.meet.example.com是访客账号recorderinternal.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 应用它需要四类端口协同工作端口协议用途是否需公网暴露关键检查点80TCPcertbot HTTP 验证是curl -I http://meet.example.com必须返回 200443TCPHTTPS 流量入口是openssl s_client -connect meet.example.com:443 -servername meet.example.com应显示有效证书4443TCPJVB 的 TLS 媒体信令端口是telnet meet.example.com 4443应连接成功非必须但建议开放10000UDPJVB 的 RTP/RTCP 媒体流端口必须nc -zuv meet.example.com 10000会失败UDP 不支持 -z改用sudo ss -uln | grep :10000确认监听实操中90% 的“黑屏”问题源于10000/udp未放行。云厂商如 AWS、阿里云的安全组默认不放行 UDP 端口且控制台界面常把“UDP”选项藏在“自定义协议”下。请务必确认# 检查本机是否监听 10000/udp sudo ss -uln | grep :10000 # 正确输出u_str LISTEN 0 128 *:10000 *:* users:((jvb,pid1234,fd23)) # 检查云防火墙规则以 AWS 为例 # 入站规则必须含TypeUDP, Port Range10000-10000, Source0.0.0.0/02.3 时间同步NTP 偏移超过 5 秒将导致 JWT Token 拒绝Jitsi 使用 JWTJSON 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调整。解决方案改用chronysudo apt install chrony sudo systemctl disable systemd-timesyncd sudo systemctl enable --now chrony chronyc tracking # 查看偏移量应 100ms2.4 内存与 CPUJVB 是内存吞噬者不是 CPU 密集型Jitsi 官方文档说“2GB RAM 足够”这是指纯文本会议。一旦开启屏幕共享、H.264 编码、或 10 人同时发言JVB进程 RSS 内存会飙升至 1.8GB。Ubuntu 22.04 的swappiness60默认值会让系统在物理内存剩 500MB 时就开始疯狂 swap导致JVBGC 延迟 2s会议卡顿。# 检查当前内存配置 free -h cat /proc/sys/vm/swappiness # 若 swappiness 10立即调整 echo vm.swappiness10 | 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]\nEnvironmentJAVA_OPTS\-Xmx1536m -Xms1024m -XX:UseG1GC\ | sudo tee /etc/systemd/system/jitsi-videobridge2.service.d/override.conf sudo systemctl daemon-reload2.5 DNS 反向解析PTR 记录Prosody 认证链的隐形环节Prosody 在建立 XMPP 连接时会反查客户端 IP 的 PTR 记录并与正向 DNSA 记录做一致性校验。若你的服务器 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 LANGzh_CN.UTF-8 | sudo tee /etc/default/locale sudo update-locale # 重启所有 Jitsi 服务使日志生效 sudo systemctl restart prosody jicofo jitsi-videobridge2 nginx2.7 禁用 snap 与 cloud-initUbuntu 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 [archamd64 signed-by/usr/share/keyrings/jitsi-keyring.gpg] 语法 echo deb [archamd64 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 依赖地狱JicofoJitsi Conference Focus和 JVBJitsi Videobridge是 Java 应用不依赖系统库直接运行 JAR 最可靠# 创建工作目录 sudo mkdir -p /opt/jitsi/{jicofo,jvb} # 下载 Jicofo 1.1.1027-1Ubuntu 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] DescriptionJitsi Conference Focus Afternetwork.target prosody.service [Service] Typesimple Userjicofo Groupjicofo WorkingDirectory/opt/jitsi/jicofo ExecStart/usr/bin/java -Dconfig.file/etc/jitsi/jicofo/jicofo.conf -jar /opt/jitsi/jicofo/jicofo.jar Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF sudo tee /etc/systemd/system/jitsi-videobridge2.service EOF [Unit] DescriptionJitsi Videobridge Afternetwork.target [Service] Typesimple Userjvb Groupjvb WorkingDirectory/opt/jitsi/jvb ExecStart/usr/bin/java -Dconfig.file/etc/jitsi/videobridge/videobridge.conf -jar /opt/jitsi/jvb/jvb.jar Restarton-failure RestartSec10 [Install] WantedBymulti-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.227上有java.lang.UnsatisfiedLinkError: net.java.sip.communicator.impl.neomedia.codec.audio.silk.SILK错误。手动下载 JAR 指定openjdk-17-jre-headless见下一步可完美规避。3.5 安装 OpenJDK 17JVB 的唯一稳定运行时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说明 JNAJava Native Access临时库路径被清理。解决方案在jitsi-videobridge2.service的[Service]块中添加EnvironmentJNA_TMPDIR/var/tmp/jna ExecStartPre/bin/mkdir -p /var/tmp/jna3.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 安装 FFmpegJitsi 录屏与转码的底层引擎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 --typeservice --staterunning | 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; } -- 启用 BOSHBrowser Over HTTP StreamingJitsi 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会因无法登录focusauth.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 prosody4.2 Jicofo 配置聚焦服务的 XMPP 登录凭证与集群心跳Jicofo 是会议协调器它必须以focusauth.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 保障。重启 Jicofosudo systemctl restart jicofo # 检查日志sudo journalctl -u jicofo -f | grep -E (connected|focus|error) # 应看到 Connected to XMPP server 和 Focus role acquired4.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禁用 TCPTCP 会大幅增加延迟 ice { udp true tcp false preserve-order true } // RTP/RTCP 端口范围必须与防火墙开放的 10000/udp 一致 media { port 1