Clash 代理協定與核心選型參考

Ⅰ協定譜系總覽:從 SOCKS5 到 QUIC 世代

代理協定是用戶端與遠端伺服器之間的一套約定:資料以什麼格式封裝、用什麼方式加密、憑證如何驗證、傳輸走 TCP 還是 UDP。Clash 系用戶端的定位是規則的執行者與協定的實作者——它本身不發明協定,而是把各社群已公開的協定逐一實作,交由規則引擎統一調度。因此選用哪個協定,實際上是在選用伺服器端與用戶端共同支援的一種封裝格式;用戶端能力再強,也跑不動伺服器不提供的協定。

還要區分協定的兩個方向。輸入方向是本機應用程式如何連進用戶端:瀏覽器與系統代理走 HTTP 或 SOCKS5 連接埠,這兩個協定只負責進門,不會出現在訂閱裡。輸出方向才是本卷的主角:用戶端把流量封裝成 SS、VLESS 等格式送往遠端伺服器。日常所說的選協定,選的始終是輸出這一側。

譜系與誕生背景

SOCKS5 與 HTTP 代理是最早的通用代理形式,只負責轉發、不定義加密,今天仍作為 Clash 的本機輸入協定使用。約 2012 年,Shadowsocks 把對稱加密引入代理協定:把流量加密後傳給遠端,伺服器解密再轉發,協定本體維持極簡,十餘種程式語言都有實作。約 2016 年 V2Ray 專案發布,其原生協定 VMess 走了另一條路:全量加密、時間戳驗證、可更換傳輸層,把可設定性推到很高的位置。約 2018 年出現的 Trojan 提出偽裝優先:讓代理連線在外形上與一次普通 HTTPS 存取一致,驗證只靠一個密碼。約 2020 年,VLESS 作為 VMess 的簡化版問世,把加密職責交還給 TLS,標頭更輕;同一時期,基於 QUIC 的 Hysteria 與 TUIC 先後出現,用 UDP 換取弱網下的吞吐,Hysteria2 是前者的修訂版。六條線索,構成今天 Clash 設定裡 proxies 段的主要候選。

條目速覽

下表把六類協定並排著錄,先建立整體印象,細節見後續各章。

讀這張表抓住三個維度就夠:封裝與外形——協定是否自帶偽裝、流量呈什麼形態;開銷與效能——交握幾個往返、加密占用多少處理器、弱網下吞吐維持如何;生態與支援度——伺服器端是否普遍提供、用戶端核心是否實作、訂閱格式是否涵蓋。後文每一條目都按這三維展開。

與規則引擎的關係

必須分清兩個層面:協定決定單一連線怎麼發送,規則決定哪個連線走哪條協定。Clash 的規則引擎在協定之上運作:一份設定裡可以並存 SS、VLESS、Hysteria2 三種節點,由規則按網域、IP 段、程式名稱把流量分給不同策略群組,策略群組再綁定具體節點。因此選協定與分流設定是兩件事,前者看本卷,後者的完整實戰請參見《Clash 規則分流設定實戰》一文。

ⅡShadowsocks:輕量加密的起點

Shadowsocks(縮寫 SS)是 Clash 支援歷史最久的代理協定,也是訂閱裡出現頻率最高的一類。它的設計目標一句話就能說完:用盡可能少的交握與盡可能簡單的格式,把 TCP 與 UDP 流量加密轉發到遠端。

設計目標與封裝格式

SS 的連線沒有交握階段:用戶端把目標位址、連接埠與負載一起加密後直接送出,伺服器用同一把預共用金鑰解開,讀出目標位址再轉發。金鑰由使用者密碼經金鑰派生函式產生,主金鑰之外每個連線再派生子金鑰,避免重放攻擊。因為沒有協定交握,SS 在 TCP 系協定裡首字節延遲最低;因為格式簡單,一個完整實作只需幾百行程式碼,從路由器韌體到瀏覽器擴充功能都有移植版本。

SS 原生定義了 UDP 中繼:用戶端把 UDP 資料包加密後送到伺服器代為收發,遊戲、語音通話與 QUIC 建立連線都依賴這項能力。Clash 設定裡的 udp: true 即是開啟此開關;節點若用於遊戲,除開啟開關外還應確認服務商未限制 UDP 中繼。

SS 還有一組外掛生態(如 simple-obfs、v2ray-plugin),可在 SS 外層再包一層混淆或 WebSocket 傳輸,mihomo 透過 plugin 與 plugin-opts 欄位支援其中一部分。外掛屬於疊加層,不會改變 SS 本體格式。

加密套件:遷移至 AEAD

早期 SS 使用 aes-256-cfb、chacha20-ietf 這類串流加密,只加密不驗證完整性,後來被證實存在可被主動偵測利用的缺陷,社群遂整體遷移到 AEAD(具驗證的加密)。目前可用的三大套件是 aes-128-gcm、aes-256-gcm 與 chacha20-ietf-poly1305:前兩者在具 AES-NI 指令集的桌上型與伺服器處理器上幾乎零開銷;後者不依賴硬體指令,在手機與低階路由器的 ARM 晶片上反而更快。其後社群又提出 2022-blake3-aes-128-gcm 等新套件,shadowsocks-rust 與 mihomo 均已實作,以 BLAKE3 進行金鑰派生並強化重放防護,新部署可優先考慮。

適用場景與限制

SS 的限制同樣來自它的簡潔:協定沒有偽裝層,加密流量在外形上是長度隨機、內容高熵的資料流,與正常 HTTPS 的 TLS 記錄形態不同;協定也不定義伺服器端的多使用者管理,一個連接埠對應一把金鑰。因此 SS 適合作為夠用就好的通用選項——實作廣泛、開銷低、維護省心;追求外形偽裝時,則看第四章的 Trojan 與第三章的 VLESS。

用戶端設定要點

在 Clash 設定裡,SS 節點只需 server、port、cipher、password 四項必填,udp 控制 UDP 轉發。cipher 必須與伺服器端嚴格一致——套件寫錯是 SS 節點連不上的首要原因,排查時先核對這一行,再核對密碼與連接埠。若服務商提供的是 ss:// 分享連結,匯入用戶端時會自動展開成下列欄位,無需手動輸入。

proxies:
  - name: "ss-aead"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

ⅢVMess 與 VLESS:V2Ray 系的兩次迭代

VMess 與 VLESS 同出自 V2Ray 專案(其後分裂出 V2Fly 與 Xray 等分支):前者是專案的原生主力協定,後者是反思前者複雜度之後的減負版。理解這兩代之間的取捨,就理解了代理協定的一個核心分歧——加密應該放在哪一層。

VMess:全量加密的設計

VMess 的思路是協定自身完成全部安全機制:請求標頭含使用者 UUID、時間戳與驗證,整個連線以 AES-128-GCM 或 ChaCha20-Poly1305 加密,不依賴外層 TLS。時間戳驗證要求用戶端與伺服器時鐘誤差在約兩分鐘以內,這是 VMess 排錯時最先要檢查的地方——裝置時區錯亂、未開啟網路校時都會觸發驗證失敗。早期 VMess 的 alterId 參數用於派生多份金鑰,後來被證實會削弱安全性,新版實作已將其棄用,設定裡見到 alterId 非零應視為過時寫法。

VMess 的 UUID 同時承擔使用者識別碼,伺服器端據此進行多使用者分流與流量統計;這也是 vmess:// 分享連結欄位最多的原因——一段 Base64 編碼的 JSON,要裝下位址、連接埠、UUID、傳輸層、TLS 開關與偽裝網域。

VLESS:把加密交還給 TLS

VLESS 的命名即態度:去掉 VMess 的加密層,協定標頭只保留 UUID 與極少數控制欄位,加密完全交給外層 TLS。好處是雙重的:標頭更短,處理器不再做二次加密;搭配 XTLS Vision 流控(flow: xtls-rprx-vision)時,TLS 記錄可以直通轉發,再省一次加解密複製。代價是 VLESS 必須搭配 TLS 使用——裸跑的 VLESS 沒有保密性可言,mihomo 等核心也只接受 TLS 形態的 VLESS 節點。

Xray 分支後來在 VLESS 之上又提出 REALITY 形態:不簽發自己的證書,而是借用真實網站的 TLS 外形完成交握,省去網域與證書維護,mihomo 以 reality-opts 欄位支援。它屬於 TLS 層的又一種取捨:部署更簡單,設定項更多,一般使用者仍以服務商提供的訂閱為準。

傳輸層:WS、gRPC 與中轉

V2Ray 系的另一塊拼圖是傳輸層(network):ws 把流量裝進 WebSocket 訊框,grpc 裝進 HTTP/2 串流,兩者都能套 TLS 並偽裝成一般網站流量。這套組合的實際價值在於可以掛在 CDN 之後:網域解析到 CDN,CDN 回源到伺服器,真實位址不外露,還能借用 CDN 的接入點改善繞路線路。Clash 系核心完整支援 ws 與 grpc 傳輸,設定裡以 network、ws-opts、grpc-opts 欄位描述。

二選一的結論

新部署選 VLESS + TLS,舊節點維持 VMess 即可。VMess 的全加密在沒有 TLS 的場景仍有意義;但在有證書的條件下,VLESS 的低開銷與直通轉發全面占優。對應設定形如:

proxies:
  - name: "vless-vision"
    type: vless
    server: example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000000"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: example.com

ⅣTrojan:偽裝優先的設計哲學

Trojan 的設計文件開篇即給出判詞:與其費心把代理流量混淆成別的樣子,不如讓它直接就是別的樣子。Trojan 連線在外形上就是一次標準的 TLS 連線,協定本體藏在 TLS 之內,驗證只靠一個密碼的雜湊值。

TLS 即本體

Trojan 伺服器監聽 443 連接埠,對外表現為一個正常的 HTTPS 網站:證書有效、交握標準;收到無法驗證的連線時,可以把流量回退(fallback)給一個真實網站處理。驗證通過後,TLS 記錄內承載的是極簡的 Trojan 請求標頭:密碼雜湊、目標位址、負載。協定本身不做任何加密——加密完全由 TLS 提供。這與 VLESS 的思路一致,只是 Trojan 出現更早、格式更簡單。

Trojan 的偽裝還依賴一個細節:伺服器必須真的像網站。僅有有效證書、443 連接埠上卻沒有任何網頁內容的網站,在主動存取偵測下反而顯眼,因此多數部署會在 fallback 後掛一個真實頁面。這一層屬於伺服器維運範疇,用戶端無需關心,但選型時應知道:像不像,取決於伺服器端的完成度。

與 VMess + TLS 的異同

同樣是在 TLS 裡跑代理,Trojan 與 VMess + WS + TLS 的差異在層數:後者是 TLS 套 WebSocket 再套 VMess 三層封裝,前者只有 TLS 套 Trojan 兩層。層數少意味著開銷小、實作精簡,也意味著可設定項少——Trojan 沒有傳輸層花樣,只有 TCP + TLS 一種形態。需要 CDN 中轉時,Trojan 也可以走 WebSocket(多數核心支援),但那就回到了多層封裝的老路。

Trojan 的 UDP 支援走協定內命令字:UDP 資料包被裹進 TLS 串流內傳輸,用戶端設定同樣以 udp: true 開啟。因為 UDP 被裹在 TCP 裡,丟包敏感場景下它繼承了 TCP 的全部特性——這一點與第五章原生 QUIC 的 UDP 轉發形成對照。

部署前提與用戶端設定

Trojan 的簡潔是有代價的:部署者須持有網域與有效證書,證書通常經 ACME 自動簽發,網域解析到伺服器。對純使用方而言這些皆由服務商完成,用戶端側只需 server、port、password 與 sni 四項。sni 必須與證書網域一致;skip-cert-verify: true 會關閉證書驗證,等於放棄 TLS 的防偽能力,只適用於自簽證書的測試場景暫時使用,正式設定應保持 false。

proxies:
  - name: "trojan-tls"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

效能方面,Trojan 的開銷幾乎等於一次純 TLS 連線:交握兩到三個往返(TLS 1.3 可重複使用連線縮短),傳輸期一次對稱加解密。桌上型與伺服器上這與 HTTPS 瀏覽無異;在行動端,TLS 連線保持與 TCP 保活是主要的耗電來源,詳見第六章。

ⅤHysteria2 與 TUIC:QUIC 世代的速率協定

前四章的協定全部跑在 TCP 上。TCP 的可靠傳輸是有代價的:丟包時整條串流排隊等重傳(隊頭阻塞),高丟包線路上吞吐斷崖式下跌。QUIC 把可靠傳輸搬進使用者空間、跑在 UDP 之上,允許按串流獨立重傳,還附帶 0-RTT 交握與連線遷移兩件基礎設施大禮。Hysteria2 與 TUIC 是 QUIC 代理協定裡實作最廣的兩個。

Hysteria2:速率優先

Hysteria2 是 Hysteria 的修訂版,協定做了一次大瘦身:驗證簡化、控制面收斂,核心賣點落在壅塞控制上。它自帶的 Brutal 壅塞控制不隨丟包退讓,按使用者宣告的頻寬目標持續傳送;在丟包率高但實體頻寬充足的連線上(跨洲無線、壅塞的晚間高峰出口是典型情況),吞吐可達 TCP 系協定的數倍。代價同樣直白:Brutal 不看網路狀況,頻寬目標填高了會擠占同連線上其他流量,也可能觸發電信業者對 UDP 的限速策略。設定裡的 up 與 down 欄位就是這條速率宣告,單位 Mbps,應按伺服器實際頻寬填寫,而不是越高越好。

Hysteria2 生態還有一項 mihomo 已實作的實用特性:連接埠跳躍。伺服器監聽一個連接埠段,用戶端按約定在段內跳動送封包,設定裡以 ports 欄位寫成區間形式。此特性用於規避單連接埠限速,屬於連線層技巧,不影響協定本體格式。

TUIC:低開銷的 QUIC 封裝

TUIC 的目標與 Hysteria2 不同:追求 QUIC 之上盡可能少的額外開銷。協定原生支援 UDP 轉發,且提供兩種 UDP 模式——native 把 UDP 資料包直接對應進 QUIC 資料包,quic 則把 UDP 封包也納入可靠串流傳輸;前者適合遊戲、語音這類對延遲敏感的真實 UDP 場景。TUIC 沿用 QUIC 自帶的壅塞控制,不做激進加速,行為更守規矩,在 UDP 被限速的網路裡退化得更平緩。

QUIC 把壅塞控制做成了可插拔:TUIC 的 congestion_control 欄位可選 bbr、cubic 等演算法。粗略地說,cubic 是保守的通用預設,bbr 依頻寬與延遲建模、在緩衝較大的連線上更穩定。一般使用者保持預設即可;知道有這個選項,速度不對時便多一個排查方向。TUIC 的 heartbeat_interval 控制心跳間隔,直接影響待機耗電,行動端可放寬到數秒以上。

連線遷移與 0-RTT

QUIC 的兩件大禮值得單獨著錄。0-RTT:再次連線同一伺服器時,首個封包即可攜帶負載,省去交握往返,代理的冷啟動體感接近直連。連線遷移:連線以 Connection ID 識別而非四元組,手機從 Wi-Fi 切到行動網路、或基地台間切換導致 IP 變化時,連線不中斷、不重建,正在進行的下載與通話無感知。這兩點對行動端的意義遠大於桌上型裝置,第六章會再次引用。

proxies:
  - name: "hy2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: 30
    down: 200
    sni: example.com

Ⅵ速度、資源占用與行動端電量:橫向對比

協定對比最容易被誤讀成哪個最快。誠實的答案是:線路良好時,六類協定的吞吐差異通常小到難以察覺,瓶頸在伺服器頻寬與電信業者線路;協定差異只在三個邊緣場景顯現——交握延遲、弱網吞吐、裝置開銷。本章依這三軸對照。

另一個常被高估的指標是跑分。測速網站打滿頻寬的能力,更多取決於伺服器出口與晚間高峰壅塞;協定跑分的參考價值,不如同一線路換協定各測三次的樸素對照。若要做自己的實驗:固定伺服器與時段,只換協定類型,各測三次取中位數,再換時段複測一輪——變數只剩協定時,結論才有意義。

交握與首字節延遲

TCP 系協定先完成 TCP 交握(一個往返),帶 TLS 的再加 TLS 交握(TLS 1.3 一個往返,重複使用連線可歸零);SS 沒有協定交握,總開銷最低,Trojan 與 VLESS 次之。QUIC 系首次連線一個往返,再次連線 0-RTT。在 200 毫秒級延遲的跨洲線路上,再次存取場景下 Hysteria2 與 TUIC 的首字節能比 TCP + TLS 系快出近半秒——瀏覽網頁、短連線 API 呼叫時體感明顯。

處理器、記憶體與裝置開銷

傳輸期的處理器消耗主要是對稱加密:具 AES-NI 的 x86 裝置上,AES-GCM 單核心可跑數 Gbps,協定開銷可以忽略;沒有 AES 指令的 ARM 裝置上,ChaCha20-Poly1305 比 AES-GCM 快約兩到三倍,這是行動端建議使用 chacha20 系套件的原因。記憶體方面,各協定單一連線占用都在 MB 級以下,真正的記憶體大頭是核心的規則集與連線追蹤表,與協定無關。路由器等百兆級處理器的裝置上,避開雙層加密(VMess 內加密再套外層 TLS)能省下可觀餘量——這是 VLESS 與 Trojan 相對 VMess 的實在優勢。

行動端電量

行動端的耗電大頭不是加解密,而是射頻模組的喚醒次數。TCP 長連線依賴保活封包維持位址對應,每次喚醒都耗電;Wi-Fi 切行動網路時 TCP 連線斷裂,重連交握又是一輪射頻活動。QUIC 的連線遷移讓切換不中斷,0-RTT 讓必要的重連更快,兩者疊加,Hysteria2 與 TUIC 在頻繁移動的使用日裡,電量與流量開銷都低於 TCP 系。反向因素也存在:心跳間隔若設得過短,待機喚醒反而更密,相關參數應依寧長勿短的原則調整。

六維對照表

表中沒有全能冠軍:SS 贏在實作廣度與低延遲,QUIC 系贏在弱網與行動場景,Trojan 與 VLESS 贏在外形與低開銷。實際選擇時先看服務商提供什麼(第八章),再在已提供的協定裡依本章三軸取捨。

Ⅶ核心家族:原版 Clash、Meta 與 mihomo

Clash 一詞在生態裡同時指三件事:一個核心、一種設定格式、一族用戶端。分清這三層,是理解一切相容性討論的前提。核心是實際運作的程式:監聽本機連接埠、解析規則、按協定送出封包;用戶端是核心的圖形外殼;設定格式是兩者之間的契約。

原版 Clash 的歸檔

原版 Clash 核心由 Dreamacro 維護,以 Go 撰寫,確立了 YAML 設定格式、規則引擎與策略群組體系——今天所有 Clash 系用戶端的語法都源自它的定義。2023 年末,作者將倉庫歸檔、停止維護,閉源的 Premium 分支同步停更。歸檔不代表失效:原版核心至今仍能運作,SS、VMess、Trojan 等舊協定照常運作;但 Hysteria2、TUIC、VLESS 等新協定與 rule-set 規則集等新特性,永遠不會再出現在原版裡。

Clash Meta 與 mihomo 的繼承

Clash Meta 是社群在原版停更前就已開始的強化分支,目標是補齊原版缺失的協定與能力;原版歸檔後,它成為事實上的繼承者,並在其後更名為 mihomo。相對原版,mihomo 的主要增量包括:VLESS、Hysteria2、TUIC、WireGuard 等協定支援;rule-set 規則集,把大量規則編譯成二進位格式按需載入,取代逐行文字比對;DNS 模組的 nameserver-policy、fallback-filter 等細粒度控制;以及 TUN 輸入、程式名稱比對等系統級能力。今天活躍的用戶端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——全部以 mihomo 為核心。生態各專案的來龍去脈,《Clash 開源生態梳理》一文有完整譜系,本卷只取與選型相關的部分。

設定相容性

相容方向是單向的:為原版寫的設定,絕大多數能在 mihomo 上原樣運作;為 mihomo 寫的設定,用到新欄位的部分原版不認。實務上只需記住兩點。其一,舊用戶端(Clash for Windows、舊版 ClashX)只認原版欄位,訂閱裡出現 hysteria2 類型節點會被跳過或報錯。其二,mihomo 對個別欄位做過語意調整,例如 dns 段的 default-nameserver 必填化;從原版遷移設定時若啟動報錯,按報錯行逐項對照官方文件即可,通常是補齊欄位而非改寫。

用戶端與核心的對應

安裝包頁的清單按此編排:全平台首推的 Clash Plus,桌面主流的 Clash Verge Rev 與 FlClash,Android 的 Clash Meta for Android,均為 mihomo 系;標注已停止維護的 Clash for Windows 與 ClashX Meta 停留在舊核心時代,僅作歸檔保留。在圖形用戶端裡,核心切換通常是一個開關:Clash Plus 與 Clash Verge Rev 在設定頁提供核心版本與更新通道,FlClash 把核心內嵌、隨用戶端整體升級。一般使用者無需手動替換核心二進位檔;手動替換屬於進階操作,替換後先用 -t 參數驗證設定再啟動。實用結論是:新裝一律選 mihomo 系用戶端,舊用戶端能跑則跑、壞了再遷移。

Ⅷ訂閱格式與設定相容性

訂閱是服務商與用戶端之間的運輸格式:一個 URL,用戶端定期拉取,取得一批節點與規則。生態裡並存兩種形態:Clash 原生訂閱(一份完整 YAML)與通用分享連結(一組 ss://、vmess:// 連結的合集)。mihomo 系用戶端兩種都能匯入,但兩者資訊量不同。

Clash 原生訂閱

Clash 訂閱回傳的是一份完整或近乎完整的 config.yaml:proxies 段列出節點,proxy-groups 段預置策略群組,rules 段帶分流規則。服務商在訂閱裡預先排好自動選擇、手動選擇、兜底等策略群組,使用者匯入即可使用。好處是規則與節點同源維護,服務商更新規則時使用者無感;代價是各家規則取向不同,換服務商等於換一整套分流習慣。mihomo 系用戶端匯入 Clash 訂閱時,通常允許選擇僅匯入節點或整份採用:前者保留本機規則,後者連規則一起換成服務商版——理解這個開關,能避免規則突然被覆蓋的困惑。

通用分享連結與訂閱轉換

通用訂閱回傳按行排列的分享連結:ss:// 與 trojan:// 是 URI 格式,vmess:// 是 Base64 編碼的 JSON,vless://、hysteria2://、tuic:// 各有 URI 約定。這類訂閱只含節點、不含規則,用戶端匯入後套用自己內建的規則範本。把通用訂閱翻譯成 Clash 格式的服務稱為訂閱轉換:線上服務或自架程式按範本產生 YAML。轉換的隱私含義要清楚:訂閱連結裡包含伺服器位址與憑證,經第三方轉換等於把節點資訊交給對方——敏感節點應使用自架轉換,或用戶端內建的解析能力(mihomo 系用戶端大多支援直接匯入通用訂閱)。

欄位層面的核心差異

同一節點在不同核心裡的欄位寫法大體一致,差異集中在三處。其一,新協定欄位:hysteria2 的 up 與 down、tuic 的 udp_relay_mode 等只有 mihomo 認得。其二,傳輸層巢狀結構:ws-opts 下的 headers、grpc-opts 的 service-name,各家解析器對預設值的容忍度不同。其三,規則段:rule-providers 與 rule-set 是 mihomo 擴充功能,原版核心遇到會報錯。手動修改訂閱 YAML 時,改完用用戶端的設定驗證或核心的測試參數跑一遍,比直接重啟排錯更快:

mihomo -d /etc/mihomo -t

訂閱在 mihomo 設定裡還有更工程化的形態:proxy-providers 把節點清單宣告為外部來源,依 interval 定時刷新,health-check 定時測速,配合 url-test 策略群組實現自動擇優。服務商訂閱本質上就是一個遠端 proxy-provider;理解這層抽象後,多訂閱並存、本機節點與訂閱混合編排,都是同一機制的排列組合。

訂閱解決節點從哪來,規則解決流量往哪去。訂閱自帶的規則若不合用,可在用戶端覆寫或自建規則集;規則語法、比對順序與 MATCH 兜底的完整寫法,參見《Clash 自訂規則寫法詳解》與《Clash 規則分流設定實戰》兩文,本卷不再展開。

Ⅸ依使用場景選型:決策表與總原則

在把前八章的事實併入決策表之前,先立一條總原則:協定選擇的自由度大半在服務商一側。純使用方的真實決策順序是——先看訂閱提供了哪些協定,再依場景在已提供的協定裡挑選;自架伺服器的一方才有完整的協定選擇權,其考量也列於本章。

桌面日常:以穩為先

桌面場景線路穩定、裝置效能充裕,協定差異最小,直接用訂閱預設節點即可;同一訂閱提供多種協定時,優先選 VLESS 或 Trojan(低開銷),或 SS(低延遲)。用戶端層面,全平台首推 Clash Plus:mihomo 核心、中文介面,設定覆寫與視覺化編輯齊全,下載與安裝細節見安裝包頁。

行動端:電量與切換

手機場景的兩個痛點是網路切換與待機耗電。訂閱裡若有 Hysteria2 或 TUIC 節點,行動網路下優先使用:連線遷移讓 Wi-Fi 與行動網路互切不中斷,0-RTT 縮短必要的重連時間。若只有 TCP 系節點,把保活類參數放寬、關閉用不到的 UDP 轉發,也能省下一截電量。iOS 與 Android 的具體用戶端與匯入步驟,入門指南有分平台的主線說明。

遊戲與即時語音視訊

遊戲、語音與視訊會議對 UDP 與延遲最敏感。優先選用 udp: true 可用的節點;QUIC 系(尤其 TUIC 的 native 模式)在行動網路下表現最穩定。若希望遊戲走代理,記得把遊戲程式或網域導向延遲最低的策略群組——協定決定單一連線品質,規則決定它有沒有被用上。

弱網與高丟包線路

跨洲、晚間高峰、無線中繼這類丟包率長年偏高的連線,是 QUIC 系的主場:Hysteria2 依宣告頻寬持續傳送,吞吐維持能力顯著優於 TCP 系;TUIC 行為溫和,適合 UDP 可能被限速的環境。使用 Hysteria2 時 up 與 down 務必依真實頻寬填寫,虛高會讓壅塞惡化。若 UDP 整體不可用,退回 SS 或 Trojan 並接受吞吐折損——這是實體限制,不是設定問題。

路由器與伺服器

路由器、NAS 與伺服器上沒有圖形介面,直接跑 mihomo 核心是最乾淨的方案:一份 config.yaml 加一個開機自動啟動服務即可。低效能路由器的協定取捨遵循第六章:優先 SS(chacha20 系)或 VLESS,避開雙層加密;記憶體吃緊時用 rule-set 取代大型文字規則。OpenWrt 旁路由的完整部署紀錄見《OpenWrt 路由器部署 mihomo 核心》一文。

自架伺服器

自架一側的決策鏈是:有網域與證書,選 Trojan 或 VLESS + TLS,外形與開銷俱佳;不想維護網域證書,選 SS(2022 系套件),最省心;線路丟包嚴重且 UDP 通暢,加掛 Hysteria2,與 TCP 系並存依場景切換。協定之外,自架更要緊的是系統更新、金鑰強度與管理介面暴露,這些超出本卷範圍,但重要性不低於協定本身。

決策表

協定是連線的一環,不是全部:規則決定分流是否聰明,DNS 決定解析是否乾淨,核心與用戶端決定能力邊界——三者與協定同等重要。DNS 的 nameserver 與 fallback 分工見《Clash DNS 設定詳解》,常見連線異常的排查路徑收錄在常見問題頁。讀完本卷仍不確定時,回到入門指南先把預設設定跑通,再逐項替換實驗,是最不容易迷路的順序。