直播带货多平台开播：推流中转要多大上行带宽才够？
问题场景：多平台同时开播，为什么画面总卡？
做跨境电商直播的团队常遇到一种情况：TikTok Shop 播着，独立站同步推流，Shopee 也挂着，结果观众端频繁缓冲，主播口型和声音对不上。排查一圈发现，主播本地网络的上行带宽被吃满了——一路 1080p 直播推流通常需要 6~10Mbps 稳定上行，三路同时推就是 20~30Mbps，很多办公室宽带上行只有 30~50Mbps，再叠加其他办公流量，必然卡顿。
更麻烦的是跨境链路。从国内推流到海外平台，如果走普通国际带宽，晚高峰丢包和抖动会直接反映在直播画面上。这时候需要一台推流中转服务器：主播把流推到中转机，中转机再分发到各平台，既分摊了本地上行压力，也能借中转机所在地区的优质线路改善跨境质量。
三种中转方案横评：云直播、SRS 自建、大带宽物理机
方案一：云厂商直播服务。按流量或带宽计费，开通快，全球节点多，适合刚起步、场次不固定的团队。缺点是长期高频开播成本高，多平台转推往往要额外配置，且数据经过第三方，对内容合规要求高的品类需要评估。
方案二：自建 SRS 中转。在服务器上部署开源流媒体服务，主播推一路 RTMP 到服务器，服务器再转推多个平台。灵活、可控、成本固定，适合每天开播、需要自定义水印或录制回放的团队。门槛在于需要有人懂基础运维，配置一次即可长期使用。
方案三：大带宽物理机 + 推流软件。直接租用带 G 口或大带宽的物理服务器，配合 OBS 多路推流或中转软件。带宽独享、性能稳定，适合多机位、多平台、高码率场景。缺点是需要自行维护系统，价格比云直播按量付费的起步成本高。
对多数外贸企业来说，如果每天固定开播 2 场以上、平台超过 2 个，方案二或方案三的长期成本更可控。关键变量是上行带宽和线路质量。
配置怎么估：上行带宽、CPU 与地区选择
先算带宽。一路 1080p30 推流按 6Mbps 保守估算，转推到 3 个平台就是 18Mbps 上行，加上 20% 余量，中转机至少需要 25Mbps 独享上行。如果做 1080p60 或更高码率，单路按 10Mbps 算，三平台就需要 35Mbps 以上。注意很多标称“大带宽”的机器是共享或国际带宽，晚高峰会缩水，选购时要确认是否独享、是否 CN2 或优质 BGP。
CPU 方面，纯转推不转码时，4 核以上通常够用；如果要转码（比如统一分辨率再分发），按每路 1080p 转码约 2~4 核估算，多路就要 8 核以上。内存 16G 起步，做录制或 RAG 知识库辅助客服时建议 32G 以上。
地区选择看观众在哪。面向东南亚观众，香港、新加坡、马来西亚节点延迟低；面向北美，洛杉矶、西雅图更合适；面向日韩，东京节点有优势。香港节点对国内主播推流也友好，是常见的折中选择。
卡顿排查步骤：从主播端到平台端逐段定位
- 测主播端上行：开播前用测速工具测上行，确认稳定值大于“路数 × 单路码率 × 1.2”。
- 看中转机负载：登录服务器查看 CPU、内存、网络出口是否跑满，带宽打满是最常见的卡顿原因。
- 分段测延迟：从主播 ping 中转机，再从中转机 ping 平台推流地址，定位是本地到中转还是中转出海这一段差。
- 检查丢包与抖动：跨境线路晚高峰丢包超过 1%~2% 就会明显卡顿，考虑换 CN2 或优化线路。
- 降码率验证：临时把码率降到 4Mbps，如果卡顿消失，基本确认是带宽不足。
避坑要点：不要用普通云服务器的小带宽实例做多平台中转；不要忽略平台对推流码率和 key 的限制；不要把所有平台放在同一路推流里硬扛，合理分配码率更稳。
选购推荐：按场景匹配机型
如果主营东南亚市场、需要兼顾国内推流，香港节点是优先项。香港大带宽服务器 IX 提供 30M 带宽，Platinum-8168*2 / 64G / 1T NVME 的配置，298.5 元/月，跑 2~3 路 1080p 转推足够，适合刚起步的多平台开播团队。
如果观众主要在北美，或需要更大带宽余量做多机位、高码率直播，美国洛杉矶大带宽服务器 XXII 是 G 口带宽，Gold-6133*2 / 64G / 1T NVME，763.5 元/月，上行充裕，转推多平台不易成为瓶颈，也方便后续加录制和转码。
决策建议
先算清“平台数 × 单路码率”得出上行需求，再按观众地区选节点：东南亚选香港或马来西亚，北美选洛杉矶或西雅图，日韩选东京。预算有限、场次不多可先用云直播服务；每天固定开播、平台超过两个，自建 SRS 加大带宽物理机的长期成本更低、可控性更强。卡顿先查带宽是否跑满，再查跨境线路丢包，多数问题出在这两处。