中國戶外直播指南

快速決策：四種方案白話版比較

給不想看落落長技術文件、只想知道「我該選哪個」的人看的懶人包。想了解每個選擇背後的工程原理，可以往下滑看完整技術章節。

① LiveU + 翻牆卡 + LRT → 日本 LiveU Cloud

在幹嘛：翻牆卡本身內建「翻牆」能力，LiveU 用它自己的 LRT 模式，把訊號送到日本的 LiveU 官方雲端伺服器中轉，再轉播出去。

白話理解：全部交給 LiveU 官方處理，你只要負責插卡、開機、開播。最省心，但每月要付翻牆卡和 LiveU 雲端服務的錢，而且多繞一手（中國 → 日本 → 你的平台），延遲會比較高。

適合：不想學技術、預算夠、只求穩定開播的人。

② LiveU + RPi5 + Bonding（多卡合併）+ RTMP Direct → 自己的 VPS/PC

在幹嘛：買 2–3 張中國一般 SIM 卡插在 USB modem 上，接到一台樹莓派（RPi5），樹莓派把三張卡的網路「合併」成一條更粗更穩的線（這就是 Bonding），再包一層偽裝成正常網站流量的加密隧道（Reality），直接送到你自己架的伺服器（VPS 或家用 PC），繞過 LiveU 官方雲端。

白話理解：最自由、最穩、但也最難搞的方案。三張卡互相備援，一張訊號差不影響直播；隧道偽裝讓對岸網路審查看不出你在幹嘛。代價是要自己買設備、自己設定、自己維護，出問題也要自己排查。

適合：長時間戶外移動直播（例如邊走邊拍好幾小時）、對穩定性要求最高的人。

③ LiveU + RPi5（只插 1 張卡，沒有 Bonding）→ Windows PC

在幹嘛：跟②很像，一樣是 RPi5 + 隧道加密偽裝，但只用 1 張 SIM 卡，不做多卡合併，樹莓派設定也簡單很多（不用裝那套多卡合併的系統，一般 Windows 電腦也能當接收端）。

白話理解：②的簡化版。少了「多卡互相備援」這個保險，一張卡訊號不好或斷線，直播就會受影響；但抗審查能力完全沒打折——加密偽裝的邏輯跟②一模一樣。

適合：手上只有一張可用 SIM 卡、或想先簡化測試整條流程能不能通，之後再升級成②的人。

④ 手機（iPhone / Samsung）直接裝 VPN App，用 Reality 或 Hysteria2 直推 Twitch

在幹嘛：完全不用 LiveU、不用樹莓派。SIM 卡直接插在手機上，手機裝一個翻牆 App（例如 v2rayNG、Shadowrocket），手機本身當直播主機，直接把畫面推上 Twitch。

白話理解：最輕裝的做法，一支手機搞定。協議預設建議選 VLESS+Reality（偽裝成正常網站流量）而不是 Hysteria2——因為手機用的是電信 SIM 卡數據，電信商比較容易對 Hysteria2 這種協議限速，Reality 相對不會被卡流量。只有在 Reality 被針對性封鎖、或訊號真的很差時，才切換成 Hysteria2。

適合：不想帶一堆設備、臨時想開播、或當作①②③斷線時的緊急備案。

系統目標與邊界

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

選擇邏輯與決策矩陣

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

中國端出境方案比較

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

方案一：本地 SIM 卡 + VLESS+Reality（本文件主要涵蓋）

• SIM 卡使用中國三大電信一般上網卡（非翻牆卡）
• 穿越 GFW 靠 VLESS+Reality，偽裝 TLS 1.3，幾乎無特徵
• 完全自架、自主掌控，VPS 費用為主要持續成本

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

• SIM 卡為商業翻牆卡（如電信貓、iRoaming 等），網路層已內建 GFW 繞過
• LiveU LRT 為 LiveU 專有協議，穿透力強
• 最省心，有商業團隊維護線路；缺點是費用高、繞日本 AWS 增加延遲（+80–150ms）

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

• RPi5 的 SIM 只走中國國內段（低延遲、穩定），GFW 穿越交給固定寬頻
• 住宅 / 商業固定 IP 被 GFW 針對性封鎖的機率遠低於 VPS 機房 IP
• 適合長期在中國固定地點直播；需要在中國有常駐據點與設備

三方案綜合比較

費用明細

• 方案一 每月：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

台灣端 ingest 路線選擇

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

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

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

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

排列組合決策矩陣

不可行組合說明

• 【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 上），但需在中國有固定據點租屋，備案合規風險高，技術複雜度高，成本接近方案三。

決策流程

graph TD
    Start([想換架構？]) --> Q1{預算與技術意願？}
    Q1 -->|預算充足 + 完全不想碰技術| A1["維持現有方案: 翻牆卡 + LiveU LRT + 日本 AWS"]
    Q1 -->|願意自架 2-4 小時 + 追求低成本| Q2{台灣現場是否有公網 IP？}
    Q2 -->|是, 具備真實公網 IPv4| A2["選擇 路線 A: 台灣本機 Ingest (0 元 VPS 持續費用)"]
    Q2 -->|否, 處於 CGNAT 寬頻環境| A3["選擇 路線 B: 租用香港/日本/台灣 VPS (每月持續費用約 $15-40 USD)"]
    Q1 -->|只有 1 張 SIM 卡 / 想先簡化測試| A5["免 Bonding 精簡版: 單卡直推 (不裝 OMR，RPi5 純跑 Xray client)"]
    Q1 -->|長期駐點中國 >6個月 + 有固定辦公室| A4["考慮 方案三: 中國據點固定寬頻 + Xray 出境隧道 (⚠️ 需審慎評估風險)"]
          

整體架構拓撲

路線 A：台灣本機 Ingest 架構拓撲

graph TD
    subgraph China ["════════ 中國現場邊界 ════════"]
        FX30["Sony FX30 攝像機"] -->|HDMI 輸出| LiveU["LiveU Solo (RTMP Direct 模式)"]
        LiveU -->|WiFi / Ethernet| RPi5["樹莓派 Raspberry Pi 5 (OpenMPTCProuter v0.63)"]

        subgraph RPi5_Detail ["多鏈路聚合調校"]
            direction TB
            ModemA["USB Modem A (中國電信 SIM)"]
            ModemB["USB Modem B (中國聯通 SIM)"]
            ModemC["USB Modem C (中國移動 SIM)"]
        end

        RPi5 ---> ModemA & ModemB & ModemC
        ModemA & ModemB & ModemC -->|MPTCP Bonding 頻寬聚合| Tunnel["跨越 GFW 防火牆 (標準 TLS / QUIC 流量)"]
    end

    subgraph Taiwan ["════════ 台灣本機端防禦邊界 ════════"]
        Tunnel -->|公網傳輸| LinuxServer["Linux Ingest 本機主機 (Ubuntu 22.04 / Debian 12)"]

        subgraph Linux_Detail ["內部服務堆疊"]
            direction TB
            OMR_S["omr-server 核心接收端"]
            Xray["Xray 服務端解密"]
            MediaMTX["MediaMTX 核心本體 (RTMP Ingest + 強認證)"]
            QoS["CAKE QoS 隊列調校 (限制 ACK 阻塞 / 防 Bufferbloat)"]
        end

        LinuxServer ---> OMR_S --> Xray --> MediaMTX
        LinuxServer --> QoS

        MediaMTX -->|區域網路 RTMP 含 Auth| OBS["OBS Studio 控制台 (Windows 主機 / Linux 筆電)"]
        OBS -->|CBR 預測碼率推流| Twitch((Twitch 串流平台))
    end
          

路線 B：VPS Ingest 架構拓撲

graph TD
    subgraph China_B ["════════ 中國現場邊界 ════════"]
        FX30_B["Sony FX30 攝像機"] -->|HDMI| LiveU_B["LiveU Solo (RTMP Direct 模式)"]
        LiveU_B -->|LAN / WiFi| RPi5_B["樹莓派 Raspberry Pi 5 (OMR 多卡聚合 + 隧道加密)"]
    end

    subgraph VPS ["════════ 香港 / 日本 / 台灣 雲端 VPS ════════"]
        CloudServer["Linux Cloud VPS (1 vCPU / 1GB RAM)"]

        subgraph VPS_Detail ["雲端收斂服務堆疊"]
            direction TB
            V_OMR["omr-server 聚合接收解包"]
            V_Xray["Xray 傳輸層解密"]
            V_MMTX["MediaMTX 串流中繼 (1935/8890 端口對公網下架)"]
        end

        CloudServer ---> V_OMR --> V_Xray --> V_MMTX
    end

    subgraph Taiwan_B ["════════ 台灣工作室接收端 ════════"]
        OBS_B["OBS Studio 導播台 (Windows 本機 / Linux 筆電)"]
    end

    RPi5_B -->|優化回程線路 CN2 GIA / CMIN2| CloudServer
    V_MMTX -->|跨公網 RTMP 安全拉流| OBS_B
    OBS_B -->|CBR 固定碼率推流| Twitch_B((Twitch 串流平台))
          

資料流對照

硬體清單與費用總覽

中國端硬體（隨身攜帶）

台灣端 / VPS 端

軟體清單

費用總覽

一次性硬體費用

每月持續費用比較

三方案每月費用明細

• 方案一（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。此外三台 Modem 的射頻並不會相互干擾，真正的殺手是「散熱疊加」與「供電瞬降」。

[ 行動電源 PD 65W+ ]
    │                  │
    ▼                  ▼
[ RPi5 主板 ]    [ 獨立供電 USB Hub ] (⚠️ 必須有外部 PD 輸入孔)
                    ├── Modem A（貼銅散熱片）
                    ├── Modem B（小風扇主動散熱）
                    └── Modem C（保持通風間距）

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

申請資格與必備文件

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

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

資費方案參考（2026 年行情）

三大電信商基本比較

常見資費方案（人民幣/月）

換算參考：¥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 場/月 為例：

流量加餐包組合建議

中國聯通（推薦首選）

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

中國移動

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

中國電信

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

多卡策略與風險注意事項

多卡策略建議

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

重要注意事項

• 流量「定向」與「通用」陷阱：部分加餐包標榜「定向流量」（如騰訊系、阿里系免流）。推流到 Twitch / 日本伺服器不適用定向流量，務必確認購買的是「通用流量」或「國內 + 國際通用」。
• 限速門檻（公平使用政策）：

  電信商	達量限速門檻	限速後速度
  聯通	200GB/月	1Mbps（仍可推流但碼率需降）
  移動	100GB/月	128Kbps（基本無法推流）⚠️
  電信	200GB/月	3.1Mbps（可低碼率備援）

• 實名制與風控：台胞證辦卡後，若回台灣長期不使用，可能被系統判定「異常」而停話。解決方案：每月至少發一則簡訊或產生少量流量保持活躍；開通國際漫遊（收簡訊免費）。
• 繳費便利性：中國門號回台灣後，無法用台灣信用卡直接繳費。建議綁定支付寶 / 微信支付，或請中國朋友協助代繳。

實用聯絡方式

設定步驟

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

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

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

{
  "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"
      }
    }
  }]
}

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/

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

# 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

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 上測試回程線路 (各跑 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)

# 僅允許台灣固定 IP 存取 RTMP
sudo ufw allow from 你的台灣固定IP to any port 1935
sudo ufw allow 443/tcp # xray 必須對中國端開放
sudo ufw enable

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

免 Bonding 精簡方案：單卡直推

適用情境：只有 1 張可用 SIM 卡、想先簡化測試、或訊號穩定不需要多卡合併容錯。核心邏輯不變（RTMP Direct + VLESS+Reality 偽裝翻牆），差別只在拿掉 MPTCP 這一層 bonding。

適用情境與取捨

拿掉 bonding，放棄的是「單卡波動不影響直播、多卡頻寬合併」這兩個核心承諾。換來的是設定複雜度大幅降低、少一張 SIM 卡的月租費、少一層 TCP 疊加。

架構圖與封包結構

中國現場                                    台灣/海外
┌──────────────┐   Ethernet   ┌──────────┐   VLESS+Reality   ┌──────────────┐
│  LiveU Solo  │ ───RTMP────► │   RPi5   │ ─────(TCP)───────► │ ingest server │
│ (RTMP Direct)│              │ (xray    │      單一 SIM       │ (xray+media-  │
└──────────────┘              │  client) │      無 bonding     │  mtx)         │
                               └──────────┘                     └──────────────┘
                                    │
                               單張 SIM 卡
                               （4G/5G 直連）

拿掉 MPTCP subflow 這一層後變成兩層 TCP：RTMP (TCP) → Reality (TCP) → 單一實體網路（4G/5G）

RPi5 端設定

不需要 OpenMPTCProuter（OMR 的核心賣點就是 MPTCP bonding，單卡用不到）。改用標準 Raspberry Pi OS Lite + xray-core client，設定更單純：

1. 用 Raspberry Pi Imager 燒錄 Raspberry Pi OS Lite (64-bit)，開機後 SSH 進去更新系統
2. 安裝 xray-core：

   bash <(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)

client 設定（/usr/local/etc/xray/config.json）：

{
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 1935,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "你的 ingest server IP",
        "port": 443,
        "network": "tcp"
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "你的 ingest server IP",
            "port": 443,
            "users": [
              {
                "id": "你的 UUID",
                "flow": "xtls-rprx-vision",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "你的 SNI",
          "fingerprint": "chrome",
          "publicKey": "你的 public key",
          "shortId": "你的 shortId"
        }
      }
    }
  ]
}

dokodemo-door inbound 直接把本機 1935 port 收到的 RTMP 流量，透過 outbound 的 VLESS+Reality 送到 ingest server 的 443 port。開機自啟：

sudo systemctl enable xray
sudo systemctl start xray

LiveU Solo 設定：Ethernet 接 RPi5，目的地 URL 填 rtmp://liveu:密碼@RPi5的LAN IP:1935/live/liveu（注意是打去 RPi5 本機的 1935 port，不是公網 IP）。

Server / VPS 端設定差異

沿用完整版的 server 端設定，但跳過安裝 omr-server 這一步——omr-server 是接收 MPTCP bonding 流量的元件，單卡用不到。xray 細調、mediamtx、CAKE、MSS Clamp、systemd、UFW 其餘步驟完全比照辦理。

硬體與費用差異

風險與限制

手機直推變體（無 RPi5）

若連 RPi5 都想省掉，改成手機直接當編碼器（例如 Moblin 或其他支援 RTMP/SRT 輸出的直播 app），SIM 卡直接插手機，用 v2rayNG（Android）或 NekoBox 等 app 建立 VLESS+Reality tunnel，本機走 VPN 模式導流。

這個變體也是「備援計畫與故障排查」章節「情況 B」（RPi5 或 USB Modem 全數故障）的正式版本——差別在於情況 B 是臨時應急，這裡是把它當成一開始就規劃好的正式架構。

深度說明

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

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

VLESS+Reality+Vision vs Hysteria2 深度比較

VLESS+Reality+Vision 有沒有用到 BBR？

上表「弱網表現」只講了 TCP in TCP 的 HOL blocking，還有一個更底層的變數：BBR/CUBIC 是作業系統核心層的 TCP 壅塞控制演算法，跟 VLESS/Reality/Vision 這三層完全無關——它們都跑在 TCP 之上，封包丟了要不要降速，交給當下的作業系統設定。

sysctl net.ipv4.tcp_congestion_control
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

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 的實戰建議

協議封裝命名對照

「隧道包隧道」(tunnel-in-tunnel) 沒有統一的專有名詞，但依外層／內層協議的組合，各自有各自的說法。以下整理四種組合，並對照回本頁的實際情境：

實戰建議：VLESS+Reality 為主、Hysteria2 為備援

不是二選一，是「主力 + 備援」的組合：

為什麼 Reality 是預設

• RTMP 本身是 TCP，整條鏈路（RTMP → 隧道 → MPTCP）已經是 TCP 起家，用 Reality 不會多引入一種傳輸層
• 偽裝能力最強——GFW 看到的是標準 TLS 1.3 握手，被主動探測時 Reality 還會把連線轉發給真實網站，幾乎沒有特徵
• 抗封鎖穩定性長期來看優於 Hysteria2（UDP 特徵即使有混淆，還是比偽裝成正常 HTTPS 更容易被盯上）

什麼時候切 Hysteria2

• Reality 突然被 GFW 針對性封鎖
• 弱網環境丟包率特別高、TCP meltdown 已經嚴重影響直播品質時，QUIC 的多路復用能讓丟包不阻塞整體
• 代價是 UDP 在部分中國 ISP 會被 QoS 限速，設定複雜度也略高

實戰 SOP

1. 平時用 VLESS+Reality 開播
2. 在 ingest server 同時裝好 Hysteria2，保持隨時可切換的狀態
3. 直播中若發現碼率異常、延遲飆高，直接在 OpenMPTCProuter 後台切協議，不用重新設定整條鏈路

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 計算邏輯

Bufferbloat 與 CAKE QoS 的關係

台灣端上傳頻寬同時被 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 是否自動重連

壓力測試

• 持續推流 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，但維持直播）。
• 協議選擇：手機走電信 SIM 卡數據，UDP 流量被電信商限速的機率比固定寬頻更高，建議手機端優先用 VLESS+Reality 而非 Hysteria2；只有在 Reality 被針對性封鎖或訊號極差時才切換。

情況 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。

故障排查

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

安全性注意事項

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

✅ 必做事項

• mediamtx 帳密分離：設定 publish (LiveU 推流) 與 read (OBS 拉流) 分開的兩組帳密，絕對不要用同一組。
• 強密碼與隨機 UUID：xray 使用強密碼 and 隨機生成的 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 的連線紀錄。

❌ 絕對不要做