VPS自托管视频会议：带宽、Jitsi与BigBlueButton对比

VPS 上自托管视频会议首先受带宽限制

小型服务器上的自托管视频会议失败通常只有一个原因，而且几乎从来不是安装问题。现代工具都使用 SFU（选择性转发单元）作为服务器组件。SFU 接收每位参与者的一路视频流，再将其副本转发给其他每位参与者，因此服务器的出站流量会随参与人数的平方增长。共享上行链路上的 1 GB 或 2 GB VPS 可以正常运行软件，但无法承载您设想的全员会议。

因此，请按以下顺序处理。先统计人数，再计算所需兆比特数，最后选择服务器。安装只需二十分钟复制并粘贴命令。上行链路决定其他人是否能听到您的声音。

为什么带宽会随参与者数量的平方增长？

先看 mesh。每个浏览器都会编码自己的摄像头画面，并将副本直接发送给其他每个浏览器。整个过程中没有媒体服务器处理视频。两人 mesh 通话只需要信令服务器，不需要其他组件。因此，一对一通话几乎不产生托管成本。参与者达到四到五人左右后，mesh 就无法正常工作，因为家庭网络中的笔记本必须同时上传自己视频的四到五个独立副本。

SFU 的工作方式不同。每个浏览器只向服务器上传一个副本。服务器读取 RTP（实时传输协议）标头，然后将这些数据包转发给其他参与者，不对视频进行解码。这就是 SFU 的核心机制。因此，SFU 的 CPU 占用较低，但网络带宽消耗较高。

更早的方案是 MCU（多点控制单元）。它会解码每个传入的视频流，将这些视频合成为一幅画面，再对合成画面重新编码。出站带宽很小，但 CPU 成本极高。现在几乎没有视频系统使用 MCU，本指南中的系统也不使用 MCU。

下面计算 SFU 的带宽。假设每个人都以 1.2 Mbps 发送视频，并且没有人关闭摄像头。服务器接收 N 乘以 1.2 Mbps 的流量。这个数值呈线性增长，通常不会造成问题。服务器发送 N 乘以（N 减 1）再乘以 1.2 Mbps 的流量，因为 N 个人中的每个人都必须接收其他 N 减 1 路视频流。第二个数值才是导致项目无法继续扩展的因素。

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

这些行是算术结果，不代表任何特定服务器的实测值。每月列按每月通话二十小时计算。先看最后一行。五十人同时开启摄像头时，单台机器需要持续产生 2,940 Mbps 的出站流量。三十人需要 1,044 Mbps。四人需要 14.4 Mbps，任何 VPS 都能轻松处理。参与人数从四人增加到三十人时，人数增长七点五倍，而出站流量增长超过七十倍。

实际部署的流量通常低于这些数值，具体原因如下。Jitsi 和 LiveKit 都使用 simulcast：发送端会同时发布多个质量层，SFU 会向当前未显示在屏幕上的参与者转发低质量层。Jitsi 还提供 last-N 设置，只转发最近发言者的视频。两种方式都能显著减少流量。但它们都不会改变曲线的增长趋势；一旦所有人都打开摄像头并将彼此固定显示，它们就不再有效。

VPS 上行链路实际能提供什么？

方案页面写着“1 Gbps 端口”。这表示虚拟网卡的速率，并不保证下一跳的带宽。该链路与同一物理主机上的其他租户共享，因此高峰时段的持续吞吐量会低于端口速率，而视频会议通话正是持续负载。大多数方案还包含每月传输额度，超出后会限速或计费。

发票上的额外费用通常就来自这个传输额度。一个月内进行二十小时的三十人通话，会以每小时 469.8 GB 的速率从服务器传出 9.4 TB。五十人通话进行二十小时，会传出 26.5 TB。查看 RAM 配置前，先确认传输额度；如果方案页面对此含糊其辞，这种含糊本身就是答案。对于此类负载，正确解读低价 VPS 方案比其他几乎所有方面都更重要。

Jitsi Meet：默认选择及其要求

Jitsi Meet 是大多数人应首先尝试的方案。它从项目自己的 Debian 软件源安装，安装过程中会配置 nginx 和证书；视频桥接服务（JVB）只使用一个 UDP 端口，因此防火墙规则较少。它要求 Debian 11 或更高版本，或 Ubuntu 22.04 或更高版本。

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

安装程序会要求输入主机名，然后提供证书选项。选择 Let's Encrypt，并提供一个已解析到此服务器公网地址的域名。证书通过 HTTP challenge 签发，因此如果域名指向其他位置，该步骤会失败。

然后开放端口。以下是手册记录的端口，并将 SSH 放在最前面，以免 ufw enable 将您锁在服务器外：

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 和 443 用于提供 Web 应用，并支持证书续期。UDP 10000 承载所有音频和视频流，这是最容易遗漏的端口。UDP 3478 和 TCP 5349 属于 coturn 服务器。Jitsi 软件包会同时安装该服务器和视频桥接服务。当用户所在网络阻止 UDP 时，系统会使用 coturn 作为备用路径。

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

第一条命令应显示服务处于 active 状态。第二条命令应显示视频桥接服务正在监听 UDP 10000。如果没有输出，说明视频桥接服务未启动，/var/log/jitsi/jvb.log 会说明原因。

在容量规划方面，Jitsi 手册给出了自己的起始配置建议，而 BigBlueButton 给出的建议要高得多：

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

对于正式使用的服务器，Jitsi 手册建议使用 8 GB 内存和 4 个专用核心；通常 1,000 Mbps 的网络带宽就足够。手册还指出，较小的部署可以运行在 4 GB 或 2 GB 内存上。该页面还有一点值得注意：负责处理信令的 XMPP 服务器 Prosody 只能使用一个核心。额外的核心可以帮助视频桥接服务，但不会提升信令处理能力。

为什么所有人都加入了通话，但没有人能看到视频？

这是 VPS 上常见的 Jitsi 故障。参与者列表可以正常显示，聊天也能使用，但所有视频画面都保持黑屏。videobridge 会公布它在自身接口上找到的地址。如果云服务商为虚拟机分配私有地址，再将公网地址映射到该私有地址，JVB 找到的唯一地址就是私有地址。因此，每个客户端都会尝试向类似 10.0.0.5 的地址发送媒体数据包，但这些数据包无法到达目标。

需要向 bridge 同时告知这两个地址。向 /etc/jitsi/videobridge/jvb.conf 添加静态映射：

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

使用 sudo systemctl restart jitsi-videobridge2 重启。通过 ip -4 addr show 获取本地地址，并从云服务商的控制面板获取公网地址。旧版指南会在 /etc/jitsi/videobridge/sip-communicator.properties 中使用 org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS 和 org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS 这两个键配置相同内容。这种配置仍然有效，但新安装应使用上面的映射块。

另一个原因是未配置防火墙。大多数云服务商都会在控制面板中运行独立于服务器上 ufw 的网络防火墙，UDP 10000 必须在两者中都放行。要确定数据包在哪一层被丢弃，请在服务器上运行 sudo tcpdump -ni any udp port 10000，同时让某个外部用户加入。如果完全没有数据包到达，说明请求尚未到达服务器，因此拦截发生在操作系统之外。如果数据包已到达，但视频画面仍然黑屏，说明 bridge 返回了客户端无法访问的地址，因此问题出在映射配置上。如果你不确定 ufw 本身的配置，请参阅VPS 实际需要的 ufw 规则，其中说明了容易出错的规则顺序。

BigBlueButton：重量级、约束多，并且希望独占整台服务器

BigBlueButton 面向教学场景设计。它提供白板、分组讨论室、投票和演示区域，录制流程也是核心功能，而不是后加的扩展。相比之下，它是这里最重量级的选项，而且不能作为软件包添加到现有服务器中。

截至 2026 年 8 月，受支持的安装路径是在 Ubuntu 22.04 上部署 BigBlueButton 3.0，并使用 jammy-300 版本标志进行选择。项目声明的生产环境要求是 16 GB 内存并启用 swap、8 个具有较高单线程性能的 CPU 核心、250 Mbps 对称带宽；如果保留录制内容，需要 500 GB 磁盘空间（禁用录制时需要 50 GB）。所需端口为 TCP 80 和 443，以及 UDP 16384 到 32768 端口范围。

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

项目提供的示例会将该脚本直接通过管道传给 bash。应先下载并阅读脚本，因为它会重写 nginx 配置、安装自己的媒体和音频组件、锁定软件包版本，并声明该主机名。这是设计要求，而不是缺陷：BigBlueButton 预期独占整台机器。-w 标志用于配置防火墙，-s 是主机名，-e 是 Let's Encrypt 注册的地址，-g 用于添加 Greenlight 前端。如果同一台服务器还要为其他服务终止 TLS，应将 BigBlueButton 迁移到其他服务器，或者在脚本修改配置前，先确认 nginx 反向代理配置的实际作用。

仔细比较图表中的两行。BigBlueButton 要求的内存和 CPU 核心数是 Jitsi 建议值的两倍，但带宽要求只有四分之一。这两个数值的测量方式不同，假设的房间规模也不同，因此应将它们分别视为各自项目的起始配置，而不是进行同类对比。CPU 差距是真实存在的，原因在于 BigBlueButton 除了转发视频之外还要执行许多其他任务。

Galène：轻量方案

Galène 是一个使用 Go 编写的紧凑型 SFU。它会构建为单个静态二进制文件，自带 Web 客户端，并包含 TURN 服务器，因此无需维持 XMPP 服务器、Java 运行时或 Rails 应用。如果您的需求是在配置适中的主机上稳定支持 10 人通话，请先尝试它，再决定是否需要更高配置的硬件。

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Ubuntu 24.04 中的 golang-go 软件包版本是 Go 1.22。如果 go build 报错称模块需要更新版本的 Go，请从 go.dev 安装当前工具链，不要继续使用发行版软件包。

Galène 将房间称为 group，而 group 是一个 JSON 文件：

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

打开 https://your.server:8443/group/night-watch/，并使用 vimes 登录。这些凭据直接来自项目的 README，因此在该端口可从其他位置访问前，请先修改它们。对于正式部署，项目提供了 systemd 单元配置：

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

端口配置如下：Web 界面使用 TCP 8443，内置 TURN 服务器使用 TCP 和 UDP 1194，媒体使用一段高位 UDP 端口。固定这段端口范围，以便为其编写一条防火墙规则：

./galene -udp-range 40000-40100

在 VPS 上，-turn 选项最重要。-turn ':1194' 会监听所有公网 IPv4 地址。-turn '203.0.113.1:1194' 用于告知 Galène 客户端实际看到的地址。当主机自身的地址是私有地址时，必须设置此选项。-turn '' 会禁用内置服务器，这样您就可以通过 data/ice-servers.json 指定外部服务器。默认值是 auto；不存在 ice-servers.json 时，它的行为类似于 :1194。

您可以通过在 data/config.json 中设置 proxyURL，将 nginx 放在 Web 界面前面，并为 /ws location 配置代理及 WebSocket upgrade 请求头。请明确其作用范围：客户端仍会直接向 TURN 端口建立 UDP 流和 TCP 连接，因此反向代理只处理页面和信令。媒体流不会经过反向代理。

Galène 文档称其服务器资源需求非常适中，但没有公布具体数值，因此不要期待一个明确的配置要求。上文的带宽计算仍然完全适用。它节省的是 SFU 之外所有组件所需的内存，以及这些组件带来的维护环节。

Owncast：一对多，带宽保持线性增长

许多“视频会议”需求实际上是一个人向观众演示，观众通过聊天输入内容。如果您的需求属于这种情况，SFU 就不是合适的工具，成本结构也会完全不同。Owncast 从 OBS 或类似编码器接收 RTMP 流，并通过普通 HTTPS 提供 HLS。每位观众所需的带宽呈线性增长，而不是二次增长；由于输出是普通 HTTP 分片，还可以将其放到对象存储或 CDN 后面，避免由源站承担这些流量费用。

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

项目文档说明，不要以 root 身份运行此程序，并且在执行任何远程脚本前先检查脚本内容，因此上文将下载单独列为一个步骤。安装程序会获取当前版本；如果系统中尚未安装 ffmpeg，还会获取一个 ffmpeg 二进制文件。在安装目录中运行 ./owncast，然后访问 /admin，通过端口 8080 打开管理面板。默认登录用户名是 admin，默认流密钥 abc123 是密码。将域名指向服务器前，请先修改密码。

HLS 设计会带来两个结果。观众会比实时画面延迟数秒或数分钟，因为 HLS 会传输完整分片，因此无法进行来回对话。传输路径中也完全不使用 UDP 和 TURN，所以即使 WebRTC 通话无法建立连接，它也能到达这些网络。

Owncast 也是这里唯一一个有意执行转码的工具。启用的每种输出质量都需要对输入流执行一次额外的 ffmpeg 编码，并持续整个直播过程。在小型 VPS 上，建议提供一种或两种画质。提供五种画质会使 CPU 饱和，而网络仍处于空闲状态。

在已运行的 Matrix 服务器上部署 Element Call

如果您已经运行 Matrix，视频通话只是新增功能，不需要再运维另一套产品。但这仍不止一个软件包。Element Call 需要在您的 homeserver 后端部署两个组件。第一个是 LiveKit SFU，负责转发媒体流。第二个是 MatrixRTC 授权服务 element-hq/lk-jwt-service，负责向客户端提供 LiveKit WebSocket URL 和用于连接的已签名 JWT（JSON Web Token）。该服务使用 Matrix 联邦 API，因此前面需要配置 TLS 反向代理，并使用联邦网络可以访问的域名。

LiveKit 文档列出的端口：

• TCP 7880 用于 API 和客户端 WebSocket，前面应配置终止 TLS 的代理
• TCP 7881 用于基于 TCP 的 ICE，在客户端无法通过 UDP 连接到外部网络时使用
• UDP 50000 到 60000 用于媒体流，每个房间参与者使用其中两个端口
• 启用内置 TURN 服务器时使用 UDP 3478 和 TCP 5349；如果前面没有负载均衡器，5349 必须改用 443

每个参与者使用两个端口听起来很吓人，但实际并非如此。10,000 个端口的范围足以容纳数千名参与者，而您的上行带宽会远早于端口范围耗尽。无论如何都应开放整个范围，因为部分开放的端口范围可能让某些用户连接成功、其他用户连接失败，这是最难排查的一类故障。homeserver 这一侧需要单独配置，详见 在 VPS 上运行 Synapse homeserver。

为什么总有一个人无法连接？TURN 以及阻断 UDP 的网络

先介绍一些只使用一次的术语。ICE（interactive connectivity establishment，交互式连接建立）是两个 WebRTC 端点用来查找可用路径的过程。STUN（session traversal utilities for NAT，NAT 会话穿透工具）是一项小型服务，用于告知客户端：从外部看，客户端自身的公网地址是什么。TURN（traversal using relays around NAT，使用中继穿透 NAT）是一种中继：不存在直连路径时，双方都将媒体发送到 TURN 服务器，再由服务器转发。

对于无法观察其网络的参与者，必须使用 TURN。其中一人可能位于完全阻止出站 UDP 的企业或校园网络中。另一人可能位于运营商级 NAT 后方。该 NAT 会针对每个目标分配不同的源端口，这称为对称 NAT，会使 STUN 报告的地址失效。

这种症状很明确。大多数人可以加入，所有功能也都正常。某一人能看到参与者列表和聊天内容，但只能看到黑色画面和加载指示器。其浏览器已经收集候选地址，但没有任何候选地址对可用，ICE 最终进入 failed 状态。在 Chrome 中，尝试连接期间打开 chrome://webrtc-internals，可以看到候选地址对及失败信息。让该用户改用移动数据，通过手机重试。如果这样可以正常工作，原因就是其网络，解决方案是使用 TURN。

通过 TCP 的 443 或 5349 端口运行 TURN，是几乎所有网络都能使用的回退方式，因为阻止 443 端口上的 TLS 就等于阻止 Web。Jitsi 的软件包会为你安装并配置 coturn，这正是其文档化防火墙规则包含 UDP 3478 和 TCP 5349 的原因。Galène 在 1194 端口内置 TURN。LiveKit 提供内置 TURN 服务器，可在配置中启用。如果你自行运行 coturn：

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

在 Debian 和 Ubuntu 上，设置 TURNSERVER_ENABLED=1 前，软件包提供的服务不会启动；该设置位于 /etc/default/coturn 中。已安装但从未启用的 coturn，从外部看与完全没有 TURN 没有区别。因此，仅这一行配置就可能让人排查数小时。

现在说明一个常被忽略的成本。中继会在两个方向上传输每个经中继参与者的全部媒体流。当 coturn 与 SFU 共用一台服务器时，大部分流量会经过 loopback，因此消耗的是 CPU，而不是上行带宽；TLS 监听器还会在媒体已有的 DTLS 加密之上，再次加密每个数据包。将 TURN 移到独立服务器后，该服务器需要单独规划带宽，容量计算方式与 SFU 相同。通过 TCP 运行 TURN 还会将实时媒体转换为可靠流，因此丢失的数据包会被重传，而不是直接跳过。使用易丢包链路的中继参与者会不断累积延迟，而不是只出现短暂卡顿。中继是确保连接的回退方式，但其质量通常不如直连路径。

SFU 何时会转码，这会带来什么成本？

SFU 只转发数据包，从不解码视频。因此，4 个 CPU 核心就能服务一个按纸面配置看似无法承载的会议室。两个功能会打破这一特性，而且启用它们的用户通常不会预料到这一点。

录制是第一个功能。Jitsi 使用 Jibri 进行录制。Jibri 的文档明确说明了其工作方式：启动一个在虚拟帧缓冲区中渲染的 Chrome 实例，然后使用 ffmpeg 捕获并编码输出。这相当于在整个通话期间持续运行一个完整的浏览器来渲染整个会议，同时运行一个视频编码器。相同文档还说明，单个 Jibri 一次只支持一个录制任务，并且 Jibri 应运行在独立的物理机或虚拟机上，不能有其他应用使用显示或音频设备。录制需要第二台服务器，而不是勾选一个复选框。

电话拨入是第二个功能。将电话线路接入会议，意味着在 48 kHz 的 Opus 与电话网络接受的格式之间进行持续的双向转换，通常是 8 kHz 的 G.711，并且贯穿整个通话。音频转码的成本远低于视频转码，但它按每条通话线路运行，且不会暂停，因此成本会随拨入用户数量增长。如果需要拨入号码，自托管 VoIP 服务器负责执行这项工作。出于与 Jibri 相同的原因，它也应部署在独立的服务器上。

实际需要多大的服务器？

对于两个人，几乎不需要什么资源。Jitsi 在恰好有两名参与者时默认启用点对点模式。在此模式下，会议不再通过 videobridge 发送数据，而是使用直接连接。第三个人加入后，系统会切回 videobridge。因此，运行 Jitsi 的 1 GB VPS 很适合作为一对一通话服务器，但不适合四人通话。这也是“我测试时明明能用”如此常见的原因。

对于最多约十名开启摄像头的用户，在八名参与者时，67.2 Mbps 的出口带宽处于普通 VPS 上行链路可以持续承载的范围内。只要不进行录制，2 个 vCPU 和 4 GB 内存足以运行这一规模的 Jitsi 或 Galène。应监控流量传输计数器，而不是 CPU 图表。

对于三十人，最坏情况下需要持续 1,044 Mbps，连续运行二十小时就是 9.4 TB。达到这一规模后，应先计算带宽成本，再计算服务器成本。启用 last-N，使 videobridge 只转发最近发言者的视频；将参会者默认设置为关闭摄像头；并将 SFU 部署在流量配额足以满足计算结果的位置。

超过这一规模后，单台 VPS 就不合适了。要么活动本质上是直播，此时 Owncast 加 CDN 的成本只是上述方案的一小部分；要么就需要在单一信令层后部署多个 videobridge，这已经是与最初项目不同的工程。

最后还要考虑路由。大多数团队每天需要聊天的时间远多于视频通话，而聊天服务托管成本低，也容易持续运行。为日常通信部署自托管的 Slack 替代方案，仅在计划通话时运行会议服务器，这种安排才能适应小型 VPS 的预算。

FAQ

为什么参与者可以加入我的 Jitsi 会议，却无法互相看到或听到？

聊天和参与者列表通过信令通道传输，该通道使用 TCP 443；音频和视频则通过 UDP 10000 发送到 videobridge。如果参与者列表正常显示，但所有视频画面都保持黑屏，说明媒体路径中断，而信令路径正常。请在两个防火墙中检查 UDP 10000：一个是服务器本机上的防火墙，另一个是服务商控制面板中的独立网络防火墙。然后确认 bridge 知道自己的公网地址：如果虚拟机使用私有地址，并通过映射获得公网地址，请在 /etc/jitsi/videobridge/jvb.conf 的 ice4j.harvest.mapping 下添加静态映射，然后重启 jitsi-videobridge2。在有人加入时运行 sudo tcpdump -ni any udp port 10000，即可判断问题属于哪一侧；如果完全没有数据包，说明阻断发生在操作系统之外的上游网络。

30 人视频通话需要多少带宽？

最坏情况下，如果所有人都开启摄像头，并且 SFU 向每个人转发完整质量的视频层，服务器的出站流量约为 1,044 Mbps，即每小时 469.8 GB。这是按 N 乘以（N 减 1）路流、每路 1.2 Mbps 计算的结果，不是对您实际部署的测量。正常使用时，simulcast 和 last-N 设置会大幅降低流量，因为任意时刻通常不会显示大多数参与者。容量规划仍应接近最坏情况，因为最坏情况就是所有人同时开启摄像头的全员会议。

我可以在 1 GB VPS 上运行 Jitsi Meet 吗？

可以安装，双人通话也能运行。这部分是因为 Jitsi 在恰好有两名参与者时使用点对点模式，完全跳过 videobridge。但它不适合作为群组通话服务器。Prosody、videobridge 和 Java runtime 都需要内存；手册建议正式部署使用 8 GB 内存，而带宽消耗通常会早于内存成为瓶颈。如果您只有 1 GB 的服务器，Galène 比 Jitsi 更适合这种配置。

如果 VPS 有公网 IP 地址，我还需要 TURN 服务器吗？

需要。TURN 解决的问题发生在通话的另一端。位于禁止出站 UDP 的企业网络中，或位于会为不同目标分配不同源端口的运营商级 NAT 后方的参与者，无法建立直接的媒体路径，无论您的服务器地址是否为公网地址。通过 TCP 443 或 5349 运行的 TURN，会为他们提供一个中继，其流量对防火墙而言类似普通 Web 流量。Jitsi 的软件包安装默认会配置 coturn，因此其文档中的防火墙规则会开放 UDP 3478 和 TCP 5349。

为什么 BigBlueButton 比 Jitsi Meet 需要多得多的硬件？

因为 BigBlueButton 不只是转发视频。其公布的生产环境要求是 16 GB 内存和 8 个 CPU 核，而 Jitsi 手册中的要求是 8 GB 内存和 4 个 CPU 核。BigBlueButton 在同一台服务器上运行完整的音频会议栈、共享白板和演示层、录制及后处理流水线，以及带用户账户的 Web 前端。它对运行平台也有明确要求：截至 2026 年 8 月，受支持的安装版本是 Ubuntu 22.04 上的 3.0。两组数据都来自各自项目的文档，只能作为起点，不能视为对您实际工作负载的测量结果。