▶協議詳解:六種協議與三代核心的選型參考

協議全景:六種主流協議從哪來、解決什麼問題

先記住一條主線:代理協議的演進史,就是一部「在加密、偽裝、速度三者之間反覆找平衡」的歷史。用戶端訂閱裡常見的六種協議——Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC——分屬三個世代,每一代都是對上一代短板的直接回應。搞清楚各自的出發點,後面所有對照表都能讀得順。

Shadowsocks:輕量加密的起點

Shadowsocks(常縮寫為 SS)是六者中資歷最老的一個。設計目標只有一句話:用盡量少的開銷給 TCP 流量套一層對稱加密。它沒有交握協商、沒有連線階段概念,用戶端和伺服端事先約定同一個密碼與加密方法,連線建立後直接傳密文。好處立竿見影:實作極簡、CPU 佔用低、幾乎所有平台都有成熟實作;代價同樣明顯——流量特徵相對固定,缺乏元資料層面的偽裝能力。後續社群給它補上了 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),把早期流加密的完整性缺陷修掉了,這也是今天設定裡建議只用 AEAD 方法的原因。

VMess 與 VLESS:帶連線階段層的兩代協議

VMess 出自 V2Ray 專案,思路比 SS 更進一步:引入使用者 ID(UUID)、時間戳驗證與動態元資料,每條連線的標頭都不一樣,並支援掛載 WebSocket、gRPC 等多種傳輸層。靈活是它的最大賣點,複雜也是它的最大負擔——協議標頭計算量偏大,時間戳機制還要求用戶端與伺服端時鐘偏差不能太大,手機時間不準就連不上是 VMess 的經典故障。VLESS 是同一個社群對 VMess 的「減負版」:砍掉內建加密與時間戳驗證,把加密職責整體外包給底層 TLS,協議本體只保留身份標識與路由資訊。結果是標頭更小、轉發更快,但它必須搭配 TLS(或 REALITY 這類衍生方案)使用,裸奔的 VLESS 沒有任何保密性。

Trojan:把自己藏進 HTTPS 的人流裡

Trojan 換了個思考方向:與其發明新的加密格式,不如讓代理流量在外觀上與一般 HTTPS 完全一致。它直接複用標準 TLS 交握,伺服端配真實憑證,驗證失敗的存取會被回落到一個普通網站。對觀察者而言,一條 Trojan 連線和一次正常的網頁瀏覽沒有可辨識的差別。設計取捨也隨之而來:必須有網域和有效憑證,部署門檻比 SS 高;所有流量都過一層完整 TLS,單核加解密吞吐會略低於輕量協議,但換來了最穩的「融入背景」能力。

Hysteria2 與 TUIC:QUIC 世代的提速派

前四種協議都跑在 TCP 上,受制於 TCP 的壅塞控制與隊頭阻塞:丟一個封包,整條連線都要等重傳。Hysteria2 與 TUIC 把底座換成了基於 UDP 的 QUIC。Hysteria2 的核心是自帶激進的壅塞控制策略,專門面向高遺失率、高延遲的長距離線路,弱網環境下的吞吐提升非常直觀;TUIC 則更「標準派」,盡量貼著 QUIC 規範做多工與 0-RTT 快速交握,追求低延遲的同時保持協議行為溫和。兩者共同的軟肋:部分網路對 UDP 有限速或攔截策略,遇到這種環境,QUIC 系協議反而不如老實的 TCP 系穩定,所以它們是「備選加速檔」而不是無腦預設項。

傳輸層設計取捨:TCP、TLS 與 QUIC 三條路線

協議比較經常被簡化成「哪個快」,但決定體驗的第一變數其實是傳輸層路線。把六種協議按底座分成三派,很多現象會瞬間說得通。

TCP 直連派:SS 與輕裝 VMess

SS 與不掛 TLS 的 VMess 直接在 TCP 上傳輸自訂密文。優點:相容性最好,任何允許 TCP 的網路都能跑;實作輕,舊裝置、路由器都帶得動。缺點:自訂密文本身就是一種特徵,且 TCP 隊頭阻塞在遺失封包的線路上會顯著拖慢體感速度——延遲數字可能不難看,但網頁載入會一頓一頓,這正是延遲測試數字怎麼看一文裡拆解過的「數字好看體驗差」的典型來源之一。

TLS 封裝派:Trojan、VLESS 與掛 WS 的 VMess

這一派把流量放進標準 TLS 連線階段。外觀與一般 HTTPS 一致,穿透各類中間裝置的成功率最高;配合 CDN 轉送(常見於 VMess/VLESS + WebSocket 組合)還能隱藏伺服器真實位址。代價是交握輪次多:TCP 三向交握加 TLS 交握,首包延遲天然比直連派高一截;每字節都要過一次 TLS 加解密,吞吐上限受 CPU 單核效能影響明顯。

QUIC 派:Hysteria2 與 TUIC

QUIC 把加密交握與傳輸交握合併,理想情況下一個往返即可建立連線,支援 0-RTT 時甚至更快;流級多工徹底繞開隊頭阻塞,單條遺失封包只影響單條流。行動網路切換(Wi-Fi 換 5G)時,QUIC 的連線遷移能力也讓重新連線更平順。短板前文說過:UDP 在部分網路裡是「二等公民」,被限速時表現會斷崖式下滑。

連線速度與資源佔用:數字背後的規律

先給結論:同一台伺服器、同一條線路下,六種協議的「極限頻寬」差距通常小於線路本身波動;真正拉開體感差距的是首包延遲、遺失封包復原與 CPU 瓶頸三件事。逐項看。

首包延遲:交握輪次決定下限

打開一個新網站,用戶端要先與代理伺服器建立連線。SS 只需 TCP 三向交握即可傳送資料,輪次最少;Trojan/VLESS 要在 TCP 之上再完成 TLS 交握,多出一至兩個往返;Hysteria2/TUIC 靠 QUIC 把兩步合一,長距離線路上優勢明顯,TUIC 的 0-RTT 在重複存取同一伺服器時可以做到「發出即帶資料」。線路延遲 50ms 時這些差距感知不強;延遲 200ms 以上時,每省一個往返都是肉眼可見的提速。

吞吐與 CPU:加密路徑的帳

滿速下載時,瓶頸常常不是線路而是加解密。SS 配 AEAD 套件的單位字節開銷最低,老舊路由器也能接近線速;Trojan/VLESS 的 TLS 路徑在支援 AES-NI 指令集的現代 CPU 上開銷可控,但在低階 ARM 裝置上會先於頻寬到頂;QUIC 系協議目前多在使用者態實作,同吞吐下 CPU 佔用普遍高於核心態最佳化成熟的 TCP 堆疊,這是「Hysteria2 跑分快但風扇也快」的原因。桌面平台一般無感,軟路由和電視盒子上要認真對待。

遺失封包復原:弱網下的分水嶺

丟包率超過 1% 的線路上,TCP 系協議的吞吐會被壅塞演算法壓得很低,而且所有多工同一條連線的請求一起卡住;Hysteria2 的激進補償策略在這種環境下常能把可用頻寬拉回數倍,TUIC 的流隔離也能保證「一個請求卡住不連累其他」。反過來,在低丟包的優質線路上,三派的實際速度差可以忽略,此時選協議應該看偽裝與相容性而非跑分。

行動端電量表現:協議如何影響續航

手機上掛用戶端整夜掉電,協議選擇是變數之一,但通常不是最大的那一個。這一章把「協議相關」的耗電因素單獨拉出來講清楚,系統層面的排查(省電白名單、背景策略、探測間隔)參見部落格的Android 耗電排查清單。

無線電喚醒:小封包頻率是隱形大戶

行動晶片的基頻有「睡眠—喚醒」狀態機,每次收發資料都可能把基頻從低功耗態拉起來,拉起來之後還要保持一段高功耗駐留。因此耗電與流量總量關係不大,與「多久來一個封包」關係極大。協議或其上層實作的心跳、保活、探測越頻繁,基頻越難睡,整夜待機掉電就越多。

三派協議的耗電畫像

TCP 系協議自身沒有強制心跳,連線靜默時幾乎不產生額外喚醒,待機友善;需要注意的是掛 WebSocket 的 VMess/VLESS,部分伺服端會設定週期性 ping 訊框,間隔過短就是標準的「電量刺客」。QUIC 系協議為了維持 NAT 映射與連線遷移能力,通常帶有內建的保活探測,靜默狀態下的喚醒次數天然多於 TCP 系;換來的好處是網路切換時不必推倒重新連線——頻繁在 Wi-Fi 與行動網路之間切換的通勤情境裡,一次完整重新連線(重新交握、重新探測節點)的耗電可能比多幾次保活更高。所以結論不是一邊倒:重度行動切換的使用者選 QUIC 系反而可能更省電,長時間駐留單一網路的使用者選 TCP 系更穩。

可操作的省電原則

• 待機為主的裝置:優先 SS 或 Trojan,避開心跳間隔激進的 WebSocket 設定。
• 通勤高頻切網:可試 TUIC 或 Hysteria2,利用連線遷移減少重新交握。
• 無論哪種協議:把策略群組的自動測速間隔調大到十分鐘以上,探測本身也是喚醒源。
• TUN 模式常駐會接管全域流量,耗電高於僅代理部分應用程式屬正常現象,按需開啟。

核心家族:原版、Meta 與 mihomo 是什麼關係

先把一句話釘死:這三個名字不是三個競爭產品,而是同一條演進線上的三個階段。理清家族關係,用戶端選擇與設定相容性問題會少一大半。更完整的時間線梳理見部落格的核心差異對照一文。

原版核心:規則分流範式的奠基者

最初的 Clash 核心確立了今天所有衍生品沿用的骨架:YAML 設定、proxies 節點清單、proxy-groups 策略群組、rules 規則段,以及「按網域與 IP 規則決定流量去向」的分流範式。它原生支援 SS、VMess、Trojan 等當時的主流協議,但對後來出現的 VLESS、Hysteria2、TUIC 沒有支援。原始儲存庫已經停止更新,原版核心如今屬於「歷史階段」,不建議新使用者再圍繞它搭建環境。

Meta 分支:社群接棒的功能擴展版

原版活躍期間,社群維護的 Clash.Meta 分支就在並行推進:補齊新協議支援(VLESS、Hysteria 系、TUIC)、增強 TUN 模式、擴展 DNS 與嗅探能力、引入 sub-rules 等更靈活的規則寫法。它保持對原版設定的向下相容——舊設定檔基本可以直接餵給 Meta 核心執行,反過來則不行:用了 Meta 擴展欄位的設定在原版核心上會回報「unsupported」類錯誤。

mihomo:同一核心的現用名

原版儲存庫封存後,Meta 分支改名為 mihomo 並延續開發至今。**mihomo 就是 Clash.Meta 的現用名,二者是同一個專案**,設定格式、命令列行為、API 全部延續。今天主流用戶端——下載頁首推的 Clash Plus,以及 Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等——底層核心均為 mihomo 或其衍生。選用戶端時看到「基於 mihomo/Meta 核心」字樣,即代表六種協議與 TUN、嗅探等能力都在支援範圍內。

設定欄位與核心相容性:哪些寫法只有新核心認

拿到訂閱或手寫設定時,最常見的翻車點是「欄位與核心不匹配」。這一章按欄位層級過一遍相容性邊界,設定檔的整體結構逐段精讀請移步設定檔結構解析。

全核心通用的骨架欄位

port、socks-port、mixed-port、allow-lan、mode、log-level、external-controller 這些頂層欄位從原版時代沿用至今,任何核心都認。proxies 裡 SS、VMess、Trojan 三類節點的基礎寫法同樣通用。只用這些欄位的設定,拿到任何用戶端都能跑。

僅 Meta/mihomo 支援的擴展欄位

以下寫法出現任意一個,設定就只能在 Meta/mihomo 系核心上執行:type 為 vless、hysteria2、tuic 的節點;tun 段的完整設定(含 stack、auto-route、dns-hijack);sniffer 嗅探段;GEOSITE 類規則與部分擴展規則類型;proxy-providers 與 rule-providers 的增強參數。一個最小的 Hysteria2 節點範例:

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

對照一個全核心通用的 Shadowsocks 節點,可以看到擴展協議只是多了幾個欄位,骨架完全一致:

proxies:
  - name: "示例-SS"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"

相容性排錯的三步法

1. 確認核心:打開用戶端設定頁查看核心標識,寫著 mihomo 或 Meta 即為新核心。會看到版本號旁通常帶核心名。
2. 看錯誤關鍵字:日誌裡出現 unsupported type 或 unknown field,基本可以斷定是舊核心遇到了新欄位。
3. 就高不就低:把用戶端換成基於 mihomo 核心的版本(下載頁所有在維護的用戶端均滿足),而不是反過來刪設定欄位遷就舊核心。

訂閱格式相容性:換用戶端時會發生什麼

訂閱是「一條 URL 換回一整份節點設定」的機制,但不同生態的訂閱格式並不通用。搞清楚三種常見形態,換用戶端、換平台時就不會一臉問號。

Clash YAML 訂閱:本生態的原生格式

訂閱連結回傳一份完整的 YAML 設定(或至少包含 proxies 段),用戶端拉取後直接載入。這是 Clash 系用戶端的原生格式,欄位資訊最完整:節點參數、策略群組結構、規則段可以一併下發。注意點只有一個——回傳的設定裡若含 Meta 擴展欄位,舊核心用戶端會載入失敗,錯誤表現參見上一章。

分享連結與 Base64 聚合:跨生態的最大公約數

ss://、vmess://、trojan:// 開頭的單節點分享連結,以及把一堆連結 Base64 打包的聚合訂閱,是跨用戶端生態的通用交換格式。它只描述節點本身,不含策略群組與規則。mihomo 系用戶端大多能直接識別這類訂閱並自動套一份預設策略群組;反向相容則看目標用戶端——部分協議(尤其 Hysteria2、TUIC)的分享連結格式各家實作細節不同,跨生態匯入偶發參數丟失屬常見現象。

訂閱轉換:方便,但要知道會丟什麼

訂閱轉換服務能把一種格式翻譯成另一種,常用於「機場只給通用訂閱、用戶端想要完整 YAML」的情境。三點務必清楚:一,轉換按範本產生策略群組與規則,原訂閱裡沒有的分流邏輯是範本加的,不代表服務商意圖;二,冷門協議參數(如 Hysteria2 的頻寬提示欄位)可能在轉換中被靜默丟棄,連不上時優先懷疑這裡;三,訂閱連結含身份憑證,提交給公共轉換服務等於交出節點資訊,自建或使用用戶端內建的本地轉換更穩妥。更多訂閱相關問答見說明中心。

按使用情境選型:直接抄答案

前面所有鋪墊收束到這一章。找到自己的情境,按建議順序在用戶端裡試,第一個連通且穩定的就是目前環境的正確答案。

桌面日常:網頁、辦公、開發

做什麼:優先 Trojan 或 VLESS + TLS,備選 SS。桌面 CPU 效能充裕,TLS 開銷無感,偽裝能力優先。會看到:延遲穩定、長時間掛機不斷線。搭配 Windows 或 macOS 平台的 Clash Plus,規則分流按入門指南的預設設定即可。

行動端:通勤與戶外

做什麼:頻繁切網選 TUIC 或 Hysteria2,吃 QUIC 的連線遷移;駐留單一網路、重視續航選 SS 或 Trojan。會看到:切網後恢復更快,或整夜待機掉電收斂。配合上文電量章節的探測間隔設定一起調。

弱網與長距離線路:高丟包、高延遲

做什麼:首選 Hysteria2,次選 TUIC。會看到:同一條爛線路上吞吐明顯回升,影片拖動不再轉圈。若所在網路對 UDP 限速(表現為 QUIC 節點全部逾時或速度驟降),回退 Trojan。

路由器與常駐伺服器

做什麼:優先 SS(AEAD),CPU 開銷最低;裝置效能充裕再考慮 Trojan。核心直接跑 mihomo 命令列版,下載頁核心區提供各架構包。會看到:低階 ARM 裝置也能貼近線速轉發。QUIC 系協議在軟路由上 CPU 佔用偏高,謹慎常駐。

一套訂閱多協議並存:建議姿勢

多數服務商同一節點會提供多種協議入口。建議做法:在策略群組裡把不同協議的同地區節點放進同一組,手動切換比較幾天;用戶端選基於 mihomo 核心的版本,保證六種協議全部可用,不用遷就協議做用戶端選擇。

實測自查:用四組對照實驗取代猜測

協議選型最忌諱的是憑感覺。前面所有表格給的是規律,而你手上的線路、電信業者、裝置效能是獨一份的組合,結論必須靠自己跑一遍才算成立。好消息是不需要專業工具,用戶端自帶的面板加瀏覽器就夠,下面四組對照實驗各花五到十分鐘,做完你會拿到一張屬於自己網路環境的協議排序表。

實驗一:同節點換協議,比首包回應

做什麼:在同一服務商的同一地區裡,挑出協議不同但落地相同的幾個節點,依次設為目前出口,每次開啟一個此前沒造訪過的網頁,記錄從按下 Enter 到首屏出現文字的主觀耗時,重複三輪取中間值。為什麼這樣測:首包體感由交握輪次決定,而交握輪次正是三派協議的結構性差異,單看用戶端的延遲數字反映不出來。會看到:優質線路上幾種協議差距在半秒以內,可視為等價;長距離線路上 QUIC 系通常明顯領先,TLS 系落後半拍到一拍。如果結果與規律相反,大概率是所在網路對 UDP 做了限速,直接把 QUIC 系從候選裡劃掉。

實驗二:大檔案下載,比吞吐與 CPU

做什麼:找一個穩定的大檔案來源,分別用不同協議下載同一份檔案兩分鐘,記錄用戶端顯示的平均速度,同時開啟系統的工作管理員或活動監視器,盯住用戶端行程的 CPU 佔用峰值。為什麼這樣測:吞吐上限往往不由線路決定而由加解密路徑決定,只看速度會漏掉「速度達標但裝置發燙」的隱性代價。會看到:桌面機上幾種協議速度接近而 QUIC 系 CPU 偏高;低階 ARM 裝置(軟路由、盒子)上則可能出現 SS 跑滿頻寬、其他協議先到 CPU 天花板的分化。這一組結果直接決定路由器該選什麼協議常駐。

實驗三:弱網重現,比遺失封包復原

做什麼:製造一個可控的差線路——用手機熱點並把訊號拉到只剩一兩格,或選一個已知擁塞時段的遠距離節點,然後播放一段線上影片並反覆拖動進度條,觀察卡頓與重新緩衝的頻率。為什麼這樣測:遺失封包復原能力是 Hysteria2 存在的理由,而它只在壞線路上才顯現,好線路上做這項比較等於白做。會看到:TCP 系在拖動後要等更久才恢復流暢,Hysteria2 復原最快,TUIC 居中且更平穩。若你的日常網路本來就乾淨穩定,這一組差異可以忽略,不必為它犧牲相容性。

實驗四:整夜待機,比電量與斷線

做什麼:手機充滿電後開著用戶端過夜,不主動使用,早上記錄電量下降百分比與用戶端連線是否還活著,換協議再來一晚,盡量保證兩晚的網路環境一致。為什麼這樣測:耗電與保活策略、基頻喚醒頻率相關,短時間觀察完全測不出來,只有跨夜資料有意義。會看到:靜默的 TCP 系掉電最少;帶保活的 QUIC 系與配了短心跳的 WebSocket 組合掉電更多。若兩晚差距超過百分之十,說明協議或心跳設定確實是主因,再回到電量章節調整探測間隔;若差距在百分之三以內,問題不在協議,按系統層面的背景策略去查。

四組實驗做完,把結果寫成一句自己的結論,例如「我家寬頻乾淨,四種 TCP 系協議等價,優先 Trojan;出門用手機切網多,改 TUIC」。這句話比任何通用建議都準,因為它是在你的真實環境裡量出來的。日後換了服務商、換了城市、換了主力裝置,再花二十分鐘重跑一遍即可,不必推翻整套認知。

常見誤區與延伸閱讀

最後清一遍高頻誤解,每條都對應真實的求助貼模式。

誤區一:協議越新越好

不成立。Hysteria2、TUIC 是針對特定環境(弱網、切網)的特化方案,優質有線網路上相對 Trojan 沒有體感優勢,還要多付 CPU 與電量。協議選型看環境匹配度,不看發布年份。

誤區二:延遲低等於協議快

不等於。用戶端顯示的延遲只是一次探測往返,不含吞吐、遺失封包復原與交握開銷資訊。同一節點 SS 與 Trojan 的探測值幾乎一樣,弱網下實際體驗卻可能差數倍。詳細機制見延遲數字解讀。

誤區三:Meta 和 mihomo 是兩個核心,要二選一

是同一個專案的前後兩個名字。用戶端說明裡出現任一名字,能力集合都一致,不存在選擇問題。

誤區四:訂閱在 A 用戶端能用,在 B 用戶端就一定能用

取決於訂閱格式與核心版本的交集。YAML 訂閱含擴展欄位時舊核心會拒載;通用訂閱跨生態匯入可能丟參數。換用戶端後連不上,先按設定相容性一章的三步法排錯,再去說明中心的故障排查分類找對應條目。

誤區五:分流不生效是協議的鍋

大概率不是。分流由規則段與 DNS 行為決定,與節點協議無關;規則失效最常見的根因是 DNS 洩漏或 fake-ip 設定不當,排查路徑見DNS 洩漏檢測與修復。

讀完本頁,協議與核心的選型依據已經齊了。下一步:去安裝包頁按平台領取用戶端,再按入門指南把訂閱匯入、模式選擇與連線驗證走完一遍主線。