直播业务从小范围试播走到大规模并发，推流往往是最先出问题的环节。画面卡顿、推流中途断开、主播端突然黑屏，很多故障追到底都和推流配置有关。这篇文章以一个实际改造的案例为线索，讲讲阿里云推流的基本链路、需要关注的配置，以及出问题时的排查顺序。
一、推流在直播链路里的位置
一条直播链路大致分三段。采集端把音视频编码后推到云端；云端完成转码、录制和分发；观众端通过拉流地址播放。推流是第一段，画面质量和稳定性基本在这里就定下了。推流质量差，后面的CDN再好，也只能把差的画面更快地送到观众面前。
二、开通前要先准备什么
在控制台开通阿里云视频直播服务后，建议先完成三项准备：
- 添加推流域名和播放域名，按提示配置CNAME解析。解析没生效之前推流会直接失败，这时不必往别处找原因。
- 开启推流鉴权，生成鉴权Key。没有鉴权的推流地址一旦泄露，别人就能占用你的流名推流。
- 按业务决定是否开启录制、转码和时移。这些功能会增加费用和处理环节，用不到就先关掉。
推流地址的格式一般是 rtmp://推流域名/应用名/流名称，后面带鉴权参数。鉴权参数通常包含过期时间戳和MD5签名，时间一到地址就失效。这一点在正式环境里很关键，所以地址最好由后端按场次动态生成，不要把长期有效的地址写进客户端或者配置文件里。
协议选择会影响体验。RTMP兼容性好，OBS等常见推流工具接入最简单，大多数常规直播场景都用它。如果是连麦或对延迟很敏感的互动场景，可以再评估SRT或WebRTC。选型前先想清楚业务里延迟、画质和接入成本哪个最优先，协议跟着这个顺序定。
三、案例：一场电商晚会的推流改造
某家居品牌准备在大促前做一场两小时的直播带货。团队最开始是用OBS直接推到一个固定地址。首场试播时，主播端网络一波动，画面就频繁卡住；观众端延迟超过十秒，弹幕互动明显跟不上。
排查下来有三个问题。第一，编码码率设成了固定的高值，上行带宽不够时没有余地，码率下不去，画面只能卡。第二，关键帧间隔设得太长，观众端起播慢，切换画面也慢。第三，推流地址没有鉴权，而且和测试环境共用同一个流名，偶尔会出现串流。
团队随后做了四处调整：
- 把码率调到与上行带宽匹配的区间，并留出约30%的余量。带宽按实测值来算，再取七成左右作为码率上限，别直接拿标称带宽套用。
- 关键帧间隔调到2秒左右。画质和延迟之间要有取舍，2秒是这个场景下比较均衡的点。
- 测试和正式环境使用独立的域名和应用名，推流地址由后端按场次生成，每场都是新地址。
- 主播机房接入双路网络，OBS里同时配置备用推流地址，主线路出问题时手动切换。
调整后的第二场试播，画面稳定性明显好转，观众端延迟稳定在三到五秒之间，全程没有再出现串流。这个案例说明，参数和场景对上，比单纯拉高画质更实际。
四、推流出问题时的排查顺序
遇到推流异常，建议按下面的顺序一项项查，别一上来就重装OBS或者换网络：
- 先看鉴权参数有没有过期。这里最常见的坑是服务器时间和本地时间有偏差，拿时间戳一对比就能发现问题。
- 再确认推流域名解析是否正确，本地网络能不能连上推流节点。可以用ping或telnet测一下端口连通性。
- 查看推流端的上行带宽和丢包率。如果丢包明显，多半是采集端或本地网络的瓶颈，服务端通常没问题。
- 最后到控制台查看推流状态和日志，把异常发生的时间点找出来，再和现场操作对一下。
大多数问题按这四步基本能定位。遇到无法解释的抖动，先把一段时间的推流日志留存下来。和服务商沟通时，能直接给出时间点和现象，效率会高很多。
五、上线前的几项检查
正式开播前，可以对照下面几条过一遍：
- 用正式环境的推流地址在OBS里跑一次完整测试，确认能正常推流，并且在播放端看得到画面。
- 测试和正式的域名、应用名、流名分开，避免测试流误占正式流名。
- 提前把备用推流地址填进OBS，并在模拟直播里实际切换一次，别等出事才第一次操作。
- 如果业务要上量，先用小流量试播，确认码率、延迟和稳定性都达标后再扩大规模。
阿里云推流真正要做好的是三件事：地址安全、参数匹配和链路冗余。前期多花一小时把这些做扎实，后面的大场次会省下不少救火的时间。
