Clash 通訊協定詳解:六類代理協定與 mihomo 核心的選型參考

R-01用戶端、核心、協定:先分清三層

用戶端只是外殼

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——這些名字指的都是圖形介面用戶端。用戶端負責呈現節點清單、切換代理模式、管理系統代理開關,本身不建立任何代理連線。介面差異只影響操作體驗,不影響連線鏈路的實際行為。同一份訂閱在兩個用戶端裡匯入,節點清單、延遲測速、分流結果應當一致;如果不一致,問題多半出在設定,而不是用戶端之間的差異。

核心是引擎

真正與遠端伺服器通訊的是核心:一個隨用戶端啟動的背景程式。目前下載頁列出的維護中用戶端幾乎全部內建 mihomo 核心(原名 Clash Meta)。同一套節點設定在不同用戶端裡,只要核心版本相近,連線行為、協定支援範圍、規則執行結果都基本一致。因此「選協定」本質上是「在核心支援的協定清單裡選」,而不是在用戶端介面裡選。想確認手邊用戶端的核心,打開設定或關於頁,核心名稱與版本號都會標註——看到 mihomo 或 Clash Meta 字樣,即表示協定支援範圍以本頁 R-08 章為準。

協定是封裝約定

節點資訊裡標註的 SS、VMess、Trojan、VLESS、Hysteria2、TUIC,就是協定類型。協定規定三件事:資料如何封裝、用什麼方式加密、走 TCP 還是 UDP。訂閱匯入後,用戶端把每個節點解析成核心設定裡的一項 proxy,核心按協定欄位與伺服器交握並轉發流量。協定選擇只影響「用戶端到節點」這一段;節點到目標網站的最後一段由伺服器端決定,用戶端無從干預。

本頁與教學頁的分工至此明確:quickstart.html 是「跟著做就能連上」的主線流程,本頁是「查得到、看得懂」的參考手冊。遇到不認識的設定欄位,先查術語表,再回本頁對應章節細看。

R-02代理協定的演進脈絡

通用代理:SOCKS5 與 HTTP

最早的代理協定是通用的。SOCKS5 只負責轉發,不加密、不校驗內容,常用於本機或區域網路環境;HTTP 代理同理,主要服務瀏覽器。兩者至今保留在 Clash 系設定裡,但角色是入站——本機應用程式連到用戶端監聽的埠——而不是出站連遠端伺服器。設定裡的 mixed-port 就是同時提供 SOCKS5 與 HTTP 兩種入站的混合埠,allow-lan 控制是否允許區域網路裝置接入。

# 本機入站設定(應用程式連用戶端用,不是節點設定)
mixed-port: 7890
allow-lan: false
mode: rule

專用協定的三次轉向

面向遠端伺服器的專用代理協定,大致經歷三次設計轉向。第一次,Shadowsocks 確立「輕量加密流」思路:只加密負載,不加多餘結構,四項參數即可運作。第二次,VMess 走「功能優先」:時間戳校驗、多傳輸層、協定內加密全部納入,能力變強,結構也變重。第三次,路線一分為二:Trojan 與 VLESS 把加密交給 TLS,讓流量在外形上接近普通 HTTPS;Hysteria2 與 TUIC 改用 UDP 之上的 QUIC,換取弱網吞吐與切換網路時的連線保持。

六種並存的現況

今天訂閱裡最常見的仍是六類:SS、VMess、Trojan、VLESS、Hysteria2、TUIC。沒有哪一種在所有維度上領先:開銷小的特徵相對明顯,仿真強的依賴網域名稱與證書,速度激進的依賴 UDP 環境。協定之間是取捨關係,不是替代關係——這正是需要一份選型參考的原因。

R-03Shadowsocks(SS):輕量加密流

誕生背景與設計目標

SS 於 2012 年前後發布,設計目標極其克制:在 SOCKS5 的轉發框架上加一層流加密,讓傳輸中的資料不可讀,除此之外不加任何結構。一個 SS 節點只需要四項資訊:伺服器位址、埠、密碼、加密方式。實作一個可用的 SS 用戶端只需幾百行程式碼,這是它迅速普及、並被幾乎所有核心與用戶端支援的直接原因。

AEAD 加密與現行用法

早期 SS 使用串流加密(如 aes-256-cfb),後被證實存在可主動探測的弱點,社群遂引入 AEAD(帶關聯資料的認證加密)。目前常見的三種演算法:aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305。桌面 CPU 大多帶 AES 硬體指令集,兩種 AES-GCM 幾乎零成本;多數手機 SoC 沒有對應指令集,chacha20-ietf-poly1305 在行動裝置更快也更省電。SS 還支援 UDP 轉發(設定裡的 udp 欄位),但依賴伺服端同步開啟。

proxies:
  - name: "範例節點-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

適用與局限

SS 的優點集中在工程層面:協定開銷在六類中最小,實作成熟,全核心支援,行動裝置電量表現最好。局限同樣明確:協定沒有內建偽裝層,流量特徵相對固定;它只定義加密,不處理身分與證書,伺服端真實性依賴部署者。作為日常通用協定,SS 至今仍是穩妥的預設選項,也是舊裝置與路由器上的首選。

外掛與混淆的可選擴充

SS 本身不帶偽裝,但社群為它設計了外掛機制,在加密流之外再套一層外形。最典型的是 obfs(簡單混淆)與 v2ray-plugin(WebSocket 偽裝):前者把流量整形為無特徵隨機位元組,後者把 SS 負載裝進 WebSocket 訊框,可配合 CDN 中繼。設定裡透過 plugin 與 plugin-opts 欄位啟用。需要理解的是,外掛是 SS 的可選外掛,不是協定本體——同一節點帶不帶外掛,對用戶端是兩種不同設定;訂閱裡若標註了外掛,用戶端必須支援對應外掛才能連線。mihomo 對主流 SS 外掛支援完整,但外掛會增加一層封裝開銷,行動裝置電量表現會略遜於裸 SS。日常使用中,若網路環境對 SS 沒有針對性限制,裸 SS 加 AEAD 加密已足夠,不必為「看起來更隱蔽」而疊加外掛。

R-04VMess:功能優先的一體化設計

設計背景

VMess 是 V2Ray 專案的原生協定,設計思路與 SS 相反:把身分驗證、時間校驗、加密與傳輸偽裝全部納入協定本身。每個請求攜帶時間戳,與伺服器時間偏差過大的請求直接拒絕,從協定層防止重播;UUID 作為使用者識別碼,一個伺服端可承載多個獨立使用者並分別統計。

傳輸層與結構開銷

VMess 支援 TCP、WebSocket、gRPC 等多種傳輸層。WebSocket 形態可以把代理流量套在普通 Web 服務的結構裡,配合 CDN 中轉是常見用法;gRPC 形態則借用 HTTP/2 的多路複用。功能完整的代價是結構複雜:交握流程長,標頭開銷在六類協定中最大,實作難度高。另外 VMess 自帶加密,若再疊加 TLS 會形成雙重加密,CPU 占用明顯上升而安全收益有限。

現況

VMess 在存量訂閱中仍然常見,mihomo 完整支援其各傳輸層形態。新部署的伺服端更多轉向結構更輕的 VLESS,VMess 逐步退居舊設定。用戶端側無需刻意迴避:節點能連、測速達標即可,協定新舊不構成更換理由。手動維護設定時留意 alterId 欄位——新版伺服端與核心已將其固定為 0,舊教學裡的非零寫法不再適用。

proxies:
  - name: "範例節點-VMess"
    type: vmess
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    network: ws
    ws-opts:
      path: /ray

R-05Trojan 與 VLESS:TLS 仿真路線

共同思路:不再自己設計加密

Trojan 與 VLESS 屬於同一條路線:協定層不實作加密,直接借用 TLS——即 HTTPS 使用的安全層。伺服器持有真實網域名稱與有效證書,用戶端與伺服器建立的是一條標準 TLS 連線,交握、加密、證書校驗全部沿用成熟實作,從外部觀察與存取一個 HTTPS 網站基本一致。mihomo 還支援 client-fingerprint 欄位(如 chrome),用 uTLS 模擬指定瀏覽器的 TLS 指紋,讓交握特徵與真實瀏覽器更接近。

Trojan:極簡結構

Trojan 的設計近乎「沒有協定」:TLS 交握完成後,用戶端在會話內傳送密碼的雜湊值完成身分校驗,之後的資料原樣轉發。協定自身結構越少,行為越接近正常 HTTPS,開銷也越小。設定只需要網域名稱、埠、密碼三項,sni 欄位通常與網域名稱一致。

VLESS:把 VMess 減重

VLESS 是 VMess 的簡化重寫:去掉協定層加密與時間戳,只保留 UUID 身分識別碼,加密完全交給外層 TLS。結構比 VMess 輕得多,標頭開銷與 Trojan 同檔;配合 XTLS 一類的傳輸優化時,資料在核心與 TLS 函式庫之間少一次複製,高頻寬情境吞吐更好。需要強調:VLESS 必須搭配 TLS 使用,明文形態的 VLESS 沒有意義,也不應出現在正常訂閱裡。

共同前提:網域名稱與證書

TLS 路線依賴真實網域名稱與有效證書,這決定了它多由自建或管理較規範的伺服端採用。用戶端側的注意點只有一個:節點裡的 sni(或 servername)欄位必須與證書網域一致,不一致交握即失敗。透過訂閱匯入的節點這一欄位已寫好,手動新增或修改節點時才需要留意。

proxies:
  - name: "範例節點-Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true
  - name: "範例節點-VLESS"
    type: vless
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    tls: true
    servername: example.com
    client-fingerprint: chrome

R-06Hysteria2 與 TUIC:QUIC 上的 UDP 路線

QUIC 帶來的變化

QUIC 是建立在 UDP 之上的現代傳輸協定,也是 HTTP/3 的基礎。它把加密、壅塞控制、多路複用整合進傳輸層:交握通常一個往返完成,支援 0-RTT 會話恢復;連線以連線識別碼維繫,而不是來源位址四元組,因此 Wi-Fi 切到行動網路時會話可以繼續,不必重建。Hysteria2 與 TUIC 都以 QUIC 為基礎,但取捨方向不同。

Hysteria2:主動占頻寬的壅塞控制

Hysteria2 的核心是名為 Brutal 的自訂壅塞控制:不按傳統方式探測可用頻寬,而是按設定的目標頻寬主動發包。在高丟包、高延遲線路上,這種策略能跑出明顯高於任何 TCP 協定的吞吐——TCP 類協定遇到丟包會指數級退讓,Brutal 不退讓。代價同樣清楚:發包激進,對伺服端頻寬有硬性要求;設定裡的 up 與 down 值必須接近真實線路,虛高或虛低都會拉低實際速度。協定還支援埠跳躍(在埠區間內輪換),用於規避單埠限速,mihomo 以 ports 欄位設定。

TUIC:多路複用與低延遲

TUIC 的設計目標是低延遲與低開銷:把多條 TCP 連線複用在一條 QUIC 會話裡,應用程式每開一個新連線不必重新交握;原生支援 UDP 中繼,遊戲、語音這類延遲敏感流量受益直接。壅塞控制沿用 QUIC 標準演算法族,行為比 Hysteria2 溫和,對線路的侵入性小,也更適合頻寬不大的伺服端。

UDP 路線的邊界

兩類協定都依賴 UDP 可達。部分網路環境對 UDP 限速甚至完全阻斷,此時它們會直接不可用或速度驟降,用戶端無法繞開這一限制,只能換回 TCP 類協定。另一點是資源:QUIC 的加密、重傳、壅塞控制全部在使用者態完成,CPU 占用高於純 TCP 協定,長時間大流量下載時,行動裝置的發熱與耗電差異可以感知。

如何判斷所在網路是否適合 UDP 協定

最可靠的方法是實測而非猜測。先把節點切換到 Hysteria2 或 TUIC,開啟一個影片或跑一次下載,觀察速度是否達到預期、連線是否穩定;再換到 Trojan 或 SS 重複一次。若 UDP 協定明顯更快且不掉線,說明所在網路對 UDP 寬鬆,可以把它設為預設;若 UDP 協定時快時慢、頻繁中斷,或乾脆連不上,說明網路對 UDP 不友善,應回到 TCP 類協定。企業內網、校園網、部分公共 Wi-Fi 是 UDP 受限的高發場景;家庭寬頻與主流行動網路通常寬鬆。還有一點容易被忽略:某些網路對 UDP 的限速是分時段的——晚高峰收緊、凌晨放開,因此單次測速結論不必當成永久結論,發現預設協定突然變慢時,先懷疑網路策略變化,再懷疑節點本身。

proxies:
  - name: "範例節點-Hysteria2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    up: 50
    down: 200
  - name: "範例節點-TUIC"
    type: tuic
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    alpn: [h3]

R-07橫向對比:速度、資源與電量

連線建立

TCP 類協定(SS、VMess、Trojan、VLESS)先完成 TCP 交握,帶 TLS 的再加一個 TLS 交握,首次建立通常一到三個往返。QUIC 類把傳輸與加密交握合併,通常一個往返,會話恢復可 0-RTT。日常瀏覽感知差別不大;短連線密集的情境——資訊流刷新、API 請求頻繁的應用程式——QUIC 類更占優。

吞吐與開銷

協定標頭開銷從小到大大致為:SS < Trojan ≈ VLESS < VMess;QUIC 類標頭不算小,但多路複用攤薄了交握成本,實際吞吐更多取決於壅塞控制策略。同一線路下:穩定低丟包時,SS、Trojan、VLESS 互差距不大;高丟包時 Hysteria2 吞吐最高,TUIC 次之,TCP 類協定整體退讓明顯。

CPU 與記憶體

桌面端(Windows、macOS、Linux)上,六類協定的 CPU 占用都在可忽略範圍,選型不必以效能為依據。行動裝置不同:手機 SoC 的小核跑 AES 與 ChaCha20 的能效差異明顯;QUIC 的使用者態重傳與壅塞控制會持續占用 CPU。記憶體方面各協定差異不大,核心整體占用主要取決於規則數量與活動連線數,與協定類型關係不大。

行動裝置電量

同等流量下的相對耗電,從省到費大致為:SS(chacha20-ietf-poly1305)< Trojan ≈ VLESS < VMess < TUIC < Hysteria2。以推播、即時通訊為主的掛背景用法,各類協定差異不大;持續影片播放或大檔案下載時,差異開始可感知。iOS 的 Clash Plus 與 Android 各用戶端使用同一 mihomo 核心,上述結論跨平台一致;iOS 端的取得與設定流程見技術筆記(iPhone 上怎麼用 Clash)。

測速的正確姿勢

選型前建議按統一口徑測速:同一時段、同一目標、同一裝置。用戶端測速得到的是延遲,反映交握與往返成本;吞吐要用實際下載驗證。單連線下載受協定開銷影響大,多連線下載受壅塞控制影響大——兩個數字都看一眼,比只看延遲可靠。

延遲低不等於速度快

這是選型時最容易混淆的一對指標。延遲(用戶端測速顯示的數字)衡量的是「一個封包往返要多久」,主要決定網頁開啟、操作回應的快慢;吞吐衡量的是「單位時間能傳多少資料」,主要決定下載、看高畫質影片的流暢度。一個節點可以延遲很低但吞吐有限——例如距離近但頻寬小;也可以延遲偏高但吞吐充足——例如跨洲但線路品質好。日常瀏覽網頁、用社交應用,低延遲體驗更好;看 4K 影片、下大檔案,高吞吐更關鍵。因此選型時先想清楚自己的主要用途:以互動式操作為主,優先看延遲;以大流量傳輸為主,優先看吞吐。兩者都要時,取延遲與吞吐都達標的節點,而不是某一項特別突出、另一項墊底的節點。用戶端的測速功能只給延遲,吞吐需要實際下載或線上測速工具驗證,這一步不要省。

R-08核心家族:Clash、Clash Meta 與 mihomo

原版 Clash 的歷史定位

原版 Clash 核心於 2023 年停止維護,倉庫已封存。它支援 SS、VMess、Trojan 等早期協定,不認識 VLESS、Hysteria2、TUIC。原版還曾有一個閉源增強版 Clash Premium,提供 TUN 與腳本能力,同樣已停止維護。仍在使用 Clash for Windows、ClashX Meta 等停更用戶端的使用者,實際執行的就是這個時代的核心或其早期分支——現有節點能連,但新協定、新功能不會再有,訂閱裡的新協定節點會被直接跳過。

Meta 到 mihomo:繼承與擴展

Clash Meta 是社群在原版基礎上的活躍分支,2023 年底更名為 mihomo。它完整繼承原版的 YAML 設定格式,加入 VLESS、Hysteria2、TUIC 支援,並帶來 TUN 模式增強、規則提供器(rule-providers)、外部控制器擴展等能力。TUN 模式透過虛擬網路卡接管全域流量,原理與開啟方法在技術筆記裡有專文(Clash TUN 模式是什麼)。下載頁維護中的用戶端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——內建核心均為 mihomo。

設定相容性

相容方向是單向的:mihomo 能直接執行原版 Clash 的舊設定;反過來不成立——含新協定節點或新欄位(如 rule-providers)的設定,原版核心解析失敗。訂閱轉換工具通常提供「Clash」與「Clash Meta」兩種輸出:使用 mihomo 用戶端時選 Meta 輸出;選錯為舊格式時,新協定節點會在轉換階段被丟棄,表現為「訂閱裡明明有的節點,匯入後不見了」。

R-09訂閱格式與按情境選型

訂閱格式的三種形態

訂閱連結回傳的內容常見三種形態。一是 Base64 節點清單:每行一個 ss:// 或 vmess:// 分享連結,通用性最好,但不帶 Clash 的策略組與規則結構,匯入後由用戶端自行組織。二是 Clash YAML:完整設定,包含 proxies、proxy-groups、rules 三段,匯入即用,是 mihomo 用戶端的首選形態。三是線上訂閱轉換的輸出:把 Base64 清單轉成 Clash YAML,舊訂閱也能獲得完整結構,但轉換服務會接觸節點明文,選擇時留意其可信度。訂閱的取得與匯入細節,技術筆記有專文(Clash 訂閱連結怎麼匯入)。

按使用情境選型

• 日常瀏覽與影片:SS 或 Trojan、VLESS。開銷小、電量友善,桌面與手機都適用。
• 高丟包線路:Hysteria2。跨洲線路、晚間高峰壅塞時吞吐優勢最明顯,前提是所在網路不限 UDP。
• 遊戲與語音:TUIC 或 Hysteria2。UDP 中繼延遲低,同時確認用戶端已開啟 UDP 轉發。
• 頻繁切換網路:QUIC 類協定。連線隨網路切換保持,通勤情境斷線次數明顯減少。
• 舊裝置與路由器:SS。CPU 占用最低,實作最成熟,長期運作最穩。

三個常見迷思

「協定越新越快」不成立:速度取決於線路品質與壅塞控制,不取決於發布時間,穩定線路上 SS 與最新協定的差距很小。「加密層數越多越安全」不成立:VMess 疊 TLS 這類雙重加密只增加 CPU 開銷,安全性由最外層決定。「換用戶端協定表現就不同」也不成立:同一核心下協定行為一致,用戶端只影響操作體驗——用戶端之間的差異對比見技術筆記的橫向對比(主流用戶端橫向對比)。

多協定混用的實際策略

真實訂閱往往同時提供多種協定的節點,這恰恰是優勢而非負擔。合理的用法是按用途分流,而不是死守單一協定:把延遲敏感、需要 UDP 中繼的流量(遊戲、語音通話)交給 TUIC 或 Hysteria2 節點;把日常瀏覽、影片這類以 TCP 為主的流量交給 SS 或 Trojan 節點;把協定最輕、最省電的 SS 留給掛背景的即時通訊與推播。mihomo 的策略群組(proxy-groups)正是為此設計——可以建多個策略群組,各指定不同協定節點,再用規則(rules)把不同網域或應用導向對應策略群組。這樣一次設定,各類流量各走最優鏈路,無需手動切換。對不願深究規則的一般使用者,更簡單的等價做法是:日常固定用一個實測最快的協定節點,只在它明顯變慢或連不上時,手動切到備用協定的節點。兩種思路沒有高下之分,取決於願意在設定上投入多少時間。

收尾:四步選型流程

1. 確認用戶端核心是 mihomo(下載頁維護中用戶端均滿足)。
2. 匯入訂閱,按協定類型瀏覽節點清單。
3. 在常用網路裡對候選協定各測一次速,延遲與吞吐都看。
4. 把實測最好的類型設為策略組預設,其餘保留為備用。

協定部分到此為止。剩下的操作——匯入訂閱、選模式、開系統代理、驗證連通——回到使用文件按步驟執行;需要下載用戶端,前往下載頁;遇到不認識的術語,查術語表。