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 的原創實作,也是最佳實作。
雷達圖評估 核心特色- 支援協議: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 |
VLESS
一種輕量、低開銷的代理協議。VLESS 是 VMess 的簡化改進版。
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 之間」的折衷方案。不必特地換過去。
Hysteria2
基於 QUIC(UDP)的代理協議,有自己的官方引擎。
- 特色:速度快,在弱網環境表現好。核心賣點是 Brutal 擁塞控制。傳統 TCP/BBR「一丟包就降速」,Brutal 則相反。你告訴 Brutal 頻寬是多少,Brutal 就按固定速率推送。丟包時 Brutal 也不降速。Brutal 對推流(上傳)友善。UDP 比 TCP 更不容易卡頓。
- 偽裝:有流量混淆,有一定的抗封鎖能力(Salamander,2026 年 5 月起新增 Gecko)。
- 缺點:在某些中國 ISP 環境中,UDP 會被 QoS 限速。
- 適合情境:對速度要求高的場景,例如推流到 Twitch,或下載大檔案(必須確認頻寬填寫正確)。
1. 家裡寬頻同步速率(例如 500/500): 錯誤。瓶頸在中國到台灣的跨境這一段。本地同步速率再高,也無法代表跨境容量。
2. 你打算用掉的量(例如手機直播頂多 20/20): 也不對。這是用量,不是容量。這個數字沒有為 FEC 和重傳開銷留下緩衝。稍有波動就會到達上限。
3. 實測這條跨境路徑的真實容量——正確答案。用 iperf3 透過隧道,在平常直播的時段(尤其是晚高峰)量出穩定吞吐量。取實測值的八到九成填入。
但這不等於 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
WireGuard
現代化 VPN 協議,程式碼極簡,效能優秀。
SoftEther
多協議 VPN 伺服器軟體。同時支援自家協議、OpenVPN 相容模式、L2TP/IPSec 和 SSTP。曾以偽裝 HTTPS(443 port)聞名。
OpenVPN
最老牌、生態最成熟的 VPN 協議。.ovpn 設定檔的通用性極高。
協議選擇建議
| 使用情境 | 推薦協議 | 備註 |
|---|---|---|
| 一般科學上網(看影片、使用 Discord) | VLESS + Reality + Vision | 最穩定,偽裝性最強 |
| 高速推流 / 弱網環境(固定寬頻 / VPS) | Hysteria2 | UDP 特性,需注意 ISP QoS |
| 手機直播(使用電信 SIM 卡資料) | VLESS + Reality + Vision | 行動資料的 UDP 更容易被電信商限速,見下方「手機直播情境」 |
| 中國科學上網 | 不可以用 WireGuard | 特徵明顯,會立即被封鎖 |
手機直播情境的功耗考量
若情境是手機直接執行 VPN client 直播(而非 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 的抗丟包能力比偽裝能力更重要。
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 + 直播推流 | 未直接驗證。住宅寬頻的上傳頻寬通常較窄,手機直播疊加上去,理論上仍可能顯眼(推測)。需要實測 | 有實戰案例(見下方混淆變數說明),同樣不能單獨歸因於協議 |
要得到乾淨的結論,必須做交換測試:在住宅 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 直播的協議優先序:① 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 → 平台伺服器
| 組合 | 例子 | 是否有結構性問題 |
|---|---|---|
| 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 抗丟包機制疊加,理論上更適合弱訊號環境(推測)。但仍待實測 |
實務建議
- 電腦端與手機端拆成兩套獨立設定,不共用同一套判斷邏輯。兩者的網路特性(固網與行動資料)差異太大。
- 手機端再依「訊號好壞」做動態切換,不建議固定使用一個協議。上方「自動切換邏輯」的健康判斷指標(RTT 持續超過 200ms、封包遺失率超過 3%、60 秒內重連 2 次以上),可以直接沿用在手機端的判斷邏輯上。
- 未來上 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。依當地審查和網路品質,實測後決定 |
- 「科學上網」永遠會放大風險,「直播」也會放大風險。兩者疊加(情境 7、8,尤其是情境 7)時,風險最高。因此專業戶外直播團隊使用多卡 Bonding 和 RPi5 分流架構,分攤這個雙重風險,而不是只用一支手機。
- 手機和電腦的差異,本質是「行動網路」和「固網」的差異,不是裝置效能或系統的差異。如果你的手機連接穩定的 Wi-Fi(不是電信資料),應該用「電腦上網/直播」那一列的邏輯判斷。這和插著 SIM 卡使用 4G/5G 的風險等級完全不同。
- 不科學上網的情境(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」,更高階,晚高峰更穩 |
線路測試指令(雙向完整版)
商家宣傳的線路不可以完全相信,必須自己測試。測試分兩個方向:去程(你的電腦 → 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 取樣次數
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
- 連線建立後的實際傳輸速度,走的是「中國 client ↔ 你的伺服器」直接對接,完全不經過偽裝目標網站。偽裝目標的速度,和你平常使用的速度沒有關係。
- 但每次新連線的「握手」階段,需要你的伺服器連線到偽裝目標,取得真實憑證。這段路徑的延遲和穩定度,會影響「連線建立的速度和穩定性」。這才是延遲測試真正有意義的地方。
選擇 Reality 的偽裝目標網域(SNI)時,除了延遲,還必須確認目標支援 TLS 1.3 和 H2,而且沒有開啟 ECH(目標一旦開啟 ECH,Reality 偽裝就會失效)。以下提供 PC 和 VPS 兩端各三種批量測試腳本。
- 用 openssl 批量腳本先大範圍篩選,快速排除 ALPN h2 FAIL 的候選。
-
對剩下的候選,再用
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
實測結果:優質網域排名(作者實測,僅供參考)
一線推薦(獨立 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。因此優先度最低 |
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 自架 | 自架 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 選擇策略」 |
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 後,回到列表頁面:
- 點擊 Inbound 右側的「二維碼 (QR Code)」圖示。
- 將 QR Code 截圖,或點擊「複製連結」。
- 傳給朋友。朋友使用 Shadowrocket (iOS) 或 v2rayN (Windows) 掃碼或貼上,即可連線。
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 而定 | 可開(見下方「包含所有網路」) |
為什麼選擇「無 TUN + 規則」:四種純 client 組合比較
先排除下方的 Windows 方案(只代理 Chrome)。只看純粹用 client 軟體本身(v2rayN / sing-box / Clash / NekoBox / Hiddify 這類支援 TUN 開關的軟體)做出來的四種組合。核心差異在於「攔截機制」和「路由決策」是兩件不同的事。分開看才不會混淆。
| 組合 | 攔截範圍 | 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 方案是這裡最保守的子集) |
Windows 架構:v2rayN + Chrome + ZeroOmega
此方案不開啟 TUN 模式,只代理 Chrome 瀏覽器流量。微信、QQ 等系統軟體全程直連,不在系統層面留下代理痕跡。這是目前最安全的低調方案。
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 假名 |
ip.sb
,確認仍顯示台灣 IP。
Step 3:ZeroOmega (代理規則)
- 離線安裝 ZeroOmega (Manifest V3 版本)。
-
新建情境模式
VLESS_Proxy:協議選 SOCKS5,伺服器127.0.0.1,連接埠10808。 -
新建
Auto_Switch模式:規則列表網址填入gfwlist.txt的 raw URL,情境模式選擇VLESS_Proxy,預設選「直接連線」。 - 點擊「立即更新情境模式」並套用。
ip.sb (應顯示台灣 IP)、dnsleaktest.com
(不應出現中國電信/聯通 DNS)、browserleaks.com/webrtc
(Local IP 不應顯示 192.168.x.x)。
管理員維護
此章節供管理員(伺服器架設者)使用,一般使用者不需要閱讀。內容涵蓋日常維護、DDNS 設定、時間同步與日誌查看。
DDNS 自動更新(浮動 IP 環境必須閱讀)
如果使用住宅 IP 自架(不是 VPS),ISP 分配的是浮動 IP。這時必須設定 DDNS,讓網域始終指向最新 IP。
- 購買一個便宜的網域(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
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 就換成別的網域)。這樣可以降低組合特徵被關聯分析的理論風險。
腳本檔案另外保存,不放進本文件。保存在伺服器的同一個資料夾,以便查閱。