協議與核心技術參考

A協議演進脈絡:三代設計思路

六種協議不是同一時期的產物,各自針對當時最突出的問題做設計。按核心思路可以分成三代,理解這個順序之後,後面所有的對比都不需要死記——每一代的優點和短板都是設計目標的直接結果。

第一代:極簡封裝

以 Shadowsocks 為代表。設計目標是「輕」:用對稱加密直接封裝 TCP 流,協議頭壓到最短,沒有交握協商、沒有連線管理、沒有額外元資料。伺服端與用戶端只需要約定四個參數(位址、埠、加密方式、密碼)就能通訊。代價是協議本身不攜帶身份體系,也沒有傳輸層偽裝能力——所有後續需求都要靠外部手段補齊。

第二代:協議內元資料

以 Vmess 為代表。它在協議內部引入了使用者 ID(UUID)、時間戳驗證、指令欄位等結構化元資料,並把「承載方式」抽象成可替換的傳輸層:同一個 Vmess 節點可以跑在裸 TCP、WebSocket、HTTP/2 或 gRPC 之上,再按需疊加 TLS。靈活性大幅提升,設定項也隨之膨脹——一個 Vmess 節點的可配參數是 Shadowsocks 的數倍,排錯難度同步上升。

第三代:借殼與換底

第三代分成兩條路線。一條是「借殼」:Trojan 與 VLESS 不再自己發明加密封裝,而是直接把資料放進標準 TLS 連線裡,讓代理流量在外觀上與一般 HTTPS 存取一致,同時省掉一層冗餘加密。另一條是「換底」:Hysteria2 與 TUIC 放棄 TCP,基於 QUIC(UDP)重建傳輸層,主攻高延遲、高丟包連線上的吞吐量與交握速度。兩條路線解決的問題不同,不存在替代關係。

一句話總結:沒有全能協議,只有目標不同的取捨。第一代贏在簡單省資源,第二代贏在靈活,第三代借殼路線贏在流量特徵乾淨,換底路線贏在弱網表現。選型就是把你的使用場景對準其中一個目標。

B六種協議逐項拆解

本章按協議逐個說明設計要點、關鍵參數與適用邊界。所有參數名以 Clash 系列設定檔(YAML)中的欄位為準,範例值均為佔位,不可直接連線。

Shadowsocks(SS)

最精簡的一種。現行實作統一使用 AEAD 加密套件(常見為 aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305),同時保證機密性與完整性驗證。參數只有伺服器位址、埠、加密方式、密碼四項,幾乎不存在設定出錯的空間。CPU 與記憶體開銷在六種協議中最低,老舊裝置與嵌入式環境友善。短板同樣明確:流量雖然加密,但不做任何協議偽裝;協議本身也不含多路複用,每個連線獨立建立。設定片段如下:

proxies:
  - name: "ss-example"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

Vmess

V2Ray 生態的核心協議。身份驗證基於 UUID,早期版本還要求用戶端與伺服端時間偏差不超過約 90 秒,時間不同步是 Vmess 節點連不上的經典原因之一;alterId 是舊版遺留欄位,現行 AEAD 驗證方式下應設為 0。Vmess 的真正價值在傳輸層組合:network 欄位可選 tcp / ws / h2 / grpc,再透過 tls: true 疊加外層加密。其中 WebSocket + TLS 是使用最廣的組合,因為它可以掛在標準 Web 伺服器後面複用 443 埠。參數多意味著排錯點多:路徑(ws-opts.path)、Host 標頭、SNI 任何一項與伺服端不一致都會導致交握失敗。

Trojan

「借殼」路線的直接體現。Trojan 不發明自己的加密,整個連線就是一條真實的 TLS 連線,伺服端持有有效憑證,驗證只靠一個密碼雜湊。未通過驗證的存取會被回落(fallback)到一個真實網站,因此從外部觀測,Trojan 伺服端與一般 HTTPS 站台行為一致。用戶端參數極少:位址、埠、密碼、SNI。需要注意 skip-cert-verify 欄位——它會跳過憑證驗證,僅用於自簽憑證的測試環境。

VLESS

可以理解為「去掉內層加密的 Vmess」:既然外層已經有 TLS,協議內部就不再重複加密,只保留 UUID 驗證與極簡協議頭,省掉一輪加解密的 CPU 開銷。VLESS 必須與 TLS 類傳輸配合使用,不能裸跑。其 flow 欄位(如 xtls-rprx-vision)進一步最佳化了 TLS 套 TLS 場景下的冗餘加密問題,是目前低開銷方向上的主流方案之一。關鍵限制:VLESS 不在原版 Clash 核心的支援範圍內,只有 mihomo(Clash Meta)系列核心可以解析,詳見E 章。

Hysteria2

「換底」路線代表。基於 QUIC 建構,驗證只需一個密碼,設定複雜度接近 Shadowsocks。它的核心差異在壅塞控制:不依賴傳統 TCP 的丟包退讓策略,而是按照設定或偵測得到的頻寬持續傳送,在高丟包、高延遲連線上能維持遠高於 TCP 系列協議的實際吞吐量。代價是對連線頻寬的占用較為激進,且部分網路環境對 UDP 流量有限速或丟棄策略,遇到這類網路時表現會明顯劣化。設定片段:

proxies:
  - name: "hy2-example"
    type: hysteria2
    server: node.example.com
    port: 443
    password: "your-password"
    sni: node.example.com

TUIC

同樣基於 QUIC,但設計目標偏向「低延遲」而不是「高吞吐量」。TUIC 利用 QUIC 的 0-RTT 能力,重複連線可以在第一個資料封包就攜帶請求,交握延遲接近零;對 UDP 流量提供原生轉發模式(udp-relay-mode: native),適合遊戲、即時語音這類對延遲抖動敏感的應用。與 Hysteria2 一樣依賴 UDP 通道,在限制 UDP 的網路裡同樣受影響。支援範圍也限於 mihomo 系列核心。

快速識別訂閱裡的協議

拿到一份 YAML 訂閱後,用文字編輯器搜尋 type: 欄位就能清點其中包含的協議類型:ss、vmess、trojan、vless、hysteria2、tuic 分別對應本章的六種協議。分享連結形態的訂閱則看 URI 前綴,例如 ss:// 開頭是 Shadowsocks,vmess:// 開頭是 Vmess。清點結果直接決定用戶端核心的最低要求:只要出現後三種中的任意一種,就必須使用 mihomo 系列用戶端載入。這個兩分鐘的檢查動作,可以在匯入之前就避開絕大多數「節點消失」「解析失敗」類問題,也能幫你判斷服務商提供的入口類型是否覆蓋了你的使用情境。

C連線速度與吞吐量對比

「哪個協議快」要拆成三個獨立指標看:交握延遲(建立新連線要幾個來回)、穩定吞吐量(頻寬能跑多滿)、弱網退化(丟包時掉多少)。三個指標的排名並不一致。

交握延遲

TCP 系列協議(SS、Vmess、Trojan、VLESS)建立新連線至少需要一次 TCP 交握;疊加 TLS 1.3 後再加一個往返,合計約 2 個 RTT。QUIC 系列協議(Hysteria2、TUIC)把傳輸交握與加密交握合併,首次連線約 1 個 RTT,複用連線時 TUIC 可做到 0-RTT。對網頁瀏覽這種「大量短連線」的負載,交握差異直接體現在頁面首位元組時間上。

穩定吞吐量

連線品質良好時,六種協議的吞吐量差距很小,瓶頸通常在節點頻寬而非協議本身。協議端的可感差異有兩處:一是加密開銷——支援硬體 AES 指令的裝置上 aes-*-gcm 幾乎免費,VLESS 的 vision 流控還能省掉冗餘加密;二是隊首阻塞——在 TCP 上做多路複用時,一個丟包會阻塞同連線內的全部串流,QUIC 的串流之間相互獨立,不存在這個問題。

弱網退化

高丟包環境是 QUIC 系列協議的主場。TCP 的壅塞控制把丟包解讀為壅塞並大幅降速,跨海高延遲連線上尤其明顯;Hysteria2 的頻寬驅動策略在同等丟包率下能維持成倍的有效吞吐量。反過來,在 UDP 被限速的網路裡,TCP 系列協議反而更穩。

補充一點:用戶端節點列表裡的「延遲」數字是對測速位址發起一次 HTTP 請求的總耗時,反映的是目前連線狀態,不是協議優劣。同一節點不同時段測出的延遲波動,與協議類型基本無關。延遲數字異常時的排查思路見部落格《Clash 節點逾時無法連線的排查順序》。

自行驗證的簡單方法

對比協議表現不必依賴他人的評測結論,自己動手更可靠:在同一個落地節點、同一時段分別切換不同協議入口,先用用戶端內建的延遲測試記錄交握耗時,再開啟同一個測速網站記錄下行頻寬,最後在晚間高峰時段重複一輪,把三組資料放在一起,就能看出你所在連線上各協議的真實差距。測試時注意每次只改變「協議」這一個變數,不要同時更換節點、執行模式或分流規則,否則結果之間沒有可比性;每組至少測三次取中位數,排除偶發抖動的干擾。

D資源占用與行動裝置電量表現

桌面裝置上六種協議的資源差異幾乎無感,但在手機上,協議與執行模式的選擇會直接反映在電量統計裡。影響電量的因素按權重排序:執行模式 > 保活策略 > 加密開銷。

CPU 與加密開銷

現代手機 SoC 普遍帶 AES 硬體指令,aes-128-gcm / aes-256-gcm 的加解密成本極低;chacha20-ietf-poly1305 面向無 AES 指令的老裝置設計,新裝置上反而略慢。VLESS 因為去掉了內層加密,單位流量的 CPU 消耗是六者中最低的。QUIC 系列協議的協議堆疊執行在使用者態,大流量場景(長時間高畫質影片、大檔案傳輸)下 CPU 占用會明顯高於 TCP 系列,這部分開銷在手機上會轉化為發熱與耗電。

連線保活與背景行為

行動網路下,長連線需要週期性心跳維持 NAT 映射,每次心跳都會短暫喚醒基頻。TCP 系列協議依賴系統協議堆疊保活,行為較為節制;QUIC 連線的保活由應用層負責,不同實作的心跳間隔差異較大。日常放在背景、流量以即時訊息為主的場景,SS / Trojan 這類「安靜」的協議電量表現通常更好;Hysteria2 / TUIC 更適合前景重度使用時段。

執行模式的影響

比協議選擇影響更大的是執行模式:系統代理模式只處理走代理設定的應用程式流量;TUN 模式接管全部系統流量,所有資料封包都經過用戶端行程,常駐 CPU 占用與記憶體占用都更高。iOS 平台還有額外限制——網路擴充行程有嚴格的記憶體上限,規則集與訂閱體積過大時可能觸發擴充行程重啟。行動裝置如果不需要接管特定應用程式,優先使用系統代理模式即可。

E核心家族:原版、Premium 與 mihomo

「Clash」這個詞實際指向一個核心家族,不同用戶端內建的核心不同,直接決定了它能識別哪些協議。選用戶端之前先分清核心,能避開大量「訂閱匯入後節點消失」的問題。

三條分支的關係

原版 Clash 核心是這一切的起點:以 Go 語言撰寫、開源,確立了 YAML 設定格式、策略群組與規則分流的基本模型,支援 SS、Vmess、Trojan 等當時的主流協議,目前儲存庫已經封存,不再更新。Premium 是原作者在原版基礎上發布的閉源建置,主要補充了 TUN 模式與更強的規則能力,同樣已停止演進。Clash Meta 是社群在原版封存前後接續維護的分支,後更名為 mihomo——它是目前唯一持續活躍的分支,新增協議支援全部發生在這條線上。

功能差異對照

用戶端與核心的對應

用戶端是核心外面的圖形介面外殼,核心決定協議能力,外殼決定操作體驗。目前活躍的用戶端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——均基於 mihomo 核心,六種協議全部可用;而 Clash for Windows、ClashX Meta 等已停止維護的用戶端停留在舊核心或舊版本上,不建議用於包含新協議的訂閱。各用戶端的詳細取捨見橫向評測,安裝包統一從用戶端下載頁取得。mihomo 與原版核心的完整差異分析,可讀部落格《mihomo 核心與原版 Clash 核心差異詳解》。

F設定與訂閱格式相容性

協議與核心的選擇最終都落到一個問題上:手裡這份訂閱,在這個用戶端裡能不能完整載入。本章說明訂閱的常見形態與跨核心遷移時的相容要點。

訂閱的三種形態

一是 Clash YAML 訂閱:一份完整設定檔,包含 proxies、proxy-groups、rules 三大段,Clash 系列用戶端可直接匯入,這是最推薦的形態。二是分享連結集合:以 ss://、vmess:// 等 URI 組成的 Base64 文字,面向多種用戶端通用,Clash 系列用戶端匯入時由用戶端或轉換服務翻譯成 YAML。三是多格式端點:同一訂閱位址根據請求方的 User-Agent 回傳不同格式,服務商端較常見。無論哪種形態,匯入步驟見教學頁第一步。

跨核心遷移要點

從舊核心遷到 mihomo,絕大多數欄位原樣相容,YAML 不需要重寫。反方向則不成立:設定裡只要包含舊核心不認識的 type(如 vless、hysteria2、tuic),舊核心會在解析階段報錯,整份設定載入失敗,表現為「訂閱更新後所有節點消失」。這也是從 Clash for Windows 遷移到現役用戶端的最常見動因之一。若訂閱透過 proxy-providers 參照外部節點列表,同樣遵循這個規則:

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

常見載入失敗原因

訂閱拉取正常但節點異常時,按順序檢查三點:第一,用戶端核心是否支援訂閱內全部協議類型(用文字編輯器開啟訂閱,搜尋 type: 欄位核對);第二,YAML 縮排是否被二次編輯破壞——YAML 對縮排敏感,多一個空格即解析失敗;第三,proxy-groups 參照的節點名是否與 proxies 內的 name 完全一致,包含空格與表情符號在內。訂閱本身拉取失敗(逾時、403 等)的處理見常見問題的故障排查分類。

G按使用場景的協議選型建議

前面幾章的結論在這裡收攏成可直接執行的選型表。前提是訂閱裡同一落地提供多種協議入口——多數服務商如此;若訂閱只有單一協議,本章可作為與服務商溝通或更換套餐的參考。

日常網頁瀏覽與辦公

負載特徵是大量短連線、單連線資料量小。Trojan 或 VLESS 是均衡選擇:交握開銷可接受、流量特徵乾淨、CPU 占用低。SS 同樣完全夠用,且參數最少、最不容易配錯。這個場景下協議差異的體感接近於零,不必糾結。

高畫質串流與大檔案

負載特徵是長連線、高持續吞吐量。連線品質好時任何協議都能跑滿;跨海高延遲或晚間高峰丟包明顯時,Hysteria2 的優勢最大,同等連線下有效吞吐量通常顯著高於 TCP 系列協議。注意確認所在網路未對 UDP 限速,否則退回 Trojan / VLESS。

行動網路通勤

行動網路訊號波動大、基地台切換頻繁,連線重建是常態。QUIC 系列協議的連線遷移與低交握成本在這裡價值最大:TUIC 的 0-RTT 讓斷網恢復幾乎無感。若以省電為優先,參考D 章的結論,待機時段用 SS / Trojan,重度使用時段再切換。

遊戲與即時會議

核心指標是延遲抖動而非頻寬,且流量以 UDP 為主。TUIC 的原生 UDP 轉發是首選;Hysteria2 次之。TCP 系列協議轉發 UDP 需要額外封裝,抖動表現普遍更差。用戶端建議配合 TUN 模式,確保遊戲行程的 UDP 流量被接管。

伺服器與路由器常駐

無介面環境直接執行 mihomo 核心,協議選擇以穩定優先:SS 或 Trojan 的長期穩定性與低資源占用最適合 7×24 常駐;核心安裝包見下載頁的核心區。軟路由等 ARM 裝置注意選擇對應架構的建置版本。

H常見誤區與排錯入口

誤區一:協議越新越快

協議決定的是特定條件下的行為差異,不是絕對速度。連線品質好時六種協議吞吐量幾乎一致;Hysteria2 在優質連線上不會比 SS 快,在 UDP 受限的網路裡反而更慢。先確認瓶頸在哪(節點頻寬、本地網路、還是協議與網路的匹配度),再談換協議。

誤區二:延遲數字低等於體驗好

節點列表的延遲測的是一次 HTTP 往返,與持續吞吐量、丟包率沒有直接關係。50ms 但晚間高峰丟包嚴重的節點,實際體驗可能遠差於 180ms 但連線乾淨的節點。判斷節點品質應結合實際使用中的載入速度與穩定性,而不是只看測速數字。

誤區三:全域模式更穩

全域模式只是把所有流量都送進代理,不解決任何連線層問題,反而會讓本應直連的流量繞路,放大節點故障的影響面。規則模式配合合理的分流規則才是常態用法,全域模式適合臨時排查「是不是規則沒命中」這一類問題。

誤區四:加密層數越多越安全

VLESS 去掉內層加密不是削弱安全性——外層 TLS 1.3 已經提供完整的機密性與完整性保障,疊加第二層對稱加密只增加 CPU 開銷,不增加防護。安全性的關鍵在憑證驗證是否開啟、密碼強度是否足夠,而不在加密層數。

誤區五:換協議能解決一切連線問題

協議只是連線鏈路中的一環。訂閱過期、本機防火牆攔截、系統時間偏差、DNS 解析被污染、節點伺服器端故障,這些問題換任何協議都不會消失。正確的排查順序是先確認訂閱有效、再確認本機網路與系統設定正常、最後才考慮協議與網路環境的匹配問題。把「換協議」當成第一反應,往往只是把真正的故障原因往後拖。遇到連不上的情況,建議按固定順序逐層排除:先看用戶端日誌有沒有明確報錯,再用瀏覽器直接存取測速位址驗證直連是否正常,最後切換節點與協議做交叉對比,定位問題出在本機、鏈路還是伺服器端。

排錯入口索引

• 訂閱更新失敗、開機自動啟動、模式切換等高頻問題:常見問題按分類整理了標準處理步驟。
• 節點全部逾時或部分逾時:按部落格《節點逾時無法連線的排查順序》給出的固定順序逐層檢查。
• 看不懂用戶端日誌裡的錯誤:參考《Clash 執行日誌怎麼看》逐條對照錯誤含義。
• 正文出現的名詞(AEAD、SNI、RTT、TUN 等)釋義:查術語手冊對應分類。