开源视频会议系统Jitsi Meet部署指南：企业平替腾讯会议、钉钉、飞书的自托管方案

做企业内部办公支撑这几年，线上开会这件事一直绕不过去：腾讯会议、钉钉会议、飞书会议轮着装，价格表一年比一年丰富，功能却越来越像。直到我翻到一个 23.9k star 的开源视频会议项目，才动了彻底换掉商业会议软件的念头——自己部署一套完全可控的开源视频会议系统，作为“腾讯、钉钉、飞书”的平替方案。

这篇文章我会把整套思路和落地细节都摊开讲：从为什么选它，到架构原理、部署实操、性能调优，再到真实使用中的坑和扩展方案。如果你也在做企业信息化、内部办公系统选型，或者单纯对自托管线上会议感兴趣，这篇能帮你省下不少调研时间。

1. 为什么我盯上了这个 23.9k star 的开源会议项目

1.1 商业会议软件的隐形成本

腾讯会议、钉钉会议、飞书会议在体验上确实做得不错，一键入会、美颜、降噪、文档协作，该有的都有。但作为企业长期使用，有几个问题始终绕不开。

首先是费用。免费版限制时长和人数，商业版按 “方” 收费，200 人以上的会议一年下来是一笔不小的开支。而且这个费用是每年都要交的订阅制，不是买断。如果你只是个小团队，每天开 3 场会、每场 20 人，一年费用很容易冲到几千上万。

其次是数据资产。会议内容、聊天记录、参与人信息全部沉淀在别人的服务器上。虽然商业软件都有合规承诺，但企业内部研发讨论、客户方案评审、薪资绩效面谈这类敏感会议，很多人心里其实是不踏实的。

然后是定制能力。商业会议软件你很难改它，比如想接入公司内部的统一身份认证，想和自研 OA 系统深度联动，想把会议录制直接归档到内部存储，这些都受制于平台开放程度。飞书的开放接口算做得不错的，可依然存在边界。

我用了一段时间开源方案后最大的感受是：如果你能接受部署和维护的成本，自托管视频会议带来的自主性是商业软件给不了的。这也是“23.9k star”这个项目能火起来的最根本原因——大家被商业会议软件的授权费和数据边界问题夹得太难受了。

1.2 “平替”到底意味着什么

可能有人要问：开源平替是不是就等于“粗糙的盗版”？不是的。视频会议这件事的技术成熟度已经非常高了，底层 WebRTC 技术栈本身就是 Google 主导的开源生态，商业会议软件也是在这个基础上做了大量工程优化。换句话说，开源方案和商业方案在底层技术上是同源的，差异主要在封装、生态和运营能力上。

这个 23.9k star 的项目走的是“自托管 + 网页端入会 + 标准 WebRTC”路线，不需要安装客户端，浏览器直接进会，支持屏幕共享、录制、聊天、举手、分组讨论这些高频功能。它不追求做到和腾讯会议 100% 一致，而是把核心开会体验打磨到够用、稳定、可控的程度。

对大多数中小团队来说，“平替”的定位非常精准：80% 的开会场景都是 10 到 50 人的内部会议，这种规模下开源方案完全能扛住。真正需要和外部客户大规模连线的场景，再切回腾讯会议也不迟，两个方案不冲突，可以并存。

2. 项目选型：谁在对标“腾讯/钉钉/飞书”

2.1 23.9k star 的正是 Jitsi Meet

这个项目叫 Jitsi Meet，GitHub 上 star 数大约在 23.9k，是目前开源视频会议领域热度最高、社区最活跃的方案之一。它的背景也很硬：最早是 2003 年出现的 Jitsi 项目，后来被 Atlassian 收购又开源释放出来，现在由社区主导维护，生态非常完整。

Jitsi Meet 主打的是“零安装”体验：主持人创建一个房间链接发出去，参会人点开链接，浏览器授权麦克风摄像头就进来了，不需要装任何插件或客户端。这个体验和腾讯会议网页版非常像，但底层是完全自托管的。

它的功能清单相当能打：

• 高清音视频通话，基于 WebRTC 技术
• 屏幕共享，支持整个屏幕或单窗口
• 实时聊天，支持私聊和公开聊天
• 会议录制，可以录到本地，也可以配 Jibri 组件录到云端
• 举手发言、分组讨论、投票、背景模糊
• 端到端加密，可选开启
• 全部通过 REST API 可控，方便集成

我对它的评价是：它不是那种“demo 级”的开源玩具，而是真的可以拿来当生产工具用的东西。后面我会详细讲部署和配置。

2.2 架构核心：WebRTC 到 SFU 的转变

要理解 Jitsi Meet 为什么能在浏览器里流畅很多人视频，得先了解它的核心架构。传统的视频会议是 MCU 架构，服务器把所有参会人的视频流拉过来，混成一路再推给每个人。人一多，服务器就得做大量解码和编码，CPU 消耗极高，延迟也大。

Jitsi Meet 采用的是 SFU（Selective Forwarding Unit）架构，全称是选择性转发单元。原理特别好理解：每路视频流从发送端上来，服务器不混流，而是按需把指定的几路流转发给其他参会者。服务器只做“分发”，不做“混合”，CPU 开销小很多，延迟也更低。

这么说吧，MCU 像是一个总机接线员，每个电话都经过它转接处理，线路一多它就忙不过来；SFU 像是一个高速路由器，只管把数据包导流到该去的地方，不管里面的内容怎么变。所以 SFU 架构天然适合多人会议，能支撑更多并发。

Jitsi Meet 的服务端核心叫做 JVB（Jitsi Videobridge），它负责处理音视频流转发；配合 Prosody 这个 XMPP 服务器做信令和房间管理；再加上 nginx 做反向代理，一整套架构就齐了。这套组合经过十多年打磨，稳定性和性能在开源领域是顶级的。

2.3 和竞品开源方案的横向对比

如果只看开源视频会议，市面上还有几个选项，我也都调研过，放一起对比更直观：

BigBlueButton 的教学场景很强，但通用会议功能不如 Jitsi 轻快；LiveKit 是现代云原生方案，但需要写更多代码才能达到 Jitsi 的“开箱即用”；mediasoup 更是纯粹的底层库，不适合直接部署。综合下来，Jitsi Meet 是“部署成本、功能完整度、社区活跃度”三角平衡做的最好的一个。

另外一个现实因素是它在这个赛道 star 数是断层领先，意味着网上能搜到的踩坑文章、第三方教程、插件方案最多。真出了问题也容易找到答案，这对自托管方案来说太重要了。

3. 部署实录：从裸机到可开会

3.1 硬件选型与网络环境规划

部署 Jitsi Meet 对硬件要求不算苛刻，主要看并发人数和视频路数。我这里给出基于实测的参考配置：

• 10~20 人并发会议：2 核 CPU、4GB 内存
• 30~50 人并发会议：4 核 CPU、8GB 内存
• 100 人以上并发：8 核 CPU、16GB 内存起步，建议上集群

网络带宽比 CPU 更容易成为瓶颈。每个发送视频的参会方大约需要 1~2Mbps 上行，服务器端下行带宽等于“上行总和 × 在线人数”减去本地上行的部分。50 个人同时开摄像头，按平均 1.5Mbps 每人算，服务器下行峰值可能需要 50×1.5×49/50≈70Mbps。所以带宽至少预留 100Mbps 才比较稳。

我在实际部署时用到的是 4 核 8GB 的云主机，实测 30 人全开视频的会议，CPU 占用峰值在 60% 左右，内存 5GB 上下，整体还算轻松。建议别买太低配的机器，Jitsi 虽然优化得好，但它还要跑 nginx、Prosody、JVB 三个进程，太抠配置容易在高峰期掉链子。

3.2 快速部署：Docker 方案是首选

部署 Jitsi Meet 有几种方式：deb 包手动装、Ansible 一键部署、Docker 容器化部署。我最推荐 Docker，因为升级、回滚、迁移都方便，配置也集中在一个目录里。

先拉取官方 Docker Compose 配置：

bash复制git clone https://github.com/jitsi/docker-jitsi-meet.git
cd docker-jitsi-meet
cp env.example .env

核心配置在 .env 文件里，几个关键项：

bash复制# 域名设置为自己的域名，必须提前把 DNS 解析到服务器 IP
CONFIG_DOMAIN=meet.example.com
# 容器内使用的公开 IP 或域名
PUBLIC_URL=https://meet.example.com
# 安全密钥，生成随机字符串填进去
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=mysecretpassword
JVB_AUTH_PASSWORD=mysecretpassword
JIGASI_XMPP_PASSWORD=mysecretpassword
JVB_BREWERY_MUC=JvbBrewery

然后编辑 docker-compose.yml，把不需要的组件注释掉。最基础的一组只需要：web、prosody、jicofo、jvb。如果需要录制再加 jibri，需要 SIP 接入再加 jigasi。

启动命令很简单：

bash复制mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody,jicofo,jvb,jigasi,jibri}
docker-compose up -d

这套默认配置启动后，访问 https://meet.example.com 就能创建一个会议房间。从拉代码到能开会，熟练的话 20 分钟能搞定，比预想中简单很多。

3.3 域名、HTTPS 证书与 TURN/STUN 配置

这一步很多人容易卡住。Jitsi Meet 是浏览器 WebRTC 应用，要求必须是 HTTPS 环境才能跑，否则浏览器会禁止摄像头和麦克风权限。Docker 部署时，web 容器会自动尝试 Let's Encrypt 免费证书，但前置条件是域名已经解析到服务器，且 80/443 端口开放。

证书申请成功后，Jitsi 会在 /etc 的配置文件里自动填入证书路径。如果想用已有的企业证书，也可以手动挂载到容器里替换，对运维来说很友好。

然后是内网穿透问题。我在公司内网部署时遇到一个典型情况：内网用户直接通过内网 IP 访问，外网用户通过域名访问，但内网和外网访问同一个 Jitsi 域名时，WebRTC 需要协商媒体通路。默认配置下，服务器只会把公网 IP 给客户端，内网客户端拿到公网 IP 反而做不了 NAT 打洞。

解决方案是在 .env 里显式配置 TURN/STUN 服务器：

bash复制TURN_HOST=你的域名
TURN_PORT=3478
TURN_TRANSPORT=udp

如果没有自己的 TURN 服务，可以用云厂商提供的 TURN 服务，或者部署开源 coturn 很简单，几行命令就能跑起来。TURN 的作用是给 WebRTC 网络协商兜底：当两个客户端无法直接建立 P2P 通道时，就通过 TURN 服务器中转音频视频流。没有 TURN，大约 15% 到 20% 的网络环境会莫名卡顿或无法连接。

我见过很多部署 Jitsi 后“明明配置没问题但外部用户进不来”的案例，绝大多数都是 TURN 没配好。这个配置务必在正式使用前反复验证。

3.4 云主机安全组与端口放行清单

部署完成后，别忘检查云厂商安全组。Jitsi 需要放行的端口不只是 80/443，还有：

10000 到 20000 的 UDP 端口范围是 JVB 转发媒体流的默认区间。安全组放行时把它写上，不然就会出现：网页能打开、房间能创建、但大家进会后都看不到对方视频的诡异情况。我帮同事排查过一次，折腾了一下午，最后发现就是安全组只开了 443。

4. 功能对标：到底“平替”到了什么程度

4.1 能打的：音视频、屏幕共享、聊天、分组讨论

部署好之后，我特意拉了一个 20 人的测试会，把高频场景挨个过了一遍。

音视频质量：在相同网络条件下，Jitsi 的清晰度和腾讯会议没有肉眼可见的差距。默认配置下每个人可以发 720p 的视频流，如果带宽不充足，JVB 会自适应降级到 360p，画质可能有损失，但通话不会中断。这个自适应机制对弱网用户非常友好，我在一个手机上用 4G 热点也保持了稳定通话。

屏幕共享：支持整个屏幕或单个应用窗口，这个在实际演示中的高频操作。实测下来，共享 PPT 和网页都没有明显延迟，参会人能通过左下角的“您正在观看 {user} 的屏幕”标识知道是谁的共享。

聊天和举手：这两个功能虽然小，但开会有它们才算完整。Jitsi 的聊天支持公开和私聊，举手功能在全员大会时特别好用，主持人能看到有人举手提示，再决定是否同意其发言。

分组讨论是 Jitsi 的一个黑马功能。主持人在会议中点击“分组讨论”，可以创建任意数量的子房间，把参会人手动拉进去，也可以选随机分组。每个子房间有自己的音视频通道，互不干扰，讨论结束后主持人可以一键把所有人拉回主房间。这个场景对培训、头脑风暴会特别实用，腾讯会议的这个功能是要额外收费的。

这个表基本说明了问题：对于日常内部会议的核心场景，Jitsi 是完全够用的，甚至在某些功能上比商业版还要大方。

4.2 差一点：大规模会议、统一管控、生态整合

当然平替不是没有短板，把“差一点”的点说清楚，免得大家部署完期望值太高。

第一是超大规模会议的支撑。数千人同时在线的网络研讨会场景，Jitsi 不是做不了，而是需要非常强的集群架构才能做到。JVB 单机在 50~80 人以下是轻松应对的，超过 100 人就得考虑横向扩展、录像分片、SFU 分流等高级配置。而腾讯会议开到几千人也是靠背后的音视频网络基础设施，这个自建成本很高。

第二是后台管理和企业管控能力。钉钉/飞书会议天然集成在组织通讯录里，开会能直接拉人、看组织架构、按部门建群。Jitsi 本身没有组织架构概念，它只认房间和用户认证。需要配合 LDAP 或 SSO 插件补这一课，配置工作量有一定规模。

第三是生态整合度。飞书会议和飞书文档、云盘、IM 的联动很顺滑，开会时直接在会议里编辑文档、共享云盘文件，这些体验在 Jitsi 里没有，它更没有“日历邀请直接生成会议链接”的原生能力。要补齐体验，得自己开发或者集成第三方工具。

比较实际的策略不是“全替换”，而是“混合共治”：内部日常会议走 Jitsi，对外重要客户、大型发布会、千人培训走商业软件。这个思路我们实践下来最顺。

4.3 企业级补充：Jibri 录制、Jigasi SIP、认证与 SSO

把小短板补起来，Jitsi 离企业级就更近一步。

Jibri 是录制组件。它本质是一个无头浏览器，进入会议后捕获音视频流，然后生成 mp4 文件。配置好之后，会议主持人点击“开始录制”，Jibri 会自动加入会议录制画面，结束后把文件传到本地或 S3 存储。自监督的意义在于，录下来的会议视频直接归企业自己管理，不经过第三方服务器，这对内审有要求的企业很关键。

Jigasi 是 SIP 网关，简单说就是把传统电话网络和 Jitsi 会议室打通。参会人没有网络时，可以通过拨打电话号码的方式进入会议。这个功能在大企业尤其有用，因为很多一线岗位的同事并没有长期稳定的网络环境，语音接入是最后一道保障。

认证和 SSO 方面，Jitsi 支持通过 Prosody 做密码认证，也支持对接企业现有的 LDAP/AD 或 SAML SSO 系统。登录后可以在后台看到会议室信息、用户入会记录，适合做内部审计。

如果你在选型阶段就拿着一张“企业会议需求清单”逐项核对，Jitsi 的覆盖度其实相当可观。

5. 上线后的性能调优与避坑清单

5.1 音频卡顿和回声问题排查

部署完最频繁遇到的是音频问题。我举一个实际案例：测试时发现有两个参会人声音断断续续，其他人都正常。

排查链路是这样的：先看这两个人是不是连的同一个 WiFi——他们确实在同一个办公室；再看是不是本地网络丢包——用 ping 测网关延迟，正常；然后看 JVB 日志，发现发往其中一个 IP 的 RTP 包丢包率高达 20% 以上。

最后定位到问题根源是无线路由器的 QoS 策略：同楼层大量设备占用带宽，语音包优先级不够，导致 RTP 报文延迟和乱序。解决方式是在路由器上给会议服务器 IP 和会议室网段设置带宽保障规则，同时把 Jitsi 客户端的音频编码码率上限提高一些。经过调整后丢包率降到 1% 以下，声音恢复流畅。

另一个常见回声抱怨，多数是参会人戴了半入耳耳机，电脑扬声器和麦克风之间形成声学回路。Jitsi 自身有回声消除机制，但有时不能完全抵消。可以在设置里建议参会人“佩戴耳机”“关闭系统提示音”，或者由主持人强制开启“降噪”选项。

5.2 JVB 端口池和内核参数优化

JVB 默认的媒体端口范围是 10000 到 20000，看起来很多，但如果并发会议多，这个池其实很容易不够用。一个连接通常占用一个 UDP 端口，50 个人同时开会可能就要占 50 个端口。如果发现日志里出现 “no ports available” 的错误，说明端口池快被耗尽了。

调优方式有两种：一是把端口范围扩大，例如改成 20000-30000，这样理论上能支撑更多并发；二是让 JVB 使用单端口模式，所有媒体流复用同一个 UDP 端口，靠 RTP 内部 SSRC 区分会话。单端口模式更节省服务器端口资源，但要求网络环境对 UDP 限制较小，默认不开启。

还有一个容易被忽略的内核参数：UDP 缓冲区大小。JVB 在高并发时会因为 UDP 接收缓冲区溢出而丢包。建议把系统 UDP 缓冲调大：

bash复制sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.rmem_default=26214400
sysctl -w net.core.wmem_max=26214400
sysctl -w net.core.wmem_default=26214400

调整完用 sysctl -p 激活。实测在 30 人并发的场景下，这个设置可以减少约 5%~8% 的媒体丢包率。

5.3 会议人数上限与网格布局

Jitsi 默认的参会人数上限由会场配置决定，默认是 75 人。如果没设限，超出服务器负载会整体变慢。建议在 .env 或界面里按服务器性能设置上限，比如 50 人，且把“Tile view”中的最大显示视频数调整到 6、9 或 12。

为什么这个设置重要？因为视频会议最耗资源的部分不仅在于转发，还在于客户端渲染。Jitsi 默认把所有人视频都平铺展示，相当于每个客户端同时解码多路视频流，对带宽和客户端性能都是考验。把最大显示路数限制在 9 路，可以显著减少参会人手机或旧电脑的发热和卡顿，而主持人仍然可以钉住某一路视频重点查看。

5.4 负载均衡与横向扩容思路

前面说单机扛 50~80 人没问题，但到了 200 人级别就需要考虑集群了。Jitsi 的横向扩展思路是：前边一个 nginx 负载均衡，后面挂多个 JVB 节点，通过 prosody 共享会议室状态。会议房间可以分布式路由到不同 JVB，实现跨节点会议。

不过这层架构比单机复杂不少，需要维护配置同步、JVB 注册发现、共享存储等。如果团队没有专门的运维同学，我不建议一上来就搞集群；单机顶不住的时候，优先考虑“分会议室”：拆成多个小型会议，而不是把所有人在一个房间里钉死。90% 的内部会议其实都不需要超过 50 人同时开视频。

6. 深度集成与二次开发的扩展玩法

6.1 API 与第三方系统整合

Jitsi 的开放能力远不止“部署后能用”，它提供了 REST API 和 iframe API 两条整合路径。

对外集成时，REST API 可以用来创建和管理房间。比如你做一个内部会议预约系统，用户在系统里提交主题和时间，后端自动调用 Jitsi 的 API 生成一个带鉴权的会议室，入会链接直接嵌入邮件通知。这套流程完全可以自动化，我就见过有人用它替代了“手动建会、复制链接发到群里”的琐碎流程。

iframe API 更适合深度嵌入自有办公平台。你可以在企业门户里嵌一个 <iframe>，把 Jitsi 会议窗口直接放到页面上，配合自定义的 UI 皮肤、Logo、会议室密码策略，让员工感觉用的是自家产品，而不是外挂第三方系统。这个体验和飞书里直接开会几乎无差别。

对集团公司来说，Jitsi 的 SSO 集成还能和现有的统一登录体系融合，员工用企业账号直接进入会议，账号和权限由内部管控，离职员工的会议权限随之回收。

6.2 前端界面定制与品牌化

Jitsi 的前端界面是基于 React 实现的，主题可配置。你可以在 .env 里设置：

bash复制ENABLE_LOBBY=1
DISABLE_JOIN_LEAVE_NOTIFICATIONS=1
APP_NAME=企业花名

更复杂的界面定制可以直接改前端代码重新构建镜像。我见过有企业把 logo、背景图、会议室默认布局全改成自家风格，做成对内对外都像商业产品的样子。

要注意的是，如果改了前端代码，后续升级 Jitsi 版本时要重新合并补丁，维护成本会上去。建议只做配置层级的定制，不要轻易动源码。除非有专门的前端同事在维护，否则升级麻烦会抵消掉定制带来的好处。

6.3 成本对比：自托管的真实账单

算一笔账，看看自托管到底省不省钱。

如果只是 10 人以内的小团队，用免费版商业软件其实是最省事的。但如果你面对的是一家对数据有要求的公司，比如产品研发、金融机构、政务单位，那么自托管 Jitsi 的商业价值远远超过省下那点订阅费——“数据不出域”本身就是一笔估值极高的无形资产。

我在实际使用中最值的配置是：自托管 Jitsi 负责内部日常会议和保密项目讨论；腾讯会议保留给对外客户和跨组织交流。两者并存，既控制预算，又保住了对外协作的便利性。

7. 一个容易被忽视的私有化部署细节：数据备份与升级

7.1 哪些数据必须备份

自托管最大的风险是数据在自己手里“丢了自己负责”。Jitsi 本身是无状态或轻状态的：会议室存在内存里，会议结束就销毁；但如果你启用了录制、聊天记录持久化、用户注册信息，这些数据是写进数据库或文件系统的，必须纳入备份策略。

我备份的范围包括：

• ~/.jitsi-meet-cfg/prosody：XMPP 用户账户、房间配置、聊天记录
• ~/.jitsi-meet-cfg/jibri：录制任务状态
• ~/.jitsi-meet-cfg/web：自定义前端配置、证书
• nginx 反代配置和 .env 文件

一个最简单的策略是每天凌晨用 cron 把整个 .jitsi-meet-cfg 目录打包，加密后传到异地存储。恢复时直接解压覆盖、重新 docker-compose up -d，五分钟就能回到最近一次备份的状态。

7.2 升级路径与版本回滚

Jitsi 的迭代节奏比较快，安全补丁和功能更新都比较频繁。建议每季度做一次升级，升级前先看官方 release notes，确认没有破坏性变更。

升级流程不复杂：

bash复制docker-compose pull
docker-compose up -d

但如果是从老版本跨大版本升级，比如从 8.x 升到 9.x，建议先在测试机验证，再动生产。我踩过一次大版本升级后客户端连接全部失败的坑，原因是 prosody 的数据目录格式不兼容，好在提前备份了配置，用旧镜像回滚就恢复了。

所以一定不要在生产机上直接瞎升级。先把 docker 镜像 tag 固定到当前版本的 commit，再拉新镜像，这样万一出问题还能一键回滚到旧镜像。

7.3 监控与告警

自托管最怕的其实是“会议开到一半，服务器挂了没人知道”。我建议至少要接一个基础的存活监控和资源监控。

最省事的方式是在云平台控制台设置 CPU、内存、带宽的告警阈值，CPU 超过 90% 持续 5 分钟就触发短信提醒。更专业一点可以用 Prometheus + node_exporter 抓取主机指标，再配合 Grafana 画出曲线图，能在问题发生前提前发现隐性风险。

结合我自己的运维经验，最关键的告警指标有三个：磁盘空间（尤其是录制文件存储分区）、内存使用率、UDP 端口池剩余数量。这三个任何一个告警都意味着会议系统离“不可用”很近，必须尽快处理。

我个人的体会是：Jitsi Meet 这套方案，部署本身不难，真正值钱的是后面这一整套“如何稳定运营”的工程经验。把它当生产系统来对待，它就能撑住正式业务；如果只当玩具跑起来就撒手不管，那开会翻车的时候千万别怪开源项目不行。自托管方案最大的魅力就在这里——你把控制权拿过来了，同时责任也接过来了，但这份责任换来的自主和安心，我认为非常值。