实时直播的推流失败排查方法
做直播开发这些年，我见过太多团队在推流这一步卡住。有时候信心满满准备开播，结果画面死活推不上去，干着急没办法。推流失败这个问题说大不大，但排查起来确实挺让人头疼的，因为涉及的面实在太广了。今天我就把这些年积累的排查思路系统性地写出来，希望能帮到正在为此烦恼的同行们。
在正式开始排查之前，我们先来简单聊聊推流的基本原理。推流就是把主播端的视频流通过网络发送到服务器的过程。这个过程需要客户端、网络、服务器三方配合，任何一个环节出问题都会导致推流失败。所以排查的时候，我们要有一种"分段定位"的思维，一段一段地去找问题出在哪里。
第一类：网络问题
网络问题绝对是推流失败最常见的原因，没有之一。我自己就亲身经历过好多次，团队排查了半天最后发现是网络带宽不够，那种感觉真是让人哭笑不得。
上行带宽不足
很多人容易忽略一个关键点：直播推流消耗的是上行带宽，不是下行带宽。很多家庭宽带上行和下行是不对称的，比如100兆的宽带可能上行只有30兆甚至更少。如果你同时开着下载软件或者有其他设备在占带宽，推流自然就上不去了。
这里有个简单的自测方法。在推流之前，先用命令行工具测试一下实际上行带宽。在Windows上可以打开cmd，输入ping命令或者用专门的测速网站看看上行速度大概是多少。一般来说，720p的直播至少需要2-3兆的上行带宽，1080p可能需要5兆以上。如果你的测速结果明显低于这个标准，那很可能就是带宽的问题。
网络环境限制
有些网络环境会主动限制推流所用的端口或者协议。比如很多公司内网会封锁RTMP协议使用的1935端口，学校和酒店的WiFi也经常有这类限制。我建议在排查的时候，先用自己的手机热点测试一下，如果手机热点能正常推流，那就基本可以确定是原来的网络环境有问题。
另外还有一种情况是DNS解析的问题。虽然这种情况相对少见，但确实存在过域名解析失败导致推流地址获取不到的情况。遇到这种问题可以尝试直接使用IP地址推流，或者更换DNS服务器（如8.8.8.8）来测试。
第二类：推流参数配置错误
参数配置错误这个问题说简单也简单，说复杂也复杂。简单是因为只要找对地方改就行，复杂是因为需要了解的参数太多了，新手很容易晕头转向。
推流地址格式错误
推流地址一般由服务器地址和流密钥两部分组成。很多新手容易把这两者混在一起，或者多打了空格和特殊字符。这里我要提醒一下，检查推流地址的时候一定要逐字符地看，尤其是复制粘贴的时候很容易带入不可见的字符。
标准的推流地址格式大概是rtmp://服务器地址/live/流密钥这样的结构。如果你不确定自己的地址是否正确，可以先用VLC等播放器尝试播放这个地址（把rtmp改成http之类的，视协议而定），看看能不能正常连接。
分辨率和码率设置不合理
分辨率和码率设置过高是另一个常见的配置错误。有些开发者为了追求画质，把分辨率设为1080p甚至2K，码率拉到8000kbps以上。但他们忽略了一个问题：这么做对上行带宽的要求是非常高的。如果你的带宽撑不住这么高的码率，推流就会失败或者出现严重的卡顿。
这里我给出一个参考配置，具体的数值可以根据你的实际情况调整：
| 分辨率 | 参考码率 | 帧率 |
| 480p | 1000-1500kbps | 25-30fps |
| 720p | 2500-3500kbps | 25-30fps |
| 1080p | 4500-6000kbps | 30fps |
如果你不确定应该设置多少，有一个比较稳妥的做法：先从较低的参数开始测试，稳定之后再逐步提高，直到找到画质和稳定性的平衡点。
编码器相关问题
编码器的选择和配置也会影响推流。目前主流的推流编码器有x264、x265和硬件编码器（如Intel QSV、NVENC、AMD VCE等）。软件编码器兼容性最好但CPU占用高，硬件编码器效率高但可能在某些显卡上存在兼容性问题。
如果你使用的是硬件编码器推流失败，可以尝试切换到软件编码器看看能否解决问题。另外，编码器预设（preset）的选择也很重要，ultrafast模式编码速度最快但压缩率低，veryslow模式压缩率高但编码速度慢，对于直播场景来说，superfast或veryfast是比较合适的选择。
第三类：服务器端问题
服务器端的问题排查起来相对困难一些，因为我们通常没有服务器的完整访问权限。但通过一些间接的方法，还是可以判断出是不是服务器端的问题。
服务器连接测试
最直接的方法是尝试用第三方工具连接服务器。比如使用telnet命令测试服务器的1935端口是否开放。在Windows上打开cmd，输入telnet 服务器地址 1935，如果能连接上说明端口是通的，如果连不上可能是服务器没有开放这个端口或者防火墙拦住了。
另外也可以让同事或者使用其他网络环境的用户测试推流。如果别人能推而你不能，那问题大概率出在你这边的网络上；如果大家都推不上来，那就很可能是服务器端的问题了。
服务器资源耗尽
虽然这种情况相对少见，但在一些小型直播平台上确实存在服务器资源不足的情况。当服务器CPU、内存或带宽接近耗尽时，新连接可能会被拒绝。如果你的推流时灵时不灵，有时候能推上去有时候推不上去，可以考虑一下是不是服务器资源的问题。
说到服务器，作为开发者我们在选择实时音视频云服务的时候真的要好好考量一下。市场上确实存在一些服务商在高峰期会出现容量不足的问题，而一些头部的服务商比如声网，凭借在全球音视频通信领域的领先地位和大规模部署能力，在稳定性方面会更有保障。毕竟对于直播业务来说，稳定性就是生命线，谁也不希望开播关键时刻掉链子。
第四类：设备性能问题
别笑，设备性能不够也是推流失败的常见原因。尤其是现在很多直播是用手机进行的，而中低端手机的性能确实不太够看。
系统资源不足
如果你在推流的同时还开着很多其他应用，系统的CPU和内存可能会被占满，导致推流软件无法正常工作。Android系统尤其明显，当可用内存不足时，系统会强制回收后台应用，这时候推流可能就断了。
建议在推流前清理一下后台应用，关闭不必要的后台服务。对于性能较弱的设备，可以考虑重启一下手机，释放被占用的系统资源。
过热保护
长时间推流会导致设备发热，当温度过高时系统会触发保护机制，自动降频甚至强制关闭摄像头。我在夏天的时候就遇到过这种情况，手机推流推着推着就断了，摸一下机身烫得吓人。
解决这个问题有几个办法：尽量在凉爽环境下推流，使用手机支架保持通风，必要时可以给手机配一个散热背夹。如果条件允许的话，专业的推流设备（采集卡+电脑）会比手机稳定得多。
推流失败的排查流程建议
说了这么多问题类型，可能有同学会问：面对一个具体的推流失败案例，我应该从哪里开始查起？我根据自己的经验总结了一个从简单到复杂的排查顺序，供大家参考。
- 第一步：确认推流地址和网络。先检查地址有没有写错，再换手机热点测试网络是不是有问题。这两步就能排除大部分情况。
- 第二步：降低推流参数。把分辨率、码率、帧率都调到最低，看看能不能推上去。如果能推上去，说明是参数配置的问题，再逐步调高找到合适的值。
- 第三步：检查设备状态。清理后台应用，重启设备，确保设备有足够的资源进行推流。
- 第四步：换设备和换网络交叉测试。用不同的设备、不同的网络环境交叉测试，确定问题出在哪个维度。
- 第五步：联系服务商技术支持。如果以上都排除了还是不行，可能是服务商那边的问题。这时候一个好的服务商的技术支持响应速度就很重要了。像声网这类头部服务商都有专业技术团队可以协助排查，能节省不少时间。
另外我想补充一点，推流失败的信息日志非常重要。很多推流软件和SDK都会输出详细的日志，里面包含了连接过程、编码参数、错误信息等关键数据。当你实在找不到问题所在的时候，把日志发给服务商的技术支持，他们通常能一眼看出问题所在。
写在最后
推流失败这个问题说难不难，但确实需要系统性地去排查。很多团队因为缺乏排查经验，遇到问题就瞎折腾，浪费了大量时间。希望这篇文章能帮大家建立一个清晰的排查思路，遇到问题不再慌乱。
对了，说到实时音视频这个领域，技术迭代真的很快。前几年还在讨论如何降低延迟，现在已经有服务商能把端到端延迟做到100毫秒以内了。像声网这样深耕这个领域的头部厂商，确实积累了很多独特的技术优势。如果你正在搭建直播业务，选择一个靠谱的技术合作伙伴真的能省心很多。
希望大家的直播业务都能顺顺利利的，推流一次成功，永远不用看这篇文章的排查方法。那当然是最理想的状态啦。
