TikTok 直播推流中继实战：用 Nginx-RTMP/SRS 自建低延迟中转节点（2026）

2026-08-16 · DevCraft Studio

手把手教你在新加坡、香港或印尼 VPS 上用 Nginx-RTMP 或 SRS 搭建 RTMP/SRT 推流中转节点，配合 BBR 拥塞控制与 CN2 GIA/AS9929 优化线路，降低跨境直播卡顿并提升推流稳定性。

延伸阅读

更多相关攻略推荐：【IP 地址 02】喊了二十年“狼来了”，为什么 IPv6 依然无法、【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、【PaaS自托管 01】2026 避坑实测：Dokploy 轻量自托、2026 TikTok Shop 多店防关联架构实测：IP 隔离 +。

为什么 TikTok 跨境直播需要自建推流中转

做 TikTok 出海直播的团队几乎都会遇到同一个问题：主播人在国内，网络到 TikTok 服务器（美区、东南亚、欧洲）的链路又长又抖。直接把 OBS 推到 TikTok，晚高峰一堵就卡成 PPT，观众掉线、推荐流量跟着掉。这不是你电脑配置不行，而是跨境公网链路本身质量不可控。

自建推流中转的核心思路是：主播先把流推到你自己的海外节点（新加坡 / 香港 / 印尼），再由这台 VPS 把流稳定地 relay（中转）到 TikTok。第一段（国内到海外优化节点）走的是你精心挑选的优化线路（CN2 GIA / AS9929），第二段（海外节点到 TikTok）在海外本地网络里，质量天然就好。把"最难的那一跳"交给专业优化的线路，整体卡顿率能压下来一大截。

根据多家 VPS 评测与行业调研，使用稳定海外原生 IP 的账号，其直播平均观看时长比频繁切换 IP 的账号高出约 37%，直播间推荐流量获取率高出约 58%。而超过 80% 的封禁案例源于 IP 频繁变动或使用了被标记的数据中心黑名单 IP，而不是 VPS 本身的问题。所以"中转 + 静态原生 IP"是出海直播团队最务实的组合。

节点选哪里：新加坡 / 香港 / 印尼

中转节点的物理位置直接决定第一段链路的延迟。给 TikTok 这类业务挑节点，原则是"离你的主播近、离目标市场近、离优化线路近"。

  • 新加坡：覆盖东南亚和澳洲市场最稳，到国内延迟可低至 65–80ms，是很多跨境卖家的首选。RakSmart 等商的精品 CN2 新加坡节点到国内平均延迟约 80ms，50M 带宽可跑满，三网往返直连。
  • 香港：离华南最近，CN2 GIA 线路内地稳定 25–40ms，华南 10–20ms，晚高峰波动 ≤5ms，丢包率 ≤0.3%。如果你主播在广东一带，香港是延迟最低的选择。
  • 印尼（雅加达）：面向印尼本地 TikTok 市场，原生 IP 解锁最好。缺点是到国内延迟偏高（150ms 以上），更适合"节点就在目标市场附近"的出海形态，而非作为国内主播的中转跳板。

实战建议：主播在国内的团队，优先新加坡或香港；做印尼本地化直播、主播也在印尼的，直接用印尼节点。无论选哪个，一定要确认线路是 CN2 GIA 或 AS9929 这类精品优化线路，而不是普通国际线路。

方案一：用 Nginx-RTMP 部署推流中继

Nginx-RTMP 是最轻量的方案，纯流量转发（passthrough，不重新编码）几乎不占 CPU，1 核 1G 的 VPS 就能把一路 6Mbps 的流同时 relay 到多个目标。适合预算紧、只想"稳稳地转一下"的团队。

在 Ubuntu/Debian 上安装。现代发行版可以直接装预编译模块，省去编译：

sudo apt update
sudo apt install -y libpcre3-dev libssl-dev zlib1g-dev ffmpeg
sudo apt install -y nginx libnginx-mod-rtmp

编辑 /etc/nginx/nginx.conf，在 http {} 块之外添加 rtmp 块。下面是一段可直接用的中转配置：主播推流到 rtmp://relay-ip/live/你的key，VPS 自动把它 relay 到 TikTok 的 RTMP 入口。

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # 中继到 TikTok 的 RTMP 入口（URL 与 stream key 以 TikTok 后台为准）
            push rtmp://rtmp.tiktok.live/push/你的TIKTOK_KEY;
            push_reconnect 2s;

            # 如需同时备份一路到另一台中转/平台，可再加 push
            # push rtmp://备用节点/live/key;
        }
    }
}

改完重启：sudo systemctl restart nginx。然后在 OBS 的推流设置里选"自定义"，服务器填 rtmp://你的VPS IP/live，串流密钥填你自定义的 key 即可。Nginx-RTMP 还支持 on_publish 鉴权（防别人盗推）、push_reconnect 断线自动重连、以及 /stat 状态页监控在线流和码率。

优点：轻、稳、资料多。缺点：原生不支持 SRT、WebRTC，低延迟能力有限。如果你只要 RTMP→RTMP 的稳定中转，它完全够用。

方案二：用 SRS 做 RTMP/SRT 中继（跨境更抗抖）

SRS（Simple Realtime Server）是专为直播设计的开源服务器，支持 RTMP、SRT、WebRTC、HLS。相比 Nginx-RTMP，它最大的优势是支持 SRT 协议——SRT 基于 UDP，自带 ARQ 重传和前向纠错，在丢包、高抖动的跨境公网上比 TCP 上的 RTMP 稳得多。这就是为什么很多跨境直播架构把"国内到中转"这一段改成 SRT。

编译并安装 SRS（带 SRT 支持需要 --srt=on）：

sudo yum install -y gcc gcc-c++ make openssl-devel zlib-devel
git clone https://github.com/ossrs/srs.git /opt/srs
cd /opt/srs/trunk
./configure --srt=on && make -j$(nproc) && make install

下面是一个精简的中继配置：RTMP（1935）和 SRT（10080）都能接入，并把 GOP 缓存和队列按低延迟场景调小，最后把流 relay 到 TikTok。

listen 1935;
max_connections 20000;
daemon on;
srs_log_tank file;
srs_log_file /var/log/srs.log;

vhost __defaultVhost__ {
    # SRT 接入：跨境抗抖更稳
    srt_server {
        enabled on;
        listen 10080;
        latency 120;
        peerlatency 60;
        maxbw 20000000;
        passphrase your_srt_psk;
        pbkeylen 16;
    }

    # 低延迟参数
    gop_cache on;
    queue_length 30;
    tcp_nodelay on;
    min_latency on;

    # 转封装为 HLS（可选，便于网页观看）
    hls {
        enabled on;
        hls_fragment 2;
        hls_window 8;
        hls_path /data/hls;
    }

    # 把流中继/转发到 TikTok
    forward {
        enabled on;
        destination rtmp://rtmp.tiktok.live/push/你的TIKTOK_KEY;
    }
}

经验值：SRT 的 latency 不要设太小，跨境场景落在 80–120ms 比较稳（实际端到端延迟约为 latency 的两倍）。主播端用 OBS 的 SRT 输出，或 ffmpeg 推送：

ffmpeg -re -i source.flv -c copy -f mpegts \
  "srt://你的VPS:10080?streamid=#!::r=live/livestream,m=publish"

SRS 的 min_latency on 开启后"接收即转发"，配合 tcp_nodelay on 关闭 Nagle 算法，端到端延迟可压到 100–500ms 量级（局域网实测更低，公网会受链路影响略高）。

开启 BBR 拥塞控制，进一步降低延迟

无论用 Nginx-RTMP 还是 SRS，VPS 的 TCP 栈都值得调一下。默认的 CUBIC 是"丢包型"算法——要等队列塞满才降速，容易产生缓冲区膨胀（bufferbloat），在跨境长肥管道上延迟和抖动都会被放大。BBR 是 Google 提出的"测量型"算法，它直接估计瓶颈带宽和最小 RTT，主动配速到理想工作点，对长肥网络（高带宽 × 高延迟）收益最明显。

现代内核（4.9+，绝大多数 2026 年镜像都自带）直接启用即可。先确认可用：

sysctl net.ipv4.tcp_available_congestion_control

输出包含 bbr 就行。永久启用（写入 sysctl 配置，重启仍生效）：

cat >> /etc/sysctl.d/99-bbr.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system

BBR 依赖精确的封包配速（pacing），所以 务必把队列规则设为 fq（Fair Queue），否则效果打折。验证是否生效：

sysctl net.ipv4.tcp_congestion_control
# 期望输出：net.ipv4.tcp_congestion_control = bbr
sysctl net.core.default_qdisc
# 期望输出：net.core.default_qdisc = fq

顺手再补几个通用优化（同样写进 99-bbr.conf）：net.ipv4.tcp_window_scaling = 1、net.ipv4.tcp_fin_timeout = 30、net.ipv4.tcp_keepalive_time = 1200、net.ipv4.ip_local_port_range = 1024 65535。大内存机器还可把 rmem_max/wmem_max 提到 64MB–256MB。注意：BBR 与同链路上的 CUBIC 流量共享瓶颈时可能抢占较多带宽，是否启用请结合实际链路评估。

为什么线路比带宽更重要：CN2 GIA 与 AS9929

选 VPS 最常踩的坑是只看带宽数字。但跨境场景里，线路等级远比带宽数字重要——带宽决定"水管多粗"，线路决定"水流走的路径多顺畅"。一条 50Mbps 的 CN2 GIA 在晚高峰能吊打 1Gbps 的普通国际线路。

主流优化线路：

  • CN2 GIA（电信 AS4809）：全程双向优化专线，去程回程都走 59.43 开头的 CN2 高速节点，延迟低、抖动小、几乎不拥堵。香港节点内地稳定 25–40ms，美国节点国内平均约 160–180ms。适合电信宽带用户、对实时性要求高的直播。
  • AS9929（联通 A 网）：联通高端企业级线路，对标 CN2 GIA。晚高峰几乎不拥堵，北美方向延迟可长期稳定在 150–170ms，丢包率基本在 0.5% 以下。联通用户为主时首选，性价比高。
  • CMI（移动国际直连）：移动用户延迟 35–55ms，移动用户首选。
  • CN2 GT：仅入境走 CN2，出境仍走 163 骨干，晚高峰可能小幅波动，适合预算有限的业务。

怎么验证线路？用 traceroute 看路由节点的 AS 编号：全程 AS4809/59.43 是 CN2 GIA，全程 AS9929 是联通精品；如果一路是 AS4837 或绕到欧美再回来，那就是普通线路，晚高峰必卡。实测数据显示，CN2 GIA 等精品线路晚高峰丢包率控制在 0.5% 以下、带宽达标率高达 98.7%，而普通线路晚高峰丢包率高达 5%–15%。对于直播这种实时业务，这个差距就是"流畅"和"卡成 PPT"的区别。

静态原生 IP 对推流稳定性的作用

TikTok 的风控核心看三件事：IP 纯净度、原生性、地域一致性。数据中心 IP（尤其某些被滥用的机房段）容易被识别并限流；而静态原生 IP（IP 归属地与 ASN 真实匹配、非广播段）权重更高、被风控的概率更低。

"静态"意味着 IP 长期不变。TikTok 算法对账号登录环境敏感，频繁切换 IP 极易触发风控。行业调研显示，83% 的直播封禁案例源于 IP 频繁变动或使用数据中心黑名单 IP。所以出海团队应该做到：每台直播机用固定静态原生 IP、避免多账号共用同一 IP、每次换设备后用 App 完成二次验证与人脸识别以巩固信任。

同时，原生 IP 的"地域一致"还能帮助你解锁目标市场的 TikTok（例如新加坡原生 IP 解锁东南亚 TikTok，印尼原生 IP 解锁印尼区）。像 LisaHost 的韩国双 ISP 住宅静态 IP、RakSmart 的新加坡原生 IP，都是针对这类场景推出的。挑 VPS 时把"是否提供静态原生 IP"和"是否精品线路"列为同等重要的硬指标。

一条完整的中转链路示例

把上面所有环节串起来，一条典型的出海直播链路长这样：

  • 主播在国内，OBS 通过 SRT（或 RTMP）把流推到新加坡/香港的中转 VPS（CN2 GIA / AS9929 线路 + 静态原生 IP）。
  • 中转 VPS 上跑 SRS 或 Nginx-RTMP，开启 BBR，把流低延迟地 push/forward 到 TikTok 的 RTMP 入口。
  • TikTok 侧拿到稳定的流，观众看到的是流畅直播；主播端到 TikTok 的整体延迟被控制在可接受范围，晚高峰也不容易崩。

运维要点：给 1935/10080 端口加监控（cron 定时探测），断流自动重启服务；用 SRS 的 /stat 或 Nginx-RTMP 的 /stat 页面看实时码率和在线数；推流加 on_publish 鉴权防盗推；中转节点和 TikTok 间可再备一路中继做冗余。对于只做转发的场景，1 核 1G 足够；若要 SRS 顺带转码出多码率，建议 4 核 8G 起步。

延伸阅读：想深入了解线路类型可看 什么是 CN2 GIA，挑节点参考 各地区 VPS 延迟对比，原生 IP 价值见 原生 IP 与流媒体解锁，跨境出海整体方案见 2026 跨境电商 VPS 指南。