做直播的团队最怕的，往往是推流显示一切正常，观众端却黑屏。遇到阿里云无直播的情况，很多人第一反应是平台出了问题，但多数时候是配置或链路上的某一处出了错。常见原因和排查顺序可以按下面的思路理一遍，适合正在处理这类问题的同学。
先分清问题出在哪一段
“无直播”没有统一的错误码，它可能出现在推流端、云端或播放端。排查前先把现象分成三类：推流失败，编码器提示连接异常；推流成功但拉流没有画面；拉流有画面，但卡顿、延迟很高。三类现象的排查方向完全不同。如果不先分开，常见结果是在推流端反复重启设备，问题其实出在播放域名上。
最常见的几类原因
- 推流地址或密钥有误。服务器域名、AppName、StreamName 任何一段拼错，或者鉴权参数已经过期。
- 播放域名没配好。域名还没完成绑定，或者加速域名的状态不正常。
- 编码参数超出播放端范围。分辨率、码率或音视频编码格式，有些终端并不支持。
- 出口网络被拦。本地防火墙或机房出口屏蔽了 RTMP 默认端口 1935，推流根本发不出去。
- 账户或服务状态异常。余额不足、资源包用完，或直播功能没有在当前地域开通。这一项容易被忽略，建议先看一眼控制台。
排查时可以按这个顺序走
- 先看推流端。打开编码器日志，确认连接是否建立，码率是否持续输出。码率归零通常说明推流已经断了。
- 逐段核对推流地址。服务器、AppName、StreamName 建议直接从控制台复制，不要手动输入。流名区分大小写，这是很多团队踩过的坑。
- 如果开启了鉴权，确认密钥和过期时间与控制台一致。时间戳过期后，推流看起来正常，云端却不会接收。
- 查看控制台的流状态和监控数据，判断云端是否已经收到流。没收到，问题在推流侧；收到了，问题多半在拉流侧。
- 用 VLC 或 ffplay 直接打开播放地址。这一步能排除播放器自身的缓存或解码问题，省得在业务页面上绕圈子。
- 仍然定位不了，就提交工单，并附上推流日志和出问题的具体时间点。时间点越准，工程师越容易对到后台记录。
两个真实发生过的场景
推流正常，观众端一直黑屏
一个电商团队在大促前测试直播间，OBS 显示推流正常，观众端却始终黑屏。团队先后重启了编码器和路由器，前后耗费近两个小时。最后发现播放地址里的 StreamName 和推流时大小写不一致，改过来之后画面立刻恢复。这个例子说明，地址核对应该放在第一步，而不是最后一步。
晚高峰频繁断流
一家在线教育机构的课程直播，每晚八点左右就断断续续，白天却一切正常。排查下来，原因在机房出口。晚高峰时其他业务占满了带宽，推流码率大幅抖动，云端判定流中断。团队把固定码率改成自适应码率，并给直播单独划出一部分出口带宽，问题才得到缓解。这类故障在控制台上不一定有明显报错，需要把本地网络监控和云端数据放在一起看。
链路不可用时的备选做法
直播链路暂时出问题，业务未必要完全停下来。常见的应对方式有三种。
- 多路推流备份。同一路信号同时推送到两个服务商，播放端通过切换地址完成故障转移。成本会高一些，但适合对在线率要求高的活动。
- 录制回放兜底。直播过程中同步录制，链路异常时以回放形式提供已录好的内容，观众不至于直接离开。
- 降级为图文或音频。画面一时恢复不了，先保证公告、时间安排和互动入口可以访问，总比干等着强。
平时怎么减少事故
大多数直播事故都可以提前规避。大型活动之前，最好做一次完整的压力测试，覆盖不同网络环境和终端类型，手机端的兼容性尤其要测。推流地址和鉴权参数建议放进统一的配置中心管理，不要靠人工修改，每次手改都可能引入新的拼写错误。另外，为关键直播设置告警。码率突然归零，或观看人数在短时间内明显下跌，都应该第一时间通知值班人员，而不是等观众来反馈。
阿里云无直播的问题看起来复杂，但大多可以沿着“推流、云端、拉流”三段逐一排除。先把排查顺序定下来，再配合备份方案，直播在关键时刻才会稳得住。
