Clash 協定與核心技術參考

Clash 系用戶端本身不發明協定,它是一個「多協定出站框架」:設定檔裡每個節點宣告自己的 type,核心依類型呼叫對應的協定實作。因此選協定的第一步,不是糾結哪個「最快」,而是搞清楚每種協定在設計上犧牲了什麼、換來了什麼。六種主流協定可以按兩個維度粗分:傳輸層走 TCP 還是 UDP(QUIC),以及協定本身是否依賴 TLS 提供加密。

Shadowsocks:極簡加密轉送

Shadowsocks 是六者中最早的一代,設計目標只有一個:用盡可能少的程式碼,在用戶端與伺服器端之間建立一條加密的 SOCKS 轉送通道。協定標頭極短,沒有交握協商階段,連線建立後直接傳輸密文。早期的串流加密方案已被淘汰,現行實作統一使用 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),同時提供機密性與完整性驗證。它的取捨很清楚:犧牲了協定層的可擴充性(沒有多工複用、沒有內建 UDP over TCP),換來了最低的實作複雜度與最小的每包開銷。至今仍是低規格裝置與老舊路由器上的首選,也是很多訂閱裡的「保底節點」類型。SS2022 系列套件在金鑰管理與抗重播上做了強化,核心層面視為同一 ss 類型的不同 cipher。

VMess:V2Ray 時代的多功能協定

VMess 隨 V2Ray 專案誕生,定位與 SS 相反:寧可複雜,也要功能齊全。它在協定標頭裡攜帶使用者 ID、加密方式、時間戳記等元資料,支援動態連接埠等特性,並且天然與 V2Ray 的傳輸層外掛體系(WebSocket、gRPC、HTTP/2)組合使用。代價是協定標頭開銷大於 SS,且早期依賴用戶端與伺服器端時間同步——本機時間偏差過大時會交握失敗,這是排查 VMess 節點連不上時的經典檢查項。VMess 的價值在生態:大量面板、訂閱轉換工具圍繞它建構,相容性覆蓋面廣。作為純協定來看,它的加密與封裝設計已顯厚重,這直接催生了後面的 VLESS。

Trojan:把自己藏進 HTTPS 的形態裡

Trojan 的思路是做減法:既然 TLS 已經提供了完善的加密,協定層就不再重複加密,只在 TLS 通道內傳一個簡單的認證標頭加原始流量。從外部觀察,一條 Trojan 連線與一般 HTTPS 存取在傳輸形態上高度相似;認證失敗的連線會被伺服器端回退到一個真實網站。它的取捨是:強烈依賴一套可用的網域與證書,部署門檻高於 SS,但用戶端實作極薄、執行開銷低。對使用者而言,Trojan 節點的連線行為穩定可預期,TCP + TLS 的組合在各種網路環境下相容性最好,幾乎不存在「電信業者把這類流量單獨限速」的問題。

VLESS:去除冗餘的下一代框架

VLESS 是 Xray 生態對 VMess 的重構:去除協定自帶加密(交給 TLS),去除時間戳記依賴,協定標頭壓縮到最小,只保留 UUID 認證與必要的路由資訊。這讓它成為一個「薄殼」,真正的差異化能力來自搭配的傳輸方案——XTLS Vision 透過流量控制減少 TLS in TLS 的雙重加密開銷,REALITY 則免去了自持證書的要求。選型時要注意:VLESS 本身幾乎沒有開銷,效能表現取決於伺服器端配的是哪套組合,訂閱裡同樣寫著 vless 的兩個節點,實際行為可能差別很大。用戶端側需要核心支援對應的傳輸特性,這也是後文核心章節強調 mihomo 的原因之一。

Hysteria2:為丟包環境而生的 QUIC 協定

Hysteria2 建構在 QUIC 之上,核心賣點是自訂壅塞控制:傳統 TCP 的壅塞演算法在高丟包連線上會大幅退讓,跨洋連線實際吞吐經常只有頻寬的零頭;Hysteria2 採用更激進的傳送策略,允許使用者直接宣告上下行頻寬,在丟包 5% 以上的連線上仍能維持接近標稱的速度。取捨同樣明顯:激進傳送封包在壅塞網路中會擠占他人頻寬,部分電信業者對持續大流量 UDP 連線會有 QoS 降速策略,遇到這種網路時 QUIC 系協定反而不如 TCP 系穩定。它適合「連線品質差但沒有 UDP 限制」的情境,不適合當成無腦預設項。

TUIC:面向低延遲的另一條 QUIC 路線

TUIC 與 Hysteria2 同屬 QUIC 系,但側重點不同:它不做激進頻寬爭搶,而是充分利用 QUIC 的原生能力——0-RTT 交握讓重新連線幾乎無感,連線內多工複用避免隊頭阻塞,UDP 流量原生轉送(native 模式)對遊戲、即時語音這類小封包高頻的應用尤其友善。壅塞控制可在 cubic、new_reno、bbr 之間選擇,行為比 Hysteria2 溫和。它的短板是生態較小,提供 TUIC 節點的服務商少於其他協定,用戶端支援要求核心為 Meta 血統。延遲敏感、丟包不嚴重的情境下,TUIC 的手感通常是六者中最好的。

把六種協定按傳輸層切開,會發現效能討論裡的大部分現象都能歸因到這一層。SS、VMess、Trojan、VLESS 的主流形態走 TCP,Hysteria2 與 TUIC 走 UDP 上的 QUIC。兩條路線的差異體現在四個方面。

交握成本

TCP + TLS 1.3 建立一條新連線需要一次 TCP 三方交握加一次 TLS 交握,首位元組延遲約為兩個 RTT;QUIC 把傳輸交握與加密交握合併,首次連線一個 RTT,重用會話時 0-RTT 直接傳送資料。實體延遲 200ms 的跨洋連線上,這個差距在頻繁建立連線的情境(網頁開啟瞬間的數十個並行請求)裡可以被明顯感知。TCP 系協定透過連線多工(mux)緩解,但 mux 引入了下一個問題。

隊頭阻塞

TCP 是單一有序位元組流:一個封包丟失會卡住這條連線上所有後續資料,即使後續資料屬於不相關的請求。在 TCP 連線上做多工複用,等於把多個請求綁上同一條容易被單點卡死的流,丟包環境下體感反而變差——這是「mux 不要隨便開」的原理。QUIC 在協定內以獨立串流(stream)傳輸,單一串流丟包不影響其他串流,多工複用是零負擔的原生能力。

中間裝置友善度

TCP 443 連接埠的 TLS 流量是網際網路上最普遍的形態,任何網路環境都必須放行;UDP 長連線在部分電信業者與企業網路中會被 QoS 限速、縮短 NAT 逾時甚至丟棄。這是 QUIC 系協定「有時飛快有時無法使用」的根源。選型結論:環境未知時 TCP 系是安全牌,QUIC 系需要實測驗證。

偽裝傳輸的位置

WebSocket、gRPC 這類傳輸外掛屬於 TCP 系協定的可選外殼,常用於套 CDN 中轉的情境;代價是每層封裝都增加延遲與開銷,CDN 回源本身也引入額外一跳。QUIC 系協定不走這套體系。訂閱裡同名協定的不同節點若傳輸外殼不同,延遲表現可能差出一倍,測速時應分開對待。

協定本身的加解密開銷在現代硬體上都很小,真正拉開差距的是交握模型、壅塞控制與封裝層數。下表是同等連線條件下的定性對比,方向可靠,倍數因環境而異。

兩點解釋。其一,QUIC 系協定 CPU 佔用偏高不是加密的問題,而是 QUIC 協定堆疊執行在使用者態,收送封包路徑比核心態 TCP 長;桌面平台無感,低功耗裝置上可測出差異。其二,「高丟包連線吞吐」這一行的差距遠大於表格能表達的程度:同一條丟包 10% 的連線,TCP 系協定可能只跑出頻寬的十分之一,Hysteria2 能維持一半以上。連線品質決定了這張表哪一行對你重要。

測速方法建議:在用戶端裡對同一服務商的不同協定節點做延遲測試只反映交握 RTT,不反映吞吐;吞吐要用實際下載或串流媒體載入來驗證,並且分早晚高峰各測一次。下載頁提供的各用戶端均內建延遲測試,Clash Plus 的分組測速可以一次比完同組全部節點。

手機上代理用戶端的耗電由三部分構成:VPN 服務常駐的基礎開銷、協定堆疊處理流量的 CPU 開銷、以及最關鍵的——網路行為觸發的行動網路/Wi-Fi 無線電喚醒。第三項佔大頭。協定對耗電的影響,主要透過心跳與重新連線行為傳導。

心跳與保活

TCP 系協定依賴 NAT 對應存活,用戶端或伺服器端通常以數十秒等級的 keepalive 維持;每次心跳都可能把已休眠的行動網路模組喚醒到高耗電狀態並維持數秒。QUIC 系協定同樣需要保活,但 QUIC 的連線遷移(connection migration)允許網路切換(Wi-Fi 與行動網路之間)後沿用原連線,省去一輪完整重新連線;TCP 系協定在每次網路切換後必須全部重建連線,伴隨一波集中的交握流量與無線電活躍。頻繁在 Wi-Fi 與行動網路間切換的使用模式下,QUIC 系協定的電量表現通常更好。

加密與協定堆疊開銷

AEAD 加解密有硬體指令加速,各協定差距可忽略。QUIC 使用者態協定堆疊在行動晶片上的額外 CPU 消耗可測但不顯著,持續大流量傳輸(長時間影片)時才會體現;輕量瀏覽情境下可以不計。

比協定影響更大的因素

實測中,用戶端設定對耗電的影響遠大於協定選擇:規則集自動更新間隔過短、日誌等級開在 debug、DNS 平行解析策略激進、節點自動測速間隔過密,任何一項的耗電都可能超過協定差異一個量級。逐項排查方法見部落格文章手機上 Clash 耗電嚴重怎麼排查,Android 電池最佳化白名單與 iOS 按需連線的具體設定也在該文中。

「Clash」這個名字在今天至少指三樣東西:一個已停止開發的原版核心專案、它的社群強化分支 Clash.Meta、以及 Meta 更名延續至今的 mihomo。GUI 用戶端(Clash Plus、Clash Verge Rev、FlClash 等)都是套在核心外面的圖形介面,核心決定了協定支援範圍與設定語法上限。三者的譜系與差異如下。

三代核心譜系

原版 Clash 確立了 YAML 設定格式、規則分流模型與 RESTful 控制介面,支援 SS、VMess、Trojan 等當時的主流協定;專案停止開發並移除倉庫後,原版核心不再獲得任何更新,新協定一概不支援。Clash.Meta 是社群在原版基礎上的強化分支,補齊了 VLESS、Hysteria 系、TUIC 等新協定與大量分流能力;後因避免名稱糾紛更名為 mihomo,專案本體、設定格式與開發團隊均未中斷——mihomo 就是 Meta,只是換了名字。當前生態裡仍在積極維護的 Clash 系核心只有 mihomo 一個,主流 GUI 用戶端也已全部移轉到它。三代核心的完整來龍去脈見部落格文章Clash 原版、Meta 與 mihomo 核心差異對照。

功能差異對照

設定相容性

mihomo 對原版設定基本向下相容:一份能在原版核心執行的 YAML,通常可以直接被 mihomo 載入。反向不成立——設定裡只要出現 mihomo 擴充欄位(如 hysteria2 節點類型、TUN 段、強化 DNS 欄位),原版核心會直接報錯退出。判斷一份設定是否依賴 mihomo,可檢索這類欄位:

proxies:
  - name: hy2-node
    type: hysteria2      # 原版核心不識別該類型
    server: example.com
    port: 443
    password: your-password

tun:                     # 原版開源核心無此段
  enable: true
  stack: system
  auto-route: true

選型結論直接給出:今天沒有理由新裝原版核心。協定覆蓋、TUN 模式、維護狀態三項都指向 mihomo;本站下載頁提供的 GUI 用戶端均基於 mihomo 或其衍生版本,核心區也提供 mihomo 各平台裸核心,供伺服器與路由器使用者使用。

訂閱是服務商向用戶端分發節點的載體,格式不符是匯入失敗的頭號原因。當前流通的訂閱主要有三類。

三類訂閱格式

第一類是 Clash YAML 訂閱:一份完整或部分的 Clash 設定檔,包含 proxies、proxy-groups、rules 等段,Clash 系用戶端原生支援,資訊最完整,分組與分流規則可由服務商預先配置。第二類是 Base64 通用訂閱:把 ss://、vmess:// 等節點分享連結逐行拼接後整體編碼,只含節點不含規則,歷史最悠久、相容面最廣;現代 Clash 用戶端多能自動識別並轉換,但轉換後需要用戶端自行補分組與規則。第三類是其他生態的專有格式(如 sing-box 的 JSON),Clash 系用戶端不直接支援,需經訂閱轉換服務翻譯。

協定支援對訂閱的影響

格式正確不代表全部節點可用:YAML 訂閱裡若包含 hysteria2、tuic、vless 類型節點,而用戶端核心是舊版或原版,輕則這些節點被靜默丟棄,重則整份設定載入失敗。表現為「訂閱匯入成功但節點清單比別人少」或「更新訂閱後用戶端報錯」。處理順序:先確認用戶端核心為 mihomo 血統,再檢查訂閱連結是否帶了服務商提供的 Clash 專用參數(很多服務商同一訂閱網址透過 URL 參數輸出不同格式)。

用 proxy-providers 管理訂閱

手動維護設定的使用者,建議用 proxy-providers 把「節點來源」與「分組規則」解耦:節點由訂閱網址定期拉取,分組與規則寫在本機設定裡,訂閱更新不會覆蓋個人客製。最小範例:

proxy-providers:
  main:
    type: http
    url: "訂閱網址"
    interval: 86400        # 拉取間隔(秒),行動裝置不宜過短
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

綜合前面各章,給出可直接執行的判斷流程。前提:節點協定由服務商決定,以下建議用於「同一服務商提供多種協定節點時選哪個」,以及「更換服務商時優先考察什麼」。

桌面日常使用(辦公 / 瀏覽 / 影音)

優先 Trojan 或 VLESS。TCP + TLS 組合在任何網路下相容性最好,低開銷、行為穩定,長時間掛機不出狀況。連線丟包明顯(晚高峰跨洋)且網路不限 UDP 時,把 Hysteria2 節點設為備選,高峰時段手動切換。用戶端選 Clash Plus,分組測速與規則管理開箱即用;偏好開源桌面方案可選 Clash Verge Rev。

行動裝置(手機 / 平板)

訊號穩定環境選 Trojan / VLESS,通勤等頻繁切換網路情境優先 TUIC(連線遷移減少重新連線,0-RTT 降低切換網路後的恢復延遲)。避免長期使用 Hysteria2 掛在背景——激進傳送封包模型對電量不友善。用戶端設定比協定更重要:更新間隔、日誌等級按電量章節的建議收緊。iOS 使用者透過 App Store 取得 Clash Plus,流程見教學頁。

弱網與高丟包連線

Hysteria2 是為這個情境設計的,收益最大;頻寬參數按真實連線填寫,虛標上行只會加重丟包。若 UDP 被限速(表現為 QUIC 節點速度週期性跳水),退回 TCP 系協定,並優先選伺服器端有 BBR 壅塞控制的節點。

遊戲與即時應用

關注 UDP 轉送與延遲抖動:TUIC(native UDP 模式)與 Hysteria2 原生轉送 UDP,是第一梯隊;SS 需伺服器端開啟 UDP 支援;VMess / Trojan 的 UDP 能力取決於伺服器端實作,普遍不如 QUIC 系。選型前先確認遊戲用 UDP 還是 TCP,回合制與網頁遊戲走 TCP,協定差異不大。

伺服器與路由器

裸跑 mihomo 核心,協定選 SS(資源佔用最低)或 Trojan;MIPS / ARMv7 等低規格裝置避免 QUIC 系協定的使用者態協定堆疊開銷。核心各架構包在下載頁核心區,以命令列方式執行:

mihomo -d /etc/mihomo    # 指定設定目錄啟動

決策速查

誤區一:某某協定「最快」,全情境通用。不存在。速度由連線品質、伺服器負載、壅塞控制共同決定,協定只是其中一個變數。同一協定在不同連線上排名可以完全顛倒,結論只能來自自己連線的多次實測。

誤區二:新協定一定比舊協定好。SS 誕生最早,但在低規格裝置與穩定連線上仍是開銷最低的選擇;VLESS + REALITY 組合很新,但要求核心與伺服器端版本匹配,出問題時排查難度也更高。協定是工具,匹配情境比追新重要。

誤區三:用戶端決定協定效能。GUI 用戶端只是核心的外殼,同一 mihomo 核心下,不同用戶端的協定吞吐沒有本質差異。用戶端之間的差別在互動、平台適配與設定管理能力,協定層面看核心版本即可。

誤區四:延遲測試低等於體驗好。用戶端裡的延遲數字通常是一次 HTTP 交握的 RTT,不反映吞吐、丟包與穩定性。一個延遲 80ms 但晚高峰丟包嚴重的節點,體驗不如延遲 150ms 但全天穩定的節點。

誤區五:設定報錯先怪協定。載入失敗的多數原因是 YAML 縮排錯誤、訂閱格式不符或核心版本過舊,協定本身出問題的機率排在最後。按「格式 → 核心 → 節點 → 協定」的順序排查,效率最高。

更多具體錯誤的處理方式,見說明中心的疑難排解分類;本頁出現的所有術語在名詞速查頁可逐條對照。完成選型後,回到教學頁按主線完成匯入與驗證,或直接前往下載頁取得用戶端。