做直播的朋友应该都遇到过这种场景正播得热火朝天推流软件突然弹出一条“网络断开”的提示画面直接冻结观众那边开始黑屏转圈又或者连接没断但画面码率被压得越来越低清晰度肉眼可见地往下掉弹幕全在喊卡。这种断流、限流的问题十个里面至少有九个最后都能在网络上找到根源。问题在于很多人第一反应是怀疑电脑配置不行、编码器设置不对甚至直接怪平台暗中搞你唯独漏掉了最该先查的东西——你从本地到直播平台这条网络链路本身。这篇文章把我这几年处理过的直播网络问题做个完整复盘从最基础的概念区分到一步步的排查命令、参数计算、工具用法再到几个真实案例全部写清楚。适合正在被断流问题折磨的娱乐主播、带货运营、做多平台分发的朋友也适合刚入行、想系统了解直播网络原理的新手运营。看完你至少能明白断流和限流到底是不是一回事、该用什么工具查、查出来的数字代表什么、最后怎么落地解决。1. 先分清你遇到的是“断流”还是“被限流”1.1 症状与现象两者最直观的区别所谓断流指的是推流端到平台服务器之间的连接直接中断。表现非常明显——OBS 右侧状态栏的“丢帧”瞬间飙红日志里出现大量 Disconnected、Reconnecting 之类的字样画面整个停住观众端看到的是“主播暂时离开”或者黑屏。严重的时候平台后台会直接判定主播离线整场直播终断你再重推就是一场新的直播之前的观众全部流失。限流就不一样了。连接还在直播也在继续但你会感觉整个链路在悄悄“动手脚”画面从清晰慢慢糊掉码率从 8000Kbps 被压到 3000Kbps 甚至更低观众开始刷“卡了”“糊了”但你的推流端显示一切正常丢帧率也不高。限流可能发生在网络层面比如运营商在高峰期对上行业务做了带宽限制也可能发生在平台层面比如平台侧的接入节点繁忙主动降低了你的码率分配。这两种情况的排查方向是截然不同的搞混了会白费很多功夫。1.2 为什么先分清这件事很重要我见过太多人把这两个问题混在一起处理。以为自己是断流就疯狂重装系统、换直播软件、升级电脑硬件结果问题出在路由器上完全白折腾反过来以为是平台限流跑去跟平台客服申请提权折腾半天才发现是自己家 Wi-Fi 信号不稳推流端持续丢包画面才一直糊。记住一个简单判断口诀连接中断、重连、画面直接停住优先怀疑网络链路连接不断、画质下降、观众卡顿优先怀疑带宽不够或链路质量差。先花五分钟对照症状确认是“连接断”还是“质量降”后面所有排查动作才算有的放矢。2. 正式排查前的准备工具、指标和基线2.1 需要准备的排查工具清单排查直播网络问题不需要多高端的设备一台能开终端的电脑就够了。我常用的工具就这几样ping系统自带用来测基础延迟和丢包是所有排查的第一步。tracert / traceroute / WinMTR测从你本地到平台推流节点的每一跳路由定位瓶颈在哪个环节。iperf3临时搭一个测速点测试真实的 UDP 上行吞吐比网页测速靠谱得多。OBS 自带统计窗口推流时实时看丢帧率、上传带宽、网络抖动这个最直观很多人居然忽略了。平台直播后台的推流状态/健康度页面能看到平台侧接收到的码率和连接质量。这些工具里ping 和 WinMTR 是不需要安装的OBS 统计是软件自带的真正要额外下载的也就是 iperf3而且很小放在 U 盘里随身带都不占地方。我建议长期做直播的朋友把这套工具固定下来别每次都临时找。2.2 必须先建立三个基线指标排查网络问题最忌讳没有参照物。一台设备从来没用过你不可能知道现在的延迟是变高了还是正常。所以在一切正常的时候先花十分钟测出三个基线数值记下来以后出问题才有对比上行带宽实测值不间断测 3 次取最低值这个数字决定了你推流码率的天花板。到推流域名的稳定延迟RTTping 一分钟以上取平均值同时记录最大最小值。丢包率基线正常网络应该是 0%偶尔 1% 以内还能接受超过 2% 就得警惕。有了这三个数值你才敢判断“现在是变差了”还是“其实一直都这样只是今天观众多了感觉明显”。很多人直播卡了一天最后发现自己的上行带宽从来就没够过这种事我见得太多了。2.3 常见误区测速快并不等于推流稳很多人一听网络卡第一件事就是打开测速网站看到“下行 500Mbps”就很安心觉得带宽够够的。这里一定要打破一个误区直播用的是上行带宽衡量的是上传能力而大部分家用宽带套餐标称的都是下行速度上行可能是可怜的 30Mbps 甚至 20Mbps。下行千兆、上行不够导致推流卡顿的家庭我一个月能遇到好几个。另外测速网站的结果是“瞬时峰值”不代表“持续稳定值”。运营商的宽带在最理想状态下能跑出标称速度但你实际推流时链路要承受几分钟甚至几小时的持续压力中间任何一点的拥塞、丢包、运营商限速都会让画面崩掉。所以测速要做但必须做多次、看持续值而不是看那一次最高的数字。3. 本地网络排查从 Wi-Fi 到路由器问题高发区3.1 Wi-Fi 断流的高发原因与解决说句实在话但凡严肃直播我都建议优先用有线网络。Wi-Fi 这东西方便是方便但它是半双工的共享介质信号干扰、路由器带机量、网卡驱动任何一个环节抽风都会导致推流不稳定。如果你确实只能用 Wi-Fi先检查几件事。第一是网卡驱动尤其是 Intel AX200/AX201 这批无线网卡的断流问题特别出名表现为 Wi-Fi 显示连接正常、信号满格但会毫无征兆地断流几秒再自动重连。解决办法是去官方下载最新驱动同时在设备管理器里找到无线网卡在电源管理选项卡中把“允许计算机关闭此设备以节约电源”关掉。第二是信号频段2.4GHz 穿墙好但干扰大路由器放得远了信号弱5GHz 速度快但穿墙差直播设备距离路由器最好在同一个房间、十米以内。第三是用信道扫描工具看看周围 Wi-Fi 信道拥挤程度手动把路由器信道调到一个相对干净的位置能改善不少。还有一个很多人不知道的坑USB 3.0 设备会产生电磁干扰影响 2.4GHz Wi-Fi 信号。如果你的直播设备旁边正好插着 USB 3.0 的移动硬盘或者采集卡Wi-Fi 时不时断一下可以考虑把它们挪远一点或者干脆换 5GHz / 有线。3.2 有线连接也不是万能网卡和路由器同样会出事换了有线就一劳永逸了吗远远不是。网线的质量、水晶头接触、网卡的协商速率每一个环节都可能出问题。先看网卡协商速率在电脑的网络设置里查看当前连接速度千兆网卡应该显示 1.0 Gbps如果显示 100 Mbps 甚至 10 Mbps说明网线或者接口有问题这种降速会导致上行带宽严重不达标。再看网线市面上很多标着“超六类”的网线其实铜包铝长距离传输衰减严重近距离还能跑满稍微远点就出问题。直播设备的网线尽量用正规品牌长度别太长别为了省事把网线绕在电源线上走线。路由器的处理能力也要考虑尤其是那种百来块钱的老路由器。新一代手机的 Wi-Fi 6、智能家居设备、电视盒子全都连在上面连接数一多路由器 CPU 和内存扛不住NAT 会话表溢出轻则个别设备断流重则整个网络瘫痪。直播前重启一次路由器是最简单的办法但治标不治本长期做直播一台支持 QoS 的中端路由器是值得的投资。3.3 光猫、NAT 和“双路由”的坑家庭宽带现在普遍是光猫拨号光猫后面再接你自己的路由器这就形成了两层 NAT。日常上网没问题但直播涉及连麦、接收推流数据、跑一些双向交互协议的时候双 NAT 会导致端口映射失败、连接建立不稳定。如果条件允许我建议把光猫改成桥接模式用你自己的路由器来拨号这样只有一个 NAT 层链路更干净。不过改桥接需要联系运营商要超级管理员账号不是所有地区都给做不到也没关系至少要保证光猫和路由器不要做重复的拨号、重复的 DHCP避免网络环境里出现多个网关冲突。另外检查一下路由器的 UPnP 是否开启这个功能对游戏和直播软件自动做端口映射有帮助默认关闭的话建议打开但要注意它也会带来一定的安全风险家用环境下可以用访问控制列表来约束。4. 上行链路排查带宽、丢包和运营商的一堆事4.1 上行带宽的计算方法既然直播主要吃上行那这个数字怎么算我给大家一个可复用的公式。先看推流软件里设置的码率比如 OBS 里设 6000Kbps意思是每秒要传 6000 千比特的数据。加上协议开销、音频流、以及网络本身的波动余量实际需要的上行带宽大概是码率的 1.5 到 2 倍。也就是说推 6000Kbps 的直播家里上行至少要保证 12Mbps 左右才比较稳。那实际可用上行怎么测最简单的方式是用测速工具选一个离你近的服务器连续测 3 次取最低值。但更准确的做法是用 iperf3 拉一个云服务器做 UDP 上行测试命令大概长这样试 30 秒就能看出稳定上行是多少iperf3 -c 服务器IP -u -b 20M -t 30 --reverse20M 是目标带宽如果结果显示实际吞吐在 15M 上下波动说明你这条链路的上行上限可能就 15M 左右推流码率就得按这个来定。另外别忽略上传任务的干扰家人看视频、手机自动备份照片、游戏下载这些东西会在后台悄悄吃掉大量上行带宽。直播期间把这些全停了是成本最低的优化。4.2 丢包和抖动怎么测带宽够不够决定画面能推多高丢包和抖动则决定画面会不会断、会不会卡。丢包率一高RTMP 这类基于 TCP 的协议会反复重传表现为延迟越来越大、画面越来越卡抖动大观众端缓冲就会频繁被打断出现“一卡一顿”的体验。用 ping 测丢包时别只 ping 几秒钟至少要 ping 一百次以上因为偶发丢包需要足够样本才能暴露出来。Windows 系统可以这样测ping -n 100 -l 1400 推流域名或IP-l 1400是把包加大到接近 MTU 上限这样更能暴露链路质量问题。看结果里的“丢失 0%”和最长时间如果丢包超过 2%直播就极大概率出问题。另外ping 网关测试的是你到路由器的质量ping 运营商网关测试的是你到运营商这一段ping 推流域名测试的是整条链路这三段分开测才能定位故障发生在哪一段。4.3 运营商限速和高峰期的影响我有个朋友的直播一到晚上八点就卡白天完全正常查了半天最后发现是运营商在晚高峰时段对上行业务做了限制。这是很多主播都踩过的坑家用宽带的 QoS 优先级最低到了晚间网络使用高峰运营商会对 P2P、视频上传这类高带宽业务做调度让你的上行带宽缩水。怎么确认很简单白天测一次上行晚上八到十一点再测一次如果差距明显基本可以认定是运营商高峰限速。解决办法几个思路一是把推流码率适当调低并保证稳定比如从 8000 降到 6000画质略降但至少不断流二是换一个时段直播避开晚高峰三是有条件的考虑升级到企业级宽带它的服务等级更高晚高峰限速的概率小很多当然价格也贵不少。另外如果是用 4G/5G 热点或随身 Wi-Fi 推流请直接放弃这个方案移动网络在拥挤环境下的抖动和丢包实在不适合作为固定的直播上行链路。5. 到平台端的路由与 CDN 排查5.1 先确认你推到了哪个节点平台给你的推流地址通常是一个 RTMP 地址比如rtmp://live-push.xxx.com/live/密钥域名背后映射的是一组就近的接入节点。问题在于DNS 解析出来的节点不一定是离你最近或者链路最优的那个尤其是本地运营商 DNS 有缓存污染的时候可能把你导到一个绕远路的节点上。遇到推流地址对应多个 IP、或者平台提供了多个备用推流域名的情况建议先用 ping 和 tracert 分别测一下每个节点手动挑延迟最低、丢包最少的那个来用。如果平台支持选择推流域名华南/华北/华东节点优先选离你地理距离最近的区域别图省事一直用一个固定地址。5.2 traceroute 的解读方法traceroute 是定位链路瓶颈的核心工具。Windows 下直接在命令行用tracert -d 推流域名Linux 或 macOS 用 traceroute或者两个平台都能用图形化的 WinMTR持续追踪一段时间的丢包和延迟。怎么看结果重点看每一跳的延迟数值和最后三跳的丢包率。如果延迟从某一跳开始突然飙升比如前面都是 10ms到了第 8 跳突然变 80ms说明这一跳存在严重的拥塞或绕路。如果丢包集中在中间运营商骨干网的某几个节点那你很难直接解决这是运营商之间互联互通的问题只能靠换推流节点、换协议、或者联系运营商反馈。如果最后一跳或者目标地址本身丢包严重那问题很可能出在平台侧接入节点太忙这时候换节点或者联系平台客服更有效。有个细节要提醒traceroute 中间出现几个* * *不一定是问题很多路由器默认丢弃 ICMP 包或者限制 TTL 响应这不代表链路不通。判断标准是最终能否到达目标、以及最终几跳的延迟和丢包是否正常。5.3 平台侧的健康度怎么看现在主流直播平台的后台基本都提供推流状态或者直播健康度页面能看到平台侧实时接收到的码率、帧率、连接状态。排查断流问题时一定要同时开着你自己的 OBS 统计和平台后台页面对比看。比如 OBS 显示丢帧率 0%、本地一切正常但平台后台显示接收码率忽高忽低说明问题出在你到平台中间这一段优先查路由和运营商。反过来说OBS 本地丢帧率飙升但平台后台显示码率很稳定那可能是你本地电脑编码不稳定或者采集卡/软件设置问题跟网络关系不大。这种“两端对照”的方法能快速帮你判断故障在本地还是在链路这也是我每次排查必做的一步。6. 软件、参数与协议的排查最后一层防线6.1 OBS 推流参数最容易踩的坑网络排查到后面很多人忽略一个事实有时候链路本身没问题是推流软件的参数把网络坑了。最常见的是码率控制模式选错。直播请务必用 CBR 固定码率不要用 VBR 或者 CRF因为 VBR 在不同画面复杂度下码率波动剧烈网络不稳定时容易瞬间冲高导致断流。推荐在 OBS 的输出设置里选“简单输出”模式固然方便但要调细节还是得切到“高级输出”把码率控制设为 CBR关键帧间隔设 2 秒部分平台要求 1 或 4 秒以平台文档为准缓冲区大小通常等于目标码率比如目标 6000缓冲也填 6000。还有一个参数是“自动重连”。OBS 设置里有“自动重连”开关和重连延迟很多人开着但延迟设得特别长网络闪断一下后要等很久才恢复。建议把重连延迟设短比如 1 到 2 秒最多重连次数设个十几次这样短时抖动不会直接导致直播终断。另外低延迟模式这类选项要慎开它靠减少缓冲来换取更低时延网络稍一波动反而更容易断追求稳定优先的话保持默认缓冲更稳妥。6.2 RTMP、RTMPS、SRT换个协议可能就能救回来现在平台推流的主流还是 RTMP它基于 TCP优点是兼容性好、几乎所有平台都支持缺点是对丢包极其敏感——一旦链路出现丢包TCP 的拥塞控制和重传机制会让延迟滚雪球式上升最终断流。RTMPS 是 RTMP 加了 TLS 加密安全性好但开销更大对网络要求更高。如果你的平台支持 SRT 协议我强烈建议试试。SRT 基于 UDP 设计自带丢包重传和前向纠错能在网络质量较差的环境下保持稳定的推流连接。同样是丢包 2% 的链路上RTMP 可能已经断成狗SRT 还能稳住 1080p 的画面。我实际测试过跨省推流到远端节点SRT 的断流率比 RTMP 低很多。缺点是对平台支持要求高不是每个平台都开放 SRT 接入而且有一定额外延迟但只要平台支持多播平台分发场景下这是非常值得推荐的一个协议选择。6.3 防火墙、安全软件和代理类工具的干扰Windows 防火墙第一次运行 OBS 时会弹出联网确认框如果当时点了“取消”之后 OBS 的推流连接可能被防火墙静默拦掉一部分。检查防火墙和杀毒软件里有没有把 OBS、直播软件的联网行为当作可疑流量处理如果有手动添加放行规则。另外一些安全软件开启“全网监控”或“加密扫描”功能后会代理你的网络流量导致推流的 TCP 连接被二次封装稳定性大幅下降直播前把这些功能关掉或者把直播软件加入白名单会好很多。这里要特别提醒一类工具各种代理类软件、加速器。这类工具一旦开启会把系统全部流量或者部分流量导向异常路径直播推流这种对实时性要求极高的长连接流量被这么一转延迟和抖动都会明显恶化断流频繁几乎是必然结果。排查断流问题时请把所有这类全局代理、加速器软件彻底退出确认没有后台常驻进程再测试。这一点很多教程不会提但实际遇到的概率真不小。7. 常见问题速查表与三个实战案例复盘7.1 断流限流问题速查表现象优先怀疑原因第一步处理直播中途频繁重新连接本地上行不稳、Wi-Fi 信号差、路由器老化换有线测ping 网关判断本地丢包画质逐渐变糊但不断流上行带宽不足、运营商高峰限速测连续上行降低推流码率或换时段连麦时断流加重NAT 类型限制、UPnP 未开启、双 NAT光猫改桥接开启 UPnP检查 NAT 类型只有晚上固定时间卡运营商晚高峰拥塞/限速与白天对比测速调低码率或升级宽带推流域名延迟高、路由绕路DNS 解析到差节点、跨运营商互通问题换推流节点用公共 DNS 重新解析特定网卡频繁断流网卡驱动或省电机制问题更新驱动关闭节能选项换有线开了加速器后更卡代理流量路径异常完全退出代理/加速类软件再测OBS 正常但平台端码率波动链路中间拥塞或平台接入节点繁忙traceroute 对照联系平台客服反馈7.2 案例一Intel AX201 网卡半夜断流有个主播朋友新配的笔记本Intel AX201 无线网卡Wi-Fi 显示信号满格但每晚直播必断流几次时间不固定有时开播十分钟就断。一开始他怀疑是平台问题换了两个平台照样断。我让他先在 OBS 统计里观察发现断流前几秒有大量丢帧而且断流后 Wi-Fi 会短暂重新连接。这才确定是无线网卡的问题。处理方法是更新到最新网卡驱动把电源管理里“允许计算机关闭此设备以节约电源”关掉同时把路由器信道从拥挤的自动模式改为固定信道。处理后断流问题基本消失。这个案例说明网卡驱动和节能策略导致的断流症状和网络链路问题一模一样但方向完全不一样不查软件层面根本定位不到。7.3 案例二路由器 NAT 表满一开播就全家断网另一个朋友家里设备特别多电视、盒子、摄像头、手机、平板加起来快二十台。直播时经常出现推流丢帧、连麦失败甚至有时候整个家里网络都断。排查时我 ping 网关发现延迟忽高忽低重启路由器后短时间正常过一会儿又复发。这是典型的路由器连接数被打满了。解决方法是先确定路由器带机能力几十块的老路由器确实扛不住这么多设备。我给他开了 QoS把直播电脑的 MAC 地址设为最高优先级同时把一些 P2P 下载设备限速再观察。效果改善明显但长期看还是换了一台中端路由。这个案例给所有直播人的提醒是你家的路由器不只是服务你的电脑全家设备都在抢占资源直播前至少要做到关闭大流量应用有条件就上 QoS。7.4 案例三白天正常晚上糊运营商高峰限速这个案例就是前面提到的晚间限速问题。主播住老小区宽带标称上行 50Mbps白天实测能有 35Mbps 左右推 8000Kbps 的 1080p 完全没问题。但每晚八点以后实测上行掉到 10Mbps 以下画面只能在 480p 和 720p 之间来回切换。处理上一是把推流码率从 8000 降到 6000帧率从 60 降到 30牺牲一部分画质换来画面不糊二是尝试用平台支持的 SRT 线路推流在丢包链路下比 RTMP 稳定不少三是跟运营商反馈现象看当地有没有企业宽带优惠套餐如果直播是主要收入来源该升级就升级。这个案例说明带宽瓶颈不一定是你的问题运营商的政策和链路质量同样会直接影响直播效果。做直播这几年我养成了一个习惯每次直播前固定花两分钟做一个“体检”——看 OBS 统计、ping 一下推流域名、确认没有大流量任务在后台跑播完顺手记一条直播日志。别小看这两分钟很多问题不是“没遇到”而是“没记下来”。等到断流的时候再临时抓瞎连基线都没有根本判断不了是网络变差了还是本来就这样。有这条基线在手再去跟运营商工程师或平台客服沟通一报数据对方就知道你不是小白处理效率完全不一样。网络排查这事说穿了就两个字耐心。一步一个脚印把链路每一段都查清楚断流和限流的坑总能填平。
直播断流与限流排查指南：从网络链路到推流参数全解析
做直播的朋友应该都遇到过这种场景正播得热火朝天推流软件突然弹出一条“网络断开”的提示画面直接冻结观众那边开始黑屏转圈又或者连接没断但画面码率被压得越来越低清晰度肉眼可见地往下掉弹幕全在喊卡。这种断流、限流的问题十个里面至少有九个最后都能在网络上找到根源。问题在于很多人第一反应是怀疑电脑配置不行、编码器设置不对甚至直接怪平台暗中搞你唯独漏掉了最该先查的东西——你从本地到直播平台这条网络链路本身。这篇文章把我这几年处理过的直播网络问题做个完整复盘从最基础的概念区分到一步步的排查命令、参数计算、工具用法再到几个真实案例全部写清楚。适合正在被断流问题折磨的娱乐主播、带货运营、做多平台分发的朋友也适合刚入行、想系统了解直播网络原理的新手运营。看完你至少能明白断流和限流到底是不是一回事、该用什么工具查、查出来的数字代表什么、最后怎么落地解决。1. 先分清你遇到的是“断流”还是“被限流”1.1 症状与现象两者最直观的区别所谓断流指的是推流端到平台服务器之间的连接直接中断。表现非常明显——OBS 右侧状态栏的“丢帧”瞬间飙红日志里出现大量 Disconnected、Reconnecting 之类的字样画面整个停住观众端看到的是“主播暂时离开”或者黑屏。严重的时候平台后台会直接判定主播离线整场直播终断你再重推就是一场新的直播之前的观众全部流失。限流就不一样了。连接还在直播也在继续但你会感觉整个链路在悄悄“动手脚”画面从清晰慢慢糊掉码率从 8000Kbps 被压到 3000Kbps 甚至更低观众开始刷“卡了”“糊了”但你的推流端显示一切正常丢帧率也不高。限流可能发生在网络层面比如运营商在高峰期对上行业务做了带宽限制也可能发生在平台层面比如平台侧的接入节点繁忙主动降低了你的码率分配。这两种情况的排查方向是截然不同的搞混了会白费很多功夫。1.2 为什么先分清这件事很重要我见过太多人把这两个问题混在一起处理。以为自己是断流就疯狂重装系统、换直播软件、升级电脑硬件结果问题出在路由器上完全白折腾反过来以为是平台限流跑去跟平台客服申请提权折腾半天才发现是自己家 Wi-Fi 信号不稳推流端持续丢包画面才一直糊。记住一个简单判断口诀连接中断、重连、画面直接停住优先怀疑网络链路连接不断、画质下降、观众卡顿优先怀疑带宽不够或链路质量差。先花五分钟对照症状确认是“连接断”还是“质量降”后面所有排查动作才算有的放矢。2. 正式排查前的准备工具、指标和基线2.1 需要准备的排查工具清单排查直播网络问题不需要多高端的设备一台能开终端的电脑就够了。我常用的工具就这几样ping系统自带用来测基础延迟和丢包是所有排查的第一步。tracert / traceroute / WinMTR测从你本地到平台推流节点的每一跳路由定位瓶颈在哪个环节。iperf3临时搭一个测速点测试真实的 UDP 上行吞吐比网页测速靠谱得多。OBS 自带统计窗口推流时实时看丢帧率、上传带宽、网络抖动这个最直观很多人居然忽略了。平台直播后台的推流状态/健康度页面能看到平台侧接收到的码率和连接质量。这些工具里ping 和 WinMTR 是不需要安装的OBS 统计是软件自带的真正要额外下载的也就是 iperf3而且很小放在 U 盘里随身带都不占地方。我建议长期做直播的朋友把这套工具固定下来别每次都临时找。2.2 必须先建立三个基线指标排查网络问题最忌讳没有参照物。一台设备从来没用过你不可能知道现在的延迟是变高了还是正常。所以在一切正常的时候先花十分钟测出三个基线数值记下来以后出问题才有对比上行带宽实测值不间断测 3 次取最低值这个数字决定了你推流码率的天花板。到推流域名的稳定延迟RTTping 一分钟以上取平均值同时记录最大最小值。丢包率基线正常网络应该是 0%偶尔 1% 以内还能接受超过 2% 就得警惕。有了这三个数值你才敢判断“现在是变差了”还是“其实一直都这样只是今天观众多了感觉明显”。很多人直播卡了一天最后发现自己的上行带宽从来就没够过这种事我见得太多了。2.3 常见误区测速快并不等于推流稳很多人一听网络卡第一件事就是打开测速网站看到“下行 500Mbps”就很安心觉得带宽够够的。这里一定要打破一个误区直播用的是上行带宽衡量的是上传能力而大部分家用宽带套餐标称的都是下行速度上行可能是可怜的 30Mbps 甚至 20Mbps。下行千兆、上行不够导致推流卡顿的家庭我一个月能遇到好几个。另外测速网站的结果是“瞬时峰值”不代表“持续稳定值”。运营商的宽带在最理想状态下能跑出标称速度但你实际推流时链路要承受几分钟甚至几小时的持续压力中间任何一点的拥塞、丢包、运营商限速都会让画面崩掉。所以测速要做但必须做多次、看持续值而不是看那一次最高的数字。3. 本地网络排查从 Wi-Fi 到路由器问题高发区3.1 Wi-Fi 断流的高发原因与解决说句实在话但凡严肃直播我都建议优先用有线网络。Wi-Fi 这东西方便是方便但它是半双工的共享介质信号干扰、路由器带机量、网卡驱动任何一个环节抽风都会导致推流不稳定。如果你确实只能用 Wi-Fi先检查几件事。第一是网卡驱动尤其是 Intel AX200/AX201 这批无线网卡的断流问题特别出名表现为 Wi-Fi 显示连接正常、信号满格但会毫无征兆地断流几秒再自动重连。解决办法是去官方下载最新驱动同时在设备管理器里找到无线网卡在电源管理选项卡中把“允许计算机关闭此设备以节约电源”关掉。第二是信号频段2.4GHz 穿墙好但干扰大路由器放得远了信号弱5GHz 速度快但穿墙差直播设备距离路由器最好在同一个房间、十米以内。第三是用信道扫描工具看看周围 Wi-Fi 信道拥挤程度手动把路由器信道调到一个相对干净的位置能改善不少。还有一个很多人不知道的坑USB 3.0 设备会产生电磁干扰影响 2.4GHz Wi-Fi 信号。如果你的直播设备旁边正好插着 USB 3.0 的移动硬盘或者采集卡Wi-Fi 时不时断一下可以考虑把它们挪远一点或者干脆换 5GHz / 有线。3.2 有线连接也不是万能网卡和路由器同样会出事换了有线就一劳永逸了吗远远不是。网线的质量、水晶头接触、网卡的协商速率每一个环节都可能出问题。先看网卡协商速率在电脑的网络设置里查看当前连接速度千兆网卡应该显示 1.0 Gbps如果显示 100 Mbps 甚至 10 Mbps说明网线或者接口有问题这种降速会导致上行带宽严重不达标。再看网线市面上很多标着“超六类”的网线其实铜包铝长距离传输衰减严重近距离还能跑满稍微远点就出问题。直播设备的网线尽量用正规品牌长度别太长别为了省事把网线绕在电源线上走线。路由器的处理能力也要考虑尤其是那种百来块钱的老路由器。新一代手机的 Wi-Fi 6、智能家居设备、电视盒子全都连在上面连接数一多路由器 CPU 和内存扛不住NAT 会话表溢出轻则个别设备断流重则整个网络瘫痪。直播前重启一次路由器是最简单的办法但治标不治本长期做直播一台支持 QoS 的中端路由器是值得的投资。3.3 光猫、NAT 和“双路由”的坑家庭宽带现在普遍是光猫拨号光猫后面再接你自己的路由器这就形成了两层 NAT。日常上网没问题但直播涉及连麦、接收推流数据、跑一些双向交互协议的时候双 NAT 会导致端口映射失败、连接建立不稳定。如果条件允许我建议把光猫改成桥接模式用你自己的路由器来拨号这样只有一个 NAT 层链路更干净。不过改桥接需要联系运营商要超级管理员账号不是所有地区都给做不到也没关系至少要保证光猫和路由器不要做重复的拨号、重复的 DHCP避免网络环境里出现多个网关冲突。另外检查一下路由器的 UPnP 是否开启这个功能对游戏和直播软件自动做端口映射有帮助默认关闭的话建议打开但要注意它也会带来一定的安全风险家用环境下可以用访问控制列表来约束。4. 上行链路排查带宽、丢包和运营商的一堆事4.1 上行带宽的计算方法既然直播主要吃上行那这个数字怎么算我给大家一个可复用的公式。先看推流软件里设置的码率比如 OBS 里设 6000Kbps意思是每秒要传 6000 千比特的数据。加上协议开销、音频流、以及网络本身的波动余量实际需要的上行带宽大概是码率的 1.5 到 2 倍。也就是说推 6000Kbps 的直播家里上行至少要保证 12Mbps 左右才比较稳。那实际可用上行怎么测最简单的方式是用测速工具选一个离你近的服务器连续测 3 次取最低值。但更准确的做法是用 iperf3 拉一个云服务器做 UDP 上行测试命令大概长这样试 30 秒就能看出稳定上行是多少iperf3 -c 服务器IP -u -b 20M -t 30 --reverse20M 是目标带宽如果结果显示实际吞吐在 15M 上下波动说明你这条链路的上行上限可能就 15M 左右推流码率就得按这个来定。另外别忽略上传任务的干扰家人看视频、手机自动备份照片、游戏下载这些东西会在后台悄悄吃掉大量上行带宽。直播期间把这些全停了是成本最低的优化。4.2 丢包和抖动怎么测带宽够不够决定画面能推多高丢包和抖动则决定画面会不会断、会不会卡。丢包率一高RTMP 这类基于 TCP 的协议会反复重传表现为延迟越来越大、画面越来越卡抖动大观众端缓冲就会频繁被打断出现“一卡一顿”的体验。用 ping 测丢包时别只 ping 几秒钟至少要 ping 一百次以上因为偶发丢包需要足够样本才能暴露出来。Windows 系统可以这样测ping -n 100 -l 1400 推流域名或IP-l 1400是把包加大到接近 MTU 上限这样更能暴露链路质量问题。看结果里的“丢失 0%”和最长时间如果丢包超过 2%直播就极大概率出问题。另外ping 网关测试的是你到路由器的质量ping 运营商网关测试的是你到运营商这一段ping 推流域名测试的是整条链路这三段分开测才能定位故障发生在哪一段。4.3 运营商限速和高峰期的影响我有个朋友的直播一到晚上八点就卡白天完全正常查了半天最后发现是运营商在晚高峰时段对上行业务做了限制。这是很多主播都踩过的坑家用宽带的 QoS 优先级最低到了晚间网络使用高峰运营商会对 P2P、视频上传这类高带宽业务做调度让你的上行带宽缩水。怎么确认很简单白天测一次上行晚上八到十一点再测一次如果差距明显基本可以认定是运营商高峰限速。解决办法几个思路一是把推流码率适当调低并保证稳定比如从 8000 降到 6000画质略降但至少不断流二是换一个时段直播避开晚高峰三是有条件的考虑升级到企业级宽带它的服务等级更高晚高峰限速的概率小很多当然价格也贵不少。另外如果是用 4G/5G 热点或随身 Wi-Fi 推流请直接放弃这个方案移动网络在拥挤环境下的抖动和丢包实在不适合作为固定的直播上行链路。5. 到平台端的路由与 CDN 排查5.1 先确认你推到了哪个节点平台给你的推流地址通常是一个 RTMP 地址比如rtmp://live-push.xxx.com/live/密钥域名背后映射的是一组就近的接入节点。问题在于DNS 解析出来的节点不一定是离你最近或者链路最优的那个尤其是本地运营商 DNS 有缓存污染的时候可能把你导到一个绕远路的节点上。遇到推流地址对应多个 IP、或者平台提供了多个备用推流域名的情况建议先用 ping 和 tracert 分别测一下每个节点手动挑延迟最低、丢包最少的那个来用。如果平台支持选择推流域名华南/华北/华东节点优先选离你地理距离最近的区域别图省事一直用一个固定地址。5.2 traceroute 的解读方法traceroute 是定位链路瓶颈的核心工具。Windows 下直接在命令行用tracert -d 推流域名Linux 或 macOS 用 traceroute或者两个平台都能用图形化的 WinMTR持续追踪一段时间的丢包和延迟。怎么看结果重点看每一跳的延迟数值和最后三跳的丢包率。如果延迟从某一跳开始突然飙升比如前面都是 10ms到了第 8 跳突然变 80ms说明这一跳存在严重的拥塞或绕路。如果丢包集中在中间运营商骨干网的某几个节点那你很难直接解决这是运营商之间互联互通的问题只能靠换推流节点、换协议、或者联系运营商反馈。如果最后一跳或者目标地址本身丢包严重那问题很可能出在平台侧接入节点太忙这时候换节点或者联系平台客服更有效。有个细节要提醒traceroute 中间出现几个* * *不一定是问题很多路由器默认丢弃 ICMP 包或者限制 TTL 响应这不代表链路不通。判断标准是最终能否到达目标、以及最终几跳的延迟和丢包是否正常。5.3 平台侧的健康度怎么看现在主流直播平台的后台基本都提供推流状态或者直播健康度页面能看到平台侧实时接收到的码率、帧率、连接状态。排查断流问题时一定要同时开着你自己的 OBS 统计和平台后台页面对比看。比如 OBS 显示丢帧率 0%、本地一切正常但平台后台显示接收码率忽高忽低说明问题出在你到平台中间这一段优先查路由和运营商。反过来说OBS 本地丢帧率飙升但平台后台显示码率很稳定那可能是你本地电脑编码不稳定或者采集卡/软件设置问题跟网络关系不大。这种“两端对照”的方法能快速帮你判断故障在本地还是在链路这也是我每次排查必做的一步。6. 软件、参数与协议的排查最后一层防线6.1 OBS 推流参数最容易踩的坑网络排查到后面很多人忽略一个事实有时候链路本身没问题是推流软件的参数把网络坑了。最常见的是码率控制模式选错。直播请务必用 CBR 固定码率不要用 VBR 或者 CRF因为 VBR 在不同画面复杂度下码率波动剧烈网络不稳定时容易瞬间冲高导致断流。推荐在 OBS 的输出设置里选“简单输出”模式固然方便但要调细节还是得切到“高级输出”把码率控制设为 CBR关键帧间隔设 2 秒部分平台要求 1 或 4 秒以平台文档为准缓冲区大小通常等于目标码率比如目标 6000缓冲也填 6000。还有一个参数是“自动重连”。OBS 设置里有“自动重连”开关和重连延迟很多人开着但延迟设得特别长网络闪断一下后要等很久才恢复。建议把重连延迟设短比如 1 到 2 秒最多重连次数设个十几次这样短时抖动不会直接导致直播终断。另外低延迟模式这类选项要慎开它靠减少缓冲来换取更低时延网络稍一波动反而更容易断追求稳定优先的话保持默认缓冲更稳妥。6.2 RTMP、RTMPS、SRT换个协议可能就能救回来现在平台推流的主流还是 RTMP它基于 TCP优点是兼容性好、几乎所有平台都支持缺点是对丢包极其敏感——一旦链路出现丢包TCP 的拥塞控制和重传机制会让延迟滚雪球式上升最终断流。RTMPS 是 RTMP 加了 TLS 加密安全性好但开销更大对网络要求更高。如果你的平台支持 SRT 协议我强烈建议试试。SRT 基于 UDP 设计自带丢包重传和前向纠错能在网络质量较差的环境下保持稳定的推流连接。同样是丢包 2% 的链路上RTMP 可能已经断成狗SRT 还能稳住 1080p 的画面。我实际测试过跨省推流到远端节点SRT 的断流率比 RTMP 低很多。缺点是对平台支持要求高不是每个平台都开放 SRT 接入而且有一定额外延迟但只要平台支持多播平台分发场景下这是非常值得推荐的一个协议选择。6.3 防火墙、安全软件和代理类工具的干扰Windows 防火墙第一次运行 OBS 时会弹出联网确认框如果当时点了“取消”之后 OBS 的推流连接可能被防火墙静默拦掉一部分。检查防火墙和杀毒软件里有没有把 OBS、直播软件的联网行为当作可疑流量处理如果有手动添加放行规则。另外一些安全软件开启“全网监控”或“加密扫描”功能后会代理你的网络流量导致推流的 TCP 连接被二次封装稳定性大幅下降直播前把这些功能关掉或者把直播软件加入白名单会好很多。这里要特别提醒一类工具各种代理类软件、加速器。这类工具一旦开启会把系统全部流量或者部分流量导向异常路径直播推流这种对实时性要求极高的长连接流量被这么一转延迟和抖动都会明显恶化断流频繁几乎是必然结果。排查断流问题时请把所有这类全局代理、加速器软件彻底退出确认没有后台常驻进程再测试。这一点很多教程不会提但实际遇到的概率真不小。7. 常见问题速查表与三个实战案例复盘7.1 断流限流问题速查表现象优先怀疑原因第一步处理直播中途频繁重新连接本地上行不稳、Wi-Fi 信号差、路由器老化换有线测ping 网关判断本地丢包画质逐渐变糊但不断流上行带宽不足、运营商高峰限速测连续上行降低推流码率或换时段连麦时断流加重NAT 类型限制、UPnP 未开启、双 NAT光猫改桥接开启 UPnP检查 NAT 类型只有晚上固定时间卡运营商晚高峰拥塞/限速与白天对比测速调低码率或升级宽带推流域名延迟高、路由绕路DNS 解析到差节点、跨运营商互通问题换推流节点用公共 DNS 重新解析特定网卡频繁断流网卡驱动或省电机制问题更新驱动关闭节能选项换有线开了加速器后更卡代理流量路径异常完全退出代理/加速类软件再测OBS 正常但平台端码率波动链路中间拥塞或平台接入节点繁忙traceroute 对照联系平台客服反馈7.2 案例一Intel AX201 网卡半夜断流有个主播朋友新配的笔记本Intel AX201 无线网卡Wi-Fi 显示信号满格但每晚直播必断流几次时间不固定有时开播十分钟就断。一开始他怀疑是平台问题换了两个平台照样断。我让他先在 OBS 统计里观察发现断流前几秒有大量丢帧而且断流后 Wi-Fi 会短暂重新连接。这才确定是无线网卡的问题。处理方法是更新到最新网卡驱动把电源管理里“允许计算机关闭此设备以节约电源”关掉同时把路由器信道从拥挤的自动模式改为固定信道。处理后断流问题基本消失。这个案例说明网卡驱动和节能策略导致的断流症状和网络链路问题一模一样但方向完全不一样不查软件层面根本定位不到。7.3 案例二路由器 NAT 表满一开播就全家断网另一个朋友家里设备特别多电视、盒子、摄像头、手机、平板加起来快二十台。直播时经常出现推流丢帧、连麦失败甚至有时候整个家里网络都断。排查时我 ping 网关发现延迟忽高忽低重启路由器后短时间正常过一会儿又复发。这是典型的路由器连接数被打满了。解决方法是先确定路由器带机能力几十块的老路由器确实扛不住这么多设备。我给他开了 QoS把直播电脑的 MAC 地址设为最高优先级同时把一些 P2P 下载设备限速再观察。效果改善明显但长期看还是换了一台中端路由。这个案例给所有直播人的提醒是你家的路由器不只是服务你的电脑全家设备都在抢占资源直播前至少要做到关闭大流量应用有条件就上 QoS。7.4 案例三白天正常晚上糊运营商高峰限速这个案例就是前面提到的晚间限速问题。主播住老小区宽带标称上行 50Mbps白天实测能有 35Mbps 左右推 8000Kbps 的 1080p 完全没问题。但每晚八点以后实测上行掉到 10Mbps 以下画面只能在 480p 和 720p 之间来回切换。处理上一是把推流码率从 8000 降到 6000帧率从 60 降到 30牺牲一部分画质换来画面不糊二是尝试用平台支持的 SRT 线路推流在丢包链路下比 RTMP 稳定不少三是跟运营商反馈现象看当地有没有企业宽带优惠套餐如果直播是主要收入来源该升级就升级。这个案例说明带宽瓶颈不一定是你的问题运营商的政策和链路质量同样会直接影响直播效果。做直播这几年我养成了一个习惯每次直播前固定花两分钟做一个“体检”——看 OBS 统计、ping 一下推流域名、确认没有大流量任务在后台跑播完顺手记一条直播日志。别小看这两分钟很多问题不是“没遇到”而是“没记下来”。等到断流的时候再临时抓瞎连基线都没有根本判断不了是网络变差了还是本来就这样。有这条基线在手再去跟运营商工程师或平台客服沟通一报数据对方就知道你不是小白处理效率完全不一样。网络排查这事说穿了就两个字耐心。一步一个脚印把链路每一段都查清楚断流和限流的坑总能填平。