Clash 協議與核心技術參考

01 · SELECTION MODEL

先區分協議、傳輸層與用戶端能力

協議名稱並不等於完整的連線方案

在 Clash 用戶端的節點清單中，使用者通常會先看到 ss、vmess、trojan、vless、hysteria2 或 tuic。這些名稱描述代理工作階段如何驗證、封裝與傳輸資料，但不代表完整的網路條件。節點的實際表現還取決於底層採用 TCP 或 UDP、是否疊加 TLS、是否透過 WebSocket 或 gRPC 承載、伺服器距離、連線丟包、壅塞控制、網域名稱解析方式，以及用戶端核心的實作。

例如，同樣是 VLESS，TCP 與基於 WebSocket 的連線會有不同的握手開銷；同樣是 Shadowsocks，不同加密方法對舊裝置 CPU 的負擔也不同。Hysteria2 與 TUIC 都建立在 QUIC 架構上，但工作階段管理、驗證欄位與壅塞策略並不相同。只比較協議名稱而忽略傳輸欄位，容易把伺服器品質、網路路徑與協議設計混為一談。

因此，選型應分三層理解。第一層是節點協議，決定驗證方式與基本封裝。第二層是傳輸與安全參數，例如 network、tls、servername、ALPN、壅塞控制與 UDP 中繼。第三層是用戶端能力，包括核心是否識別該欄位、圖形介面能否完整編輯、Android 背景執行是否穩定，以及訂閱轉換過程是否保留原始參數。三層同時符合，節點才能依預期建立連線。

速度結論必須連同測試條件一起看

協議不存在脫離環境的固定速度排名。在短距離、低丟包的連線中，TCP 協議通常已足夠穩定，測速差異可能主要來自伺服器負載。在高往返延遲或波動明顯的行動網路中，QUIC 類協議可能更快恢復傳輸，但也可能因電信商網路對 UDP 的處理方式而失去優勢。節點延遲只代表探測請求的往返時間，不能直接等同於網頁首次開啟速度、檔案吞吐量或影片緩衝能力。

合理的比較方式是固定用戶端、核心、伺服器區域、測試時間與規則模式，再分別記錄首次連線耗時、持續吞吐量、切換網路後的恢復時間與裝置耗電量。至少進行多輪測試，以排除單次無線網路抖動。若訂閱中的多個協議來自不同伺服器，結果只能用來比較節點整體品質，不能據此判斷協議本身。

從使用限制出發，而不是從協議熱度出發

選擇協議前，先回答四個問題：用戶端核心是否支援、訂閱能否完整下發、目前網路是否穩定提供 UDP，以及裝置是否需要長時間在背景執行。桌面端可接受較高的記憶體用量，行動裝置則還要考慮射頻喚醒、重新連線頻率與電池最佳化。路由器也會受到 CPU 架構、記憶體容量與硬體加速能力限制。同一節點在電腦上運作穩定，不代表適合低功耗裝置長期承載全家的流量。

如果只需要可靠連線與廣泛相容性，成熟的 SS、Trojan 往往較容易部署與遷移。需要現代傳輸組合時，可在確認核心支援後選擇 VLESS。高延遲或丟包連線可測試 Hysteria2、TUIC，但同時應保留一個 TCP 類型節點作為備援。VMess 常見於既有訂閱，繼續使用並沒有問題；新設定是否採用，應依服務端生態與用戶端相容範圍判斷，而不是只按名稱的新舊決定。

本頁後續章節將依協議家族、效能面向、核心關係與情境決策展開。若目前遇到的是「已連線但網頁打不開」，應先依八步網路排查清單檢查節點、DNS、規則與系統時間，而不是立即更換協議。連線故障與協議選型是兩個不同問題，分開處理更容易得到穩定結論。

02 · SS / VMESS

Shadowsocks 與 VMess：成熟實作與狀態式工作階段

Shadowsocks 的設計重點

Shadowsocks 在設定中通常寫作 ss，核心結構相對直接：用戶端使用預先共用的密碼衍生金鑰，對代理流量加密後轉送至伺服器。現代設定通常採用 AEAD 或較新的 2022 系列加密方法。其協議標頭較精簡，用戶端實作廣泛，TCP 與 UDP 轉送路徑也相當成熟，因此常被用作相容性基準。

SS 的優勢不在於「任何環境都最快」，而在於實作數量多、設定欄位少、資源開銷容易預測。對一般網頁、軟體更新、長連線與常見 UDP 應用，通常能提供穩定結果。在效能較弱的路由器上，加密方法會明顯影響 CPU 使用率。具備硬體加速的 AES 平台可能適合 AES-GCM；部分行動處理器或不同架構的裝置使用 ChaCha20-Poly1305 時會更均衡。不能只看演算法名稱判斷快慢，應觀察裝置的實際負載。

2022 系列方法改良了金鑰與工作階段的處理方式，但要求用戶端與伺服器同時支援。若訂閱錯誤地將新方法降級為舊欄位，常見結果不是速度變慢，而是直接驗證失敗。匯入後應檢查 cipher 與 password 是否完整，尤其確認密碼符合伺服器要求的金鑰格式。圖形介面只顯示節點名稱時，可匯出設定或檢視原始 Profile 進行確認。

VMess 的狀態與時間條件

VMess 使用使用者識別碼完成驗證，並包含工作階段相關處理。Clash 設定中常見欄位包括 uuid、alterId、cipher、傳輸網路與 TLS 設定。較新的伺服器通常採用簡化的驗證組合，但舊訂閱仍可能保留歷史欄位。由於生態中的設定來源差異很大，VMess 節點最需要檢查的不是名稱，而是欄位組合是否與伺服器一致。

VMess 對系統時間較為敏感。Android 或桌面系統時間偏差較大時，可能出現節點看似存在、網路權限也正常，但握手持續失敗的情況。此時重新安裝用戶端通常沒有作用，應先啟用系統自動設定時間與時區，再重新連線。企業網路、虛擬機快照或長期離線的裝置更容易出現時間偏差。

VMess 可以承載於 TCP、WebSocket、HTTP 或 gRPC 等傳輸之上。傳輸層增加了部署彈性，也增加設定項目數量。WebSocket 節點需要路徑與 Host 相符；TLS 節點需要伺服器名稱與憑證名稱匹配；gRPC 節點則需要正確的服務名稱。任何欄位在訂閱轉換中遺失，都可能導致連線失敗。因此，VMess 的相容性不能只按「核心支援 VMess」判斷，還要確認該核心支援訂閱所使用的具體傳輸組合。

適用範圍與限制

需要簡單設定、方便跨用戶端遷移時，SS 通常是穩妥選擇。已有 VMess 訂閱且運作穩定時，不必只因協議名稱改變就重新設定。經常在多個用戶端之間切換的使用者，應優先保留 VMess 節點的原始訂閱，避免經過多層轉換。每次轉換都會增加欄位改名、預設值變化或傳輸參數遺失的機率。

在 Android 上長期執行時，兩者的基本耗電通常不是由協議標籤決定，而是共同受到實際流量、TLS 連線數量、UDP 活躍程度、DNS 模式與延遲測試頻率影響。若背景耗電突然增加，可參考Android 背景耗電與常駐設定，先關閉高頻率自動測速，並檢查裝置廠商的電池策略是否反覆終止 VPN 服務。

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

範例展示 mihomo 相容的基本欄位結構。網域、連接埠與密碼需要替換為訂閱提供的實際值。手動填寫時請保持 YAML 縮排一致，不要使用定位字元；若用戶端由訂閱管理，應優先在原始設定來源修正，而不是每次更新後重複修改本機副本。

03 · TROJAN / VLESS

Trojan 與 VLESS：TLS 工作階段與精簡驗證

Trojan 的連線結構

Trojan 通常以 TLS 作為連線基礎，用戶端透過密碼完成驗證。設定的關鍵欄位包括伺服器位址、連接埠、密碼、對應 SNI 的 servername、憑證驗證與 UDP 開關。欄位數量不算多，但 TLS 名稱必須準確。伺服器位址可以是 IP，SNI 仍應填寫憑證對應的網域；若同時將 IP 當作伺服器名稱，憑證驗證通常無法通過。

Trojan 常見的優勢是建立在成熟的 TLS 堆疊上，桌面與行動系統的實作普遍穩定。其效能主要受 TLS 握手、連線重複使用、伺服器設定與網路品質影響。已建立的長連線不會在每次傳輸時重複完成完整握手，因此持續吞吐量通常較為平穩。在大量短連線的情境中，連線重複使用與 DNS 結果更值得關注，單看加密開銷不足以解釋全部差異。

用戶端中可能有「略過憑證驗證」之類的選項，但不應作為長期修復方法。憑證錯誤通常表示系統時間、SNI、網域或伺服器憑證設定不一致。暫時關閉驗證只會掩蓋根本原因，也會改變原有的安全邊界。正確順序是確認自動時間、核對 servername、檢查訂閱是否保留該欄位，再由伺服器維護者檢查憑證鏈。

VLESS 的職責範圍

VLESS 將驗證與傳輸安全分開處理，本身不提供傳統意義上的內建加密層，通常依賴 TLS 或其他受支援的安全傳輸。它使用 UUID 類識別碼進行驗證，協議標頭相對精簡，可與 TCP、WebSocket、gRPC 等傳輸組合。部分設定還包含流量控制或 Reality 相關欄位；這些能力是否可用，取決於伺服器實作與用戶端核心。

「支援 VLESS」只表示核心能識別基礎協議，不代表支援所有擴充功能。舊版原版 Clash 對 VLESS 及其後續擴充的支援範圍有限；mihomo 作為 Meta 分支延續，涵蓋的欄位更完整。使用 Clash Plus、Clash Verge Rev、FlClash 等用戶端時，還需確認實際嵌入的核心與設定入口。圖形介面可能只開放常用欄位，但匯入訂閱仍可能保留更多參數；也可能在內部轉換時捨棄介面無法識別的值。

VLESS 設定的排查順序應從基礎層開始。先檢查位址、連接埠與 UUID，再檢查 TLS、伺服器名稱與傳輸類型，最後檢查路徑、服務名稱、流量控制或 Reality 參數。不要一次修改多個欄位，否則連線恢復後便無法判斷真正原因。訂閱更新覆蓋本機修改也是常見現象；完成驗證後，應將修正寫回訂閱來源或用戶端的持久覆寫層。

兩者如何選擇

Trojan 更適合欄位相對集中、TLS 設定清楚且方便跨用戶端遷移的情境。VLESS 則更適合伺服器已採用相應生態，且用戶端明確使用 mihomo 等相容核心的情境。兩者都無法繞過伺服器線路品質。若 Trojan 與 VLESS 位於不同伺服器，測速結果無法證明某個協議效率更高；只有同機、同線路、同一時間範圍的對照才具參考價值。

在行動裝置上使用時，持續的 TLS 工作階段通常不會造成異常耗電。真正影響電量的是連線是否頻繁中斷、系統是否反覆啟動 VPN 服務、應用程式是否持續執行 URL 測試，以及 QUIC、語音或遊戲等 UDP 流量是否長時間活躍。一個設定正確且連線穩定的 Trojan 節點，可能比不斷重新連線的輕量協議更省電。穩定性本身就是功耗因素。

proxies:
  - name: vless-tls
    type: vless
    server: proxy.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: ws
    tls: true
    servername: edge.example.com
    ws-opts:
      path: /proxy
      headers:
        Host: edge.example.com

此片段用於說明欄位層級，不代表任何可連線節點。WebSocket 路徑區分大小寫，Host 與 SNI 可能相同，也可能由伺服器分別指定。匯入失敗時應對照訂閱原文，而不是根據其他節點複製欄位。不同伺服器的路徑與驗證資訊不能混用。

04 · QUIC TRANSPORT

Hysteria2 與 TUIC：面向波動連線的 QUIC 協議

QUIC 改變了哪些連線行為

Hysteria2 與 TUIC 都使用基於 UDP 的 QUIC 傳輸。QUIC 將加密握手、可靠傳輸與多路複用結合在使用者空間實作，避免傳統 TCP 多連線之間完全獨立的隊頭阻塞。在往返延遲較高、丟包呈波動狀態的連線中，設定得當的 QUIC 工作階段可能更快恢復吞吐量。從 Wi-Fi 切換至行動數據時，部分實作還能透過連線遷移降低重新建立工作階段的成本。

這些特性不代表任何 UDP 環境都會更快。如果接入網路限制 UDP 工作階段時間、路由設備處理大量 UDP 的能力較弱，或 NAT 映射頻繁變動，QUIC 節點可能出現能連線但吞吐不穩、待機後恢復緩慢、語音正常但網頁偶爾逾時等現象。此時應先確認 UDP 基礎可用性，再調整協議參數。直接提高頻寬宣告通常無法修復網路路徑問題。

Hysteria2 的頻寬與壅塞設定

Hysteria2 簡化了早期設定結構，常見欄位包括伺服器、連接埠、密碼、SNI、憑證驗證與上下行頻寬提示。頻寬值不是用戶端憑空取得的加速額度，而是壅塞控制用來估算傳送節奏的輸入。填寫明顯高於實際接入能力的數值，可能造成突發丟包與重傳；填得過低則會限制吞吐量。沒有明確要求時，應優先採用訂閱提供的值或核心預設策略。

Hysteria2 對 UDP 路徑品質敏感。測試時除了延遲，也應觀察持續下載是否週期性降速、切換網路後是否恢復，以及待機喚醒後第一個請求是否逾時。Android 裝置廠商的電池策略若凍結用戶端，QUIC 保活可能中斷；回到前景後重新連線屬於系統背景限制，不一定是協議故障。應先將用戶端加入適當的背景執行策略，再比較協議。

憑證相關處理方式與其他 TLS 協議相同。SNI 必須對應伺服器憑證；系統時間需要準確；略過驗證不應作為日常設定。若訂閱提供混淆密碼或跳躍連接埠等擴充欄位，必須確認 mihomo 核心與目前用戶端版本使用的欄位名稱一致。設定轉換器可能識別基礎 Hysteria2，卻忽略擴充項目。

TUIC 的工作階段與並行特性

TUIC 同樣建立在 QUIC 之上，常見驗證由 UUID 與密碼組成，並提供壅塞控制、UDP 中繼模式、SNI 與 ALPN 等參數。其設計重視並行流與低延遲資料傳輸。對網頁多請求、即時通訊，以及同時存在 TCP、UDP 流量的情境，在穩定連線下可維持良好回應。但伺服器與用戶端必須在協議版本與欄位定義上相符，舊格式設定不能只修改 type 後繼續使用。

TUIC 的壅塞控制選項應根據伺服器建議與連線特性選擇。盲目複製他人的參數，可能在不同頻寬與佇列管理條件下得到相反結果。UDP 中繼模式也會影響相容範圍；某些模式強調原生 UDP 行為，某些模式則更適合透過 QUIC 流轉送。若遊戲、語音或 DNS 出現個別故障，應核對中繼模式，而不是只看節點是否「連線成功」。

Hysteria2 與 TUIC 適合加入策略組，作為特定連線的候選項，不必取代所有 TCP 節點。可以建立手動選擇組，保留一個成熟的 TCP 節點與一個 QUIC 節點，在固定網站、固定檔案與固定時間範圍下比較。如此既能利用波動連線下的恢復能力，也能在 UDP 條件改變時快速切換。

05 · PERFORMANCE / POWER

連線速度、資源用量與行動裝置耗電

把「快」拆成四項指標

使用者感受到的速度至少包含連線建立時間、第一個位元組時間、持續吞吐量與故障恢復時間。網頁開啟緩慢可能是 DNS、TLS 或首次連線延遲；大型檔案速度慢更接近持續吞吐問題；搭乘捷運或切換行動熱點後長時間無回應，則屬於連線恢復問題。不同協議最佳化的環節不同，單次延遲測試無法涵蓋全部指標。

SS 的基礎封裝較輕，在低丟包環境中建立連線與傳輸都較直接。Trojan 以及啟用 TLS 的 VMess、VLESS 會增加握手流程，但長連線建立後，持續傳輸的差異通常會縮小。Hysteria2 與 TUIC 在高延遲、波動或隨機丟包的連線上可能更快恢復，但前提是 UDP 路徑穩定。協議速度不是固定屬性，而是協議機制與目前連線互相作用的結果。

用戶端延遲測試也有測量限制。URL-Test 通常會向指定位址發出 HTTP 請求，結果包含 DNS、連線與伺服器回應。同時測試多個節點會在短時間內建立大量連線，導致行動裝置射頻保持活躍並喚醒 CPU。測速間隔過短時，使用者看到的是頻繁變化的數字，代價則是背景耗電與額外流量。日常使用不需要持續重新整理秒級延遲。

CPU、記憶體與連線數量

CPU 使用量主要來自加密、TLS、資料複製、規則比對、DNS 處理與 TUN 協議堆疊。桌面處理器通常不會因單一普通連線產生明顯負擔，但高速下載、數百個並行連線或效能較弱的路由器會放大差異。SS 加密方法應配合硬體能力選擇；TLS 類協議會使用系統或核心的加密函式庫；QUIC 在使用者空間維護丟包恢復與壅塞控制，可能比簡單的 TCP 代理消耗更多計算資源。

記憶體用量不能只看協議。規則集規模、Geo 資料、Fake-IP 對映、連線追蹤與日誌等級都會增加常駐記憶體。相同節點在規則模式與全域模式下，資源差異可能來自規則比對而非協議。排查時先固定設定，只替換一個節點，再觀察穩定執行一段時間後的 CPU 與記憶體，避免把啟動時載入規則的峰值誤認為長期狀態。

連線重複使用可以減少握手，但過多長連線也會增加狀態維護負擔。瀏覽器、即時通訊與系統同步服務可能同時保持連線。TUN 模式接管的應用範圍更大，因此連線數通常高於只使用系統代理。若切換 TUN 後耗電上升，應檢查哪些應用程式被納入代理、DNS 是否形成迴圈，以及背景同步應用是否持續重試。

Android 耗電取決於喚醒模式

Android 上的 Clash 用戶端透過 VpnService 建立本機 VPN 介面。只要 VPN 圖示存在，系統就會將符合條件的流量交給用戶端，但常駐服務本身不等於持續高負載。真正影響電量的是每秒處理的資料量、網路射頻保持活躍的時間、定時測速、日誌寫入、重新建立連線，以及裝置廠商的背景策略。

頻繁終止後重新啟動，通常比穩定常駐更耗電。用戶端被電池最佳化凍結後，系統應用程式仍可能產生請求；恢復時會集中重新連線，表現為短時間 CPU 峰值與流量突增。需要長期使用時，應允許用戶端維持必要的背景執行，同時降低自動測速頻率、結束排錯後關閉詳細日誌，並避免多個 VPN 或網路過濾應用程式同時接管。

QUIC 協議可能維持 UDP 對映與保活，在行動網路下的耗電取決於實作與網路逾時策略。若待機耗電異常，可分別測試一個 TCP 節點與一個 QUIC 節點，每輪維持相同的規則、DNS 與應用程式使用方式。只切換協議組，不修改其他設定。記錄螢幕關閉後的電量變化、用戶端重新連線次數與系統網路狀態，才能判斷差異來源。

如果用戶端顯示已連線，但應用程式完全沒有流量，應先排除 DNS、規則與系統代理問題。瀏覽器與終端機讀取代理的路徑不同，相關驗證方法請參考系統代理未生效的兩條排查路徑。只有確認流量確實抵達核心後，協議效能比較才有意義。

06 · KERNEL FAMILY

原版 Clash、Clash.Meta 與 mihomo 的家族關係

原版 Clash 的設定基礎

原版 Clash 建立了廣泛使用的 YAML 設定結構，包括 proxies、proxy-groups、rules、DNS、監聽連接埠與執行模式。大量訂閱與用戶端介面仍以這套結構為基礎。其核心價值在於統一節點、策略組與規則分流的表達方式，讓不同協議都能納入同一套選擇與自動測試機制。

原版專案停止維護後，現有用戶端仍可能繼續使用其歷史核心，但新協議、DNS 行為與平台支援不會自動獲得後續改進。因此，「Clash 設定」與「原版 Clash 核心」需要分開理解。前者已成為生態中的通用設定稱呼，後者則指特定實作。檔案採用 Clash YAML，不代表只能由原版核心讀取。

從 Clash.Meta 到 mihomo

Clash.Meta 在原有設定模型上擴充協議、TUN、DNS、規則提供者與平台能力，之後以 mihomo 核心名稱持續發展。實際使用時，使用者仍會看到 Meta 設定、Meta 節點或 Clash Meta for Android 等名稱；這些名稱反映專案演進與用戶端品牌，不代表存在三套完全獨立的設定語法。

mihomo 對原版 Clash 設定維持高度相容，同時加入 VLESS、Hysteria2、TUIC、Reality 相關參數，以及更多 DNS 與 TUN 選項。相容方向主要是「新核心讀取舊設定」。反向則不成立：包含新協議與擴充欄位的 mihomo 設定，無法直接交給原版核心完整執行。舊核心可能回報未知代理類型，也可能忽略無法識別的全域欄位，形成部分功能可用、部分行為偏離預期的狀態。

設定相容性也會受到欄位預設值影響。新核心可能修正歷史行為、加入嚴格驗證，或改變某些邊界條件。遷移後即使檔案通過語法檢查，也要驗證 DNS、規則命中、UDP、區域網路監聽與 TUN 接管。語法通過只表示結構可解析，不代表執行結果完全相同。

用戶端名稱不等於固定的核心能力

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等是圖形用戶端或應用程式名稱；mihomo 則是其中常見的代理核心。用戶端負責安裝、權限、設定管理、系統匣或行動介面，核心負責協議連線、DNS、規則與流量處理。兩者的更新節奏可能不同，因此不能只看用戶端名稱推斷全部協議能力。

本站下載頁依平台列出目前可選的用戶端，並將 Clash Plus 列為全平台優先選擇。需要 VLESS、Hysteria2、TUIC 等現代協議時，應選擇明確採用 mihomo 或相容實作的用戶端。Clash for Windows 與 ClashX Meta 已標示為停止維護，適合處理既有環境或封存需求，不應作為驗證新協議欄位的首選。

Android 還要區分應用程式版本、核心架構與安裝套件架構。ARM64 裝置通常使用對應架構套件，通用套件則用於相容更多裝置。成功安裝不代表訂閱中的所有協議都可用；核心載入 Profile 時仍會驗證代理類型與欄位。遇到「部分節點消失」時，應查看設定載入日誌，確認是訂閱未下發、用戶端篩選，還是核心拒絕了未知欄位。

遷移時先執行靜態檢查

mihomo 提供設定檢查入口。具備命令列環境時，可以在啟動前驗證 YAML 是否可解析。這項檢查能發現縮排、未知類型與部分欄位錯誤，但不會測試節點密碼、伺服器憑證或實際網路路徑。

mihomo -t -f ./config.yaml

檢查通過後，再依「DNS 解析—單節點連線—規則命中—UDP—TUN」的順序驗證。不要一開始就啟用全部覆寫、腳本與複雜規則，否則發生錯誤時很難定位層級。想了解 Profile 各區域的職責，可繼續閱讀設定檔結構與多設定管理。

07 · PROFILE COMPATIBILITY

訂閱格式、欄位轉換與設定相容界線

連結訂閱與 YAML Profile

Clash 用戶端常見的匯入來源有兩類。第一類是完整的 YAML Profile，直接包含節點、策略組、規則與 DNS 設定。第二類是 URI 或聚合訂閱，由伺服器回傳節點連結，再由用戶端或轉換服務產生 Clash 設定。前者結構完整，適合保留規則與進階欄位；後者方便跨應用程式分發，但轉換過程可能遺失特定協議擴充。

單一節點 URI 的表達能力受協議格式限制。SS、Trojan、VMess、VLESS、Hysteria2 與 TUIC 各自擁有不同的連結欄位，用戶端解析器也可能採用不同的容錯規則。連結中的網域、路徑、SNI 與節點名稱需要進行 URL 編碼；若伺服器輸出格式不規範，某個用戶端可能接受，另一個用戶端則會拒絕。這類差異不是節點本身失效，而是解析階段不一致。

完整 YAML 更適合檢查問題。節點欄位可以逐項讀取，策略組的引用關係也很清楚。訂閱更新時，用戶端通常會以遠端內容取代快取的 Profile；直接編輯產生的檔案，可能在下次更新後消失。需要長期修改時，應使用用戶端提供的覆寫、合併或腳本入口，並確認覆寫執行順序。

轉換器最容易遺失的欄位

伺服器、連接埠與驗證資訊等基礎欄位通常能夠保留，較容易遺失的是傳輸擴充。VMess 與 VLESS 的 WebSocket Host、路徑、gRPC 服務名稱、流量控制參數，Trojan 的 SNI，Hysteria2 的混淆與頻寬提示，以及 TUIC 的壅塞控制與 UDP 中繼模式，都需要轉換器明確理解。轉換器若只識別協議基礎結構，節點仍會出現在清單中，但建立連線時可能失敗。

另一類問題是欄位名稱變更。某些訂閱使用上游專案的原始命名，而 Clash 設定要求另一套鍵名；部分用戶端會自動對映，部分則直接保留未知欄位。排查時應取得轉換前的原始節點資訊，與匯入後的 YAML 進行比對。只在圖形介面中查看節點名稱，無法確認欄位是否完整。

策略組也會在轉換過程中改變實際體驗。節點雖然全部匯入，卻可能沒有加入目前選取的群組；規則最終指向另一個策略；自動測試組也可能因測試 URL 無法連線，而將可用節點標記為失敗。在判斷協議之前，應先於手動選擇組中直接選定單一節點，排除策略組自動切換的影響。

最小可驗證設定

完整訂閱無法載入時，可以建立最小設定，只保留監聽、一個節點、一個手動策略組與最終規則。這樣能區分節點欄位錯誤與大型規則、DNS、Provider 的問題。最小設定驗證成功後，再逐層加入 DNS、規則提供者與 TUN。每次只增加一類功能，並保留上一份可正常運作的檔案。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: test-node
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,MANUAL

此設定結構可用於 mihomo 的基礎驗證，範例位址與驗證值需要替換。測試期間使用 log-level: info 即可；需要定位握手欄位時，可暫時提高日誌詳細程度，完成後恢復，避免長期寫入大量記錄。若用戶端自行管理連接埠，應遵循用戶端產生的基礎範本，不要與介面設定重複宣告。

相容性檢查清單

多個設定共存時，應為 Profile 使用清楚的名稱，並記錄其核心要求，例如「基礎相容」「mihomo 擴充」「行動裝置低功耗」。名稱應用來說明設定目的，不要只用日期區分。用戶端切換 Profile 後，還要確認目前的策略組選擇，因為部分應用程式會為每個 Profile 個別儲存狀態，另一些則沿用同名策略組的上次選擇。

08 · DECISION GUIDE

依使用情境選擇協議，並保留備援路徑

日常網頁與多裝置遷移

主要需求是網頁、軟體更新與一般應用程式，且需要在 Windows、macOS、Android 與 Linux 之間遷移時，應優先選擇欄位較少、用戶端支援廣泛的協議。SS 與 Trojan 通常適合作為基礎節點。SS 需要確認所有裝置都支援該加密方法；Trojan 則需要確認 SNI 與憑證。兩者都建議啟用伺服器實際支援的 UDP 轉送，以免 DNS、語音或部分應用程式單獨失效。

用戶端方面，Clash Plus 是本站的全平台首選，適合需要統一介面與設定入口的使用者。Clash Verge Rev、FlClash 等可作為桌面替代方案，Clash Meta for Android 與 Surfboard 則可因應不同的 Android 使用習慣。選擇用戶端時，應先看平台與核心，再看介面功能，不要因為兩個應用程式都帶有 Clash 名稱，就假設設定能力完全相同。

高延遲、波動網路與即時流量

網路往返時間較高，或移動過程中的丟包波動明顯時，可以測試 Hysteria2 或 TUIC。測試前先確認 UDP 可達，並保留一個 TCP 節點。固定使用相同的應用程式與測試內容，觀察連線恢復、首次開啟與持續傳輸，不要只比較延遲數字。若 QUIC 節點在 Wi-Fi 下穩定，卻在行動數據下頻繁中斷，應優先保留雙協議策略組，依網路環境手動切換。

遊戲、語音與視訊會議更關注抖動、丟包恢復與 UDP 中繼。節點能開啟網頁，不代表即時流量正常。TUIC 需要核對 UDP 中繼模式，Hysteria2 需要核對 UDP 與壅塞參數；SS、Trojan、VLESS 則需要確認用戶端與伺服器都啟用 UDP。測試時應觀察實際應用程式，不要用網頁測速取代即時情境。

低功耗裝置與路由器

效能較弱的路由器應先控制規則集、日誌與並行連線，再比較協議。輕量的 SS 搭配適合硬體的加密方法，通常較容易預測資源用量；Trojan 與 VLESS TLS 需要考慮握手與加密函式庫；Hysteria2、TUIC 的使用者空間 QUIC 則會增加 CPU 與記憶體壓力。以高吞吐量為目標時，路由器 CPU 可能先達到上限，導致速度無法繼續提升。

Android 長期在背景執行時，應優先選擇連線穩定的節點，而不是理論上封裝最輕的節點。頻繁中斷並重新握手的節點會造成更多喚醒。建議將測速週期設為分鐘級或按需執行，維持一般日誌等級，並確認系統沒有反覆終止 VPN 服務。若只在特定應用程式中使用代理，可透過應用程式分流減少不必要的背景連線。

舊訂閱與新核心遷移

既有 VMess、SS 或 Trojan 訂閱運作正常時，遷移至 mihomo 不必先更換協議。第一步只替換核心或用戶端，保持 Profile 內容不變；第二步驗證 DNS、規則、UDP 與 TUN；第三步再加入 VLESS、Hysteria2、TUIC 等新節點。分階段遷移可以將核心差異與協議差異分開。

從 mihomo 回退至舊核心時，需要刪除或替換舊核心無法識別的節點與欄位。單純將檔名改回去並沒有作用。若策略組引用了已刪除的節點，也會造成載入失敗。回退設定應作為獨立 Profile 儲存，並使用基礎協議與通用欄位。如此一來，新設定發生問題時便能快速恢復，不必臨時修改複雜的主要設定。

可執行的決策順序

1. 確認用戶端。檢查作業系統、CPU 架構與實際核心。需要現代協議時，優先選擇採用 mihomo 的用戶端。
2. 確認訂閱。查看節點類型與擴充欄位是否完整，避免使用不支援目標協議的轉換器。
3. 建立基礎節點。先使用 SS、Trojan 或既有的穩定節點，驗證 DNS、規則、系統代理與 TUN。
4. 加入候選協議。在同一個手動策略組中加入 VLESS、Hysteria2 或 TUIC，每次只測試一個變數。
5. 依情境測試。分別觀察網頁首次開啟、持續下載、即時 UDP、網路切換與待機恢復。
6. 儲存備援設定。保留上一份可正常運作的 Profile，不要讓訂閱更新覆蓋唯一可用的設定。

協議選型的最終目標不是取得固定排名，而是建立可解釋、可回退的連線組合。穩定節點負責日常基準，現代協議應對特定網路條件，手動策略組負責快速切換，獨立 Profile 則用於隔離變更。發生故障時，應從訂閱、解析、策略、連線、DNS 與系統接管逐層判斷，避免將所有問題歸咎於協議。

完成選擇後，可前往安裝套件頁面確認對應平台的用戶端，或依使用指南完成匯入與首次連線。若 Profile 更新後出現結構變化，請繼續參考Profile 結構拆解；若已成功連線卻無法存取網路，則返回已連線但無法上網排查清單逐項驗證。