Clash 協議與核心技術參考

02 · TCP FAMILIES

SS、VMess、Trojan 與 VLESS 的設計取捨

SS：結構精簡，依賴明確的加密方法

Shadowsocks 通常簡稱 SS。其核心思路是以較輕量的協議結構承載代理流量，透過預先共享的密碼和指定加密方法保護資料。現代設定應使用目前核心支援的 AEAD 方法，並確保伺服器端與客戶端的加密方法、密碼和連接埠完全一致。SS 本身欄位較少，匯入訂閱和跨客戶端遷移相對直接，記錄中的失敗原因也較容易沿著連接埠、密碼、加密方法和網路可達性逐項排查。

欄位少不代表所有 SS 節點表現都相同。伺服器端實作、加密演算法的硬體加速、UDP 中繼、外掛參數和底層網路都會影響結果。部分訂閱還會附帶 plugin 與 plugin-opts，用於增加額外承載層；如果目前核心不支援指定外掛，即使基礎的 server、port、cipher 和 password 都正確，節點仍然無法使用。面對資源有限的路由器，SS 經常是容易理解的起點，但應在目標架構上測試加密開銷，不能只根據桌面處理器的結果推斷。

VMess：身分、時間與傳輸選項較多

VMess 來自 V2Ray 生態系，設定通常包含使用者識別、alterId、加密選項、網路傳輸和 TLS 等欄位。歷史設定中常可看到不同的 alterId 值，較新的伺服器部署通常採用更精簡的組合，但客戶端仍可能為了相容舊訂閱而保留解析欄位。VMess 的驗證過程對時間狀態較敏感，裝置時間明顯偏差時可能出現驗證失敗，因此排查時除了檢查位址和使用者識別，也應確認系統時間同步正常。

VMess 的實際複雜度主要來自可搭配多種傳輸方式。TCP、WebSocket、HTTP 和 gRPC 對路徑、反向代理與伺服器端設定有不同要求。WebSocket 設定需要核對 path 與 Host；gRPC 需要核對 service-name；啟用 TLS 時還要檢查 servername、憑證驗證和 ALPN。訂閱轉換工具有時會遺漏較少見的傳輸欄位，表現為節點名稱存在、基礎資訊正確，但握手始終失敗。處理這類問題時，應逐欄比較轉換前後的單一節點設定，而不是不斷切換代理模式。

Trojan：以 TLS 承載，憑證參數是關鍵

Trojan 通常透過標準 TLS 連線承載資料，驗證核心是密碼。其設定表面上不複雜，但 TLS 相關欄位決定連線能否建立。server 是實際連線位址，servername 或 SNI 用於 TLS 握手中的主機名稱，兩者可以相同，也可能不同。若使用網域連線，DNS 解析、憑證有效性與主機名稱匹配都必須成立。若訂閱將網域替換為 IP，卻沒有保留正確的 servername，常見結果是 TCP 可達但 TLS 驗證失敗。

部分使用者會直接開啟 skip-cert-verify 來繞過憑證錯誤，這會掩蓋網域、憑證鏈或系統時間問題。更穩妥的順序是先確認裝置時間，再檢查 servername 是否對應憑證名稱，然後確認伺服器端憑證鏈和網路路徑。只有在明確知道憑證驗證失敗原因並接受相應風險時，才應調整驗證策略。Trojan 也可以使用 WebSocket 或 gRPC 等承載方式，排查邏輯與 VMess 類似：先確認 TLS，再核對 path、Host 或 service-name，最後檢查 UDP 與策略組行為。

VLESS：減少協議層負擔，安全性依賴傳輸層

VLESS 同樣來自 V2Ray 體系，但設計上不在協議層提供與 VMess 相同的加密機制，通常依賴 TLS 或其他安全傳輸提供機密性和身分驗證。它使用使用者識別進行驗證，常見設定包括 uuid、flow、network、tls、servername，以及與傳輸對應的附加欄位。由於協議層處理更直接，VLESS 經常用於需要靈活傳輸組合的部署，但「欄位更精簡」不代表可以省略安全傳輸。

VLESS 設定的相容性問題集中在擴充能力。不同核心對 flow、Reality、客戶端指紋、傳輸細節和 UDP 行為的支援時間並不一致。mihomo 支援多種 VLESS 擴充功能，但具體可用欄位仍應以目前核心文件和執行記錄為準。訂閱中出現未知欄位時，解析器可能忽略它，也可能拒絕整個節點；忽略比報錯更難發現，因為節點看似已匯入，卻在執行階段失敗。遷移到另一個客戶端前，應確認關鍵擴充沒有在轉換過程中消失。

proxies:
  - name: "SS baseline"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上例只展示 SS 節點的最小結構，用於辨識欄位關係。實際位址、連接埠、密碼和加密方法必須來自伺服器端設定。YAML 對縮排敏感，列表項目下的欄位需要保持在同一層級；密碼中含有冒號、井字號或其他特殊字元時應使用引號。設定載入失敗與連線失敗是兩類問題：前者先檢查 YAML 語法和欄位名稱，後者再檢查網路、驗證與伺服器端狀態。

04 · PERFORMANCE

連線速度、資源占用與行動端電量

連線建立時間與持續吞吐量不是同一項指標

網頁開啟速度受 DNS、TCP 或 QUIC 握手、TLS、伺服器處理和頁面資源數量共同影響。協議握手較輕，只能減少其中一部分時間；如果 DNS 緩慢或頁面需要連線到多個網域，節點的單連線優勢未必能轉化為明顯體驗。持續下載則更依賴路徑容量、壅塞控制和伺服器端出口。短連線測試應重複造訪多個目標並排除快取影響，持續傳輸測試應維持足夠時間，觀察速度是否穩定、是否週期性歸零，以及切換網路後的恢復情況。

多路複用也需要謹慎理解。將多個邏輯連線放到較少的底層連線中，可以減少重複握手，但底層連線出現壅塞或中斷時，影響範圍也會擴大。TCP 上的多路複用仍可能受到單條 TCP 連線丟包恢復影響；QUIC 的多串流設計能減少串流之間的阻塞，但會增加使用者空間的狀態管理。對於大量短請求，多路複用可能有效；對於少量長時間的大流量連線，收益不一定明顯。預設關閉或開啟都不應視為絕對結論，應依應用程式類型進行測試。

CPU、記憶體與加密開銷

SS 的資源消耗與加密方法、處理器指令集和並行數相關。支援硬體加速的桌面處理器可以高效處理常見 AEAD 演算法，而某些低功耗架構對另一類演算法更友善。Trojan、VMess over TLS 和 VLESS over TLS 都要承擔 TLS 處理，實際開銷還取決於傳輸層是否使用 WebSocket、gRPC 或額外的多路複用。Hysteria2 與 TUIC 除了加密外，還要在使用者空間維護 QUIC 的確認、重傳、壅塞和串流狀態。

記憶體占用通常不是由協議名稱單獨決定。連線數量、規則規模、DNS 快取、TUN 路由、記錄等級和 provider 數量，都可能比單一節點的差異更明顯。路由器出現記憶體壓力時，應先減少不必要的規則集、縮短過多的 provider 鏈路、限制詳細記錄持續寫入，再比較協議。桌面端則應觀察長時間執行後是否持續增加，而不是只記錄剛啟動時的數值。發生異常增加時，保存設定結構和觸發步驟，比簡單判斷某協議「更吃記憶體」更有助於定位。

行動端耗電主要由喚醒頻率決定

手機電量表現不僅取決於加密運算，更取決於無線模組和 CPU 被喚醒的頻率。頻繁的節點健康檢查、較短的 DNS 快取、持續記錄、背景測速和過於積極的保活，都會增加喚醒次數。即使每次處理量很小，長時間累積也會明顯影響待機。基於 QUIC 的節點可能為了維持 NAT 對映而傳送保活封包，TUN 模式還要處理更多系統流量；如果裝置上有大量背景應用程式，這些因素會疊加。

最佳化順序應先處理全域行為，再更換協議。將健康檢查間隔設定為符合故障發現需求的合理值，不要讓多個 provider 同時高頻探測；只保留實際使用的策略組；除錯結束後恢復一般記錄等級；不需要接管所有流量時優先使用系統代理；確認區域網路連線開關與實際需求一致。完成這些調整後，再在同一時段比較 TCP 與 QUIC 節點。測試期間應保持螢幕亮度、應用程式活動和網路類型相近，否則系統排程差異會掩蓋協議差異。

建立可重複的測試記錄

測試表至少應記錄裝置、作業系統、客戶端、核心、網路類型、接管方式、DNS 模式、節點協議和測試時段。一次只修改一個變數，例如先固定規則模式與系統代理，只替換 SS 和 Hysteria2 節點；下一輪再固定節點，比較系統代理與 TUN。每輪同時記錄成功率和錯誤類型。若五次連線中有兩次逾時，即使成功時速度很高，也不適合作為自動選擇組的唯一節點。

行動端電量至少應觀察一個完整的日常使用週期，並查看系統電量頁面中客戶端的前景與背景活動。短時間執行幾分鐘無法代表待機保活成本。出現耗電異常時，可以先停止所有主動健康檢查並關閉詳細記錄，再逐項恢復，以定位喚醒來源。關於背景執行與省電策略的進一步步驟，可閱讀Clash 手機耗電快怎麼辦。

06 · SUBSCRIPTIONS

訂閱格式、設定相容性與欄位保真度

節點連結、節點清單與完整設定

「訂閱」可能指三種不同內容。第一種是由多個協議連結組成的節點清單，例如 ss、vmess、trojan 或 vless 連結；客戶端或轉換服務負責將連結解析為 Clash 節點。第二種是已轉換好的 proxies 清單，只包含節點，不含完整規則和 DNS。第三種是完整的 Clash 或 mihomo 設定，除節點外還包含 proxy-groups、rules、rule-providers、dns、tun 等部分。匯入前先判斷類型，可以避免把完整設定當成節點 provider，或用訂閱更新覆蓋本地規則。

節點連結適合跨工具傳遞，但並非所有擴充參數都有統一表達方式。VLESS 的 flow、Reality 欄位，Hysteria2 的頻寬與混淆參數，TUIC 的驗證和壅塞控制選項，都可能因連結規範、產生端或轉換端不同而遺失。完整 YAML 能表達更多欄位，但對目標核心的依賴更明確。需要在多個 mihomo 客戶端之間遷移複雜設定時，保留 YAML 通常比反覆轉成分享連結更可靠。

proxy-providers 負責來源，不等於協議轉換

proxy-providers 可以讓 mihomo 從檔案或 URL 載入節點集合，並依 interval 更新。它適合將節點來源與主設定分離，再由多個策略組引用同一個 provider。provider 的 health-check 可以定期造訪測試位址，用於判斷節點是否可用，但檢查頻率會影響網路請求和行動端耗電。provider 讀取的是目標核心能夠解析的內容；如果遠端回傳的是不相容格式，單純放入 provider 並不會自動完成任意協議轉換。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: "https://www.example.com/"

範例中的網域僅用於表示結構。url 應替換為實際訂閱位址，並避免公開分享含有存取憑據的連結。path 指向核心工作目錄下的快取檔案；interval 是更新週期；health-check 的 interval 是健康檢查週期，兩者含義不同。測試位址應穩定、回應較小，並與實際網路目標具有可比性。若多個 provider 都設定很短的檢查週期，客戶端會持續產生背景連線，行動端尤其需要控制頻率。

轉換過程最容易遺失擴充欄位

訂閱轉換通常經歷解析來源格式、對應欄位、產生目標 YAML 三個步驟。傳統 SS、VMess 和 Trojan 的常見欄位對應較成熟，但外掛、gRPC、Reality、客戶端指紋、Hysteria2 與 TUIC 的擴充項目更容易受到轉換器能力限制。轉換後應抽查每種協議至少一個節點，比較 server、port、uuid 或 password、network、tls、servername、alpn、flow、udp 等關鍵欄位。不要只比較節點數量；數量相同也可能存在欄位遺失。

節點名稱也可能影響管理。轉換器為了去重會重新命名節點，而 proxy-groups 中若直接寫入舊名稱，載入時會出現找不到代理的錯誤。使用 providers 引用節點集合可以減少名稱耦合，但規則目標與策略組名稱仍必須存在。遷移完整設定時，先檢查所有規則最終指向的策略組，再檢查策略組引用的節點或 provider，形成從 rules 到 proxy-groups 再到 proxies 的引用鏈。

YAML 語法正確仍可能存在語意錯誤

YAML 檢查可以發現縮排、重複結構和類型問題，卻無法確認遠端位址、密碼、SNI 或規則目標是否正確。常見語意錯誤包括連接埠被寫成字串後遭某些解析器拒絕、布林值使用不一致、同名策略組重複、規則指向不存在的群組、provider 路徑沒有寫入權限，以及節點啟用了伺服器端不支援的 UDP。應先執行核心設定檢查，再啟動並觀察第一輪 provider 更新、DNS 初始化和節點握手記錄。

當完整訂閱由服務方維護時，本地修改可能在下一次更新時被覆蓋。需要長期保留的規則應放在客戶端支援的覆寫、合併或本地設定層，而不是直接編輯遠端快取檔案。不同客戶端對覆寫機制的名稱和能力不同，遷移前應匯出本地規則。Clash Plus 等客戶端可以簡化設定管理，但仍需要區分遠端訂閱、產生後的執行設定和本地覆寫三個層次，排查時確認實際生效的是哪一份。

08 · MIGRATION

協議測試、設定遷移與故障定位

遷移前建立可恢復的最小設定

從舊客戶端遷移到 Clash Plus、Clash Verge Rev、FlClash 或其他 mihomo 客戶端時，先保留舊客戶端可運作的設定，不要立即刪除。在新客戶端中只匯入一個節點或一個 provider，建立包含 DIRECT、單一代理和 MATCH 的最小規則，確認核心啟動、DNS 和系統代理正常。基準通過後，再加入完整策略組、規則集和 TUN。這樣可以將客戶端安裝問題、核心相容問題和複雜設定問題分開。

若從原版 Clash 設定遷入 mihomo，多數基礎欄位可以繼續使用，但仍應檢查 DNS 和 TUN 的預設行為。若反向遷移，則需要刪除 VLESS、Hysteria2、TUIC 等原版不支援的節點及 Meta 擴充規則。策略組引用必須同步更新，否則設定會因目標不存在而失敗。任何批次修改都應先複製檔案，並使用核心檢查命令確認語法，再替換正在執行的設定。

按階段讀取記錄

啟動階段記錄回答「設定能否載入」。重點查看 YAML 解析、未知欄位、provider 檔案、監聽連接埠和 TUN 權限。更新階段記錄回答「遠端內容能否取得並解析」，重點查看訂閱請求、回傳格式、快取路徑和節點數量。連線階段記錄回答「目標流量是否命中規則並完成握手」，重點查看規則目標、節點名稱、DNS、逾時、TLS 和驗證資訊。將不同階段混在一起會導致錯誤判斷，例如訂閱更新成功並不能證明節點握手成功。

常見的 dial tcp timeout 表示在規定時間內沒有完成 TCP 連線，可能來自位址無法連線、連接埠受阻、DNS 結果異常或伺服器端未監聽；connection refused 表示目標明確拒絕連線，優先檢查連接埠與服務狀態；TLS 錯誤應檢查系統時間、servername 和憑證；authentication failed 指向密碼、UUID 或驗證字串。QUIC 節點若持續逾時，應先切換網路判斷 UDP 路徑，再檢查協議參數。更多記錄文字和定位順序請參考Clash 執行記錄怎麼看。

連接埠、系統代理與 TUN 的分層檢查

mixed-port 常用於同時提供 HTTP 與 SOCKS 入口。開啟系統代理後，作業系統應指向客戶端實際監聽的位址與連接埠；如果連接埠被其他程式占用，核心可能啟動失敗，介面開關也不代表監聽已成功。可以先關閉其他代理工具，再查看記錄中的監聽錯誤。區域網路共享還需要 allow-lan、防火牆和正確的監聽位址，不能只將本機位址填入另一台裝置。

TUN 模式位於更低的接管層，需要系統權限、虛擬網卡或相應的網路擴充功能。啟用後無法上網時，先關閉 TUN 回到系統代理基準。如果系統代理正常，表示節點、訂閱和基本 DNS 大致可用，問題更可能出在 TUN 權限、路由或 DNS 劫持。然後重新啟用 TUN，逐項檢查自動路由、介面選擇、私有位址排除和 DNS 模式。不要在 TUN 故障時同時更換協議節點，否則會失去有效對照。

協議替換採用單一變數順序

從 VMess 切換到 VLESS，或從 Trojan 切換到 Hysteria2 時，應盡量保持目標服務、客戶端、規則、DNS 和接管方式一致。先確認新節點能在手動選擇組中單獨連線，再加入自動測試或回復組。測試網頁、持續下載、UDP 應用程式和切換網路後恢復四類行為，並記錄錯誤。若新協議只在某類業務中表現較好，可以建立專用策略組，而不是一次性替換全域預設。

複雜協議的調校應分層進行：第一輪使用訂閱預設參數；第二輪只調整傳輸相關選項；第三輪再考慮多路複用、頻寬或壅塞控制；最後處理 TUN 與 DNS。每一輪都應能回到上一步。調整參數後若效能下降，應撤銷最近一次變更，而不是繼續疊加設定。可恢復性是正式環境設定的重要屬性，能讓升級核心、切換客戶端和更換網路時都有明確退路。

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

這段內容展示用於排查的基礎結構：規則模式、混合連接埠、區域網路開關、一般記錄等級和三條規則。實際設定還需要定義名為 PROXY 的策略組或代理。規則依序比對，明確網域應放在更通用的 GEOIP 與 MATCH 之前。若記錄顯示目標命中 DIRECT，就不應繼續排查代理協議握手，而應先修正規則目標。

建立最終選擇記錄

完成測試後，為每個預設節點記錄協議、傳輸、TLS 主機名稱、適用網路、是否支援 UDP、對應 provider 和回復節點。不需要保存密碼等敏感內容，只記錄定位所需的結構資訊。行動端另外記錄是否啟用 TUN、健康檢查間隔和背景限制；路由器記錄核心架構、服務啟動方式和規則集來源。下一次客戶端或核心更新後，依照同一份記錄重新測試，比重新憑感覺選擇更可靠。

最終設定通常不需要涵蓋所有協議。保留一到兩個穩定的 TCP 節點、一個經驗證的 QUIC 節點，再透過清晰的策略組組織，已足以應付多數桌面與行動情境。節點數量過多會增加健康檢查、名稱管理和故障定位成本。協議手冊的作用不是要求同時啟用所有技術，而是協助辨識每種方案要解決的問題、依賴的條件，以及失敗時的回復路徑。