中國戶外直播指南

適用場景:從中國大陸戶外直播,透過多張 SIM 卡頻寬合併(Bonding)+ OpenMPTCProuter + VLESS+Reality/Hysteria2 繞過 GFW,將 LiveU Solo 的 RTMP Direct 流量安全傳輸回台灣,再由 OBS 推流至 Twitch。

系統目標與邊界

在開始硬體採購與軟體設定前,必須先明確這套系統的「定位」與「極限」。這是一套低成本、自架、長時間戶外直播的 contribution uplink 系統,而非廣播級商業解決方案。

本架構的目標

  • 中國戶外長時間直播(10-12 小時/場,5-7 天/月)
  • 避免從中國直推 Twitch(GFW 直接封鎖 RTMP)
  • 避免依賴 LiveU 日本 AWS 中轉(增加 hop、latency 與雲端費用)
  • 用多張 SIM 卡頻寬合併,降低單卡波動風險
  • 繞過中國 ISP 針對大流量上行的 QoS 干擾
  • 保留本地 OBS 的完整控制權(版面覆蓋、Alert、二次編碼)
  • 長時間穩定推流

本架構不是

  • 廣播級(broadcast-grade)超低延遲 contribution 系統
  • 具備封包層級 FEC(Forward Error Correction)的專業傳輸
  • LiveU 官方多鏈路系統的完整替代品
💡 核心定位:
低成本 DIY remote contribution uplink system。用架構層面的多路合併(MPTCP Bonding)與隧道防禦(VLESS+Reality / Hysteria2),彌補 RTMP 在嚴苛網路環境下的先天弱點。

選擇邏輯與決策矩陣

本文件的架構選擇分為兩個維度:中國端如何出境(繞過 GFW)台灣端如何接收串流。兩者獨立選擇,可自由組合。

中國端出境方案比較

以下三種方案決定的是:你的直播流量如何從中國穿越 GFW 送到台灣。

方案一:本地 SIM 卡 + VLESS+Reality(本文件主要涵蓋)

RPi5(本地 SIM × 3,MPTCP bonding)
  → VLESS+Reality+Vision tunnel 或 Hysteria2
  → 台灣 VPS 或本機 → OBS → Twitch
  • SIM 卡使用中國三大電信一般上網卡(非翻牆卡)
  • 穿越 GFW 靠 VLESS+Reality,偽裝 TLS 1.3,幾乎無特徵
  • 完全自架、自主掌控,VPS 費用為主要持續成本

方案二:翻牆 SIM 卡 + LiveU LRT JP Cloud

LiveU Solo(翻牆卡,bonding 由 LiveU 處理)
  → LiveU LRT → 日本 AWS
  → 台灣本機 OBS → Twitch
  • SIM 卡為商業翻牆卡(如電信貓、iRoaming 等),網路層已內建 GFW 繞過
  • LiveU LRT 為 LiveU 專有協議,穿透力強
  • 最省心,有商業團隊維護線路;缺點是費用高、繞日本 AWS 增加延遲(+80–150ms)

方案三:中國租屋固定寬頻 + Windows PC Xray

RPi5(本地 SIM × 3)
  → [中國國內網路,無 GFW] → 租屋 Windows PC
  → Xray VLESS+Reality(固定寬頻出境)
  → 台灣 VPS 或本機 → OBS → Twitch
  • RPi5 的 SIM 只走中國國內段(低延遲、穩定),GFW 穿越交給固定寬頻
  • 住宅 / 商業固定 IP 被 GFW 針對性封鎖的機率遠低於 VPS 機房 IP
  • 適合長期在中國固定地點直播;需要在中國有常駐據點與設備

三方案綜合比較

💡 費用說明:以下費用以 NTD 為單位,假設 LiveU Solo 硬體已持有。翻牆 SIM 費用依供應商與流量方案差異極大,租屋費用依中國城市差異極大,僅供參考。
項目 方案一:SIM + Reality 方案二:翻牆卡 + LRT 方案三:租屋 + Xray
GFW 穿透強度 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
穩定性 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
自主掌控 ✅ 完全自主 ❌ 依賴第三方 ✅ 完全自主
戶外直播 ⚠️ RPi5 需先連回租屋
IP 被封風險 ⚠️ VPS 機房 IP 低(商業維護) 極低(住宅 IP)
延遲 高(繞日本)
一次性費用(NTD) ~5,600–8,700 ~0 ~10,600–23,700
每月費用(NTD) ~1,400–4,000 ~4,500–9,500 ~8,000–21,650
一年總持有成本 ~22,400–56,700 ~54,000–114,000 ~106,600–283,500
推薦情境 偶爾赴中直播 不想自架 長期駐點直播

費用明細

  • 方案一 每月:HK/JP/TW VPS(CN2 GIA)~500–1,300 + 中國一般 SIM × 3 ~900–2,700
  • 方案一 一次性:RPi5 ~2,500 + USB Modem × 3 ~1,800–3,600 + Hub / 行動電源 / 散熱 ~1,300–2,600
  • 方案二 每月:翻牆卡 × 3(電信貓 / iRoaming 類)~3,000–8,000 + LiveU Connect ~1,500
  • 方案三 每月:中國租屋 ~6,750–18,000 + 固定寬頻 ~225–450 + 中國 SIM × 3 ~900–2,700 + 台灣 VPS ~165–500
  • 方案三 一次性:中國 Windows 迷你主機 ~5,000–15,000 + RPi5 + Modems + 周邊 ~5,600–8,700
⚠️ 注意:本文件後續的技術細節主要對應方案一。方案二無需額外設定;方案三的 Windows PC Xray 設定參考台灣端 xray 設定邏輯,反向套用於 client 端。

台灣端 ingest 路線選擇

本文件提供兩條台灣端架構路線,依你的實際網路條件選擇:

評估條件 路線 A:台灣本機 ingest 路線 B:VPS ingest
台灣家裡有真正公網 IPv4? 必須有 不需要
台灣 ISP 可做 Port Forwarding? 必須可以 不需要
擔心家裡網路成為單點故障? 是的話不適合 適合
每月持續費用 低(無 VPS 費用) 增加 VPS 費用
對台灣回程路由的掌控度 中(依 VPS 供應商)
設定複雜度 略低(不需 port forwarding)

如何判斷是否有真正的公網 IP

# 在台灣 Linux 機或路由器上執行
curl ifconfig.me

對照 Router WAN 介面的 IP,若兩者相同代表有真正公網 IP,路線 A 可行。若不同(或 WAN IP 是 100.64.x.x 開頭),代表處於 CGNAT,必須選路線 B 或向 ISP 申請固定 IP。

排列組合決策矩陣

若使用 LiveU + RPi5 架構,可組合以下元素:

組合 SIM 卡類型 中轉架構 出境方式 可行性 推薦度
1.1 + 2.1 三大電信一般卡 中國境內 VPS 直推台灣 無隧道 ❌ 不可行
1.1 + 2.2 三大電信一般卡 中國境內 VPS + Xray VLESS+Reality ⚠️ 理論可行 ⭐⭐
1.1 + 2.3 三大電信一般卡 直推海外 AWS 無隧道 ❌ 不可行
1.2 + 2.1 翻牆卡 中國境內 VPS 直推台灣 翻牆卡內建 ⚠️ 邏輯冗餘
1.2 + 2.2 翻牆卡 中國境內 VPS + Xray 雙重隧道 ❌ 架構錯誤
1.2 + 2.3 翻牆卡 直推海外 AWS 翻牆卡內建 ✅ 翻牆卡現況 ⭐⭐⭐
🎯 推薦 三大電信一般卡 台灣/海外 VPS + Reality VLESS+Reality ✅ 完全可行 ⭐⭐⭐⭐⭐
💡 關鍵結論:一般卡必須搭配「出境隧道」才能連境外;翻牆卡已內建出境能力,再加中轉層只會增加延遲。

不可行組合說明

  • 【1.1 + 2.1】一般卡 + 中國境內 VPS 直推台灣:從中國境內任何節點「直接」推流到台灣境外,都會被 GFW 識別並阻斷。即使中轉經過中國境內 VPS,最後一跳「中國→台灣」仍暴露在 GFW 下,且中國境內伺服器對外提供串流服務需 ICP 備案。
  • 【1.1 + 2.3】一般卡 + 直推海外 AWS:中國三大電信一般上網卡預設封鎖所有境外連線(除少數白名單),LiveU 的 RTMP Direct 直接嘗試連線 AWS 會被 GFW 靜默丟包。

理論可行但不推薦

【1.1 + 2.2】一般卡 + 中國境內 VPS + Xray 出境:技術上可行(一般卡走中國內網,出境隧道在中國 VPS 上),但需在中國有固定據點租屋,備案合規風險高,技術複雜度高,成本接近方案三。

決策流程

想換架構?
│
├─ 預算充足 + 完全不想碰技術?
│  └─ 維持翻牆卡 + LiveU LRT + 日本 AWS
│
├─ 願意花 2-4 小時自架 + 追求低成本?
│  └─ 推薦:一般卡 + 台灣/海外 VPS + Reality(本文件方案一)
│     ├─ 台灣家有公網 IP? → 選路線 A(本機 ingest,0 VPS 費用)
│     └─ 台灣是 CGNAT? → 選路線 B(租香港/日本/台灣 VPS,$15-40/月)
│
└─ 長期駐點中國(>6 個月)+ 有固定辦公室?
   └─ 可考慮中國租點 + Xray 出境(但需評估備案風險)

整體架構圖

路線 A:台灣本機 ingest

═══════════════════════ 中國現場 ═══════════════════════

  Sony FX30
     ↓ HDMI
  LiveU Solo(RTMP Direct 模式)
     ↓ WiFi / Ethernet(連接 RPi5 的 AP/LAN)
  Raspberry Pi 5
  ┌────────────────────────────────────────────┐
  │  OpenMPTCProuter v0.63                     │
  │  WAN1 → 中國電信 SIM → USB Modem A        │
  │  WAN2 → 中國聯通 SIM → USB Modem B        │
  │  WAN3 → 中國移動 SIM → USB Modem C        │
  │  MPTCP Bonding 頻寬聚合                    │
  │  VLESS+Reality 或 Hysteria2 隧道           │
  │  MSS Clamp + USB Autosuspend 關閉          │
  └────────────────────────────────────────────┘
     ↓ MPTCP + 加密隧道(TCP 443 或 UDP,偽裝 HTTPS/QUIC)
     ↓ GFW 只看到標準 TLS/QUIC 流量,順利放行

═══════════════════════ 台灣家裡 ════════════════════════

  Linux 本機(Ubuntu 22.04 / Debian 12)
  ┌────────────────────────────────────────────┐
  │  omr-server:Bonding 接收端                │
  │  xray:VLESS+Reality 解密                  │
  │  mediamtx:RTMP ingest + Auth             │
  │  CAKE QoS:防止 bufferbloat               │
  │  Netdata:即時鏈路觀測(建議安裝)         │
  └────────────────────────────────────────────┘
     ↓ RTMP 內網(含 auth)
  Windows 本機 或 Linux 筆電
  ┌────────────────────────────────────────────┐
  │  OBS Studio                                │
  │  Media Source + 場景覆蓋 + Alert           │
  └────────────────────────────────────────────┘
     ↓ RTMP
  Twitch

路線 B:VPS ingest

═══════════════════════ 中國現場 ═══════════════════════

  (與路線 A 相同:FX30 → LiveU → RPi5 + OMR + Reality)

═══════════════ 香港 / 日本 / 台灣 VPS ═══════════════

  Linux VPS(建議 CN2 GIA 優化線路,1 vCPU / 1GB RAM 即足)
  ┌────────────────────────────────────────────┐
  │  omr-server:Bonding 接收端                │
  │  xray:VLESS+Reality 解密                  │
  │  mediamtx:RTMP ingest + Auth             │
  └────────────────────────────────────────────┘
     ↓ RTMP(公網,有 Auth,建議 IP 白名單)
  台灣 Windows 本機 或 Linux 筆電
  ┌────────────────────────────────────────────┐
  │  OBS Studio                                │
  │  Media Source 拉取 VPS 上的 RTMP 串流      │
  └────────────────────────────────────────────┘
     ↓ RTMP
  Twitch
⚠️ 路線 B 注意:OBS 從 VPS 拉流需跨公網,mediamtx auth 尤其重要,建議只開放台灣固定 IP 或使用 RTMPS。

資料流對照

區段 路線 A 路線 B
LiveU → RPi5 WiFi / Ethernet WiFi / Ethernet
RPi5 → ingest server MPTCP + Reality → 台灣本機 MPTCP + Reality → 香港/日本/台灣 VPS
ingest server → OBS 內網 RTMP 公網 RTMP(需 auth)
OBS → Twitch RTMP RTMP

硬體清單與費用總覽

中國端硬體(隨身攜帶)

設備 規格建議 用途 供電 估價(NTD)
Raspberry Pi 5 4GB RAM 跑 OpenMPTCProuter USB-C PD 行動電源 約 2,500
USB Modem × 3 Huawei E3372h-153 或 Quectel EC21 各插一張 SIM,強烈建議改成 Stick Mode USB Hub 供電 600–1,200 /支
獨立供電 USB Hub 7-port,支援 USB-C PD 輸入 避免 RPi5 主板電壓瞬降 獨立行動電源 400–800
行動電源 USB-C PD 65W 以上 RPi5 + Hub 同時供電 800–1,500
microSD 32GB A2 Class 10 安裝 OpenMPTCProuter 200–400
SIM × 3 電信 + 聯通 + 移動 三電信商互補 視方案
散熱套件 銅散熱片 + 小風扇 防 modem 過熱斷線 100–300
⚠️ 重要提醒:SIM 插在 USB Modem 內,不是插在 RPi5 上(RPi5 本身沒有 SIM 卡槽)。Hub 必須獨立供電,不可從 RPi5 的 USB 偷電。

台灣端 / VPS 端

設備 路線 A(本機 ingest) 路線 B(VPS ingest)
ingest server 台灣 Linux 本機(x86_64,Ubuntu 22.04 / Debian 12,2GB RAM 以上) 香港或日本 / 台灣 VPS(1 vCPU / 1GB RAM,建議 CN2 GIA 線路)
OBS 主機 Windows 11,有獨顯;或 Linux 筆電 同左
路由器 支援 port forwarding 不需要特殊設定

軟體清單

軟體 安裝位置 用途
OpenMPTCProuter v0.63 RPi5(刷入 microSD) MPTCP Bonding 客戶端
omr-server Linux ingest server Bonding 接收端
xray-core Linux ingest server(omr-server 腳本內含) VLESS+Reality server
mediamtx v1.9.x Linux ingest server RTMP ingest + auth
OBS Studio Windows 本機 或 Linux 筆電 場景覆蓋、推 Twitch
Netdata Linux ingest server(建議) 即時鏈路品質監控

費用總覽

一次性硬體費用

項目 費用(NTD)
Raspberry Pi 5(4GB) 2,500
USB Modem × 3 1,800–3,600
獨立供電 USB Hub 400–800
行動電源(PD 65W+) 800–1,500
microSD(32GB A2) 200–400
散熱套件 100–300
合計 約 5,800–9,100

每月持續費用比較

項目 路線 A 路線 B
ingest server NT$0(自家機器) USD 15–40/月(依 VPS 規格)
中國 SIM 流量費 依用量 依用量
LiveU Solo Connect ~USD 45/月(保留 LRT 備援用) 同左
台灣 ISP 固定 IP 申請 部分 ISP 免費,部分需加購 不需要

三方案每月費用明細

  • 方案一(SIM + Reality):HK/JP/TW VPS(CN2 GIA)~NT$500-1,300 + 中國一般 SIM × 3 ~NT$900-2,700,總計 ~NT$1,400-4,000
  • 方案二(翻牆卡 + LRT):翻牆卡 × 3 ~NT$3,000-8,000 + LiveU Connect ~NT$1,500,總計 ~NT$4,500-9,500
  • 方案三(租屋 + Xray):中國租屋 ~NT$6,750-18,000 + 固定寬頻 ~NT$225-450 + 中國 SIM × 3 ~NT$900-2,700 + 台灣 VPS ~NT$165-500,總計 ~NT$8,000-21,650

實戰警告:Modem 散熱與供電架構

實戰中最常見的中斷原因不是 GFW,而是 USB Modem 過熱觸發熱保護,或 Hub 供電不足造成 USB 瞬降 reset。現代 4G/5G Modem 的 RF 射頻不會互相干擾,真正的殺手是「散熱疊加」與「供電瞬降」。

[ 行動電源 PD 65W+ ]
    │                  │
    ▼                  ▼
[ RPi5 主板 ]    [ 獨立供電 USB Hub ] (⚠️ 必須有外部 PD 輸入孔)
                    ├── Modem A(貼銅散熱片)
                    ├── Modem B(小風扇主動散熱)
                    └── Modem C(保持通風間距)
❌ 絕對不要做:
  • 將三台 Modem 緊貼在一起,或塞進密閉收納包內運作。
  • 從 RPi5 的 USB 端口「偷電」給 Hub(三卡同時搜尋基地台瞬間電流達 1.5A,會觸發 RPi5 過流保護)。

中國電信商申請與流量策略

申請資格與必備文件

台灣居民持有效「台灣居民來往大陸通行證(台胞證)」即可在中國三大電信商門市辦理手機門號。

文件 說明
台胞證(正本) 必備,實名認證主要憑證
台灣護照(備用) 部分門市掃瞄設備可能要求
預儲值金 約 ¥100-500 人民幣,依方案而定
大陸住址 / 飯店資訊 部分門市會要求登記

申請流程:到高德地圖搜尋「中國聯通/移動/電信 營業廳」,攜帶證件到直營門市(非代理點較可靠),告知「我要辦手機號,用台胞證申辦」,選擇資費方案 → 實名拍照認證 → 當場開卡。

💡 提醒:中國門號無法線上申辦,必須本人臨櫃完成實名制。辦卡時務必拍照留存合約內容、方案名稱、營業員工號,若後續有爭議可作為投訴依據。

資費方案參考(2026 年行情)

三大電信商基本比較

電信商 信號覆蓋 資費定位 台胞推薦度
中國移動 ⭐⭐⭐⭐⭐ 最廣 中高 ⭐⭐⭐
中國聯通 ⭐⭐⭐⭐ 城市佳 💰 最便宜 ⭐⭐⭐⭐⭐
中國電信 ⭐⭐⭐⭐ 南方強 中等 ⭐⭐⭐⭐

常見資費方案(人民幣/月)

方案等級 月租 通用流量 適合情境
🔹 保號/最低 ¥8-19 0-100MB 回台收簡訊、驗證碼
🔹 入門 ¥29-39 5-20GB 短期旅遊、輕度使用
🔹 主流 ¥49-79 30-60GB 長期駐點、中度使用
🔹 高階 ¥99+ 80GB+ 或無限 商務、重度上網

換算參考:¥29 ≈ NT$130;¥79 ≈ NT$360

如何辦到 8 元保號卡

直接告知營業員:「我要辦 8 元月租方案」。若被拒絕,換一家直營門市(不同門市權限不同)。部分門市會要求「先辦高價方案,次月 1 號再改」—— 務必確認合約條款。辦好後回台灣,可透過中國聯通國際客服 +86-186-1861-0010 申請改為 8 元方案。

直播流量需求計算

流量換算公式

6000 kbps = 0.75 MB/s = 2.7 GB/小時
8000 kbps = 1.0 MB/s = 3.6 GB/小時

每月總流量估算

以 6000–8000 kbps,10–12 小時/場,5–7 場/月 為例:

情境 計算方式 每月流量
🔹 最低需求 2.7 GB × 10h × 5 天 135 GB
🔹 一般需求 3.15 GB × 11h × 6 天 ~208 GB
🔹 最高需求 3.6 GB × 12h × 7 天 302 GB
⚠️ 注意:上述為純推流流量,實際使用需額外預留 10–20% 用於 MPTCP 協議開銷、Reality 隧道 TLS 封裝 overhead、系統更新、監控與重傳流量。建議預算:每月 150–350 GB

流量加餐包組合建議

中國聯通(推薦首選)

加餐包 價格 流量 有效期 備註
20GB 包 ¥20 20GB 7 天 性價比高
50GB 包 ¥40 50GB 30 天 直播首選
100GB 包 ¥70 100GB 30 天 大流量優惠

聯通直播組合建議:基礎方案 ¥39/月(20GB 通用)+ 50GB 加餐包 × 3 = ¥120 + 備用 20GB 包 × 1 = ¥20,合計 ¥179/月(約 190GB 流量)

中國移動

加餐包 價格 流量 有效期
30GB 包 ¥35 30GB 30 天
60GB 包 ¥60 60GB 30 天

移動直播組合建議:基礎方案 ¥59/月(30GB)+ 60GB 加餐包 × 2 = ¥120 + 30GB 備用包 × 1 = ¥35,合計 ¥214/月(約 210GB 流量)

中國電信

加餐包 價格 流量 有效期
50GB 包 ¥50 50GB 30 天
100GB 包 ¥90 100GB 30 天

電信直播組合建議:基礎方案 ¥79/月(60GB + CN2 GIA 骨幹)+ 100GB 加餐包 × 1 = ¥90 + 50GB 備用包 × 1 = ¥50,合計 ¥219/月(約 210GB 流量)

多卡策略與風險注意事項

多卡策略建議

三大電信 SIM 各持一張,在 OpenMPTCProuter 做 Bonding,各有其定位:

SIM 卡 角色 優勢
中國聯通 主力推流 城市信號穩定、資費低、限速門檻高(200GB/月)
中國電信 次要 CN2 GIA 骨幹,延遲最低,南方地區覆蓋強
中國移動 偏遠備援 覆蓋最廣,山區 / 郊區補位
💡 提示:三卡透過 OpenMPTCProuter 自動 Bonding,單卡斷線不影響直播。若預算有限只辦兩張,建議聯通 + 移動,覆蓋互補效果最好。

重要注意事項

  • 流量「定向」與「通用」陷阱:部分加餐包標榜「定向流量」(如騰訊系、阿里系免流)。推流到 Twitch / 日本伺服器不適用定向流量,務必確認購買的是「通用流量」或「國內 + 國際通用」。
  • 限速門檻(公平使用政策)
    電信商 達量限速門檻 限速後速度
    聯通 200GB/月 1Mbps(仍可推流但碼率需降)
    移動 100GB/月 128Kbps(基本無法推流)⚠️
    電信 200GB/月 3.1Mbps(可低碼率備援)
  • 實名制與風控:台胞證辦卡後,若回台灣長期不使用,可能被系統判定「異常」而停話。解決方案:每月至少發一則簡訊或產生少量流量保持活躍;開通國際漫遊(收簡訊免費)。
  • 繳費便利性:中國門號回台灣後,無法用台灣信用卡直接繳費。建議綁定支付寶 / 微信支付,或請中國朋友協助代繳。

實用聯絡方式

項目 資訊
中國聯通國際客服 +86-186-1861-0010(可英文/繁體中文)
中國移動國際客服 +86-138-0010-0186
中國電信國際客服 +86-189-1891-0000
工信部投訴 https://dxss.miit.gov.cn

設定步驟

本章節分為四個分頁,請依據您選擇的架構路線與設備,點擊對應的分頁查看詳細設定指令與實戰細節。

台灣端 Linux 設定(路線 A:本機 ingest)

前置條件:Ubuntu 22.04 / Debian 12、具備真正公網 IPv4(非 CGNAT)、路由器可設定 Port Forwarding。

1. 安裝 omr-server 與 xray 細調

# 安裝 OpenMPTCProuter server (內含 xray)
wget -O - https://www.openmptcprouter.com/server/omr-6-install.sh | sh

# 取得 server key (RPi5 設定時需填入)
cat /root/openmptcprouter_config.txt

編輯 /etc/xray/config.json,確保 VLESS+Reality 參數正確:

{
  "inbounds": [{
    "port": 443, "protocol": "vless",
    "settings": {
      "clients": [{ "id": "你的UUID", "flow": "xtls-rprx-vision" }],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp", "security": "reality",
      "realitySettings": {
        "dest": "www.cloudflare.com:443",
        "serverNames": ["www.cloudflare.com"],
        "privateKey": "你的私鑰",
        "shortIds": ["隨機8位hex"],
        "fingerprint": "chrome"
      }
    }
  }]
}

2. mediamtx 安裝與 Auth 設定

⚠️ 密碼警告:liveuobs 的密碼僅能使用大小寫英文與數字 (A-Za-z0-9)!絕對不可包含 @ : / # ? & 等特殊字元,否則 LiveU 設備解析 RTMP URL 時會靜默失敗。
VERSION="v1.9.1"
wget https://github.com/bluenviron/mediamtx/releases/download/${VERSION}/mediamtx_${VERSION}_linux_amd64.tar.gz
tar -xzf mediamtx_*.tar.gz && sudo mv mediamtx /usr/local/bin/

設定 /etc/mediamtx.yml

authMethod: internal
authInternalUsers:
  - user: liveu
    pass: 純英數字強密碼
    permissions: [{ action: publish, path: live/liveu }]
  - user: obs
    pass: 純英數字強密碼
    permissions: [{ action: read, path: live/liveu }]
rtmpAddress: :1935
paths:
  live/liveu:
    sourceOnDemand: no

3. CAKE QoS 與 MSS Clamp (核心優化)

# CAKE QoS (將 90000kbit 換成實際上傳頻寬的 90%)
sudo tc qdisc replace dev eth0 root cake bandwidth 90000kbit \
  diffserv4 dual-srchost nat wash no-ack-filter split-gso rtt 50ms

# MSS Clamp (寫死 1360,避開 PMTU Blackhole)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360
sudo apt install iptables-persistent -y && sudo netfilter-persistent save

4. 防火牆 (UFW) 與 systemd

sudo ufw allow 443/tcp          # xray VLESS+Reality
sudo ufw allow 1935/tcp         # mediamtx RTMP
sudo ufw allow 65001/udp        # omr-server Glorytun
sudo ufw allow 65101/tcp        # omr-server Shadowsocks
sudo ufw allow 65201:65208/udp  # omr-server MLVPN
sudo ufw enable && sudo ufw reload

# 設定自動重啟
sudo systemctl edit xray --force
# 填入:[Service]\nRestart=always\nRestartSec=5
sudo systemctl edit omr-server --force
# 填入:[Service]\nRestart=always\nRestartSec=10

VPS 設定(路線 B:VPS ingest)

架構差異:VPS 直接具備公網 IP,無需處理 CGNAT 與路由器 Port Forwarding。但 OBS 需跨公網拉流,安全性設定更重要。

1. VPS 選型與線路測試

  • 規格:1 vCPU / 1GB RAM 即足,頻寬 ≥ 20Mbps。
  • 線路:優先選擇 CN2 GIA (電信) / AS9929 (聯通) / CMIN2 (移動) 優化線路。
# 在 VPS 上測試回程線路 (各跑 100 次取樣)
apt install mtr-tiny -y
mtr -rwzbc 100 223.5.5.5        # 電信 (阿里 DNS)
mtr -rwzbc 100 114.114.114.114  # 聯通 (114 DNS)
mtr -rwzbc 100 180.76.76.76     # 移動 (百度 DNS)

💡 判斷標準:中間節點丟包不代表真實丟包,只看「最後一跳」是否 0% 丟包且延遲穩定。

2. 安裝步驟與安全強化

安裝 omr-serverxraymediamtxCAKEMSS Clamp 的指令與「路線 A」完全相同。

⚠️ UFW 白名單限制:由於 OBS 需跨公網連入 VPS 的 1935 Port,強烈建議僅允許台灣 OBS 主機的固定 IP 存取,防止 mediamtx 被暴力破解或盜推流。
# 僅允許台灣固定 IP 存取 RTMP
sudo ufw allow from 你的台灣固定IP to any port 1935
sudo ufw allow 443/tcp # xray 必須對中國端開放
sudo ufw enable

若台灣 IP 是動態的,請確保 mediamtx 的 obs 密碼足夠複雜,並考慮安裝 fail2ban 監控 1935 Port 的異常連線。

中國端 Raspberry Pi 5 設定

核心原則:在台灣完成所有設定與壓力測試,確認無誤後再帶入中國。戶外斷電風險高,務必使用 squashFS 唯讀根目錄系統。

1. 燒錄 OMR 與初次設定

  1. 下載 rpi-5-squashfs-factory.img.gz (v0.63+),用 Balena Etcher 燒錄至 microSD (A2 Class 10)。
  2. 網路線連接電腦至 RPi5 LAN 口,瀏覽器開啟 http://192.168.100.1 (注意是 http)。
  3. 預設帳號 root,密碼為空,立即設定強密碼

2. VPN 協議與 WAN 設定

進入 System → OpenMPTCProuter → Settings Wizard,填入台灣端 IP 與 Server Key。

💡 協議選擇:強烈建議首選 Hysteria2 (UDP/QUIC)。MPTCP 本身是 TCP,若再選 VLESS+Reality 會形成「三層 TCP」,在戶外 4G/5G 高丟包環境下會引發嚴重的 Head-of-Line Blocking 導致斷流。

進入 Network → Interfaces,將識別為 eth1, eth2, eth3 的 USB Modem 新增為 WAN 介面,並在各介面的 Advanced Settings勾選 MSS clamping

3. 關閉 USB Autosuspend (必做)

Linux 預設會讓閒置 USB 休眠,導致 Modem 假死且 log 無錯誤。SSH 連入 RPi5 執行:

# 永久關閉 USB 休眠
echo 'usbcore.autosuspend=-1' >> /etc/cmdline.d/usb.conf
reboot

4. LiveU Solo 設定 (強烈建議有線)

  • 物理連接:使用 Cat5e 網路線連接 LiveU Solo Ethernet 口與 RPi5 LAN 口 (eth0)。有線可消除 WiFi 干擾,延遲穩定 <1ms。
  • Solo Portal:推流模式選 RTMP Direct,URL 填入 rtmp://liveu:密碼@你的公網IP/live/liveu
  • 備援:保留 LRT + RTMP 設定在 Portal 中,緊急時可一鍵切換回 LiveU 日本 AWS 中轉。

OBS 推流端設定 (Windows / Linux 筆電)

OBS 負責從 ingest server 拉流、疊加版面與 Alert,並二次編碼推送到 Twitch。

1. 編碼器選擇 (Linux 筆電適用)

顯卡類型 推薦編碼器 OBS 設定名稱 備註
NVIDIA (GTX/RTX) ✅ NVENC H.264 NVIDIA NVENC H.264 首選,需 proprietary driver
Intel (UHD/Iris) ✅ VA-API H.264 FFmpeg VA-API H.264 需安裝 intel-media-driver
AMD (RX 5000+) ✅ VA-API H.264 FFmpeg VA-API H.264 open source 驅動已內建
無獨顯 / 舊硬體 ⚠️ x264 (CPU) x264 吃 CPU,建議碼率 ≤ 4500kbps

2. Media Source (拉流設定)

來源 → 新增 → 媒體來源,取消勾選「本機檔案」

  • 路線 A (內網):rtmp://obs:密碼@192.168.x.x/live/liveu
  • 路線 B (公網):rtmp://obs:密碼@VPS公網IP/live/liveu
⚠️ 緩衝設定:勾選「使用緩衝」,大小設為 1000-3000 ms絕對不要勾選 Ultra Low Latency。OBS 進階設定中的 Network Buffering 建議設為 1-5 MB,設 0 會卡頓,設超過 10 MB 會累積明顯延遲。

3. 推流設定 (OBS → Twitch)

設定項目 建議值 說明
碼率控制 CBR 固定碼率讓 bonding 流量可預測,避免突衝擊穿頻寬
目標碼率 6000–8000 kbps 依出發前實測的「穩定最低聚合頻寬」決定
關鍵影格間隔 2 秒 Twitch 強制要求
B-frames 0 降低 encoder 內部緩衝延遲
Profile / Tune high / zerolatency 兼顧畫質與即時性
🐧 Linux 筆電用戶注意 (NVIDIA Optimus):
若您的筆電同時擁有 Intel 內顯與 NVIDIA 獨顯,OBS 預設可能會使用內顯編碼導致極度卡頓。請務必在終端機使用 prime-run obs 啟動 OBS,或在 ~/.bashrc 中設定 export __NV_PRIME_RENDER_OFFLOAD=1 強制調用獨顯 NVENC。出發前請務必使用 nvidia-smi 確認驅動已正確載入。

深度說明

台灣端 VPS 為何仍需要 Reality 偽裝?

很多人誤以為「伺服器在台灣,GFW 管不到」,這是錯誤的。GFW 封鎖的不是「某個國家的 IP」,而是「流量特徵」與「協議指紋」。

架構組合 GFW 能否識別 RTMP? 預計存活時間
台灣 IP + RTMP 明文 (無隧道) ✅ 100% 可識別 (DPI 看穿) < 10 秒
台灣 IP + Reality 偽裝 ❌ 無法識別 (視為 TLS) 長期穩定
💡 結論:「有沒有偽裝」比「伺服器在哪裡」重要 100 倍。台灣 IP 的優勢在於「被主動黑名單的機率較低」且「延遲低」,但若不包上 Reality 隧道,RTMP 的握手魔數 (0x03) 依然會在出境瞬間被 GFW 靜默丟包。

TCP in TCP 問題說明與解法

本架構若使用 VLESS+Reality,封包結構為 RTMP (TCP) → Reality (TCP) → MPTCP subflow (TCP),三層都是 TCP。在戶外 4G/5G 丟包率高的環境下,外層 TCP 的重傳機制會阻塞內層 TCP 的 ACK,引發嚴重的 Head-of-Line Blocking (HOL Blocking),導致直播延遲飆升甚至斷流。

避開 TCP in TCP 的實戰建議

方案 做法 適用情境
方案 A(推薦) 在 OMR 的 VPN 設定改用 Hysteria2(UDP/QUIC 底層) GFW 對 UDP 干擾不嚴重的地區
方案 B 使用 Glorytun UDPMLVPN 作為底層隧道承載 Xray 需要 UDP 穿透力更強的方案
方案 C(保底) 維持 VLESS+Reality,但備妥 Hysteria2 在 OMR 快速切換 見備援計畫
⚠️ 注意:若必須維持 VLESS+Reality,在戶外弱網環境下需接受 HOL Blocking 風險,此時建議調高 OBS 的 Network Buffering 至 3–5 MB,以犧牲延遲換取穩定性。

MTU / MSS / Bufferbloat 深度說明

為什麼 MTU/MSS 在這套架構特別重要?

本系統的封包結構經歷多層封裝,每一層都會消耗 header 空間:

RTMP(TCP)
  ↳ 包在 VLESS+Reality(TCP + TLS overhead,約 60 bytes)
      ↳ 包在 MPTCP(subflow header,約 20 bytes)
          ↳ 傳出實體網路(Ethernet MTU 1500 bytes)

若內層 TCP 的 MSS 沒有向下調整,加上外層 header 後會超過 1500 bytes,導致靜默分片(silent fragmentation)、PMTU Blackhole(ICMP 被過濾導致 PMTU Discovery 失效)、重傳率暴增、OBS 畫面卡頓。

MSS 計算邏輯

計算步驟 數值
設定 tunnel 介面 MTU 1400 bytes(為外層封裝留 100 bytes 空間)
減去 IP header − 20 bytes
減去 TCP header − 20 bytes
最終 MSS 設定值 1360 bytes
💡 為什麼用固定值而非 --clamp-mss-to-pmtu
動態方式依賴 PMTU Discovery(透過 ICMP Type 3 Code 4),但跨境鏈路的 ICMP 常被 GFW 或 ISP 過濾,PMTUD 會靜默失效。直接寫死 1360 是更可靠的做法。

Bufferbloat 與 CAKE 的關係

台灣端上傳頻寬同時被 OBS(推 Twitch)和 omr-server(接收中國端串流)佔用時,沒有 QoS 的情況下,TCP ACK 封包會被大封包排在後面等待。中國端的 LiveU 收不到 ACK 就會誤以為鏈路惡化而降碼率。CAKE QoS 的作用是確保上傳隊列不會被少數大封包塞死,讓 ACK 能及時通過。

上線前測試清單

🚨 核心原則:在台灣模擬完整流程,出發前排除所有問題,絕對不要到中國現場才發現問題並除錯。

基本連線測試

  • RPi5 連上 ingest server(omr-server 後台顯示 connected)
  • xray tunnel 建立成功(journalctl -u xray 無錯誤)
  • LiveU RTMP Direct 推流到 mediamtx(http://Linux機IP:9997 顯示 publisher)
  • OBS 能從 mediamtx 拉流
  • OBS 能推流到 Twitch

斷線恢復測試(必測)

  • 拔掉 Modem A:觀察 LiveU 碼率是否平滑下降但繼續推流;重新插回後是否自動恢復
  • 拔掉 Modem A + B(只剩 C):確認系統能以單卡繼續推流
  • 重啟 xray:systemctl restart xray,觀察 LiveU 是否在 30 秒內自動 reconnect
  • 重啟 omr-server:systemctl restart omr-server,觀察整條 tunnel 的恢復時間
  • 重啟 mediamtx:systemctl restart mediamtx,觀察 OBS 的 Media Source 是否自動重連
⚠️ 注意:若 LiveU 斷線後不會自動 reconnect,出發前必須制定手動重連的 SOP(例如準備好能開 Solo Portal 的手機),不能只依賴自動恢復。

壓力測試

  • 持續推流 30 分鐘,觀察碼率穩定性
  • 摸 USB Modem 溫度,過燙需加散熱
  • 確認 CAKE 在運作:tc qdisc show dev eth0
  • 確認 MSS clamp 有封包計數:iptables -t mangle -L FORWARD -v | grep TCPMSS

備援計畫與故障排查

備援計畫

戶外直播充滿變數,必須針對各種潛在故障點準備對應的備援方案(Plan B),確保直播不中斷。

情況 A:ingest server 掛掉(本機或 VPS)

  • 對策:切回 LiveU LRT 模式。
  • 操作:LiveU Solo Portal → 關閉 RTMP Direct → 改回 LRT + RTMP 輸出 → 目的地填 LiveU 雲端轉發設定。
  • 注意:雖然要過日本 AWS 增加延遲,但至少直播不中斷。平時把 LRT 設定保留在 Portal,不要刪掉。

情況 B:RPi5 或 USB Modem 全數故障

  • 對策:LiveU 直接改用手機熱點,繼續用 RTMP Direct 單卡推流(無 bonding,但維持直播)。

情況 C:Reality 被 GFW 封鎖

  • 對策:預先在 ingest server 裝好 Hysteria2 備用。
  • 操作:在 OpenMPTCProuter 後台的 VPN 設定切換為 Hysteria2。
  • 注意:不要只有單一隧道協議,務必保留備用協定隨時切換。

情況 D:台灣 ISP 掛掉(路線 A)

  • 短期:啟用 4G 備援路由(若有備用 router)。
  • 中期:臨時切換到路線 B(快速開一台 VPS,同樣的設定流程)。

情況 E:方案一整體失效(VPS IP 被封 + Reality 被封)

依序嘗試以下切換順序:

  1. 換 VPS IP:同一供應商重新開機取得新 IP,或換節點。
  2. 切換到 Hysteria2:參考情況 C。
  3. 切換到方案二(翻牆卡 + LRT):準備一張備用翻牆卡,LiveU LRT 設定保留不刪。
  4. 切換到方案三(租屋固定寬頻):若有中國據點,啟用備用 Windows PC Xray。
⚠️ 最終防線:建議至少保留方案二(翻牆卡 + LRT)作為最終備援。發生重大直播當天突發封鎖時,翻牆卡切換速度最快,能確保重要活動順利播出。

故障排查

當系統出現異常時,請依照以下症狀與指令進行排查。

症狀 診斷指令 說明
Bonding 沒有合併頻寬 systemctl status mptcpd 確認 MPTCP 服務狀態;確認三個 WAN 介面都 Connected;若 HiLink mode,確認三張卡網段不衝突。
Modem 突然消失
(WAN disconnected)
lsusb
cat /sys/module/usbcore/parameters/autosuspend
dmesg -T | grep -i usb | tail -20
autosuspend 應顯示 -1;over-current → 供電問題;device disconnected → 過熱問題。
Tunnel 不通 / GFW 封鎖 ss -tlnp | grep 443
journalctl -u xray -f
確認 xray 監聽 443;確認 port 443 forwarding 正確(路線 A)。
LiveU 推流被拒
(Auth 失敗)
journalctl -u mediamtx -f 密碼若含特殊字元需 URL encode(例如 @%40)。
OBS 拉不到串流 systemctl status mediamtx
瀏覽器開 http://Linux機IP:9997
確認 LiveU 正在推流(需要 publisher 存在 OBS 才能拉);OBS URL 格式需含 auth。
推流碼率不穩 / jitter 高 tc qdisc show dev eth0
sudo iptables -t mangle -L FORWARD -v | grep TCPMSS
確認 CAKE 套用;MSS clamp 封包計數若為 0 → 規則被覆蓋需重新插入。
全域快速檢查 systemctl status omr-server xray mediamtx 三個服務都 active (running) 是基本前提。

安全性注意事項

將串流服務暴露在公網(尤其是路線 B 的 VPS),必須做好基本的安全防護,避免被盜推流、頻寬被盜用或遭受惡意攻擊。

✅ 必做事項

  • mediamtx 帳密分離:設定 publish (LiveU 推流) 與 read (OBS 拉流) 分開的兩組帳密,絕對不要用同一組。
  • 強密碼與隨機 UUID:xray 使用強密碼和隨機生成的 UUID,避免被掃描器爆破。
  • 嚴禁洩漏機密:不在任何公開頻道、截圖或直播畫面中洩漏 Stream Key、Reality 私鑰、mediamtx 密碼或 VPS 真實 IP。

💡 建議事項

  • 優先使用 RTMPS:若 LiveU Solo 版本支援 RTMPS Direct,優先使用以加密 RTMP 流量,防止中間人側錄。
  • IP 白名單(路線 B 必備):VPS 的 mediamtx RTMP port (1935) 加 IP 白名單,只允許台灣 OBS 主機的固定 IP 存取。
  • 安裝 fail2ban:在 ingest server 安裝 fail2ban,自動封鎖暴力嘗試 SSH 或 RTMP 連接埠的惡意 IP。
  • 定期檢查日誌:定期確認 journalctl -u mediamtx 裡沒有異常的 publish 嘗試或未知 IP 的連線紀錄。

❌ 絕對不要做

  • 裸露 mediamtx(無 auth 設定,任何人皆可推流與拉流,極易被盜用頻寬推播違規內容)。
  • 使用弱密碼或預設密碼(如 admin123456liveu123)。
  • 公開 Reality 的 shortIdprivateKey(這會導致偽裝徹底失效,節點秒封)。
  • 在 GitHub 等公開倉庫提交包含真實 IP、UUID 或密碼的 config.jsonmediamtx.yml