Clash 協定、核心與訂閱相容性技術參考

01 · Decision Model

先確認限制，再比較協定名稱

協定、傳輸與用戶端是三個層次

在 Clash 設定中，「節點類型」通常對應代理協定，例如 ss、vmess、trojan、vless、hysteria2 或 tuic。協定負責規定用戶端與伺服器如何建立工作階段、驗證身分、封裝目標位址以及傳遞應用程式資料。它不等同於底層傳輸：VMess、VLESS 等協定可以組合 TCP、WebSocket、gRPC 或其他傳輸方式；Trojan 通常與 TLS 一起出現；Hysteria2 和 TUIC 則以 QUIC 及 UDP 傳輸能力為重要基礎。訂閱中看似相同的協定節點，只要傳輸方式、TLS 參數或伺服器實作不同，實際行為就可能明顯不同。

用戶端是更外層的操作介面。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等 GUI 用戶端負責匯入設定、切換策略群組、管理系統代理與顯示連線資訊，真正解析節點欄位並建立連線的是其內建或呼叫的核心。選擇用戶端時，需要同時確認平台支援與核心能力；選擇節點時，則要確認協定欄位是否能被目前的核心識別。GUI 能顯示節點名稱，不代表底層一定能完整處理該節點的所有選項，尤其是較新的協定擴充或傳輸參數。

用四個問題縮小範圍

第一項限制是伺服器已提供哪些內容。用戶端不能把一個 Shadowsocks 節點直接改成 VLESS，也不能只修改 type 欄位就完成協定轉換。協定兩端必須採用一致的驗證與封裝規則，因此節點類型首先由伺服器設定決定。如果訂閱只提供一種協定，合理做法是檢查目前核心是否支援，並最佳化節點、策略與 DNS，而不是在用戶端中任意改寫協定名稱。

第二項限制是網路路徑是否可靠支援 UDP。Hysteria2 與 TUIC 的主要傳輸建立在 UDP 和 QUIC 之上；如果本地網路、路由設備或伺服器入口對 UDP 的支援不穩定，可能出現握手逾時、速度波動或頻繁重新連線。此時 TCP 類方案即使峰值吞吐量不突出，持續可用性也可能更好。判斷 UDP 能力不能只看網頁是否能開啟，應觀察一段時間內的連線建立、休眠恢復、大型檔案傳輸與網路切換表現。

第三項限制是裝置資源。桌面裝置通常更在意並行連線、下載吞吐量與長時間執行穩定性；手機與平板還要考量無線模組喚醒、背景存活、網路切換與電量消耗；路由器或小型伺服器則可能受 CPU 指令集、記憶體與檔案描述元數量限制。加密演算法、使用者空間壅塞控制、連線多工與日誌層級都會改變資源用量，協定名稱只能提供方向，不能取代實測。

第四項限制是設定的可遷移性。長期使用的訂閱可能包含規則集、策略群組、DNS、腳本或特定核心擴充。遷移到另一個用戶端時，最容易出問題的往往不是基礎節點，而是規則提供者、TUN 參數、嗅探設定與較新的協定欄位。若需要在多台裝置間共用設定，應優先選擇共同支援的欄位子集，並把平台專屬設定放在用戶端本機，而不是全部寫入同一份通用訂閱。

選型時建議先保留一個穩定基準，再比較候選協定。基準可以是目前能持續連線、設定欄位較少的節點。接著只改變一個變數，例如維持相同伺服器區域與相近線路，分別測試 TCP 類與 QUIC 類節點。如果同時更換伺服器、協定、連接埠與策略群組，結果就無法歸因，也很難判斷後續應調整哪一項。

02 · Established Protocols

Shadowsocks 與 VMess：成熟基礎與組合能力

Shadowsocks 的簡潔設計

Shadowsocks 常縮寫為 SS，其核心概念是使用預先共用的密碼與選定的 AEAD 加密方法，保護用戶端與伺服器之間的資料，並以較輕量的協定封裝轉發 TCP 或 UDP 流量。它的設定項目相對集中，典型節點只需要伺服器位址、連接埠、密碼與加密方法。較少的協商步驟與清楚的實作邊界，使它容易獲得不同核心與用戶端支援，也適合作為檢查訂閱、DNS 與策略群組是否正常運作的基準協定。

「設定簡單」不代表所有 Shadowsocks 節點都相同。加密方法必須與伺服器一致，名稱拼寫也要符合核心支援清單。現代設定通常採用 AEAD 方法；舊式串流加密方法可能因實作策略或安全特性而不再被部分用戶端接受。如果訂閱包含外掛欄位，還要確認目前核心是否支援相應外掛及其參數。一個基礎 SS 節點能夠匯入，不能推論帶外掛的另一個節點也一定相容。

從資源角度來看，Shadowsocks 的協定處理通常較直接。實際 CPU 消耗取決於加密方法、裝置硬體加速能力、並行數量與吞吐量規模。在一般桌面裝置上，協定本身很少成為日常瀏覽的主要瓶頸；在低功耗路由器、高速下載或大量並行連線的情境中，演算法實作與單核心效能才會逐漸顯現差異。如果測速時 CPU 已接近持續滿載，繼續切換策略群組通常無法提升吞吐量，應先減少變數並檢查裝置處理能力。

VMess 的身分與傳輸組合

VMess 源自 V2Ray 生態系，節點通常使用 UUID 作為使用者識別，並可與多種底層傳輸組合。它在訂閱中經常同時帶有 network、TLS、主機名稱、路徑或服務名稱等欄位。對使用者而言，VMess 的主要特色不是某個單一的速度結論，而是設定組合較豐富：同為 VMess，TCP、WebSocket 與 gRPC 方案的握手流程、連線多工方式及額外標頭成本都不同。

排除 VMess 節點問題時，需要由外到內逐項核對。先確認伺服器、連接埠與 UUID，再確認加密或安全欄位，接著檢查傳輸類型。如果使用 WebSocket，應核對路徑與 Host；如果搭配 TLS，應核對伺服器名稱、憑證驗證與 ALPN 等資訊；如果使用 gRPC，則需注意服務名稱及多工行為。訂閱轉換工具若遺漏其中任何一項，節點仍可能顯示在用戶端中，但連線會在握手階段失敗。

VMess 對系統時間較為敏感。裝置時間有明顯偏差時，身分驗證可能無法正常完成，因此當「同一份訂閱在一台裝置可用、另一台裝置全部逾時」時，系統時間與時區是成本很低、但值得優先檢查的項目。自動時間同步恢復後，應重新載入設定或重新啟動相關連線，避免舊連線狀態繼續干擾判斷。

兩者如何選擇

如果伺服器同時提供 SS 與 VMess，且兩者線路條件相近，SS 更適合作為低複雜度基準：欄位較少，遷移到不同核心時更容易找出問題。VMess 則適合已有成熟部署、需要特定傳輸組合，或訂閱生態已圍繞其參數組織的情況。選擇不應基於「欄位多所以更進階」或「欄位少所以一定更快」，而應觀察額外傳輸層是否解決明確需求，以及目前核心是否能正確表達這些設定。

在行動裝置上，連線數量與重新連線頻率通常比單次加密計算更影響使用感受。WebSocket 或 gRPC 組合可能引入額外握手與連線管理，但合理的連線多工也可能減少重複建立連線的次數。如果應用程式流量以短請求為主，應觀察首次請求與休眠恢復；如果以持續影音或下載為主，應觀察十分鐘以上的穩定吞吐量。單次延遲數字只能反映探測目標在某一時刻的狀態，無法涵蓋上述差異。

遷移設定時，SS 基礎欄位在 Clash 系核心之間通常具有良好的可攜性；VMess 的基礎欄位也相當成熟，但傳輸擴充的命名與巢狀結構更值得檢查。如果訂閱來自轉換服務，建議保留原始訂閱網址，並在轉換前後比對一個節點的伺服器、連接埠、UUID、網路類型、TLS、路徑與主機名稱，避免只根據節點顯示名稱判斷轉換是否完整。

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

上例展示 mihomo 設定中基礎 Shadowsocks 節點的欄位關係。範例網域與密碼需要替換為伺服器提供的實際資訊；udp: true 僅表示允許核心處理該節點的 UDP 流量，伺服器與網路路徑也必須具備相應能力。不要從其他節點複製密碼、連接埠或加密方法後只修改名稱，這種設定雖然能通過 YAML 語法解析，卻無法完成協定驗證。

03 · TLS-Oriented Choices

Trojan 與 VLESS：驗證層與傳輸層的取捨

Trojan 的連線結構

Trojan 通常將密碼驗證與 TLS 連線結合。用戶端首先需要完成 TLS 握手，再於加密連線中提交協定驗證資訊與目標位址。設定中除了伺服器、連接埠與密碼外，還經常出現 sni、憑證驗證、ALPN 與 UDP 支援等欄位。它的節點結構不算複雜，但 TLS 相關參數必須與伺服器憑證及入口設定一致，任何一處名稱不符都可能表現為握手失敗。

SNI 用於在 TLS 握手中指定目標伺服器名稱。訂閱提供網域作為伺服器位址時，核心通常可據此處理；若伺服器欄位是 IP 位址，而憑證簽發給某個網域，通常需要另外填寫伺服器名稱。關閉憑證驗證雖可能暫時繞過名稱或憑證鏈問題，卻會改變連線的身分驗證特性，不應作為長期排錯方法。較穩妥的做法是確認伺服器憑證、系統時間、SNI 與訂閱欄位是否一致。

Trojan 的效能包含兩個部分：首次 TLS 握手成本，以及建立連線後的資料傳輸成本。短連線很多時，重複握手對首個封包時間的影響更明顯；維持連線或合理使用多工時，這部分成本會被攤薄。TLS 實作通常經過廣泛最佳化，在現代桌面與手機處理器上擁有成熟的硬體與軟體支援，因此不能只憑「多一層 TLS」就判斷它一定較慢。線路延遲、伺服器負載與應用程式建立連線的模式往往更關鍵。

VLESS 將擴充交給外層

VLESS 同樣來自 V2Ray 相關生態系，但其協定層設計更輕量，通常使用 UUID 識別使用者，並將加密與安全能力交給 TLS、REALITY 或其他外層機制。對 Clash 使用者而言，VLESS 的關鍵不只是 type: vless，還包括網路傳輸、TLS 開關、伺服器名稱、流量控制欄位，以及可能出現的用戶端指紋等擴充。不同組合之間的相容邊界，比協定名稱本身更值得關注。

VLESS over TCP、VLESS over WebSocket 與 VLESS over gRPC 的連線行為並不相同。TCP 組合層次較少，排錯鏈路相對短；WebSocket 增加 HTTP 升級、路徑與主機欄位；gRPC 則依賴 HTTP/2 語意與服務名稱。如果再疊加 TLS 或其他安全層，設定欄位會繼續增加。訂閱轉換時必須維持這些欄位之間的對應關係，不能把傳輸類型改成 TCP 後，仍保留只屬於 WebSocket 的路徑，期待核心自動推論。

VLESS 的部分擴充由不同專案逐步實作。mihomo 支援常見的 VLESS 組合，但舊版 Clash 原始核心不具備同等能力，部分較早的 GUI 即使可以讀取 YAML，也可能在啟動核心時回報未知代理類型或未知欄位。因此，包含 VLESS 的訂閱較適合使用持續維護且明確採用 mihomo 的用戶端。本網站下載頁中，Clash Plus 與 Clash Verge Rev 都可作為桌面端優先考察的選項，具體平台入口可在下載頁選擇。

驗證成功不等於所有流量都正常

Trojan 或 VLESS 節點顯示可連線，只代表基礎探測可能已完成，不表示 TCP、UDP、IPv6 與所有應用程式協定都已驗證。測試時至少應涵蓋一般網頁、長連線應用程式、網域解析以及需要 UDP 的應用情境。如果只有部分應用程式失敗，應檢查規則比對、DNS、TUN 與 UDP 能力，而不是立即認定協定本身不可用。

連線建立後立即中斷時，常見的檢查順序是：系統時間、伺服器位址與連接埠、身分憑證、TLS 開關、SNI、憑證驗證、傳輸類型、路徑或服務名稱。VLESS 還需要核對 flow 等擴充欄位是否為伺服器要求，且核心是否支援。日誌中的「TLS handshake」「authentication」「unknown field」對應不同層次，排錯時應根據關鍵字定位，而不是反覆切換節點來掩蓋原始錯誤。

從選擇角度來看，Trojan 適合伺服器已圍繞標準 TLS 入口部署、參數相對固定的情況；VLESS 適合需要利用其傳輸與安全層組合，且用戶端核心明確支援相關擴充的情況。如果多台裝置共用訂閱，應先列出所有裝置的核心能力，再選擇共同支援的組合。桌面端可使用的較新擴充，不一定能被舊版行動用戶端或路由器外掛完整識別。

04 · QUIC Transport

Hysteria2 與 TUIC：面向變動網路的 UDP 方案

為什麼選擇 QUIC 與 UDP

Hysteria2 和 TUIC 都以 QUIC 作為重要基礎。QUIC 運作於 UDP 之上，在使用者空間完成加密連線、可靠傳輸、多重串流與壅塞控制。與傳統 TCP 連線相比，它可以減少部分傳輸層與安全層的往返，也避免多個邏輯串流完全共用同一個 TCP 隊頭阻塞狀態。對於延遲變化明顯、存在一定封包遺失或需要較高吞吐量的線路，這類設計提供更多調整空間。

但 UDP 並不是自動取得高效能的開關。QUIC 仍受實體頻寬、往返延遲、封包遺失、伺服器出口與裝置處理能力限制。部分路由器對長時間 UDP 工作階段的狀態維持時間較短，某些網路會限制 UDP 封包大小或速率，企業網路也可能只允許特定類型的 UDP 流量。出現週期性斷線時，應檢查 NAT 工作階段、MTU、路徑品質與網路切換，而不是只調整用戶端的測速目標。

Hysteria2 的頻寬與壅塞控制

Hysteria2 是 Hysteria 系列的後續協定，設定通常包含伺服器、連接埠、密碼、TLS 伺服器名稱，以及可選的頻寬或混淆相關參數。它強調在複雜線路上利用 QUIC 與壅塞控制維持傳輸效率。用戶端中的上行、下行頻寬設定不是電信方案數字的顯示項目，而是壅塞控制演算法的重要輸入；填寫遠高於實際可用能力的數值，可能造成傳送過快、排隊與封包遺失增加，最終反而降低穩定性。

頻寬參數應根據長期可用水準，而非瞬間峰值設定。可以先不填寫可選值，採用伺服器建議或核心預設行為；確實需要手動設定時，先以穩定時段的多次結果決定保守範圍，再分別觀察上行與下行。行動網路的上行能力通常波動更大，過高的上行估計會影響確認封包與互動流量。修改後至少測試網頁首個封包、持續下載、影片拖曳與裝置休眠恢復，不能只看短時間速度。

Hysteria2 使用 TLS 相關機制驗證伺服器，系統時間與伺服器名稱仍然重要。如果訂閱提供 SNI，應維持原值；如果節點使用 IP 位址連線，也不要因此刪除憑證對應的網域。遇到憑證錯誤時，應回到訂閱來源核對欄位。混淆密碼等擴充同樣需要與伺服器一致，單方面在用戶端啟用並不會建立可用連線。

TUIC 的工作階段與並行特性

TUIC 同樣基於 QUIC，節點常見欄位包括伺服器、連接埠、UUID、密碼、伺服器名稱、壅塞控制演算法與 UDP 轉發模式。其設計著重低延遲建立連線、多工與 UDP 流量承載。不同 TUIC 協定世代的欄位並不完全相同，訂閱來源、伺服器實作與用戶端核心需要採用相容格式。看到 tuic 類型後，仍應核對驗證欄位與版本語意，而不能只複製另一個節點的 UUID。

壅塞控制演算法決定傳送端如何根據確認、延遲與封包遺失調整速率。演算法名稱本身不存在脫離環境的優勝順序：較積極的策略可能在頻寬充足時快速提升吞吐量，也可能在共用網路或緩衝較深的線路上造成排隊；較保守的策略可能更平穩，但需要較長時間才能達到峰值。如果訂閱已提供伺服器建議，通常應先維持原值。只有在重複測試確認問題可重現後，才單獨修改該欄位。

TUIC 與 Hysteria2 都可能讓手機的無線模組維持更活躍的收發狀態，尤其是在大量並行、持續傳輸或頻繁保活時。另一方面，如果協定能更快完成傳輸並及時進入閒置狀態，整體耗電量也可能下降。因此，不能只按「基於 UDP」判斷耗電高低。應在相同亮度、相同應用程式任務與相近訊號強度下比較一段完整使用週期，並同時觀察背景重新連線次數。

建立可靠的失敗回退

如果訂閱同時提供 QUIC 類與 TCP 類節點，可以在策略群組中保留兩類候選。網路環境支援 UDP 時，優先實測 Hysteria2 或 TUIC；出現握手逾時、切換網路後無法恢復、路由設備負載過高時，回退到 SS、Trojan 或其他 TCP 傳輸節點。回退不是對協定降級的評價，而是讓連線方式適應目前的路徑。

排查 QUIC 類節點時，建議先關閉用戶端內不必要的並行測速，避免測試本身占滿頻寬。接著確認系統時間、UDP 可用性、伺服器位址與連接埠、驗證資訊、SNI 與憑證，再查看 MTU 或封包大小相關現象。如果小流量正常而大流量停頓，路徑 MTU、壅塞控制與路由設備的 UDP 狀態表值得重點檢查；如果一開始就無法握手，則更可能是 UDP 路徑、連接埠、驗證或 TLS 參數問題。

05 · Performance

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

把「速度」拆成四項指標

協定比較中的速度至少包含建立連線時間、首個封包時間、穩定吞吐量與故障恢復時間。建立連線時間受 DNS、TCP 或 QUIC 握手、TLS 與驗證步驟影響；首個封包時間還包含伺服器存取目標的耗時；穩定吞吐量取決於頻寬、壅塞控制、封包遺失恢復與裝置處理能力；故障恢復時間則反映網路切換或路徑變化後能否快速重新建立工作階段。只記錄一個延遲數字，會把這些差異壓縮成無法解釋的結果。

Clash 用戶端中的延遲測試通常會向指定 URL 發起探測，適合排除完全無法連線的節點與發現明顯異常，但不等同於應用程式的實際存取。探測目標所在位置、連線是否重用、DNS 結果與快取都會影響數字。選擇節點時，可以先用延遲測試縮小範圍，再以實際應用程式完成持續驗證。如果兩個節點的探測結果接近，不必反覆追求很小的數值差異，應更重視長連線穩定性與失敗率。

公平比較需要控制變數。盡量選擇同一服務商、同一地區、相近時間與相同目標，關閉背景更新與雲端同步，並讓每個候選完成一次預熱。每項測試重複多次，記錄中位表現與最差情況，而不是只保留最快結果。協定節點位於不同伺服器時，測得的主要差異可能來自線路與負載，不能歸因於協定設計。

CPU、記憶體與並行連線

Shadowsocks 的基礎封裝較輕，VMess、Trojan 與 VLESS 的具體成本取決於外層傳輸與 TLS，Hysteria2 和 TUIC 則需要在使用者空間處理 QUIC、加密、封包遺失恢復與壅塞控制。這個順序只能描述處理結構，不能直接轉化為固定的資源排名。成熟實作、硬體加速、封包大小與連線數量都會改變結果。某個協定在低速網頁瀏覽中差異很小，在高速轉發或數千條連線下卻可能暴露單核心瓶頸。

記憶體用量通常會隨連線表、DNS 快取、規則集、日誌與 TUN 狀態增加。大型規則集與複雜 DNS 設定可能比節點協定本身占用更多記憶體。如果用戶端執行一段時間後資源持續上升，應區分是活動連線未釋放、日誌層級過高、規則提供者更新，還是核心異常。只切換協定節點無法解決規則與日誌造成的資源問題。

路由器與小型伺服器更需要關注並行數量與架構。Mihomo 核心本身需要與裝置 CPU 架構相符；高吞吐量 QUIC 在較弱的 CPU 上可能更早達到處理上限。此時可降低並行測試數量、選擇處理成本較低的節點、縮減日誌，並確認系統軟體中斷與 NAT 處理沒有成為瓶頸。本網站下載頁的 Linux 與核心區用於區分桌面 GUI 與面向伺服器、路由器的核心檔案，一般桌面使用者通常不需要手動管理獨立核心。

行動裝置電量取決於工作週期

手機耗電不能只看用戶端程序瞬間的 CPU 使用率。代理連線會影響無線模組喚醒、背景保活、DNS 請求、連線重試與系統 VPN 介面。訊號較弱時，裝置發射功率與重傳成本都會上升；如果協定頻繁重新連線，即使每次計算量很少，也可能增加整段時間的耗電。反過來，能穩定維持工作階段並快速完成資料傳輸的方案，可能更早進入閒置狀態。

比較行動裝置電量時，應固定螢幕亮度、網路類型、應用程式任務與測試時間。可以分別執行三類任務：持續半小時的網頁與訊息混合使用、傳輸固定大小的檔案、鎖定螢幕後的背景通知與恢復。記錄系統電量變化、裝置溫度與斷線次數。一次短時間測速無法呈現背景行為，整天混合使用又容易受到相機、定位與螢幕活動干擾，分階段測試更容易找出原因。

TUN 模式通常涵蓋更多應用程式流量，也會讓核心持續參與路由與 DNS 處理；系統代理只影響遵循代理設定的應用程式，資源範圍相對有限。比較協定時應維持代理模式一致，否則得到的是 TUN 與系統代理的差異，而非協定差異。Android 與 iOS 的背景管理機制不同，同一用戶端在兩個平台上的結果也不應直接互相比照。

最終選擇應以穩定區間為依據。某個節點偶爾達到很高峰值，但經常出現停頓，未必適合會議、同步與長連線應用；另一個節點峰值稍低卻能維持連續傳輸，通常更適合作為預設策略。可以把前者放入下載或大流量策略群組，把後者用於日常預設群組，透過規則分流讓協定特性服務於具體任務。

06 · Kernel Family

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

原版 Clash 奠定設定模型

原版 Clash 建立了後來廣泛使用的設定模型：代理節點放在 proxies，策略群組放在 proxy-groups，規則依序放在 rules，並透過系統代理、透明代理或其他入口接收流量。規則命中後，再將連線交給策略群組或指定出口。許多訂閱與教學至今仍沿用這套基本術語，因此理解原版設定結構仍然有價值。

原版專案的維護狀態已經改變，其協定集合與擴充能力不能代表目前的 mihomo 生態系。它適合用來理解基礎相容層，但不應被視為較新節點類型的能力基準。包含 Hysteria2、TUIC、VLESS 擴充、複雜 DNS 或規則提供者選項的設定，通常需要 mihomo 系核心。舊版用戶端若固定綁定原版核心，可能無法識別這些欄位。

Clash.Meta 擴充協定與網路能力

Clash.Meta 在原有設定模型上增加協定、傳輸、DNS、TUN、嗅探與規則相關能力。它盡量維持常用 Clash 設定的遷移路徑，同時引入新的節點類型與欄位。對使用者最直接的變化是，同一份訂閱可以包含更豐富的協定組合，用戶端也能提供更完整的透明代理與 DNS 控制。

擴充相容性並不代表所有原版設定都會產生完全相同的執行結果。DNS 預設值、規則集行為、TUN 堆疊、嗅探與連線處理可能因設定與實作更新而變化。遷移時應先保留原設定副本，使用核心的設定檢查功能確認語法，再依序驗證節點、策略群組、規則、DNS 與 TUN。一次開啟所有擴充會讓問題來源難以判斷。

mihomo 是目前沿用的名稱

mihomo 是 Clash.Meta 後續採用的專案名稱。實際資料中仍可能同時出現「Meta core」、「Clash.Meta」與「mihomo」，這些名稱反映專案歷史與用戶端介面中的不同命名，不應簡單理解為三個互不相關的核心。目前用戶端若標示使用 mihomo，通常代表延續 Meta 系列的協定與設定能力，但具體支援範圍仍需以用戶端隨附的核心與設定說明為準。

GUI 用戶端與核心的更新節奏可能不同。用戶端介面新增某項設定，需要底層核心提供對應參數；核心支援的新欄位，也可能尚未被 GUI 製作成可操作的控制項。多數情況下，訂閱節點由核心直接讀取，因此重要的是確認用戶端實際呼叫哪個核心，而不是只看產品名稱中是否含有 Clash。Clash Plus、Clash Verge Rev、FlClash 與 Clash Nyanpasu 等用戶端的定位與平台涵蓋範圍，可在用戶端比較頁繼續查看。

設定相容性需要分層判斷

第一層是 YAML 語法相容性。縮排、清單與鍵值結構正確，設定才可能被解析。第二層是欄位識別，核心需要知道 type、傳輸與擴充欄位的含義。第三層是語意相容性，也就是欄位雖然存在，但預設值或組合限制是否相同。第四層是執行環境相容性，例如 TUN 權限、系統代理介面、網路擴充與防火牆規則。只通過語法檢查，不能證明後面三層都正常。

基礎 SS、VMess、Trojan 節點與一般策略群組通常具有良好的遷移基礎；VLESS、Hysteria2、TUIC、REALITY、複雜 DNS 與 TUN 選項則更依賴 mihomo 能力。如果設定需要同時服務多個用戶端，可以維護一個公共基礎層，只放入共同支援的節點、策略群組與規則，再為桌面、行動裝置與路由設備分別加入本機覆寫。這比把所有平台選項塞進單一 YAML 更容易維護。

從 Clash for Windows 遷移時，還要區分 GUI 設定與設定檔內容。視窗行為、開機啟動、系統代理連接埠與更新設定可能儲存在應用程式本機，不會隨訂閱遷移；節點、策略群組與規則通常來自設定。可參考Clash for Windows 停止更新後的遷移方案逐項整理，而不是只複製應用程式目錄。

mihomo -t -f config.yaml

上面的命令用於讓獨立 mihomo 核心檢查設定檔。不同用戶端可能將核心封裝在應用程式內部，不需要使用者直接執行命令；如果使用下載頁提供的獨立核心，應在終端機進入檔案所在目錄，並將 config.yaml 替換為實際設定路徑。檢查通過表示語法與已知欄位可被讀取，仍需啟動後測試連接埠、DNS、規則與節點連線。

07 · Subscription

訂閱格式、欄位轉換與相容邊界

訂閱連結不等於統一檔案格式

使用者通常把一個遠端位址統稱為「訂閱」，但該位址回傳的內容可能是 Clash YAML、URI 清單、Base64 封裝文字，或面向特定用戶端的 JSON。用戶端能否直接匯入，取決於它是否能識別回傳格式，或是否內建轉換流程。HTTP 請求成功只代表檔案已下載，不代表節點欄位已正確解析。

Clash YAML 通常可以同時描述連接埠、DNS、節點、策略群組、規則與規則提供者，適合完整設定分發。URI 清單則更著重逐一列出節點，每種協定使用自己的連結結構，複雜傳輸欄位可能透過查詢參數表達。用戶端將 URI 清單轉換為 Clash 設定時，需要產生節點物件並將其放入策略群組；如果轉換器不了解較新的欄位，可能出現節點遺失、參數遺漏或類型降級。

匯入後檢查四個層次

第一步檢查設定是否成功更新，並記錄更新時間與來源名稱。更新失敗時，先查看 HTTP 狀態、憑證、網路與連結有效性，不要立即刪除原有設定。第二步檢查節點數量與類型，確認 SS、VMess、Trojan、VLESS、Hysteria2 與 TUIC 等預期類型是否存在。第三步抽查欄位完整性，尤其是伺服器名稱、TLS、傳輸路徑、UUID、密碼與 UDP 選項。第四步確認策略群組引用的節點名稱仍然存在，避免節點已匯入卻沒有加入任何可選群組。

節點顯示名稱不是可靠的唯一識別。訂閱更新可能修改名稱、加入地區前綴或調整排序，手動撰寫的策略群組若依舊名稱引用，更新後就會出現找不到代理的錯誤。使用正規表示式篩選或代理提供者時，也要確保運算式不會意外排除新節點。需要長期固定選擇時，建議使用清楚的策略群組與自動篩選條件，而不是依賴清單位置。

訂閱轉換最常遺漏的是巢狀傳輸參數。VMess 或 VLESS 的 WebSocket 路徑、Host、gRPC 服務名稱，Trojan 的 SNI，Hysteria2 的驗證與 TLS 參數，TUIC 的壅塞控制與驗證欄位都需要保留。轉換後若基礎節點可用而某一類全部失敗，應優先比對該類節點的原始欄位與產生的 YAML，而不是修改全域 DNS。

設定合併需要明確的覆寫規則

部分用戶端支援在遠端訂閱上疊加本機覆寫，例如加入自訂規則、修改 DNS 或建立策略群組。合併機制可能採用鍵值覆蓋、清單追加、腳本處理或範本產生，不同用戶端的順序並不一致。覆寫前應確認是「遠端值覆蓋本機值」還是「本機值最後生效」，尤其要注意 rules 與 proxy-groups 這類清單。錯誤的追加順序可能讓兜底規則提前命中，後續規則完全沒有執行機會。

規則會由上而下比對，命中後停止繼續檢查。如果本機設定把 MATCH 或同等的兜底規則放在前面，遠端規則即使成功合併也不會生效。策略群組則需要確保名稱唯一且引用關係完整，循環引用會導致設定失敗。DNS 覆寫還可能影響節點伺服器網域的解析路徑，因此修改 nameserver、fake-ip 或代理伺服器解析設定後，應同時測試節點網域能否正常解析。

訂閱安全與維護習慣

訂閱位址通常包含用於識別帳戶或設定的隨機路徑，應視為敏感設定，不要發佈在公開頁面、截圖或日誌中。排錯時可以展示節點類型與已去識別化的欄位，但應隱藏完整訂閱位址、密碼與 UUID。將設定傳給他人協助檢查前，應先複製一份並替換驗證資訊，避免直接編輯正在使用的原始檔案。

更新訂閱前保留最近可用的設定，有助於區分「遠端內容變化」與「本機用戶端變化」。如果更新後所有節點消失，可以切回舊設定驗證；如果舊設定也失敗，再檢查網路、系統時間與伺服器狀態。用戶端升級與訂閱更新盡量不要同時進行，否則出現問題時，很難確認變化來自核心還是遠端設定。

多台裝置使用同一份訂閱時，建議將節點資訊與平台設定分離。訂閱負責節點與通用策略，本機用戶端負責系統代理、TUN 權限、啟動行為與平台 DNS。iOS、Android、Windows、macOS 與 Linux 的系統介面不同，將某個平台的路徑、網卡名稱或權限欄位寫入共用設定會降低可攜性。需要選擇平台用戶端時，可從下載頁進入對應標籤，其中 Clash Plus 作為全平台優先選擇，其他用戶端則依系統與設定需求補充。

如果匯入、更新或策略群組引用仍然異常，可以前往常見問題，依安裝設定與故障排除分類繼續定位。需要逐段閱讀設定結構時，可參考Clash 設定檔結構解析，先理解連接埠、節點、策略群組與規則之間的引用，再處理用戶端特有的覆寫功能。

08 · Scenario Guide

依裝置與使用情境完成協定選擇

桌面日常使用：優先建立穩定基準

Windows 與 macOS 桌面裝置適合先建立一個長期穩定的預設策略群組。如果伺服器提供 Shadowsocks、Trojan 或成熟的 VMess 節點，可以從欄位完整、連線穩定的一類開始；VLESS、Hysteria2 與 TUIC 則作為確認支援後的候選。預設群組不需要包含所有節點，數量過多會增加選擇成本，也會讓自動測試頻繁建立連線。可以按協定或用途拆分策略群組，再由上層群組進行選擇。

在用戶端方面，Clash Plus 可作為全平台首選，Clash Verge Rev 適合需要桌面端規則、訂閱與 mihomo 設定介面的使用者。從舊用戶端遷移時，先匯入訂閱與基礎規則，不要立即複製所有應用程式設定。確認系統代理連接埠、DNS 與節點可用後，再依需要啟用 TUN。這樣可以將系統權限問題與協定連線問題分開。

辦公、會議與即時通訊更重視連續性。應選擇長連線穩定、網路恢復可靠的節點，而不是峰值最高的節點。大型檔案下載或同步可以放入獨立策略群組，允許選擇吞吐量較高、但資源用量也可能更明顯的 Hysteria2、TUIC 或其他節點。透過規則將不同應用程式分配到不同策略，比頻繁手動切換全域節點更容易控制。

手機與平板：先看切換網路與背景恢復

行動端首要測試項目是 Wi-Fi 與行動網路切換、鎖定螢幕後恢復、弱訊號下重新連線與系統 VPN 穩定性。協定在固定 Wi-Fi 下速度很高，但切換網路後需要手動重新連線，就不適合作為預設行動節點。SS、Trojan 等成熟組合可以作為基準；Hysteria2 與 TUIC 若在實際行動網路中能保持穩定，則可用於對吞吐量與恢復能力有要求的任務。

電量比較至少應涵蓋一個完整工作週期，並維持代理模式一致。節點探測間隔過短、策略群組自動測試過於頻繁、日誌持續寫入與大量背景應用程式流量，都可能放大耗電。應先降低自動測試頻率並關閉不必要的除錯日誌，再比較協定。否則得到的結論主要反映用戶端設定，而不是節點類型。

iOS 與 Android 的背景策略不同，用戶端可用功能也不同。不要把桌面端 YAML 中所有 TUN、網卡與腳本參數直接複製到行動端。訂閱只保留節點與共同支援的策略，平台權限與 DNS 由行動用戶端在本機管理。iOS 使用者可以在下載頁選擇 Clash Plus 的 App Store 入口；Android 還可依介面偏好與設定相容性比較 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard。

路由器與常駐裝置：優先考量資源與可維護性

路由器、家用伺服器與小型 Linux 裝置需要先確認 CPU 架構、記憶體、儲存空間與系統服務管理方式。獨立 mihomo 核心適合熟悉命令列、設定檔與服務日誌的使用者；一般桌面使用者則更適合 GUI 用戶端。在低功耗裝置上，規則集規模、連線並行數量與 DNS 快取可能比是否有 GUI 更影響資源使用。

協定選擇應以裝置能持續處理的吞吐量為上限。Hysteria2 或 TUIC 在線路條件合適時可能提供良好的傳輸表現，但使用者空間 QUIC 處理會占用 CPU；如果裝置處理能力不足，SS 或其他較輕量的組合反而更穩定。可以在傳輸過程中查看 CPU 單核心使用率、軟體中斷與記憶體，確認瓶頸位於裝置、線路還是伺服器。

常駐裝置更需要可回退的設定。保留一份經過驗證的基礎 YAML，並將實驗性協定放入獨立策略群組。更新核心前先執行設定檢查，更新後依序驗證 DNS、節點、規則與區域網路存取。不要同時更新核心、訂閱、規則集與系統網路元件。分批變更看似耗時，實際上能大幅縮短故障定位時間。

一套可重複執行的決策流程

第一步，列出訂閱實際提供的協定與目前用戶端核心，不要在用戶端中自行猜測或轉換節點。第二步，依網路路徑分組：TCP 類節點作為基礎候選，Hysteria2 與 TUIC 歸入需要驗證 UDP 的候選。第三步，檢查協定所需欄位是否完整，尤其是 TLS、SNI、UUID、密碼、傳輸路徑與服務名稱。第四步，以固定目標測試建立連線、持續吞吐量、切換網路後恢復與資源用量。

第五步，依裝置選擇預設節點。桌面端優先考量穩定性與長時間執行；行動端優先考量背景恢復與電量；路由設備優先考量資源上限與服務管理。第六步，將具有明顯優勢但適用範圍較窄的節點放入專用策略群組，例如下載、串流影音或大流量同步。第七步，記錄目前可用的設定與測試條件，以便訂閱或核心變更後重新比對。

如果結果差異很小，應選擇欄位更清楚、多台裝置都支援且維護成本較低的方案。協定選型的目標不是找出理論上最複雜的組合，而是在現有伺服器、網路與裝置條件下，取得可解釋、可恢復、可遷移的連線。一個能穩定運作且容易排錯的設定，通常比依賴大量特定擴充的設定更適合作為長期基準。

完成選型後，可以返回Clash Verge Rev 教學，依步驟匯入訂閱、選擇規則模式並驗證連線；需要進一步調整規則順序時，可閱讀Clash 流量分流設定與策略群組實戰。如果用戶端仍回報設定錯誤，應先保存原始日誌中的第一筆錯誤資訊，再到常見問題頁，依設定解析、建立連線、DNS 與系統代理四個方向排查。