Clash 協定手冊

第一章 · 手冊定位與查閱方式

本手冊與站內其他頁面的分工,先說明如下。入門指南負責"從安裝到連通"的主線操作:下載客戶端、匯入訂閱、選擇模式、驗證連線,四步完成即可正常使用,全程不要求理解任何協定術語。本手冊負責的是另一半工作——回答「節點列表裡那些 ss、vmess、trojan、hysteria2 字樣分別是什麼」「為什麼同一份訂閱裡有的節點快有的慢」「舊版客戶端為什麼讀不出某些節點」這類需要原理支撐的問題。兩者的關係可以概括為:教學頁保證能用,手冊頁保證會選。尚未完成安裝的讀者,建議先依教學頁操作一次,再回到本頁按需查閱;客戶端安裝包統一由下載頁提供,各平台首推 Clash Plus。

全書結構依查閱習慣編排。第二章至第四章依技術脈絡分三組介紹六種協定:Shadowsocks 與 VMess 代表早期自建加密的路線,Trojan 與 VLESS 代表複用標準 TLS 的偽裝路線,Hysteria2 與 TUIC 代表基於 QUIC 傳輸的新一代路線。第五章將六者放進同一張表做橫向效能對比,並單獨討論行動裝置耗電。第六章梳理原版 Clash、Clash.Meta 與 mihomo 三代核心的沿革與功能差異——這直接決定客戶端能識別哪些協定。第七章說明 Clash 訂閱與其他分享格式的相容關係。第八章依使用情境收束成可執行的選型條款。

有兩項術語約定需先確認。其一,本手冊所稱「協定」,對應 Clash 設定檔中 proxies 項目的 type 欄位,即客戶端與遠端伺服器之間的傳輸協定,與「規則」「策略群組」等概念屬於不同層面。其二,絕大多數使用者並不會手寫協定欄位——節點參數由訂閱下發,客戶端解析後呈現為節點列表;因此「選協定」在實務上體現為兩件事:在多協定混編的訂閱裡優先選用某類節點,以及在與服務提供方溝通時明確要求某類節點。理解這一點,後續各章的選型建議才有依據。

第二章 · Shadowsocks 與 VMess:兩代經典協定的設計取捨

Shadowsocks:最簡化的加密轉發

Shadowsocks(以下簡稱 SS)是六種協定中結構最簡單的一個,誕生年代最早,設計目標只有一條:在本地與遠端之間建立一條加密的資料轉發通道,除此之外不附加任何東西。運作方式為:客戶端在本地監聽,收到應用程式流量後依預共享密碼加密,傳送至遠端伺服器解密轉發。協定本身沒有交握階段、沒有連線狀態、沒有版本協商,第一個資料封包即攜帶業務資料。現行實作統一採用 AEAD 加密套件,常見取值為 aes-128-gcm、aes-256-gcm 與 chacha20-ietf-poly1305,其中 ChaCha20 系列在不具備 AES 硬體指令的老舊手機與路由器上速度明顯更快。

這種極簡結構帶來兩面性。正面是開銷全場最低:無交握代表首次連線即可立即建立,單層加密代表 CPU 與記憶體占用可忽略不計,因此 SS 至今仍是舊裝置與嵌入式環境的首選。反面是協定行為特徵長期被廣泛研究,現代部署中常需搭配傳輸層外掛程式補強,這屬於伺服端職責,客戶端側無須介入,只需依訂閱下發的 plugin 欄位照常解析即可。

關於 SS 還有兩處細節值得單獨交代,因為它們直接影響可用性判斷。第一是加密套件的選擇邏輯:aes-128-gcm 與 aes-256-gcm 在具備 AES-NI 指令的現代處理器上由硬體加速,幾乎不占 CPU;而在缺少該指令集的低階 ARM 晶片、舊款手機與家用路由器上,AES 只能以軟體實作,吞吐會明顯下滑,此時 chacha20-ietf-poly1305 往往能跑出成倍的速度差。若同一訂閱對同一節點同時提供兩種套件,舊裝置優先選 ChaCha20 系,並非安全性考量,而是純粹的算力適配。第二是 UDP 轉發:SS 原生支援 UDP 中繼,但是否真正可用取決於伺服端有沒有開啟對應的埠轉發,而客戶端設定裡的 udp: true 只是宣告意願,並不能創造能力。這正是「網頁正常但遊戲語音不通」的常見成因之一——判斷方法是在客戶端連線詳情裡觀察是否出現 UDP 類型的連線紀錄,而非反覆改寫設定檔。

VMess:結構化的連線協定

VMess 是 V2Ray 專案的原生協定,設計年代晚於 SS,思路截然不同:與其做一條極簡管道,不如做一個結構完整的連線協定。VMess 以使用者 UUID 為身分憑證,請求標頭攜帶指令、加密方式等元資料,並內建時間校驗機制——客戶端與伺服端的系統時間偏差超出容許範圍(約九十秒)即交握失敗,這也是「節點全部逾時,先檢查手機時間」這條經典排查經驗的出處。VMess 的另一特點是傳輸層高度可組合:可裸跑 TCP,也可套用 WebSocket、gRPC 等傳輸並疊加 TLS,套用 WebSocket 加 TLS 後對外呈現為一次普通的加密網頁連線,是共享主機環境下常見的部署形態。

取捨同樣清楚:結構化標頭與多層傳輸帶來了靈活性,也帶來了高於 SS 的交握延遲與 CPU 開銷;早期的 alterId 動態埠混淆機制已被 AEAD 標頭取代,現代訂閱中該欄位應為 0,若拿到非零值的舊式節點,相容性與安全性都需存疑。兩者的典型設定欄位如下,僅供核對訂閱解析結果,一般不建議手動改寫:

proxies:
  - name: "範例-SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "範例-VMess"
    type: vmess
    server: node.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

第三章 · Trojan 與 VLESS:複用標準 TLS 的偽裝路線

Trojan:把自己藏進 HTTPS

Trojan 的設計出發點與前兩者相反:不發明任何新的加密結構,直接複用網際網路上最普遍的 TLS。一次 Trojan 連線從外部觀察就是一次標準的 HTTPS 存取——真實網域名稱、有效憑證、標準交握,全部齊備;只有持有正確密碼的客戶端,才會在 TLS 通道內被識別為代理請求,其餘存取(包括瀏覽器直接開啟該網域)會被回落到伺服器上掛載的真實網站。這套機制要求伺服端必須持有網域與憑證,部署門檻落在服務方,客戶端側反而極其簡單:核心欄位只有 password 與 sni 兩項。

效能層面,Trojan 的建連成本就是一次 TLS 交握,不多不少;資料面只有 TLS 單層加密,CPU 開銷低於 VMess 套用 WebSocket 加 TLS 的多層結構,吞吐上限也更高。選型時唯一需要留意的欄位是 skip-cert-verify:該項為 true 代表跳過憑證驗證,僅應在明確知曉原因的排查情境短暫使用,日常設定中出現此值應向服務方確認緣由。

VLESS:做減法的下一步

VLESS 可以理解為對 VMess 的一次系統性減法:既然外層已有 TLS 負責機密性,協定內層的加密就是重複勞動——VLESS 因此拿掉了內建加密,協定標頭壓縮到最小,身分仍以 UUID 表達,機密性完全交由外層 TLS 負責。在此基礎上,VLESS 生態發展出兩項重要擴充:XTLS 流量控制(常見取值 xtls-rprx-vision)透過減少內外兩層加密的重複處理提升大流量吞吐;REALITY 則借用第三方真實網站的 TLS 指紋完成交握,使伺服端不再需要自備網域與憑證。

對客戶端使用者而言,VLESS 系列有兩個實務要點。第一,協定支援完全取決於核心世代:mihomo 核心完整支援 VLESS、XTLS 與 REALITY,原版 Clash 核心一概不識別,拿到此類節點卻出現 unsupported proxy type 錯誤,應先核對客戶端核心(詳見第六章)。第二,VLESS 的欄位數量在六種協定中最多——flow、reality-opts、client-fingerprint 等任一項與伺服端不匹配都會導致連線失敗,故此類節點務必依賴訂閱自動下發,手動抄寫容易出錯。

第四章 · Hysteria2 與 TUIC:基於 QUIC 的新一代協定

共同基礎:QUIC 帶來了什麼

前三章的四種協定全部建構在 TCP 之上,本章這兩種則建構在 QUIC 之上——QUIC 是運行於 UDP 的使用者空間傳輸協定,也是 HTTP/3 的基礎。這一層的更換帶來三項共通收益:其一,0-RTT 連線恢復,斷線重連幾乎不產生額外交握往返,首連體驗明顯優於「TCP 三向交握加 TLS 交握」的疊加;其二,連線遷移能力,手機在 Wi-Fi 與行動網路之間切換時連線可以延續,不必重建連線;其三,壅塞控制在使用者空間實作,可替換為更激進的演算法,不受作業系統核心 TCP 協定堆疊的限制。

兩條不同的實作路線

Hysteria2 走的是激進頻寬利用路線。其標誌性設計是允許使用者宣告連線頻寬(設定中的 up/down 欄位),內建的壅塞控制據此主動填滿連線,在高封包遺失、高延遲的弱網環境下,吞吐表現常明顯優於依賴標準壅塞控制的 TCP 系協定——後者遇到封包遺失會保守退讓,而 Hysteria2 不會。其外觀偽裝基於 HTTP/3,與正常的第三代網頁流量同層。TUIC 則走「更標準的 QUIC」路線:不做激進填滿,壅塞控制演算法可在 bbr、cubic、new_reno 之間選擇,並原生定義了兩種 UDP 轉發模式(over stream 與 native),對遊戲、語音這類 UDP 業務的轉發語義比 TCP 系協定乾淨得多。

必須說明的代價

兩條路線的差異還體現在頻寬宣告這一處細節上,它是 Hysteria2 最容易被誤用的欄位。up/down 並非限速閥門,而是告知壅塞控制「連線大致有多寬」,演算法據此決定發包節奏。宣告值遠高於實際頻寬,會讓傳送端持續超發,表現為封包遺失率飆升、延遲抖動加劇,實測速度反而低於不宣告;宣告值明顯偏低,則演算法主動收斂,連線利用不足。故此欄位應由服務方依線路實況給定,使用者不宜憑「我家寬頻有一千兆」隨手填寫。TUIC 一側對應的調節位是壅塞控制演算法:bbr 在高延遲長肥管道上通常最穩,cubic 在低延遲穩定連線上更平順,new_reno 僅作相容保留。兩者共通的實務結論是:QUIC 系節點的表現對參數的敏感度遠高於 TCP 系,同一台伺服器換個參數就可能換個量級,因此「這類協定不好用」的結論在核對參數來源之前不宜過早下定。

QUIC 系列的代價與收益同樣明確。第一,連線依賴 UDP,而部分接入網路對 UDP 流量施加限速或低優先權排程,此時 QUIC 系協定的實測速度可能反而不如一條普通的 Trojan 連線——是否受限只能實測,無法預判。第二,使用者空間協定堆疊加上全程加密,CPU 占用高於 TCP 系協定,直接反映為行動裝置耗電上升(第五章詳述)。第三,QUIC 依靠週期性偵測維持連線活性,手機背景常駐時的喚醒次數多於安靜的 TCP 長連線。綜上,QUIC 系協定應被理解為「特定情境的利器」,而非預設之選。

第五章 · 連線速度、資源占用與行動裝置耗電對比

比較口徑

先說明比較口徑:協定效能受伺服器規格、線路品質、傳輸層組合影響極大,任何「某協定延遲多少毫秒」的絕對數值脫離環境都沒有意義。下表給出的是同等伺服器與線路條件下的相對量級,只用於回答「同一訂閱裡幾種節點相互比較孰優孰劣」,不構成對任何具體節點的效能承諾。表中 VMess 依最常見的 WebSocket 加 TLS 組合計,VLESS 依 REALITY 組合計。

各欄結論的成因

首次連線建立一欄取決於交握層數:SS 無交握,首個封包即傳送資料;Trojan 只需一次 TLS 交握;VMess 套用 WebSocket 加 TLS 需要 TCP、TLS、WebSocket 三層依序建立,故最慢;QUIC 兩者在連線恢復時可做到 0-RTT,重連情境優勢尤其明顯。弱網吞吐一欄取決於壅塞控制:TCP 系協定受作業系統標準壅塞控制限制,遇封包遺失會保守退讓;Hysteria2 的主動填滿策略在封包遺失環境下退讓最少。CPU 一欄取決於加密層數與協定堆疊位置:單層加密的 SS、Trojan、VLESS 最省;QUIC 系的使用者空間協定堆疊本身就是持續的運算負擔。

行動裝置耗電的單獨說明

行動裝置耗電值得獨立說明,因為它的決定因素與桌面端不同。手機上 Clash 透過 VpnService 建立虛擬網路卡常駐背景,耗電由三部分構成:核心處理流量的 CPU 時間、維持連線活性的心跳喚醒、以及行動網路數據機被喚醒的次數。TCP 系協定在閒置期幾乎靜默,而 QUIC 的活性偵測更頻繁,行動網路下每次偵測都可能喚醒數據機,長時間待機的累計差異相當可觀。實測排查方法與背景策略最佳化,站內部落格《Clash 手機耗電快怎麼排查》有完整步驟;Android 端 VpnService 的授權與保持存活機制見《Clash Android 客戶端使用要點》。

第六章 · 核心家族:原版 Clash、Meta 與 mihomo 的關係

三代沿革

「Clash」一詞在今天的語境裡至少指三樣東西:一種 YAML 設定格式、一個核心家族、一批 GUI 客戶端。釐清核心沿革是理解相容性問題的前提。最初的原版 Clash 核心確立了這個生態的全部基礎範式——YAML 設定、proxies/proxy-groups/rules 三段式結構、規則分流與策略群組;其閉源的 Premium 版本額外提供 TUN 模式等強化能力。其後,社群分支 Clash.Meta 在保持設定相容的前提下大幅擴充協定支援。原版倉儲封存停止維護後,Meta 分支延續開發並更名為 mihomo,成為目前事實上的主力核心;本站首頁認證編號行所載 KERNEL mihomo,指的即是這個核心。

功能差異對照

上表還有一層容易被忽略的含意:核心世代不僅決定「能不能連」,也決定「連上之後的行為是否一致」。以 DNS 為例,原版核心的 fake-ip 實作較為樸素,遇到部分只認真實 IP 的應用容易出現解析異常,只能靠手工維護過濾名單迴避;mihomo 增加了 fake-ip 過濾強化與網域嗅探能力,可在流量中還原真實網域再交給規則比對,同樣一份規則在兩代核心上的命中結果因此可能不同。再以規則集為例,新式二進位規則集載入更快、體積更小,但舊核心完全無法解析,一旦訂閱方切換到新格式,舊客戶端會在啟動階段直接失敗而非降級運行。這類差異無法透過「改設定」彌合,只能透過更換核心解決,這也是本站在各處一致推薦維護中客戶端的原因。

設定相容性與客戶端對應

設定相容性遵循單向原則:為原版核心編寫的設定檔在 mihomo 上基本可以直接運行,mihomo 對舊欄位保持了良好相容性;反過來則不成立——包含 VLESS 節點、新式規則集或嗅探設定的檔案交給原版核心,會在啟動階段直接報錯。這條原則映射到客戶端層面即為選型結論:本站下載頁收錄的維護中客戶端(各平台首推 Clash Plus,以及 Clash Verge Rev、FlClash 等)均內建 mihomo 核心,六種協定全部可用;已停止維護的 Clash for Windows 與 ClashX Meta 封存項目,前者搭載原版核心,無法識別 QUIC 系與 VLESS 節點。若節點列表出現 unsupported proxy type 一類錯誤,應對照本表更換 mihomo 系客戶端,而非修改訂閱。各客戶端的完整橫向對比另見客戶端對比頁。

第七章 · 訂閱格式與設定相容性

三種常見格式

日常接觸到的「訂閱」實際上存在三種形態,相容範圍各不相同。第一種是 Clash 專用訂閱:一份完整的 YAML 文件,包含 proxies、proxy-groups、rules 全部三段,Clash 系客戶端可直接讀取,這是最理想的形態。第二種是單節點分享連結:ss://、vmess://、trojan:// 一類 URI,一條連結描述一個節點,不含任何分組與規則資訊。第三種是通用聚合訂閱:多行分享連結整體以 Base64 編碼後透過 HTTP 分發,是跨客戶端生態的最大公分母格式。後兩種並非 Clash 原生格式,需經過轉換才能使用——多數訂閱服務會同時提供 Clash 專用網址,應優先取用;mihomo 系客戶端普遍內建了對常見分享連結的解析能力,但轉換結果只含節點,分組與規則仍需設定檔補齊。

節點與設定分離:proxy-providers

進階用法中值得掌握的機制是 proxy-providers:把節點來源宣告為外部資源,主設定只負責分組與規則,核心依週期自動抓取更新節點。其價值在於自訂規則與訂閱更新互不干擾——直接改寫訂閱下發的完整設定,下次更新即被覆寫;providers 結構則可長期維護。典型宣告如下:

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub?token=xxxx"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

與 proxy-providers 同源的機制還有 rule-providers,兩者一併使用才構成一套可長期維護的設定骨架:節點來源交給前者依週期抓取,網域與 IP 規則集交給後者遠端更新,主設定檔裡只保留策略組結構與少量個人自訂規則,體量通常不過百行。這樣組織的好處在升級時體現得最明顯——換訂閱只需替換一個網址,換規則來源只需替換一個規則集網址,個人客製部分始終不受影響。需要留意的是三項參數:interval 決定抓取週期,過短會給上游造成無謂壓力,一般取一天較為合適;path 指向本地快取檔案,同一份設定內不同 provider 的路徑不得重名,否則後寫入者會覆寫前者;health-check 的偵測網址與間隔決定策略組自動切換的靈敏度,間隔過短會持續產生背景流量,在行動裝置上亦會推高耗電,與第五章的結論相互呼應。

相容性注意事項

有三條實務經驗值得記錄。其一,同一訂閱網址對不同客戶端可能回傳不同內容——伺服端常依請求的 User-Agent 判斷客戶端類型並下發相應格式,故「瀏覽器開啟訂閱網址所見的內容」與「客戶端實際取得的內容」未必一致,排查訂閱問題時不應以瀏覽器所見為準。其二,新協定節點的可用性由訂閱輸出端與核心共同決定:即便客戶端運行 mihomo,若訂閱端仍依原版欄位輸出,Hysteria2、VLESS 等節點也不會出現在列表中,此時應向服務方索取 mihomo 格式的訂閱網址。其三,訂閱匯入後應設定自動更新間隔,長期未更新的訂閱是「節點全部逾時」的高頻原因之一。匯入操作的完整步驟見入門指南,各格式差異的詳細討論見部落格《Clash 訂閱連結匯入教學》。

第八章 · 依使用情境的協定選型建議

選型的前提認知

先釐清一個常見誤解:Clash 客戶端裡並沒有一個「協定選擇開關」。所謂選型,是在訂閱下發的節點列表中,依節點類型有傾向性地選用——多數訂閱為多協定混編,同一地區往往同時提供數種類型的節點;策略群組亦可將不同協定的節點編入同一群組,依延遲自動切換。因此下列建議的用法是:對照情境確定優先類型,在節點列表中優先選用該類型,並保留一類備援。

情境對照表

三條補充條款

其一,遊戲與會議情境除協定外還涉及流量接管方式:此類程式常不遵循系統代理設定,需在客戶端開啟 TUN 模式才能完整接管,兩種接管機制的差異見部落格《Clash TUN 模式和系統代理有什麼區別》。其二,行動裝置在耗電與速度之間取捨時,建議以第五章耗電欄為主要依據,QUIC 系節點僅在確實有弱網或大流量需求時啟用。其三,任何建議都無法取代實測——同類型節點因伺服器與線路不同,表現差異可能大於協定之間的差異,選定類型後仍應在實際使用時段做對比驗證。

一份可重複使用的實測流程

既然實測不可替代,不妨把它固定成流程,避免每次都憑感覺切換節點。第一步,固定變數:選定同一地區的若干節點,類型各異,在同一時間段內測試;跨時段、跨地區的對比數據沒有可比性,因為線路負載本身隨時間波動。第二步,分別記錄三項指標:客戶端內建延遲測試給出的往返時間(反映建立連線品質)、一次固定大小檔案的實際下載耗時(反映吞吐)、以及連續使用十分鐘後是否出現斷流或速度衰減(反映穩定性)。第三步,把結論落到策略組:把實測最優的兩三個節點編入手動選擇組置於首位,再把同地區其餘節點編入自動選擇組作為備援,而不是把幾十個節點一律丟進同一個自動組——後者在延遲接近時會頻繁抖動切換,反而影響體驗。第四步,每次訂閱更新後抽查一次:節點背後的伺服器與線路是會變的,三個月前的結論不必然仍然成立。整套流程一次約十五分鐘,對長期使用者而言是回報最高的一次性投入。

選型三步收束

全書內容收束為三步操作。第一步,確認客戶端核心:維護中的 mihomo 系客戶端(各平台首推 Clash Plus,安裝包見下載頁)可使用全部六種協定,舊核心客戶端請先更換。第二步,確認訂閱供給:檢查節點列表實際包含哪些類型,缺少所需類型時向服務方索取 mihomo 格式訂閱。第三步,依上表情境排序並實測驗證,保留一類 TCP 系節點作為備援。操作層面的疑問請至入門指南逐步執行,異常錯誤請至常見問題頁對照排查。