Clash 協定與核心技術參考

一、先建立協定選擇框架

協定名稱不等於速度等級

Clash 用戶端中的協定類型，首先描述用戶端與伺服器如何建立連線、驗證身分、封裝資料與處理壅塞，並不直接代表固定的速度等級。相同協定放在不同伺服器、線路與裝置上，結果可能差異很大。伺服器距離、出口頻寬、往返延遲、封包遺失率、伺服器負載與本地網路品質，通常比協定名稱更早決定實際體驗。把協定清單簡單排列成「新協定一定快、舊協定一定慢」，容易得出錯誤結論，也可能在更換節點後把線路差異誤認為協定差異。

選擇時應將問題拆成三個層次。第一層是傳輸層：基於 TCP、UDP，還是允許組合多種傳輸方式；第二層是協定層：如何驗證、加密與多工連線；第三層是實作層：目前用戶端使用哪個核心，以及該核心是否完整支援訂閱宣告的欄位。只有三層同時吻合，節點才可能正確載入並穩定執行。用戶端介面顯示某個協定名稱，不代表所有擴充參數都已獲得支援；訂閱轉換器能輸出一段 YAML，也不代表目標核心能理解其中每個欄位。

先確認限制，再比較偏好

實際選擇可以從四項限制開始。首先確認服務提供者提供的節點類型，因為協定必須由連線兩端共同支援，用戶端無法在本機直接把 VMess 節點改成 VLESS 或 Trojan。其次確認用戶端核心。原版 Clash 對早期常見協定與基礎規則系統的支援較穩定，但較新的協定與擴充能力通常需要 Clash Meta 或其後續專案 mihomo。再次確認裝置環境：桌面裝置通常較能容忍額外記憶體與持續連線，行動裝置則應留意背景保活、無線模組喚醒次數與弱網切換。最後確認網路特性：穩定低遺失率網路與高延遲、輕度遺失率網路，適合的方案並不相同。

在確認這些限制後，才適合比較啟動速度、持續吞吐量、並行能力、資源用量與設定複雜度。瀏覽網頁與傳輸大型檔案的指標也不同。網頁存取更在意 DNS、握手次數與首位元組時間；大型檔案更在意持續吞吐量與壅塞控制；即時音訊與視訊則同時重視抖動、封包遺失恢復與排隊延遲。單次測速只能反映測試當下的一條路徑，無法涵蓋一天內的負載變化，也不能取代實際業務測試。

建立可重複的測試方法

比較兩個節點時，應盡量維持伺服器地區、測試時間、用戶端核心、DNS 設定與規則模式一致。先關閉其他高流量工作，再分別觀察建立連線、首次開啟網頁、連續下載、影片拖曳與待機恢復。每個方案至少重複測試數次，記錄中位表現，而不是只保留最好的一次。如果切換協定的同時也更換伺服器，就無法判斷改善來自協定還是線路。行動裝置還應加入鎖定螢幕後恢復、Wi-Fi 與行動網路切換、低電量模式等測試，這些環節往往比前景測速更容易暴露問題。

本頁所有結論都用於理解設計取捨，不是替協定做脫離環境的絕對排名。一個設定簡單、伺服器穩定、核心支援完整的傳統協定，往往比參數複雜但部署不匹配的新協定更可靠。合理選擇的目標，是減少不必要的變數，讓連線在目標裝置與日常網路中保持可預期，而不是追逐單項測試中的最高數字。

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

Shadowsocks：結構精簡，取決於實作品質

Shadowsocks 通常簡稱 SS，其核心概念是以較輕量的方式加密並轉送 TCP 與 UDP 流量。設定要素相對精簡，常見必要資訊包括伺服器位址、連接埠、密碼與加密方法。由於協定結構精簡、實作廣泛，在桌面、行動與資源有限的裝置上都容易部署。對只需要穩定轉送、希望降低設定複雜度的情境，SS 仍具明確價值。實際執行負擔不只取決於協定本身，也取決於所選加密演算法能否利用裝置硬體加速。

SS 常見的相容問題來自加密方法名稱與擴充外掛。較新的 AEAD 方法與舊式方法在安全特性和實作支援上有所差異；若訂閱包含外掛參數，目標核心還必須理解外掛類型及其選項。只複製伺服器、連接埠與密碼而遺漏外掛欄位，節點可能成功載入，卻無法完成通訊。遷移時應完整比較節點物件，而不是只看介面中最醒目的四項資訊。

VMess：能力集中，但設定欄位較多

VMess 是較早形成完整生態系的一類協定，通常會搭配 UUID 身分識別、傳輸層選項、TLS 設定與路徑參數。它可以承載於 TCP、WebSocket 等不同傳輸形式之上，因此兩個都標示為 VMess 的節點，內部結構可能完全不同。用戶端需要正確處理位址、連接埠、UUID、傳輸網路、Host、路徑、TLS 伺服器名稱與憑證驗證策略。任何關鍵欄位在訂閱轉換中遺失，都可能導致握手失敗。

VMess 的優勢在於歷史工具鏈與訂閱生態系較成熟，許多用戶端都能識別常見連結格式。代價是參數組合較多，排除問題時不能只檢查「是否支援協定」。例如節點使用 WebSocket 時，路徑與 Host 由伺服器設定決定；啟用 TLS 後，伺服器名稱與憑證的對應關係也必須正確。某些舊設定還會帶有現代實作不再強調的相容欄位，遷移到 mihomo 時應讓用戶端或可靠的訂閱產生端輸出目前格式，不宜將多年累積的舊欄位原樣拼接。

Trojan：透過 TLS 建立驗證與傳輸

Trojan 的典型設定以 TLS 連線為核心，常見資訊包括伺服器、連接埠、密碼、伺服器名稱與憑證驗證設定。對用戶端而言，相較一般 TCP 協定，它多了完整的 TLS 握手與憑證檢查，因此 DNS 解析、系統時間、SNI 與憑證鏈都會影響連線結果。設定正確時，Trojan 的使用邏輯相當直接；設定錯誤時，錯誤訊息常表現為 TLS 握手失敗、憑證名稱不符或遠端關閉連線。

Trojan 不代表所有連線都具有相同負擔。首次 TLS 握手需要額外往返與密碼學運算，連線重用、工作階段恢復與伺服器實作都會影響後續表現。在高延遲環境中，如果應用程式頻繁建立短連線，握手成本更容易被察覺；在持續傳輸中，這項固定成本所占比例會下降。若節點再疊加 WebSocket、gRPC 等傳輸方式，還要繼續核對網路類型與對應參數，不能只保留 Trojan 的密碼與伺服器名稱。

VLESS：精簡協定層，將能力交給組合

VLESS 常使用 UUID 進行身分識別，但協定本身不負責傳統意義上的內容加密，實際安全特性通常由 TLS 或其他受支援的傳輸組合提供。它的設計傾向於減少協定層的重複工作，並將傳輸、加密與擴充能力交給組合設定。這讓 VLESS 具備高度擴充性，也使相容性判斷更依賴具體組合。僅看到節點類型為 VLESS，無法推斷它是否能被某個 Clash 核心使用，還必須查看傳輸網路、TLS、流量控制與其他擴充欄位。

在 mihomo 中使用 VLESS 時，基礎節點與常見傳輸通常有良好支援，但部分依賴特定實作的新擴充功能，仍需核對核心文件與用戶端更新狀態。訂閱提供者若輸出只適用於另一個核心的欄位，匯入後可能被忽略或回報錯誤。排查時可以先將複雜組合縮減為伺服器允許的基礎形式，確認身分資訊與 TLS 能正常運作，再逐項恢復傳輸與擴充參數。這個順序比同時修改多個選項更容易定位問題。

三、Hysteria2 與 TUIC：面向高延遲與封包遺失的 UDP 方案

為什麼改用 UDP 承載

傳統 TCP 連線具備成熟的可靠傳輸與壅塞控制，但當代理通道外層與應用程式內層同時使用 TCP 時，封包遺失恢復、重傳與壅塞控制可能互相影響。尤其在往返延遲較高或存在間歇性封包遺失的網路中，一次外層丟包可能讓多條內層連線同時等待。基於 UDP 建構的現代協定，可以在使用者空間安排串流、多工、確認與壅塞控制，因而更靈活地處理不同網路條件。Hysteria2 與 TUIC 都屬於這條路線，但兩者的實作目標、參數表達與核心支援細節並不完全相同。

UDP 方案的價值不能理解成「跳過可靠性」。應用程式資料仍需依設計完成確認、重傳與排序，只是這些工作由使用者空間的協定堆疊負責組織。它們也不會憑空創造頻寬：伺服器出口不足、無線訊號不佳或路徑長期壅塞時，任何協定都會受到實體條件限制。優勢主要在於更合適的壅塞控制、較少受到隊頭阻塞影響，以及多串流並行時更靈活的調度。

Hysteria2：設定較集中，著重弱網吞吐量

Hysteria2 建立於 QUIC 相關能力之上，常見設定包含伺服器位址、連接埠、驗證密碼、TLS 伺服器名稱與憑證驗證選項。部分部署還會指定上下行頻寬提示或壅塞控制相關參數。它的設計重點之一，是在高延遲且有一定封包遺失的路徑上維持可用吞吐量，因此常用於跨地區連線、行動網路或品質波動明顯的線路。不過，頻寬參數不是越大越好。若填入的數值明顯高於實際可用頻寬，傳送端可能造成排隊與額外丟包；填得過低則會主動限制吞吐量。

使用 Hysteria2 時，應先確認 UDP 路徑可用，再檢查驗證與 TLS。如果節點完全無法建立連線，可以依序測試網域解析、伺服器連接埠、系統時間、SNI 與憑證；若能連線但速度波動很大，應繼續觀察實際上下行、路由器佇列與無線網路品質。某些網路對長時間 UDP 工作階段的映射維持時間較短，可能表現為閒置後第一個請求失敗或頻繁重新連線，此時應從系統背景策略、路由器 NAT 狀態與用戶端連線記錄共同判斷。

TUIC：更應關注多工與連線管理

TUIC 同樣使用基於 UDP 的現代傳輸能力，節點設定通常包含伺服器、連接埠、UUID、密碼、TLS 伺服器名稱，以及壅塞控制或 UDP 轉送方式等參數。不同實作階段曾使用不同欄位表達，訂閱來源與核心之間若存在格式差異，最容易出現的情況是節點能被識別，但某個可選參數未依預期生效。因此，遷移 TUIC 時不能只確認 type，還要核對驗證欄位名稱、壅塞控制名稱、UDP 中繼模式與憑證設定。

TUIC 的多工有助於減少重複握手，讓多個應用程式串流共用底層連線，但共用並非越多越好。如果一條底層連線持續壅塞，過度集中可能讓更多請求一起受到影響；如果建立太多獨立連線，又會增加握手、記憶體與 NAT 映射成本。用戶端與核心通常提供相對合理的預設值，除非已透過記錄確認瓶頸，否則不建議只根據網路上的參數片段大幅調整。

UDP 協定的網路與裝置限制

在穩定、低延遲且幾乎不丟包的有線網路中，Hysteria2 或 TUIC 未必比簡單的 TCP 方案帶來明顯改善，因為其使用者空間協定堆疊、加密與計時器也需要處理器資源。反過來，在高延遲或輕中度隨機丟包環境下，它們更可能維持平順吞吐量。若丟包來自嚴重壅塞，盲目提高傳送速率只會加重排隊；此時應先降低頻寬提示、檢查路由器緩衝並減少並行工作。

企業、校園或公共 Wi-Fi 可能採用不同的 UDP 策略，切換網路後結果也可能改變。行動裝置還會受到行動網路 NAT、背景凍結與無線模組省電策略影響。因此，UDP 協定應保留一個可用的 TCP 方案作為對照，而不是在連線異常時同時更換核心、DNS 與規則。對照節點有助於判斷問題位於協定路徑，還是整個設定環境。

proxies:
  - name: "Hysteria2-Test"
    type: hysteria2
    server: test.example.com
    port: 443
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

  - name: "TUIC-Test"
    type: tuic
    server: test.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

以上片段用於說明 mihomo 設定結構，位址與驗證資訊都是範例值，不能直接建立連線。實際設定應由伺服器提供，並保持伺服器名稱與憑證一致。手動輸入後，先使用用戶端的設定檢查功能，確認欄位名稱與縮排正確，再加入策略群組測試。

四、如何比較連線速度、吞吐量與資源用量

將「速度」拆成四項指標

使用者感受到的速度至少包含連線建立時間、首位元組時間、持續吞吐量與並行穩定性。連線建立時間受 DNS、TCP 或 QUIC 握手、TLS 握手與協定驗證影響；首位元組時間還包括目標網站回應與策略比對；持續吞吐量主要受線路頻寬、壅塞控制、封包遺失恢復與處理器能力影響；並行穩定性則與連線重用、檔案描述元、記憶體及伺服器負載相關。只看測速頁面的峰值，無法解釋網頁首次開啟緩慢、影片拖曳卡頓或大量小請求排隊等現象。

SS 的協定處理相對精簡，在硬體加速良好的裝置上通常具備較低的額外負擔。Trojan，以及啟用 TLS 的 VMess、VLESS，都需要考量 TLS 握手；但持續連線建立後，固定握手成本會被長時間傳輸攤薄。Hysteria2 與 TUIC 的使用者空間傳輸邏輯較複雜，可能消耗更多處理器與記憶體，同時在高延遲或丟包網路中透過更靈活的壅塞控制取得更穩定的有效吞吐量。最終結果取決於網路條件，而不是由協定層單獨決定。

加密與處理器能力

現代桌上型處理器與行動晶片通常會為常見密碼學操作提供硬體最佳化，但不同演算法、執行庫與核心實作的利用程度各異。低功耗路由器、較舊手機與入門級伺服器，更容易在高速傳輸時遇到單核心瓶頸。此時通常會看到網路頻寬仍有餘裕，但核心程序使用率持續升高、裝置溫度上升，吞吐量卻無法繼續增加。更換協定可能改變結果，但也應檢查是否啟用了過多記錄、複雜規則、流量嗅探或大量連線多工，因為這些功能同樣會消耗資源。

記憶體用量主要來自核心基礎執行、規則集、DNS 快取、連線狀態與緩衝區。協定本身的靜態差距，往往小於規則集規模與並行連線造成的差距。載入多個大型規則提供者、保留過長記錄、同時執行多個訂閱並啟用複雜 DNS 分流，可能比從 SS 切換到 Trojan 更為明顯。在伺服器或路由器上部署 mihomo 時，應將可用記憶體留給系統網路堆疊與快取，避免記憶體壓力觸發頻繁回收。

TCP 與 QUIC 類協定的丟包表現

TCP 在穩定網路中效率高、實作成熟，系統核心也經過長期最佳化。它的不足通常在高延遲與丟包同時存在時更明顯，尤其當多個應用程式串流被包在同一條外層 TCP 連線中，一個遺失的資料段可能阻塞後續資料交付。QUIC 類方案會分開管理不同串流的狀態，能減輕單一串流丟包對其他串流的影響，並在使用者空間採用合適的壅塞控制。但 UDP 封包仍會經過路由器佇列與網路路徑，嚴重壅塞時同樣需要降速。

判斷是否受到丟包影響，不能只執行一次連通測試。應觀察連續請求、穩定下載與即時業務是否以固定間隔出現停頓。如果切換到 Hysteria2 或 TUIC 後持續吞吐量改善，但裝置明顯發熱，表示網路收益與裝置成本同時存在，需要按使用時間權衡。如果改善只出現在短時間測速中，長時間傳輸卻逐步下降，可能涉及伺服器限速、過熱降頻或錯誤的頻寬參數。

一套更可靠的比較流程

先選擇相同地區、線路條件相近的兩個節點，在同一個用戶端與相同規則模式下測試。第一輪記錄首次連線與開啟網頁；第二輪進行數分鐘的持續傳輸，觀察平均而非峰值吞吐量；第三輪同時發起多個常用應用程式請求，檢查互動延遲；第四輪讓連線閒置後恢復，確認工作階段是否穩定。測試期間記錄核心程序的處理器、記憶體與裝置溫度，並在不同時段重複測試。如果結論變化很大，應優先歸因於線路負載，而不是立即修改協定參數。

五、行動裝置電量、背景連線與網路切換

耗電不只由加密運算決定

行動裝置耗電由處理器運算、無線模組活躍時間、背景喚醒、資料重傳與系統 VPN 服務共同構成。協定的密碼學負擔只是其中一部分。一條持續維持但活動頻率較低的連線，可能比頻繁中斷後重新建立更省電；一個理論處理效率較高、卻因網路不穩定而持續重傳的方案，也可能消耗更多電量。評估協定時，至少應觀察一個完整使用週期，包括前景瀏覽、鎖定螢幕待機、訊息抵達、網路切換與影片傳輸，而不是只看幾分鐘測速後的電池百分比。

SS 設定較簡單，通常容易在行動裝置上取得穩定表現，但最終仍取決於 UDP、DNS 與系統 VPN 實作。Trojan、VMess 與 VLESS 若頻繁建立 TLS 或傳輸層連線，會增加喚醒與握手成本；如果用戶端能合理重用連線並維持工作階段，這部分成本便可降低。Hysteria2 與 TUIC 在弱網下可能減少長時間等待與重複傳輸，改善有效能耗，但其使用者空間協定處理、計時器與持續 UDP 工作階段，也可能提高背景活動。不存在適用於所有手機與網路的固定耗電排名。

Android 的背景與電池策略

Android 用戶端通常透過系統 VPN 介面接管流量。不同廠商的背景管理可能限制應用程式程序、VPN 服務或網路活動，鎖定螢幕後中斷不一定是協定故障。使用 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard 時，應先確認系統狀態列中的 VPN 連線是否仍存在，再檢查應用程式是否遭電池最佳化暫停。如果只有某種協定在鎖定螢幕後恢復較慢，可以比較其連線保活與工作階段恢復；若所有協定同時停止，則更可能是系統背景策略或應用程式程序遭終止。

Android 上的網路切換也值得單獨測試。從 Wi-Fi 切換到行動網路時，本地 IP、NAT 映射與路徑都會改變。傳統 TCP 連線通常需要重建，QUIC 類協定在實作允許時可能更靈活，但用戶端、系統 VPN 與伺服器必須共同配合。如果切換後顯示已連線卻沒有流量，可以先暫停再恢復用戶端連線，接著檢查 DNS 是否仍指向舊網路環境。頻繁自動切換的裝置可適度減少不必要的並行連線，避免每次切換都重建大量工作階段。

iOS 的系統 VPN 生命週期

iOS 用戶端同樣會受到系統 Network Extension 生命週期與記憶體限制影響。Clash Plus 透過系統提供的網路擴充功能處理流量，背景狀態由系統統一調度。節點參數複雜、規則集過大、DNS 快取與連線數量過多，都可能增加擴充功能的記憶體壓力。行動裝置設定不宜照搬資源充足的桌面設定，尤其不應同時載入多個重複的大型規則集。協定無法連線時，先確認設定本身能通過解析，再查看是單一節點失敗，還是整個 VPN 擴充功能退出。

在 iOS 上比較耗電時，應讓螢幕亮度、應用程式使用方式與網路類型盡量接近，並在系統電池頁面觀察一段時間。如果某方案前景速度很高，但背景活動明顯增加，可以嘗試減少持續連線、關閉不需要的流量嗅探或調整規則，不能只靠更換協定解決。需要安裝 iOS 用戶端時，可在iOS 下載區查看 Clash Plus 的 App Store 入口與官方網站 clashplus.io。

弱網下的電量與體驗平衡

在穩定的家庭 Wi-Fi 中，輕量 TCP 方案通常已足夠，持續使用 Hysteria2 或 TUIC 未必帶來可感知的收益。在通勤、行動網路與經常切換基地台的環境中，可以比較現代 UDP 方案是否減少影片緩衝與連線停頓。如果手機溫度、背景活動或流量用量明顯上升，應回到預設參數，避免填寫超過實際頻寬的上行與下行值。過高的傳送速率造成排隊與重傳，不僅降低體驗，也會延長無線模組的工作時間。

行動裝置建議保留兩個策略入口：一個選擇經日常驗證的穩定節點，另一個選擇適合高延遲或丟包網路的節點。遇到異常時先切換策略，不必立即重新載入全部設定。這樣能快速判斷是單一節點問題，還是用戶端整體問題，也能減少頻繁修改設定帶來的變數。訂閱更新後若協定欄位發生變化，應先手動測試新節點，再將它加入自動選擇或故障轉移策略。

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

原版 Clash：設定體系的基礎

原版 Clash 建立了廣泛使用的 YAML 設定結構、規則系統、策略群組與控制介面。常見的 proxies、proxy-groups、rules、DNS 與連接埠欄位都源自這套體系。許多用戶端即使已更換核心，介面與設定概念仍延續原版 Clash 的組織方式。因此，理解原版設定模型仍然有價值：節點負責描述連線，策略群組負責選擇與自動測試，規則負責將請求交給相應策略，DNS 則會影響網域解析與規則比對。

原版 Clash 的協定涵蓋範圍更接近其維護時期的常見需求。對於 SS、VMess、Trojan 等基礎設定，它形成了穩定且廣泛相容的語法，但面對 Hysteria2、TUIC、VLESS 擴充、規則能力與現代 DNS 功能時，通常需要後續核心。繼續使用只支援原版核心的舊用戶端，可能出現訂閱能匯入但新節點被跳過、未知欄位回報錯誤，或功能遭靜默忽略的情況。

Clash Meta：在既有模型上擴充

Clash Meta 以相容 Clash 設定體系為基礎，增加更多協定、傳輸方式、規則能力與 DNS 選項。它的重要性不只是增加節點類型，而是讓原有策略群組與規則模型能繼續承載新的協定實作。使用者可以保留大部分熟悉的設定結構，同時使用 VLESS、Hysteria2、TUIC 等能力。不過，「相容原版」主要表示大量基礎欄位與組織方式可以沿用，不代表任意 Meta 設定都能反向交給原版 Clash。

設定一旦使用 Meta 專屬協定或擴充欄位，就會形成單向相容關係：mihomo 通常能理解許多原版 Clash 設定，但原版 Clash 無法理解所有 mihomo 設定。遷移前應辨識這些擴充點，包括代理類型、規則類型、DNS 模式、流量嗅探、規則提供者格式與策略群組選項。如果需要同時維護新舊用戶端，應採用共同支援的欄位子集，或由訂閱系統分別產生兩份目標設定，而不是強行讓一份複雜設定相容所有核心。

mihomo：專案名稱延續與目前實作

mihomo 是 Clash Meta 後續採用的專案名稱，許多用戶端介面與文件仍會同時出現 Meta、Clash Meta Core 或 mihomo。判斷時應關注實際核心，而不是只依據用戶端名稱。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等圖形用戶端，可以將設定管理、系統代理、記錄與更新操作包裝成介面，但節點協定最終仍由核心解析與執行。用戶端本身的更新與核心更新也可能分開進行，因此介面功能正常不代表核心已支援訂閱中的所有新欄位。

本站下載頁將圖形用戶端與 mihomo 核心套件分開列出。一般桌面與行動使用者優先選擇圖形用戶端，Clash Plus 作為全平台首選，適合希望透過統一介面完成匯入、策略選擇與系統代理管理的使用者。直接下載 mihomo 核心則更適合伺服器、路由器，或需要自行管理設定與程序的使用方式。核心本身不等同於完整桌面應用程式，系統代理、開機啟動、設定編輯與更新都需要外部工具處理。

如何確認用戶端正在使用哪個核心

首先查看用戶端的「關於」「核心」或「執行狀態」頁面，區分應用程式名稱與核心名稱。其次查看設定檢查或啟動記錄，核心通常會在載入階段回報未知欄位、代理解析失敗或規則錯誤。再次選擇一個只有 mihomo 支援的節點進行測試；如果節點在匯入時被過濾，表示訂閱轉換目標或目前核心不相容。不要只根據安裝套件檔名猜測，因為部分用戶端允許切換核心或獨立更新核心檔案。

從舊用戶端遷移時，應先在新用戶端匯入訂閱副本，不要覆蓋唯一可用的設定。確認節點數量、策略群組與規則都符合預期後，再測試 DNS 與協定連線。關於 mihomo 與原版 Clash 的詳細差異，還可閱讀mihomo 與原版 Clash 的差異。如果設定在啟動階段直接回報錯誤，應先依第一個解析錯誤處理，因為後續錯誤可能只是前一個結構問題引發的連鎖結果。

七、訂閱格式、YAML 欄位與遷移相容性

節點連結、訂閱清單與完整設定是三個層級

單一節點連結通常只描述一個代理所需的資訊，例如協定、伺服器、連接埠與驗證參數。訂閱清單是一組節點的集合，可能使用 Base64 文字、專用連結清單或伺服器產生的格式。完整 Clash 設定則不只包含節點，還包含策略群組、規則、DNS、連接埠與其他執行參數。將訂閱匯入用戶端時，用戶端可能會執行解析、轉換、合併與覆寫，因此最終載入的 YAML 不一定與遠端原始內容完全相同。

相容問題常發生在轉換階段。來源訂閱可能包含目標核心不認識的協定，轉換器可能捨棄未知欄位；也可能將另一個生態系的欄位映射成 Clash 語法，卻未涵蓋某項擴充參數。節點數量看起來正確，並不能證明每個節點結構完整。遷移後應抽查不同協定各一個節點，尤其是帶有 WebSocket、gRPC、TLS、Reality 類擴充或 UDP 參數的節點，確認關鍵欄位沒有遺失。

YAML 結構與型別必須準確

YAML 依靠縮排表達層級，清單項目、物件與字串型別都必須準確。連接埠通常寫成數字，布林值寫為 true 或 false，包含特殊字元的密碼與名稱適合使用引號。Tab 字元、全形標點、錯誤縮排與重複鍵，都可能導致設定解析失敗。如果用戶端提供語法檢查，應在替換主要設定前使用；手動編輯時一次只修改一小段，並保留上一份可載入的副本。

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

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "SS-Test"
      - DIRECT

rules:
  - MATCH,手動選擇

這段設定展示節點、策略群組與規則之間的引用關係。策略群組中的名稱必須與節點名稱完全一致，規則末尾引用的策略群組也必須存在。範例位址與密碼不可直接連線。真實訂閱中如果節點名稱包含逗號、特殊符號或重複名稱，轉換器可能會重新命名，手動撰寫的策略群組引用也要同步更新。

基礎欄位相容不代表行為完全一致

相同欄位在不同核心中可能具有不同的預設值，某些舊欄位也可能仍被接受，但已不再建議使用。遷移時最安全的方式，是讓目標用戶端重新產生基礎設定，只遷入節點、策略群組與確實需要的規則，而不是整份複製舊用戶端匯出的所有執行參數。系統代理連接埠、控制介面、快取路徑與外部資源目錄通常與裝置環境有關，不適合直接跨平台沿用。

DNS 是另一個高風險區域。原版 Clash、Meta 與 mihomo 的 DNS 能力與可用欄位持續演進，舊設定中的 nameserver、fallback、fake-ip 範圍與過濾規則，都需要配合目前核心重新核對。如果節點能連線但部分網域解析異常，應將問題拆成「系統請求是否進入用戶端」「Clash 使用哪個解析器」「解析結果如何進入規則比對」三個步驟。詳細請求路徑可查閱Clash DNS 設定詳解。

訂閱更新失敗與本機覆寫

用戶端通常會儲存訂閱位址、遠端設定快取與本機覆寫。如果直接編輯由遠端設定產生的檔案，下次更新可能覆蓋修改；如果覆寫規則寫得過於寬鬆，也可能在更新後刪除新節點欄位。建議保留原始訂閱，只在用戶端支援的覆寫層加入策略群組或規則。更新失敗時，先判斷是位址無法存取、回傳內容為空、身分參數失效，還是下載成功但解析失敗。前兩類屬於取得階段，後兩類屬於內容階段，排查方向不同。

對於定期更新，不宜設定過短的間隔。頻繁請求不會讓節點持續變快，反而可能造成重複解析、策略群組重建與行動裝置背景喚醒。訂閱提供者明確給出更新時間時，依其建議設定；沒有要求時，依實際變更頻率選擇合理週期。更新後若節點數量突然減少，先保留舊快取，不要立即刪除可用設定。相關處理順序可參考Clash 訂閱更新失敗原因與自動更新間隔設定。

八、依裝置與網路情境完成最終選擇

穩定桌面網路：先選擇相容性與維護成本

Windows、macOS 或 Linux 桌面裝置連線穩定寬頻時，協定差異往往小於伺服器線路差異。已有可靠的 SS、Trojan、VMess 或 VLESS 節點時，沒有必要只因協定名稱較舊就更換。應優先選擇目前用戶端完整支援、訂閱欄位清楚、伺服器維護穩定的方案。需要圖形介面時，可以先從下載頁選擇 Clash Plus，再依平台需求比較 Clash Verge Rev、FlClash、Clash Nyanpasu 或其他列出的用戶端。

桌面端首次設定建議使用規則模式，不要立即堆疊複雜覆寫。先驗證節點直接連線測試、策略群組切換與 DNS，再載入額外規則。如果同一服務提供多種協定，可以選擇相同地區的節點進行單一變數比較：穩定網路下優先觀察首次開啟、長期穩定性與資源用量，而不是只看峰值。SS 設定簡潔，Trojan 與 VLESS 常依賴 TLS 參數，VMess 則需要完整保留傳輸欄位；只要其中一種設定與線路較成熟，都可能成為更合適的日常選擇。

高延遲或輕中度丟包：比較 Hysteria2 與 TUIC

跨地區連線、行動熱點或無線品質波動明顯時，可以測試 Hysteria2 與 TUIC。先確認用戶端使用 mihomo，並確保訂閱輸出完整的節點欄位。測試時使用預設參數建立基準，不要先填入過高的頻寬值。如果持續下載更平順、影片拖曳恢復更快，且裝置資源消耗可接受，表示現代 UDP 方案適合目前路徑；若連線經常在閒置後失效，或某些網路完全無法建立 UDP 工作階段，則保留 Trojan、VLESS 或 SS 作為替代入口。

Hysteria2 更適合希望使用較集中的驗證與 TLS 設定，並針對弱網吞吐量進行測試的情境；TUIC 則應更關注驗證欄位、多工、壅塞控制與 UDP 中繼方式是否與目標核心相容。兩者都不應脫離伺服器設定自行轉換。如果伺服器只提供其中一種，就應圍繞該實作進行測試，而不是根據名稱推斷另一種一定更快。

行動裝置：將穩定恢復放在峰值之前

Android 與 iOS 的選擇應加入鎖定螢幕、背景執行與網路切換測試。日常以家庭 Wi-Fi 為主時，穩定的 SS、Trojan 或 VLESS 通常容易取得平衡表現；使用行動網路時，延遲較高且有隨機丟包，可以測試 Hysteria2 或 TUIC，但也要同時觀察耗電、溫度與背景活動。如果用戶端在鎖定螢幕後遭系統暫停，應先調整系統允許的背景策略，不要把所有斷線都歸因於協定。

行動裝置設定應控制規則集與並行規模，避免將桌面設定完整複製到手機。保留一個經驗證的穩定策略與一個弱網策略，切換時只改變節點或策略群組。訂閱更新後先測試，再放入自動選擇群組。如此既能減少突發相容問題，也方便判斷異常來自節點、協定還是系統 VPN 生命週期。

路由器與伺服器：資源預算決定上限

在路由器、旁路由或小型伺服器上直接執行 mihomo 時，應先確認處理器架構、可用記憶體、儲存空間與系統服務管理方式。低功耗裝置使用簡單協定與適量規則通常更穩定；複雜 DNS、流量嗅探、大型規則集與現代 UDP 協定疊加後，可能出現單核心滿載或記憶體壓力。部署前先以少量節點與基礎規則執行，觀察長期資源用量，再逐項增加功能。

路由器承擔整個區域網路流量時，並行連線數遠高於單台電腦。協定多工、連線追蹤、DNS 快取與記錄都會放大資源需求。如果尖峰時段速度下降，應同時查看處理器、記憶體、溫度、網路介面與上游線路，不能只替換協定。直接使用 mihomo 核心，代表需要自行處理程序守護、設定權限與更新流程；不熟悉這些操作時，桌面或行動圖形用戶端的維護成本較低。

遷移與驗證清單

從舊用戶端遷移到 mihomo 用戶端時，先備份訂閱位址與目前可用設定，再安裝目標用戶端。建議優先選擇 Clash Plus，並在新用戶端重新加入訂閱，不要覆蓋舊應用程式資料。匯入完成後核對節點數量與協定分布，分別選擇 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC 中實際存在的節點進行測試。接著檢查策略群組、規則模式、DNS 與系統代理，最後才處理開機啟動、背景權限等應用程式設定。

驗證節點時依固定順序進行：設定能否解析、節點能否完成連線、網域能否解析、規則能否選擇預期策略、持續傳輸是否穩定，以及鎖定螢幕或閒置後能否恢復。第一步失敗就不應繼續調整測速參數；節點連線成功但網頁無法開啟時，應檢查 DNS 與系統代理；只有持續傳輸階段異常時，才重點比較壅塞、丟包與資源用量。遇到無法上網、訂閱更新失敗或啟動錯誤，可進入疑難解答依現象排查。

最終選擇不必追求全域唯一答案。桌面、手機與路由器可以使用不同用戶端與不同協定；穩定網路與弱網也可以放在兩個策略群組中按需切換。協定選擇的核心，是讓伺服器能力、核心支援、訂閱欄位與裝置條件形成完整閉環。只要這四項一致，傳統協定與現代協定都能在適合的情境中發揮作用。