Clash 協定與核心參考

第一章 · 先看這一節:本頁怎麼用,與教學頁如何分工

站內兩條主線先分清楚。教學頁是上手主線:裝好客戶端、匯入訂閱、選好模式、驗證分流,照著做完就能用,全程不要求理解協定細節。本頁是另一條線——系統查閱手冊,回答的是「為什麼」與「該選哪個」:訂閱節點列表裡那一串協定類型各自是什麼來歷,連線速度差在哪一步,手機上誰更省電,幾個核心之間到底是什麼關係。兩頁互為補充:第一次設定,請先到教學頁把主線走完;設定能跑了、想把節點列表裡的選項看明白,再回來這裡逐章查閱。

本頁的編排方式按「選型決策」排列,不按字母順序。第二、三章講協定本身:先是經典三件套 Shadowsocks、VMess、Trojan 的誕生背景與設計取捨,再談新一代的 VLESS、Hysteria2、TUIC 各自解決了什麼老問題。第四、五章做橫向比較:連線建立速度、傳輸量瓶頸、CPU 與記憶體占用,以及行動裝置最在意的電量表現。第六、七章轉向承載協定的軟體層:核心家族關係與設定相容性,以及訂閱格式為什麼會「在這個客戶端能用、換一個就報錯」。第八章把前面所有結論收攏成一張按情境查閱的選型清單。

閱讀路徑依讀者類型分三種。剛接觸 Clash 的讀者,建議依章節順序通讀第二到第四章,建立「協定是傳輸方案、核心是執行引擎、客戶端是操作介面」這個三層概念,後面所有結論都掛在這個架構上。已經在用、但遇到「某類節點連不上」「某個協定特別耗電」這類具體問題的讀者,可直接跳到第五章與第七章,再配合疑難排解裡對應的分類條目。替家人朋友選客戶端、自己不打算深入研究的讀者,看完第六章的核心對照表與第八章的情境清單即可離開,十分鐘就夠。

名詞先在此約定好。本頁所說的「協定」專指節點的傳輸協定類型,即設定檔 proxies 段落裡 type 欄位的值;所說的「核心」指真正處理流量的核心程式;所說的「客戶端」指帶圖形介面的軟體外殼。單一名詞的完整解釋集中在概念速查,具體故障的處理步驟集中在疑難排解,本頁不重複展開,遇到生詞隨手查閱即可。

還有一條界線先劃清楚:本頁只討論工程取捨——握手輪次、加密開銷、電量、相容性,不評價任何服務商,也不涉及節點來源。節點用什麼協定是訂閱提供方決定的,讀者真正能做的選擇有兩個:一是挑一個核心能力涵蓋自己訂閱的客戶端組合,二是當訂閱同時提供多種協定的節點時,知道在什麼情境下把策略組切到哪一類。本頁所有建議都由這兩個決策點出發。

第二章 · 經典三件套:Shadowsocks、VMess、Trojan 的來歷與取捨

先看三個「老資歷」。它們出現得早、部署面廣,幾乎所有核心都支援,是訂閱裡最常見的類型。理解它們各自的設計出發點,後面看新協定時才知道「新」在哪裡。

Shadowsocks:把事情做少的典範

Shadowsocks(設定裡寫作 ss)是三者中最早成型的方案,設計哲學是「做少」:客戶端與伺服端約定一個預先共享的金鑰,流量用對稱加密演算法直接封裝轉發,沒有額外的會話協商,沒有複雜的元資料結構。現行實作普遍採用 AEAD 類加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),兼顧加密與完整性校驗。少,帶來的直接好處是快與省:建連幾乎沒有協定層面的額外往返,加解密開銷在現代 CPU 上可以忽略,連樹莓派等級的路由器都跑得動。代價同樣明確:協定本身不帶傳輸層多工,每條連線各自獨立;功能擴充空間小,想加能力只能在外層疊加外掛。給它的定位一句話:輕、快,對老舊裝置最友善,是「能用就好」情境的保底選擇。

VMess:生態換來的欄位,欄位帶來的負擔

VMess 出自 V2Ray 生態,思路與 Shadowsocks 相反——做全。它自帶使用者 ID 體系、內建加密、可自由組合的傳輸層(裸 TCP、WebSocket、HTTP/2 等都能掛),欄位豐富意味著伺服端可以做精細的使用者與路由管理。但欄位多也意味著負擔:VMess 的驗證機制依賴客戶端與伺服端的時間戳校驗,兩端系統時間偏差過大會直接導致握手失敗——「所有 VMess 節點集體超時,其他協定正常」這個經典故障,十有八九是本機時間不準,排查思路在節點超時排查順序一文有完整流程。另外,VMess 常見搭配是 WebSocket + TLS,封裝層數多,建連輪次與 CPU 開銷都比 Shadowsocks 高一截。定位:生態成熟、設定靈活,但屬於「重」方案,新部署已逐漸被 VLESS 取代。

Trojan:直接借用 HTTPS 的成熟路徑

Trojan 的取捨又是另一個方向:不自己發明加密,直接把流量放進標準 TLS 連線,伺服端行為與一台普通 HTTPS 網站伺服器一致。工程收益很實際——TLS 是網際網路上驗證最充分的加密通道,握手路徑成熟,各類網路中介裝置相容性好,客戶端實作也簡單。代價是部署門檻轉移到伺服端:需要一張有效的網域憑證,憑證過期或網域解析異常都會讓節點整體無法使用,這類故障客戶端側無解,只能等訂閱提供方處理。對使用者而言,Trojan 節點的日常表現通常穩定、延遲可預期,是網頁瀏覽與影音情境的穩妥選項。

第三章 · 新一代協定:VLESS、Hysteria2 與 TUIC 各自解決了什麼

三個新方案不是憑空出現的,每一個都針對上一章某個具體痛點。看它們時抓住一個問題:它把哪部分工作從協定層移走了,又把哪部分做重了。

VLESS:為 VMess 減重

VLESS 可以理解成 VMess 的減法版本:去掉內建加密與時間戳校驗,把機密性完全交給外層 TLS,協定本身只保留最精簡的使用者識別與路由資訊。少了一層加密封裝,CPU 開銷顯著下降,也不再有時間偏差導致的握手失敗——VMess 使用者最頭痛的兩件事一次解決。它常與新式傳輸層組合出現,例如基於 TLS 會話特徵優化的傳輸方案,這些組合的可用性取決於核心版本,這一點第七章講訂閱相容性時會展開。選型時記一條:同一訂閱裡若同時有 VMess 與 VLESS 節點,且客戶端核心支援,優先選 VLESS,幾乎是純收益。

Hysteria2:為劣質線路設計的 QUIC 方案

Hysteria2(設定裡寫作 hysteria2)換了地基:不再基於 TCP,而是建構在 QUIC(UDP 之上的現代傳輸協定)上,並搭配了激進的自訂壅塞控制策略。這套組合針對的是一個具體情境——高遺失率、高抖動的線路,例如行動網路、跨電信商的長距離連線。傳統 TCP 在丟包時會大幅退讓,速度斷崖式下滑;Hysteria2 的策略是按預設頻寬持續推進,丟了就補,弱網環境下的傳輸量表現常明顯優於 TCP 系協定。代價有兩個:一是持續的頻寬估算與重傳邏輯讓它在「好線路」上沒有優勢,還多耗資源;二是基於 UDP,少數網路環境對 UDP 流量限速或干擾,遇到時表現反而不如 TCP 系。定位:弱網利器,好網平平。

TUIC:把 QUIC 的多工用滿

TUIC 同樣建構在 QUIC 上,但著重點不同:它充分利用 QUIC 原生的多工與 0-RTT 會話恢復——多條代理請求跑在同一條 QUIC 連線裡,互不阻塞;曾連過的伺服端可以近乎零往返地恢復會話,第二次建連幾乎是瞬間完成。對高頻、小型請求的情境(網頁瀏覽、即時通訊)體感提升明顯。與 Hysteria2 相比,TUIC 的壅塞控制更接近常規實作,不做激進的頻寬搶占,持續開銷更溫和。同樣因為走 UDP,它繼承了與 Hysteria2 相同的環境依賴:所處網路對 UDP 不友善時,表現會打折。

第四章 · 連線速度與資源占用:第一筆資料由握手輪次決定

「哪個協定快」是被問得最多、也最容易答錯的問題。先把「快」拆成兩半:建連速度(點開連結到內容開始載入那一小段)與持續傳輸量(下載大檔案、看高位元率影片時的穩定速率)。兩者的決定因素完全不同,選型時要分開看。

建連速度:數一數往返輪次

建連快慢基本由「客戶端與伺服端之間要來回幾次」決定,每一次來回消耗一個 RTT(往返時延)。粗略地數:Shadowsocks 走 TCP,一次 TCP 握手後即可傳送資料;Trojan 與 VLESS 在 TCP 之上還要完成一次 TLS 握手,多一輪;VMess 若搭配 WebSocket+TLS,再疊一層升級握手,輪次最多。QUIC 系的 Hysteria2 與 TUIC 把傳輸握手與加密握手合併成一次互動,首次連線在一個往返內完成;TUIC 的 0-RTT 恢復更進一步,回訪曾連過的伺服端時幾乎不花輪次。當實體延遲本身較高時(例如跨洲線路 RTT 200ms 以上),輪次差異會被放大成體感差異——同一訂閱裡 QUIC 系節點「點開就有反應」、TCP 系節點「頓一下才動」,多半就是這個原因。

持續傳輸量:瓶頸通常不在加密

持續傳輸階段,現代 CPU 做 AEAD 加解密的速度遠超家用頻寬,加密本身很少成為瓶頸。真正拉開差距的是傳輸層對丟包的反應:TCP 系協定(SS、VMess、Trojan、VLESS)受作業系統 TCP 協定堆疊的壅塞控制支配,丟包即降速;Hysteria2 用自訂策略硬頂,弱網傳輸量領先;TUIC 介於兩者之間。所以結論反直覺:線路品質好時,六個協定的傳輸量差異很小;線路品質差時,差異主要來自傳輸層而非協定本身。

記憶體與 CPU:數量級參考

資源占用方面給定性排序即可。CPU 開銷從低到高大致是:SS ≈ VLESS < Trojan < TUIC < VMess ≈ Hysteria2——VMess 輸在多層封裝,Hysteria2 輸在持續的頻寬探測。記憶體差異主要來自連線數而非協定:QUIC 系協定單一連線承載多路請求,連線總數少,記憶體反而占優;在路由器這類記憶體以 MB 計的裝置上,SS 的極簡實作仍是唯一穩妥選項。

第五章 · 行動裝置電量:耗電的三個來源,協定只是其一

「開了 Clash 手機掉電快」是行動裝置最高頻的抱怨。先把責任拆清楚:耗電來自三層——協定本身的保活行為、客戶端的健康檢查策略、系統層面的常駐方式。三層各自獨立,逐層排查才不會冤枉協定。

協定層:UDP 保活是隱形電力殺手

QUIC 系協定(Hysteria2、TUIC)為了維持 UDP 會話,需要週期性傳送保活封包;Hysteria2 的頻寬探測邏輯在連線活躍時還會持續運作。每一次發送封包都會短暫喚醒行動裝置的射頻模組,而射頻喚醒正是行動裝置耗電的大宗。TCP 系協定(SS、Trojan、VLESS)在無流量時可以長時間靜默,系統能進入更深的省電狀態。所以在電量優先的情境下,結論恰好與第四章互補:插電或 Wi-Fi 情境放心用 QUIC 系,純電池的行動網路情境優先選 TCP 系輕協定。

客戶端層:健康檢查間隔是最值得動手調整的一項

url-test 類策略組會按 interval 週期對組內所有節點發起測速,間隔設得太密(例如 60 秒),等於讓手機每分鐘把幾十個節點逐一喚醒測一遍。行動裝置把間隔放寬到 600 秒以上,體感延遲幾乎無差,電量收益立竿見影:

proxy-groups:
  - name: 自動選擇
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600        # 行動裝置建議 ≥600 秒
    tolerance: 80        # 新舊節點延遲差小於 80ms 時不切換
    proxies: [節點A, 節點B]

tolerance 也值得一併設定:沒有它,兩個延遲相近的節點會被反覆切換,每次切換都伴隨一輪重新建連。訂閱由提供方託管、無法改設定的,可以在客戶端介面裡把自動測速組手動切成 select 型固定節點,效果等同。

系統層:TUN 常駐與廠牌背景執行原則

TUN 模式建立虛擬網卡全面接管流量,行程必須常駐,Android 各廠牌的背景限制策略又會反覆嘗試砍掉再重啟它,一砍一啟比安靜常駐更耗電。TUN 與系統代理的機制差異在TUN 模式與系統代理的差異一文有逐層拆解;Android 端從電池統計定位耗電來源、逐項關閉的完整清單,見Android 耗電排查。一個夠用的原則:手機上沒有全域接管需求就用系統代理模式,把 TUN 留給桌面端。

第六章 · 核心家族:原版、Meta 與 mihomo 到底什麼關係

很多相容性問題的根源是把「Clash」當成一個軟體。實際上它是一個家族:核心負責按設定處理流量,客戶端只是套在核心外面的操作介面。搞清家系,第七章的相容性問題就一目了然。

家系:一次分岔,兩個名字

最初的開源專案是原版 Clash 核心,配套還有閉源的 Premium 版本(多出 TUN 等能力)。原版倉庫停止維護後,由社群維護的 Clash.Meta 分支接過了演進主線,持續加入新協定與新規則類型,後來改名為 mihomo——所以「Clash.Meta」與「mihomo」是同一條血脈的先後兩個名字,日常說的「Meta 系核心」指的就是它。今天仍在活躍維護、支援全部六類協定的,只有 mihomo 這一支。選擇客戶端時,第一個要確認的就是它內建哪個核心。

能力差異:一張表看全

規則層面補一句:mihomo 對原版常用欄位(port、mode、DOMAIN-SUFFIX、GEOIP、MATCH 等)保持向下相容,舊設定直接餵給 mihomo 通常照常運作;反方向則不行——設定裡只要出現一條 mihomo 專屬語法,原版核心就會報錯拒載:

rules:
  - GEOSITE,category-ads-all,REJECT   # 僅 mihomo 識別,原版核心報錯
  - GEOIP,CN,DIRECT                   # 兩系核心通用
  - MATCH,手動選擇                     # 兩系核心通用

客戶端與核心的對應關係

落到客戶端下載頁的貨架上:Clash Plus(全平台首推)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 都基於 Meta 系能力,六類協定全部可用;ClashX Meta 同屬 Meta 系但已停止維護;Clash for Windows 基於原版核心且已停止維護,是目前「訂閱裡有新協定節點卻載入失敗」最常見的病灶——還在用它的讀者,遷移到 Clash Verge Rev 的完整流程見Windows 安裝 Clash Verge Rev 全流程。選型邏輯一句話收尾:訂閱裡只要出現過 VLESS、Hysteria2、TUIC 任意一種,客戶端就必須是 Meta 系,沒有第二個答案。

第七章 · 訂閱格式與欄位相容:為什麼換個客戶端就報錯

協定與核心之間還隔著一層:訂閱。同一條訂閱連結,在 A 客戶端節點齊全、在 B 客戶端一片空白,問題幾乎都出在這一層。這一章把訂閱的形態與失敗模式講清楚。

訂閱的兩種形態

訂閱連結傳回的內容分兩類。第一類是完整的 Clash 設定(整份 YAML,含 proxies、proxy-groups、rules),客戶端拿來即用,分流策略由訂閱提供方寫好;第二類是通用節點列表(常見為 Base64 編碼的分享連結集合),Clash 系客戶端不能直接使用,需要經過訂閱轉換服務翻譯成 Clash 格式。轉換環節是個隱形變數:轉換範本決定輸出設定用哪一系核心的語法,範本陳舊就可能把 Hysteria2 節點悄悄丟棄,或輸出原版核心不認得的欄位。節點數量對不上時,先確認訂閱形態、再檢查轉換設定,順序不要反過來。

欄位相容:一個欄位掀翻整份設定

YAML 設定是整體載入的,核心遇到不認得的節點 type 或欄位,不同實作的處理方式不同:寬鬆的會跳過該節點(表現為節點變少),嚴格的直接拒載(表現為訂閱匯入失敗、節點列表全空)。以一個 Hysteria2 節點為例,它的專屬欄位原版核心一個都不認得:

proxies:
  - name: 範例-HY2
    type: hysteria2          # 原版核心不識別此類型
    server: example.com
    port: 443
    password: your-password
    sni: example.com

反過來也有坑:個別客戶端會在匯入時「順手」改寫設定、補上預設欄位,改寫邏輯不同,同一訂閱在不同客戶端的最終行為就可能有細微差異。遇到「只有某個客戶端異常」的情況,把訂閱連結直接在瀏覽器裡開啟、核對原始內容,是最快的定位手段。

匯入失敗的排查順序

固定四步,依序執行:①確認訂閱未過期——多數失效訂閱回傳空內容或錯誤頁,而不是報錯;②確認客戶端是 Meta 系(對照第六章表格);③檢查是否經過訂閱轉換、轉換範本是否支援訂閱裡的全部協定;④查看客戶端日誌裡的 YAML 報錯行號,定位具體欄位。前兩步就能解決大半問題;「節點列表是空的」「所有節點都超時」這兩類高頻症狀,在疑難排解與節點超時排查一文裡各有獨立的完整流程,照著走即可。

第八章 · 依情境選型:一張速查清單

前七章的結論,整理成一張按情境查閱的表。用法:先在左列找到自己的主要情境,依「優先—次選」順序在策略組裡固定或分組;訂閱裡沒有優先項時,退到次選即可,不必強求。

表格之外,三條通用原則值得寫在頁邊。其一,協定選型永遠排在節點選擇之後:同協定不同節點的品質差異,通常大於同節點不同協定的差異,先用延遲測試與實際下載把節點池篩過一遍,再談協定偏好。其二,用策略組固化決策,而不是每天手動選:把弱網優先的 QUIC 系節點編成一組、省電優先的 TCP 系編成另一組,情境切換時切組,而不是在幾十個節點裡翻找——策略組的編寫方法在教學頁的進階小節有分步說明。其三,定期回顧:訂閱提供方會調整節點的協定組成,核心也在持續演進,本頁的定性結論穩定,但你手上那份訂閱的最優解每隔幾個月值得重新驗證一次。

選型想好了,落地只剩兩步:到客戶端下載頁依平台取一個 Meta 系客戶端——全平台首推 Clash Plus,Windows/macOS/Linux 也可選 Clash Verge Rev 或 FlClash;然後回教學頁把訂閱匯入與分流驗證走完。設定過程中卡在任何一步,疑難排解依分類索引查閱,生詞隨手查概念速查。這份參考寫到這裡,該圈的重點都圈完了。