企业官网建设流程全解析

3步跑通到生产：LiveKit 视频会议部署与真实踩坑记录

【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit

一场远程技术面试要求端到端延迟低于300ms，但候选人的网络环境五花八门：公司光纤、手机热点、酒店弱信号。你没法要求对方换网络，抖动只能靠服务端吸收。LiveKit 视频会议部署就是为这类场景准备的：信号与媒体分离走不同端口，服务端只转发不解码重编码，并且可以用 Redis 做跨节点扩展。

为什么选 LiveKit 而不是 Jitsi 或自建 SFU

对比 Jitsi 的一体化会议套件和用 Janus 自建转发服务，LiveKit 的差异在于：Go 语言实现的 SFU（Selective Forwarding Unit，选择性转发单元，即只转发不转码的媒体中转）核心把信号与媒体彻底解耦，分布式路由交给 Redis，且自带全平台 SDK 和 Agents 框架。如果你的团队要自己控制房间逻辑，而不是租一套"成品会议产品"，这个架构的扩展空间明显更大。

最小可运行配置：4步跑通第一个房间

第1步，安装服务端二进制。Linux 上一条命令即可，脚本会拉取最新版本并放入系统路径。

curl -sSL https://get.livekit.io | bash

第2步，用开发模式启动。该模式使用内置的占位密钥对，默认监听信号端口7880，启动日志会直接打印API Key: devkey和API Secret: secret。

livekit-server --dev

第3步，用 CLI 为房间签发一枚访问令牌。令牌是 JWT（JSON Web Token，一种服务端签名、客户端携带的凭证），里面编码了用户身份和房间权限。

lk token create \ --api-key devkey --api-secret secret \ --join --room my-first-room --identity user1 \ --valid-for 24h

第4步，验证服务真的能收发媒体。下面的命令会向房间发布一段循环演示视频，如果你用 SDK 客户端带令牌进入同一房间，应当看到画面，说明信号与媒体链路全部打通。

lk room join \ --url ws://localhost:7880 \ --api-key devkey --api-secret secret \ --identity bot-user1 --publish-demo \ my-first-room

三个高频实战场景

用正式 API Key 替换 devkey

开发密钥只能用于本地，上线前要在配置里注册正式密钥对，完整配置模板可参考 config-sample.yaml。

keys: key1: secret1

重启后，用新密钥签发的令牌正常入会，而旧 devkey 签发的令牌会直接被拒，说明密钥已切换生效。

自定义 UDP 端口范围匹配防火墙策略

WebRTC 媒体流默认走 50000-60000 的 UDP 端口段，很多公司防火墙只放行指定范围，需要显式配置。

rtc: port_range_start: 50000 port_range_end: 60000

在防火墙放行该段后重启，客户端 ICE（Interactive Connectivity Establishment，WebRTC 的 NAT 穿透协商）应能直接建立 UDP 直连，不再回落到 TCP。

Docker 单命令启动并挂载配置

容器化部署时把信号端口、TCP 回退端口和 UDP 媒体段一次性映射出来，配置以卷挂载进容器。

docker run -d --name livekit \ -p 7880:7880 -p 7881:7881 -p 50000-60000:50000-60000/udp \ -v $PWD/config.yaml:/etc/livekit/config.yaml \ livekit/livekit-server \ --config /etc/livekit/config.yaml

执行docker logs livekit看到服务就绪日志、且 7880 端口可访问，即部署成功。

从接入到第一帧画面：一条完整的媒体链路

一个用户带令牌发起入会后，链路是这样走的：客户端先通过 WebSocket 连上 7880 端口，cmd/server/main.go 中的信号与房间管理层校验 JWT、定位或创建房间，多节点部署时这一步会查 Redis 做房间路由；随后客户端发布音视频，pkg/sfu/ 里的 SFU 核心登记这条轨道（Track，一条媒体流的通道），房间内其他参与者订阅后，SFU 把 RTP 包转发到各端 UDP 端口；弱网一侧则由 BWE（Bandwidth Estimation，带宽估计）和 simulcast 降层机制决定下发哪一路质量。

把 SFU 理解成机场换乘枢纽最贴切：每位旅客（数据包）从各自航线（UDP 端口）抵达枢纽，枢纽只负责换乘调度，不拆箱重包装（不解码重编码），所以一台节点能撑住大量并发转发。

常见坑与排错

信号能连上，但两人同房间看不到画面。现象是握手成功、事件正常，唯独媒体不通。原因是 UDP 50000-60000 段未放行，NAT 穿透失败。解法：放行整个端口段；若环境只允许 TCP，配置rtc.tcp_port: 7881并直接暴露在节点上，该端口不能放在负载均衡器或 TLS 之后。

令牌签发成功，客户端却报 401。现象是lk token create无报错，连接时被拒。原因是签名的 api-key/api-secret 与服务端keys段不匹配，或令牌超过--valid-for有效期。解法：核对密钥对一致性，重新签发并给足有效期。

扩到两个节点后，同房间的人互相找不到。现象是房间"时而在时而在"，成员被分到不同节点却无法互通。原因是多节点模式依赖 Redis 做房间路由而未配置。解法：所有节点配置同一 Redis 地址与同一套密钥，路由逻辑见 pkg/routing/。

生产加固要点

• 生成正式 key/secret 密钥对，严禁带着 devkey/secret 上线
• 配置 Redis 启用多节点集群，为跨区部署做准备
• 防火墙放行 UDP 50000-60000，或启用 7881 端口的 ICE over TCP 回退
• 云环境开启rtc.use_external_ip: true，让节点通过 STUN 正确发现公网 IP
• 设置prometheus_port: 6789供 Prometheus 抓取，配合 deploy/grafana/livekit-server-overview.json 面板监控
• 为 webhook 配置 api_key 签名，把房间事件推送到你的后端
• 设置room.empty_timeout与departure_timeout，控制空房间的存活时间

下一步

接上 Redis 部署双节点集群，读 pkg/routing/ 的房间路由实现，搞懂房间如何跨节点分配。

【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit