Clash 協定與核心技術參考 代理協定選型對照

這六種協定不是六個平行的選項，而是同一個問題在不同階段給出的不同答案。它們要完成的事情一致：把本機流量加密後送到遠端伺服器，再由伺服器端發出請求。差別出在實作路徑上——傳輸層選 TCP 還是 UDP、身分驗證放在握手前還是握手後、連線是有狀態還是無狀態。這三條軸決定了協定的效能特徵、相容範圍與適合的部署環境。

第一條軸：傳輸層

Shadowsocks、Vmess、Trojan、VLESS 都屬於 TCP 優先的一類。在 QUIC 成熟之前，TCP 是幾乎所有網路環境都能承載的傳輸層，代價是握手需要往返、封包遺失的復原由核心負責。Hysteria2 與 TUIC 選擇 UDP 上的 QUIC，把加密、壅塞控制與多工全部放進使用者空間實作，好處是握手更快、封包遺失復原更靈活，代價是 CPU 佔用更高。

傳輸層的選擇直接決定連接埠要求。TCP 類協定只需要放行一個 TCP 連接埠，伺服器端防火牆、雲端服務商安全群組、容器連接埠對應三處保持一致即可。QUIC 系協定必須放行 UDP 連接埠，而且部分雲端服務商的安全群組預設不放行 UDP，設定時容易漏掉這一步，症狀是「用戶端連不上、伺服器端日誌裡什麼都沒有」。

第二條軸：身分驗證與特徵

Shadowsocks 沒有握手協商，用戶端與伺服器端共用金鑰，對上就能開始傳資料，協定層不做身分宣告。Vmess 引入 UUID 身分，把驗證做成協定的一部分，伺服器端可以依 UUID 區分使用者、統計流量、個別限速。Trojan 與 VLESS 換了一條路：把流量放進標準 TLS，驗證資訊藏在 TLS 之後，伺服器端在憑證與 SNI 層面與一般 HTTPS 網站沒有區別。

驗證方式越複雜，握手開銷越大，換來的可管理性也不同。共用密碼最簡單，缺點是換密碼要通知所有人；UUID 便於依使用者管理，代價是設定項目更多；TLS 承載類的可管理性最好，但對憑證與網域有硬性要求。選型時把「誰維護伺服器端」這件事一起考慮進去，比單純比較協定效能更有意義。

第三條軸：狀態與開銷

有狀態協定需要維護工作階段表，無狀態協定每個請求獨立處理。VLESS 是無狀態設計的代表，伺服器端不需要為每條連線保存工作階段，重啟與移轉的成本更低。Vmess 早期依賴時間窗口校驗，後來移除了這套機制，說明「狀態」在工程上始終是負擔。對用戶端來說，有狀態協定可以做連線重用（多工），減少重複握手，但對單一大流量連線沒有幫助，反而可能讓所有連線共用同一條鏈路的抖動。

把三條軸放在一起看，六種協定的定位就清楚了：Shadowsocks 與 Vmess 是通用型，相容面最廣；Trojan 與 VLESS 是 TLS 承載型，適合需要標準 HTTPS 特徵的部署；Hysteria2 與 TUIC 是 UDP 優先型，在封包遺失與高延遲鏈路上有優勢。後面三章分別展開這三組。

Shadowsocks：把加密轉發做薄

Shadowsocks 的設計目標只有一個：把本機流量加密後原樣轉發出去，不在協定裡加入任何額外協商。用戶端與伺服器端共用一組密碼，密碼經金鑰衍生函式生成工作階段金鑰，AEAD 加密（AES-256-GCM 或 ChaCha20-Poly1305）直接作用在資料流上。第一個封包就是密文，沒有握手往返，因此建立連線的延遲幾乎等於一次 TCP 握手。

代價是協定本身沒有身分宣告，伺服器端無法知道「誰」在連線，只能依密碼區分。Shadowsocks 2022 規範（SIP022）在這一點上做了改進：引入工作階段 ID 與重放保護，把金鑰衍生拆成主金鑰與工作階段金鑰兩層，同時改善了 UDP 的處理方式。新舊版本的伺服器端與用戶端之間存在相容性差異，部署前需要確認伺服器端實作是否支援 2022 規範，否則會出現「密碼正確卻連不上」的情況。

加密套件的選擇也有講究。AES-256-GCM 在具備硬體加速指令的裝置上更快，路由器與低功耗裝置上 ChaCha20-Poly1305 表現更穩定。兩者安全性同級，差別只在實作效率，用戶端與伺服器端必須使用同一套加密方式。

Vmess：把傳輸層做成可選項

Vmess 是 V2Ray 專案的原生協定，核心變化是把傳輸層抽象出來。同一個 Vmess 身分可以跑在裸 TCP、mKCP、WebSocket、gRPC、HTTP/2 之上，也可以疊加 TLS。身分用 UUID 表示，伺服器端可以依 UUID 區分使用者、做統計與限速。這種設計讓 Vmess 的部署形態非常靈活：需要走標準 WebSocket 連接埠的場景、需要 gRPC 多工的場景，都可以重複使用同一套身分設定。

靈活性帶來的是設定複雜度。Vmess 的分享連結是 base64 編碼的 JSON，欄位命名在不同實作之間並不統一（ps、add、port、id、aid、net、type、host、path、tls、sni 各代表一段資訊），轉換工具處理不當時會遺失欄位。另外，Vmess 自帶的加密層在已經疊加 TLS 的情況下屬於重複加密，運算開銷高於 VLESS——這也是 VLESS 出現的原因之一。

兩者的取捨

如果只看相容性，Shadowsocks 與 Vmess 是涵蓋最廣的兩個協定：原版 Clash、mihomo、Surfboard 以及各類行動端用戶端都能識別。差別在於資源佔用與設定成本——Shadowsocks 更省 CPU，Vmess 更靈活。UDP 轉發方面，Shadowsocks 需要伺服器端實作明確開啟，Vmess 原生支援 UDP over TCP 的轉發方式，在只放行 TCP 的環境裡更省事。

一個常見誤解是「協定越新越快」。在同一台伺服器、同一條鏈路上，Shadowsocks 與 Vmess 的實測吞吐量差異通常小於鏈路本身的波動；真正拉開差距的是握手次數與是否疊加 TLS。選型時優先考慮用戶端支援範圍與伺服器端實作，而不是協定出現的時間順序。

Trojan：把驗證放進 TLS 之後

Trojan 的做法很直接：伺服器端監聽 443，先完成標準 TLS 握手，用戶端在握手完成後提交密碼，伺服器端校驗通過才開始轉發。對中間的轉發設備而言，這個連接埠的流量與一般 HTTPS 網站沒有區別；伺服器端甚至可以在同一個連接埠上用一個真實網站做回落（fallback），未通過驗證的請求交給網站處理，因此一個網域可以同時承載網站與代理服務。

這種設計的依賴項目很明確：一張有效的憑證、一個與憑證相符的網域、正確的 SNI。三項裡任何一項錯位，用戶端都會在握手階段失敗，日誌裡通常只留下「連線被重設」或「TLS 握手失敗」這類籠統提示。Trojan 的 UDP 支援在不同實作之間有差異，原生實作提供 UDP associate，部分實作依賴擴充版本。設定上 Trojan 是六種協定裡最簡單的一類——位址、連接埠、密碼、SNI，四項就能跑起來。

VLESS：去掉重複加密

VLESS 的設計前提是：既然外層已經有 TLS，協定內部就不需要再做一次加密。於是 VLESS 本身不加密，只負責攜帶身分（UUID）與目標位址，安全性完全交給底層傳輸。這一刀砍掉了 Vmess 裡最重的運算開銷，也讓伺服器端變成無狀態——不需要維護工作階段，不需要校驗時間戳記，重啟不影響後續連線的建立。

VLESS 的另一個變化是流量控制。Vision 流控（flow 欄位取 xtls-rprx-vision）會在 TLS 層內做填充與分片，減少嵌套 TLS 場景下的額外開銷。需要注意的是，flow 參數是用戶端與伺服器端之間的約定，訂閱轉換工具如果丟棄了這個欄位，連線會退化成一般 TLS 模式——功能上仍然可用，但效能特徵與預期不同。判斷方法是打開連線日誌，確認實際使用的流控方式。

憑證與時間：兩個最常見的問題

TLS 承載類協定的故障大多不在協定本身，而在憑證鏈。自簽憑證需要用戶端明確跳過驗證，長期使用並不適合；憑證鏈不完整時，桌面瀏覽器可能因為快取了中繼憑證而顯示正常，用戶端卻直接報錯。另一類問題是系統時間——時間偏差超過憑證有效期容許範圍後驗證會失敗，症狀卻像是「節點無法使用」，很容易被誤判成伺服器端故障。

疑難排解順序建議固定下來：先看用戶端日誌裡的錯誤類型（握手失敗、憑證驗證失敗、連線逾時），再依系統時間、憑證鏈、SNI 三項逐一排除。憑證報錯的完整疑難排解路徑請見技術筆記《Clash 環境下的 HTTPS 憑證報錯：常見成因與疑難排解順序》。

Hysteria2：依設定的頻寬發送

Hysteria2 把傳輸層換成 QUIC（HTTP/3 的底層協定），內建 TLS 1.3，不需要額外設定加密套件。它最有辨識度的部分是壅塞控制：預設使用 Brutal，依用戶端設定的上下行頻寬固定速率發送，鏈路出現封包遺失時不主動降速。這個策略在封包遺失率較高的鏈路上能維持吞吐量，前提是頻寬參數填得接近真實值——填得過大，會排擠同一條鏈路上的其他流量；填得過小，則發揮不出協定本身的優勢。

Hysteria2 還提供 UDP 層的混淆選項（salamander），把 QUIC 封包做一層輕量包裝。伺服器端只需要一個 UDP 連接埠，不需要為每個使用者分配連接埠，部署與擴充都比 TCP 類協定簡單。設定項目比 Trojan 多一些：位址、連接埠、密碼、SNI、頻寬上下限，以及是否跳過憑證驗證。

TUIC：0-RTT 與原生 UDP 轉發

TUIC 同樣基於 QUIC，設計上更貼近「把 QUIC 的能力直接用滿」：v5 版本支援 0-RTT 握手，重用工作階段時可以省去一次往返；UDP 轉發有兩種模式（native 與 quic），前者把 UDP 封包直接封裝，後者走 QUIC 串流，依鏈路特徵選擇。壅塞控制演算法可以在 bbr、cubic、new_reno 之間切換，與 Hysteria2 的固定速率策略形成對比。

TUIC 的身分用 UUID 與密碼共同表示，設定項目數量與 Vmess 接近。它對用戶端的要求更高——需要核心完整實作 QUIC 堆疊，因此目前只有 mihomo 系核心支援。伺服器端同樣只需要一個 UDP 連接埠，且多個使用者共用同一連接埠不會互相干擾。

QUIC 系的共同代價

QUIC 在使用者空間實作，這是它最大的工程代價。加密、壅塞控制、重傳都在應用程式裡完成，CPU 佔用高於核心空間的 TCP；行動端持續傳輸時，電量消耗的差異會比 TCP 類協定更明顯；記憶體佔用也因為 QUIC 的緩衝區而更高。在桌面端與伺服器上這些開銷通常可以接受，在路由器、低規裝置或長時間行動使用的場景裡則需要權衡。

另一個現實限制是 UDP 連接埠本身。部分企業網路與公共 Wi-Fi 會對 UDP 做限制或降級處理，此時 QUIC 系協定的表現會明顯下降，需要退回 TCP 類協定。這也是為什麼 Hysteria2 與 TUIC 更適合當作備援節點而不是唯一節點——訂閱裡同時保留一個 TCP 類節點，切換成本最低。

三者關係

原版 Clash 核心定義了 config.yaml 的基本骨架：proxies、proxy-groups、rules、proxy-providers、rule-providers、dns、tun 等段落，以及 mode、log-level、mixed-port、external-controller 這些頂層欄位。這份骨架後來成為整個生態的事實標準，幾乎所有用戶端都依它組織設定。原版核心已經停止維護，但它的欄位命名方式一直沿用至今。

Clash.Meta 是在原版基礎上做的擴充分支，增加了新協定、新規則類型與更完整的 TUN 實作。分支後來更名為 mihomo，儲存庫與文件遷移到 MetaCubeX 組織下維護。目前仍在更新的圖形用戶端——Clash Verge Rev、Clash Meta for Android、FlClash、Clash Nyanpasu、ClashX Meta——使用的都是 mihomo 核心。Clash for Windows 使用原版核心，已封存停止維護，可以繼續載入原版設定，但不認得後來新增的欄位。

判斷一個用戶端用哪個核心，最直接的方法是看日誌裡的版本行與設定解析結果：載入設定時提示未知欄位，說明核心的欄位集合較小；能識別 sniffer、listeners、rule-set 這些段落，說明是 mihomo 系。開源生態中各專案的關係請見技術筆記《Clash 開源生態梳理：核心、用戶端與規則集的關係》。

功能差異對照

設定相容性與移轉

從原版核心移轉到 mihomo 基本上是無痛過程：原版設定裡的段落與欄位在 mihomo 中全部保留，直接載入即可。反向移轉則需要注意——mihomo 的擴充欄位在原版核心裡會觸發解析錯誤，需要逐項刪除。常見需要刪除的段落包括 sniffer、listeners、sub-rules，以及 rule-providers 中的 mrs 格式宣告。

# 以下段落僅 mihomo 系核心識別，原版核心會直接回報未知欄位
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443, 8443]

兩類核心的解析風格都是嚴格的：遇到不認識的欄位會直接報錯，而不是忽略。這個特性在移轉時是好事——設定有問題會立刻暴露，不會無聲降級。看到 unknown field 這類日誌時，先確認用戶端的欄位集合，再決定是刪除欄位還是換用戶端。

另一個容易忽略的差異是 DNS 段落。mihomo 對 dns 的設定項目做了擴充（nameserver-policy、fallback-filter 的比對方式、是否讓解析遵守規則等），原版核心的 dns 段落更簡單。移轉時如果保留了舊欄位，需要確認新核心是否仍然接受；反過來，把帶擴充欄位的 dns 段落拿到原版核心上，會直接解析失敗。

四種訂閱形態

第一種是完整 YAML 訂閱：伺服器端直接回傳一份 config.yaml，包含 proxies、proxy-groups、rules 以及連接埠設定，用戶端載入後即可使用。這種形態對使用者最省事，代價是訂閱提供方決定了規則策略，使用者自己的規則需要額外維護。第二種是分享連結清單：一份 base64 編碼的多行文字，每行是一條 ss://、vmess://、trojan://、vless://、hysteria2:// 或 tuic:// 連結，用戶端解析後得到節點清單，規則由用戶端在本機決定。

第三種是轉換服務：把分享連結清單轉換成 Clash YAML，中間可以套用規則範本。轉換服務解決了用戶端不認識分享連結的問題，同時引入了新的資訊耗損。第四種是 proxy-providers：用戶端定時從一個遠端位址拉取節點清單，與本機規則解耦，適合多訂閱合併。

proxy-providers：把節點與規則分開

proxy-providers 讓用戶端定時從遠端拉取節點清單，與本機規則解耦。它適合多訂閱合併與團隊共用設定：規則寫在本機，節點從遠端更新。每個 provider 可以個別設定更新間隔、健康檢查位址與過濾表達式。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe/xxxx"
    interval: 3600
    path: ./providers/provider-a.yaml
    filter: "(?i)(hk|sg|jp)"
    health-check:
      enable: true
      url: https://example.com/generate_204
      interval: 300

過濾表達式是 provider 裡最實用的兩個欄位：filter 與 exclude-filter，用正規表達式比對節點名稱。例如只保留名稱裡帶某個地區標識的節點，或排除臨時節點。需要注意的是，過濾發生在用戶端：伺服器端回傳的節點仍然會被下載到本機檔案，只是不進入可用清單。遇到「節點變少了」這類問題時，先看過濾表達式，再看伺服器端回傳的內容。

轉換與更新中的常見陷阱

分享連結轉 YAML 的過程會遺失資訊，這是最常見的問題來源。vless:// 的 flow 參數、hysteria2:// 的混淆與跳過驗證選項、tuic:// 的壅塞控制與 UDP 轉發模式，在部分轉換工具裡沒有對應欄位，轉換後連線會退化成預設參數。判斷方法是比對轉換前後的節點參數，而不是只看「能不能連上」。

proxies:
  - name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
  - name: "vless-a"
    type: vless
    server: 203.0.113.11
    port: 443
    uuid: b831381d-6324-4d53-ad4f-8cda48b30811
    tls: true
    servername: example.com
    flow: xtls-rprx-vision
  - name: "hy2-a"
    type: hysteria2
    server: 203.0.113.12
    port: 443
    password: "your-password"
    sni: example.com
    up: "30 Mbps"
    down: "200 Mbps"

第二類問題是 YAML 語法本身。節點名稱裡出現逗號、冒號、引號時，如果沒有加上引號包住，整份設定會解析失敗；這類錯誤通常表現為「訂閱更新成功但節點清單是空的」。第三類問題是訂閱裡的連接埠設定——部分訂閱會帶上 port、socks-port 欄位，用戶端一般會忽略它們並使用本機設定；如果發現本機連接埠被改，先檢查用戶端的連接埠覆寫選項。

訂閱更新失敗的疑難排解順序建議固定：先確認連結在瀏覽器裡能直接存取（回傳文字而不是登入頁），再確認用戶端日誌裡的 HTTP 狀態碼，最後檢查訂閱是否包含用戶端不認識的協定——包含未知協定的節點會被跳過，其餘節點正常載入。更多訂閱相關的疑難排解項目整理在常見問題頁。

用戶端決定協定上限

mihomo 系核心的用戶端支援完整的協定集：Shadowsocks、Vmess、Trojan、VLESS、Hysteria2、TUIC 都能識別。使用原版核心的 Clash for Windows 已封存停止維護，只支援 Shadowsocks、Vmess、Trojan、Snell 與 HTTP / SOCKS5 這類第一代協定；Surfboard 的協定範圍也以 Shadowsocks、Vmess、Trojan 為主。訂閱裡包含 VLESS 或 Hysteria2 節點時，在封存用戶端上這些節點會被直接跳過，症狀是「節點數比訂閱裡少」。

全平台首推的用戶端是 Clash Plus：Windows、macOS、Android、iOS 都有對應版本，iOS 端透過 App Store 取得，官網網域為 clashplus.io，訂閱匯入與規則分流的方式與其他用戶端一致。桌面端還可以選擇 Clash Verge Rev（Windows / macOS / Linux）、FlClash（全平台）、Clash Nyanpasu（Windows）；Android 端常用 Clash Meta for Android 與 FlClash；macOS 上除 Clash Verge Rev 外還有已封存的 ClashX Meta。各平台的安裝檔入口集中在取得用戶端頁。

平台差異

桌面端資源充足，可以放心使用 QUIC 系協定，CPU 佔用不是瓶頸。Android 端要留意系統的背景省電策略：省電模式會限制背景網路活動，QUIC 的長連線在背景可能被系統暫停，症狀是「切回來需要重新連線」。這類場景下 TCP 類協定的表現更穩定，或者把用戶端的保持連線設定調得更寬鬆。

iOS 端由系統統一管理網路擴充功能，用戶端的選擇以 App Store 上架的版本為準，設定匯入流程與桌面端一致，同樣是匯入訂閱連結。路由器與低規裝置上，使用者空間實作的 QUIC 堆疊會明顯吃緊，Shadowsocks 這類輕量協定更合適；同時要注意裝置記憶體，規則集本身也會佔用一部分。

情境選型表

除了協定本身，用戶端的選擇還受更新節奏影響。仍在維護的用戶端會跟進核心的新協定與新欄位，封存用戶端只能維持既有能力。用戶端之間的橫向差異請見技術筆記《主流 Clash 用戶端橫向對比：依平台與使用習慣選型》。

移轉前的準備

換用戶端或換協定之前，先把現有設定匯出備份：profile 檔案、規則檔案、訂閱連結。封存用戶端（Clash for Windows、ClashX Meta）的設定仍然可以繼續使用，匯出的 config.yaml 在 mihomo 系用戶端上基本上可以直接載入，需要刪除的是核心不認識的新欄位——方向與原版移轉到 mihomo 相反。

換協定時確認三件事：伺服器端是否支援目標協定、連接埠是否放行（QUIC 系需要 UDP）、訂閱裡是否包含該協定的節點。三項裡缺任何一項，用戶端上都不會出現可用的連線。如果伺服器端只提供分享連結，先確認連結的協定前綴與用戶端支援範圍一致，再匯入。

移轉後的驗證

驗證順序建議從規則開始：打開用戶端的連線日誌，確認流量命中的是預期規則與策略群組，而不是落到預設直連或預設代理。然後驗證 DNS——解析結果是否符合設定裡的 nameserver 與策略，是否出現意料之外的解析來源。最後驗證 UDP 轉發：需要 UDP 的應用程式能否正常運作，這一項在 QUIC 系協定上通常是原生支援的，在 Shadowsocks 上取決於伺服器端設定。

如果使用 proxy-providers，額外確認訂閱定時更新是否成功：日誌裡會記錄每次拉取的時間與結果，節點清單是否被過濾表達式清空也要一併檢查。更新失敗的常見原因是連結失效、回傳內容不是 YAML，或過濾表達式把全部節點排除掉了。

常見回退情境

QUIC 系協定在限制 UDP 的網路裡表現會下降，此時切回 TCP 類協定即可，不需要更換訂閱。憑證類問題優先檢查系統時間與憑證鏈，具體路徑請見技術筆記《Clash 環境下的 HTTPS 憑證報錯：常見成因與疑難排解順序》。訂閱更新失敗優先檢查連結可存取性與用戶端日誌，常見原因整理在常見問題頁。

如果移轉的目標是替換已停止維護的用戶端，完整流程（設定匯出、核心替換、替代方案對比）請見技術筆記《用戶端停止更新之後：設定匯出、核心替換與替代方案》。移轉完成後，建議把新設定與舊設定各保留一份，觀察一到兩週再刪除舊檔案。