Clash 協定與核心技術參考

01 / DECISION MODEL

先把協定選擇拆成四個問題

協定名稱不等於實際體驗

在 Clash 用戶端裡看到 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC，第一反應通常是比較誰「更新」、誰「更快」。這個順序經常會帶偏判斷。協定只規定雙方如何建立工作階段、封裝資料、完成驗證與處理傳輸；實際體驗還會受到伺服器出口、使用者到伺服器的連線、節點負載、壅塞控制、用戶端核心與目標網站路徑影響。一個路由較短、負載較低、參數合理的傳統協定節點，完全可能比設定粗糙的新協定節點更穩定。協定只是其中一項變數，不是單獨決定結果的標籤。

更可靠的拆解方式是問四個問題。第一，底層使用 TCP 還是 UDP，是否適合目前網路的丟包與抖動。第二，用戶端核心能否完整辨識該協定及其附加參數。第三，裝置是否需要長時間在背景執行，CPU 喚醒、持續收發與連線遷移的成本能否接受。第四，訂閱提供者是否提供相符的伺服器實作與參數。四項中任何一項不成立，紙面上的優勢都無法落實到真實連線。

傳輸層決定問題的樣貌

SS、VMess、Trojan 與 VLESS 的常見部署大多以 TCP 為基礎，也可能再搭配 TLS、WebSocket、gRPC 或其他承載方式。TCP 具備可靠傳輸、依序交付與壅塞控制，適合網頁、下載、程式碼託管等多數服務。代價是當內層應用本身也使用 TCP 時，連線丟包可能觸發多層重傳與隊頭阻塞。這不能簡單歸結為「TCP 套 TCP 一定很慢」；實際代理實作通常轉送位元組串流，不一定機械式嵌套兩個完整 TCP 狀態機，但在長肥網路與高丟包環境下，恢復速度確實可能受限。

Hysteria2 與 TUIC 使用 UDP，並透過 QUIC 或相近設計提供可靠串流、多路複用與加密。優勢主要出現在高延遲、存在隨機丟包，或 TCP 壅塞控制恢復較慢的連線上。反面也很明確：部分網路會限制 UDP，路由設備的 UDP 工作階段保持時間可能較短，行動網路切換後也要看實作能否順利遷移連線。所謂「UDP 協定更快」，應改理解為「在 UDP 可用且連線特徵相符時，更有機會維持吞吐量」。

節點、協定、傳輸與核心是四個層次

節點是可連線的伺服器實例；協定定義驗證與資料封裝；傳輸層或承載方式決定資料經由 TCP、UDP、TLS、WebSocket 等哪條路徑；核心則負責把訂閱欄位轉換成實際連線。用戶端介面只把這些層壓縮成一個節點名稱，很容易讓人把「某個節點連不上」誤判為「整個協定都不行」。排查時應先更換同協定的另一個節點，再更換同一節點群組中的另一種協定，最後檢查用戶端核心與訂閱欄位。一次只修改一個變數，結論才有意義。

例如 VLESS 節點可能同時包含 TLS、流量控制、伺服器名稱與傳輸類型；刪除其中一個欄位後，協定名稱仍顯示為 VLESS，但交握行為已經不同。Hysteria2 的驗證、伺服器名稱、跳埠範圍與頻寬提示也都屬於具體實作參數。只看節點名稱中的「高速」「專線」等文字沒有技術價值，應開啟設定查看實際欄位，或在用戶端的節點詳細資訊中確認協定類型。

測試要固定目標與時間區間

比較協定時，至少應固定節點地區、測試目標、用戶端模式與時間區間。先用用戶端的延遲測試進行可達性初篩，再透過實際網頁、持續下載、影片拖曳與網路切換觀察體驗。延遲數字通常只是測試網址的一次交握路徑，不代表頻寬；詳細原理可參考《Clash 延遲測試數字怎麼來的》。同一節點連續測試三至五次，記錄波動範圍，比盯著一次最低值更有效。

最終選擇也不必固定為單一協定。訂閱中可以保留一組日常穩定節點、一組高丟包環境的備用節點，再交給 url-test 或手動選擇群組管理。規則負責決定流量前往哪一組，協定則負責這一組內的節點如何傳輸，兩者分工不同。理解這層關係後，協定選型就從「站隊」變成可驗證的工程問題。

02 / TCP FAMILY

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

Shadowsocks：結構簡單，部署成熟

Shadowsocks 通常簡稱 SS。核心思路是使用預先共用的金鑰完成加密代理，協定結構相對精簡，伺服器與用戶端實作眾多，資源需求也容易控制。對一般網頁、下載與長時間背景連線而言，SS 的優勢不是誇張的峰值，而是元件少、參數範圍較小、部署經驗充足。節點資訊通常包含伺服器、連接埠、密碼與加密方法；現代實作應使用目前用戶端與伺服器共同支援的 AEAD 類加密方法，舊式串流加密設定不適合繼續作為新部署基準。

SS 的簡潔也代表它不負責解決所有傳輸問題。實際連線是否疊加外掛、是否支援 UDP、伺服器是否正確啟用 UDP 轉送，都取決於部署方式。訂閱中同為 SS 的兩個節點，可能因加密方法、外掛與伺服器實作不同而有明顯差異。匯入 Clash 後若 TCP 網頁正常、語音或遊戲異常，應先檢查節點的 UDP 支援與用戶端 TUN 設定，而不是直接更換 DNS。

VMess：功能完整，但欄位組合較多

VMess 是 V2Ray 生態系中廣泛使用的協定，包含使用者識別、驗證與時間相關檢查，常與 TCP、WebSocket、HTTP/2 風格承載或 TLS 組合。它的歷史價值在於將多種傳輸組合納入統一設定體系，許多訂閱服務仍保留大量 VMess 節點。代價是參數較多：使用者 ID、alterId、加密欄位、傳輸類型、路徑、Host、TLS、伺服器名稱等，任何一項不相符都可能導致交握失敗。

舊教學經常把某些歷史欄位當成固定要求，但現代伺服器可能已採用不同的預設值。處理 VMess 最穩妥的方式不是手動猜參數，而是使用伺服器產生的完整訂閱，並確認轉換過程沒有遺失 network、ws-opts、servername 等欄位。若訂閱在某個用戶端可用，轉成 Clash YAML 後卻失效，應優先懷疑轉換器的欄位映射，而不是協定本身。

Trojan：以 TLS 工作階段為基礎的簡潔驗證

Trojan 通常運作於 TLS 之上，透過密碼完成用戶端驗證。它借助成熟的 TLS 函式庫保護傳輸，設定重點在憑證網域、伺服器名稱、連接埠與密碼。相較於含有大量自訂傳輸欄位的設定，標準 Trojan 節點更容易理解；但「使用 TLS」不代表可以忽略憑證驗證。用戶端設定中的 sni 或 servername 必須與伺服器憑證及部署相符，系統時間明顯錯誤也可能使交握失敗。

部分訂閱會設定略過憑證驗證。這個選項適合用來定位憑證鏈問題，不適合作為長期預設。若啟用後才能連線，應回頭檢查憑證名稱、伺服器憑證鏈與系統時間，找出根本原因。Trojan 也可能搭配 gRPC 或 WebSocket，組合後同樣會增加路徑、服務名稱等欄位。不要把「Trojan」理解為只有一種固定封裝形式。

VLESS：輕量驗證框架，能力來自組合

VLESS 採用較輕量的協定層設計，將加密與傳輸安全更多交由 TLS 等外層機制處理。它本身不是「開啟就自動更快」的開關，實際能力來自 TLS、Reality 類安全層、流量控制與具體傳輸方式的組合。對 Clash 使用者而言，重點不是背熟組合名稱，而是確認目前 mihomo 是否支援訂閱提供的所有欄位，並避免手動精簡 YAML 時刪除 flow、reality-opts、client-fingerprint 或伺服器名稱。

VLESS 設定常見的問題是「辨識了協定名稱，卻沒有辨識附加能力」。部分舊核心能讀取基本 VLESS，卻無法處理較新的安全層或指紋欄位；介面仍可能顯示節點，點擊後才回報錯誤。因此相容性判斷不能停留在匯入成功，至少要完成連線、DNS 請求與實際 HTTPS 存取。使用持續維護的 mihomo 核心，通常比在舊版 Clash 的設定語法上反覆刪除欄位更省事。

四者之間沒有通用冠軍

在低丟包、路由穩定的有線或 Wi-Fi 環境中，這四類以 TCP 為基礎的常見方案都可能提供相近的網頁體驗。差異更常出現在首次交握、連線複用、伺服器負載與複雜欄位的容錯能力。SS 的設定面較小，故障點較少；VMess 的既有節點多，但轉換時需要保留完整欄位；Trojan 的重點是憑證鏈；VLESS 的組合能力強，也更依賴新核心。

如果訂閱同時提供四類節點，先依節點線路按相同地區分組，再比較穩定性。不要拿一個高負載 SS 節點和一個低負載 VLESS 節點來得出協定結論，也不要為了追求名稱更新而刪除穩定節點。用戶端選擇方面，Windows 使用者可優先使用下載頁首推的 Clash Plus，或選擇 Clash Verge Rev、FlClash、Clash Nyanpasu；這些圖形用戶端的底層能力仍取決於整合的核心與設定更新狀況。

03 / UDP TRANSPORT

Hysteria2 與 TUIC：高丟包連線如何選擇

為什麼兩者都著重 UDP

傳統 TCP 在穩定網路中運作良好，但面對較高往返時間、隨機丟包與頻寬快速變化時，壅塞視窗恢復可能較為保守。Hysteria2 與 TUIC 都選擇在 UDP 上建立加密、可靠傳輸與多路複用，讓應用串流不必完全受單一 TCP 位元組串流的隊頭阻塞限制。它們並非捨棄可靠性，而是將可靠傳輸交由 QUIC 或協定本身的工作階段層處理。

這類設計特別適合「連線仍有可用頻寬，但 TCP 因丟包而持續降速」的情況。多個網頁請求、影片分片與 DNS 查詢可以在同一連線中分成獨立串流，某個串流的丟包恢復不必阻塞其他串流。建立連線通常也能減少額外往返。不過，底層 UDP 必須能穩定通過本地網路、路由器、電信網路與伺服器防火牆；任何一個環節限制 UDP 或縮短工作階段保持時間，優勢都可能變成頻繁重新連線。

Hysteria2：以吞吐量為導向，但頻寬參數不是測速結果

Hysteria2 的設計重點之一，是高吞吐量連線下的壅塞控制與可靠傳輸。設定中可能出現上行與下行頻寬提示，用於協助壅塞控制理解連線能力，不代表用戶端承諾達到相應速度。若數值遠高於真實線路，可能造成過量傳送、排隊與抖動；設定過低則會主動壓低吞吐量。若訂閱已提供參數，應先保留伺服器建議值；只有在持續測試確認佇列積壓或速度受限後再調整。

Hysteria2 還涉及驗證字串、TLS 伺服器名稱、憑證驗證與可選的跳埠功能。跳埠需要伺服器、防火牆與用戶端同時設定，單獨在用戶端填入一段連接埠範圍不會自動生效。排查連線時應先固定單一連接埠，確認基礎連線成立後，再恢復附加功能。行動網路下若單一連接埠可用而跳埠不穩定，通常需要檢查路由設備與網路對 UDP 映射的處理方式。

TUIC：QUIC 工作階段、並行串流與連線遷移

TUIC 同樣以 UDP 與 QUIC 思路為基礎，常見設定包括使用者識別、密碼、伺服器名稱、壅塞控制演算法、UDP 中繼模式與連線保持參數。它適合承載並行連線，也能運用 QUIC 管理串流與工作階段。對手機而言，連線遷移值得關注：Wi-Fi 切換至行動網路時，若用戶端、核心與伺服器實作配合良好，既有工作階段可能比重新建立多條 TCP 連線更快恢復。

但連線遷移並非在所有情況下都能自動成功。裝置休眠、系統回收背景網路權限、NAT 映射變更與 VPN 介面重建，都可能使原有工作階段失效。實際測試應包含鎖定螢幕後恢復、Wi-Fi 與行動網路切換、弱訊號區短暫斷線，而不只是桌面上連續執行一次下載。TUIC 的壅塞控制選項也不宜直接照搬他人設定；伺服器支援、連線特徵與實作版本需要相互一致。

UDP 無法連通時，症狀通常比 TCP 更直接

典型症狀包括節點延遲測試逾時、連線剛建立就中斷、短時間可用後速度下降、切換網路後長時間無法恢復。先確認同一網路下其他 UDP 應用是否正常，再檢查路由器防火牆、伺服器連接埠、用戶端 TUN 與訂閱欄位。若換到另一個 Wi-Fi 後立即正常，問題較可能出在本地網路路徑；若所有網路都失敗，則回頭檢查伺服器監聽、憑證名稱與驗證欄位。

還要區分「協定連線使用 UDP」與「代理 UDP 應用流量」。Hysteria2、TUIC 的底層工作階段本身依賴 UDP，但用戶端是否正確接管遊戲、語音或 QUIC 網站流量，還取決於 TUN 模式、系統 VPN 介面、規則與 UDP 轉送能力。網頁能開啟，只代表部分 TCP 應用流量成功通過，不足以證明 UDP 應用連線完整。

選擇順序：先測可達性，再測持續負載

實際選擇可以分三輪。第一輪測試連線建立、DNS 與一般 HTTPS；第二輪持續傳輸數分鐘，觀察吞吐量是否突然歸零、是否頻繁重新連線；第三輪模擬真實裝置行為，包括鎖定螢幕、切換網路、弱訊號與同時開啟多個應用程式。Hysteria2 在高丟包長距離連線上通常有明顯吞吐量優勢，TUIC 在多串流與工作階段管理方面具吸引力，但兩者的優劣無法脫離伺服器實作與本地網路單獨判斷。

proxies:
  - name: HY2-Example
    type: hysteria2
    server: example.invalid
    port: 443
    password: "your-password"
    sni: example.invalid
    skip-cert-verify: false

proxy-groups:
  - name: UDP-Fallback
    type: select
    proxies:
      - HY2-Example
      - DIRECT

上方片段只展示 mihomo 常見的欄位結構，網域與驗證值都是明確的示例值。實際設定應由伺服器提供。若目前訂閱沒有 Hysteria2 或 TUIC 節點，不應只修改 type 強行轉換：協定必須由伺服器與用戶端成對支援，修改節點類型不會把伺服器變成另一種協定。

04 / PERFORMANCE

連線速度、吞吐量與資源占用要分開測量

「快」至少包含四個指標

用戶端中的延遲只是第一項指標。完整的效能判斷至少包括連線建立時間、首位元組時間、持續吞吐量與抖動。連線建立時間受 DNS、TCP 或 QUIC 交握、TLS 與協定驗證影響；首位元組時間還會加上目標網站處理時間；持續吞吐量取決於壅塞控制、丟包、伺服器出口與 CPU；抖動則決定語音、遊戲與即時互動是否順暢。一個節點可能延遲低但吞吐量差，也可能首次開啟稍慢但持續下載穩定。

多路複用也不是越多越好。它可以減少重複交握，讓多個邏輯連線共用底層工作階段；但若所有串流都塞進單一不穩定連線，底層工作階段發生壅塞或重設時，影響範圍會擴大。對網頁瀏覽而言，多路複用通常能降低大量短連線的成本；對長時間大流量傳輸，則要觀察單一工作階段是否形成瓶頸。協定實作、用戶端核心與伺服器參數必須一起評估。

交握成本與連線複用

SS 的基礎交握較精簡，標準設定的 CPU 與往返成本容易預測。Trojan 依賴 TLS，首次連線需要完成 TLS 流程，但後續是否複用會顯著影響實際成本。VMess 與 VLESS 的表現取決於外層傳輸；WebSocket、TLS、gRPC 等組合都會帶來各自的交握與封裝成本。Hysteria2、TUIC 借助以 UDP 為基礎的工作階段與多串流能力，可能減少並行短連線反覆建立連線的次數，但初次憑證驗證與 QUIC 工作階段仍有成本。

因此不能只按協定標頭大小排序真實速度。網頁存取通常由數十個並行資源組成，連線池與複用策略的影響可能大於單一封包增加的少量位元組。反過來，在效能較低的路由器上，高並發加密、使用者空間網路堆疊與複雜規則比對會占用 CPU，理論吞吐量尚未達到網卡上限，處理器就可能先滿載。

CPU、記憶體與規則規模

資源占用主要來自加密、資料複製、網路堆疊、DNS 快取、規則集與連線狀態。協定差異會影響加密與工作階段處理，但設定規模同樣關鍵。載入多個大型規則集、啟用 TUN、開啟流量嗅探、保存大量連線記錄，都可能讓記憶體占用高於只執行基礎系統代理的設定。判斷「某協定占用更多記憶體」前，應保持規則集、DNS、日誌層級與執行模式一致。

在桌面裝置上，幾種協定的資源差異通常不如伺服器線路差異明顯；在低功耗路由器與舊手機上，差異則會被放大。Hysteria2 與 TUIC 的使用者空間可靠傳輸、計時器與持續 UDP 工作階段可能增加 CPU 喚醒；複雜的 VLESS 組合也可能引入額外 TLS 與傳輸處理。SS 的簡單結構通常適合資源受限裝置，但前提是服務品質符合需求。

測速順序決定結論是否可信

第一步清除變數：固定用戶端、核心、DNS 模式、規則與目標，只切換節點。第二步進行可達性測試，淘汰交握失敗與波動極大的節點。第三步在相近地區、相近線路中比較協定。第四步在日常時段重複測試，避免只在網路閒置時得出結論。最後才觀察裝置溫度、CPU 與電量。協定測試需要多輪，而不是一次點擊全部延遲後選擇最小數字。

下載測試也應避免同時觸發多執行緒、系統更新與雲端硬碟同步。若瀏覽器使用 HTTP/3，目標流量本身可能經由 UDP；若用戶端沒有完整接管 UDP，結果會與一般 HTTPS 不同。為了比較代理協定，可以同時準備一個明確使用 TCP 的測試目標，以及一個真實影片或即時應用情境。工具輸出只是切片，真實任務才是最終判斷。

日誌只開到足以定位問題的程度

排查連線時可暫時將日誌層級提高到 debug，確認失敗發生在 DNS、規則比對、代理交握還是目標連線。長期保持高日誌層級會增加磁碟寫入、介面更新與 CPU 喚醒，尤其不適合手機與路由器。問題定位後應恢復為 info 或用戶端建議的層級。若日誌出現憑證名稱、驗證失敗或 UDP 逾時，應依對應層次處理，不要一次重設所有設定。

log-level: info
mode: rule

profile:
  store-selected: true
  store-fake-ip: true

unified-delay: true
tcp-concurrent: true

unified-delay 用於讓延遲測試的口徑更接近統一連線流程，tcp-concurrent 可並行嘗試解析出的位址，以縮短部分連線等待時間。它們不是協定加速器，也不會修復伺服器故障。設定項目是否生效取決於 mihomo 核心支援；使用舊版原始核心時，未知欄位可能被忽略或導致載入錯誤。

05 / MOBILE POWER

行動裝置的電量、背景執行與切換網路表現

耗電來自持續喚醒，不只來自加密

手機上的代理用戶端通常透過系統 VPN 介面接管流量。資料先進入虛擬介面，再由核心比對規則、解析網域、建立代理連線，最後寫回系統網路堆疊。耗電來源很多：加密運算、資料複製、規則查找、DNS、連線保活、日誌、介面更新與無線基頻喚醒。只看協定加密演算法無法準確預測續航，持續的小封包與過短的保活間隔，往往比一次大流量傳輸更容易讓裝置無法進入低功耗狀態。

Wi-Fi 下的結論也不能直接套用到行動網路。行動基頻從休眠恢復至活躍狀態需要額外成本，頻繁保活會延長高功耗尾端時間。Hysteria2 與 TUIC 為維持 UDP 工作階段可能定期產生活動；TCP 協定同樣可能因心跳、連線池或應用程式背景請求而保持活躍。真正要測量的是「固定應用負載下整台裝置的耗電量」，而不是協定名稱。

系統背景策略比桌面端更嚴格

Android 製造商常會對背景程序、電池最佳化與自動啟動權限施加額外限制。用戶端被系統凍結後，VPN 圖示可能仍短暫存在，但核心已無法及時處理新連線。若遇到鎖定螢幕後無法存取、解鎖後才恢復，應檢查系統對用戶端的電池策略、背景執行權限與省電模式。Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 的介面路徑不同，但底層都必須遵守系統 VPN 與背景規則。

iOS 的網路延伸功能由系統管理，Clash Plus 透過 App Store 安裝後，連線與背景行為同樣受系統調度。不要用桌面端「程序持續執行」的思維理解手機。系統可能在網路變化時重建通道，也會控制延伸功能的記憶體與執行時間。節點數量過多、規則集過大或日誌持續更新，都可能增加網路延伸功能的負擔。

協定對行動裝置體驗的實際影響

SS 的連線結構較簡單，CPU 與記憶體開銷容易控制，適合作為行動裝置的穩定基準。Trojan 以及帶 TLS 的 VLESS、VMess 需要進行 TLS 處理，但現代行動處理器對常見加密已有良好支援，日常網頁使用的差距未必明顯。更值得關注的是複雜傳輸、多層封裝與大量並行連線。若同一節點群組中的協定體驗相近，優先選擇故障點較少、切換網路後恢復穩定的方案。

Hysteria2 與 TUIC 在弱網、多串流與連線變化中可能更順暢，但持續的 UDP 工作階段對部分行動網路並不友善。有些網路會快速回收 UDP NAT 映射，有些則對大流量 UDP 採取較保守的調度。手機從 Wi-Fi 切換到行動網路後，若節點長時間停留在連線中狀態，可先切換到 TCP 備援節點，再判斷是協定工作階段遷移失敗，還是系統 VPN 介面未及時重建。

一套可重現的續航測試方法

先選擇兩個線路相近、負載穩定的節點，保持規則、DNS、應用程式與螢幕亮度一致。充電完成後等待裝置溫度恢復，分別執行相同時間的網頁瀏覽、背景播放音訊、短影片與待機情境。記錄系統電池統計中用戶端、網路與螢幕的占比，同時觀察裝置是否頻繁喚醒。一次測試不足以排除應用程式背景活動，至少應跨兩個相近時段重複測試。

測試期間不要同時更新訂閱與規則集。規則下載、解壓縮與解析會製造短時間的 CPU 與網路峰值，把這些算入協定耗電沒有意義。也不要用持續滿速下載代表日常待機；滿速情境主要測量吞吐效率，待機情境主要測量保活與系統調度。兩類結果應分開記錄。

降低裝置成本的設定方式

第一，規則集只保留實際需要的部分，避免重複載入多個職責相同的大型清單。第二，日誌維持一般層級，排查結束後關閉即時除錯。第三，節點自動測試間隔不要設定得過短；每隔幾十秒掃描一大組節點，會持續喚醒網路與 CPU。第四，啟用按需連線時確認系統行為，避免多個自動化規則互相觸發。第五，DNS nameserver 數量保持合理，過多的並行解析不會線性提高速度。

若用戶端提供 TUN 堆疊、流量嗅探、IPv6、UDP 轉送等開關，應依需求啟用，而不是全部開啟。關閉某項功能前先確認使用情境：遊戲與語音通常需要 UDP，依賴網域規則的應用程式可能需要嗅探補充目標資訊，IPv6 網路則要確認 DNS 與規則是否完整涵蓋。節省電量不是刪除功能，而是讓功能與實際流量相互對應。

行動裝置的最終建議是保留兩條路徑：一條簡單、穩定的 TCP 節點作為常駐基準；另一條 Hysteria2 或 TUIC 節點用於弱網與高丟包環境。透過實際切換網路、鎖定螢幕與待機測試決定預設項目。協定越複雜，越需要驗證系統背景行為，而不是只在前景測速頁面比較數字。

06 / CORE FAMILY

原版 Clash、Clash Meta 與 mihomo 的關係

先區分用戶端外殼與代理核心

在 Clash 生態系中，「用戶端」與「核心」經常混用。圖形用戶端負責設定管理、訂閱更新、系統代理、系統匣選單與日誌介面；核心負責監聽連接埠、DNS、規則比對、協定連線與 TUN。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等都是圖形用戶端，可能整合 mihomo，也可能允許切換核心。看到相似介面，不代表底層協定支援完全一致。

排查相容性問題時，先在用戶端的關於頁面或啟動日誌行確認核心名稱，再查看設定檔。只憑應用程式名稱判斷很容易出錯。例如某個用戶端版本可能更換核心建置方式，另一個用戶端可能保留相容性選項。本網站不硬寫具體版本號，原因很簡單：核心與用戶端持續變化，實際安裝套件中的核心識別才是目前事實。

原版 Clash：基礎語法的來源

原版 Clash 奠定了常見的 YAML 結構：proxies 定義節點，proxy-groups 定義選擇與測試邏輯，rules 依序比對流量，DNS、監聽連接埠與執行模式位於頂層。大量教學與訂閱格式都沿用這套模型。它對 SS、VMess、Trojan 等基礎協定及經典規則語法的影響至今仍在。

但原版核心已停止維護。面對 Hysteria2、TUIC、更新版 VLESS 安全組合、規則集格式與現代 TUN 能力，繼續以原版功能邊界作為新設定基準會遇到許多缺口。舊設定可以作為語法起點，但不應把舊核心當成新協定的相容目標。Clash for Windows 也已停止維護，下載頁將其置於封存位置，適合處理舊環境，不適合作為新安裝的首選。

Clash Meta：擴充相容階段

Clash Meta 在原版設定模型上擴充了協定、DNS、規則提供器、TUN 與網路能力。許多原版 YAML 可以直接載入，再逐步加入 Meta 擴充欄位。這個階段回應了生態系對新協定與複雜設定的需求，也形成常見的「Meta 設定」稱呼。設定檔中出現 rule-providers、更完整的 DNS 項目、sniffer 或新協定欄位時，通常已超出原版 Clash 的穩定能力範圍。

相容性是單向傾斜的：Meta 系核心通常能讀取大量原版設定，但原版核心無法理解所有 Meta 擴充功能。將一份 mihomo 設定直接交給舊版原始核心，可能出現未知代理類型、未知欄位或規則提供器載入失敗。刪除錯誤行有時能成功啟動，但也可能悄悄改變 DNS、路由與節點安全參數，不應把「能啟動」視為等同相容。

mihomo：目前持續維護的延續

mihomo 是 Clash Meta 專案後續採用的名稱，也是持續維護中的核心，沿用 Clash 設定思路，並持續處理新協定、網路堆疊、DNS 與規則能力。許多用戶端介面仍使用 Clash 或 Meta 術語，但底層實際執行的是 mihomo。對新安裝使用者而言，優先選擇整合並持續更新 mihomo 的用戶端更直接；Windows 平台本網站首推 Clash Plus，也可依介面與平台需求選擇 Clash Verge Rev、FlClash 或 Clash Nyanpasu。

mihomo 功能多，不代表所有開關都必須啟用。TUN、嗅探、Fake-IP、規則提供器與外部控制介面分別解決不同問題。把網路上的大型設定整份複製進來，常見後果是欄位互相覆蓋、DNS 迴圈、規則順序錯誤或資源占用增加。更穩妥的做法是從訂閱產生的可用設定開始，每次加入一個模組，確認日誌與流量路徑後再繼續。

設定相容性要看行為，不只看語法

第一層相容性是 YAML 能否解析；第二層是節點欄位能否完整辨識；第三層是 DNS、規則與 TUN 行為是否符合預期。某些未知欄位可能被忽略，設定仍能啟動，卻在流量路徑上產生差異。例如代理節點缺少伺服器名稱可能導致 TLS 失敗，規則提供器未載入會讓流量落入最終規則，Fake-IP 過濾缺失則會影響區域網路網域解析。升級核心後應檢查日誌、節點連線與關鍵規則命中情況。

遷移時保留三份副本：原始訂閱、用戶端目前可用的設定，以及準備修改的新設定。先比較頂層欄位，再比較節點協定與代理群組，最後比較規則與 DNS。不要讓多個用戶端同時寫入同一個設定目錄，以免自動更新覆蓋手動修改。需要長期維護的自訂規則，宜放在用戶端支援的覆寫或 merge 機制中，而不是直接修改訂閱產生的檔案。

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這份最小結構只展示層級關係，不包含真實節點。設定能成功解析後，再由訂閱或用戶端覆寫加入代理節點、DNS 與規則提供器。若最小設定能啟動而完整設定失敗，就依模組逐段恢復；這種二分方法比盯著整個畫面猜欄位快得多。路由器直接執行 mihomo 的部署差異，可繼續參考《路由器直接執行 mihomo 核心的部署思路》。

07 / PROFILE FORMAT

訂閱格式、節點欄位與轉換相容性

訂閱連結不等於 Clash 設定檔

訂閱連結只是取得資料的入口，回傳內容可能是完整 Clash YAML、由多個分享連結組成的文字、base64 編碼清單或服務商自訂結構。完整 Profile 除了節點，也可能包含代理群組、規則、DNS、TUN 與規則提供器；一般訂閱通常只攜帶節點。用戶端匯入後若只出現節點而沒有預期規則，不一定是匯入失敗，也可能是來源訂閱本來就不提供完整策略。

反過來，一份完整 Clash YAML 也不一定適合直接交給所有用戶端。用戶端可能使用 mihomo，但對覆寫、指令碼或外部規則集路徑有自己的管理方式。匯入前先確認檔案類型：看到 proxies:、proxy-groups:、rules: 三段，通常是完整設定；看到多行 ss://、vmess:// 等連結，則比較接近節點集合。

分享連結能攜帶什麼，取決於協定

SS 分享連結通常攜帶加密方法、密碼、伺服器與連接埠，也可能透過查詢參數附加外掛。VMess 常見分享結構會編碼使用者識別、傳輸、Host、路徑、TLS 等欄位。Trojan 連結的重點是密碼、伺服器、連接埠、SNI 與傳輸參數。VLESS 連結可能包含安全類型、flow、指紋、公鑰識別、伺服器名稱與傳輸欄位。Hysteria2、TUIC 同樣需要驗證、SNI、壅塞或 UDP 相關參數。

問題在於轉換器是否認得這些欄位。若轉換器只實作協定基礎欄位，可能保留節點名稱與伺服器，卻遺失 flow、Reality 設定、WebSocket 標頭、gRPC 服務名稱或 Hysteria2 頻寬提示。產生的 YAML 看起來整齊，實際交握卻必然失敗。新協定或複雜組合出現匯入問題時，先嘗試讓用戶端直接讀取原始訂閱，再將轉換結果逐欄位比較。

YAML 本身也有容易忽略的邊界

YAML 對縮排敏感，Tab 字元、層級錯位與冒號後的特殊文字都可能破壞解析。節點名稱包含冒號、井字號、方括號或前後空白時，使用引號會更穩妥。布林值應依核心要求寫成 true 或 false，連接埠保持數字格式。相同鍵重複出現時，不同解析器的處理方式可能不同，不應依賴後一個鍵覆蓋前一個鍵的偶然行為。

代理群組引用的是節點名稱，改名後必須同步修改群組內的引用。規則最後通常需要一個兜底項目，例如 MATCH,PROXY；規則會依從上到下的順序比對，前面的寬泛規則會攔截後面的精細規則。訂閱轉換只負責產生結構，不會自動判斷業務規則是否合理。設定檔結構與多設定管理可繼續參考《什麼是 Clash 設定檔》。

匯入後進行四層驗收

第一層看數量：節點數是否大致與來源訂閱一致，協定類型是否齊全。第二層看欄位：抽查一條複雜 VLESS、一條 Trojan 或 VMess，以及一條 Hysteria2 或 TUIC，確認 TLS、SNI、傳輸與驗證欄位。第三層看策略：代理群組是否引用現有節點、規則集是否成功載入、是否存在最終規則。第四層看行為：分別測試 DNS、一般 HTTPS、UDP 應用與切換節點。

若只有個別節點失敗，應將失敗節點與同協定的正常節點進行欄位結構對照。若整類協定都失敗，檢查核心支援與轉換器映射。若所有節點都正常但網頁無法開啟，問題更可能出在系統代理、TUN、DNS 或規則，而不是訂閱格式。先把故障限制在某一層後再修改，避免反覆匯入導致設定清單越來越混亂。

訂閱更新與自訂規則要分層管理

直接編輯訂閱產生的 Profile，下一次更新通常會覆蓋修改。若用戶端支援覆寫、合併設定或擴充指令碼，應將本地規則、DNS 調整與代理群組修改放在獨立層。基礎訂閱負責提供節點，覆寫層負責本站或裝置策略。如此節點更新時不必重新手動修改整份 YAML，也能快速停用有問題的自訂模組。

多個機場或多用途設定並存時，名稱應表達來源與用途，例如「日常」「行動備用」「測試」，不要使用「設定一」「設定二」。記錄上次更新時間與自訂覆寫是否啟用。切換 Profile 後重新確認系統代理或 TUN 狀態，因為部分用戶端只會切換設定，不會自動恢復先前的連線狀態。

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

範例展示 mihomo 的代理提供器結構，網址是明確的示例網域。interval 控制訂閱更新間隔，健康檢查有自己的獨立間隔。將兩者設得過短會增加網路請求與行動裝置喚醒。真實訂閱網址應透過用戶端介面儲存，不要公開貼到文章、截圖或共用設定中。

關於 base64、YAML 與通用格式的進一步拆解，可閱讀《Clash 訂閱格式解析》。轉換的目標應是保留語義，而不是追求檔案看起來更短。遇到新協定欄位時，少一次不必要的格式轉換，通常就少一個相容性故障點。

08 / FIELD GUIDE

依裝置與網路情境完成協定選型

Windows 與 macOS 日常桌面使用

桌面裝置通常有較寬裕的背景資源與穩定網路，選擇重點應放在用戶端維護狀態、節點線路與設定相容性。Windows 新安裝優先從 Clash Plus 開始，再依介面需求考慮 Clash Verge Rev、FlClash 或 Clash Nyanpasu；macOS 同樣可優先使用 Clash Plus，也可選擇 Clash Verge Rev、FlClash。Clash for Windows 與 ClashX Meta 已停止維護，下載頁仍保留作為封存選項。

協定方面，先以訂閱中穩定的 SS、Trojan 或 VLESS 節點建立基準。固定地區後，再加入 Hysteria2 或 TUIC，對照高丟包與持續吞吐量表現。桌面裝置可以同時保留手動選擇群組與自動測試群組，但自動測試只能反映可達性與測試網址的交握表現，最終預設節點仍應透過實際網頁、下載與影片任務確認。

Android 與 iOS 長時間背景執行

Android 可在 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 之間，依介面與設定需求選擇；iOS 使用 Clash Plus。行動裝置應先確認背景權限、VPN 狀態與切換網路後的恢復能力，再比較協定。若日常主要使用訊息、網頁與音訊，簡單穩定的 SS、Trojan 或 VLESS 通常適合作為預設；弱網或高丟包環境可切換至 Hysteria2、TUIC，但必須驗證鎖定螢幕與行動網路情境。

節點群組不要堆得過大。自動測試數十個節點會增加 DNS、連線與電量成本。可以依地區與用途拆成小組：日常組只放經過驗證的少量節點，備用組保留不同協定與不同線路。旅行、飯店 Wi-Fi 或臨時訪客網路中，若 UDP 節點全部逾時，直接切換至 TCP 備援群組，不必在現場反覆修改憑證與 DNS。

路由器與低功耗裝置

路由器執行 mihomo 時，CPU 架構、記憶體、散熱與硬體轉送能力比桌面端更關鍵。SS 的實作通常較輕，適合作為資源基準；TLS、複雜 VLESS 組合、Hysteria2 與 TUIC 需要更多使用者空間處理，實際吞吐量可能受 CPU 單核心能力限制。裝置標示的網路埠速率不等於代理吞吐量，TUN、透明代理、規則集與 DNS 都會占用資源。

先用小型規則集與單一協定測試穩定吞吐量，再逐步啟用透明代理、Fake-IP、嗅探與規則提供器。若 CPU 滿載但網路尚未達到預期速度，切換協定前先減少日誌、縮小規則規模，並檢查軟路由是否發生重複轉送。路由器需要服務多個終端，穩定性通常比單一連線峰值更重要。Hysteria2 或 TUIC 在連線特徵相符時可以提高吞吐量，但也要確認 UDP 工作階段表與防火牆容量。

即時語音、遊戲與影片

即時服務重視抖動、丟包恢復與 UDP 轉送。首先確認用戶端 TUN 或系統 VPN 已接管對應流量，規則沒有將應用程式錯誤分到 DIRECT 或 REJECT。其次比較節點到目標服務的實際路由，不要只看節點伺服器延遲。Hysteria2 與 TUIC 可能在高丟包網路中維持更平滑的多串流傳輸，但額外的可靠機制不保證所有即時 UDP 應用都能獲得更低延遲。

影片更看重持續吞吐量與壅塞恢復。延遲低但出口擁擠的節點會頻繁緩衝，延遲較高但吞吐穩定的節點反而可能更適合。選擇節點時可依《Clash 節點怎麼選》中的延遲、倍率、地區與協定四個面向篩選。倍率屬於流量成本，地區影響內容與路由，協定只是其中一項。

一套可直接執行的選擇流程

1. 確認核心。在用戶端的關於頁面或日誌中確認使用 mihomo，避免新協定欄位落到舊版原始核心。
2. 檢查訂閱。確認節點數量、協定類型與複雜欄位，保留原始訂閱，不要先進行多次轉換。
3. 建立 TCP 基準。從 SS、Trojan、VMess 或 VLESS 中選擇一個穩定節點，驗證 DNS、HTTPS 與持續連線。
4. 測試 UDP 路線。在相同地區加入 Hysteria2 或 TUIC，驗證 UDP 可達性、持續吞吐量、切換網路與恢復能力。
5. 檢查裝置成本。桌面裝置觀察 CPU 與穩定性，手機觀察待機與背景執行，路由器觀察多終端並行與溫度。
6. 建立備援群組。將不同底層傳輸放入同一個手動選擇群組，網路變化時快速切換，不要臨時修改設定。

如果某個協定只出現在一個節點上，不具備公平比較的條件，就應把它視為節點選擇，而不是協定結論。若多個同協定節點都在同一網路中失敗、換到其他網路後恢復，優先檢查 UDP 或傳輸路徑；若只有一個用戶端失敗，優先檢查核心與欄位；若所有用戶端都失敗，則回頭檢查伺服器與訂閱來源。分層排查可以避免不斷更換用戶端，卻保留同一份錯誤設定。

結論：依限制條件選擇，不要按名稱排隊

SS 的價值在於簡單成熟，適合作為通用與低資源基準；VMess 的既有節點數量與傳輸組合仍有現實價值，重點是保留完整欄位；Trojan 依賴標準 TLS 路線，憑證與伺服器名稱必須正確；VLESS 的能力來自安全層與傳輸組合，更需要持續維護的核心；Hysteria2 面向高丟包與高吞吐量連線；TUIC 強調 QUIC 多串流與工作階段能力。它們解決的問題不同，不存在脫離線路、裝置與伺服器實作的固定排名。

核心方面，新設定以 mihomo 作為主要檢查對象，原版 Clash 語法繼續作為結構基礎，Clash Meta 設定通常可以沿著遷移路徑進入 mihomo。訂閱方面，優先保留原始語義，減少不必要的轉換，匯入後依節點、欄位、策略與行為四層驗收。用戶端方面，首選持續維護且能清楚顯示核心狀態的產品；Windows 與 macOS 可優先考慮 Clash Plus，其他平台則依下載頁清單選擇。

完成選型後，回到入門指南執行訂閱匯入、模式選擇與連線驗證；需要安裝套件時前往下載頁；遇到無法上網、DNS 或規則命中問題時，請轉到說明中心。協定選擇到這裡應該成為一套可重複執行的流程：確認核心、儲存原始設定、固定變數、測試真實任務，並保留備援路徑。