VPN 代理筆記

適用情境:在台灣架設伺服器,供中國朋友科學上網使用。本筆記涵蓋底層協議、引擎選型、VPS 線路測試,以及客戶端防洩漏的完整 SOP。

名詞分類與整體架構

架設之前,必須先釐清「協議、引擎、面板、客戶端」這四個名詞的層級關係和相互依賴。

協議(規格)
  • VLESS *
  • VLESS+Reality+Vision *
  • Hysteria2 **
  • Shadowsocks
  • WireGuard **
  • SoftEther
  • OpenVPN
引擎(實作)
  • Xray
  • Sing-box
  • Hysteria2 官方引擎
  • WireGuard 官方引擎
  • SoftEther 引擎
  • OpenVPN 官方引擎
面板(管理介面)
  • 3x-ui
  • s-ui
客戶端(使用者使用)
  • Shadowrocket(iOS)
  • v2rayN(Windows)
  • Hiddify(跨平台)
關鍵觀念:
* VLESS 沒有官方獨立引擎。VLESS 只能由 Xray 或 Sing-box 執行。
** Hysteria2 和 WireGuard 協議本身附帶官方引擎。Xray 和 Sing-box 也可以實作這兩個協議。
WireGuard 沒有流量混淆。因此 WireGuard 完全不適用於在中國科學上網。
SoftEther 和 OpenVPN 同樣缺少持續更新的混淆機制。2025-2026 年的實測顯示,GFW 已主動偵測並封鎖這兩個協議。因此不建議在中國科學上網時使用。

六大引擎比較

引擎是實際執行在伺服器或客戶端上的核心程式。引擎負責實作協議規格,並處理實際的流量傳輸。協議只是「規格書」。協議必須有引擎才能運作。

Xray

XTLS 團隊開發的伺服器端代理核心。VLESS+Reality 的最佳實作。

Sing-box

SagerNet 團隊開發的通用代理工具鏈。支援的協議最多。

Hysteria2 官方

apernet 開發。基於 QUIC。在弱網和高速推流時表現極佳。

WireGuard 官方

現代化 VPN。效能極佳,但沒有混淆。不適用於在中國科學上網。

SoftEther

筑波大學開發的多協議 VPN 閘道。曾經可以繞過 GFW。現在已被主動偵測並封鎖。

OpenVPN 官方

最老牌的 VPN 協議,生態最成熟。沒有混淆,不適用於在中國科學上網。

Xray

XTLS 團隊開發,專為抗審查設計的伺服器端代理核心。Xray 是 VLESS + Reality + Vision 的原創實作,也是最佳實作。

雷達圖評估
抗封鎖能力100%
社群資源100%
設定難度中
核心特色
  • 支援協議:VLESS、VMess、Trojan、Shadowsocks、Hysteria2、WireGuard 等
  • 成熟穩定,已廣泛使用多年。教學和問題排查資料最多
  • 通常透過 3x-ui 面板管理,不需要直接輸入指令
適合對象:架設科學上網伺服器給他人使用時的首選。

協議深度解析

協議定義流量如何封裝與傳輸。在中國科學上網的場景中,協議的「偽裝能力」和「抗封鎖能力」是首要考量。

協議 隱蔽性 偽裝度 速度 穩定性 適用場景
VLESS + Reality + Vision ★★★★★ ★★☆☆☆(握手層強) ★★★★★ ★★★★☆ 抗 DPI 直連 / 主力推薦
VLESS + gRPC + TLS ★★★☆☆ ★★★★☆ ★★★★☆ ★★★★★ 長時間穩定主線
VLESS + XHTTP + Reality ★★★★☆ ★★★★☆ ★★★★☆ ★★★★☆ Reality 與 WS 的折衷
Hysteria2 (QUIC) ★★★★☆ ★★★☆☆ ★★★★★ ★★★☆☆ 影音加速 / 弱網
SoftEther ★☆☆☆☆ ★★★☆☆ ★★★★☆ ★★★☆☆ 不建議在中國使用;用於企業或非審查地區的閘道
OpenVPN ★☆☆☆☆ ★☆☆☆☆ ★★★☆☆ ★★★★☆ 不建議在中國使用;路由器原生相容
WireGuard ★☆☆☆☆ ★☆☆☆☆ ★★★★★ ★★★★☆ 不建議在中國使用;用於非審查地區的私人 VPN
評星說明:Reality 的「偽裝度」評星,是指連線建立後的流量行為。Reality 最強的地方是握手層(TLS handshake)的偽裝。SoftEther、OpenVPN 和 WireGuard 的隱蔽性偏低,不是評測失誤。這是 2025-2026 年的實測共識:GFW 已經可以主動偵測並封鎖這三個協議。

VLESS

一種輕量、低開銷的代理協議。VLESS 是 VMess 的簡化改進版。

注意:單獨使用 VLESS 時,流量特徵明顯,容易被 GFW 識別。VLESS 必須搭配 Reality 使用。

VLESS + Reality + Vision(目前主流推薦)

這三個通常一起使用,各自扮演不同角色。這是目前抗封鎖能力最強的組合:

名稱 角色 功能
VLESS 協議本體 定義如何傳輸資料
Reality 偽裝技術 把流量偽裝成真實網站的 TLS 流量,讓 GFW 無法識別
Vision 流量優化 減少特徵,提升效能(XTLS 團隊設計的優化模式)

為什麼 VLESS + Reality + Vision 強?

  • GFW 看到的是「某個台灣 IP 連到 Google、Apple 等大網站的正常 HTTPS 流量」。GFW 完全無法把這種流量和真實流量區分開來。
  • 不需要購買網域,也不需要申請 SSL 憑證。
  • 沒有官方獨立引擎。必須使用 Xray 或 Sing-box 執行。
  • 適合情境:長期穩定的科學上網,以及觀看 YouTube / Twitch / Discord。

VLESS + gRPC + TLS

把 VLESS 包在 HTTP/2 multiplex tunnel 中。流量行為類似呼叫 API。

  • 優點:長時間連線最穩定,重連少,手機最省電。
  • 缺點:偽裝度中等(不像瀏覽網頁),延遲略高於 Reality 裸連。HTTP/2 流量樣式在行動網路的電信商深度封包檢測下,相對容易被識別或限流。
  • 適合情境:Discord 語音,以及長時間 RTMP 推流的「主線」。尤其是固定寬頻或 VPS 端(非手機 SIM 資料)。在這些情境中,gRPC 可以作為比 Reality 更穩定的主線來源。

VLESS + XHTTP + Reality

HTTP-like 行為包在 Reality 底層之上。VLESS + XHTTP + Reality 也針對「連線頻繁中斷後快速恢復」做了設計。

  • 優點:沿用 Reality 的握手層偽裝(信任基礎不變,只是換傳輸行為)。對頻繁斷線重連的環境,比 gRPC 或純 Reality 更寬容。底層仍是標準 TLS。對電信商的中間設備來說,流量接近一般瀏覽 HTTPS。
  • 缺點:成熟度和教學資源不如 Reality 或 gRPC 豐富。設定較複雜。關於設定細節(padding、mode 選擇)的問題回報較少。
  • 適合情境(手機 SIM 卡資料推流):基地台切換頻繁、需要抗斷線恢復時,可以考慮作為主線候選。XHTTP 與 gRPC 是「TCP 的兩個安全選項」,兩者二選一。實際表現必須以當地電信商的實測為準。
  • 適合情境(固定寬頻/VPS):屬於「介於 Reality 與 WS 之間」的折衷方案。不必特地換過去。
重要:gRPC 與 XHTTP+Reality 誰更適合,取決於你的情境是「固定寬頻/VPS」還是「手機 SIM 資料」。兩者沒有單一定論。因此「主播進階:多協議自動 Fallback 架構」把 gRPC 設為固定場景的 PRIMARY。手機直播情境必須另外評估。

Hysteria2

基於 QUIC(UDP)的代理協議,有自己的官方引擎。

  • 特色:速度快,在弱網環境表現好。核心賣點是 Brutal 擁塞控制。傳統 TCP/BBR「一丟包就降速」,Brutal 則相反。你告訴 Brutal 頻寬是多少,Brutal 就按固定速率推送。丟包時 Brutal 也不降速。Brutal 對推流(上傳)友善。UDP 比 TCP 更不容易卡頓。
  • 偽裝:有流量混淆,有一定的抗封鎖能力(Salamander,2026 年 5 月起新增 Gecko)。
  • 缺點:在某些中國 ISP 環境中,UDP 會被 QoS 限速。
  • 適合情境:對速度要求高的場景,例如推流到 Twitch,或下載大檔案(必須確認頻寬填寫正確)。
Brutal 頻寬設定:填入「跨境路徑的實測容量」。不是家裡的同步速率,也不是用量。 三個容易混淆的數字中,只有第三個是正確的:

1. 家裡寬頻同步速率(例如 500/500): 錯誤。瓶頸在中國到台灣的跨境這一段。本地同步速率再高,也無法代表跨境容量。
2. 你打算用掉的量(例如手機直播頂多 20/20): 也不對。這是用量,不是容量。這個數字沒有為 FEC 和重傳開銷留下緩衝。稍有波動就會到達上限。
3. 實測這條跨境路徑的真實容量——正確答案。用 iperf3 透過隧道,在平常直播的時段(尤其是晚高峰)量出穩定吞吐量。取實測值的八到九成填入。
這裡的風險不對稱:設太大比設太小嚴重得多。 填太小是安全的,但會浪費頻寬:Brutal 把吞吐量鎖在上限以下,路徑可以承受更多,卻沒有用到。填太大是主動把整條連線打爆:Brutal 不會「填不滿就算了」。Brutal 把你填的數字當成事實,持續推送。路徑撐不住時,Brutal 也不退讓。結果是大量丟包、jitter 暴增,連你的 RTMP 推流本身也會受影響。如果想免填頻寬,需要更溫和的方案,官方提供 BBR/Reno 替代演算法。也可以考慮 Tuic v5。
Hysteria2 不是隨時都用滿頻寬。 Brutal 控制的是「上限」和「丟包時是否退讓」。Brutal 不會憑空製造流量把管道填滿。日常瀏覽這類輕量使用的應用層資料量小。Hysteria2 照實傳送,不會硬塞封包去逼近你設定的上限。只有「持續有資料要送(如 OBS 穩定輸出),而且路徑發生丟包」時,Brutal 才會用到頻寬上限,並且不退讓。閒置或輕量使用時,傳多少就送多少,行為和其他協議一樣。
Gecko 混淆(v2.9.2 新增,2026-05):你的環境可能還用不到。 Gecko 建立在 Salamander 之上,把 QUIC 握手包拆成隨機大小、隨機填充的碎片。使用前必須先確認客戶端內核是否支援:mihomo 1.19.26+ 已支援。sing-box 目前只有 1.14 alpha 預覽版支援。Xray-core 系(含 3x-ui 面板)完全不支援。
維運提醒:Xray-core 已移除 allowInsecure。 2026 年起(約 v26.1.31 硬報錯,v26.2.6 正式移除,UTC 2026-06-01 舊設定全面失效),Xray-core 移除了「跳過憑證驗證」的 allowInsecure 開關,改用 pinnedPeerCertSha256 憑證指紋。VLESS+Reality 完全不受影響。但是,如果你用 Xray-core 架設 Hysteria2 或其他 TLS inbound,並使用自簽憑證,而且設定中有 allowInsecure,內核可能拒絕啟動。檢查設定檔,改填 pinnedPeerCertSha256,或換成 Reality。mihomo 和 sing-box 不受影響。
2024–2025 年更新:GFW 已能大規模解密 QUIC。 USENIX Security 2025 論文證實,GFW 自 2024 年 4 月 7 日起,已能利用 QUIC Initial 封包中明文傳送的 DCID 推導解密金鑰。GFW 大規模解密 QUIC 連線,並依 SNI 黑名單封鎖特定網域。這是「QUIC 握手已加密,GFW 看不到內容」這個假設,第一次被打破。

但這不等於 Hysteria2 已被攻破:① GFW 依黑名單比對特定網域,不是無差別封鎖所有 QUIC。只要 masquerade 網域不在黑名單上(避開 google.com 這類敏感網站),風險就低。② 解密有計算成本瓶頸。中高流量負載下,覆蓋率會下降。③ 2025 年 3 月起,GFW 對境外連入方向的處理已有調整。現況比論文剛發表時更動態。

實務建議:必須開啟 obfs: salamander 混淆。masquerade 網域必須避開高知名度網站。

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

沒有必然關係。BBR/CUBIC 是作業系統核心層的 TCP 壅塞控制演算法。VLESS、Reality 和 Vision 這三層全部在 TCP 之上執行,本身不含任何壅塞控制邏輯:VLESS 負責認證和路由,Reality 負責偽裝,Vision 負責解決「TLS 套 TLS」的效能損耗。三者都不管封包丟失時是否降速。降速由目前的作業系統設定決定。

# 檢查目前演算法(Linux server 或 RPi5)
sysctl net.ipv4.tcp_congestion_control

# 啟用 BBR(核心需 >= 4.9)
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
關鍵:壅塞控制由「發送端」決定,不是接收端。 直播上傳方向是中國 → 台灣。決定是否因丟包降速的,是資料離開中國那端的發送端。如果你的架構是 RPi5 中繼,真正應該優化 BBR 的是 RPi5(Linux),不是你的 Windows PC 或手機。
Windows 沒有原生 BBR,而且 BBR2 已知會讓 v2rayN 無法使用。 現代 Windows(10 1809 / 11)預設使用 CUBIC,不是 BBR。Windows 11 22H2 起,可以用 PowerShell 手動開啟實驗性 BBR2。但社群已回報,BBR2 會破壞本機 loopback TCP 連線。而且已有 GitHub issue 證實開啟 BBR2 會導致 v2rayN 連不上、無法更新。如果你用 v2rayN 這類客戶端直連(沒有 RPi5 中繼),不建議為了追求 BBR 去開啟 Windows 的 BBR2。維持預設 CUBIC 即可。
Hysteria2 masquerade 選擇策略(對照 Reality SNI/dest 策略): masquerade 機制看起來像 Reality 的 dest 選擇,但原理完全不同。Reality 要比對 dest 網站真實的 TLS 特徵是否吻合。Hysteria2 masquerade 用的是你自己申請的憑證。這張憑證只在有人用未授權的方式探測你的 port 時才觸發。這時,你的伺服器像 reverse proxy 一樣,去抓取 masquerade 目標的內容並回傳。因此篩選重點如下:① 你的伺服器連到目標的延遲與穩定度(是伺服器去抓取,不是客戶端)。② 目標網站避免選擇知名度太高的網站(例如避開 microsoft.com,實測延遲可能極不穩定)。③ 是否支援 HTTP/3 是加分項,不是必要條件。批量測試腳本見「管理員維護」章節。

WireGuard

現代化 VPN 協議,程式碼極簡,效能優秀。

在中國科學上網的致命缺點:沒有任何流量混淆機制,UDP 封包特徵極度明顯。GFW 可以直接識別並封鎖 WireGuard。WireGuard 架設後基本上會立即被封鎖。在中國科學上網的場景中,直接排除 WireGuard。

SoftEther

多協議 VPN 伺服器軟體。同時支援自家協議、OpenVPN 相容模式、L2TP/IPSec 和 SSTP。曾以偽裝 HTTPS(443 port)聞名。

2025-2026 年實測現況:官方論壇多篇貼文證實,GFW 已針對 SoftEther 協議做主動 SNI/DPI 探測並封鎖。SoftEther 不再是穩定的選項。適合 非審查地區的多協議相容需求(舊路由器、企業既有系統、NAS 遠端存取)。不建議在中國科學上網時使用。

OpenVPN

最老牌、生態最成熟的 VPN 協議。.ovpn 設定檔的通用性極高。

致命缺點:官方沒有流量混淆機制,TLS handshake 特徵明顯。伺服器上線後,很快就會被 GFW 識別並封鎖。如果額外加上混淆層(obfs4 / stunnel),複雜度已接近直接使用 Reality。因此沒有必要繞遠路。OpenVPN 適合非審查地區的標準 VPN 需求,以及企業既有 OpenVPN 架構的維護。

協議選擇建議

使用情境 推薦協議 備註
一般科學上網(看影片、使用 Discord) VLESS + Reality + Vision 最穩定,偽裝性最強
高速推流 / 弱網環境(固定寬頻 / VPS) Hysteria2 UDP 特性,需注意 ISP QoS
手機直播(使用電信 SIM 卡資料) VLESS + Reality + Vision 行動資料的 UDP 更容易被電信商限速,見下方「手機直播情境」
中國科學上網 不可以用 WireGuard 特徵明顯,會立即被封鎖
為什麼直播場景 VLESS 容易被限速,HY2 反而不會: 原因不是 TCP 或 UDP 本質上誰比較安全。原因是流量特徵。直播上傳是「長時間、持續高吞吐、單向」的模式。一條 TCP 連線連續全速執行好幾小時,行為模式和正常瀏覽(短連線、bursty)差異極大。QoS 和 DPI 的行為分析容易盯上這種流量。HY2 使用 UDP/QUIC,混在大量合法的視訊會議和串流影音的高吞吐 UDP 流量中,異常度低很多。
這段需要更新:原本認為「GFW 和 ISP 這幾年的偵測資源主要投入在 TCP-based 協議上,UDP/QUIC 的偵測基礎建設相對不成熟」。這個看法已被 2024–2025 年的研究部分推翻(見上方 Hysteria2 的 2024–2025 更新說明)。GFW 自 2024 年 4 月起,已具備大規模解密 QUIC 並依黑名單封鎖的能力。UDP/QUIC 不再是「GFW 還沒認真對付」的協議。但是 GFW 仍然是依黑名單比對,不是無差別封鎖。開啟 Salamander 混淆,仍然可以維持相對優勢。
日常瀏覽本來就是短連線、bursty 的正常行為模式,所以 VLESS+Reality+Vision 反而是更合適、更省電的選擇。你不需要因為直播被限速的經驗,就把日常瀏覽也換成 HY2。

手機直播情境的功耗考量

若情境是手機直接執行 VPN client 直播(而非 RPi5 端 Bonding 架構),協議選擇的第一優先順序是「是否會被電信商限速」。其次才是功耗與發熱。

為什麼手機直播預設使用 Reality,不是 Hysteria2: 手機使用電信 SIM 卡資料(4G/5G)。電信商對行動資料 UDP 流量的限速機率,比對固定寬頻或 VPS 更高。Hysteria2 的底層是 QUIC/UDP。即使有混淆,被限速的風險仍然比 VLESS+Reality(偽裝成標準 TLS 1.3 的 TCP 流量)高。沒有 RPi5/Bonding 這一層備援時,一旦被限速,就沒有其他鏈路可以替代。因此被限速的風險比功耗更需要優先考慮。
協議 功耗 / 發熱 原因
WireGuard 最低 封包格式極簡,沒有額外的壅塞控制邏輯。但是 WireGuard 不適用於在中國科學上網(見上方 WireGuard 說明),這裡僅供對照參考
VLESS + Reality + Vision 中等 TCP 重傳和壅塞控制交給系統 kernel 處理,userspace 負擔較輕。4G/5G 基地台切換頻繁時,TLS 重新握手會造成耗電高峰
Hysteria2 較高(持續直播時最明顯) QUIC 的壅塞控制和重傳邏輯全部在 userspace 自行運算。長時間高吞吐量對 CPU 是持續性負擔。抗審查用的探測封包也會讓 modem 更頻繁保持活躍

什麼時候才切換到 Hysteria2:Reality 被 GFW 針對性封鎖時,作為備援。或者訊號極差(丟包率高到 Reality 的 HOL Blocking 已嚴重卡頓)時,QUIC 的抗丟包能力比偽裝能力更重要。

實戰結論:手機直播預設使用 VLESS+Reality+Vision。理由是抗限速和抗封鎖的穩定性優先。Hysteria2 的功耗較高,而且行動資料更容易被限速。只在 Reality 被封鎖或訊號極差時才切換。如果手機發熱到降頻,影響編碼效能,建議優先連接行動電源,而不是為了省電改用抗封鎖能力較弱的協議。

VPS vs 住宅 IP × 電腦/手機:三維度交叉分析

前面的「協議選擇建議」只從流量特徵的角度出發。實際上有三個變數要一起看。缺少任何一個,都可能誤判:① 伺服器使用的是 VPS 機房 IP 還是住宅 IP(IP 信譽差異詳見「VPS 選購說明」);② 科學上網的裝置是電腦(固定寬頻/Wi-Fi)還是手機(SIM 資料);③ 是日常上網還是直播推流。三個變數交叉會有 8 種組合。為了方便閱讀,拆成「電腦科學上網」和「手機科學上網」兩張表。

電腦科學上網(固定寬頻/Wi-Fi)

組合 VLESS+Reality+Vision Hysteria2
VPS + 日常上網 首選。機房 IP 本身已帶有「可能是代理」的基礎懷疑值。因此 Reality 的握手偽裝更關鍵 可用,但沒有必要,功耗較高
VPS + 直播推流 實戰回報容易被限速(機房 IP + 持續高吞吐 TCP 是雙重疊加的異常訊號) 首選,社群實測較穩定
住宅 IP + 日常上網 首選,也是最理想的情境。真實住宅 IP 疊加正常瀏覽行為模式,幾乎不可能被盯上 沒有必要,純粹多耗電
住宅 IP + 直播推流 缺乏電腦端固網直播的住宅 IP 實測資料。理論上比 VPS 安全,但未驗證(推測) 理論上更穩定,同樣缺乏電腦端實測(推測)

手機科學上網(SIM 資料)

組合 VLESS+Reality+Vision Hysteria2
VPS + 日常瀏覽 首選。短連線、bursty 的瀏覽行為和 Reality 偽裝契合度高 功耗高、沒有必要,行動資料更耗電
VPS + 直播推流 有實戰案例(見下方混淆變數說明)。但是機房 IP 加上手機直播,是雙重疊加,不能單獨歸因於協議 待驗證,需要交換測試確認
住宅 IP + 日常瀏覽 首選,最理想的情境 沒有必要,純粹多耗電
住宅 IP + 直播推流 未直接驗證。住宅寬頻的上傳頻寬通常較窄,手機直播疊加上去,理論上仍可能顯眼(推測)。需要實測 有實戰案例(見下方混淆變數說明),同樣不能單獨歸因於協議
重要:手機直播這兩格目前是「混淆變數」狀態,不是乾淨的結論。 目前唯一的手機直播實戰案例(用 PRISM Live 手機 App 直播)是「VLESS 掛 Oracle 東京機房 IP,Hysteria2 掛 NAS 住宅 IP」。協議和 IP 類型同時在變。兩個因素的方向剛好一致(都指向 VLESS 這組更可疑)。因此無法從這一組資料單獨分辨:問題是出在機房 IP,還是出在 VLESS 流量特徵。

要得到乾淨的結論,必須做交換測試:在住宅 IP 上另開一個 VLESS 節點,在 VPS 上另開一個 HY2 節點。用同一批人,以同樣的手機 App 直播方式測試。如果「住宅 IP 上的 VLESS 也順暢,VPS 上的 HY2 也被限速」,表示主因是 IP 類型。如果「住宅 IP 上的 VLESS 仍然容易被限速,VPS 上的 HY2 仍然穩定」,表示主因是協議流量特徵。在做完交換測試之前,上面兩格的建議只是「觀察到的現象」。這些建議不是可以直接套用的定論。

主播進階:多協議自動 Fallback 架構

適用於想做「主線 + 自動備援」的進階需求(同時兼顧 RTMP 推流、Discord 語音,以及 YouTube/Twitch 觀看)。如果只需要單一穩定協議,用上方的 VLESS+Reality+Vision 就夠了。不需要做到這麼複雜。

角色 協議 負責流量
PRIMARY 主線 VLESS + gRPC + TLS Discord、RTMP 推流、控制流量
FALLBACK 備援 VLESS + Reality + Vision 主線失效時接管,長連線恢復
BOOST 加速 Hysteria2 (QUIC) YouTube/Twitch 觀看、大流量下載(非關鍵流量)
自動切換邏輯(概念)
IF gRPC 健康:使用 gRPC(主線)
ELSE IF gRPC 不穩:切換 → Reality
IF Reality 也不穩或被封:切換 → Hysteria2
IF 全部失敗:每 10 秒重試 gRPC(backoff)

IF gRPC 穩定滿 60 秒:切回 gRPC(主線)

健康判斷參考指標:RTT 持續超過 200ms、封包遺失率超過 3%、60 秒內重連 2 次以上、bitrate 驟降超過 30%,或 handshake 直接失敗。

重要修正:這套邏輯只能做到「快速恢復」,不能做到「不中斷」。 自動切換到備援協議時,底層連線必須重建。RTMP 推流實務上仍然會經歷一次 reconnect(短暫中斷或掉關鍵幀)。這不是無縫切換。要做到「不中斷」,必須同時對兩條線路做冗餘推流(server 端選擇最佳的一路),或使用支援 connection migration 的協議。單純換路由無法做到零中斷,只能做到「幾秒內恢復」。
不需要從頭自己寫:Xray-core 本身內建 Observatory + Balancer 機制,可以做延遲導向的自動選路。你不需要自己建立 health-check 系統。實際要建置這套架構時,可以直接研究這個內建功能。

RTMP 直播的協議優先序:① gRPC + TLS(主線,bitrate 最穩,抖動最低)② Reality(備援)③ 不建議把 Hysteria2 當作 RTMP 上行主力(QUIC 波動較大,只適合觀看端)。

RTMP / SRT 與隧道協議搭配:依裝置與訊號拆解

適用於同時需要「電腦 RTMP」「手機 RTMP」「未來手機 SRT」,且手機端會遇到戶外弱訊號情境的架設需求。如果只做電腦固網直播,上方「RTMP 直播的協議優先序」就夠用。

先分清楚:內容協議與隧道協議是兩層,兩者不同

  • 第一層:直播內容協議(OBS 或手機直播 App 把畫面送出去的方式):RTMP(建立在 TCP 上)、SRT(建立在 UDP 上,自帶抗丟包 ARQ 機制)
  • 第二層:科學上網隧道協議(流量的包裝方式,用來繞過 GFW):Reality/gRPC/XHTTP(TCP 家族)、Hysteria2(UDP/QUIC 家族)
OBS / 手機 App
   → RTMP(TCP) 或 SRT(UDP)                     ← 第一層:直播內容協議
      → 包進 VPN 隧道(Reality/gRPC/Hysteria2) ← 第二層:科學上網隧道協議
         → 送到 VPS → 平台伺服器
修正:真正容易衝突的是「同傳輸層」的組合,不是「跨傳輸層」的組合。 這四種疊法(稱作 protocol tunneling / encapsulation)依外層和內層協議,可以分為四種。只有一種有正式的問題名稱:
組合 例子 是否有結構性問題
TCP in TCP RTMP 包進 Reality/gRPC 有,正式名稱 TCP meltdown:外層 TCP 的重傳和壅塞控制會阻塞內層 TCP 的 ACK,引發嚴重的 Head-of-Line Blocking。丟包率一高,延遲就飆升,甚至斷流
UDP in UDP SRT 包進 Hysteria2 最自然,沒有已知的結構性問題。沒有雙重 TCP 狀態機互相衝突的情況
TCP in UDP RTMP 包進 Hysteria2 通常沒有已知問題。外層 UDP/QUIC 沒有獨立的 TCP 重傳邏輯,不會互相衝突
UDP in TCP SRT 包進 Reality 有潛在問題,但未被廣泛討論。外層 TCP 的重傳和緩衝行為,可能拖慢內層 SRT 的即時性

詳細原理與實測解法,見 中國戶外直播筆記 第 4、5 節「TCP in TCP 問題說明與解法」。

依裝置與訊號拆解建議

情境 內容協議 封裝組合 建議隧道 原因
電腦 RTMP(固網) TCP TCP in TCP gRPC+TLS(主線)→ Reality(備援) 固網丟包率低,TCP meltdown 風險低。gRPC「連線很少中斷」的前提成立
手機 RTMP(訊號正常) TCP TCP in TCP XHTTP+Reality(優先)或 Reality 訊號正常時丟包率不高,TCP meltdown 風險可控。XHTTP+Reality 對斷線重連更寬容
手機 RTMP(戶外弱訊號) TCP TCP in TCP(高風險) 優先評估 Hysteria2(如果當地 GFW 對 UDP 的干擾不嚴重)。必須維持 Reality 時,把 OBS Network Buffering 調高到 3–5 MB,換取穩定 高丟包環境下,RTMP+Reality 是 TCP-in-TCP,容易觸發 TCP meltdown 和 HOL Blocking。Hysteria2(TCP in UDP)在結構上可以避開這個問題
手機 SRT(訊號正常,未來) UDP UDP in UDP Hysteria2 四種組合中最自然、沒有已知結構性問題的搭配
手機 SRT(戶外弱訊號,未來) UDP UDP in UDP Hysteria2 同上。而且 SRT 的 ARQ 和 Hysteria2 的 QUIC 抗丟包機制疊加,理論上更適合弱訊號環境(推測)。但仍待實測
與「手機直播情境的功耗考量」的關係: 那一節建議手機直播預設使用 Reality,理由是「行動資料的 UDP 更容易被電信商限速」。這個結論沒有錯,維持不變。限速風險是電信商層面的問題,和這裡討論的 TCP meltdown(協議層面的結構問題)是兩件不同的事。正確的整合邏輯如下:訊號正常時,限速風險 > meltdown 風險,預設使用 Reality。訊號極差、丟包率飆高時,meltdown 風險 > 限速風險,才切換到 Hysteria2。這和該節原本「訊號極差時才切換 Hysteria2」的結論完全一致。只是原因必須修正為 TCP meltdown,不是「跨家族組合」。
「Hysteria2 上行不建議當 RTMP 主力」是另一個獨立的經驗觀察,不是 TCP meltdown 的延伸: QUIC 本身的壅塞控制,在長時間、高吞吐的上傳場景中,可能有 bitrate 波動(社群經驗觀察,不是嚴謹的 benchmark)。這和 TCP-in-UDP 的結構是否乾淨,是兩件事。結構乾淨,不代表壅塞控制的行為模式一定適合長時間上傳。因此「RTMP 直播的協議優先序」把 Hysteria2 定位在「觀看端」,不是「上行主力」。
gRPC+TLS 不是手機 SIM 卡直播的首選:gRPC 建立在 HTTP/2 multiplexing 上,前提是「連線很少中斷」。手機使用 SIM 資料時,基地台切換頻繁。連線一旦斷裂,HTTP/2 這種多工共用連線必須整個重建。恢復成本比 XHTTP+Reality 更高。因此手機 SIM 卡直播建議優先評估 XHTTP+Reality,不建議直接套用「電腦端 RTMP 優先序」裡的 gRPC。

實務建議

  1. 電腦端與手機端拆成兩套獨立設定,不共用同一套判斷邏輯。兩者的網路特性(固網與行動資料)差異太大。
  2. 手機端再依「訊號好壞」做動態切換,不建議固定使用一個協議。上方「自動切換邏輯」的健康判斷指標(RTT 持續超過 200ms、封包遺失率超過 3%、60 秒內重連 2 次以上),可以直接沿用在手機端的判斷邏輯上。
  3. 未來上 SRT 前,建議先做交換測試:用同一台手機,在同樣的戶外弱訊號環境中,分別實測「SRT+Hysteria2」和「RTMP+Reality」的實際卡頓和畫質表現。這部分目前沒有資料。理論推導不夠準確,必須用實測資料補上。

情境速查表

前面比較的是協議本身。本節把協議對應到「你實際在做什麼」:使用什麼裝置、是否科學上網、是單純上網還是直播。一共有 8 種組合。差異主要來自兩個變數:

  • 裝置差異的本質是「網路來源」的差異:手機通常代表行動網路(4G/5G),電腦通常代表家用固網或 Wi-Fi。裝置本身不影響協議選擇。真正影響協議選擇的,是裝置背後連接的網路類型。
  • 上網和直播的差異,是「流量規模與持續性」:一般瀏覽是間歇性的小流量。直播是持續性、高碼率的長時間傳輸,更容易被 QoS 或審查系統盯上。
# 情境 網路路徑 常見協議/連線方式 主要風險 建議
1 手機上網(不科學上網) 手機 → 電信基地台/Wi-Fi → ISP → 目標網站 App 內容多為 TCP(HTTP/2),部分使用 UDP(QUIC/HTTP/3) 行動網路對持續的大流量 UDP 很敏感。但是一般瀏覽是短暫流量,不太會被限速 不需要特別處理,系統會自動選擇最佳協議
2 電腦上網(不科學上網) 電腦 → Wi-Fi/有線 → ISP → 目標網站 同上,瀏覽器同樣原生支援 QUIC/HTTP/3 家用固網限速多為「用量制」(每日 GB 上限),不看協議類型 同上,正常使用不需要調整
3 手機直播(不科學上網) 手機 App(如 Twitch/抖音)→ 電信/Wi-Fi → 平台伺服器 RTMP(TCP)較常見,部分新 App 使用 SRT/WebRTC(UDP) 如果用 SRT/WebRTC 走行動網路,持續的高碼率 UDP 容易觸發電信商的 QoS 行動網路建議先用 RTMP 或 WHIP(WebRTC)。使用 SRT 時,建議降低碼率並提高 latency 參數
4 電腦直播(不科學上網) 電腦(OBS 等)→ 家用固網 → 平台伺服器 RTMP 和 SRT 都可以,走固網 固網環境對 UDP 限速的機率低。SRT 抗丟包的優勢可以完整發揮 固網環境可以放心使用 SRT,以取得更好的畫質和穩定度
5 手機科學上網上網 手機 → 電信/Wi-Fi → VPN/代理隧道 → 真實網站 依所選協議:Reality(TCP)/Hysteria2(UDP)/WireGuard(UDP) 行動網路對 UDP 敏感,而且審查系統可能針對性限制 UDP。兩種風險疊加 優先使用 Reality。如果在穩定 Wi-Fi 下(非行動資料),可以測試 Hysteria2
6 電腦科學上網上網 電腦 → 固網/Wi-Fi → VPN 隧道 → 真實網站 同上 固網環境下,UDP 被審查針對性限制的機率因地區而異。但是固網不受電信 QoS 限制 Hysteria2 在固網通常體驗較佳。如果被識別並限速,改回 Reality
7 手機科學上網直播 手機 → 電信/Wi-Fi → VPN 隧道 → 中轉伺服器/VPS → 直播平台 直播協議(RTMP/SRT)外面再包一層 VPN 隧道協議。這等於雙層封裝 風險最高的組合:直播的持續大流量,加上科學上網隧道流量,最容易被偵測或限速。也最容易發生「UDP 包 TCP」或「雙重重傳衝突」的效能問題 優先使用 RTMP(TCP)搭配 Reality(TCP)隧道。避免 UDP 疊加 UDP 這種雙倍開銷的組合。如果走多卡 Bonding 分流,可以使用 Hysteria2
8 電腦科學上網直播 電腦(OBS 等)→ 固網 → VPN 隧道 → 中轉伺服器/VPS → 直播平台 同上,但走固網 固網環境下疊加隧道的風險比行動網路低很多。但是仍然必須注意雙層封裝的效能損耗 可以用 RTMP/SRT 搭配 Reality 或 Hysteria2。依當地審查和網路品質,實測後決定
三個重點觀察:
  1. 「科學上網」永遠會放大風險,「直播」也會放大風險。兩者疊加(情境 7、8,尤其是情境 7)時,風險最高。因此專業戶外直播團隊使用多卡 Bonding 和 RPi5 分流架構,分攤這個雙重風險,而不是只用一支手機。
  2. 手機和電腦的差異,本質是「行動網路」和「固網」的差異,不是裝置效能或系統的差異。如果你的手機連接穩定的 Wi-Fi(不是電信資料),應該用「電腦上網/直播」那一列的邏輯判斷。這和插著 SIM 卡使用 4G/5G 的風險等級完全不同。
  3. 不科學上網的情境(1-4)幾乎不需要選擇協議。系統或 App 通常會自動處理。真正需要選擇協議的是科學上網的情境(5-8)。其中「手機科學上網直播」是最複雜的組合。建議先用 iperf3 實測環境,再決定協議搭配。

面板與客戶端選擇

面板是伺服器端的網頁管理介面,讓你不需要輸入指令就能管理代理伺服器。客戶端是朋友那端安裝的 App,用來連線到你架設的伺服器。

面板:3x-ui vs s-ui

比較項目 3x-ui (★ 推薦) s-ui
底層引擎 Xray Sing-box
社群資源 非常豐富,教學最多 較少
穩定性 成熟,廣泛使用多年 相對新
特色功能 多使用者管理、流量統計、QR Code、Telegram Bot 支援 Sing-box 特有協議 (Tuic, NaïveProxy)
推薦度 ★★★★★ (一般使用首選) ★★★ (進階使用者)

3x-ui 一鍵安裝指令:

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

客戶端選擇

客戶端 = 朋友那端安裝的 App,用來連線到你架設的伺服器。

主流推薦客戶端

  • Shadowrocket(iOS 專用):iOS 科學上網最主流的選擇。付費 App(約 $2.99 美金),必須用非中國區 Apple ID 購買。支援 VLESS+Reality 和 Hysteria2。掃描 QR Code 即可連線。
  • v2rayN(Windows 專用):Windows 最主流的免費開源代理客戶端。支援訂閱連結一鍵更新、Xray/Sing-box 雙引擎,以及系統代理和 TUN 模式。

其他常用客戶端一覽

客戶端 平台 底層引擎 費用 特色
Hiddify Win / Mac / Linux / iOS / Android Sing-box 免費 跨平台支援最廣,適合多裝置使用者
v2rayNG Android Xray 免費 Android 最主流的選擇,和 3x-ui 搭配體驗佳
Clash Verge Win / Mac / Linux Clash Meta 免費 規則路由靈活,熟悉 Clash 生態的使用者首選
NekoBox Android Sing-box 免費 支援 Tuic / NaïveProxy 等 Sing-box 特有協議

VPS 選購說明

真正決定 VPS 使用體驗的不是「地區」,而是線路、距離和 IP 信譽的綜合表現。地區決定地理位置。線路決定網路路徑的品質。IP 信譽決定平台是否接受你的 IP。協議特徵決定這個 IP 能使用多久。

核心選購框架(三要素)

要素 決定什麼 說明
運營商 × 回程線路 晚高峰體驗 同樣是香港 VPS,電信走 CN2 GIA 還是走普通 163,體驗差異很大
地區(物理距離) 基礎延遲下限 地理位置決定延遲的物理下限。任何線路優化都無法突破這個下限
IP 類型與信譽 平台是否接受你 機房 IP / 住宅 IP / ISP IP 決定流媒體、帳號和支付系統是否可用

三大運營商回程線路

電信(China Telecom):追求穩定時,優先選 CN2 GIA。預算有限時,選 CN2 GT 或普通 163。

線路 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 定位
普通骨幹 AS4837 常見,性價比好,美西/日本 VPS 多數走這條線路
精品線路 AS9929 使用者少、擁塞少,穩定性更高

移動(China Mobile):注意「移動優化」不一定是 CMIN2。必須看 ASN 編號。

線路 ASN 定位
CMI AS58453 香港/日本/美西表現不差,性價比好
CMIN2 AS58807 「移動版 CN2 GIA」,更高階,晚高峰更穩
ASN 僅供參考:以上 ASN 編號可能隨供應商調整或線路重組而變動。購買 VPS 前,必須請商家提供目前實際的線路 ASN 來核對。不可以只依賴本表的數字。

線路測試指令(雙向完整版)

商家宣傳的線路不可以完全相信,必須自己測試。測試分兩個方向:去程(你的電腦 → VPS)與回程(VPS → 中國使用者)。

Step 1:在 VPS 上安裝工具,並確認出口 IP

# Debian / Ubuntu 安裝工具
apt update && apt install -y mtr-tiny traceroute iputils-ping curl

# 確認 VPS 的出口 IP 與地理位置
curl ip.sb
curl ip-api.com/json

Step 2:回程測試(在 VPS 上執行,測 VPS → 中國方向)

# 分別測三大運營商方向(各跑 100 次取樣)
mtr -rwzbc 100 223.5.5.5        # 電信(阿里 DNS,AS4134)
mtr -rwzbc 100 114.114.114.114  # 聯通方向探測(114 DNS 為第三方公共 DNS,非聯通官方基礎設施,僅作經驗性替代)
mtr -rwzbc 100 180.76.76.76     # 移動路由測試(目標為百度 DNS,AS55967,僅作探測用途)


# 參數說明:
# -r 報告模式  -w 寬格式  -z 顯示 ASN (最關鍵)
# -b 顯示 IP/hostname  -c 取樣次數
判斷標準:中間節點顯示 50–100% 丟包,不等於真實丟包(很多路由節點限制 ICMP)。只看最後一跳:0% 丟包 + 延遲穩定 = 實際通信正常。
這只測得到路由品質,測不到真實限速:MTR 可以看出路由節點和丟包,但看不出你的線路是否被針對性限速(尤其是 UDP/QUIC 類協議)。如果懷疑被限速,建議搭配 iperf3 測速懶人包 實際執行一次雙向吞吐量測試。這樣才能確認問題是路由問題,還是被限速。

SNI 網域批量測試(Reality 專用)

PC — OpenSSL + Xray 合併版(先用 openssl 快篩,ALPN 不過就跳過。過關的網域再接著執行 xray tls ping。這樣不需要測兩次)

$xrayPath = ".\xray.exe"   # 改成你的 xray.exe 實際路徑

$domains = @(
    "www.apple.com",
    "dl.google.com",
    "www.microsoft.com",
    "download-installer.cdn.mozilla.net",
    "addons.mozilla.org",
    "www.bing.com",
    "www.nvidia.com",
    "www.amd.com",
    "downloadmirror.intel.com",
    "www.adobe.com",
    "www.wto.org",
    "www.debian.org",
    "www.amazon.com",
    "www.ebay.com",
    "www.samsung.com",
    "www.ibm.com",
    "www.oracle.com",
    "www.cisco.com",
    "www.dell.com",
    "www.hp.com"
)

$results = @()
foreach ($d in $domains) {
    Write-Host "`n========== $d ==========" -ForegroundColor Cyan
    $row = [ordered]@{ Domain=$d; TLS13="-"; ALPNh2="-"; ECH="-"; Redirect="-"; OCSP="-"; PingMs="-" }
    Write-Host "--- OpenSSL 篩選 ---" -ForegroundColor Yellow
    $result = "" | openssl s_client -connect "${d}:443" -tls1_3 -alpn h2 -servername $d -status 2>&1
    $tls13 = $result | Select-String "TLSv1.3"
    $alpn  = $result | Select-String "ALPN protocol: h2"
    $group = $result | Select-String "Negotiated TLS1.3 group"
    $ocsp  = $result | Select-String "OCSP Response Status: successful"
    if ($tls13) { Write-Host "  TLS1.3: OK" -ForegroundColor Green; $row.TLS13="OK" } else { Write-Host "  TLS1.3: FAIL" -ForegroundColor Red; $row.TLS13="FAIL" }
    if ($alpn)  { Write-Host "  ALPN h2: OK" -ForegroundColor Green; $row.ALPNh2="OK" } else { Write-Host "  ALPN h2: FAIL" -ForegroundColor Red; $row.ALPNh2="FAIL" }
    if ($group) { Write-Host "  金鑰群組: $group" }
    if ($ocsp)  { Write-Host "  OCSP Stapling: 有 (加分項)" -ForegroundColor Green; $row.OCSP="有" } else { Write-Host "  OCSP Stapling: 無"; $row.OCSP="無" }
    if (-not $alpn) { Write-Host "  --> ALPN 不合格,略過後續測試" -ForegroundColor DarkGray; $results += [PSCustomObject]$row; continue }
    Write-Host "--- ECH (DNS HTTPS 記錄) ---" -ForegroundColor Yellow
    try {
        $httpsRecord = Resolve-DnsName -Name $d -Type HTTPS -ErrorAction Stop
        $echFound = $httpsRecord | Where-Object { $_.Strings -match "ech" -or $_.NameExchange -match "ech" }
        if ($echFound) { Write-Host "  ECH: 有部署,不建議作為 Reality 目標" -ForegroundColor Red; $row.ECH="有(不建議)" } else { Write-Host "  ECH: 未發布 ECH 設定" -ForegroundColor Green; $row.ECH="無" }
    } catch { Write-Host "  ECH: 查無 HTTPS 記錄 (視為未部署 ECH)" -ForegroundColor Green; $row.ECH="無記錄" }
    Write-Host "--- 跳轉檢查 ---" -ForegroundColor Yellow
    try {
        $resp = Invoke-WebRequest -Uri "https://$d" -MaximumRedirection 0 -ErrorAction Stop -UseBasicParsing -TimeoutSec 8
        $code = [int]$resp.StatusCode
        if ($code -ge 300 -and $code -lt 400) { Write-Host "  偵測到跳轉 (狀態碼: $code),扣分" -ForegroundColor Red; $row.Redirect="有跳轉" }
        else { Write-Host "  無跳轉 (狀態碼: $code)" -ForegroundColor Green; $row.Redirect="無" }
    } catch {
        $code = $_.Exception.Response.StatusCode.value__
        if ($code -ge 300 -and $code -lt 400) { Write-Host "  偵測到跳轉 (狀態碼: $code),扣分" -ForegroundColor Red; $row.Redirect="有跳轉" }
        elseif ($_.Exception.Message -match "timed out|timeout") { Write-Host "  跳轉檢查逾時,略過" -ForegroundColor DarkGray; $row.Redirect="逾時" }
        else { Write-Host "  無法判斷 (狀態碼: $code)" -ForegroundColor DarkGray; $row.Redirect="未知" }
    }
    Write-Host "--- Xray TLS Ping ---" -ForegroundColor Yellow
    if (Test-Path $xrayPath) { & $xrayPath tls ping $d } else { Write-Host "  找不到 xray.exe,略過此步驟" -ForegroundColor DarkGray }
    Write-Host "--- Ping 延遲 ---" -ForegroundColor Yellow
    $pingResult = Test-Connection -ComputerName $d -Count 4 -ErrorAction SilentlyContinue
    if ($pingResult) { $avg = ($pingResult | Measure-Object -Property ResponseTime -Average).Average; Write-Host "  平均延遲: $([math]::Round($avg,1)) ms"; $row.PingMs=[math]::Round($avg,1) } else { Write-Host "  Ping 無回應 (可能封鎖 ICMP)" -ForegroundColor DarkGray; $row.PingMs="無回應" }
    $results += [PSCustomObject]$row
}
Write-Host "`n`n================ 總結 ================" -ForegroundColor Magenta
$results | Format-Table -AutoSize
更正:延遲判斷的理由寫錯了,測試地點也很關鍵。 根據 Xray-core 官方原始碼分析,以及開發者在 GitHub 討論串貼出的封包追蹤,Reality 握手時你的伺服器會即時連線到偽裝目標網站,取得真實的 Server Hello,再轉發回客戶端。合法客戶端和 GFW 探測都會發生這件事。這表示:
  • 連線建立後的實際傳輸速度,走的是「中國 client ↔ 你的伺服器」直接對接,完全不經過偽裝目標網站。偽裝目標的速度,和你平常使用的速度沒有關係。
  • 但每次新連線的「握手」階段,需要你的伺服器連線到偽裝目標,取得真實憑證。這段路徑的延遲和穩定度,會影響「連線建立的速度和穩定性」。這才是延遲測試真正有意義的地方。
所以必須在你的伺服器主機上(不是在中國端測,也不是隨便找一台電腦測)執行這些測試腳本。這樣量到的才是真正相關的延遲數字。經驗法則可以保留:30–80ms 理想,200ms 以上考慮換候選。只是理由要改成「伺服器到偽裝目標的握手延遲」,不是「家用網路環境路由太遠」。

選擇 Reality 的偽裝目標網域(SNI)時,除了延遲,還必須確認目標支援 TLS 1.3 和 H2,而且沒有開啟 ECH(目標一旦開啟 ECH,Reality 偽裝就會失效)。以下提供 PC 和 VPS 兩端各三種批量測試腳本。

更正:「純 X25519 比較安全/比較不會被識別」這個說法是錯的。 官方文件明確寫著:如果偽裝目標支援 X25519MLKEM768(後量子混合金鑰交換),Reality client 會自動使用同一種演算法。因此 Reality 會對齊目標網站的行為,不會因為目標支援 PQC 而產生「指紋不一致」的問題。而且 X25519MLKEM768 是「X25519 + 後量子」的混合強化版,安全性只會更高,不會更低。不需要為了「避免指紋不一致」,刻意篩選只支援純 X25519 的候選。這樣做反而會排除很多原本合格的大站(Apple、Google 等現在很多都支援 X25519MLKEM768)。
建議做法:兩個工具搭配使用,不建議只選一個。
  1. 用 openssl 批量腳本先大範圍篩選,快速排除 ALPN h2 FAIL 的候選。
  2. 對剩下的候選,再用 xray tls ping 逐一確認。優先選「TLS1.3 + 憑證鏈正常 + 沒有 ECH」的候選。不需要區分是純 X25519 還是 X25519MLKEM768。

PC — PowerShell 版(呼叫 openssl.exe)

$domains = @(
    "www.apple.com",
    "dl.google.com",
    "www.microsoft.com",
    "download-installer.cdn.mozilla.net",
    "addons.mozilla.org",
    "www.bing.com",
    "www.nvidia.com",
    "www.amd.com",
    "downloadmirror.intel.com",
    "www.adobe.com",
    "www.wto.org",
    "www.debian.org",
    "www.amazon.com",
    "www.ebay.com",
    "www.samsung.com",
    "www.ibm.com",
    "www.oracle.com",
    "www.cisco.com",
    "www.dell.com",
    "www.hp.com"
)

foreach ($d in $domains) {
    Write-Host "`n=== 測試: $d ===" -ForegroundColor Cyan

    $result = echo "" | openssl s_client -connect "${d}:443" -tls1_3 -alpn h2 -servername $d -status 2>&1

    $tls13 = $result | Select-String "TLSv1.3"
    $alpn  = $result | Select-String "ALPN protocol: h2"
    $group = $result | Select-String "Negotiated TLS1.3 group"
    $ocsp  = $result | Select-String "OCSP Response Status: successful"

    if ($tls13) { Write-Host "  TLS1.3: OK" -ForegroundColor Green } else { Write-Host "  TLS1.3: FAIL" -ForegroundColor Red }
    if ($alpn)  { Write-Host "  ALPN h2: OK" -ForegroundColor Green } else { Write-Host "  ALPN h2: FAIL" -ForegroundColor Red }
    if ($group) { Write-Host "  金鑰群組: $group" }
    if ($ocsp)  { Write-Host "  OCSP Stapling: 有 (加分項)" -ForegroundColor Green } else { Write-Host "  OCSP Stapling: 無" }

    # ECH 改查 DNS HTTPS 記錄,才是準確的判斷方式
    try {
        $httpsRecord = Resolve-DnsName -Name $d -Type HTTPS -ErrorAction Stop
        $echFound = $httpsRecord | Where-Object { $_.Strings -match "ech" }
        if ($echFound) { Write-Host "  ECH: 有部署,不建議使用" -ForegroundColor Red } else { Write-Host "  ECH: 未發布 ECH 設定" -ForegroundColor Green }
    } catch {
        Write-Host "  ECH: 查無 HTTPS 記錄 (視為未部署)" -ForegroundColor Green
    }

    # 跳轉檢查
    try {
        $resp = Invoke-WebRequest -Uri "https://$d" -MaximumRedirection 0 -ErrorAction Stop -UseBasicParsing
        Write-Host "  跳轉: 無 (狀態碼 $($resp.StatusCode))" -ForegroundColor Green
    } catch {
        $code = $_.Exception.Response.StatusCode.value__
        if ($code -ge 300 -and $code -lt 400) { Write-Host "  跳轉: 有 (狀態碼 $code),扣分" -ForegroundColor Red } else { Write-Host "  跳轉: 無法判斷 (狀態碼 $code)" -ForegroundColor DarkGray }
    }
}

PC — Xray 版(xray.exe tls ping)

$xrayPath = ".\xray.exe"   # 改成你的 xray.exe 實際路徑

$domains = @(
    "www.apple.com",
    "dl.google.com",
    "www.microsoft.com",
    "download-installer.cdn.mozilla.net",
    "addons.mozilla.org",
    "www.bing.com",
    "www.nvidia.com",
    "www.amd.com",
    "downloadmirror.intel.com",
    "www.adobe.com",
    "www.wto.org",
    "www.debian.org",
    "www.amazon.com",
    "www.ebay.com",
    "www.samsung.com",
    "www.ibm.com",
    "www.oracle.com",
    "www.cisco.com",
    "www.dell.com",
    "www.hp.com"
)

if (-not (Test-Path $xrayPath)) {
    Write-Host "找不到 xray.exe,請確認 `$xrayPath 路徑" -ForegroundColor Red
    return
}

foreach ($d in $domains) {
    Write-Host "`n=== 測試: $d ===" -ForegroundColor Cyan
    & $xrayPath tls ping $d
}

PC — OpenSSL 原生版(cmd 批次檔)

@echo off
setlocal enabledelayedexpansion

set domains=www.apple.com dl.google.com www.microsoft.com download-installer.cdn.mozilla.net addons.mozilla.org www.bing.com www.nvidia.com www.amd.com downloadmirror.intel.com www.adobe.com www.wto.org www.debian.org www.amazon.com www.ebay.com www.samsung.com www.ibm.com www.oracle.com www.cisco.com www.dell.com www.hp.com

for %%d in (%domains%) do (
    echo === %%d ===
    echo. | openssl s_client -connect %%d:443 -tls1_3 -alpn h2 -servername %%d -status 2>&1 | findstr /C:"TLSv1.3" /C:"ALPN protocol" /C:"Negotiated TLS1.3 group" /C:"OCSP Response Status: successful"

    rem ECH 改查 DNS HTTPS 記錄 (type=65),openssl 本身測不出 ECH
    nslookup -type=65 %%d 2>&1 | findstr /I "ech" >nul
    if !errorlevel! == 0 (
        echo   ECH: 可能有部署,不建議使用
    ) else (
        echo   ECH: 未偵測到
    )
    echo.
)
pause

VPS — OpenSSL 版(bash,含延遲測試)

#!/bin/bash

domains=(
    www.apple.com
    dl.google.com
    www.microsoft.com
    download-installer.cdn.mozilla.net
    addons.mozilla.org
    www.bing.com
    www.nvidia.com
    www.amd.com
    downloadmirror.intel.com
    www.adobe.com
    www.wto.org
    www.debian.org
    www.amazon.com
    www.ebay.com
    www.samsung.com
    www.ibm.com
    www.oracle.com
    www.cisco.com
    www.dell.com
    www.hp.com
)

for d in "${domains[@]}"; do
    echo "=== $d ==="
    result=$(echo | openssl s_client -connect "$d:443" -tls1_3 -alpn h2 -servername "$d" -status 2>&1)

    echo "$result" | grep -q "TLSv1.3" && echo "  TLS1.3: OK" || echo "  TLS1.3: FAIL"
    echo "$result" | grep -q "ALPN protocol: h2" && echo "  ALPN h2: OK" || echo "  ALPN h2: FAIL"
    echo "$result" | grep "Negotiated TLS1.3 group"
    echo "$result" | grep -q "OCSP Response Status: successful" && echo "  OCSP Stapling: 有 (加分項)" || echo "  OCSP Stapling: 無"

    # ECH 改用 dig 查 HTTPS 記錄,比 openssl 準確
    if command -v dig &> /dev/null; then
        echDetect=$(dig +short HTTPS "$d" | grep -i "ech=")
        if [ -n "$echDetect" ]; then
            echo "  ECH: 有部署,不建議使用"
        else
            echo "  ECH: 未發布 ECH 設定"
        fi
    else
        echo "  ECH: 未安裝 dig,略過檢查"
    fi

    # 跳轉檢查
    redirectCode=$(curl -s -o /dev/null -w "%{http_code}" -I "https://$d" --max-redirs 0)
    if [[ "$redirectCode" =~ ^3 ]]; then
        echo "  跳轉: 有 (狀態碼 $redirectCode),扣分"
    else
        echo "  跳轉: 無 (狀態碼 $redirectCode)"
    fi

    ping -c 3 -q "$d" | tail -1
    echo ""
done

VPS — Xray 版(bash,xray tls ping)

#!/bin/bash

domains=(
    www.apple.com
    dl.google.com
    www.microsoft.com
    download-installer.cdn.mozilla.net
    addons.mozilla.org
    www.bing.com
    www.nvidia.com
    www.amd.com
    downloadmirror.intel.com
    www.adobe.com
    www.wto.org
    www.debian.org
    www.amazon.com
    www.ebay.com
    www.samsung.com
    www.ibm.com
    www.oracle.com
    www.cisco.com
    www.dell.com
    www.hp.com
)

if ! command -v xray &> /dev/null; then
    echo "找不到 xray 指令,請確認已安裝並在 PATH 中"
    exit 1
fi

for d in "${domains[@]}"; do
    echo "=== $d ==="
    xray tls ping "$d"
    echo ""
done

實測結果:優質網域排名(作者實測,僅供參考)

更正評分維度:先前版本把「金鑰交換是否純 X25519」列為最重要的評分依據。這個標準是錯的。Reality client 會自動對齊 dest 支援的金鑰交換演算法(純 X25519 或 X25519MLKEM768 皆可)。這不影響安全性,也不會造成指紋不一致。因此不需要把這個標準當作篩選條件。真正該看的三個維度改為:延遲(伺服器到 dest 的握手速度)、without/with SNI 是否一致(獨立 IP 比共用 CDN 更穩。一致代表這個 IP 相對專門服務這個站)、憑證涵蓋網域是否乾淨。

一線推薦(獨立 IP、without/with SNI 握手一致、延遲低、憑證乾淨)

網域 延遲 獨立性 備註
www.oracle.com 3.2ms 獨立 IP 最快之一。憑證涵蓋網域雖多,但都是 oracle.com 自家子網域。圈內使用的人相對少,可以分散風險。建議設為主 dest
www.dell.com 1.5ms 獨立 IP 這批最快之一。憑證雖多,但全是 dell 系列自家網域
www.samsung.com 1.5ms 獨立 IP 同樣非常快。憑證涵蓋網域較多,但都同源
www.microsoft.com 5.5ms 獨立 IP 憑證只有 7 個相關網域,非常乾淨。缺點是圈內使用率高,容易撞車
www.apple.com 6.2ms 獨立 IP EV 憑證只有 3 個網域,是這批技術面最乾淨的之一。注意:本文件其他章節提到「VPS 部署避開 apple.com」,原因是中國有本地 CDN,VPS 路由容易不一致。你是住宅 IP 自架情境,這個顧慮的權重較低
www.amd.com 5ms 獨立 IP 憑證集中在 amd/radeon 系列,乾淨
www.amazon.com 5.8ms 獨立 IP 憑證集中在 amazon 系列。中國未封鎖,流量背景正常
www.cisco.com 6.5ms 獨立 IP 憑證乾淨,網域數量少

可用但排序稍後(without SNI 握手失敗或給出不同憑證,代表是多租戶共享 CDN 邊緣節點。這是常見的網路現象,不算致命。只是「這個 IP 為什麼服務這個網站」的自然度論證,比一線候選弱一點)

網域 延遲 備註
www.ibm.com 2.5ms without SNI 也能握手,但 with SNI 才轉為支援後量子。判斷為輕度共享節點
www.adobe.com 2ms without SNI 給的是 Akamai 通用憑證,屬共享 CDN 節點
downloadmirror.intel.com 2.5ms without SNI 直接握手失敗,屬共享節點。而且網域語意明確指向「下載服務」
www.bing.com / www.nvidia.com / www.hp.com 2.5–5.8ms without SNI 都握手失敗,屬共享 CDN 節點。可用,但不是首選

不建議選

網域 問題
dl.google.com Google 系網域在中國本身就被封鎖。「中國 IP 成功對 google.com 完成 TLS 握手」這個組合本身不自然,容易成為異常比對訊號
download-installer.cdn.mozilla.net / addons.mozilla.org 網域語意明確指向下載服務,不像一般公司主站。而且是 Fastly 共享節點,without SNI 給出完全不相關的通用憑證,較雜
www.debian.org 延遲 287.5ms,遠超可用門檻,直接排除
www.wto.org Cloudflare 代管,延遲本身尚可。但國際組織官網的流量背景薄弱(一般人沒有理由訪問)。而且太多人用 Cloudflare 網站當 dest。因此優先度最低
建議設定:主 dest 選 www.oracle.com(延遲快、乾淨、圈內使用率低,可以分散風險),備援可設 www.microsoft.com 或 www.apple.com 輪替,技術面同樣乾淨。

地區選擇說明

地區 優點 缺點 / 注意事項 適合情境
香港 延遲最低,華南使用者體驗佳 IP 信譽問題嚴重,風控嚴格 追求極致低延遲
日本 亞洲均衡,比香港便宜,聯通/移動性價比高 部分 NTT 線路晚高峰會繞路 多數使用者的首選
美西 便宜,帶寬大,IP 多 物理距離大,延遲較高 建站、下載、預算有限
新加坡 東南亞方向的核心節點 主要使用者在中國大陸時,延遲高於香港/日本 使用者在東南亞,或需要訪問東南亞業務
歐洲 隱私合規、便宜、硬碟大、帶寬大 大陸使用者延遲高,不適合低延遲場景 隱私合規、歐洲業務、備份
台灣 IP 被封的風險低(機房 IP 較少被大量濫用於代理) 回程路由對台灣使用者最友好 幫台灣朋友架設、追求低風險的首選

IP 類型與信譽查詢

流媒體能否觀看、帳號是否會被封,核心是平台如何看待 IP。

IP 類型 說明 優缺點
機房 IP (Datacenter) 常見 VPS/雲主機 便宜穩定,但容易被識別為代理,驗證碼多
住宅 IP (Residential) 電信商分配給家庭寬頻 風控友好,但價格貴、帶寬小,而且市場上品質參差不齊
ISP IP (靜態住宅) 兼顧住宅 ASN 和機房穩定性 折衷方案,但需要驗證真實性

常用 IP 信譽查詢工具:

  • IPQS (ipqualityscore.com):查 Fraud Score、是否被標記為 Proxy/VPN
  • Scamalytics (scamalytics.com):詐騙風險評分
  • ip-api / ipinfo:查 ASN、組織名稱,以及 GeoIP 是否準確
核心公式:好 IP × 低特徵協議(如 VLESS+Reality) = 最長使用壽命。流量特徵明顯的舊協議,會讓高價 IP 迅速被列入黑名單。

部署方式比較

科學上網服務大致有三種取得方式,各有不同的適用情境、成本和風險。自架的成本是「你的時間與維護精力」。機場的成本是「你對服務商的信任」。

三種方式一覽

比較項目 住宅 IP 自架 自架 VPS (★ 推薦) 機場(訂閱服務)
IP 類型 家用住宅 IP 機房 IP (Datacenter) 機房 IP 為主
月費 無額外費用 (用自家寬頻) $5–30 USD/月 ¥30–200+/月
技術門檻 高 (需處理 DDNS、NAT) 中 (裝 3x-ui 面板即可) 無 (買了直接用)
控制權與隱私 最高 (IP 是你家住址) 完整 (VPS 商技術上可見流量) 最低 (機場商看得到一切)
穩定性 依家庭寬頻而定 穩定,IP 固定 依機場品質而定,晚高峰容易波動

住宅 IP 自架

在自己家裡的電腦或 NAS 上執行 Xray,讓中國朋友連線到你家的 IP。

  • 優點:IP 是真實住宅 IP,平台風控極度友好;無額外 VPS 費用;流量特徵最低。
  • 缺點:必須處理浮動 IP (DDNS) 與 NAT (Port Forwarding)。家用寬頻上行通常只有 10-30Mbps,多人使用容易成為瓶頸。真實住家 IP 暴露給使用者,有隱私與連帶責任風險。
  • 適合誰:技術能力強、已有長期開機設備 (NAS)、只供少數親近朋友使用。

自架 VPS(本文主要推薦方案)

租用雲端虛擬機器 (VPS),自己安裝 3x-ui 面板,完全自行控制節點。

  • 優點:固定 IP,設定一次後穩定運行;多使用者管理方便;IP 與住家無關,隱私較好;可以選擇對中國大陸友好的線路 (CN2 GIA、CMIN2)。
  • 缺點:機房 IP 大量被用於代理,GFW 可能主動封鎖 (台灣 VPS 風險相對較低);必須自行維護系統與面板更新。
  • 適合誰:想供多位朋友使用、希望穩定且維護成本低、有基礎 Linux 操作能力。

機場(訂閱式科學上網服務)

購買他人架設的代理節點訂閱,直接在客戶端使用。

  • 優點:零技術門檻;節點多、地區多;一條被封時自動換下一條。
  • 缺點:隱私風險最高 (機場商可以看到所有流量與 DNS);小機場有服務商停止營運並消失的風險;節點共享導致晚高峰品質不穩;無法自訂協議與線路。
  • 適合誰:完全不想處理技術的朋友自用 (不是你幫他們架設的場景)。
選機場建議:優先選擇按月付費、有退款政策的服務商。避開過度便宜的服務商(靠過度售賣撐住)。建議不要用機場流量登入重要帳號。

綜合建議

  • 你幫朋友架設,朋友自己使用 自架 VPS + 3x-ui(優先考慮台灣 VPS,IP 被封風險低)。
  • 你自己使用,不想付 VPS 費用 住宅 IP 自架(需注意上行頻寬和隱私)。
  • 朋友自己處理、你不想管 推薦他購買機場(按月付費、可隨時更換)。

快速架設 SOP

以下為使用 3x-ui 面板 + VLESS+Reality 在台灣/海外 VPS 架設科學上網節點的標準流程。

Step 1:安裝 3x-ui 面板

SSH 連線到你的 VPS,執行以下一鍵安裝腳本(包含 Xray 核心):

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

Step 2:登入面板

安裝完成後,終端機會顯示面板的存取資訊。開啟瀏覽器登入,並立即修改預設密碼。

  • 預設網址:http://你的IP:2053/面板路徑
  • 預設帳號:admin
  • 預設密碼:admin

Step 3:新增 Inbound (VLESS + Reality)

在左側選單點選「入站列表 (Inbounds)」→「添加 Inbound」,並依照以下參數設定:

設定項目 建議值 / 說明
協議 (Protocol) vless
port (Port) 443
傳輸 (Network) tcp
安全性 (Security) reality
Flow xtls-rprx-vision (必填,消除內層 TLS 特徵)
Public / Private Key 點擊「Get New Cert」,或由系統自動產生
SNI (偽裝網域) 見下方「SNI / dest 選擇策略」
SNI / dest 選擇策略(重要):
Reality 的設計是:GFW 主動探測時,把連線轉發給真實的偽裝目標。核心原則是選擇支援 TLS 1.3 + H2、且在 VPS 所在地區訪問穩定的知名站點。
  • 日本 VPS:www.sony.com, www.samsung.com, www.cloudflare.com
  • 香港 VPS:香港本地銀行官網、www.cloudflare.com
  • 台灣 VPS:台灣大型企業官網、www.cloudflare.com
  • 美西 VPS:www.cloudflare.com, 美國大型企業官網
避開: www.apple.com(中國有合法本地 CDN。如果 VPS 不在這個 CDN 的實際服務範圍內,路由不一致,容易被識別)、 www.google.com(在中國本身就被封鎖,無法訪問。普通 IP 大量對 google.com 發起 TLS 握手,行為不自然)。

Step 4:產生客戶端連結

儲存 Inbound 後,回到列表頁面:

  1. 點擊 Inbound 右側的「二維碼 (QR Code)」圖示。
  2. 將 QR Code 截圖,或點擊「複製連結」。
  3. 傳給朋友。朋友使用 Shadowrocket (iOS) 或 v2rayN (Windows) 掃碼或貼上,即可連線。
伺服器時間同步:Reality 握手過程會校驗時間戳。如果伺服器與客戶端的時差超過數分鐘,TLS 握手會靜默失敗。必須在 VPS 上執行 timedatectl set-ntp true 啟用 NTP 自動同步。

設定範本

以下提供 Xray (VLESS+Reality) 與 Hysteria2 的伺服器端核心設定範本。範本已移除所有敏感資訊。你必須自行替換佔位符。

Xray (VLESS + Reality + Vision)

適用於 3x-ui 面板底層,或手動部署的 Xray-core。核心重點是 xtls-rprx-vision 與 realitySettings 的偽裝目標設定。

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "<YOUR_UUID_1>",
            "email": "user-self",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "www.cloudflare.com:443",
          "serverNames": ["www.cloudflare.com"],
          "privateKey": "<YOUR_PRIVATE_KEY>",
          "shortIds": ["", "0123456789abcdef"]
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "ip": ["geoip:private"], "outboundTag": "block" },
      { "type": "field", "protocol": ["bittorrent"], "outboundTag": "block" }
    ]
  },
  "outbounds": [
    { "protocol": "freedom", "tag": "direct" },
    { "protocol": "blackhole", "tag": "block" }
  ]
}
參數說明:
• shortIds:可以設定多個,讓不同客戶端使用不同的 ID,互不干擾。
• dest 與 serverNames:必須一致。選擇 VPS 所在地區訪問穩定、支援 TLS 1.3 的知名站點(如 Cloudflare、Sony 等)。

Hysteria2 (UDP/QUIC)

適用於需要高速推流或弱網環境的備用協議。內建 BBR 擁塞控制與流量偽裝。

listen: :443

# TLS 憑證 (使用 ACME 自動簽發)
acme:
  domains:
    - "<YOUR_DOMAIN>"
  email: "<YOUR_EMAIL>"

# 身份驗證
auth:
  type: userpass
  userpass:
    "user1": "<STRONG_PASSWORD_1>"
    "user2": "<STRONG_PASSWORD_2>"

# 封鎖 QUIC 放大攻擊向量
acl:
  inline:
    - reject(all, udp/443)

# QUIC 效能調整 (針對直播長連接優化)
quic:
  initStreamReceiveWindow: 4194304
  maxStreamReceiveWindow: 8388608
  initConnReceiveWindow: 10485760
  maxConnReceiveWindow: 20971520
  maxIdleTimeout: 120s

# 頻寬上限 (依 VPS 實際頻寬調整)
bandwidth:
  up: 100 mbps
  down: 100 mbps

# 偽裝網站 (有人掃描 IP 時顯示)
masquerade:
  type: proxy
  proxy:
    url: https://www.bing.com
    rewriteHost: true

使用者說明

科學上網不只是「連上伺服器」。更重要的是「防止本機洩漏」。以下提供 Windows 與 iOS 的標準防洩漏設定 SOP。這些設定確保 DNS、WebRTC 與系統流量不會繞過代理而暴露真實 IP。

項目 Windows / macOS Android iOS(真 VPN 模式)
DNS 洩漏風險 高 中 低~中
WebRTC 洩漏風險 高 中(限瀏覽器) 低
洩漏可控性 低 中 高
洩漏面積 大(系統 DNS、多網卡、Electron App 各自獨立設定) 中 小(集中在瀏覽器)
斷線保護(Kill Switch) 無(本方案刻意不開 TUN,見下方 Step 說明) 視 client 是否支援 TUN + Kill Switch 而定 可開(見下方「包含所有網路」)
iOS「低風險」有前提:只有使用 Shadowrocket 這種系統層 VPN 模式(Network Extension),並攔截全部流量(含 UDP/STUN)時,這個說法才成立。這也是下方 iOS 說明要求開啟「禁用 STUN」的原因。如果改用純 HTTP/SOCKS proxy 模式,WebRTC 仍可能繞過代理而暴露真實 IP。風險不會比電腦低。

為什麼選擇「無 TUN + 規則」:四種純 client 組合比較

先排除下方的 Windows 方案(只代理 Chrome)。只看純粹用 client 軟體本身(v2rayN / sing-box / Clash / NekoBox / Hiddify 這類支援 TUN 開關的軟體)做出來的四種組合。核心差異在於「攔截機制」和「路由決策」是兩件不同的事。分開看才不會混淆。

前提:「無 TUN」不等於「沒有代理」。沒有 TUN 時,client 通常還是會把系統層的 HTTP/SOCKS Proxy 設定寫進 Windows/macOS 的網路設定(不是靠虛擬網卡攔截封包,而是靠系統「知道現在有一個 proxy 存在」)。這個設定提供給整個系統使用。這和下方 Windows 方案不同:Windows 方案只把 proxy 設定給 Chrome 使用。
組合 攔截範圍 DNS Leak WebRTC Leak 風控風險 關鍵前提/坑點
① 有 TUN + 全域 全機所有流量(所有 App、UDP、TCP、ICMP 全部被虛擬網卡攔下) 極低 極低 最高 所有 App 的來源 IP 全部變成境外 VPS IP。中國實名 App 會被判定為異地登入,沒有例外
② 無 TUN + 全域 只有「遵守系統 Proxy 設定」的軟體會被導向 proxy。不遵守的軟體完全不受影響,直接直連 中 高 中 防護最不上不下的一種:沒有 TUN 的保護力,又沒有「全域」分流。DNS 和 WebRTC 兩個大洞都在。不建議使用
③ 有 TUN + 規則(whitelist) 全機所有流量先被 TUN 攔下,再依 GeoIP/GeoSite 規則庫判斷:中國流量直連,境外流量走 proxy 低 低 低 前提:DNS 路由規則必須和主路由規則保持一致。這是最常見的設定錯誤
④ 無 TUN + 規則(whitelist,下方方案的上層分類) 只有「遵守系統 Proxy 設定」的軟體流量會進到 proxy engine。engine 再依規則判斷直連或轉發 中 高 低 只保護部分軟體,並依網域分流。DNS 和 WebRTC 天生脆弱,需要額外手動加固(下方 Windows 方案是這裡最保守的子集)
③「有 TUN + 規則」最常見的設定錯誤:DNS 規則和主路由規則不一致。很多 sing-box / Xray 的設定中,「流量走哪條路」和「DNS 查詢走哪個 resolver」是兩組獨立的規則。如果只設定了「網域 A 走直連」,卻忘記同步設定「網域 A 的 DNS 查詢也用本地 resolver 解析」,就會出現「連線依規則走對了路,但 DNS 查詢洩漏出去」的情況。問題通常不在協議本身,而在規則沒有對齊。
WebRTC leak 是「無 TUN」組合的天生弱點:和全域或規則無關。不管是②還是④,只要沒有 TUN,WebRTC leak 的風險都偏高。原因是系統 HTTP/SOCKS Proxy 設定天生不涵蓋 UDP/STUN 這條路。這也是下方 Windows 方案必須在瀏覽器層額外關閉 WebRTC 的原因:系統層的 proxy 設定無法處理 WebRTC,只能在應用層(Chrome flags)手動補上。
選擇你的作業系統

Windows 架構:v2rayN + Chrome + ZeroOmega

此方案不開啟 TUN 模式,只代理 Chrome 瀏覽器流量。微信、QQ 等系統軟體全程直連,不在系統層面留下代理痕跡。這是目前最安全的低調方案。

為什麼刻意不開 TUN:TUN + 全域路由會讓微博、微信、抖音等平台看到的來源 IP 變成你的境外 VPS IP,而不是中國本地 IP。對有實名制的帳號來說,平台風控系統會把這種情況判定為「異地/非常用地點登入」。這可能觸發簡訊驗證、人臉辨識、好友驗證,甚至帳號臨時凍結。這和是否違規無關。這純粹是登入位置與帳號綁定地區不符所觸發的機制。

Step 1:v2rayN 核心設定

  • 匯入節點後,按右鍵設為活動伺服器。
  • 在底部狀態列選擇 「清除系統代理」(不可以選「自動配置系統代理」)。
  • 路由設定選擇 V4-绕过大陆(Whitelist),確保只有境外流量走代理。
  • 確認狀態列顯示本地監聽:[mixed:10808]。

Step 2:Chrome 瀏覽器加固 (防洩漏必須執行)

設定項目 操作路徑 / 指令 目的
關閉安全 DNS (DoH) 設定 → 隱私權和安全性 → 安全性 → 使用安全 DNS → 關閉 防止 DNS 查詢繞過代理而洩漏
停用 QUIC 協議 網址列輸入 chrome://flags/#enable-quic → Disabled 強制使用 TCP,避免 UDP 流量繞過 ZeroOmega
WebRTC 防洩漏 網址列輸入 chrome://flags/#enable-webrtc-hide-local-ips-with-mdns → Enabled 將本機真實 IP 替換為 mDNS 假名
沒有斷線保護(Kill Switch):因為刻意不開 TUN,Chrome 走的是應用層 SOCKS5 代理,不是系統層封包攔截。v2rayN 當機或節點斷線時,不會整台機器斷網。Chrome 會悄悄改用真實網路直連,畫面上通常看不出差異。這是 TUN 取捨的另一面(iOS 端可以開啟 Kill Switch,見下方 iOS 說明)。長時間使用時,建議偶爾重新整理 ip.sb ,確認仍顯示台灣 IP。
時區 / 語言 / 瀏覽器指紋:本頁處理的是「網站或 GFW 能否看到真實 IP 和真實 DNS 查詢」,屬於反審查範疇。系統時區、語言和 Canvas 指紋屬於反追蹤範疇。廣告商通常用這些資料跨站關聯身分。這些資料和 GFW 判斷是否科學上網基本無關。一般使用不需要額外處理。

Step 3:ZeroOmega (代理規則)

  1. 離線安裝 ZeroOmega (Manifest V3 版本)。
  2. 新建情境模式 VLESS_Proxy:協議選 SOCKS5,伺服器 127.0.0.1,連接埠 10808。
  3. 新建 Auto_Switch 模式:規則列表網址填入 gfwlist.txt 的 raw URL,情境模式選擇 VLESS_Proxy,預設選「直接連線」。
  4. 點擊「立即更新情境模式」並套用。
驗證清單:設定完成後,使用 Chrome 開啟 ip.sb (應顯示台灣 IP)、dnsleaktest.com (不應出現中國電信/聯通 DNS)、browserleaks.com/webrtc (Local IP 不應顯示 192.168.x.x)。

管理員維護

此章節供管理員(伺服器架設者)使用,一般使用者不需要閱讀。內容涵蓋日常維護、DDNS 設定、時間同步與日誌查看。

DDNS 自動更新(浮動 IP 環境必須閱讀)

如果使用住宅 IP 自架(不是 VPS),ISP 分配的是浮動 IP。這時必須設定 DDNS,讓網域始終指向最新 IP。

推薦方案:Cloudflare DDNS
  • 購買一個便宜的網域(Namecheap 或 Cloudflare Registrar,約 $1–10 USD/年)
  • 將網域的 DNS 交給 Cloudflare 管理,建立 A Record 指向目前 IP
  • 在伺服器上部署自動更新腳本(例如 ddns-go 或 Cloudflare DDNS 腳本)

伺服器時間同步

Reality 握手過程會校驗時間戳。如果伺服器與客戶端的時差超過數分鐘,很容易導致 TLS 握手靜默失敗(不會有明顯的錯誤訊息,連線就是建不起來)。

# Linux 伺服器確認時間同步狀態
timedatectl status

# 若未同步,啟用 NTP
sudo timedatectl set-ntp true
客戶端提醒:Windows 和 iOS 端也必須保持系統時間準確(開啟自動同步時間)。

Xray 核心版本更新

定期更新核心,以確保安全性和效能。

環境 更新方式
3x-ui 面板 面板內「Xray 設定」→「更新核心」,最簡便
手動部署 (Linux) 重新執行安裝腳本,或手動下載 GitHub releases 並替換 binary
手動部署 (Windows) 下載 Xray-windows-64.zip → 關閉 Xray → 覆蓋 xray.exe → 重新執行 start.bat

查看連線日誌

如果需要排查連線問題,或確認使用者流量,可以在設定檔中開啟日誌記錄。

// 在 config.json 的 log 區塊加入:
"log": {
  "loglevel": "warning",
  "access": "access.log",
  "error": "error.log"
}

儲存後重啟 Xray 服務。日誌檔案會出現在 xray 執行檔所在的資料夾(或指定的絕對路徑)。

新增或移除使用者

  • 3x-ui 面板:直接在網頁介面「入站列表」中新增或刪除使用者,不需要手動編輯 JSON。
  • 手動編輯:用文字編輯器開啟 config.json,在 clients 陣列中新增或刪除使用者物件,然後重啟服務。
# 產生新 UUID 的指令
xray uuid
# 或
uuidgen

Hysteria2 masquerade 候選網域批量測試

用 PowerShell 批量測試 masquerade 候選網域的 TLS handshake 延遲和抖動,並用 Alt-Svc 標頭判斷是否支援 h3:

powershell -ExecutionPolicy Bypass -File .\hysteria2-masquerade-test.ps1 -Domains "www.bing.com","www.cloudflare.com","dl.google.com" -Samples 8

輸出會依平均延遲排序,並存成 CSV。挑選原則:優先看Jitter(抖動)小、Success 全過的網域。AvgMs 低是加分項,不是唯一標準。避開高知名度或高敏感的網域(例如 microsoft.com,實測常出現延遲或抖動異常)。避免和你的 Reality dest 使用同一個網域(例如已用 Oracle/Samsung 當 dest 時,masquerade 就換成別的網域)。這樣可以降低組合特徵被關聯分析的理論風險。

腳本檔案另外保存,不放進本文件。保存在伺服器的同一個資料夾,以便查閱。

注意:如果目標網域是 Google 系(例如 dl.google.com),選用前必須先請中國大陸端的人實際測試,確認這個網域本身沒有被封鎖。你自己這邊測到的延遲,只能證明「你連得到」,不能證明「探測者(中國大陸端)連得到」。兩者是完全不同的測試對象。可用 blocky.greatfire.org 輔助查詢。