直播视频推流节点怎么选，从协议和观众分布判断

直播视频推流用什么节点，取决于两件事：主播把画面推到哪里，观众从哪里拉流。
推流端（主播侧）要的是离自己近、上行稳定的入口节点；
分发端（观众侧）要的是覆盖观众所在地的边缘节点。
新手最稳妥的做法是先用服务商默认的就近接入节点，等出现卡顿、花屏或延迟偏高时，再按下面几个条件逐项排查和调整。

先分清推流节点和分发节点

很多人把“推流节点”和“CDN 节点”混在一起，其实它们承担的任务不同：

• 推流入口节点：主播的编码软件（OBS、ffmpeg 等）通过 RTMP 或 SRT 把视频流推到这里。它看重的是上行带宽、网络抖动和到主播的物理距离。
• 分发边缘节点：观众通过 HLS、HTTP-FLV 或 WebRTC 从最近的边缘节点拉流。它看重的是覆盖范围、并发能力和回源链路。

选错类型的节点，常见表现是：推流地址填了分发域名，OBS 一直重连；
或者推流正常但观众端频繁缓冲。
所以第一步不是找“最好的节点”，而是确认你手里这条地址是推流地址还是播放地址。

按协议决定节点类型

不同推流协议对节点的要求不一样，先看你在用哪一种：

• RTMP：最常用的推流协议，延迟通常在几秒。推流地址一般形如 rtmp://push.example.com/live/streamkey，其中 push 域名对应的就是推流入口节点。RTMP 基于 TCP，对丢包相对不敏感，但对上行带宽和 RTT 敏感。
• SRT：适合弱网或跨地域推流，抗丢包能力比 RTMP 强，需要服务端支持 SRT 监听端口。如果主播网络质量差，可以优先考虑支持 SRT 的节点。
• WebRTC：超低延迟场景使用，对节点位置和网络质量要求最高，一般由云服务商的实时音视频产品提供，不适合自己随便指定节点。

如果你只是用 OBS 推流到直播平台或自建 SRS、Nginx-rtmp，绝大多数情况选 RTMP 入口节点即可。

判断节点好坏的三个实测指标

不要只看服务商页面写的“全球节点”，实际影响体验的是下面三项：

1. 到推流节点的 RTT 和丢包：在主播电脑上执行 ping push.example.com，观察平均延迟和丢包率。延迟长期高于 100ms 或丢包超过 1%，推流就容易出现花屏和断流。
2. 上行带宽是否够用：直播码率乘以 1.5 左右是安全上行需求。例如 4Mbps 码率，上行至少要有 6Mbps 稳定带宽。可以用测速工具在推流时段实测，不要用空闲时段的数据。
3. 节点是否就近接入：服务商通常按地域提供多个推流域名。主播在华南就选华南入口，在华北就选华北入口，跨运营商时优先选支持多线 BGP 的节点。

这三项里，丢包和上行带宽比节点数量更重要。
一个离主播近、上行稳定的单节点，往往比一个“全球覆盖”但绕路的节点体验更好。

配置示例：OBS 与 ffmpeg 怎么填节点地址

以 RTMP 推流为例，服务商一般会给你两段信息：推流地址和串流密钥。
在 OBS 的“设置 → 直播 → 服务”中选择“自定义”，然后填写：

• 服务器：rtmp://push.example.com/live
• 串流密钥：你的推流密钥

如果是用 ffmpeg 推本地文件或摄像头，命令大致如下：

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k \
  -c:a aac -b:a 128k -f flv rtmp://push.example.com/live/streamkey

把 push.example.com 换成服务商实际提供的推流域名即可。
注意推流地址和播放地址通常不是同一个域名，播放地址形如 https://play.example.com/live/streamkey.m3u8，不要混用。

自建场景下，如果使用 SRS，推流入口就是 SRS 服务器监听的 1935 端口；
如果前面套了 Nginx，要确认 nginx.conf 里 RTMP 的 server 块和 application live 配置正确，并且安全组放行了对应端口。

常见卡顿的排查顺序

推流节点选好后仍然卡顿，按下面顺序排查，不要一上来就换节点：

• 先看推流端日志：OBS 底部状态栏会显示丢帧率和码率。丢帧率高说明上行不足或网络抖动，优先检查主播本地网络。
• 再测到节点的网络质量：用 ping 和 mtr 观察是否在某一跳开始丢包。如果是运营商出口问题，换同城另一个入口节点可能有效。
• 最后看观众侧：如果推流端正常，但观众缓冲多，问题更可能在分发边缘节点或回源链路，这时应调整 CDN 播放域名，而不是推流地址。

一个容易忽略的点是：推流节点不是越近越好，还要看该节点是否拥塞。
晚高峰时段可以对比两个入口节点的 RTT 和丢包，选当前更稳定的那个。

验证节点是否生效

调整节点后，不要只看“能推上去”就结束，至少验证三件事：

• 推流持续 10 分钟以上，OBS 丢帧率保持在较低水平，没有自动重连。
• 用播放器打开播放地址，观察首帧时间和缓冲次数，确认观众侧正常。
• 如果是跨地域业务，让不同地区的同事或朋友各拉一次流，确认边缘节点覆盖符合预期。

直播推流节点的选择没有一劳永逸的答案：主播位置、观众分布和网络时段都会影响结果。
先按协议选对节点类型，再用 RTT、丢包和上行带宽三项指标实测，最后用推流日志和播放效果交叉验证，基本就能避开大部分“推流卡顿”的坑。