音视频推流被中断时，最快定位的思路是：先检查网络质量与推流端日志，再排查编码参数和服务端接收状态，最后考虑CDN与播放端链路。
推流中断是直播间事故里最让人头疼的一种，画面卡住、观众投诉、后台告警一起涌过来，但大多数中断不是突发玄学，而是链路中有明确短板，本文从实际运维角度拆解排查顺序和防护手段,帮你把断流概率压到最低。
推流中断的常见原因与定位顺序
推流动作简单说就是“采集-编码-发送-服务端接收-转分发”，任何一个环节掉链子，都会表现为推流失败或中断，排查时不要四处乱试,按优先级顺序来。
先看推流端的网络波动
网络是中断第一高危因素，上行带宽不足、抖动过大、丢包率超标，都会让服务端主动断开连接，怎么快速判断？登录路由器或云服务器，用 ping 和 mtr 命令持续探测推流目标域名。
实操命令（Linux/macOS）：
mtr -n --tcp -P 1935 your-stream-server.com
观察 Loss% 列和 Avg 数值，如果丢包超过 1% 就要警惕，超过 5% 基本会断流，另外别忘了测上行带宽，可以用 speedtest-cli 或 iperf3 打流，确保实际可用上行不低于码率的1.5倍。
再查编码器与推流软件日志
如果网络正常，下一步看 OBS、vMix 或 FFmpeg 的日志，OBS 的日志路径一般在 %APPDATA%obs-studiologs（Windows）或 ~/Library/Application Support/obs-studio/logs（macOS），打开最近一次崩溃前的日志，搜索 Disconnected、Socket、Timeout 等关键字,能直接看到断开原因。
比如日志里反复出现 Connection to rtmp://... failed: Connection timed out，那大概率是服务端防火墙或带宽问题，如果出现 Error: Invalid data in file ，则是编码数据流损坏,多与硬件编码器驱动有关。
最后才怀疑服务端配置
服务端问题常被误判，nginx-rtmp 的 max_connections 设太低，或 SRS 的 queue_length 设置不够，都会在并发升高时强制踢流，检查服务端日志（一般位于 /var/log/srs/ 或 nginx 的 error.log），看有没有 kicked by server 或 client disconnect 记录。
网络层防护：降低丢包与断流风险的具体操作
网络问题防不住，推流再稳定也白搭,这里分享几套实战中验证过的手段。
给推流机设固定 IP 和 QoS 优先级
如果是现场直播，尽量用有线网络，并给电脑或编码器设置静态 IP，然后登录主路由器，开启 QoS，把该 IP 的上行带宽优先级调到最高，别让其他设备的下载流量挤占推流通道，据业内专家指出，一台家用路由器的带机量超过20台时,默认公平调度下推流包延迟会明显上升。
更换传输协议：RTMP 到 SRT 的降级方案
RTMP 基于 TCP，天生怕抖动，一旦丢包重传延迟飙升，如果推流环境网络质量差（比如户外4G），建议切换为 SRT 协议，SRT 用 UDP 加前向纠错，可以在 15% 丢包率下保持相对稳定，OBS 28 以上版本原生支持 SRT，在“设置-推流-服务器”里填 srt://your-server:9000?streamid=#!::r=live/live 即可，服务端用 SRS 或 MEDIA MTX 也能直接接收。
开启推流端的带宽自适应
很多推流软件支持动态码率调整，OBS 的“动态比特率”选项，开启后当网络变差时自动降低码率，变好时再升回来，代价是画面清晰度会波动，但总比直接断流好，FFmpeg 推流则可以加 -maxrate 与 -bufsize 配合,让编码器在有限带宽内平稳输出。
编码与推流参数配置的优化思路
推流参数不是越高越好,不匹配实际链路就是自我制造中断。
关键参数：关键帧间隔、分辨率、码率
- 关键帧间隔（GOP）建议设为2秒，比如30fps时
-g 60，GOP 太长会导致播放端花屏或者秒开失败，但不直接造成推流中断,更关键的是服务端强制关键帧请求时可能引发编码器压力。 - 分辨率与码率要匹配，1080p 视频常用码率范围为 4-8Mbps，720p 为 2-4Mbps，如果你上行带宽只有 3Mbps 却推 1080p@8Mbps,中断只是时间问题。
- 编码器选用上，优先选择硬件编码 NVENC 或 AMF，CPU 占用低，但某些显卡驱动版本有 bug，导致编码器临时卡死，遇到不明原因的断流且日志显示编码器重置，先升级驱动或切换到 x264 faster 档位对比测试。
OBS 推流设置里的几个坑
很多新手在“设置-输出”里选了 高级 模式，但把 串流 的 速率控制 设为 CBR（恒定码率）后，却不改 缓冲区大小，正确的做法是让缓冲区等于目标码率,否则长时间推流后可能触发服务端拥塞控制。
另一个常见问题：推流时开启了 遥测 或 浏览器源 的高刷新率，导致 GPU 占用过高，编码输出节奏被打乱，关闭不必要的源，再在“高级-视频”中设置 进程优先级为高,能有效降低卡顿率和中断概率。
服务端与CDN侧的稳定性保障
浏览器推流、小程序推流、OBS 推流最终都汇聚到服务端，服务端接收不稳,播放端必然断流。
选择靠谱的推流节点
自建流媒体服务器的话，建议至少双节点冗余，一个主节点，一个备用节点，在 OBS 里实现自动切换可以通过 nginx-rtmp 的 upstream 模块配置，或者手动在推流失败时切换备用地址，如果业务量不大，直接购买云厂商的直播服务更省心，行业共识认为，对于日活低于10万的直播场景，自建服务器成本并不比云服务便宜,而且运维复杂度高。
配置合理的接收参数
以 SRS 为例，修改 conf/srs.conf 中：
vhost __defaultVhost__ {
play {
gop_cache on;
queue_length 10;
}
live {
wait_keyframe on;
}
}
queue_length 表示播放端缓冲区长度，默认10秒比较合理，如果设成30秒，看直播会有延迟但不容易卡；如果设成3秒，遇到网络抖动很容易断流，注意这里的参数只影响播放端,不影响推流端。
CDN 拉流回源的超时设置
使用云直播 CDN 时，推流送到 CDN 边缘节点，再由 CDN 回源到你的源站，常见问题出在回源超时和回源重试机制，大多数云直播服务商允许你设置“回源超时”为1-3秒，超过则重试，如果你发现断流后恢复很快（几秒钟），多半是回源链路抖动，联系技术支持调整回源策略,同时确保源站的入站带宽留有冗余。
推流中断后的应急恢复与预防方案
再完备的防护也无法做到100%不中断,关键是快速恢复和减少观众感知。
断流自动重连机制
OBS 自带有“重试”机制，在“设置-高级-网络”中，开启 自动重连，设置重试延迟为2秒，最大重试次数100次，如果重连不成功，用第三方脚本检测进程并自动重启流，FFmpeg 推流可以用 shell 循环：
while true; do ffmpeg -re -i input.mp4 -c:v copy -f flv rtmp://server/live/stream echo "Stream stopped. Restarting in 3s..." sleep 3 done
注意，这种方式可能产生重复关键帧,但应急完全够用。
热备链路与切换策略
专业直播通常采用“双机热备”方案：主编码器推流到 A 节点，备用编码器推流到 B 节点，播放端通过云服务商的多 live 拉流实现秒切，如果没有额外机器，可以同一台机器推两个流，用主备地址，在 OBS 中通过“自定义 FFmpeg 命令”实现,但注意同一台机器上行带宽要足够。
事前压测和监控告警
建立一套简单的推流压测脚本，持续推流24小时，记录丢包率、推流时长、断流次数，监控上，使用 Prometheus + Grafana 或使用云厂商自带监控，对推流状态（是否在线、码率波动）做分钟级监控，触发告警，内部群里收到告警后，第一时间查看推流端日志，而不是刷新播放页，根据统计，多数中途断流在进行重连后都能恢复,但恢复期间观众已经离开。
常见问题速查
音视频推流被中断时，怎么判断是推流端还是服务端问题？
用同一套推流参数，换一个距离更近或不同运营商的服务器试推，如果新服务器正常，问题在原服务端链路；如果同样中断，问题在推流端或编码器，本地观察 OBS 右下角的“网络状态”指示，绿色正常，黄色丢包,红色断流。
直播推流卡顿怎么解决最有效？
优先降码率，将码率降低到当前上行带宽的80%以内，比如测试带宽3Mbps，码率设为2.5Mbps，如果还卡，改关键帧间隔为2秒并开启动态比特率,无效的话再排查路由器是否开了流量限速或防火墙拦截。
视频推流服务器怎么选更合算？
个人或小团队用云直播服务（酷番云、简米云）按量计费即可，一个月几十元就能起步，需要自建时，建议使用 SRS 或 MediaMTX，搭配简米云轻量应用服务器或酷番云轻量服务器，带宽选5Mbps以上，预算有限可用海外低价VPS，但延迟高,只适合测试不适合正式直播。
推流中断的根源往往不是某个设备故障，而是网络、编码、服务端三个层面没有协同，先把网络底子打牢，再优化参数配置，最后建立应急切换与监控机制，断流概率就能降到绝大多数观众无感知的水平，无论你是用 OBS 推流还是通过 API 调用云直播，围绕“质量探测、自动切换、快速恢复”这三件事做文章,就不会在事故现场手忙脚乱。