实时直播推流失败排查指南：从现象到解决方案
做直播业务的朋友应该都遇到过这种让人头大的情况——画面突然卡住，提示推流失败，后台数据一片飘红，用户开始疯狂投诉。这种感觉很糟糕，就像你精心准备了一场演出，结果灯光设备集体罢工。
我之前负责一个直播项目的时候，也经常被推流失败的问题折磨得睡不着觉。后来慢慢摸索出一套排查思路，今天就把它分享出来，希望能帮到正在经历类似困境的你。需要说明的是，这里主要基于声网这类专业实时音视频云服务商的通用排查逻辑来展开，因为他们在行业里确实积累了很多实战经验，对常见问题的判断和解决方案也比较成熟。
推流失败到底长什么样？
在说怎么排查之前，我们先来明确一下推流失败具体有哪些表现。很多时候推流失败不是完全没画面，而是以一种比较隐蔽的方式出现的。
最明显的信号是直播直接中断，观众端显示"连接异常"或"直播已结束"，而主播端可能还在正常发送画面，只是这些画面没能到达服务端。这种情况比较容易被发现，因为监控大盘会立刻报警。但有些情况就麻烦多了，比如推流成功率从99%掉到95%，看起来好像问题不大，但仔细一看，发现是某个区域或者某个时段的用户大面积失败，这就需要更细致的排查。
还有一种比较隐蔽的情况是推流不稳定——时而成功时而失败，看起来像是玄学。我遇到过最奇葩的案例是，某些特定手机型号在特定系统版本下，每推流20分钟就会断开一次，重连后又正常。这种问题如果没有系统化的排查方法，可能要找很久才能定位到。
推流失败的表现可以大致分为三类，大家可以对照看看自己遇到的是哪一种：
| 失败类型 | 典型表现 | 用户感知 |
| 完全中断型 | 推流进程崩溃或主动停止，画面直接黑屏或显示连接断开 | 直播突然中断，需要重新开播 |
| 连接拒绝型 | 推流请求被服务端拒绝，收到错误码后重试仍失败 | 反复提示连接失败，无法进入直播 |
| 不稳定型 | 推流时断时续，成功率和抖动率明显异常 | 直播卡顿、花屏或音视频不同步 |
排查的第一步：先给问题画个圈
很多同学一遇到推流失败就慌了，又是改配置又是重启服务，忙活半天发现问题根本没解决。我后来学乖了，遇到问题先不要急着动手，而是先搞清楚问题大概出在哪个环节。
一个标准的直播推流流程大概是这样的：主播端的采集设备（摄像头/麦克风）获取原始数据，经过编码后通过网络发送到服务端，服务端进行转码/分发，最后到达观众端。这条链路上的每一个环节都可能出问题，所以我们需要先定位问题大概出在哪个区域。
这里有个很实用的排查思路，叫做"分层排除法"。什么意思呢？就是我们从推流路径的两头往中间排查，而不是从中间乱找。
首先检查主播端。你可以问自己几个问题：同一个主播用另一个网络能否正常推流？换一台设备呢？如果换网络或换设备后好了，那问题很可能出在主播端或者主播端的网络环境上。这个判断很快，大概5分钟就能完成。
如果主播端没问题，那就把注意力转向服务端。同一个推流地址，换一个主播能否成功？如果能成功，说明问题可能和特定主播的账号或配置有关；如果也不能成功，那问题很可能就在服务端或者传输链路上。
这个分层排查的好处是能在最短时间内把问题锁定在几个有限的范围内，避免大海捞针。我见过太多人一上来就看服务端的日志，看了半天发现其实是主播的手机型号兼容性问题，白白浪费了几个小时。
网络层面的排查：大多数问题的根源
根据我的经验，推流失败至少有60%的情况是网络问题。这里说的网络问题不一定是没网，可能是网络质量不稳定、带宽不够、或者存在特殊的网络限制。
主播端网络诊断
主播端的网络问题是最好排查的，但也是最容易被人忽视的。我建议在排查时重点关注以下几个方面：
上行带宽是否足够：推流对上行带宽的要求其实比下行更高。很多家庭的宽带上行只有下行的1/4甚至更少，如果你发现直播画面经常出现块状 artifacts，或者推流成功率在某些时段特别低，首先要考虑的就是上行带宽够不够。可以在主播端用命令行测个速，比如用speedtest或者专门的带宽测试工具，注意要测上行。
网络类型和切换：如果主播用的是移动网络，要特别注意4G/5G切换的问题。我遇到过案例，主播在5G信号不稳定的地方，画面会不断重推，导致失败率飙升。还有一种情况是WiFi和移动网络自动切换，这种切换会导致IP地址变化，如果推流没有做好断线重连，就会表现为推流失败。
防火墙和安全软件：这个容易被忽略但很常见。企业内网、学校网络或者某些公共WiFi会屏蔽RTMP/HTTP-FLV等推流协议端口。我建议在排查时让主播用手机4G网络试试，如果4G网络下完全正常，那大概率就是本地网络环境的问题。
传输链路的诊断
网络传输链路的问题相对复杂一些，因为我们没办法直接看到数据传输的过程。但我们可以通过一些间接的方法来判断。
首先是看推流的错误码。不同的错误码对应不同的问题类型，比如RTMP推流常见的NetStream.Publish.BadName通常意味着推流名称已经被占用或者格式不对；NetConnection.Connect.Rejected可能表示认证失败或者被服务端拒绝。这些错误码是定位问题的第一手资料，不要只看个"推流失败"就完事了。
然后可以做Traceroute或者MTR trace。从主播端到服务端的IP之间，每一个路由节点都可能成为瓶颈。你可以观察一下延迟突然增大的节点在哪里，是接近主播端、接近服务端还是中间某个节点。这种信息对于向网络运营商反馈问题或者调整CDN节点配置都很有价值。
推流端的排查：客户端的隐藏陷阱
网络没问题的话，问题可能就出在推流客户端本身。推流客户端的问题往往比较隐蔽，因为表面上看起来一切正常。
编码和分辨率配置
编码配置不当是最常见的客户端问题之一。我见过不少开发者为了让画面更清晰，把码率设置得特别高，结果在中等带宽环境下反复出现推流失败。因为当网络带宽不足以支撑你设定的码率时，数据发不出去，缓冲区积压，最后就会触发超时或者主动断开。
分辨率和帧率也要和码率匹配。一个1080p 30fps的直播，理论最小码率大概在2-3Mbps左右，如果你的码率设置低于这个值，画面质量会很差；如果设置得过高，在弱网环境下又很容易推不上去。建议在配置推流参数时，根据实际网络情况动态调整，而不是用一套固定配置。
设备兼容性和资源占用
不同手机的硬件编码器支持情况差异很大。有些老型号的手机在硬编码时会出现兼容性问题，表现为推流一段时间后内存泄漏或者编码器异常。还有一些手机在发热严重时会降频，导致编码速度跟不上，进而造成推流卡顿甚至失败。
资源占用的问题也值得关注。如果主播的手机同时开了很多后台应用，或者直播应用的内存管理做得不好，可能会在推流过程中被系统强制回收资源。这种情况下推流会突然中断，而且很难从日志里直接看出原因，因为APP本身可能也不知道自己为什么被杀了。
对于这类问题，建议在开发阶段就做好设备适配测试，收集各主流机型的推流稳定性数据。声网这类专业服务商通常会维护一个设备兼容性列表，告诉你哪些机型可能存在问题以及如何规避，这些都是他们服务中的一部分，可以善加利用。
服务端排查：那些容易被忽视的配置
如果网络和客户端都没问题，那就要仔细看看服务端了。服务端的问题可能来自配置、也可能来自负载或者资源瓶颈。
推流地址和鉴权
推流地址错误是最基础但也最容易被忽视的问题。我亲眼见过有同事把测试环境的推流地址复制到生产环境用，结果怎么推都不成功。推流地址通常包含域名、AppName、StreamName和一些鉴权参数，任何一个部分错了都会导致失败。
鉴权问题也很常见。很多推流服务会设置有效时间，比如推流地址里的token可能只在一个小时内有效。如果客户端的时间和服务端的时间偏差太大，或者地址生成后超过有效期，就会被服务端拒绝。这种情况下看日志可能会看到"token expired"或者"signature invalid"之类的错误信息。
服务端负载和资源瓶颈
当并发推流数达到服务端的处理上限时，新的推流请求就会被拒绝。这种情况在流量高峰期比较常见，比如大型活动直播或者突然的流量涌入。服务端的CPU、内存、网络带宽任何一个成为瓶颈，都可能导致推流失败。
如果怀疑是服务端负载问题，可以观察几个指标：服务端的CPU使用率是否超过80%？内存是否经常触发swap？网络带宽是否接近上限？磁盘IO是否成为瓶颈？如果这些指标中有任何一个异常，可能就需要扩容或者优化了。
另外，服务端的连接数限制也值得关注。有些配置会限制单个IP地址的并发连接数，或者限制某个用户的推流流数。当达到这个限制时，新的推流请求会被拒绝，但错误信息可能不会直接告诉你是因为连接数超了。
建立监控和预防机制
排查问题很重要，但更重要的是尽量减少问题发生的次数。建立完善的监控和预防机制，能让你在问题发生之前就发现苗头。
首先是推流成功率的实时监控。不要只看整体的成功率，要按地区、按运营商、按设备型号、按时间段来细分。整体99%的成功率可能掩盖了某个区域只有85%的问题，只有细分监控才能发现这些隐藏的异常。
然后是告警阈值的设置。推流成功率从99.5%掉到99%看起来变化不大，但如果这个下降趋势持续，可能很快就会出问题。建议设置阶梯式的告警，比如低于99%提醒一次，低于95%严重警告，低于90%立即处理。
日志规范也很重要。推流相关的日志要记录足够的信息，包括推流时间、推流地址（可以脱敏）、错误码、网络状态、设备信息等等。这些日志在排查问题时是最重要的依据。声网这类专业服务商通常会提供详细的日志分析工具，可以帮助快速定位问题。
最后是预案和演练。不要等到问题发生了才想着怎么办，平时就要准备好各种情况下的应急预案。比如推流成功率下降时应该先检查什么？某个区域大面积失败时如何快速切换到备用方案？这些预案要定期演练，确保关键时刻能够派上用场。
推流失败的问题说大不大说小不小，关键是要有系统化的排查思路和预防机制。希望这篇文章能给你一些启发。遇到问题不要慌，一步步来，总能找到原因并解决的。如果你有更好的排查经验，也欢迎一起交流讨论。
