“直播不稳定”这五个字，在排障时几乎没有信息量。
它至少对应三种完全不同的故障，原因不同，解法也不通用。用错解法的结果是折腾一周没效果，然后归咎于“跨境网络就这样”。
先把它拆开。
三种症状，三个方向
一、画面变糊，码率掉下来
表现是清晰度肉眼可见地降级，但没有卡顿，观众能连续看。推流软件的码率曲线会往下掉。
这是上行带宽不够，或者被别的东西抢走了。编码器检测到发不出去，主动降码率保连续性——这是它设计好的行为，不是故障。
方向：查上行带宽和抢占。
二、卡顿、缓冲、观众端转圈
表现是画面清晰但一顿一顿，观众端出现加载圈。推流软件可能显示丢帧。
这是丢包或延迟抖动。带宽可能完全够，但包在路上丢了或者到达时间忽早忽晚，接收端拼不起连续的流。
方向：查链路质量，不是查带宽。
三、直接断流，需要重连
表现是推流中断，软件报连接断开，要手动或自动重连，观众看到直播结束或黑屏。
这是长连接被中断了。可能是 IP 变了、路由切换了、中间设备回收了会话。
方向：查连接的连续性，跟带宽和丢包都无关。
这三种混在一起说成“不稳定”，是排障效率最大的浪费。开播时先记下是哪一种。
码率和上行带宽的关系
推流码率不是你需要的带宽。需要的上行带宽是码率乘以一个余量系数。
常见的码率区间：
| 规格 码率 | |
| 720p / 30fps | 2.5–4 Mbps |
| 1080p / 30fps | 4–6 Mbps |
| 1080p / 60fps | 6–9 Mbps |
余量系数建议按 1.5 到 2 取。原因是即使设了固定码率，实际发出的数据量仍有波动，画面剧烈变化时会冲高；而上行带宽被占满的那一瞬间，就是丢帧的开始。
所以一路 1080p/30fps 的直播，上行要留 8 到 12 Mbps，而不是 6。
多平台同推要翻倍。 在本机同时推两个平台，上行就是两份。用云端转推服务的话本机只推一路，云端做分发，这时候本机的上行需求不变——这是双平台同推最省带宽的做法，代价是多一跳延迟。
多机位或多账号同时开播，上行是加总的。 三个直播间同时推 1080p，上行需求就是三十多兆，而且这三十多兆必须是持续稳定的，不是峰值能跑到就行。
上行带宽最容易被谁抢走
按抢占能力排序：
素材库和网盘的后台同步。这类工具的设计目标就是把可用带宽吃满，不限速的话它会毫不客气地占掉全部上行。
系统更新和软件自动更新。发生时间不可控，经常正好在开播时。
其他人的上传。同一个办公室里有人在传视频素材，直播的上行就被分走。
视频会议。双向占用，而且是刚性的。
这四项里，只有第一项能通过限速根治，其余三项要靠时间管理和优先级设置。
一个反直觉的点：自动切换对直播是有害的
多链路自动切换在大部分业务场景里是好事，但直播是例外。
切换发生的那一刻，正在进行的长连接必然中断，推流软件要重新握手。观众看到的就是第三种症状——直播中断了。哪怕新链路质量更好，这次中断已经发生。
所以直播场景要的不是“能自动切”，是“主链路本身足够稳”。备用链路应该是人工介入的兜底手段，不是自动生效的机制。
如果你的方案供应商强调自动切换有多快，直播这个场景要单独跟他确认：切换时正在进行的长连接会不会断。
开播前的六项检查
在开播时段测上行实际速率。 不是看套餐标称值，也不是半夜测。周三晚上八点的实际上行才是你能用的上行。
连续 ping 推流服务器域名五分钟。 记下丢包率和延迟波动区间。丢包超过百分之二，或者延迟从稳定值动不动跳高两三倍，第二种症状迟早发生。
确认路由器的上行限速设置。 有些设备默认对上行做限制，也有些被人为设过一次就忘了。同时确认有没有给推流设备设优先级。
停掉素材同步和自动更新。 开播前十分钟做这件事，比事后排查一小时有效。
用有线。 无线的抖动比有线大一个量级，而且受同频干扰影响，这个变量在直播时不值得留着。
确认 IP 是否固定。 如果链路的 IP 会变，长连接就有被打断的可能。固定 IP 在直播场景的价值不在于“更快”，在于连接的连续性。
落到方案上
按上面的算法，一个日常一路 1080p 直播的团队，上行专门留 8 到 12 Mbps；三路同时开播的，留三十多兆并且要保证是持续可用而不是峰值。
再加上前面说的两条：这条链路的 IP 要固定，而且不应该配置成质量劣化时自动切换。这两点对直播比带宽数字更重要。
跨境传输部分由中国电信等合规运营商提供，万联持有《增值电信业务许可证》，可签合同、可开发票、可电信直签。
具体怎么配，取决于三个数：同时开播几路、每路什么规格、以及这条链路上还有没有别的业务在跑。这三个数确认了才谈得上选方案。
开播前记下两个数
开播前测一次上行实际速率，开播后记一次是三种症状里的哪一种。
这两个数攒上一周，你就知道问题到底在哪一层，也知道该不该花钱、花在哪。在没有这两个数之前，任何人给你的建议都是猜的，包括我这篇。