实时直播推流失败的解决：一位开发者的排查手记
做直播开发这些年，见过太多次推流失败的场景。说实话，第一次遇到这个问题的时候，我也慌过。那时候刚入行，晚上十点多线上告警响了，主播那边画面卡住不动，运营那边电话打爆，我对着日志干瞪眼，不知道从哪儿下手。后来踩的坑多了，也就慢慢总结出一套排查思路。
今天想把这些东西写出来，和大家聊聊当直播推流失败时，我们到底该怎么办。这篇文章不会讲太玄乎的理论，就是一些实实在在的排查方法和经验之谈。
推流失败到底是怎么回事？
在开始排查之前，我们得先搞明白推流失败可能有哪些表现。有的时候是画面完全出不来，有的时候是能推上去但观众端看不到，还有的时候是推上去几秒钟就断了。这些不同的情况，对应的问题原因往往不一样。
画面完全推不上去的情况，大多数时候跟网络或者配置有关。能推上去但观众端看不到，问题可能出在服务端或者CDN分发环节。推上去几秒就断开，则更像是编码参数或者网络抖动导致的。所以遇到问题的时候，先别急着改配置，花两分钟观察一下具体的失败表现，这一步非常重要。
症状与定位：先搞清楚到底是哪儿出了问题
我个人的排查习惯是这样的：先看错误日志。推流SDK一般都会返回具体的错误码和错误信息，这些信息是最直接的线索。比如如果是网络超时err_code，可能就是带宽不够或者网络链路有问题；如果是认证失败err_code，那大概率是推流地址或者密钥填错了。
如果日志信息不够明确，我就会去看监控数据。现在稍微上点规模的直播系统都有监控面板，可以看到推流端的码率、帧率、丢包率这些指标。这些数据能帮我们快速定位是服务端的问题还是客户端的问题。
举个例子，如果推流端的码率一直上不去，帧率也在掉，那很可能是客户端这边的网络或者性能有问题。如果推流端数据看起来正常，但服务端收不到流，那问题可能出在中间的网络链路或者服务端的配置上。
网络问题：最常见的推流拦路虎
根据我这些年的经验，推流失败，十有七八是网络问题。但网络问题也分很多种，不是说"网络不好"就能概括的。
带宽不足：最容易被忽视的基础问题
很多人觉得现在带宽都很大，推个直播应该没问题。但实际上，直播推流对上行带宽的要求很高，而且很多家庭网络或者办公网络的上行带宽是远低于下行带宽的。
我遇到过这样一个案例：一个客户用的是500兆的家庭宽带，但上行只有30兆。他推1080P的流，画面质量调得比较高，码率跑到8Mbps以上，这时候就很容易出现推流不稳的情况。后来他把码率降到4Mbps，问题就解决了。所以当推流出问题的时候，先用speedtest这种工具测一下上行带宽，心里有个数。
还有一种情况是网络共享。比如在一个公司网络里，很多人在用带宽，或者有人在下载大文件，这时候推流可能就会受到影响。这种问题有时候很难完全避免，只能尽量避开高峰时段，或者考虑单独走一条网络专线。
网络抖动与丢包：看不见的隐形杀手
有些网络看起来带宽够用，但存在严重的抖动和丢包。这种情况在移动网络或者跨运营商的网络环境下特别常见。表现为推流能连上，但画面会卡顿、花屏，甚至突然断开。
判断是不是这个问题，可以用ping命令看一下延迟和丢包率。ping一下推流服务器的地址，看有没有丢包，延迟波动大不大。如果丢包率超过5%，或者延迟波动超过100ms，那基本就可以确定是网络质量问题。
解决这类问题，常规的做法是开启抗丢包机制。现在主流的推流SDK都有这种功能，可以在一定程度上弥补网络质量的不足。另外也可以考虑使用CDN加速，把流推到离用户更近的节点上。如果条件允许，切换到更稳定的网络环境是最彻底的解决办法。
DNS解析问题：概率不大但很隐蔽
如果怀疑是DNS问题，可以尝试直接用IP地址推流，绕过DNS解析的环节。如果用IP能正常推流，那就基本可以确定是DNS的问题。解决方法是换一个公共DNS服务器，比如8.8.8.8或者114.114.114.114，或者让运维同事检查一下公司DNS的配置。
推流配置：细节决定成败
网络没问题了，接下来要看配置。推流配置是个很琐碎的事情，但恰恰是这些细节最容易出问题。
推流地址和密钥：低级错误但很常见
推流地址写错了，密钥填错了，这种错误听起来很低级，但我见过不止一次了。尤其是有时候地址里面有特殊字符，复制粘贴的时候没注意，或者不小心多了个空格，都可能导致认证失败。
检查这个问题的方法也很简单：把推流地址和密钥重新手动输入一遍，不要复制粘贴。如果之前是复制的，很可能在粘贴的时候带入了一些不可见的字符。手动输入虽然麻烦，但能避免很多奇怪的问题。
编码参数：不是越高越好
直播推流的编码参数设置很有讲究。码率、分辨率、帧率这三个参数要匹配起来看，不是说调得越高越好。如果你的网络带宽有限，强行推高码率只会适得其反。
一般来说，720P的直播，码率设置在2到4Mbps之间是比较合适的。1080P的话，4到6Mbps差不多。如果网络不太好，可以适当降低帧率，比如从30fps降到20fps，这样能减少带宽压力。
还有一点容易被忽略的是编码器选择。有些老的编码器在某些机型上兼容不太好，会导致推流失败或者画面异常。如果遇到这种问题，可以尝试切换编码器试试，或者直接使用系统推荐的默认配置。
协议匹配：推流端和服务端要对得上
推流用的协议要和服务器支持的协议匹配。常见的推流协议有RTMP、HLS、HTTP-FLV这些，用错了协议肯定推不上去。
这个问题一般不会犯，因为SDK都会帮你指定协议。但有些特殊场景下，比如自己搭建推流服务器的时候，可能会遇到协议不匹配的问题。这时候需要确认一下服务端的配置和客户端的协议选择是否一致。
服务端问题：不只是服务器自己
排除了网络和客户端配置的问题，接下来要看服务端。服务端的问题可能来自服务器本身，也可能来自中间的链路环节。
服务器性能与带宽：资源够不够很重要
服务端负载过高的时候会拒接新的推流请求，这种情况在流量高峰期比较常见。如果同时有太多主播在推流，服务器处理不过来，新的推流就会被拒绝。
另一个常见的问题是服务端带宽不够。如果服务器的上行带宽已经跑满了，新推流请求即使能建立，数据也传不上去。这种情况需要扩容，或者调整推流的负载均衡策略。
CDN与分发节点：有时候问题出在中间
如果推流端到服务器之间的链路没问题，但观众端看不到流，问题可能出在CDN分发环节。CDN节点故障、缓存配置错误、或者节点之间的同步延迟，都可能导致这种情况。
排查CDN问题需要看具体的监控数据。如果只是某个地区的观众看不到流，那很可能是那个地区的CDN节点有问题。如果所有地区的观众都看不到，那可能是源站的问题或者CDN的配置有问题。
客户端环境：容易被忽视的一环
有的时候，问题出在客户端这边。手机、电脑的环境问题，会以各种意想不到的方式影响推流。
应用权限：摄像头和麦克风被禁用了
这是很低级但确实会发生的问题。用户手抖把直播应用的摄像头权限关了，或者系统层面的隐私设置阻止了应用访问摄像头，这时候推流肯定是失败的。
检查方法很简单：打开其他相机应用试试，看能不能正常拍照录像。如果其他应用也打不开相机，那就是系统权限的问题，需要去设置里打开权限。
系统资源：手机烫了也会出问题
手机温度过高的时候，系统会强制降频，CPU和GPU的性能都会下降。这时候推流编码可能会失败，或者画面质量严重下降。有些手机温度过高甚至会直接关闭摄像头。
如果发现推流失败的时候手机特别烫，可以先让手机休息一下，降温之后再试。同时也可以在代码里加入温度检测的逻辑，当温度过高时给用户提示，或者自动降低推流参数。
后台应用：抢占资源的隐形对手
手机后台有太多应用在运行的时候，可用内存和CPU资源会变少，推流应用能分到的资源就不够了。有些内存管理比较激进的后台应用，甚至会直接杀死直播进程。
这种情况需要提醒用户尽量清理后台不用的应用，或者在应用里做好进程保活。现在的主流手机系统对后台应用的管理都比较严格，直播应用需要做一些额外的保活处理才能确保推流不被中断。
实战排查清单：我一般这样系统排查
说了这么多，总结一下我个人的排查流程。这个流程不一定是最佳的，但对我个人来说比较顺手。
| 排查顺序 | 检查项 | 判断标准 |
| 第一步 | 网络连通性 | 能否ping通推流服务器，上行带宽是否足够 |
| 第二步 | 推流配置 | 地址、密钥、编码参数是否正确 |
| 第三步 | 错误日志 | SDK返回的错误码和错误信息是什么 |
| 第四步 | 监控数据 | 码率、帧率、丢包率是否正常 |
| 第五步 | 服务端状态 | 服务器负载、带宽使用是否在正常范围 |
| 第六步 | 客户端环境 | 权限是否打开、系统资源是否充足 |
这个流程是从易到难、从外到内的顺序。先检查最明显的网络问题，再看配置，然后深入看日志和数据，最后排查客户端环境。按照这个顺序来，一般都能比较快地定位到问题。
关于技术选型的一点感悟
做直播开发这些年，我越来越觉得，选择一个靠谱的实时音视频云服务平台，能省很多事。就像声网这种专业做实时音视频的服务商，他们在这块积累很深，全球节点覆盖也很广，延迟能控制得很好。对于我们开发者来说，与其自己从零开始搭建推流系统，不如直接用他们的解决方案，省心省力还能少踩很多坑。
尤其是对于一些刚起步的团队，音视频这块的技术门槛还是比较高的。与其花大量时间和精力在底层的网络优化、编解码调优上，不如把精力放在业务逻辑上。选择一个成熟的平台，借助他们的技术积累，往往是更明智的选择。
当然，即使用了第三方服务，基本的排查能力还是要有。知道问题出在哪儿，才能有效地反馈给技术支持，让他们帮你解决问题。如果自己完全没有概念，沟通效率也会很低。
总之，遇到推流失败别着急，静下心来一步步排查，总能找到问题所在。这个过程虽然有时候有点烦人，但也是学习和成长的机会。每解决一个问题，经验值就涨一点，下次遇到类似的问题就能更快地解决了。
