webrtc2rtmp测试环境搭建：从链路拆解到排查实践

webrtc2rtmp 测试环境的核心，不是把某个转换服务装起来就算完成。真正要测的是四段链路：WebRTC 推流端、转换服务、RTMP 服务端、播放验证端。只要链路里有一段没对齐，画面就会黑屏、卡住，或者推流端看起来连接成功，但服务器里根本没有流。这篇文章会按我搭建测试环境的过程往下拆，适合刚接触 WebRTC 转 RTMP、想在本地或内网验证功能的开发者参考。

很多人以为 webrtc2rtmp 是一个独立软件，装完就能直接跑。实际项目里，它通常是一个转换服务或转发网关，负责接收 WebRTC 的媒体流，再以 RTMP 协议推到流媒体服务端。所以测试环境要覆盖的不只是转换服务本身，还要包括信令服务、媒体端口、RTMP 服务端和播放器。

下面先讲清楚测试环境到底在测什么，再按系统、网络、链路搭建、验证标准和排查顺序一步步拆。

1. webrtc2rtmp 测试环境到底在测什么

1.1 先纠正一个常见误解

先纠正一个常见误解：webrtc2rtmp 不是一个“输入网址，输出 RTMP 地址”的黑盒。它的本质是协议转换，而协议转换一定伴随着几个关键动作：

1. WebRTC 推流端通过信令协商出 SDP，完成 ICE 连接。
2. 转换服务接收 WebRTC 的 RTP 媒体包。
3. 转换服务重新封装成 FLV，并通过 RTMP publish 推到流媒体服务端。
4. 播放端通过 RTMP 或 HTTP-FLV 拉流。

这四步缺一不可。如果只验证了第一步和第三步，很容易出现“推流端显示已连接，但播放端没人任何画面”的情况。这个问题通常在 WebRTC 媒体协商或者 RTMP 推流地址上，而不在转换服务本身。

所以我在搭测试环境时，会把整个链路拆成四个角色，每个角色单独看日志。

1.2 测试链路里的四个角色

如果你第一次搭 webrtc2rtmp 测试环境，建议先建立这个认知：测试环境里通常有四个角色，而不是一个服务。

这四个角色之间，网络端口、协议格式、编码格式都可能成为断点。测试环境的价值，就是把这四个断点提前暴露出来。

1.3 需要验证哪些结果

我在测试时一般会盯住这几个结果：

• WebRTC 信令是否协商成功。
• ICE 是否连通，媒体包是否真正到达转换服务。
• 转换服务是否成功连接到 RTMP 服务端，并 publish 流。
• 播放端能否拉流，是否能同时看到画面和听到声音。
• 长时间运行后，内存、CPU、网络连接是否稳定。

如果这些结果全部通过，说明测试环境的“最小可行链路”已经通了。接下来才能谈参数优化、并发和批量任务。

2. 系统、容器和网络怎么准备

2.1 系统选型与麒麟系统的注意点

webrtc2rtmp 的转换服务，大多数情况下跑在 Linux 上比较省事。实际项目里，Ubuntu、CentOS、麒麟（Kylin）这类系统我都见过。

如果你用的是麒麟这类国产 Linux 发行版，测试环境最需要关注的往往不是转换服务本身，而是依赖源、内核防火墙、SELinux 或者 AppArmor 策略。同一个服务在 Ubuntu 上能启动，到麒麟上可能因为某个系统库缺失或者安全策略导致收不到媒体包。

建议先确认三件事：

1. 项目文档里指定的操作系统版本和依赖版本。
2. 机器上是否已经安装 ffmpeg、ffprobe 这类基础工具。
3. 防火墙和安全策略是否允许 UDP 媒体端口通信。

如果项目没有明确指定系统版本，我一般先选择和部署环境最接近的系统版本，而不是随便拿一台 Windows 机器就跑。Windows 更适合作为播放端和推流端，不太适合作为 webrtc2rtmp 转换服务的验证服务器。

2.2 端口和网络规划

WebRTC 和 RTMP 对端口的要求不太一样。RTMP 通常只走一个固定 TCP 端口，默认是 1935。WebRTC 则相反，信令可能走 HTTPS，媒体流通常走 UDP，而且端口是动态的。

所以在测试环境里，端口规划好看过随意开放。下面是我常用的一组规划方式：

关键点在这里：不要只开 1935 端口。WebRTC 的 UDP 端口没开，推流端会反复尝试连接，表现是“能连上信令，但一直不出流”。

反过来也不要为了省事，直接把防火墙全部关掉。测试环境同样要保留防火墙，只是端口策略可以比生产环境宽松。

2.3 使用容器时的注意事项

不少项目用 Docker 或 Docker Compose 来起依赖服务。容器对 webrtc2rtmp 测试来说很方便，但要注意两个坑：

1. 媒体端口必须映射到宿主机，否则推流端连接不到容器里的 UDP 端口。
2. 容器内临时目录太小，例如/dev/shm容量不足，会影响媒体缓冲。

我见过最典型的问题就是 Docker 只映射了 1935 端口，没映射 WebRTC 的 UDP 端口范围，结果推流端信令连接正常，媒体流却一直无法到达转换服务。

如果只是本地学习，先不用容器，直接用宿主机跑一遍最小链路会更直观。链路通了以后，再考虑容器化。

2.4 客户端准备

测试端最好准备两台设备，或者一台电脑加一台手机。全部在同一台机器上测试，虽然方便，但容易掩盖真实网络问题。

浏览器推流端建议使用 Chrome 或 Chromium。注意 WebRTC 的 getUserMedia 在非 localhost 环境要求 HTTPS 页面，否则浏览器不会授权摄像头或麦克风。如果推流页面部署在局域网 IP 上，需要先把 HTTPS 或者本地域名处理好。

3. 最小链路的搭建和跑通步骤

3.1 先起一个 RTMP 服务端

我习惯先把 RTMP 服务端启动，因为后面的转换服务需要知道往哪里推流。以 SRS 为例，通常有一个配置文件可以直接启动，启动后能看到 1935 端口在监听。

不同项目的配置路径不同，这里不写死某个版本的命令。可以用下面这条命令确认 RTMP 端口是否已经监听：

ss -lntp | grep 1935

如果看到 LISTEN 状态，说明 RTMP 服务端已经就绪。如果没有看到，先检查服务是否启动成功，再看端口是否被占用。

端口被占用的情况也常见。比如本机已经跑了一个 nginx-rtmp，又启动 SRS，两者同时想用 1935，后启动的服务很容易报 bind 失败。遇到这种情况，不要直接改系统防火墙，先确认哪个服务占用了 1935。

3.2 启动 webrtc2rtmp 转换服务

RTMP 服务端就绪后，再启动 webrtc2rtmp 转换服务。转换服务一般需要一个配置项，用于指定 RTMP 推流地址，例如：

./webrtc2rtmp --rtmp=rtmp://127.0.0.1:1935/live/test

如果项目采用配置文件方式，就把 RTMP 地址配置到这个值。这里的重点是：推流地址里的流名称，也就是test这个部分，决定了播放时用哪个地址去拉流。

启动后先看日志。正常情况下，转换服务会显示类似这样的过程：

• 信令服务连接成功。
• 收到 WebRTC 会话请求。
• SDP 协商完成。
• ICE 连接建立。
• 开始向 RTMP 服务端 publish。
• 输出流已发布。

如果你看到“publish 成功”之类的日志，说明转换服务到 RTMP 服务端这一段已经通了。如果没有，先看 RTMP 地址、端口和鉴权参数是否正确。

3.3 从浏览器发起 WebRTC 流

转换服务起来之后，再打开项目自带的 WebRTC 推流页面。如果项目里有示例 Demo，一般会提供一个“开始推流”按钮。

点击之后，浏览器会请求摄像头或麦克风权限。如果测试的是屏幕分享，还要在浏览器的分享弹窗里选择屏幕或窗口。

推流启动后，回到转换服务日志，观察是否出现新的会话记录。如果日志里能看到收到媒体包的计数，说明 WebRTC 推流端已经和转换服务建立了媒体连接。

这里要特别注意：浏览器推流页面不能随便放在一个 HTTP 域名下。如果页面不是 localhost，浏览器很可能因为非安全上下文而拒绝获取音视频设备。这会表现为“点击按钮没反应”或者“权限弹窗一闪而过”。

3.4 播放验证

推流成功后，用播放端拉流验证。最简单的命令是：

ffplay rtmp://127.0.0.1:1935/live/test

如果没安装 ffplay，也可以用 VLC 打开网络流，输入相同地址。能出画面、有声音，说明整条链路已经通了一半。

还可以用 HTTP-FLV 再验证一次。如果 RTMP 服务端开启了 HTTP-FLV，播放地址会形如：

ffplay http://127.0.0.1:8080/live/test.flv

具体端口以你的服务端配置为准。HTTP-FLV 验证有一个好处，它能说明 RTMP 服务端已经把流转换成浏览器可以直接播放的协议格式，这对后续接入 Web 播放器很有参考价值。

4. 测试用例、参数和验收标准

4.1 从低参数开始跑

第一次跑通，不要用 4K、不要用超高码率、不要开多路并发。我一般会先把参数控制在一个稳妥范围：

为什么要先用低参数？因为链路调试时，变量越少越好。用 720p、2Mbps、25fps 跑通，比用 1080p 高码率更容易区分“协议问题”和“性能问题”。

如果你的测试机器比较老，或者用的是虚拟机，更要压低分辨率和码率。机器配置偏低的情况下，转封装服务可能因为 CPU 转码或者内存不足而卡顿。这个锅不能甩给协议转换本身。

4.2 不要只看“能不能出画面”

能出画面只是一个最低标准。测试环境要验证的内容还包括：

• 画面是否花屏或花帧。
• 声音是否清晰，是否有卡顿。
• 音画是否同步。
• 播放端延迟是否一直涨。
• 长时间运行后内存和 CPU 是否异常上升。

判断音画同步，不需要精确仪器，可以用手机计时器或者画面里放一个秒表，录制一小段，播放时看画面和声音是否对得上。这个办法很土，但在测试环境里足够暴露明显的同步问题。

延迟也是一个重要判断点。WebRTC 本身是低延迟协议，但经过转换服务和 RTMP 分发后，延迟会明显比 WebRTC 高。不要用 WebRTC 的延迟预期来要求 RTMP 链路。你要关注的是延迟是否稳定，而不是绝对数值是否最小。

4.3 长期稳定性测试

单次推一个 30 秒的视频，能出画面，不代表服务稳定。我建议至少跑一轮 30 分钟的连续推流，观察这几个指标：

如果 30 分钟还看不出来问题，可以继续跑一小时。但一般测试环境里，30 分钟已经能暴露大部分连接不稳定、内存泄漏和日志风暴问题。

4.4 建议整理的测试用例

开发阶段的测试环境，不需要一次把所有场景跑完，但至少要有下面几类用例：

1. 单路浏览器推流，验证最小链路。
2. 切换分辨率或码率，验证参数变化。
3. 纯视频无音频，验证音频缺失时是否影响推流。
4. 推流中途断网或关闭页面，验证服务是否能正常释放资源。
5. 掉线后重新推流，验证新会话是否覆盖旧会话。

为什么要有这些用例？因为转换服务最容易出问题的点，不只是协议转换，还有状态管理。旧会话没有释放、新会话推不进去、日志里出现大量残留连接，这些都是在多次推流和断流之后才会暴露的。

5. 常见失败和排查顺序

5.1 连接成功但无画面

这是 webrtc2rtmp 测试环境里最常见的问题。现象是推流端显示已连接，转换服务也有会话日志，但播放端没有任何画面。

我建议先看编码格式。WebRTC 推流端可能使用的是 VP8 或 VP9，而 RTMP 服务端或播放器不支持，导致画面出不来。可以在转换服务配置里要求推流端使用 H.264，或者在转换服务里做转码。具体用哪种方式，看项目设计。

还有一种情况是 SDP 协商里没有正确协商出视频轨。很多项目支持纯音频推流，如果你测试时只授权了麦克风，没有授权摄像头，播放端当然没有画面。

5.2 有画面但没声音

有画面没声音，通常不是网络问题，而是音频编码不匹配。

WebRTC 默认音频编码常用 Opus，但 RTMP 服务端和播放器对 Opus 的支持不一定完整。有些测试环境里，播放端能解码 H.264 视频，却无法解码 Opus 音频。这时需要检查转换服务是否把 Opus 转成 AAC，或者播放端是否支持对应音频格式。

判断方法很简单：先用 VLC 播放，看播放器日志里有没有音频解码相关报错。再用 ffprobe 查看流信息：

ffprobe rtmp://127.0.0.1:1935/live/test

输出里会显示视频编码和音频编码。看到音频编码不是预期值，问题基本就定位了。

5.3 延迟越来越高

RTMP 播放延迟逐渐上涨，常见原因不是协议转换本身，而是播放端缓冲策略和服务端缓存配置。

测试时可以先查看播放端是否在持续缓存。如果延迟稳定在一个固定值，说明是正常缓冲；如果延迟一直线性上涨，可能是播放器没有正确消费数据，也可能是服务端 FLV 缓存队列过长。

这个时候不要急着改转换服务的参数，先确认是拉流端问题还是推流端问题。可以换一个播放器验证，比如从 VLC 换成 ffplay，或者从 RTMP 换成 HTTP-FLV。如果换完延迟恢复正常，说明问题在播放器或协议选择上，而不在 webrtc2rtmp 转换链路里。

5.4 推流端频繁断连

推流端频繁重连，先看网络环境，再看防火墙。

WebRTC 对 UDP 端口要求比较敏感。如果防火墙只开放了 1935，WebRTC 媒体包可能无法到达转换服务，导致推流端不断重试。其次，NAT 环境下如果 STUN 和 TURN 配置不完整，也会导致连接不稳定。

我一般会分两步排查：第一步看信令服务日志是否正常，第二步用抓包工具或tcpdump看 UDP 包是否到达服务器。如果 UDP 包到了，再往上查转换服务是否正确处理。如果 UDP 包根本没到，重点检查防火墙、安全组和 UDP 端口映射。

5.5 我建议的排查顺序

遇到问题，不要先把参数改来改去。先按顺序排查：

1. 看现象：是黑屏、花屏、没声音、断连，还是延迟上涨。
2. 看服务和推流端日志：找出第一条异常日志。
3. 看网络连接：确认 1935 和 WebRTC UDP 端口是否连通。
4. 看媒体编码：用ffprobe检查实际输出流的编码格式。
5. 看资源占用：CPU、内存、磁盘是否异常。
6. 看安全策略：SELinux、AppArmor、防火墙是否拦截了服务。

这个顺序看上去简单，但很管用。很多“webrtc2rtmp 转换失败”的报错，最后查出来是 RTMP 地址填错、防火墙没开 UDP 端口，或者推流页面没有使用 HTTPS。

6. 测试环境验收清单和后续扩展

6.1 测试环境验收清单

一个 webrtc2rtmp 测试环境能不能算搭完，我建议按这个清单验收：

• [ ] RTMP 服务端能正常启动，1935 端口在监听。
• [ ] 转换服务能连接信令服务，日志里没有明显报错。
• [ ] 浏览器推流成功后，转换服务能看到媒体会话。
• [ ] 播放端能通过 RTMP 地址拉到流。
• [ ] 播放端能通过 HTTP-FLV 地址拉到流。
• [ ] 画面和声音正常，音画同步可接受。
• [ ] 连续推流 30 分钟，内存和 CPU 没有异常增长。
• [ ] 关闭推流页面后，服务能释放会话，日志里的连接数回落。
• [ ] 重启转换服务后，重新推流能正常恢复。

这份清单不一定需要一次全部通过，但每一条都应该能明确回答“通过了”还是“没通过”。不要用“好像能出画面”这种模糊结论来验收。

6.2 从单路测试到并发和多路流

单路链路跑通之后，很多人会立刻想并发测试。我的建议是：先不要开太多路。

并发测试前，先确认三件事：

1. 转换服务是否支持多路会话。
2. RTMP 服务端是否支持多路 publish。
3. 你的测试机器 CPU、内存、带宽是否够用。

如果这三项都满足，再逐步增加并发路数。从 1 路加到 2 路，再到 5 路，每次都要观察 CPU、内存、日志和播放端稳定性。不要一次性加到 20 路，否则出了问题根本分不清是哪一路导致的。

并发场景里，更常见的问题不是协议转换，而是资源分配。比如每路会话的内存泄漏、日志文件无限增长、RTMP 服务端连接数达到上限。这些都需要通过测试环境提前暴露。

6.3 建议补充自动化验证

如果这个测试环境要长期使用，建议把重复操作脚本化。至少可以写一个简单的测试脚本，完成三步：

1. 启动 RTMP 服务端。
2. 启动转换服务。
3. 自动发起一路 WebRTC 推流。

自动化脚本不需要一开始做得很完整，能帮你减少手动操作的重复性就好。真正重要的是，每次测试的步骤和参数保持一致。这样当问题出现时，你能复现，也能对比。

测试过程中，所有服务的关键日志最好统一放到一个目录下，并在日志里带上时间戳。我看到不少项目失败，不是因为功能不行，而是因为日志分散在多个终端窗口里，出问题后很难拼出完整调用链。

6.4 生产化前要考虑的边界

最后说一个边界问题。测试环境能跑通，不代表生产环境一定能稳定运行。webrtc2rtmp 转换服务如果要从测试走向生产，至少还要考虑这些事：

• 推流地址的鉴权与流名称策略。
• RTMP 服务端的集群和持久化配置。
• 转换服务的高可用和故障转移。
• 会话级监控指标，例如在线路数、推流时长、错误码。
• 日志采集和告警。

这些不是测试环境阶段必须解决的问题，但你在搭测试环境时就要留出扩展空间。比如测试环境里尽量用配置项管理 RTMP 地址，而不是写死在代码里；日志尽量按日期切分，而不是无限写到同一个文件。

很多人会在测试环境里为了省事把防火墙关掉、把日志级别调到最低、把所有服务跑在 root 权限下。短期看确实省事，但长期看，这些操作会让测试环境的结论失真。一个在关闭防火墙的 root 容器里跑通的链路，到了真实部署环境里，往往第一轮就翻车。

我个人更建议，先把单路最小链路跑稳，再逐步加参数、加并发、加自动化验证。webrtc2rtmp 测试环境最怕的不是功能不支持，而是链路里有一环你没有看到。把每一环的日志和验证标准都记录下来，测试环境的真正价值才能发挥出来。