協定手冊:代理協定與內核選型技術參考

CL-01手冊定位與閱讀方法

先交代這份手冊在站內的位置。Clash資源站 的內容按館藏方式組織:下載中心負責按平台上架客戶端安裝包,教學頁負責「匯入訂閱、選擇模式、連線驗證」的上手主線,選型指南負責客戶端軟體之間的橫向對比,而本頁處理的是更底一層的問題——客戶端裡跑的協定與內核該怎麼選。多數用戶被節點列表裡的 ss、vmess、trojan、vless、hysteria2、tuic 這些類型標籤困擾過:它們看起來只是名字不同,實際上卻決定了連線建立的快慢、弱網下的表現、手機的耗電水準,以及某些節點在舊內核上根本無法載入的相容性問題。

閱讀方法上,本頁不要求從頭讀到尾。八個章節各自獨立成篇:CL-02 是六種協定的「檔案卡」,逐一交代出身與取捨;CL-03 與 CL-04 是效能維度的橫向對比,前者看速度,後者看資源與電量;CL-05 講內核家族——原版 Clash、Clash Premium、Clash Meta 與 mihomo 之間的繼承關係,這是理解「為什麼有些配置在有些客戶端裡會報錯」的關鍵;CL-06 講訂閱格式與配置欄位相容性;CL-07 把前面所有結論收攏成按情境的選型表;CL-08 收錄選型時最常見的幾個誤區。每章開頭有一段導讀,先讀導讀再決定是否深入。

兩點寫作約定需要說明。第一,本頁只做技術科普與選型參考,不討論任何網路管制相關話題,協定的對比維度限定在工程層面:握手開銷、加密成本、傳輸層特性、生態成熟度。第二,本頁不貼大段配置程式碼——協定參數動輒幾十個欄位,照抄意義不大;只在必要處給出最小範例幫助辨認欄位結構,完整的配置操作請回到教學頁按步驟執行。文中出現的伺服器位址、密碼一律為示意用的假值,不可直接使用。若某個名詞在閱讀中仍感陌生,可先在技術筆記裡檢索對應專題文章,再回到本頁繼續。

CL-02協定總覽:六種協定的誕生背景與設計取捨

協定是客戶端與伺服器之間約定的「說話方式」。六種主流協定出現的年代不同、要解決的問題不同,因此沒有絕對的優劣,只有取捨的差異。先用一張總表建立座標,再逐一展開。

Shadowsocks:極簡主義的起點

Shadowsocks 是六者中資歷最老的一個,設計哲學是「把事情做少」:客戶端與伺服器共享一個密碼,流量用對稱加密封裝後直接轉發,沒有握手協商、沒有憑證體系。現代實作統一採用 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),兼顧完整性校驗與效能。極簡帶來兩個直接好處——CPU 開銷最低、實作最容易,幾乎所有內核與客戶端都支援;代價是協定特徵長期被充分研究,單獨使用時的對抗能力有限,實務上常配合 obfs、v2ray-plugin 等外掛擴充傳輸層。作為選型基準,SS 至今仍是「老裝置、低階路由器、追求省電」情境的第一候選。

VMess:傳輸層組合的開創者

VMess 出自 V2Ray 專案,核心貢獻是把「協定本體」與「傳輸層」解耦:同一個 VMess 連線可以跑在裸 TCP、WebSocket、HTTP/2 等多種傳輸之上,再按需套一層 TLS。這種模組化設計讓它在很長一段時間裡是靈活性的代名詞。取捨在於:協定頭包含用戶 ID、加密方式聲明、時間戳校驗等欄位,每個資料包的固定開銷明顯高於 SS;時間戳校驗還要求客戶端與伺服器時鐘偏差在約九十秒以內,手機時間不準會直接導致握手失敗——這是排查 VMess 節點「莫名超時」時第一個該檢查的點。今天的 VMess 通常以 WebSocket + TLS 的組合出現,相容性極好,但效能上限不如後來者。

Trojan:把自己藏進 HTTPS 裡

Trojan 的思路與前兩者相反:不發明新的加密封裝,直接複用標準 TLS。客戶端與伺服器完成一次貨真價實的 TLS 握手,流量行為與一般 HTTPS 存取幾乎一致;驗證失敗的連線會被伺服端轉交給一個真實的網站,進一步降低可辨識度。這個設計讓 Trojan 的實作非常薄——協定本體只有一個密碼雜湊加目標位址,幾乎零額外開銷,效能貼近裸 TLS 的理論上限。門檻在伺服端:必須持有網域與有效憑證,部署比 SS 複雜;客戶端一側則需要注意 sni 欄位必須與伺服端憑證相符,設錯會報 TLS 握手錯誤。對客戶端用戶而言,Trojan 是「穩定、低開銷、行為端正」的可靠選項。

VLESS:做減法的下一代框架

VLESS 是 VMess 的精簡繼任者,出自同一生態。它把 VMess 裡被認為冗餘的部分全部刪掉:不再自帶加密(交給外層 TLS)、不再做時間戳校驗、協定頭壓縮到最小。本體變輕之後,安全性完全取決於搭配的傳輸層——常見組合是 VLESS + TLS + Vision 流控,或 VLESS + REALITY(一種無需自有憑證、借用真實網站 TLS 指紋的握手方案)。設計取捨非常清晰:用「本體零加密」換取最低的封裝開銷,再用現代傳輸層補足安全。需要注意的是 VLESS 的各種流控與傳輸組合迭代較快,舊內核往往不認識新欄位,這也是它對內核版本最敏感的原因,詳見 CL-05 與 CL-06 兩章。

Hysteria2:為爛網路而生

Hysteria2 構建在 QUIC 之上,整個協定跑在 UDP 上,加密由 TLS 1.3 完成。它的獨特之處是自帶一套激進的壅塞控制:傳統 TCP 遇到丟包會大幅退讓,導致高丟包鏈路上的實際吞吐遠低於頻寬;Hysteria2 允許按配置的頻寬持續發送,透過冗餘與快速重傳對抗丟包。工程結論很直接——在跨境長鏈路、晚高峰壅塞、無線訊號差這類「高延遲高丟包」環境下,Hysteria2 的吞吐往往顯著領先 TCP 系協定;而在本身通暢的網路裡優勢不明顯,激進發包反而可能擠占同網段其他裝置。它的硬性前提是 UDP 通道可用:部分電信業者與公共 Wi-Fi 會對 UDP 限速或攔截,此時 Hysteria2 會整體失效,選型時必須準備一個 TCP 系協定墊底。

TUIC:QUIC 生態的輕量路線

TUIC 同樣基於 QUIC,但走的是「標準化、輕量化」路線:直接複用 QUIC 的多路複用與 0-RTT 握手能力,不像 Hysteria2 那樣重寫壅塞控制,而是提供 BBR、Cubic 等標準演算法供選擇。0-RTT 意味著與曾經連線過的伺服器重新建連幾乎不消耗往返時間,對「頻繁切換網路的手機端」格外友善;QUIC 原生的 UDP 轉發能力也讓它處理遊戲、語音這類 UDP 流量更自然。短板在生態:TUIC 相對年輕,伺服端部署面與機場支援度都不如前五者,且同樣依賴 UDP 通道可用。可以把它理解為「溫和版的 QUIC 方案」——想要 QUIC 的低延遲收益、又不想要 Hysteria2 的激進風格時,TUIC 是對應答案。

CL-03連線速度與吞吐:三個決定體驗的環節

用戶口中的「這個節點快」,實際由三個環節分別決定:連線建立速度(點開一個新網站要等多久)、穩態吞吐(下載與影片能跑多滿)、並發表現(網頁幾十個請求同時發出時是否互相阻塞)。三個環節的主導因素完全不同,分開看才能得出可靠結論。

連線建立:握手往返次數是硬帳

建立一條代理連線的耗時基本等於「握手往返次數 × 鏈路延遲」。SS 沒有握手,發出第一個資料包即完成建連,是理論最快;Trojan、VLESS + TLS、VMess + TLS 都需要一次完整 TLS 握手,TLS 1.3 下為一個往返;VMess 若再疊加 WebSocket,還要多一次 HTTP Upgrade 往返,是 TCP 系裡建連最慢的組合。QUIC 陣營的 Hysteria2 與 TUIC 把傳輸握手與 TLS 握手合併進同一個往返,重複建連時更可借助 0-RTT 做到「首包即資料」。鏈路延遲越高,這筆帳越顯著:同樣的握手差距,在延遲很低的近距離鏈路上幾乎無感,在延遲明顯的遠距離鏈路上則會被放大數倍,表現為「點開新頁面前的白屏時間」差異。

穩態吞吐:壅塞控制與加密成本

連線建立之後,長時間大流量傳輸(下載、高畫質影片)的瓶頸轉移到壅塞控制與加密開銷。通暢鏈路上,六種協定的穩態吞吐差距不大,都能接近鏈路頻寬,此時反而是加密成本決定上限——SS 與 Trojan 封裝最薄,VMess 的逐包頭部開銷讓它在小包密集的情境(如大量圖片的頁面)略吃虧。一旦鏈路出現持續丟包,格局立刻改變:TCP 系協定(SS/VMess/Trojan/VLESS over TCP)受制於內核 TCP 的退讓策略,吞吐隨丟包率上升而陡降;Hysteria2 憑自訂壅塞控制在同等丟包下仍能維持接近配置頻寬的吞吐,TUIC 選用 BBR 時也明顯優於傳統 TCP。這就是「晚高峰 QUIC 系協定體感更好」的技術根源。

並發與隊頭阻塞

現代網頁動輒同時發起數十個請求。跑在單條 TCP 連線上的多路複用(如 VMess 的 mux)存在隊頭阻塞問題:一個丟包會卡住整條連線上所有請求。QUIC 在傳輸層原生解決了這一點,每個串流獨立重傳,互不拖累——Hysteria2 與 TUIC 因此在「網頁大量小請求並發」的情境下體感更流暢。TCP 系協定的應對方式是乾脆不用多路複用,讓內核為每個請求單獨建連,配合連線複用池也能取得不錯的並發表現,代價是建連開銷更頻繁。實際測試時建議區分情境:用大檔案下載測吞吐,用圖片牆類網頁測並發,用新網域首次存取測建連,單一的延遲數字(ping 值)只能反映鏈路距離,與三者都不等價——這個誤區在 CL-08 還會展開。

CL-04資源占用與行動端電量表現

桌面端用戶很少關心代理內核吃多少 CPU,手機用戶則每天都在為電量精打細算。這一章把「資源占用」拆成加密運算、協定堆疊位置、無線電喚醒三個因素,並給出行動端的實操建議。

加密運算:硬體加速是分水嶺

對稱加密是代理流量的固定成本。近十年的手機與電腦 CPU 普遍內建 AES 指令集,aes-128-gcm 這類套件的加解密幾乎不占用可感知的 CPU;沒有硬體加速的老裝置(部分低階路由器、老款電視盒子)則應選 chacha20-ietf-poly1305,它為純軟體實作優化,同等安全強度下速度可達軟體 AES 的數倍。協定層面,SS 與 Trojan 只有一層加密,運算成本最低;VMess 自帶加密再疊加外層 TLS 時存在雙重加密,是六者中單位流量 CPU 成本最高的組合;VLESS 本體不加密的設計正是為了消掉這層冗餘。在路由器上跑 mihomo 內核時,這筆帳直接決定裝置能不能跑滿頻寬。

QUIC 的用戶態成本

TCP 協定堆疊在作業系統內核裡執行,經過幾十年優化;QUIC 目前主要在用戶態實作,同等流量下 CPU 占用普遍高於 TCP 系協定,記憶體占用也略高。桌面端這點差異無關痛癢,但在手機上,持續大流量走 Hysteria2/TUIC 時的發熱與耗電會比 SS/Trojan 明顯一階。結論不是「手機別用 QUIC」,而是「QUIC 的收益要花在刀刃上」:網路差的時候它帶來的體驗提升遠超電量代價,網路好的時候則不必為用不上的抗丟包能力付電費——支援自動切換策略群組的客戶端裡,可以把 QUIC 節點與 TCP 節點混編,讓規則按需選擇。

無線電喚醒與心跳:行動端耗電的大頭

手機耗電的真正大頭往往不是運算,而是行動網路/Wi-Fi 模組被反覆從休眠中喚醒。長連線協定若維持頻繁心跳,即使每次只發幾十位元組,也會阻止無線電進入深度休眠。這方面 QUIC 系有一個常被忽略的優勢:連線遷移。手機在 Wi-Fi 與行動網路之間切換時,TCP 連線必須斷開重建(觸發一輪完整握手與流量重傳),QUIC 連線可以原地遷移到新網路繼續使用——通勤情境下頻繁的重連正是耗電與卡頓的來源之一。實操建議:行動端優先選擇Android 平台的 Clash Plus 或 FlClash 這類基於 mihomo 內核的客戶端,按需開關 TUN 模式(虛擬網卡全程接管會帶來額外的常駐開銷,原理見技術筆記中的TUN 模式詳解);策略群組的自動測速間隔不要設得過密,幾百毫秒一輪的健康檢查在手機上就是標準的電量殺手。

CL-05內核家族:原版 Clash、Meta 與 mihomo 的關係

「內核」是客戶端介面之下真正處理流量的引擎。市面上所有 Clash 系客戶端共享同一套配置語法,但引擎有代際之分——不理解這層關係,就無法解釋「同一份訂閱在 A 客戶端能用、在 B 客戶端報錯」的現象。

三代內核的繼承鏈

原版 Clash 內核確立了這套生態的全部基礎:YAML 配置、代理群組(策略群組)、基於規則的分流。它支援的協定以 SS、VMess、Trojan、Socks5、HTTP 為主。原作者隨後維護過閉源的 Premium 版本,補充了 TUN 模式與規則集(rule providers)等進階能力。在原版倉庫停止更新後,社群分支 Clash Meta 接手主線,大幅擴展協定支援並保持活躍開發;此後 Meta 專案更名為mihomo——今天說 Clash Meta 內核與 mihomo,指的是同一個專案的同一條主線。理解這條繼承鏈後,選型規則可以濃縮成一句話:配置語法向前相容,協定支援只增不減,新協定一律認準 mihomo。

功能差異對照

客戶端與內核的對應關係

客戶端只是內核的圖形外殼,選客戶端本質上是在選內核。本站下載中心上架的活躍客戶端——Clash Plus(全平台首推)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——均基於 mihomo 內核,六種協定全部可用;歸檔區的 Clash for Windows 與 ClashX Meta 已停止維護,前者搭載的原版/Premium 內核無法載入 VLESS、Hysteria2、TUIC 節點,訂閱裡含這些協定時會直接報「unsupported proxy type」或整份配置載入失敗。這正是「尋找 Clash for Windows 替代方案」成為高頻檢索詞的原因:不是舊軟體壞了,是協定生態往前走了。各客戶端的介面與功能差異,另見選型指南的逐項對比;伺服器與路由器用戶可直接在下載中心取得mihomo 內核裸執行檔,不經圖形介面執行。

CL-06訂閱格式與配置檔案相容性

協定與內核之外,第三個常見的翻車點是訂閱格式。同一批節點可以被打包成多種格式分發,客戶端能不能吃下這份訂閱、吃下之後欄位會不會丟,都有明確的規律可循。

三類主流分發格式

目前流通的訂閱大體分三類。第一類是Clash YAML 完整配置:一份包含 proxies、proxy-groups、rules 的完整 YAML 檔案,Clash 系客戶端可直接匯入,資訊保留最完整,是本站教學預設採用的格式。第二類是Base64 分享連結合集:把 ss://、vmess://、trojan:// 等單節點 URI 編碼後按行拼接,通用性最好,但只攜帶節點連線參數,不含任何分流規則與策略群組,匯入 Clash 系客戶端前需要經過轉換。第三類是sing-box JSON 等其他生態的格式,Clash 系客戶端不直接相容,需要轉換服務翻譯。判斷手上訂閱屬於哪一類,把訂閱連結在瀏覽器裡開啟看回傳內容即可:YAML 有清晰的縮排結構,Base64 是一大段無空格的字母數字。

欄位相容:同一份 YAML 的代際差異

Clash YAML 語法整體向前相容,但 mihomo 擴展的欄位在原版內核上會被拒絕或忽略,典型的有:新協定的 type 值(vless、hysteria2、tuic)、rule-providers 規則集、sniffer 嗅探段、GEOSITE 類規則,以及 VLESS 相關的 flow、reality-opts 等傳輸欄位。反方向沒有問題——為原版內核寫的舊配置,mihomo 可以原樣載入。辨識一個節點條目的協定類型,看 type 欄位即可,以下是一個最小示意(參數均為假值,僅用於辨認結構):

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

  - name: "範例-Shadowsocks"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

訂閱轉換與多配置管理

當格式與客戶端不匹配時,就輪到「Clash 訂閱轉換」登場:轉換服務讀取原始訂閱,輸出目標格式,並可在轉換時套用遠端範本補全策略群組與分流規則。使用轉換服務要注意兩點——訂閱連結會經手第三方服務,對隱私敏感的用戶應優先要求訂閱提供方直接給出 Clash YAML 格式;轉換範本決定了最終的策略群組結構,範本過於複雜會拖慢配置載入,選簡潔範本為宜。多份訂閱並存時的命名、更新與切換策略,技術筆記的Profile 基礎概念一文有專門整理;具體到某個客戶端的匯入按鈕在哪、更新間隔怎麼設,回教學頁按平台小節操作即可,此處不重複展開。

CL-07按使用情境的選型建議

前六章的結論在這裡收攏。選型的正確順序是:先確認內核(mihomo 系客戶端,協定全相容),再按自己的主要情境挑協定,最後留一個不同傳輸層的協定墊底。以下按五個典型情境給出參考結論。

桌面日常辦公與網頁瀏覽

鏈路品質通常穩定,建連速度與並發體驗比極限吞吐更重要。首選 Trojan 或 VLESS + TLS:一層加密、開銷薄、行為穩定,TLS 1.3 單往返握手讓新頁面開啟乾脆利落。SS 同樣完全夠用,且在任何客戶端上零門檻。策略群組建議把同協定的多個節點編入 url-test 自動選擇群組,健康檢查間隔設在幾分鐘一次即可——桌面端不心疼這點背景流量,但過密的檢查同樣會給節點側帶來無謂壓力。客戶端按下載中心 Windows 區的順序選擇,首推 Clash Plus。

行動端通勤與省電優先

手機情境的兩個關鍵詞是網路切換與電量。協定上建議 TUIC 或 Trojan 二選一:TUIC 的 0-RTT 與連線遷移特性專治「出電梯瞬間的斷流重連」,Trojan 則勝在單位流量能耗最低。VMess 在手機上是相對最不划算的選擇——雙重加密費電,時間戳校驗又容易被手機的時鐘漂移觸發握手失敗。配合 CL-04 的省電檢查清單調整客戶端設定,Android 用戶從下載中心 Android 區取得 Clash Plus 或 FlClash,iOS 用戶按下載頁 iOS 區指引經 App Store 安裝 Clash Plus。

弱網、高丟包與晚高峰

判斷標準:延遲波動大、下載速率遠低於頻寬、影片反覆緩衝。這是 Hysteria2 的主場——自訂壅塞控制在高丟包鏈路上的吞吐優勢在 CL-03 已經解釋過,體感差距通常是「能不能流暢看高畫質」等級的。兩個前提務必確認:所在網路的 UDP 通道未被限速(公共 Wi-Fi 與部分行動網路常見此問題),以及節點側配置的頻寬參數與實際線路相符——頻寬值虛高會導致大量無效重傳,反而更慢。墊底方案必備:同一策略群組裡放一個 Trojan 或 SS 節點,UDP 不通時手動或按規則切換。

遊戲、即時語音與低延遲需求

即時類應用的痛點是 UDP 流量轉發與延遲抖動。優先 TUIC:QUIC 原生的 UDP 轉發路徑乾淨,標準壅塞控制不會像 Hysteria2 那樣為吞吐犧牲平順度,更適合穩定的小包流。次選 Hysteria2。TCP 系協定轉發 UDP 需要額外封裝,延遲與抖動都會增加一階,能避則避。此外注意分流規則:遊戲流量建議按行程或目標網段直接指定固定節點,不要交給自動測速群組——測速切換瞬間的連線遷移對下載無感,對正在進行的對局則是斷線。規則寫法可在教學頁的規則小節找到入口。

老裝置、路由器與常駐服務

樹莓派、軟路由、NAS 這類裝置的限制是 CPU 與記憶體。協定選 SS(無硬體 AES 時配 chacha20 套件)或 Trojan,避開 QUIC 系的用戶態開銷與 VMess 的雙重加密;內核直接用mihomo 裸執行檔,按裝置架構選擇 AMD64/ARM64/ARMv7/MIPS 版本,不跑圖形介面。常駐服務還要控制配置複雜度:上千條規則與幾十個策略群組會顯著推高記憶體占用,路由器上建議用精簡規則集,把複雜分流留給桌面端。

CL-08選型常見誤區與檢索入口

最後一章收錄諮詢頻率最高的幾個認知誤區,並給出站內的後續檢索路徑。這些誤區共同的特點是:結論聽起來順理成章,推導過程卻缺了關鍵一環。

誤區一:協定越新越好

協定的「新」解決的是特定情境的特定問題,不是全面升級。VLESS 相對 VMess 是明確的減法優化,但 Hysteria2 與 TUIC 相對 Trojan 並非代際碾壓——通暢網路下三者體感幾乎無差,QUIC 系反而多付出用戶態 CPU 與 UDP 可用性兩筆成本。正確做法是按 CL-07 的情境對號入座,而不是無條件追新。同理,「某協定已過時」的說法也要打折扣:SS 誕生最早,卻仍是低階裝置情境無可替代的最優解。

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

客戶端裡的延遲測試(如對測試 URL 的 HTTP 請求耗時)只反映「此刻到該節點跑一趟有多快」,與吞吐、丟包率、並發表現都不是一回事。一個延遲數字漂亮的節點可能頻寬極小,高峰期丟包嚴重的節點在深夜測試時也可能數字很好看。選節點應結合時段多測幾輪,大流量情境再補一次實際下載測試;節點全部逾時時也別急著換訂閱,按技術筆記的排查順序從本機網路查起,多數問題出在離自己最近的一環。

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

VMess over TLS 的雙重加密是歷史包袱,不是安全增益——內層加密在外層 TLS 已經建立的前提下不提供額外的保密性,只消耗 CPU。VLESS 把本體加密刪掉、完全信任 TLS 1.3,安全強度並無損失,這正是現代協定設計的共識:一層可靠的加密勝過多層重複的加密。評估安全性應看加密套件與實作品質,而不是數層數。

誤區四:內核版本盲目追新或死守舊版

兩個方向的極端都有代價。死守停更內核的問題在 CL-05 已經說透——新協定一概無法使用;而內核大版本更新偶爾伴隨配置欄位的調整,盲目第一時間升級可能遇到舊配置需要小改的情況。穩妥節奏是:保持客戶端在活躍維護的版本線上(下載中心的推薦排序即以此為準),大版本更新後先在一份備份配置上驗證,再切換日常使用。配置檔案的備份與多 Profile 管理方法,見 CL-06 章末給出的筆記連結。

下一步去哪裡

讀完本手冊,站內的後續路徑按需取用:動手安裝從下載中心按平台取件;第一次配置走教學頁的三步主線;客戶端軟體之間猶豫不決,查選型指南的橫向對比;TUN 模式、DNS 洩漏、macOS 權限這類專題問題,到技術筆記按標籤檢索。本頁隨協定生態演進不定期修訂,編目資訊以頁首館藏卡為準。