架構總覽
伺服器引擎
Xray ★推薦 Sing-box Hysteria2 官方 WireGuard ✗
協議組合
VLESS+Reality+Vision Hysteria2 (QUIC) WireGuard (不適用)
管理介面 / 客戶端
3x-ui(伺服器面板) s-ui Shadowrocket (iOS) v2rayN (Win) Hiddify(全平台) v2rayNG (Android)
s-ui
底層引擎:Sing-box
協議支援Sing-box 支援的全部協議(含 Tuic、NaïveProxy)
多用戶管理
QR Code
Telegram Bot
社群資源較少,比 3x-ui 少許多
穩定性相對新,社群測試較少
適合對象

想使用 Sing-box 特有協議(Tuic、NaïveProxy),或習慣 Sing-box 生態的進階用戶。

Shadowrocket
iOS 專用
費用$2.99 美金(付費)
底層引擎Xray / Sing-box
協議VLESS+Reality、Hysteria2…
需非中國區 Apple ID 購買。掃 QR Code 即可連線,操作最直覺。
v2rayN
Windows 專用
費用免費開源
底層引擎Xray + Sing-box 雙引擎
特色訂閱連結、TUN 全局代理
Windows 最主流選擇,支援一鍵更新節點。
Hiddify
Win / Mac / Linux / iOS / Android
費用免費
底層引擎Sing-box
特色最廣平台支援、TUN 全局代理
一個 App 覆蓋所有主流平台,最適合跨裝置需求。
v2rayNG
Android 專用
費用免費開源
底層引擎Xray
特色Android 最主流選擇
與 3x-ui 搭配使用體驗最佳。
Clash Verge
Win / Mac / Linux
費用免費
底層引擎Clash Meta
特色規則路由靈活
熟悉 Clash 生態的用戶首選。
NekoBox
Android
費用免費
底層引擎Sing-box
特色Android 上的 Sing-box 客戶端
需要 Tuic / NaïveProxy 等 Sing-box 特有協議時的 Android 選擇。
目標架構
推薦方案:VLESS + Reality + Vision
中國朋友(Shadowrocket / v2rayN) ↓ VLESS + Reality + Vision GFW:看到正常 TLS 流量 → 放行 ↓ 你的台灣伺服器(3x-ui / Xray) ↓ YouTube / Twitch / Discord
架設步驟
1
安裝 3x-ui
在台灣伺服器上執行以下指令,一鍵安裝 3x-ui 面板與 Xray 核心。
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
2
登入面板
安裝完成後,開啟瀏覽器登入管理面板,立即修改預設密碼
網址:http://你的IP:2053 帳號:admin 密碼:admin(⚠️ 登入後立即修改)
3
新增 Inbound(VLESS + Reality)
在面板中新增一個入站連接,按以下設定填寫:
協議:VLESS 傳輸方式:TCP 安全性:Reality SNI(偽裝網域):www.apple.com Flow:xtls-rprx-vision Public / Private Key:系統自動生成 → 儲存
4
產生客戶端連結
在 Inbound 列表點選「QR Code」或「複製連結」,傳給朋友,用 Shadowrocket 或 v2rayN 掃碼 / 貼上即可連線。
5
(可選)加開 Hysteria2 Inbound
如需高速推流(如 Twitch),可在面板另建一個 Hysteria2 Inbound,兩種協議共存,不互相干擾。
協議:Hysteria2 傳輸方式:UDP 端口:自定義(如 443) 混淆:obfs-password 填入任意字串
以下範本已移除所有敏感資訊(UUID、私鑰、密碼、API Token、個人路徑、個人域名)。 需填寫之處以 <YOUR_XXX> 標示。
重點說明
協議堆疊
VLESS + Reality + Vision(xtls-rprx-vision
偽裝目標
www.apple.com:443 — GFW 看到的是連到 Apple 的正常 TLS
封鎖規則
Private IP 與 BitTorrent 直接 block,避免伺服器被濫用
多用戶
每位使用者有獨立 UUID + email 標籤,方便在 log 中識別流量
shortIds
多個 shortId 讓不同客戶端各自使用,互不干擾
完整設定檔
{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "<YOUR_UUID_1>",          // 用 uuidgen 或 3x-ui 介面產生
            "email": "user-self",              // 識別標籤,可自訂
            "flow": "xtls-rprx-vision"
          },
          {
            "id": "<YOUR_UUID_2>",
            "email": "user-mobile",
            "flow": "xtls-rprx-vision"
          },
          {
            "id": "<YOUR_UUID_3>",
            "email": "friend-pc",
            "flow": "xtls-rprx-vision"
          },
          {
            "id": "<YOUR_UUID_4>",
            "email": "friend-mobile",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "dest": "www.apple.com:443",         // 偽裝目標,需是真實可連的 TLS 網站
          "serverNames": ["www.apple.com"],
          "privateKey": "<YOUR_PRIVATE_KEY>", // 3x-ui 自動生成,或 xray x25519
          "shortIds": ["", "1", "2", "3", "4", "5", "6"]
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],               // 封鎖存取伺服器內網
        "outboundTag": "block"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],             // 封鎖 BT,防止 DMCA
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv4"             // 強制走 IPv4 出口
      },
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ]
}
選購核心框架
運營商 × 回程線路
決定晚高峰體驗。同樣是香港 VPS,電信走 CN2 GIA vs 普通 163,體驗天差地別。
地區(物理距離)
決定延遲下限。物理位置是任何線路優化都無法突破的物理極限。
IP 類型與信譽
決定平台認不認你。機房 IP / 住宅 IP / ISP IP 影響流媒體、帳號、支付的可用性。
地區是門牌號,線路是路況,IP 信譽是入場券,協議特徵決定這張票能用多久。
三大運營商回程線路
📡 電信(China Telecom) 關鍵字:163 / CN2 GT / CN2 GIA
線路 ASN IP 特徵 品質 備註
163 ChinaNet AS4134 202.97.x.x 普通 覆蓋廣,成本低,晚高峰易擁塞
CN2 GT AS4809 59.43.x.x 中階 比普通好,晚高峰仍有波動
CN2 GIA AS4809 59.43.x.x 最優 ★ 晚高峰最穩,價格最貴 → 香港/日本/美西首選
📡 聯通(China Unicom) 關鍵字:AS4837 / AS9929
線路 ASN IP 特徵 品質 備註
普通骨幹 AS4837 219.158.x.x 普通 美西/日本常走此路,性價比好
精品線路 AS9929 精品 ★ 用戶少,擁塞少,適合遠端辦公/遊戲/低丟包
📡 移動(China Mobile) 關鍵字:CMI / CMIN2
線路 ASN 品質 備註
CMI AS58453 普通 香港/日本/新加坡/美西不差,性價比好
CMIN2 AS58807 精品 ★ 「移動版 CN2 GIA」,晚高峰更穩,更貴。注意:「移動優化」≠ CMIN2,看 ASN!
線路與連線品質測試(雙向完整版)
🖥 去程(Client → Server)
你的電腦執行。測試你連到 VPS 的路徑、延遲、丟包率。
🌐 回程(Server → Client)
SSH 進 VPS 後執行。商家宣稱的線路優化通常指這個方向。
Step 1 — 安裝工具(在 VPS 上)
apt update && apt install -y mtr-tiny traceroute iputils-ping curl # CentOS / Rocky yum install -y mtr traceroute bind-utils curl
Step 2 — 確認 VPS 出口 IP(在 VPS 上)
curl ip.sb # 顯示出口 IP curl ip-api.com/json # IP + 國家 + 城市 + ASN(詳細) curl https://ipinfo.io # 另一個來源 curl -6 ip.sb # 確認 IPv6 出口(若有)
Step 3 — 回程測試(SSH 進 VPS 執行)
mtr -rwzbc 100 223.5.5.5 # → 電信(阿里 DNS,AS4134) mtr -rwzbc 100 114.114.114.114 # → 聯通(114 DNS,AS4837) mtr -rwzbc 100 180.76.76.76 # → 移動(百度 DNS,AS58461) mtr -rwzbc 100 -6 2400:3200::1 # → IPv6 方向 # 參數說明 # -r 報告模式(跑完輸出一次,不即時滾動) # -w 寬格式(顯示完整 hostname,不截斷) # -z 顯示 ASN ← 最關鍵,用來判斷走哪條線路 # -b 同時顯示 IP 和 hostname # -c 取樣次數(100 次比 10 次更準確)
看到的 IP 段 ASN 代表線路
202.97.x.x AS4134 電信普通 163(晚高峰易堵)
59.43.x.x AS4809 電信 CN2(GT 或 GIA)
219.158.x.x AS4837 聯通普通骨幹
AS9929 聯通精品線路
AS58453 移動 CMI
AS58807 移動 CMIN2(精品)
221.183.x.x 移動進入國內後的常見段
⚠️ 中間節點顯示 50–100% 丟包,不代表真實丟包——很多路由節點限制 ICMP 回應。只看最後一跳:0% 丟包 + 延遲穩定 = 實際通信正常。
Step 4 — 去程測試(在你的電腦執行)
# macOS / Linux ping -c 20 <VPS-IP> # 延遲 + 丟包率 traceroute <VPS-IP> # 路由追蹤(靜態版,一次性輸出) mtr -rwzbc 50 <VPS-IP> # 進階路由追蹤(需先 brew install mtr) nc -zv <VPS-IP> 443 # 測試 443 port 是否可連 # Windows(CMD / PowerShell) ping -n 20 <VPS-IP> tracert <VPS-IP> Test-NetConnection -ComputerName <VPS-IP> -Port 443
網頁工具(無需安裝)
工具 用途
ping.pe 從全球多點同時 ping 你的 VPS IP,直接看各地延遲分佈
tools.ipip.net/traceroute 從中國大陸三大運營商節點 traceroute 到你的 IP(去程最直觀)
ipqualityscore.com IP 信譽:Fraud Score、是否被標記為 Proxy / Hosting
scamalytics.com 詐騙風險評分
ipinfo.io/<IP> ASN、組織名稱、地區
常用指令速查
# ── 在 VPS 上執行(回程)── curl ip.sb curl ip-api.com/json mtr -rwzbc 100 223.5.5.5 # 電信 mtr -rwzbc 100 114.114.114.114 # 聯通 mtr -rwzbc 100 180.76.76.76 # 移動 mtr -rwzbc 100 -6 2400:3200::1 # IPv6 ping6 2400:3200::1 # IPv6 連通測試 # ── 在你的電腦執行(去程)── ping -c 20 <VPS-IP> # macOS/Linux ping -n 20 <VPS-IP> # Windows traceroute <VPS-IP> # macOS/Linux tracert <VPS-IP> # Windows mtr -rwzbc 50 <VPS-IP> # macOS/Linux(需安裝) nc -zv <VPS-IP> 443 # 測試端口(macOS/Linux) Test-NetConnection <VPS-IP> -Port 443 # 測試端口(Windows)
地區選擇指南
🇭🇰
香港
✓ 離大陸最近,延遲最低
✓ 華南用戶天然優勢
✓ CN2 GIA / CMIN2 / AS9929 等精品線路選項多
✗ 機房 IP 信譽問題嚴重
✗ 帳號/支付/AI/廣告平台對 HK 流量謹慎
要速度 → 香港仍很強;要帳號/支付/流媒體 → 謹慎,先測 IP 信譽
🇯🇵
日本
✓ 亞洲均衡節點,比香港便宜
✓ 延遲通常比美西低
✓ 聯通/移動用戶性價比好
✗ 部分 NTT 晚高峰繞路或擁塞
選購看線路:優先軟銀、IIJ、CMI、CMIN2 或 AS9929
🇺🇸
美西
✓ 便宜大碗,帶寬大 IP 多
✓ 美國流媒體最友好
✓ 建站/下載/開發測試常見
✗ 物理距離大,延遲高於香港/日本
電信→CN2 GIA;聯通→AS9929/4837;移動→CMI/CMIN2
🇸🇬
新加坡
✓ 東南亞核心節點
✓ 用戶在東南亞時首選
✗ 主要用戶在大陸時,延遲高於香港/日本
東南亞業務優先;中國大陸主用戶不推薦
🇪🇺
歐洲
✓ 隱私合規、歐洲業務
✓ 便宜大硬碟大帶寬
✗ 大陸用戶延遲極高
✗ 遠端桌面/遊戲/中轉明顯慢
適合歐洲業務、備份、大資源;不適合大陸低延遲
IP 類型
機房 IP(Datacenter)
費用便宜
穩定性
平台友好度低 ✗
適合用途建站、開發部署、翻牆
易被識別為服務器/代理,部分平台限制登入、支付、流媒體播放。
住宅 IP(Residential)
費用昂貴
穩定性
平台友好度高(理論上)
適合用途帳號、支付、風控敏感場景
⚠️ 市場水深:很多「住宅 IP」其實是機房 IP,或來源不透明的代理池,IP 跳動頻繁易觸發風控。
ISP IP(靜態住宅)
費用中等
穩定性較高
平台友好度中偏高
適合用途折衷方案
兼顧住宅 ASN 識別優勢 + 機房穩定性。但部分商家靠 ASN/資料庫標籤包裝,真實性需驗證。
購買前 IP 信譽核查清單
  • ASN 是運營商或真實 ISP(非機房 ASN)
  • GeoIP 國家和城市是否穩定(用 ip-api.com / ipinfo.io 確認)
  • IPQSScamalytics 的 Fraud Score 是否低
  • 是否被標記為:Proxy / VPN / Hosting / Tor / Crawler
  • 用你的目標平台實測(評分工具只能參考,不能代表真實結果)
住宅 IP ≠ 乾淨 IP,ISP IP ≠ 免風控。真正有價值的是:來源透明、ASN 合理、位置穩定、歷史乾淨。
IP 信譽 × 協議特徵
好 IP 要配合低特徵協議,否則再貴的 IP 也很快被識別浪費
高價住宅 IP × 流量特徵明顯的舊協議(VMess、Shadowsocks) ↓ 平台識別 → 加入黑名單 → IP 迅速失去價值 高價住宅 IP × 低特徵協議(VLESS + Reality + Vision / XHTTP) ↓ 流量接近正常 HTTPS → 識別概率低 → 延長使用壽命
快速選購公式
電信用戶 CN2 GIA 優先 香港 / 日本 / 美西,務必測回程
聯通用戶 AS9929 優先 其次 AS4837;日本/美西性價比不錯
移動用戶 CMIN2 優先 其次 CMI;香港/日本/新加坡/美西都值得測
三網混合 三網優化 BGP 或分別買不同線路做分流
靜態建站 CDN 優先 源站放便宜美西/歐洲/日本,不必買貴線路
流媒體 地區 + IP 信譽優先 線路只是體驗加分項,今天能解鎖 ≠ 下個月還能
帳號/支付/AI 不迷信香港 考慮乾淨住宅/ISP IP,或更符合業務地區的美/日/新
資料來源: 买 VPS 避坑指南:选错线路卡到哭!三大运营商怎么选?住宅 IP 真的更好吗?
三種部署方式比較
住宅 IP 自架 自架 VPS ★推薦 機場(訂閱)
IP 類型 家用住宅 IP 機房 IP 機房 IP 為主
月費 無額外費用 $5–30 USD/月 ¥30–200+/月
技術門檻
控制權 完整 完整
隱私 最高 最低
IP 被封風險 極低(住宅 IP) 低至中(依地區) 中(共享節點)
穩定性 依家庭寬頻 穩定 依機場品質
住宅 IP 自架
在自家機器跑 Xray
IP 最乾淨,但需處理 DDNS 與 NAT
注意事項
動態 IP需搭配 DDNS(如 Cloudflare DDNS)自動更新域名
NAT / 端口轉發需在路由器設定;部分 ISP 有 CGNAT,無法對外開放
上行頻寬家用上行通常 10–30 Mbps,多人同用易成瓶頸
隱私風險你的真實住家 IP 直接暴露給所有使用者
穩定性需要機器 24 小時開機;停電或斷網即中斷
適合誰
技術能力強、已有長期開機設備(NAS 等)、只供少數親近朋友使用。
機場(訂閱式)
購買他人架設的節點訂閱
零技術門檻,但隱私與控制權全交給服務商
主要注意事項
隱私風險最高機場商可看到你所有翻牆流量與 DNS 查詢
跑路風險小機場可能隨時關閉;建議按月付費,避免預付長期
訂閱連結外洩連結洩漏後別人可蹭用你的流量額度
晚高峰品質節點被大量用戶共享,便宜機場尤其明顯
無法自訂協議、線路、節點完全由機場商決定
選機場建議
✓ 優先選按月付費 + 有退款政策的服務商
✓ 先試用,再決定是否長期訂閱
✗ 避開過度便宜的(靠過度售賣撐)
✗ 不要把重要帳號登入走機場流量
✗ 不要把訂閱連結公開分享
適合誰
完全不想碰技術的朋友自用;非你幫他們架設的場景。
怎麼選?
你幫朋友架 自架 VPS + 3x-ui 台灣 VPS 首選,IP 被封風險低
自己用、家有 NAS 住宅 IP 自架 需搞定 DDNS + NAT,上行注意頻寬
朋友自己搞定 推薦他買機場 按月付費、可隨時換,選有口碑的服務商
自架的成本是「你的時間與維護精力」,機場的成本是「你對服務商的信任」。兩者各有取捨,不存在絕對最優解。
整體架構:流量路徑
Chrome 輸入網址
    ↓
ZeroOmega 攔截(判斷走代理或直連)
    ↓
SOCKS5 送到本機 127.0.0.1:10808
    ↓
v2rayN 接收,VLESS + Reality 打包加密
    ↓
偽裝成正常 HTTPS 流量送到 VPN Server(port 443)
    ↓
Server 端 Xray 解密,轉發到目標網站
洩漏風險評估
風險類型 洩漏內容 處理方式 狀態
IPv6 DNS 洩漏 你查詢的域名 停用 IPv6 ✅ 消除
QUIC/UDP 洩漏 連線目標 IP 和域名 停用 QUIC ✅ 消除
WebRTC 洩漏 本機真實 IP Chrome flags ✅ 消除
Chrome 內建 DoH 你查詢的域名 關閉安全 DNS ✅ 消除
系統其他軟體 其他 App 流量 刻意不處理(設計取捨) ⚠️ 範圍外
TUN 模式缺失 UDP 全局流量 刻意不開(避免留痕) ⚠️ 設計取捨
Step 0
Windows 11 全新安裝
最推薦的起點,從根本排除預裝監控軟體
確認授權PowerShell 執行 slmgr /xpr,確認為數位授權(OEM 自動啟用)
本機帳號安裝時選「離線帳戶」,不要在中國境內登入微軟帳號
驅動程式從硬體製造商官網(Intel/AMD/NVIDIA)下載,不要用品牌整包
前置準備
網路加固
停用 IPv6,清除監控軟體
清除監控軟體解除安裝電腦管家、360、品牌助手等;全新安裝者可跳過
停用 IPv6設定 → 網路 → 介面卡選項 → 取消勾選「IPv6」
Step 1
安裝並設定 v2rayN
本機代理核心,不開 TUN,清除系統代理
下載由管理員提前下載 v2rayN-windows-64.zip 傳送(GitHub 在中國可能無法訪問)
匯入節點伺服器 → 掃描螢幕上的 QR Code → 右鍵設為活動伺服器
系統代理選「清除系統代理」,不開 TUN 模式
路由設定選 V4-绕过大陆(Whitelist),中國網站直連
確認狀態狀態列顯示「本地:[mixed:10808]」
Step 2
安裝純淨版 Chrome
從官方管道下載,關閉遙測和安全 DNS
下載管理員在台灣下載離線版(google.com/chrome?standalone=1&platform=win64)
關閉遙測設定 → 隱私權 → 關閉「協助改善 Chrome」和「回報診斷資訊」
關閉安全 DNS設定 → 隱私權 → 安全性 → 使用安全 DNS → 關閉
Step 3
安裝 ZeroOmega
SwitchyOmega 3,控制 Chrome 流量出口
離線安裝管理員提供 .crx → chrome://extensions/ → 開啟開發人員模式 → 拖曳安裝
新建 VLESS_ProxySOCKS5 / 127.0.0.1 / 10808
新建 Auto_Switch規則網址填 gfwlist.txt URL,情境模式選 VLESS_Proxy,預設直連
日常模式使用 Auto_Switch,中國網站自動直連,境外自動走代理
💡 更新規則前先切到 VLESS_Proxy 模式,建議每月更新一次 gfwlist
Step 4
防止 WebRTC 洩漏
Chrome flags 內建方案,無需安裝額外擴充功能
Chrome flagschrome://flags/#enable-webrtc-hide-local-ips-with-mdns → 設為 Enabled → Relaunch
無痕模式ZeroOmega 需要在 Extensions → 詳細資料 → 開啟「允許在無痕模式中執行」
驗證browserleaks.com/webrtc,Local IP 應為空或 .local 結尾
Step 5
停用 QUIC 協議
防止 UDP 流量繞過 ZeroOmega
Chrome flagschrome://flags/#enable-quic → Experimental QUIC protocol → Disabled → Relaunch
影響Chrome 自動退回 TCP,速度影響幾乎感覺不到
Step 6
驗證連線安全
設定完成後依序執行四項測試
IP 改變ip.sb — Chrome 顯示台灣 IP,Edge 顯示中國 IP,結果不同 ✅
DNS 無洩漏dnsleaktest.com → Extended Test — 只出現 Cloudflare / Google DNS ✅
WebRTC 無洩漏browserleaks.com/webrtc — Local IP 不顯示 192.168.x.x 或 10.x.x.x ✅
Discord 語音discord.com/app — 能正常加入語音頻道通話 ✅
日常使用注意事項
瀏覽器分工
Edge微信網頁版、微博、bilibili 等中國網站
Chrome + ZeroOmegaYouTube、Discord、Instagram 等境外網站
低調原則
✗ 不在微博/微信/抖音提到 VPN、節點、代理
✗ 不截圖分享連線設定或這份教學
✗ 不在直播中露出代理相關軟體或設定
✗ 不把連線資訊告訴不信任的人
常見問題排解
問題 排查步驟
連線後 IP 沒有改變 確認 ZeroOmega 模式正確;確認 v2rayN 在背景執行;重啟 v2rayN
網頁完全開不了 確認節點 UUID、PublicKey、ShortId;確認 SOCKS5 連接埠為 10808;聯繫管理員
REALITY 連線失敗 / 斷連 確認 ShortId 與伺服器端一致;確認 UUID 已授權;IP 被封請聯繫管理員
Discord 卡在 RTC 連線中 確認 ZeroOmega 使用 SOCKS5(非 HTTP);確認 v2rayN 路由含 UDP 流量
Auto_Switch 規則無法更新 先切到 VLESS_Proxy 模式再更新,更新完切回 Auto_Switch
速度很慢 YouTube 建議 720p 以下;避開晚上 8-11 點;聯繫管理員確認伺服器狀態
名詞 類型 說明
系統定位

中國戶外長時間直播系統。透過多張 SIM 卡頻寬合併(MPTCP Bonding)+ OpenMPTCProuter + Xray VLESS+Reality, 將 LiveU Solo 的 RTMP 流量安全穿越 GFW,傳回台灣後由 OBS 推流至 Twitch。

避免
從中國直推 Twitch(GFW 封鎖)
依賴 LiveU 日本 AWS 中轉
達成
多卡頻寬合併降低波動
完整本地 OBS 控制權
定位
低成本 DIY contribution uplink
非廣播級,非商業替代品
中國端出境方案(三選一)
本文件 Section 3–21 的技術細節主要對應本方案。完全自架,VPS 費用為主要持續成本。
RPi5(本地 SIM × 3,MPTCP bonding)
  → VLESS+Reality+Vision tunnel
  → 台灣 VPS 或本機 → OBS → Twitch
一次性費用
5,600
~8,700 NTD
RPi5 + Modems + 周邊
每月費用
1,400
~4,000 NTD
VPS + 中國 SIM × 3
一年總持有成本
22,400
~56,700 NTD
推薦:偶爾赴中直播
三方案綜合比較
評估項目方案一:SIM + Reality方案二:翻牆 SIM + LRT方案三:租屋 + Xray
GFW 穿透強度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
穩定性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
自主掌控✅ 完全自主❌ 依賴第三方✅ 完全自主
戶外直播⚠️ RPi5 需先連回租屋
IP 被封風險⚠️ VPS 機房 IP低(商業維護)極低(住宅 IP)
延遲高(繞日本 AWS)
台灣端 ingest 路線(兩選一)
路線 A 台灣本機 ingest
台灣需有公網 IPv4必須有
Router Port Forward必須可以
月費低(無 VPS 費)
回程路由掌控
單點故障風險家裡斷網即中斷
路線 B VPS ingest(香港 / 日本)
台灣需有公網 IPv4不需要
Router Port Forward不需要
月費+VPS USD 15–40
回程路由掌控中(依 VPS 供應商)
單點故障風險家裡斷網不影響 ingest
判斷是否有公網 IP:在台灣 Linux 機執行 curl ifconfig.me,與 Router WAN 介面 IP 比對。若相同 → 路線 A 可行;若不同或 WAN IP 是 100.64.x.x → 必須選路線 B 或向 ISP 申請固定 IP。
系統限制與風險
限制項目說明
RTMP over TCPTCP 確認機制在高 packet loss 時會放大 latency
無硬體 FEC無法像 LiveU 高階機種做封包層級的數學修復
TCP in TCPMPTCP 內包 Reality TCP,極端惡劣環境有 HOL blocking 風險
住宅 ISP upstream台灣家裡上行 jitter 無法完全消除(路線 A)
USB Modem高溫與供電不穩是最常見的中斷原因
OMR 非 enterprise-grade適合個人規模,不適合商業廣播
路線 A:台灣本機 ingest
資料流(路線 A)
Sony FX30
HDMI 輸出
↓ HDMI
LiveU Solo
RTMP Direct 模式,WiFi 連接 RPi5 的 AP
↓ WiFi
Raspberry Pi 5(中國現場)
OpenMPTCProuter v0.63 · MPTCP Bonding
WAN1 中國電信 / WAN2 中國聯通 / WAN3 中國移動
Xray VLESS+Reality 隧道 · MSS Clamp
↓ MPTCP + VLESS+Reality(TCP 443,偽裝 HTTPS)
      GFW 只看到 TLS 流量,順利放行
台灣 Linux 本機(ingest server)
omr-server(Bonding 接收端)· xray(VLESS+Reality 解密)
mediamtx(RTMP ingest + Auth)· CAKE QoS
↓ RTMP 內網(含 auth)
Windows OBS Studio
Media Source + 場景覆蓋 + Alert
↓ RTMP
Twitch
路線 B:VPS ingest
資料流(路線 B)
中國現場
與路線 A 相同:FX30 → LiveU → RPi5 + OMR + Reality
↓ MPTCP + VLESS+Reality → GFW
香港 / 日本 VPS(建議 CN2 GIA 優化線路)
1 vCPU / 1GB RAM 即足 · omr-server · xray · mediamtx
VPS 直接有公網 IP,不需 port forwarding
↓ RTMP 公網(有 Auth,建議 IP 白名單)
台灣 Windows OBS
Media Source 拉取 VPS 上的 RTMP 串流
↓ RTMP
Twitch
資料流區段對照
區段路線 A路線 B
LiveU → RPi5WiFi / LANWiFi / LAN
RPi5 → ingest serverMPTCP + Reality → 台灣本機MPTCP + Reality → 香港/日本 VPS
ingest server → OBS內網 RTMP公網 RTMP(需 auth)
OBS → TwitchRTMPRTMP
協議選型說明
為什麼用 RTMP Direct
協議支援備註
RTMP Direct✅ 支援唯一可直連自架 server 的選項
RTMPS Direct⚠️ 部分版本建議開啟(若支援)
SRT Direct❌ 不支援SRT 必須先走 LRT → LiveU 日本 AWS
RIST / Zixi❌ 不支援
MPTCP + Reality 補強 RTMP
RTMP 弱點OMR + Reality 補強方式
無 multipathMPTCP 將封包拆分至多條 WAN 並行傳輸
無 GFW 偽裝VLESS+Reality 完美偽裝成 TLS 1.3 商業流量
無 FECMPTCP 多路備援降低單點重傳代價
單卡波動多卡互補,單卡掉包不影響整體 session
中國端硬體(隨身攜帶)
Raspberry Pi 5
4GB RAM · USB-C PD 行動電源供電
跑 OpenMPTCProuter,接 USB Modem × 3
約 NTD 2,500
USB Modem × 3
Huawei E3372h-153 或 Quectel EC21
各插一張 SIM
⚠️ 強烈建議改成 Stick Mode(見深度說明)
NTD 600–1,200 / 支
獨立供電 USB Hub
7-port,支援 USB-C PD 輸入
避免 RPi5 主板電壓瞬降
NTD 400–800
行動電源
USB-C PD 65W 以上
RPi5 + Hub 同時供電
NTD 800–1,500
microSD
32GB A2 Class 10
安裝 OpenMPTCProuter(squashFS)
NTD 200–400
散熱套件
銅散熱片 + 小風扇
防 modem 過熱斷線
NTD 100–300
SIM 插在 USB Modem 內,不是插在 RPi5 上。RPi5 本身沒有 SIM 卡槽。
台灣端 / VPS 端
設備路線 A(本機)路線 B(VPS)
ingest server台灣 Linux 本機(x86_64,Ubuntu 22.04 / Debian 12,2GB RAM+)香港或日本 VPS(1 vCPU / 1GB RAM,建議 CN2 GIA 線路)
OBS 主機Windows 11,有獨顯同左
路由器支援 port forwarding不需要特殊設定
軟體清單
軟體安裝位置用途
OpenMPTCProuter v0.63RPi5(刷入 microSD)MPTCP Bonding 客戶端
omr-serverLinux ingest serverBonding 接收端
xray-coreLinux ingest server(omr-server 腳本內含)VLESS+Reality server
mediamtx v1.9.xLinux ingest serverRTMP ingest + auth
OBS StudioWindows 本機場景覆蓋、推 Twitch
NetdataLinux ingest server(建議)即時鏈路品質監控
費用總覽
硬體一次性
5,800
~9,100 NTD
(RPi5 + Modems + 周邊)
路線 A 每月
NT$0
ingest(自家機器)
+ 中國 SIM 流量費
路線 B 每月
USD 15–40
VPS 費
+ 中國 SIM 流量費
中國三大電信商跨境線路品質(中國 → 台灣)
電信商骨幹線路連台灣品質部署定位
中國電信CN2 GIA最穩定,延遲最低主力
中國聯通169 骨幹次穩定,頻寬彈性好次選
中國移動CMI 國際尖峰時段易壅塞,容易被 QoS僅作備援
前置條件:OS Ubuntu 22.04 / Debian 12 · 有真正公網 IPv4(非 CGNAT)· Router 可做 port forwarding · Linux 機在區域網路有固定 IP
1
安裝 omr-server
安裝完成後取得 server key(RPi5 端設定時需要)。
wget -O - https://www.openmptcprouter.com/server/omr-6-install.sh | sh

# 取得 server key
cat /root/openmptcprouter_config.txt

# 確認服務狀態
systemctl status omr-server
systemctl status xray
2
細調 xray VLESS+Reality(/etc/xray/config.json)
關鍵參數:flow: xtls-rprx-vision(必填,消除內層 TLS 特徵)· fingerprint: chrome · dest 選知名國際站點(不同省份最佳 dest 不同,需實測)
{
  "inbounds": [{
    "port": 443, "protocol": "vless",
    "settings": {
      "clients": [{ "id": "用 uuidgen 產生的 UUID", "flow": "xtls-rprx-vision" }],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp", "security": "reality",
      "realitySettings": {
        "dest": "www.microsoft.com:443",
        "serverNames": ["www.microsoft.com"],
        "privateKey": "用 xray x25519 產生的私鑰",
        "shortIds": ["用 openssl rand -hex 4 產生"],
        "fingerprint": "chrome"
      }
    }
  }]
}
systemctl restart xray
3
安裝 mediamtx 並設定 Auth(必做)
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(publish 和 read 用不同帳密):
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
連線 URL:
LiveU 推流:rtmp://liveu:密碼@你的公網IP/live/liveu
OBS 拉流(路線 A):rtmp://obs:密碼@Linux機內網IP/live/liveu
# systemd 服務
cat > /etc/systemd/system/mediamtx.service << 'EOF'
[Unit]
Description=mediamtx
After=network.target
[Service]
ExecStart=/usr/local/bin/mediamtx /etc/mediamtx.yml
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable mediamtx
systemctl start mediamtx
4
套用 CAKE QoS(防 bufferbloat)
OBS 推 Twitch 和 omr-server 接收串流同時佔用台灣端上行,沒有 QoS 時兩者互搶,導致 MPTCP ACK 封包延遲,LiveU 誤判鏈路惡化而降碼率。
# 查看網卡名稱
ip link show

# 套用 CAKE(90000kbit = 家裡上傳 100Mbps 的 90%,請依實際頻寬調整)
sudo tc qdisc replace dev eth0 root cake bandwidth 90000kbit \
  diffserv4 dual-srchost nat wash no-ack-filter split-gso rtt 50ms

# 確認套用(出現 cake 字樣即成功)
tc qdisc show dev eth0
5
設定 MSS Clamp(核心優化)
本系統是 RTMP inside Reality inside MPTCP 多層封裝,建議直接寫死 MSS 1360(= tunnel MTU 1400 − IP header 20 − TCP header 20),不用動態 --clamp-mss-to-pmtu(依賴 ICMP,跨境常被過濾)。
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

# 確認規則生效(封包計數應 > 0 後才算生效)
sudo iptables -t mangle -L FORWARD -v | grep TCPMSS
若計數始終為 0,代表規則順序被其他規則覆蓋,需刪掉重新以 -I FORWARD 1 插到最前面。
6
systemd 自動重啟
# xray
sudo systemctl edit xray
# 填入:
[Service]
Restart=always
RestartSec=5

# omr-server
sudo systemctl edit omr-server
# 填入:
[Service]
Restart=always
RestartSec=10

sudo systemctl daemon-reload
7
防火牆設定(UFW)
sudo ufw allow 443/tcp          # xray VLESS+Reality
sudo ufw allow 1935/tcp         # mediamtx RTMP
sudo ufw allow 8554/tcp         # mediamtx RTSP(備用)
sudo ufw allow 65001/udp        # omr-server Glorytun
sudo ufw allow 65101/tcp        # omr-server Shadowsocks
sudo ufw allow 65101/udp
sudo ufw allow 65201:65208/udp  # omr-server MLVPN
sudo ufw allow 65500/tcp        # omr-server 管理 API
sudo ufw enable && sudo ufw reload
8
安裝 Netdata 監控(建議)
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh
# 安裝後:http://Linux機內網IP:19999
直播時重點觀察:IPv4 TCP Retransmission(飆高 = SIM 鏈路惡化)· Network Interface Bandwidth(確認多卡帶寬有疊加效果)· CPU / Memory
VPS 上的安裝與路線 A 完全相同(omr-server、xray、mediamtx、MSS clamp、systemd),差異只有以下三點。
1
VPS 選購建議
地點:香港 or 日本(對台灣和中國回程都相對友好)· 線路:盡量選有 CN2 GIA 或 CMI 優化的方案 · 規格:1 vCPU / 1GB RAM,頻寬 ≥ 20Mbps · OS:Ubuntu 22.04 / Debian 12
2
路線 A 的設定步驟 1–8 全部執行
VPS 直接有公網 IP,不需要在路由器設定 port forwarding。ufw 指令相同。
3
限制 mediamtx 只允許台灣 OBS IP 存取
# 只允許台灣 OBS 主機的固定 IP
sudo ufw allow from 你的台灣固定IP to any port 1935
若台灣 IP 是動態的,至少確保 mediamtx auth 密碼夠強,並考慮安裝 fail2ban。OBS URL 填入 VPS 公網 IP,格式:rtmp://obs:密碼@VPS公網IP/live/liveu
在台灣先完成所有設定,確認無誤後再帶去中國。
1
燒錄 OpenMPTCProuter(squashFS)
下載地址:https://releases.openmptcprouter.com/v0.63-6.12/rpi5/targets/bcm27xx/bcm2712/
選擇 rpi-5-squashfs-factory.img.gz,用 Balena Etcher 燒錄到 microSD。
選 squashFS 而非 ext4:squashFS 為唯讀根目錄系統,戶外突然斷電不會損毀;ext4 斷電後容易無法開機。
2
初次設定(瀏覽器進入管理介面)
網路線連電腦到 RPi5 的 LAN 口,開啟瀏覽器:http://192.168.100.1(用 http,不是 https)
初始帳號 root,密碼為空,立即設定強密碼
3
設定 VPN 協議
System → OpenMPTCProuter → Settings Wizard
填入:Server IP(台灣 Linux 機或 VPS 的公網 IP)· Server Key(從 /root/openmptcprouter_config.txt 取得)· VPN 協議選 Xray(VLESS+Reality)
→ Save and Apply
4
新增 WAN 介面(Stick Mode:eth1、eth2、eth3)
Network → Interfaces → 下拉選 eth1 → Add an interface,重複新增 eth2、eth3 → Save and Apply。確認三個介面都顯示 Connected。
5
關閉 USB Autosuspend(必做)
Linux 預設讓閒置 USB 裝置進入省電休眠。Modem 睡著後不會自動醒,bonding 靜默減少一條線,且 log 無明顯錯誤。
ssh root@192.168.100.1

# 方法一:kernel 參數(永久有效,推薦)
echo 'usbcore.autosuspend=-1' >> /etc/cmdline.d/usb.conf
reboot

# 確認(應顯示 -1)
cat /sys/module/usbcore/parameters/autosuspend
6
RPi5 端 MSS Clamp
# 立即生效
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360

# 持久化(OpenWrt/OMR 的方式)
echo 'iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360' \
  >> /etc/firewall.user
7
LiveU Solo 設定
LiveU Solo 用 WiFi 連接 RPi5 的 AP。在 LiveU Solo Portal 設定:
推流模式:RTMP Direct · 目的地 URL:rtmp://liveu:密碼@你的公網IP/live/liveu
平時把 LRT 設定也存在 Portal,不要刪掉。緊急時一鍵切換備援。
8
USB Modem Watchdog(RPi5 端)
當 modem 假死時,直接 power cycle USB port。注意:usbreset 指令在 OpenMPTCProuter 環境上不是預裝指令,需用 sysfs authorized 節點。執行前先用 lsusb -t 確認設備路徑。
# 先確認設備路徑
lsusb -t

cat > /root/modem_watchdog.sh << 'EOF'
#!/bin/sh
# 將 USB_PATH 替換為 lsusb -t 確認的實際路徑
if ! ip link show eth1 | grep -q "LOWER_UP"; then
    logger "[watchdog] eth1 down, power cycling USB"
    USB_PATH="/sys/bus/usb/devices/1-1"
    echo 0 > "${USB_PATH}/authorized"
    sleep 3
    echo 1 > "${USB_PATH}/authorized"
    sleep 10
fi
EOF
chmod +x /root/modem_watchdog.sh

# crontab 每分鐘執行一次
(crontab -l 2>/dev/null; echo "* * * * * /root/modem_watchdog.sh") | crontab -
Media Source 設定
1
新增媒體來源
OBS → 來源 → 新增 → 媒體來源 → 取消勾選「本機檔案」
填入 URL:
· 路線 A:rtmp://obs:密碼@192.168.x.x/live/liveu
· 路線 B:rtmp://obs:密碼@VPS公網IP/live/liveu
不要勾選 Ultra Low Latency:中國 uplink 的 jitter 是常態,需要 buffer。Network Buffering 建議設 1–5 MB(設 0 畫面容易卡頓;設超過 10 MB 會累積明顯延遲)。
推流設定(OBS → Twitch)
設定項目建議值說明
編碼器NVENC H.264有獨顯時用 NVENC,釋放 CPU 給 overlay 運算;否則用 x264
碼率控制CBR固定碼率讓 bonding 流量可預測,避免複雜場景突衝擊穿頻寬
目標碼率6000–8000 kbps依出發前實測的穩定最低聚合頻寬決定
關鍵影格間隔2 秒(固定)Twitch 要求
B-frames0降低 encoder 內部緩衝延遲
Profilehigh
Tunezerolatency
USB Modem:Stick Mode vs HiLink Mode
這是實戰中最常踩的坑。HiLink Mode 出廠預設,必須切換到 Stick Mode 才能讓 MPTCP 正常運作。
模式說明對 bonding 的影響
HiLink Mode(出廠預設)Modem 自帶 Web UI(192.168.8.1),內建 DHCP,對系統表現為一台小路由器多一層 NAT,三張卡預設同一網段會路由衝突,MPTCP 路徑偵測受干擾
Stick Mode(推薦)Modem 對系統表現為純網卡(NDIS/CDC-ECM),RPi5 直接取得電信商 IPMPTCP 正常運作,無多餘 NAT
Huawei E3372h 切換方法
出發前在台灣操作,確認可用後再帶去中國。
方法一:AT 指令(若設備開放 COM port)
# 1. 插入 Windows,裝置管理員確認出現 COM port
# 2. PuTTY / Tera Term 連接(鮑率 115200)
# 3. 輸入 AT 指令(適用部分韌體版本)
AT^SETPORT="A1,A1"
# 重啟 Modem,不再出現 192.168.8.1 Web UI 即成功
方法二:刷韌體

E3372h-153(HiLink 版本)與 E3372s(Stick 版本)的韌體不同,可嘗試刷入 E3372s 固件。操作步驟依批次版本不同差異大,建議搜尋你手上具體的 IMEI 前幾碼確認批次,再找對應的刷機教學。

HiLink Mode 補救方案(若無法切換)

三張卡必須手動改為不同網段:Modem A 保持 192.168.8.1 → Modem B 改為 192.168.9.1 → Modem C 改為 192.168.10.1。改完後三張卡才能同時插在 RPi5 上不衝突。HiLink 補救方案仍有多層 NAT,Stick Mode 才是正確做法。

MTU / MSS / Bufferbloat 深度說明
本系統的封包結構(每層封裝都消耗 header 空間):
RTMP(TCP)
  ↳ 包在 VLESS+Reality(TCP + TLS overhead,約 60 bytes)
      ↳ 包在 MPTCP(subflow header,約 20 bytes)
          ↳ 傳出實體網路(Ethernet MTU 1500 bytes)
若內層 TCP 的 MSS 沒有向下調整,加上外層 header 後會超過 1500 bytes,導致靜默分片、PMTU Blackhole(ICMP 被過濾導致 PMTU Discovery 失效)、重傳率暴增、OBS 畫面卡頓。
計算步驟數值
設定 tunnel 介面 MTU1400 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 常被過濾,PMTUD 會靜默失效。直接寫死 1360 是更可靠的做法。
Bufferbloat 與 CAKE

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

Port Forwarding / CGNAT / DDNS
# CGNAT 確認
curl ifconfig.me
# 與 Router WAN 介面顯示的 IP 比較:相同 → 路線 A 可行;不同 → 選路線 B
Router Port Forwarding(路線 A 專用)
Port協議用途
443TCPxray VLESS+Reality
1935TCPmediamtx RTMP
8554TCPmediamtx RTSP(備用)
65001UDPomr-server Glorytun
65101TCP + UDPomr-server Shadowsocks
65201–65208UDPomr-server MLVPN
65500TCPomr-server 管理 API
DDNS 設定(若 IP 是動態的)
sudo apt install ddclient -y
# /etc/ddclient.conf:
protocol=noip
use=web, web=dynamicdns.park-your-domain.com/getip
login=你的帳號
password=你的密碼
你的hostname.ddns.net

sudo systemctl enable --now ddclient
中國環境 DNS 污染嚴重,建議同時保留 IP 直連方式,不要只依賴 DDNS domain。
散熱與供電
實戰中最常見的中斷原因不是 GFW,而是 USB Modem 過熱、Hub 供電不足、行動電源 PD 輸出不穩。
[ 行動電源 PD 65W+ ]
    │                  │
    ▼                  ▼
[ RPi5 主板 ]    [ 獨立供電 USB Hub ]
                    ├── Modem A(貼銅散熱片)
                    ├── Modem B(小風扇主動散熱)
                    └── Modem C(保持通風間距)
✅ 必做
• 三個 Modem 都要有散熱
• Hub 必須獨立供電
• Modem 之間保留通風間距
❌ 不建議
• 設備塞進密閉包包內運作
• 使用無 PD 協議的普通行動電源
過熱或供電不足的症狀:某條 WAN 介面突然消失,重新插拔 USB 後恢復 · dmesg 出現 over-current change 或 device disconnected · 無任何 tunnel 相關的 log 錯誤
在台灣模擬完整流程,出發前排除所有問題,不要到中國才發現。點擊項目可標記完成。
基本連線測試
  • 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:觀察整條 tunnel 的恢復時間
  • 重啟 mediamtx:觀察 OBS 的 Media Source 是否自動重連
  • 壓力測試
  • 持續推流 30 分鐘,觀察碼率穩定性
  • 摸 USB Modem 溫度,過燙需加散熱
  • 確認 CAKE 在運作:tc qdisc show dev eth0
  • 確認 MSS clamp 有封包計數:iptables -t mangle -L FORWARD -v | grep TCPMSS
若 LiveU 斷線後不會自動 reconnect,出發前必須制定手動重連的 SOP(例如準備好能開 Solo Portal 的手機),不能只靠自動恢復。
備援計畫
情況 Aingest server 掛掉
1.LiveU Solo Portal → 關閉 RTMP Direct
2.改回 LRT + RTMP 輸出 → 填 LiveU 雲端轉發設定
3.雖要過日本 AWS,但維持直播不中斷
平時把 LRT 設定保留在 Portal,不要刪掉。
情況 BRPi5 或 USB Modem 全數故障
1.LiveU 直接改用手機熱點
2.繼續用 RTMP Direct 單卡推流(無 bonding,但維持直播)
情況 CReality 被 GFW 封鎖
1.預先在 ingest server 裝好 Hysteria2 備用
2.在 OpenMPTCProuter 後台切換為 Hysteria2
bash <(curl -fsSL https://get.hy2.sh/)
不要只有單一隧道協議。
情況 D台灣 ISP 掛掉(路線 A)
短期啟用 4G 備援路由(若有備用 router)
中期臨時切換到路線 B(快速開一台 VPS)
情況 E方案一整體失效(VPS IP + Reality 同時被封)
1.換 VPS IP:同一供應商重新開機取得新 IP,或換節點
2.切換到 Hysteria2(參考情況 C)
3.切換到方案二(翻牆 SIM + LRT):準備一張備用翻牆 SIM,LiveU LRT 設定保留不刪
4.切換到方案三(租屋固定寬頻):若有中國據點,啟用備用 Windows PC Xray
建議至少保留方案二(翻牆 SIM + LRT)作為最終備援。發生重大直播當天突發封鎖時,翻牆 SIM 切換速度最快。
故障排查
症狀診斷指令說明
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
應顯示 -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);格式 rtmp://liveu:密碼@公網IP/live/liveu
OBS 拉不到串流 systemctl status mediamtx
http://Linux機IP:9997
確認 LiveU 正在推流(需要 publisher 存在 OBS 才能拉);OBS URL 格式需含 auth
推流碼率不穩 / jitter 高 tc qdisc show dev eth0
iptables -t mangle -L FORWARD -v | grep TCPMSS
systemctl status omr-server
確認 CAKE 套用;MSS clamp 封包計數若為 0 → 規則被覆蓋需重新插入
全域快速檢查 systemctl status omr-server xray mediamtx 三個服務都 active (running) 是基本前提
✅ 必做
  • mediamtx 設定 publish + read 分開的兩組帳密(不要用同一組)
  • xray 使用強密碼和隨機 UUID
  • 不在任何公開頻道洩漏 Stream Key、Reality 私鑰、mediamtx 密碼
💡 建議
  • 若 LiveU Solo 版本支援 RTMPS Direct,優先使用
  • 路線 B(VPS)的 mediamtx RTMP port 加 IP 白名單
  • 在 ingest server 安裝 fail2ban,自動封鎖暴力嘗試的 IP
  • 定期確認 journalctl -u mediamtx 裡沒有異常的 publish 嘗試
🚫 不要做
  • 裸露 mediamtx(無 auth)
  • 使用弱密碼或預設密碼
  • 公開 Reality 的 shortId 或私鑰
軟體版本資訊
軟體版本
OpenMPTCProuterv0.63(kernel 6.12,RPi5 squashFS image)
omr-serveromr-6-install.sh(對應 v0.63)
mediamtxv1.9.1
xray-core隨 omr-server 腳本安裝的最新穩定版
OBS Studio最新穩定版

文件版本:v7(2026 年 5 月整合版)。在 v6 基礎上新增出境方案比較(方案一/二/三)及跨方案備援切換邏輯。如有軟體版本更新,請以官方文件為準。