直播推流断流频繁时，先查上行带宽，再查编码器，这个顺序能省掉你大半天的排查时间。多数情况下，断流不是编码器“干活不卖力”，而是网络管道太细或者抖动太厉害，下面按排查优先级展开讲。
先判断上行带宽是否够用：用数据说话，别靠感觉
看推流码率和上行带宽的匹配关系
直播推流本质是把编码器产出的数据流,通过上行带宽送到服务器，假设你设置视频码率是6000kbps，音频是128kbps，加上协议开销和冗余，实际需要的上行带宽至少是码率总和的1.2到1.5倍，也就是大约5Mbps到9Mbps，如果家里或工作室的上行带宽只有10Mbps，看起来刚好够，但一旦有别的设备抢网或者线路波动，断流就来了。
用可验证的方法测真实上行速度
别拿运营商标称的“100M宽带”当真，那个通常指下行，上行速度要实测，操作方法：
- 打开测速网站,选择离你所在城市最近的节点，测三次取平均值。
- 推流时打开任务管理器或资源监视器,观察“发送”字节数是否在码率附近波动。
- 用命令行工具,比如
iperf3，丢包率超过1%就说明上行链路质量不佳。
业内专家指出,上行带宽测试要在推流时段测，而不是半夜测，晚高峰和周末的数据更有参考价值。
区分“带宽不足”和“带宽抖动”
带宽不足是持续断流,每隔几秒就卡一次，带宽抖动是间歇性断流，画面偶尔花屏、卡顿，然后自动恢复，抖动是线路质量问题，带宽不足是容量问题，这两种情况处理方式不同：
- 带宽不足：降低码率，或者升级宽带套餐。
- 带宽抖动：检查网线、换有线连接、调整路由器QoS设置。
再看编码器配置是否合理：设置不对也会加剧断流
编码器CPU占用过高导致帧率不稳
当你用CPU软件编码（x264）时，如果编码预设调成slow或veryslow，CPU占用会冲到90%以上，导致编码速度跟不上实时帧率，推流端就会丢帧，丢帧不等于断流，但积压多了，编码器会主动断开连接，解决办法：
- 把预设改为medium或faster。
- 如果电脑配置不高,换硬件编码（NVENC、QuickSync或AMF）。
- 推流分辨率从1080p降到720p,对断流问题有直接缓解作用。
关键帧间隔设置不对
直播推流依赖关键帧,关键帧间隔设得太大，播放端缓冲不足时就会断流，行业共识认为，关键帧间隔建议设为2秒（即帧率的2倍），有些主播为了画质把GOP拉到5秒甚至更长，一旦网络抖动，恢复时间变长，表现为频繁断流。
编码器参数和带宽的协同关系
编码器码率设置得比实际上行带宽高,是断流的最常见配置错误，比如上行只有8Mbps，编码器码率设成10000kbps，那数据必然堆积，正确做法：
- 先测出稳定上行带宽。
- 把编码器最大码率设为上行带宽的80%。
- 再留出15%余量给音频和协议开销。
用排除法定位断流根源：两步就能锁定问题
第一步：先固定编码器，测带宽
把编码器码率降到2000kbps，分辨率调到720p，保持推流15分钟，如果断流消失，说明问题大概率出在带宽或码率匹配上，如果断流依旧频繁，再看编码器或网络线路质量。
第二步：固定带宽条件，测编码器
在本地推流到局域网内的服务器（例如用OBS推流到同一局域网内的Nginx服务器），绕开公网，如果局域网推流稳定，说明编码器没问题，问题出在公网上行链路，如果局域网也断流，那就是编码器设置或电脑性能问题。
工具组合推荐
- OBS自带日志：看“RTMP connect”和“Disconnected”的时间戳。
- Wireshark抓RTMP流：观察TCP重传率。
- 路由器和光猫的后台：看上行接口的丢包统计。
场景化对比：不同推流环境下的排查优先级
家用宽带推流
家庭宽带多为非对称线路,上行带宽小且容易受邻居使用高峰影响，此时先查上行带宽是绝对正确，具体场景：晚上8点开始直播，电视在看4K视频，手机连着WiFi刷短视频，你的推流断流，十有八九是上行带宽被抢了。
移动网络推流
户外直播用5G或4G,信号波动比固网更剧烈，这时先查信号强度，再看编码器，因为移动网络的上行带宽再大，基站信号一弱，丢包率迅速上升，建议用手机直播时选择编码器硬件直推模式，减少手机CPU发热降频带来的编码不稳定。
公司或机房推流
公司专线或机房服务器推流,上行带宽通常不是瓶颈，此时优先查编码器参数，尤其是CPU抢占和转码任务，如果同一台服务器同时跑多个推流任务，线程分配不合理会导致所有流集体断线。
断流后的快速修复动作：不用重启整套设备
降低码率是“最稳”的临时方案
直播过程中发现断流频繁,最直接的干预手段是把视频码率从当前值降到2000-3000kbps，同时把分辨率从1080p降到864x480，这个操作能在10秒内减轻上行压力，恢复稳定推流。
切换线路或协议
部分直播平台支持RTMP自动切换线路,手动选择备用节点，可以避开拥堵的上行路径，如果你的直播软件支持SRT协议，也可以尝试用SRT替代RTMP，SRT的抗丢包能力更强，但需要服务器端支持。
重启编码器进程
长时间运行的编码器偶尔会出现内存泄漏或线程死锁,表现为推流间歇性断开，重启OBS或编码器进程，能恢复初始状态，虽然听起来简单，但确实能解决一小部分断流问题。
Q&A：直播推流断流频繁，常见疑问解答
为什么上行带宽明明足够，推流还是断？
上行带宽测的是理想值,但实际推流是持续流量，路由器NAT表满、老旧网线干扰、光猫缓存不足，都会导致瞬间丢包，运营商对P2P和长连接可能存在限速策略，测速时流量特征不同，推流时被限流。
编码器用硬件编码还是软件编码更不容易断流？
硬件编码CPU占用低,不容易因硬件过载导致断流，但画质略逊，软件编码画质好，但高预设下CPU占用高，反而容易因处理不过来而丢帧，推荐配置：Intel核显或NVIDIA显卡硬件编码，码率控制选CBR，兼顾稳定性和画质。
更换推流软件能不能解决断流？
不能,断流的根源在于网络链路和编码参数，推流软件只是封装数据的工具，除非原软件有严重的协议实现bug，否则换软件只是心理安慰，真正有效的是调整码率、关键帧间隔和线路选择。
直播断流是一个系统性问题,记住排查顺序：先验证上行带宽是否满足码率1.5倍要求，再检查编码器是否占用过高或参数不匹配，大多数情况下，你把码率降到带宽的80%，断流问题就解决了一大半，剩下的小部分，则需要从网络设备、线路质量甚至运营商策略层面去处理。