多平台同时直播看起来是一件很简单的事：两个平台，两个推流地址，填进 OBS 不就行了？
但真正做过跨境同播的主播和团队都知道，麻烦往往不出在配置界面上，而是出在：
- 上行带宽根本不够
- 两路推流共用一个出口，一个平台掉帧另一个也跟着抖
- Restream 的中转节点到 TikTok 的路径不稳定
- YouTube 推流端口被封了但 TikTok 正常，分不清是哪段链路出问题
这篇文章拆解多平台同播在带宽、软件配置和推流链路上的真实挑战，以及跨境场景下哪些方案实际可用。
先搞清楚同播的两种模式
"多平台同播"在技术实现上有两种完全不同的方式，搞清楚这个前提，后面的配置才不会选错路。
模式一：本地多路输出
OBS 同时向多个平台推送独立的 RTMP 流。
- 每路推流各自建立一条 TCP 连接
- 每路推流消耗独立的上行带宽
- 任何一路断流不影响另一路（网络层面互相独立）
OBS 30.0 之后原生支持多路输出，不需要插件。
优点：简单、可控、链路独立。
缺点：上行带宽需求是两路之和；每条链路质量需要单独保证。
模式二：推流中转聚合
OBS 只推一路流到中间节点（如 Restream、自建分发服务器），由中间节点再分发到多个平台。
- 本地只需要一路推流带宽
- 中间节点负责分发
- 中间节点的连接质量决定最终到各平台的稳定性
优点：本地带宽压力小；配置简单。
缺点：多了一个故障点；节点到目标平台的路径质量你无法控制；跨境场景下延迟可能更高。
两种模式没有绝对优劣，选择取决于你的上行带宽状况和对链路控制需求的高低。如果上行充足，本地多路通常更稳；如果上行紧张，中转聚合更合适，但需要仔细选择中间节点的位置和质量。
带宽计算：多少上行才够用？
这是多平台同播最容易被忽略的前提。
假设：
- TikTok 推流码率：6 Mbps（1080p30，电商直播常用）
- YouTube 推流码率：8 Mbps（1080p30，YouTube 推荐范围）
两路合计：14 Mbps。
但 14 Mbps 只是理论最小值，实际直播还需要留余量：
| 消耗来源 | 估算占用 |
|---|---|
| TikTok 推流码率 | 6 Mbps |
| YouTube 推流码率 | 8 Mbps |
| 音频码率（两路） | 0.5 Mbps |
| 系统后台、云盘、更新 | 1~2 Mbps |
| 链路抖动缓冲余量 | 2~3 Mbps |
| 合计建议稳定上行 | ≥ 18 Mbps |
注意：这里说的是稳定上行，不是测速看到的峰值。
跨境推流在晚高峰时段，稳定上行可能只有测速峰值的 50%~70%。如果你的宽带测速是 30 Mbps 上行，不代表直播时能稳定跑 30 Mbps。
实测方式：用 iperf3 或 speedtest-cli 在正式开播的时间段（而不是下午两点）连续测 5~10 分钟，观察稳定值，而不是峰值。
# 连续测试上行，每次 10 秒，共测 6 次（覆盖 1 分钟窗口）
for i in {1..6}; do speedtest --no-download; sleep 10; done
如果稳定上行低于你的两路推流码率之和，就先不要做同播，或者先降低其中一路的码率。
OBS 配置：原生多路输出
OBS 30.0 之后原生支持多路输出（Multitrack Video），配置方法如下。
第一步：确认 OBS 版本
打开 OBS → 帮助 → 关于，确认版本号 ≥ 30.0。
如果版本较低，建议先升级。
第二步：开启多路输出
设置 → 推流 → 找到"启用多路输出"或"Multitrack"选项（各版本界面有差异）
部分版本的路径是：设置 → 推流 → 服务选择"自定义" → 在高级设置中找到多输出选项。
如果当前版本没有原生支持，也可以使用第三方插件：
obs-multi-rtmp：一个常见的 OBS 多路推流插件，支持添加多个推流目标
第三步：配置两个平台的推流地址
对于 TikTok：
- 进入 TikTok 直播伴侣或后台获取推流地址和推流码
- 服务器地址示例：
rtmp://push-rtmp.tiktokv.com/live/ - 密钥：从直播设置中复制
对于 YouTube：
- 进入 YouTube Studio → 直播 → 串流密钥
- 服务器地址：
rtmp://a.rtmp.youtube.com/live2 - 密钥：从直播设置中复制
把两组配置分别填入 OBS 的两个输出目标。
第四步：分别设置码率
两个输出可以使用不同的码率配置：
- TikTok：按平台实际需求设置
- YouTube：按 YouTube 推荐参数设置
不建议两路都使用同一套最高码率，尤其是上行带宽有限的情况下。
推流链路：跨境场景下最关键的一环
配置好 OBS 只是开始，跨境同播最容易出问题的是推流链路——也就是从你这里到 TikTok 和 YouTube 服务器之间的路径。
跨境推流面临的挑战：
- 物理距离长：从国内推到美国、欧洲的服务器，链路延迟本身就高
- 晚高峰拥堵：共享出口带宽在晚间容易拥堵，抖动和丢包上升
- 路由不稳定：公网路由可能绕行第三方节点，增加延迟
- 平台接入点差异：TikTok 和 YouTube 的 RTMP 入口在地理位置和网络质量上不同
如果你直接从本地网络向两个平台同时推流，任何一段路径的波动都会影响对应平台的直播质量。
推荐做法：每个平台独立的固定推流入口
最稳的跨境同播方式：
本地 OBS → [TikTok 专属推流入口] → TikTok 服务器
本地 OBS → [YouTube 专属推流入口] → YouTube 服务器
通过端口转发，为每个平台建立一个固定入口：
- 固定入口使用优质跨境线路（CN2 GIA、BGP 等）
- 每个平台用独立的入口 IP 和端口
- 两路链路互相独立，任何一路出问题不影响另一路
这样做的好处：
- 链路独立：TikTok 掉帧不会带动 YouTube 也出问题
- 路径可控：入口到目标平台的路径走优质线路，不走公网拥堵的普通路由
- 故障可定位：两路分开，出问题更容易判断是哪一侧的问题
配置示例
假设你在 WarpTok 创建了两个服务：
服务 A（给 TikTok）
- 入口 IP：
203.x.x.1 - 入口端口：
11935 - 转发目标：TikTok 推流服务器 IP（通过
ping推流域名获取）+ 端口 1935
服务 B（给 YouTube）
- 入口 IP：
203.x.x.2 - 入口端口：
12935 - 转发目标：YouTube 推流服务器 IP + 端口 1935
在 OBS 的两个输出目标中分别填写：
# TikTok 输出
服务器：rtmp://203.x.x.1:11935/live/
密钥：[TikTok 推流码]
# YouTube 输出
服务器：rtmp://203.x.x.2:12935/live2
密钥：[YouTube 推流码]
注意：路径部分（/live/、/live2）来自平台原始推流地址，不能省略。
关于 Restream 的判断
Restream 和类似的聚合转发服务适合：
- 上行带宽有限（只有一路带宽余量）
- 对各平台延迟差异不敏感
- 主要内容是娱乐直播而非电商促单
跨境电商场景下，Restream 的局限性：
- Restream 服务器在海外，从国内推到 Restream 的第一跳链路质量你无法控制
- Restream 到 TikTok / YouTube 的链路质量也不透明
- 出了问题更难定位是哪段的问题
如果你已经有稳定的跨境推流入口，本地多路通常比借助 Restream 中转更可控，延迟也更低。
如果你必须用 Restream（上行真的不够），建议测试 Restream 服务器到你当前网络环境的延迟和稳定性，选最近的节点。
常见失败模式
失败模式一：只测了总带宽，没测稳定性
两路推流合计 14 Mbps，宽带上行测速 30 Mbps，看起来没问题。
但实际直播时，晚高峰稳定上行只有 15 Mbps，余量不足，两路推流都开始掉帧。
解法：在正式直播的时间段做稳定性测试，而不是只看峰值。
失败模式二：两路推流共用同一个出口 IP
共用一个入口时，入口节点的任何问题都会同时影响两路推流。
解法：为每个平台建立独立的推流入口，链路互相隔离。
失败模式三：调试时用日间网络，正式直播是晚上
日间网络质量通常好于晚间。用日间测试的结果来估算晚间直播能力，容易高估。
解法：在接近正式直播的时间段做 10~15 分钟压测。
失败模式四：两路推流用了同样的码率
如果你给 TikTok 和 YouTube 都设置了 8 Mbps，但实际上行只能稳定提供 14 Mbps，两路都会在边界上抖动。
解法：总推流码率不要超过稳定上行的 70%，并给两路分别设置合理的目标码率。
失败模式五：出了问题不知道是哪路
两路推流同时出问题，但不知道是 TikTok 那边还是 YouTube 那边，也不知道是本地还是链路。
解法：两路使用独立入口，分别监控 OBS 掉帧数据，出问题时可以单独关闭一路排查。
开播前检查清单（多平台版）
在通用开播前检查清单的基础上，多平台同播需要额外确认：
- 每个平台的推流地址和密钥是否正确
- 每路推流入口是否独立可用
- 上行带宽是否能稳定承载两路推流的总码率
- OBS 多路输出是否都处于启用状态
- 测试时两路直播间是否都能收到正常画面
- 每路推流单独关闭时，另一路是否不受影响
- 应急预案中是否包含"关闭某一路保另一路"的操作步骤
总结
TikTok 和 YouTube 同时开播在技术上不复杂，但稳定地做到需要解决几个实际问题：
- 带宽充足：稳定上行至少是两路码率之和的 130%
- 链路独立：每个平台配独立的推流入口，互不干扰
- 在正确的时间段测试：不要用日间测试估算晚高峰能力
- 可以快速定位问题：出问题时知道是哪一路、哪一段
如果这几点都能保证，多平台同播才能真正稳定，而不是靠运气。
