協定手冊:代理協定與核心技術參考

A協定總覽:六種協定的誕生背景與設計取捨

Clash 生態裡常見的六種協定,可依誕生順序排成一條演化線:Shadowsocks 最早,VMess 與 Trojan 屬於中間一代,VLESS、Hysteria2 與 TUIC 是較新的方向。每一代都在回應上一代暴露出的問題,因此沒有「全面勝出」的協定,只有取捨不同的協定。

Shadowsocks:極簡對稱加密

Shadowsocks(常縮寫為 SS)的設計目標是最小化:用戶端與伺服端約定同一套密碼與加密方法,資料經 AEAD 對稱加密後直接傳輸,沒有交握協商,沒有額外的驗證往返。這帶來兩個直接好處——實作簡單、連線建立快;代價是協定本身不提供偽裝層,擴充能力得靠 SIP003 外掛體系(如 obfs、v2ray-plugin)來補齊。加密方法上,aes-128-gcm 與 chacha20-ietf-poly1305 是目前的主流選擇,前者在有硬體加速的 x86 裝置上更快,後者在多數手機的 ARM 晶片上表現更好。

VMess 與 Trojan:兩條相反的路線

VMess 來自 V2Ray 專案,走「功能齊全」路線:基於使用者 UUID 做動態驗證,支援多種傳輸層(TCP、WebSocket、gRPC 等)自由組合,中繼資料裡帶較多控制資訊。取捨是協定頭開銷偏大,且驗證依賴用戶端與伺服端的系統時間大致同步——時間偏差過大就會直接連線失敗,這也是排查 VMess 節點異常時第一個要檢查的地方。Trojan 走的是相反路線:不自創加密,直接沿用標準 TLS,讓流量外觀跟一般 HTTPS 網站沒兩樣。代價由伺服端承擔——部署需要網域與有效證書,對使用者來說幾乎無感,設定欄位也最少。

VLESS、Hysteria2 與 TUIC:新一代的減法與換道

VLESS 是對 VMess 的減法:去掉協定自身的加密與時間驗證,把安全性完全交給外層 TLS(以及 REALITY 等擴充),協定頭壓到最薄,轉發開銷明顯低於 VMess。Hysteria2 與 TUIC 則是換道:放棄 TCP,改用基於 UDP 的 QUIC 當底層。Hysteria2 的特色是內建激進的壅塞控制策略,在高丟包、高延遲的弱網線路上仍能維持吞吐量;TUIC 的重點是交握效率,利用 QUIC 的 0-RTT 特性把連線建立壓到極短,並原生支援 UDP 轉發。這三者在 Clash 生態裡都只有 mihomo 系核心支援,這點會在第 E 章展開說明。

B傳輸層差異:TCP 系與 QUIC 系的分水嶺

六種協定真正的分水嶺不在加密方式,而在傳輸層:SS、VMess、Trojan、VLESS 屬於 TCP 系,Hysteria2 與 TUIC 屬於 QUIC 系。搞懂這條界線,比記住每個協定的欄位更有用,因為它直接決定了協定在不同網路環境下的行為差異。

TCP 系:成熟、保守、路徑友善

TCP 系協定最大的優勢是「路徑友善」:TCP 是網路上最成熟的傳輸協定,途經的路由器、防火牆、電信業者 QoS 設備都對它有完善的處理邏輯,極少出現整類流量被限速或丟棄的情況。Trojan 與 VLESS 疊上 TLS 之後,流量特徵跟一般網頁瀏覽沒有差別,相容性最好。代價有兩個:一是交握輪次多——TCP 三向交握疊上 TLS 交握,連線建立至少需要兩到三個往返,節點距離越遠,首包等待就越明顯;二是隊頭阻塞——TCP 保證位元組流嚴格有序,一個封包丟失就會卡住後面所有資料,即使後面的資料跟這次遺失毫無關係。在丟包率高的線路上,這會把偶發丟包放大成整體卡頓。

QUIC 系:少交握、抗丟包,但要看 UDP 待遇

QUIC 在 UDP 之上重新實作了可靠傳輸,並把 TLS 1.3 交握合併進連線建立過程,新連線通常一個往返就能完成,重連情境下 0-RTT 甚至能隨首包一併帶上資料。QUIC 的串流(stream)彼此獨立,單個封包丟失只會影響所屬的串流,不會拖累其他請求,這是它在弱網下體驗更好的結構性原因。QUIC 還支援連線遷移:裝置從 Wi-Fi 切到行動網路時,連線可以延續而不必重建,對行動裝置的價值相當明顯。它的軟肋同樣來自 UDP:部分電信業者與企業網路會對 UDP 流量限速或降低優先度,遇到這種線路時,QUIC 系協定的表現可能反而不如一般的 TLS-over-TCP 連線。因此「Hysteria2 一定比 Trojan 快」這種說法並不成立——快不快,取決於這條線路怎麼對待 UDP。

多工的實作位置不同

TCP 系協定可以透過 mux 設定,把多個請求複用進同一條連線,減少交握次數,但複用同時會放大隊頭阻塞的影響範圍,通常只建議在高延遲線路上依需求開啟。QUIC 系協定的多工是原生內建的,不需要額外設定,也不會引入跨請求的阻塞,這是傳輸層設計帶來的先天差異,不是調參數能抹平的。

C連線速度與資源占用:定性對比

協定效能沒有放諸四海皆準的數字可引用——同一協定在不同線路、不同裝置上的表現差距,遠大於協定之間的差距。因此本章只做定性對比,給出「其他條件相同」前提下的相對排序,以及資源占用的結構性差異。

連線建立速度

影響「打開一個新網站要等多久」的核心變數是建連往返次數。依交握輪次由少到多排列:TUIC 與 Hysteria2(QUIC,一個往返,重連可用 0-RTT)最快;SS 次之(沒有協定交握,只有 TCP 三向交握);Trojan 與 VLESS 需要 TCP 加 TLS 兩層交握;VMess 因協定頭與驗證開銷,通常在同類裡建連最慢。要注意這個排序只影響新連線的首包時間,連線建立之後的持續傳輸速度跟它沒有關係。瀏覽網頁這類頻繁建立短連線的場景對建連速度最敏感,看影片、下載大檔案這類長連線場景則幾乎無感。

吞吐量與 CPU 開銷

持續吞吐量的瓶頸通常在線路本身,協定差異主要體現在 CPU 占用上。加密運算是大頭:x86 裝置普遍內建 AES 硬體加速指令,跑 aes-128-gcm 幾乎不吃 CPU;多數 ARM 行動晶片上 chacha20-ietf-poly1305 反而更省力。VLESS 因為協定自身不做加密(只靠外層 TLS 一層),同等吞吐量下 CPU 占用最低,這也是它常被用於高流量轉發場景的原因。QUIC 系協定的加解密收發目前多在使用者空間完成,缺少作業系統對 TCP 那套成熟優化,在跑滿頻寬的極限場景下 CPU 占用會明顯高於 TCP 系——桌上型裝置沒感覺,低功耗裝置得留意。

記憶體與低規格裝置

記憶體占用主要由核心與規則資料決定,協定本身的差異很小。真正吃記憶體的是 GEO 資料庫與大體積規則集,在軟路由、老手機這類記憶體有限的裝置上,精簡規則檔案比更換協定更能降低占用。如果裝置是記憶體不多的路由器,建議優先選 SS 或 Trojan 這類實作簡單的協定,並使用Mihomo 核心的精簡設定,而不是在低規格裝置上追求 QUIC 系協定的新特性。並行連線數多的場景(如網頁多開、P2P)下,每條 TCP 連線都有各自的系統開銷,開啟 mux 或改用原生多工的 QUIC 系協定可以減少連線總數,這是從資源角度選協定時的另一個考量。

D行動裝置耗電表現:協定之外還要看用戶端行為

手機上的耗電問題常常被歸咎給協定,實際上電量消耗是三層因素疊加的結果:協定的保持連線行為、用戶端的背景執行策略、系統對 VPN 服務的排程方式。只換協定卻不調整用戶端行為,省電效果通常有限。

無線電喚醒:行動裝置耗電的真正大頭

在行動網路下,手機的基頻晶片在沒有資料傳輸時會進入低功耗狀態,任何一個封包都會把它喚醒並維持一段高功耗視窗。因此耗電的關鍵不是傳輸了多少資料,而是喚醒了多少次。協定層的保持連線心跳、用戶端的定時延遲測試、策略群組的自動測速,每一項都在製造週期性喚醒。QUIC 系協定的連線遷移特性在這裡很有實際價值:Wi-Fi 與行動網路切換時連線直接延續,省掉了重建連線的交握以及隨之而來的一連串喚醒;TCP 系協定在切換網路時所有連線都要作廢重建,通勤這種頻繁切換的場景下差距會慢慢累積。

用戶端側可以調整的項目

比選協定影響更大的是用戶端設定。第一,策略群組的自動測速間隔:url-test 類型的群組預設會週期性地對群組內所有節點發起測試,間隔設太短等於讓手機每隔幾分鐘就喚醒一次並批量建連,行動裝置上建議把 interval 拉長,或對不常用的群組改用手動選擇。第二,TUN 模式與系統代理的差異:TUN 模式接管全部流量,處理路徑更長,待機耗電略高於只代理瀏覽器流量的系統代理模式;不需要接管全域流量時,行動裝置用系統代理模式更省電。第三,規則數量:每個新連線都要跑一次規則比對,規則集越大比對開銷越高,行動裝置設定應避免堆疊大量用不到的規則集。

iOS 的特殊限制

在 iOS 上,代理用戶端運行在 Network Extension 框架內,系統對這個擴充功能程序的記憶體限制相當嚴格,超過就會被直接終止——表現為代理無故斷線。因此 iOS 用戶端得格外控制規則與 GEO 資料的體積,協定上也宜選擇實作較輕量的類型。Clash Plus 在 iOS 上透過 App Store 發行,針對這項限制做了記憶體控制,是 iOS 平台的首選;安裝入口見下載頁 iOS 分區。Android 平台則要留意系統的電池優化白名單:用戶端被系統凍結後,VPN 服務重啟同樣會帶來一輪重連耗電,加入白名單比調整協定更能改善續航。

E核心家族:原版、Premium、Meta 與 mihomo 的關係

「Clash」這個詞在不同語境下指的東西不一樣:有時指核心(在背景處理流量的命令列程式),有時指用戶端(帶圖形介面的應用程式)。用戶端只是核心的外殼,協定支援、規則能力、TUN 實作全都由核心決定。搞懂核心家族的關係,是理解「為什麼這個節點在 A 用戶端能用、在 B 用戶端卻報錯」的前提。

三代核心的演化線

原版 Clash 核心是這一切的起點,確立了 proxies、proxy-groups、rules 三段式設定結構,支援 SS、VMess、Trojan 等基礎協定;其上游倉庫已經封存,不再更新。Premium 是原版作者維護的閉源強化版,補上了 TUN 模式與規則提供者(rule providers)等能力,同樣已隨原版一起停止演進。Clash Meta 是社群在原版基礎上延續的分支,後來改名為 mihomo——兩個名字指的是同一條演化線,現在的正式名稱是 mihomo。它在維持設定結構相容的同時,補齊了 VLESS、Hysteria2、TUIC 等新協定,擴充了規則集(rule-set)、網域探測(sniffer)、更完善的 GEO 資料管理等能力,是目前唯一仍在積極維護的主線核心。

用戶端與核心的對應關係

選用戶端本質上就是在選核心。下載頁收錄的用戶端裡:Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX Meta 都是基於 mihomo 系核心,能完整使用六種協定;Clash for Windows 基於原版 / Premium 核心且已停止維護,遇到 VLESS、Hysteria2、TUIC 節點會直接報不支援,只建議還有歷史設定包袱的使用者繼續沿用。如果訂閱裡已經出現 QUIC 系協定的節點,用戶端就必須選 mihomo 系,沒有別的辦法。各用戶端在介面、平台覆蓋、更新節奏上的詳細差異,見用戶端對比頁;結論先講:全平台場景下 Clash Plus 是首選,桌面端次選 Clash Verge Rev。

F設定與訂閱格式相容性

訂閱其實是「伺服器發下來的一份設定檔」,格式相容性問題因此分兩層:設定檔本身的欄位是否被核心識別,以及訂閱連結發出的格式是否被用戶端識別。兩層各有各的坑,混在一起排查只會繞遠路。

設定欄位層:同一結構,兩套欄位集

所有 Clash 系核心共用同一份 YAML 結構:proxies 定義節點,proxy-groups 定義策略群組,rules 定義分流規則。差異在欄位集:原版核心只認識基礎協定的欄位,mihomo 在同一結構裡擴充了新協定類型與附加參數。下面的片段展示了同一份設定裡新舊兩類節點的形態差異:

proxies:
  - name: "節點-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "節點-HY2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

把這份設定交給原版核心,解析到 type: hysteria2 時會以「unsupported proxy type」這類錯誤整份拒絕載入——不是跳過這個節點,而是整份設定失敗。這解釋了一個高頻現象:訂閱在新用戶端裡正常,在舊用戶端裡卻「一個節點都沒有」。反過來,純基礎協定的設定在 mihomo 上可以原樣運行,相容是單向的:新核心認得舊設定,舊核心不認新欄位。

訂閱發送層:格式與 User-Agent

訂閱連結回傳的內容常見三種形態:Clash YAML(直接可用)、Base64 編碼的分享連結列表(需用戶端轉換)、以及 sing-box 等其他生態的 JSON(Clash 系用戶端不直接支援)。很多訂閱伺服器會依據請求標頭裡的 User-Agent 決定發出哪種格式——同一條連結,用 Clash 系用戶端請求會得到 YAML,用瀏覽器打開卻得到 Base64。這帶來一個隱藏問題:如果伺服器不認識某個用戶端的 UA,可能發出錯誤格式甚至直接拒絕回應,表現為「連結在別的用戶端能用、在這個用戶端匯入失敗」。遇到這種情況,可以在用戶端的訂閱設定裡自訂 UA 字串,或聯絡訂閱提供方確認支援的用戶端清單。

訂閱匯入報錯、更新後節點清零這類具體故障的逐項自查,已在技術筆記《Clash 訂閱失效或解析失敗的六種原因與自查步驟》裡單獨展開,本章不再重複。

G依使用場景區分的選型建議

前面各章的結論在這裡收攏成可以直接執行的建議。前提再強調一次:線路品質的影響大於協定差異,以下建議都假設「同一台節點伺服器提供多種協定入口」,在這個前提下依場景挑協定才有意義。

用策略群組落實選型,而不是手動切換

選型落地的方式不是每次手動換節點,而是把判斷寫進策略群組。常見做法:為不同用途建立獨立的策略群組——瀏覽走一個 url-test 群組(自動選延遲最低的節點),下載走一個手動 select 群組(固定在吞吐量好的節點),再用規則把不同網域分派到對應的群組。這樣選型只需要做一次,之後由規則自動執行。群組內混排協定是可以的,url-test 的自動測試會幫你比較它們的實際表現;要注意的是自動測試主要反映的是建連延遲,吞吐量差異仍需手動實測確認。

兩種不必糾結的情況

第一,訂閱只提供一兩種協定時,根本沒有選型空間,直接用就好——不必因為「手冊說 QUIC 更快」就去要求更換協定,收益不確定但溝通成本確定。第二,桌上型有線網路、線路品質良好時,六種協定的體驗差距會被壓縮到難以察覺,這時把精力放在規則與策略群組的組織上(參考教學的分流章節),回報遠高於反覆切換協定。選型建議真正有價值的地方在邊界場景:弱網、行動裝置、低規格裝置、UDP 受限,這四種環境下依上表調整,差異是能感受到的。

H常見誤區與排查線索

最後一章收錄圍繞協定與核心的高頻誤區,以及「表現—定位—去處」式的排查索引。這裡只給判斷線索,完整的排查步驟在對應的專題文章裡。

三個流傳最廣的誤區

誤區一:「協定越新越快」。新協定解決的是特定場景的問題(弱網、交握延遲、UDP 轉發),不是全場景提速。線路本身的頻寬、壅塞程度、實際距離決定了體驗的上限,協定只影響逼近上限的效率。誤區二:「加密越強越安全,應該選加密最複雜的協定」。六種協定在密碼學層面都採用現代 AEAD 或 TLS 1.3,強度都已經足夠,複雜度差異體現在功能與開銷上,不體現在「安全等級」上;為了想像中的安全性去選開銷更大的協定,純粹是損失。誤區三:「延遲測試的數字代表使用體驗」。用戶端裡的延遲測試通常是一次 HTTP 請求的耗時,反映的是建連與線路往返時間,不反映吞吐量、丟包與 UDP 待遇;兩個節點顯示相同的延遲數字,實際體驗可能天差地別。這個數字用來橫向比較同協定的節點是有效的,跨協定比較則要謹慎。

依故障表現定位

節點顯示「unsupported proxy type」或訂閱載入後節點清零:優先懷疑核心不支援該協定類型,對照第 E 章確認用戶端的核心家族,必要時更換 mihomo 系用戶端(下載頁各平台都有)。VMess 節點單獨失效而其他協定正常:檢查裝置系統時間是否跟標準時間偏差過大。QUIC 系節點(Hysteria2/TUIC)在特定網路下明顯變慢或不通、切換網路後又恢復正常:符合 UDP 被限速的特徵,該網路下改用 TCP 系協定。所有節點全部逾時:多數跟本地網路、訂閱伺服器或用戶端狀態有關,跟協定選型無關,依《Clash 節點全部逾時無法連線?》的順序由近到遠排查。代理已連線但網頁打不開:通常卡在系統代理、DNS 或規則命中環節,對照《Clash 已連線但打不開網頁》的清單逐項確認。

延伸入口

名詞層面的疑問(策略群組、TUN、GEO 資料、REALITY 等)收錄在術語表裡並依分類整理;安裝、設定、使用過程中的零散問題在 FAQ 依「基礎認知—安裝設定—使用技巧—故障排查」四類組織;平台相關的安裝細節(macOS 網路擴充功能授權、Windows TUN 模式)在技術筆記的平台指南系列裡有逐畫面說明。本頁會隨核心與協定生態的變化持續修訂,請以目前版本為準。