vMix现场直播推流到网页：RTMP转HLS/FLV配置与排障

1. 把链路拆开看：vMix 到浏览器之间真正缺的那一环

做线下活动导播的人基本都遇到过一个很具体的场景：现场用 vMix 切完机位、叠了字幕条、加了画中画，返送屏上一切正常，主办方转头问一句“能不能放到网页上，让外地同事直接在浏览器里打开就看”。这时候你会发现 vMix 本身并不产出“一个网页直播间”，它产出的是一路持续变化的音视频数据流。vMix 编辑输出的视频要嵌入网页直播，核心动作其实只有一句话：把 vMix 编码出来的实时流，交给一个能被浏览器识别的传输协议去分发。想明白这句话，后面的所有配置都只是填空。

这篇内容面向三类人：手里已经有 vMix、能正常切画面的现场导播；需要把活动现场信号挂到自己网站或活动页面前端工程师；以及被临时拉来救火、只要求“明天上午十点能看”的运维同学。不管你是哪一类，看完都应该能独立把一条从采集端到浏览器播放器的链路搭起来，并且知道每个参数为什么这么填。

先说清楚 vMix 在整条链路里究竟站在哪个位置。它在链路里承担的是“采集—切换—合成—编码”这四件事，输出的是一个已经压缩好的码流。而浏览器能直接消费的东西非常有限：要么是一个.m3u8播放列表（HLS），要么是一个.flv长连接（HTTP-FLV），要么是一路 WebRTC 会话。这三样东西 vMix 一个都不直接给，所以中间必然存在一个“协议转换 + 分发”的环节。很多人卡住不是因为不会点 vMix 的按钮，而是没意识到这个中间环节必须存在，试图在 vMix 里找一个“生成网页”的开关，翻遍设置也找不到。

我见过最典型的误区是：把 vMix 的输出当成“文件”。vMix 确实可以录制，录出来是 mp4，但录播文件丢到网页上不是直播，观众看到的是延迟几分钟的“准直播”，互动完全没法做。另一个误区是以为局域网能预览就等于公网能播，vMix 较新版本内置了基于浏览器的输出预览能力，同一网段用手机打开确实能看到画面，但它面向的是现场监看，并发能力、鉴权、公网带宽、移动端兼容性全都不在设计目标里，直接拿来做对外直播，十个人同时打开就会开始转圈。

1.1 为什么中间必须有一个“转封装”角色

压缩后的音视频数据本身是一串连续的字节，问题是不同协议对这串字节的“包装方式”完全不同。RTMP 用的是基于 TCP 的块传输，HLS 是把流切成一个个几秒的小文件放在 HTTP 服务器上，WebRTC 走的是 UDP 上的 RTP。vMix 最擅长、也最稳定的输出方式是把流推给一个 RTMP 地址，这是它内置编码器最成熟的一条路径。而浏览器最擅长的是发 HTTP 请求拿文件或者拿长连接。

中间这个角色做的事情，学术上叫转封装或转协议，通俗点说就是“把自来水厂的管道接进你家水龙头”。它不改变水质（不重新编码），只是换一种接法。这一层通常由一个流媒体服务承担，负责接收推流、切片或转协议、再通过标准 HTTP 提供给前端。理解这一点之后你会发现，选型的本质是选“中间这层用什么”，而不是选 vMix 怎么设。

也因此，中间层放在哪儿会直接决定延迟和成本。放在本地一台闲置机器上，局域网观看延迟很低，但公网观众进不来；放在有公网带宽的服务器上，任何人能看，但带宽账单会很实在；交给第三方分发网络，省心但需要额外配置回源和鉴权。这三条路我在不同项目里都走过，后面会分别讲清楚各自的门槛。

1.2 三条主流路线摆在台面上对比

真正可落地的方案就那么几种，我把它们拆成一张表，你按现场条件对号入座就行。

路线 A 是绝大多数人的第一选择，原因很朴素：稳、兼容性最好、几乎所有浏览器和手机都认 HLS，iOS Safari 甚至原生支持，连播放器库都不用引。代价就是延迟，HLS 本质是“切片 + 缓冲”，你不可能既要切片又要零延迟。路线 B 是我个人在内部场景里最常用的，延迟压到三五秒，主持人说一句话，弹幕里三秒后就有反应，互动感完全不一样，缺点是依赖服务端支持 FLV 长连接，且部分老旧设备兼容性略差。

路线 C 适合那种“必须实时对话”的场景，比如远程嘉宾点评。SRT 本身是为不稳定网络设计的传输协议，抗丢包能力强，vMix 较新版本已经内置 SRT 输出。不过它的配置复杂度明显高一档，要处理端口映射、加密口令、以及对端是否支持。路线 D 只适合现场，前面已经说过它的问题，这里再强调一次：局域网能看不等于能对外直播，这两件事的技术要求差了一个量级。

1.3 延迟、成本、并发这个三角，你只能选两条

这句话听着像废话，但在实际项目里它是最有用的一句。4 Mbps 的 1080p 码流，一百个人同时看，理论出口带宽就是 400 Mbps，这个数字摆在任何一台单机服务器面前都不现实，而且这还是不考虑突发和重传的理想值。所以一旦观众规模超过几十人，第三方分发基本是绕不开的。

反过来，如果只是十几个人的内部评审，你自己一台带宽 20 Mbps 的小机器跑起来绰绰有余，完全没必要上分发网络，配置还简单。我在一个小型项目里试过用一台 2 核 4G 的机器承接三十人观看的 720p 流，CPU 占用不到 30%，跑了一整天没出问题。所以别一上来就堆资源，先把观众数量算清楚。

延迟这边同理。你要先问清楚业务方：“晚十秒能接受吗？”多数公开活动答案是能，那就老老实实 HLS，别折腾低延迟；只有明确的互动需求，才值得为 WebRTC 或 LL-HLS 付出额外的配置成本和兼容性代价。把这个问题在动手之前问出来，能省掉后面一大半返工。

2. 输出侧怎么定参数：编码器、码率、关键帧一个都不能拍脑袋

vMix 里有两个容易混淆的概念，我见过不少人在这上面栽跟头：Output和Stream。Output 是给外部设备或 NDI 用的那一路，你可以在设置里把 Output 1 设成全屏、NDI、SRT 等；Stream 才是真正做编码推流的那一路，有独立的编码参数。很多人跑去 Output 面板里找推流地址，找半天找不到，就是因为这两个是分开的模块。

实际操作路径是：打开 vMix 设置，进到输出相关的面板，找到 Stream 分页。vMix 支持多路 Stream，也就是最多四路同时推，每一路可以设不同的分辨率、码率和目标地址。这个能力非常关键，后面讲多码率自适应时会用到，它能让你在服务端完全不转码的情况下同时提供高清和标清两路，省掉大量 CPU。

推流目标选 Custom RTMP Server，地址填rtmp://live.example.com/live，Stream Key 填program（这个值要和中间层的应用名对上）。填完点开始，面板上会显示连接状态、已推时长、当前码率和丢帧计数。这个面板是你排查问题的第一现场，推不上去的时候先看它，比在后面瞎猜快得多。

2.1 分辨率与帧率：先问播出终端是什么

现场制作很容易陷入“越高越好”的冲动，4K 采集、4K 输出，结果推流端一压，画质还不如老老实实 1080p。原因很简单：推流码率是有限的，同样的码率下，分辨率越高，每个像素分到的比特越少，压缩痕迹越明显。1080p 用 4 Mbps 和 4K 用 4 Mbps，观感差距是非常直观的。

我的经验判断是：观众主要在手机上看，1280×720 就够，把码率省下来给稳定性和并发；观众在电脑大屏上看，1920×1080 起步；只有明确要求投大屏或做素材留存，才考虑更高分辨率。帧率同理，25 或 30 帧覆盖 95% 的场景，访谈、讲座、产品演示都够用；只有体育赛事、舞蹈、游戏这类快速运动内容才需要 50 或 60 帧，而且帧率翻倍意味着码率至少要提高 30% 到 50% 才能维持同等画质。

还有一个细节常被忽略：vMix 工程本身的帧率要和推流帧率一致。如果采集卡是 60 帧输入，工程设 30 帧，vMix 会做帧率转换，画面里快速横移的物体会出现轻微抖动。这不影响能不能播，但影响观感，属于“能优化就该优化”的项。

2.2 码率不是越大越好，算一下上行余量

码率的确定有一套很朴素的算法：先查经验值，再看上行带宽，最后取两者较小值再打八折。

为什么上行建议要留出接近一倍余量？因为推流是持续性的，网络不是恒定的。你按 4.7 Mbps 配了一条刚好 5 Mbps 的线路，只要中间出现几秒钟的波动，vMix 就会开始丢帧，观众看到的是画面卡一下、声音断一下。留余量就是给波动留缓冲空间。

单路推流之外，如果你打算同时推高清和标清两路，上行带宽要按两路之和再乘 1.3 来算。比如 1080p 那路 4.7 Mbps 加上 480p 那路 1.4 Mbps，加起来 6.1 Mbps，建议上行至少 8 Mbps。现场做这个预算的时候，千万别拿“测速软件跑出来的峰值”当依据，要用持续上传测试的稳定值。

2.3 关键帧间隔为什么必须卡在 2 秒

这是我踩过最多次坑的一个参数。关键帧（I 帧）是完整画面，播放器从任意位置接入时，必须等下一个关键帧才能出画面。HLS 切片是按关键帧切的，如果你的关键帧间隔是随机的或者特别长（比如 10 秒），切片就会变得又大又不均匀，观众打开页面要等很久才有画面，切换清晰度时也会黑屏好几秒。

标准做法是把关键帧间隔固定为 2 秒，也就是帧率乘以 2：30 帧的流设 60，25 帧的流设 50。这样 HLS 切 4 秒的片，每片正好包含两个关键帧，切片边界整齐，首帧加载快，多码率切换也顺滑。在 vMix 的 Stream 高级设置里能找到关键帧间隔或 GOP 的选项，有些版本把它藏在自定义编码参数里，需要手动填。如果面板上找不到，可以在推流地址后面加参数，或者干脆用 vMix 自带的编码预设，它默认就是这个值。

顺带说一个相邻问题：B 帧。B 帧能提高压缩效率，但会增加编码延迟，而且某些低延迟播放器处理不好。直播场景我一般把 B 帧设成 0 或者最多 2，宁可牺牲一点压缩率换稳定。这个参数在 vMix 里通常不暴露，走默认即可，不用专门去调。

2.4 音频参数和音画同步，翻车重灾区

音频被轻视的程度远超它应得的。视频糊一点观众能忍，声音断断续续或者和画面差半秒，投诉立刻就来。

参数上没什么可纠结的：AAC-LC、48 kHz 采样率、立体声、128 kbps。这个组合兼容性最好，从老旧安卓机到 iOS 到桌面浏览器全都认。不要用 AC-3，浏览器不支持；不要用太低的采样率，44.1 kHz 在某些采集链路里会引起重采样，反而更容易出问题。

音画同步的问题通常不出在编码环节，而出在采集环节。摄像机通过采集卡进来，音频走调音台另一路进来，两条链路的延迟天然不同，可能差几十毫秒到几百毫秒。vMix 里有音频延迟补偿的设置，可以按毫秒调整某一路音频，把它对齐到画面。判断方法很直接：让现场拍手，看画面里手合上的瞬间和听到声音的瞬间是否同步，差多少就补多少。

还有一个隐蔽的坑：如果音频源在 vMix 里被设成了“跟随某个输入”，而你中途把这个输入切走了，音频可能会跟着断。稳妥做法是把音频单独固定到总输出，别让它跟着画面切换乱跑。这个设置在现场彩排时一定要试一次切换，别等正式开播才发现。

3. 中间层搭建：让 vMix 推出来的流变成浏览器能吃的格式

这一层是整个链路的技术核心。你要做的事情是：接收 RTMP 推流，把它转成 HLS 或 HTTP-FLV，再通过 HTTP 提供给前端。可选的开源方案不少，思路大同小异，我这里按“能跑起来”的顺序讲一遍完整配置，你照抄改域名就行。

服务器准备上，最低配一台 2 核 4G、带宽按并发算的机器就能起步。系统装常见的 Linux 发行版，开放两个端口：1935 给 RTMP 推流用，80 或 443 给 HTTP 分发用。如果走 HTTPS（现在基本是必须的，后面会讲原因），记得提前把证书配好，因为网页如果是 https，加载 http 的流会被浏览器直接拦掉。

3.1 协议选择：HLS 做底，FLV 做体验

HLS 的优势是普适，几乎所有浏览器、所有手机、所有智能电视都支持，而且它基于普通 HTTP 文件请求，能直接套 CDN，扩容几乎无痛。缺点是延迟，标准 HLS 的延迟是“切片时长 × 播放列表长度 + 播放器缓冲”，三片 4 秒加上缓冲，十几二十秒很正常。

HTTP-FLV 的优势是延迟低，它是把 FLV 标签通过 HTTP 长连接持续推给播放器，不需要等切片，两到五秒就能出画面。缺点是依赖服务端模块支持，而且它不是标准协议，播放器得用专门的库。另外它在移动端的兼容性不如 HLS，部分浏览器对长连接的处理会有问题，比如切后台再回来需要重连。

我的常规做法是两条都开：桌面端优先用 FLV 拿低延迟，移动端和兼容性存疑的环境回落到 HLS。这个降级逻辑在前端几行代码就能写完，成本很低，收益很明显。

3.2 一份可以直接抄的配置

用常见的开源流媒体服务来搭，核心配置大概是这样（以 RTMP 模块 + HLS 输出为例）：

worker_processes auto; events { worker_connections 1024; } rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # HLS 输出 hls on; hls_path /var/www/hls; hls_fragment 4s; hls_playlist_length 20s; hls_cleanup on; hls_nested on; # 只允许本机或指定来源推流 allow publish 127.0.0.1; allow publish 203.0.113.10; deny publish all; # 允许任意来源拉流 allow play all; } } } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name live.example.com; ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/privkey.pem; location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } root /var/www; add_header Cache-Control no-cache; add_header Access-Control-Allow-Origin *; } } }

几个地方值得单独说。hls_fragment 4s是切片时长的下限，实际切片由关键帧触发，所以前面强调的 2 秒 GOP 在这里起作用——关键帧对齐了，切片才会整齐。hls_playlist_length 20s决定播放列表里保留几个切片，太长会增加延迟，太短会让网络差的观众频繁卡顿，20 秒是个折中值。add_header Access-Control-Allow-Origin *这行如果你漏了，前端页面和流不在同一个域名下就会直接报跨域错误，画面永远出不来，而控制台报错信息又很含蓄，新手极容易卡在这里。

allow publish那几行是安全底线。不设限制的话，任何人知道你的地址都能往你的服务器上推流，把你辛苦搭的分发通道变成别人的免费通道。至少要把推流来源限制成现场固定出口 IP，如果现场 IP 不固定，就用推流密钥校验的方式，多数服务端都支持。

3.3 多码率：优先在 vMix 侧解决

很多人一想到多码率就想到服务端转码，其实 vMix 的多路 Stream 才是更省事的路子。你可以在 vMix 里开两路 Stream，一路 1080p 4.5 Mbps，一路 720p 2.5 Mbps，分别推到服务端的两个应用，比如live/hd和live/sd，服务端只做切片不做转码，CPU 占用几乎为零。

代价是上行带宽翻倍，所以这条路适合现场有专线或者上行充裕的情况。如果上行紧张，那就只能在服务端转码，但一定要评估 CPU：软件转一路 1080p 到 720p，在普通云主机上大概吃满一到两个核，转两路以上就得考虑用带硬件编码的机型。

多码率还需要一个主播放列表，把两路流的地址写在一起，播放器才能自动切换。手写一个master.m3u8就可以：

#EXTM3U #EXT-X-VERSION:3 #EXT-X-STREAM-INF:BANDWIDTH=4800000,RESOLUTION=1920x1080 hd/program.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2700000,RESOLUTION=1280x720 sd/program.m3u8

BANDWIDTH要填得比实际码率略高一点，播放器会根据这个值和当前网速决定切哪一路。填得太保守会导致明明网速够却一直停在低清，填得太夸张会在网络波动时频繁切换，看得很闹心。

3.4 鉴权：播放地址不能裸奔

公开活动还好，内部会议、付费内容就必须控制谁能看。最简单的做法是给播放地址加一个有时效的签名，前端请求时带上，服务端校验签名和过期时间。签名内容一般包括路径、过期时间戳，再加一个只有服务端知道的密钥做哈希。

这个逻辑不必自己写，多数流媒体服务和反向代理都支持。核心原则是：推流密钥绝对不能出现在前端代码里，播放地址也不要长期有效。我见过有人把推流地址直接写死在活动页面的 JS 里，任何人打开开发者工具就能拿到，后果就是被人拿去推别的内容。这种低级错误一旦发生，排查起来非常难受，因为从服务端看推流是正常的，只是内容不对。

4. 网页端落地：播放器选型与几行关键代码

到了前端这一层，工作量比想象中小。核心就是选一个播放器库，把流地址喂给它，再处理几个兼容性细节。

4.1 播放器怎么选，看你的协议组合

如果是标准的 HLS 方案，直接用 hls.js 就够了，它会在不原生支持 HLS 的浏览器上做解析，在 Safari 上则可以直接交给原生播放。判断逻辑我一般这么写：

<video id="player" controls autoplay muted playsinline style="width:100%;max-width:1280px;background:#000"></video> <script src="/static/hls.min.js"></script> <script> (function () { var video = document.getElementById('player'); var src = 'https://live.example.com/hls/program.m3u8'; if (video.canPlayType('application/vnd.apple.mpegurl')) { // Safari / iOS 原生支持 video.src = src; } else if (window.Hls && window.Hls.isSupported()) { var hls = new window.Hls({ liveDurationInfinity: true, // 直播模式下不按点播算时长 maxBufferLength: 10, // 缓冲上限，压低延迟 maxMaxBufferLength: 20, manifestLoadingTimeOut: 8000, manifestLoadingMaxRetry: 4 }); hls.loadSource(src); hls.attachMedia(video); hls.on(window.Hls.Events.ERROR, function (evt, data) { if (data && data.fatal) { switch (data.type) { case window.Hls.ErrorTypes.NETWORK_ERROR: hls.startLoad(); // 网络抖动，重新拉流 break; case window.Hls.ErrorTypes.MEDIA_ERROR: hls.recoverMediaError(); break; default: hls.destroy(); break; } } }); } else { video.outerHTML = '<p>当前浏览器不支持该播放格式，请更换浏览器。</p>'; } })(); </script>

autoplay和muted必须同时出现，这不是可选项。现代浏览器普遍禁止带声音的自动播放，只写 autoplay 会被静默拦截，画面停在第一帧不动，用户以为流挂了。加上 muted 之后自动播放就能过，再提供一个“点击开启声音”的按钮让用户主动解除静音，这是目前最通行的做法。playsinline则是为了防止 iOS 上一播放就强制全屏，那个体验在嵌入页里非常糟糕。

maxBufferLength这个参数值得单独说。HLS 播放器默认会往前缓冲比较长的时间，网络一波动它就想多存点货，结果延迟越积越大，播了半小时之后延迟可能到一分钟。把这个值压到 10 秒左右，延迟能稳定在一个可接受的区间。代价是网络差的时候更容易卡，所以要根据实际网络条件微调，不要无脑往小里设。

4.2 嵌入已有页面：iframe 还是直接放 video

如果活动页是别人维护的，你只负责提供一路流，最省事的是给对方一个独立的观看页地址，让他用 iframe 嵌进去：

<iframe src="https://live.example.com/watch/program" style="width:100%;aspect-ratio:16/9;border:0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen> </iframe>

allow这个属性必须写，尤其autoplay。默认情况下 iframe 里的自动播放是被禁止的，即使里面加了 muted 也不行，必须有父页面显式授权。这个坑很隐蔽，因为你在自己页面里直接打开是正常的，一嵌到别人页面就变成一帧静止画面，两边互相甩锅。

aspect-ratio也是我强烈建议用的。用固定高度做视频容器的老办法在移动端会变形，用 aspect-ratio 让高度跟着宽度走，竖屏横屏都不会出问题。如果要兼容很老的浏览器，就得用 padding-top 百分比的老套路，现在基本不需要了。

4.3 一个容易被忽略的点：https 页面不能加载 http 流

现在活动页基本都是 https，而你的流地址如果还是http://，浏览器会把它当作混合内容直接拦掉，控制台报一个 mixed content 的警告，画面永远是黑的。这个问题在新手那里发生频率极高，因为本地测试的时候用的是 http 页面，一切正常，上线换成 https 就挂了。

解决办法只有一条：给流地址也配上证书，走 https。用反向代理把 443 转发到内部的 HTTP 服务即可，配置不复杂，但一定要在彩排阶段就验证，别在开播前十分钟才发现。

5. 排障实录：从推流到播放的一条检查链

直播这行的特点是问题一定会在最不该出现的时候出现，所以排查顺序比排查技巧更重要。我一般按“从后往前”或者“从前往后”走一条固定链路，不跳步，这样最慢五分钟能定位到环节。

5.1 固定检查链：五步定位法

第一步，看 vMix 的 Stream 面板状态。是不是绿色的“Streaming”，已推时长在增长，丢帧计数是不是 0。如果状态是红色的或者一直在重连，问题在推流侧：地址写错、密钥不对、端口被封、上行带宽不够。这一步能在十秒内排除掉一半的可能性。

第二步，在服务器上看有没有收到流。查流媒体服务的日志，或者直接看切片目录里有没有新的 ts 文件在生成。如果 vMix 显示推流成功但服务器上没文件，那多半是应用名对不上，rtmp://host/live里的live和配置里的application live必须完全一致，多一个斜杠都不行。

第三步，用播放器直接打开播放地址。拿 VLC 或者浏览器直接访问 m3u8，绕开你自己的网页。这一步能区分“流本身有问题”和“网页代码有问题”。VLC 能播而网页不能，问题就在前端或者跨域；VLC 也播不了，问题在服务端或者编码。

第四步，看浏览器控制台。网络面板里看 m3u8 请求是不是 200，ts 请求是不是 403 或 404，控制台有没有 CORS 报错。跨域和权限这两类问题在这里一目了然，不用猜。

第五步，看编码参数是否被浏览器接受。如果前面都正常但画面就是黑的，检查是不是用了浏览器不支持的编码。H.264 是安全牌，H.265 在多数浏览器上直接不支持，音频用 AC-3 同理。这种情况在 VLC 上可能能播，因为 VLC 解码器全，浏览器就未必。

5.2 常见问题速查表

5.3 几条踩出来的经验

别在开播前十分钟改参数。这句话听起来像废话，但我真的见过有人在开场前把码率从 4M 调到 6M，结果上行扛不住，前十分钟全是卡顿。所有参数调整必须在彩排时完成，正式开播只做“开始推流”这一个动作。

提前半小时推流预热。有些分发网络对新建的流有缓存预热过程，第一分钟可能拉不到。提前推上去，让流先跑一会儿，正式开始时观众点开就是秒开。这个习惯养成之后，开场事故率能降一大截。

准备一路本地录制备份。vMix 在推流的同时可以录制，把整场录下来。万一网络中途彻底断了，至少还有完整素材可以事后补发。这个成本几乎为零，收益极大。

观众端的网络差异比你想象的大。你在办公室千兆网络下测得很顺，观众可能在地铁上用手机看。所以多码率不是奢侈品，是必需品。哪怕只做高清和标清两路，体验差距也非常明显。

注意 vMix 工程里的音频是否被静音。这个错误低级到不好意思写出来，但发生频率真的不低：画面切得好好的，推流也正常，就是没声音，最后发现是某一路输入的音频被误关或者总线被静音。彩排时一定要用另一台设备实际听一遍。

6. 上线前的压测与一份可执行的检查清单

链路搭通不等于能上线。我见过太多“本地测试完美、正式开播崩盘”的案例，共同点都是没做压测。压测不需要多专业，找几个不同网络环境的人同时打开观看页，看十分钟，观察三件事：开播到出画面的时间、十分钟内卡顿次数、延迟是否在持续增长。这三项都过关，基本就稳了。

如果条件允许，用工具模拟二三十个并发拉流，同时观察服务器 CPU、内存、出口带宽和磁盘写入。HLS 的磁盘写入量不小，切片一直在生成和清理，磁盘 IO 打满会导致切片延迟，进而让所有人都卡。这个指标很多人不看，出了问题时又很难联想到。

我平时用的一份上线检查清单，可以直接拿去改：

• 推流地址和密钥是否正确，是否已限制推流来源 IP
• 视频编码 H.264、音频 AAC-LC 48kHz，关键帧间隔 2 秒
• 多码率是否配置，主播放列表能否正常解析
• 服务端切片目录权限是否正确，磁盘剩余空间是否充足
• 播放页在 https 下能否正常加载，跨域头是否配置
• 桌面 Chrome、Safari、iOS、安卓各测一遍
• iframe 嵌入场景单独测一次自动播放
• 断流后能否自动恢复，恢复时间是多久
• 录制是否同时开启，录制文件路径是否有空间
• 现场专线的实际上行是不是持续测过，不是峰值测速

关于断流恢复，这个点值得多说一句。现场网络偶尔会瞬断一两秒，vMix 会自动重连，但服务端那边可能已经把流标记为结束，播放列表停更，观众端就卡在那里不动了。解决办法是在前端加一个检测：如果播放列表超过一定时间没更新，就重新加载播放地址。hls.js 里监听错误事件重新 startLoad 就能覆盖大部分情况，我上面那段代码里已经写了。这个小逻辑看着不起眼，实际能救回不少场次。

最后分享一个我个人很受用的小技巧：在 vMix 里做一个“信号提示”图层，用文字或角标显示当前时间和码流状态，把它叠在画面角落。彩排和正式播出时，只要看一眼画面就知道流是不是实时的、有没有卡在某一帧。这比盯着后台面板直观得多，尤其是在多机位、多屏监看的现场，一眼就能发现异常。

另一件事是我这两年越来越重视的：把整条链路的配置写成文档，包括服务器配置、域名、端口、密钥存放位置、每一步的验证方法。现场换人或者半年后再做一场类似的，翻出文档半小时就能复现，不用重新踩一遍坑。直播这行临时性太强，能沉淀下来的东西不多，配置文档算一个。