上行带宽不足时，链路应对的核心顺序是：先压编码码率，再换自适应传输协议，最后叠加多链路聚合，每一步都服务于保住关键帧和连接不断线。
上行带宽不足怎么办先判断瓶颈再动手
很多人一遇到推流卡顿就急着调码率,结果画面糊了，卡顿还在，问题不总在带宽大小，可能出在线路质量，也可能出在你的网卡和路由器协商速率上，动手改任何参数之前，先花五分钟确认瓶颈在哪。
用OBS的带宽测试功能摸底
OBS自带的“自动配置向导”里有带宽检测，但那个结果偏理想化，更靠谱的做法是：
- 打开OBS的设置 → 推流 → 服务，选一个你实际要用的平台节点
- 用OBS的“检测带宽”功能连续跑三轮，取最低值作为你的可靠上行
- 跑测试时关掉所有其他占用网络的应用,包括手机自动备份和云盘同步
如果软件测出的最大可用带宽是你目标码率的1.5倍以上，瓶颈大概率不在物理带宽，而在线路抖动或丢包。
分清带宽不足和线路差
行内有个说法：上行带宽是水管粗细，线路质量是水压稳定性，水管粗但水压忽高忽低，一样会断流，判断方法是观察推流日志中的丢包率，丢包率低于1%而帧数下降明显，可能是编码器负载过高；丢包率长期高于3%，线路质量才是主因。
直播上行带宽不够时，码率与编码参数的调整顺序
确认带宽确实不够,再进入参数调整环节，调整顺序有讲究：先动码率，再动分辨率，最后动帧率，顺序反了会成倍放大画质损失。
码率压到带宽的几成才合理
直播推流码率建议压到实际可用带宽的75%到80%，不要顶满，顶满时遇到瞬时波动，链路没有重传余量，视频必然卡死，以一个实际场景为例：你用手机热点直播，测出上行带宽约4Mbps，那码率设定在3200Kbps左右是合理的，留出的800Kbps给控制信令和网络抖动做缓冲。
动态码率：让编码器自己跟着链路走
OBS 28以上版本支持动态码率，在“输出 → 比特率”里勾选“动态比特率”，编码器会根据你设定的目标码率范围和实际链路状况自动升降，配合丢包自动调低码率选项，大多数轻度抖动场景能自行消化。
分辨率和帧率的取舍顺序
- 带宽只剩原来的一半：把分辨率从1080P降到720P，帧率保持30帧
- 带宽只剩四分之一：分辨率降到720P，帧率降到25帧，码率压到1500Kbps
- 带宽严重不足：优先保住画面流畅度，分辨率再降到540P，但尽量不降帧率，因为帧率突变在观众端感知非常明显
关闭B帧和调整GOP，降低解码端压力
在“输出 → 编码器设置”里，x264编码器把“B帧数”设为0，能减少画面解码顺序的复杂性，一定程度降低带宽波动带来的花屏概率，GOP（关键帧间隔）建议设置在2秒，即帧率30时设60，帧率25时设50，过长的GOP会导致画面切换时长时间模糊，过短则浪费带宽。
传输链路层面的应对：SRT推流协议与自适应码率
码率压到极限还不够,带宽不足时，传输协议往往决定生死，行业共识认为，传统RTMP协议用TCP传输，丢包后会重传但会引入延迟堆积；而SRT协议基于UDP，自带丢包重传和带宽自适应机制，在弱网环境下的表现明显更稳。
什么时候值得把RTMP换成SRT
满足以下任意一个条件,就值得换：
- 上行带宽波动幅度超过30%
- 推流到跨地域的服务器节点,比如人在四川推流到华东机房
- 长时间户外移动直播,多普勒效应导致信号频繁切换
OBS切换SRT的实操路径
- 在OBS设置 → 推流 → 服务，选择“自定义”
- 在服务器栏填入SRT地址,格式为
srt://推流地址:端口?mode=caller&latency=2000000 - 串流密钥保持与RTMP模式下的Stream Key一致
- 在“输出 → 高级模式”中，编码器选择“x264”，速率控制选“VBR”
- 确认推流平台支持SRT接入,不支持时可用FFmpeg转封装：
ffmpeg -i rtmp地址 -c copy -f mpegts srt目标地址，无需重新编码，CPU开销很小
SRT的latency参数设定也有讲究,2000毫秒是户外直播和演唱会直播的常用值，过低会频繁触发重传，过高又会让互动延迟变大。
自适应码率协议：不止SRT一个选项
- RIST协议：抗丢包能力与SRT相近，但拥塞控制更激进，适合网络质量尚可但带宽不高的场景
- QUIC协议：基于UDP的新一代传输协议，抗丢包能力不错，但直播平台兼容性还在爬坡期
- RTMPS（RTMP over TLS）：只是加了一层加密，对带宽不足没有任何改善，别做无用功
多链路聚合与边缘接入，缓解推流卡顿的上行压力
单条链路的物理上限就在那,协议优化到头了还是不够，就得用聚合策略把多条链路的带宽合并使用。
软硬件聚合方案怎么选
- 软件方案：用Zixi或FFmpeg的Multi-path插件，把视频流拆成多份，通过不同链路发送到服务端再合并，优点是几乎零成本，缺点是拆包逻辑和服务器端的合并逻辑都得自己配置，适合有一定技术底子的团队
- 硬件方案：LARIAT、LiveU等聚合编码器，插两到三张SIM卡，自动把数据包分发到不同的运营商网络，业内专家指出，这类设备对网络切换的容错能力远强于普通路由器拨号，但价格相当于一台中高端电脑，适合专业直播团队
聚合时的链路管理规则
- 永远把主链路设为有线宽带,哪怕它带宽只有副链路的一半，有线链路的抖动远低于4G/5G无线链路
- 两条链路的延迟差超过100ms时,优先丢弃高延迟链路的数据包，而不是等它慢慢追上来
- 定期检查各链路的健康状态,每30秒一次ping测试，丢包率连续三次超过5%就把权重转移给备用链路
边缘节点就近接入，少走冤枉路
带宽不足有时候不是真的不够,而是你的推流数据绕了远路，国内主流云直播平台都有边缘推流节点，接入点离你越近，物理链路越短，抖动和丢包概率越低，如果你在二三线城市或西部省份，优先选择有当地节点的云直播服务商，查询方式：在服务商控制台查看推流域名的CNAME解析结果，看解析到哪个城市的IP段，就近节点没有接入，也可以用HTTPDNS服务强行指定最近的边缘节点。
问与答：上行带宽不足怎么办的常见场景
上行带宽不足怎么办，先调码率还是先换协议？
先压码率,调整码率是本地操作，立即生效，成本几乎为零；换协议需要平台支持，还要验证链路稳定性，把码率压到可用带宽的80%之后仍频繁丢包，再切换到SRT协议，协议切换后码率可以适当回升10%~15%，因为SRT的重传机制比RTMP更高效。
直播上行带宽不够，OBS一直提示“丢帧”怎么处理？
打开OBS的“视图 → 统计”面板，观察“丢帧数”和“网络抖动”两个指标，丢帧率在0.5%以内属于正常波动，超过1%就按三层排查：先检查路由器是否为QoS设置了限制，其次看电脑网卡是否有省电模式在降速，最后用mtr命令追踪到推流节点的每一跳丢包情况，哪个节点丢包高就在服务商控制台切换推流线路。