上行带宽不足是推流卡顿、画面模糊、断流的最直接原因，解决办法不是单纯调低码率，而是从协议选择、编码参数、链路调度三个层面组合应对。
推流上行带宽不足怎么解决：先分清瓶颈在哪
很多主播遇到问题第一反应是降码率,但实际操作中往往把分辨率从1080p降到720p，码率压到1500kbps，画面照样一卡一卡，多数情况下，问题不在编码端，而在链路传输端。
上行带宽不足有两种常见场景,一种是物理带宽确实不够，比如家用宽带的上行只有2-4Mbps，或者户外用4G/5G随身WiFi，信号波动导致实际速率远低于标称值，另一种是带宽够但链路质量差，丢包率高、抖动大，TCP协议下的RTMP推流会频繁重传，表现为码率表上看着不高，但实际占用带宽远超预设值。
区分这两种情况可以靠一次简单的测试,用OBS的自动配置向导，选择"优化直播，录制文件"之外的自定义模式，把码率固定在3000kbps，帧率30，观察10分钟内的丢帧数，如果丢帧率在0.5%以下，说明物理带宽够，问题出在编码参数或协议上；如果丢帧率持续超过1%，说明链路本身已经饱和了。
行业共识认为,推流稳定性的关键指标不是平均码率，而是码率的瞬时峰值能否被链路消化。
链路应对方案：换个协议比调参更直接
RTMP是传统推流协议,基于TCP，优点是兼容性好，几乎所有平台都支持，但TCP的拥塞控制机制在弱网环境下会把丢包重传当成主要任务，导致推流延迟飙升、画面反复缓冲，如果上行丢包率超过2%，RTMP推流的体验会断崖式下跌。
SRT协议是近年来的替代方案,基于UDP，内置前向纠错（FEC）和自动重传（ARQ），能在丢包环境下保持相对稳定的画面输出。SRT在5%丢包率下仍能维持可用画质，而RTMP在同等丢包下基本无法正常推流。
这个差距在户外移动场景里非常明显。
方案对比：
| 对比项 | RTMP | SRT | 备注 |
|---|---|---|---|
| 传输协议 | TCP | UDP | TCP重传策略不适合弱网 |
| 丢包容忍度 | 低于2% | 约5%-10% | 视FEC参数配置而定 |
| 延迟 | 1-3秒 | 5-2秒 | SRT延迟更低 |
| 平台支持 | 几乎所有平台 | 需接收端支持 | 部分平台不支持SRT |
| 配置难度 | 简单 | 中等 | 需设置延迟和FEC参数 |
直播间和平台推流优先选RTMP,因为兼容性是最重要的，但如果是户外直播、赛事转播、异地连线这类链路质量不确定的场景，SRT中继是最好的选择，具体操作方式：先用RTMP推流到本地或云端的SRT中转服务器，再由服务器用RTMP转推给平台，这样既享受SRT的抗丢包能力，又不破坏平台兼容性。
具体链路架构： 推流端（OBS）→ SRT推流 → 中转服务器（如Nginx配合SRT模块）→ RTMP转推 → 直播平台。
编码端配合：码率、帧率、分辨率要联动调整
带宽不足时,只降码率不降帧率，或者只降分辨率不降码率，都是无效操作，三者必须联动调整。
- 分辨率决定像素量，像素量乘以帧率就是每秒要处理的数据量，再乘以编码复杂度系数才是实际码率需求。
- 帧率决定动态流畅度，从60fps降到30fps或是24fps，码率需求直接减半。
- 码率是压缩比的上限，码率越低，压缩越狠，画面细节损失越大。
实操参数建议（以上行带宽3Mbps为例）：
-
如果是游戏直播（动态画面多）：720p + 30fps + 2500kbps，这是画面流畅度与清晰度的均衡点。
- 如果是电台/聊天类（人脸为主）：1080p + 30fps + 3000kbps，静态画面对码率需求没那么高。
- 如果是户外移动直播：720p + 24fps + 2000kbps，优先保链路稳定，画质其次。
OBS里开启"动态码率"选项，让编码器根据链路反馈自动调整码率，比手动压码率更稳，另外关键帧间隔设置2秒，也就是每2秒插入一个完整的I帧，这样即使网络波动导致部分帧丢弃，解码端也能在2秒内恢复画面。
多链路聚合与节点调度：用两条路解决带宽焦虑
单条链路的物理上限就摆在那里,无论怎么调参都有天花板，多链路聚合是把两条或更多独立链路的带宽合并使用，比如4G + 5G + 有线宽带，通过聚合盒子或软件实现。
市面上有专门的聚合推流设备,价格从数百元到数千元不等，但不一定需要额外买硬件，部分直播软件已经集成了简单的多链路聚合功能，或者可以使用开源的聚合方案，通过并行传输、动态调度，将数据块分散到多条链路上，接收端再汇总恢复成完整流，这种方式的实用价值在于：当某条链路突然断掉时，其他链路还能继续顶住，避免直播中断。
链路调度的思路则是把推流请求导向质量更好的节点,国内直播平台通常会提供多个接入节点，自动选择延迟最低的节点，手动操作时，可以查看节点列表的丢包率数据，选择丢包率最低的节点推流，部分第三方工具支持自定义DNS解析，把推流域名解析到更近或负载更低的IP上，也能改善链路质量。
上行带宽不足推流卡顿的应急清单
现场直播中出现卡顿,按以下顺序排查和操作，效率最高：
- 查看OBS右下角丢帧率显示,丢帧率>1%说明链路有问题。
- 切换推流节点,优先选择同省或同运营商的节点。
- 码率降低一档（如3000→2000），帧率保持30不变，先看是否缓解。
- 若仍卡顿,帧率降到24，分辨率降到720p。
- 无效,说明链路物理带宽已经耗尽，改用SRT协议推流到中转再转推。
- 检查WIFI信号强度或移动网络延迟,考虑切换网络或重组路由。
直播画面模糊但没卡顿的情况,多半是码率设置过低而分辨率过高导致的，1080p + 1500kbps的码率，画面一定会糊，这是压缩能力上限决定的，不是调参数能解决的。
Q&A
Q：为什么我推流码率设得很低，上传带宽还是占满？
A：可能是因为编码器使用了CBR固定码率模式，帧率突变或画面剧烈变化时实际编码码率会超过设定值，OBS的采集缓冲和后台其他程序也在占用上行带宽，检查任务管理器网络占用情况，并启用OBS的动态码率选项限制瞬时峰值。
Q：弱网环境下推流画面反复缓冲，换SRT协议一定有效吗？
A：SRT协议比RTMP更适合弱网环境，但它不是万能的，SRT的FEC纠错会引入额外的带宽开销，当物理带宽本身不足以支撑编码码率时，SRT也会卡顿，最稳妥的做法是把SRT和降码率结合起来使用，在保证链路稳定的前提下尽可能提升画质。
Q：推流用什么分辨率？带宽和清晰度怎么选？
A：带宽在2-3Mbps时选720p+30fps，带宽在4Mbps以上时可以尝试1080p+30fps，追求画质上限但带宽有限的情况，优先保证分辨率和帧率中的一个，另一个做降级处理，户外直播常用720p+30fps作为默认配置，因为链路波动对低分辨率流的冲击更小。
上行带宽不足的应对本质上是确认链路物理上限，然后用协议和编码的灵活性去适配它，先测链路，再选协议，随后调三参数，最后留应急方案，照这个顺序走，绝大多数推流卡顿问题都能解决。