Clash 協定與核心選擇

核心系列與用戶端分工

Clash、Meta 與 mihomo 的關係

Clash 最初建立了一套以 YAML 設定檔描述節點、策略群組與規則的運作方式。應用程式的連線會進入統一的路由流程，再依規則決定直連、代理或拒絕。原始開源專案已封存，歷史上的開源核心與 Premium 分支，功能也不完全相同。因此，設定檔標示「適用於 Clash」，不代表所有名稱相近的用戶端都能讀取，更不代表支援目前所有協定。

Clash.Meta 在這套設定體系上擴充了協定、DNS 與路由功能，後續以 mihomo 之名持續維護。網路教學中的 Meta、Clash Meta 與 mihomo，通常指的是同一條核心演進路線，但不同時期的教學可能描述不同階段的行為。遇到新協定、規則參數或 DNS 欄位時，應確認目前執行核心實際支援的功能，不要只憑文章標題中的名稱判斷相容性。舊範例有助於理解架構，但不能取代目前的欄位說明。

用戶端負責管理，核心負責處理連線

用戶端是管理介面，真正執行協定握手、網域名稱解析、策略選擇與連線轉送的是核心。Clash Verge Rev 提供桌面設定管理與連線檢視介面；FlClash、Clash Meta for Android 等用戶端也有各自的操作方式與系統整合功能。同一個核心在不同介面中，設定名稱、設定合併順序與權限申請流程可能不同。用戶端能啟動，不代表核心已接受訂閱中的所有節點；設定匯入成功，也不代表每個節點都能通過驗證。

跨平台選擇可先考慮首推的 Clash Plus，再依所需功能比較其他用戶端。Clash Plus 支援多個平台，不代表各平台的內部實作完全相同，也不應只憑產品名稱推斷其使用的核心。若需要查看桌面規則與管理覆寫設定，可再評估 Clash Verge Rev。安裝檔下載頁列出可選用戶端；其中 Clash for Windows、ClashX Meta 已停止維護，參考舊資料時，請區分已封存的用戶端與仍持續演進的協定功能。

先確認目前執行的核心

開啟用戶端的設定或關於頁面，查看核心名稱；如果介面只顯示用戶端資訊，請查看啟動記錄中的核心識別資訊。區分穩定版與 Alpha 版：後者通常用來驗證較新的變更，並不是自動提升連線效能的開關。日常使用建議維持穩定環境；只有明確遇到已修正的問題，或需要驗證特定功能時，才測試其他版本。切換前先備份設定，避免同時變更版本與更新訂閱，導致難以判斷故障原因。

遷移時，先確認設定能否通過解析，再檢查節點能否建立連線，最後確認規則是否如預期套用。這三個階段分別對應欄位支援、協定互通與路由邏輯。共用 YAML 格式只代表結構相近，不保證欄位、預設值與擴充功能完全一致。若舊設定依賴指令碼、特定規則提供者行為或用戶端專用的替代機制，請逐項確認替代方案；不要為了讓解析通過就大量刪除未知欄位，否則設定可能仍能啟動，但實際行為已經改變。

SS 與 VMess：基礎封裝的取捨

Shadowsocks 的簡潔架構

Shadowsocks 通常簡稱 SS，透過用戶端與伺服器共用金鑰建立加密代理。早期設計著重降低協定負擔，部署方式也較直接，不會強制為每條連線建立完整的 TLS 工作階段。對使用者來說，最常見的參數是伺服器位址、連接埠、加密方法與密碼。參數較少不代表可以任意替換：伺服器使用哪種加密方法，用戶端就必須選用相同方法；即使密碼相同，演算法選錯仍無法正常通訊。

現代部署應區分舊式串流加密、AEAD 加密與 Shadowsocks 2022 系列。AEAD 將加密與訊息驗證結合，接收端可以確認資料是否遭到竄改；2022 系列也調整了金鑰與工作階段的處理方式。這些都不是可以隨意套用在舊節點上的「加強模式」。部分加密方法要求符合長度規範的編碼金鑰，不能直接以一般密碼取代。訂閱中出現特定加密方法時，先確認目前核心支援該方法，再核對伺服器端參數；不要只為了通過輸入欄位檢查，就手動改成其他名稱。

SS 可處理 TCP；若連線雙方都支援並啟用，也可以轉送 UDP，但兩者採用不同的處理路徑。網頁可以開啟、語音連線卻失敗，可能只是 UDP 沒有端對端連通。外掛則是另一層擴充：部分 SS 部署會透過額外外掛封裝流量，用戶端必須支援相同的外掛與選項。支援 SS 不代表支援任意外掛組合；遷移節點時若漏掉外掛欄位，常見狀況是位址與密碼看似正確，連線建立後卻立即中斷。

VMess 的驗證與傳輸組合

VMess 源自 V2Ray 生態系，圍繞使用者識別、驗證與資料傳輸設計，常以 UUID 作為身分參數。它與 SS 的差異不只是把密碼換成 UUID，驗證與封裝方式也不同。VMess 可以搭配不同傳輸方式，因此兩個同樣標示為 VMess 的節點，可能一個使用直接 TCP，另一個則使用 WebSocket 搭配 TLS。連線流程、憑證要求與中間設備的相容性也會隨之改變，不能將單次測試結果套用到所有 VMess 節點。

檢查 VMess 節點時，應一併核對身分參數、傳輸類型、是否啟用 TLS，以及路徑或服務名稱等擴充欄位。VMess 驗證也與時間有關，裝置系統時間不準可能導致驗證失敗；遇到這類錯誤時，先恢復自動校時，再檢查帳號。舊教學可能還會提到與早期驗證方式相關的參數，新設定通常採用現代 AEAD 用法。不要只為了模仿舊截圖而新增歷史欄位，也不要把用戶端接受某個欄位，當成伺服器仍使用該機制的證明。

如何從現有節點中做選擇

若需求是一般網頁瀏覽與檔案傳輸，在伺服器端條件相近時，SS 的設定通常較容易核對，故障變因也相對較少。若現有服務使用 VMess，且參數完整、運作穩定，就不必只因協定名稱較早而遷移。加密成本也取決於裝置處理器與演算法實作：具備硬體加速的桌機，與低功耗路由器的表現可能差異明顯。不能只根據協定欄位數量估算效能，更不能把協定出現的先後當成品質排名。

實際比較時，先固定相同裝置、相同網路連線與相近的伺服器區域，再分別檢查連線建立、持續傳輸與 UDP 應用。若兩個節點來自不同線路，線路差異往往比協定差異更大。記錄故障發生在解析、驗證還是傳輸階段，比反覆切換加密方法更有幫助。不確定參數時，請向訂閱服務商確認；不要讓試錯後的設定覆蓋訂閱原始檔，否則下次更新可能還原參數，讓問題看起來像是反覆發生。

Trojan 與 VLESS：驗證與傳輸分層

Trojan 在 TLS 連線中進行驗證

Trojan 的常見實作以 TLS 為基礎，將代理驗證與請求放在受保護的連線中。TLS 負責傳輸加密與伺服器身分驗證，Trojan 則確認使用者是否有權使用代理。這種設計運用成熟的 TLS 生態系，同時保留較直接的代理請求架構。節點通常包含伺服器、連接埠、密碼與伺服器名稱；即使欄位不多，憑證、網域名稱與伺服器監聽設定仍須彼此相符，否則連線會在驗證前失敗。

伺服器位址與 TLS 伺服器名稱是不同概念。位址決定連線目的地，可以是網域名稱或 IP；伺服器名稱通常用於傳送 SNI 與驗證憑證名稱，告知伺服器要使用哪個網站設定。訂閱若提供專用的伺服器名稱，應保留該值，不要隨意改成位址欄中的 IP。憑證過期、憑證鏈不完整或名稱不相符時，應在伺服器端或正確的設定位置修正，不應把停用驗證當成一般相容性處理方式。

Trojan 不保證比其他協定更快。建立新連線需要完成底層連線與 TLS 握手，實際耗時會受往返時間、工作階段恢復與用戶端連線重用行為影響。常見的 Trojan 用法透過 TCP 隧道承載代理資料；若要轉送 UDP，也須確認雙方實作與設定是否支援。不能因為應用程式使用 UDP，就推斷節點外層也使用 UDP。協定名稱描述的是代理層，實際網路表現還會受到外層傳輸方式影響，這是理解節點差異的重要區別。

VLESS 將輕量驗證與外層安全分開

VLESS 源自 V2Ray 相關生態系，採用較精簡的身分驗證與請求架構。VLESS 本身不提供類似 SS 的獨立內容加密，通常需要 TLS、REALITY 等外層機制保護傳輸。若認為「沒有加密所以更快」，就忽略了完整的連線堆疊：實際節點可能包含驗證、傳輸封裝、加密握手及其他流量處理。應比較完整組合，例如 VLESS 搭配 TLS 與某種傳輸方式，而非只比較設定中的類型名稱。

REALITY 是配合特定伺服器部署使用的安全機制，不是可以任意加到任何 VLESS 節點上的選項。使用時須提供正確的公鑰、短識別碼、伺服器名稱及相關握手參數，實際欄位依用戶端實作而異。公鑰錯誤與 UUID 錯誤發生在不同階段：前者可能導致安全握手失敗，後者則可能在後續身分驗證時失敗。訂閱若缺少其中一項，不應拿另一個節點的欄位拼湊補齊；所有參數都必須來自同一套伺服器設定。

VLESS 的 flow 也不是通用的加速等級。它會選擇與伺服器相配的資料流處理方式，並須符合相應的安全層與傳輸條件。WebSocket 路徑、gRPC 服務名稱也會影響實際路由，不是備註文字。若節點只支援特定組合，變更傳輸類型不會自動改變伺服器設定。修改前先確認伺服器實際提供的入口；只在用戶端把下拉選單改成看起來較新的名稱，通常只會造成協定不相容。

分別檢查憑證與傳輸錯誤

遇到 TLS 錯誤時，先檢查系統時間、憑證效期與伺服器名稱，再確認本機憑證環境是否異常。如果 TLS 握手成功，之後才中斷，請接著核對密碼、UUID、路徑、要求標頭與服務名稱。記錄中的「連線遭重設」只表示對端或路徑上的設備終止了連線，不能單憑這項訊息判定密碼錯誤。應依失敗階段逐步排查，必要時請伺服器管理員檢查對應入口的記錄，不要在用戶端不斷切換無關的安全選項。

選擇時，若環境已有可靠的 TLS 部署，且希望參數架構較直接，可評估 Trojan；若明確需要 VLESS 相關的傳輸組合或資料流處理功能，再選用相應的 VLESS 節點。兩者都需要完整且可信的伺服器端參數。只匯入訂閱的使用者，應優先保留服務商產生的設定，並確認用戶端支援整套組合。若只是想了解欄位名稱，可參考術語表，日常使用不必手動重建整套節點。

Hysteria2 與 TUIC：以 QUIC 為基礎的傳輸路徑

為什麼以 UDP 建構傳輸方式

QUIC 在 UDP 之上實作連線管理、安全握手、可靠傳輸與多重資料流。它不是把 TCP 資料直接改裝成 UDP 封包，而是將原本由傳輸層負責的部分功能，交由使用者空間的協定實作處理。多個資料流可減少單一資料流封包遺失造成的交付阻塞，但仍可能共用壅塞控制與路徑頻寬。Hysteria2、TUIC 利用 QUIC 建構代理協定，目的是在特定網路條件下提供更彈性的傳輸方式，而不是保證在所有網路環境都優於 TCP。

使用這兩類節點前，先確認網路連線允許相應的 UDP 通訊。有些網路對 UDP 採用不同的逾時、限速或轉送策略，能直接瀏覽網頁不代表 QUIC 代理也能使用。若節點一直停留在握手階段，先檢查 UDP 是否可達、連接埠與伺服器是否正在監聽，再核對驗證資訊。將問題一概歸因於密碼錯誤只會浪費時間；同一伺服器上的 TCP 節點可以連線，只能證明另一條傳輸路徑正常，不能證明 UDP 入口也正常。

Hysteria2 的頻寬與壅塞控制

Hysteria2 以 QUIC 為基礎，提供適用於高往返時間與封包遺失網路的傳輸方案。壅塞控制行為可能與頻寬設定有關，實際效果也受伺服器端策略影響。設定中的上行與下行參數，是傳輸控制的輸入值，不是購買頻寬或解除線路限制的按鈕。填入遠高於實際網路能力的數值，可能造成排隊、封包遺失，並拖慢其他應用程式的回應。請依本地網路能力與伺服器說明設定，再在可重複的條件下觀察結果。

Hysteria2 與早期的 Hysteria 協定並不相容。節點名稱都包含 Hysteria，不代表只要修改類型欄位就能完成遷移。驗證、混淆與連接埠相關設定都須依雙方實作重新確認。若啟用連接埠跳躍，伺服器與中間轉送設備也必須共同支援相應範圍；只在用戶端填入多個連接埠，不會自動建立伺服器入口。家用路由器或電信網路的連線追蹤方式，也可能使同一節點在不同網路下表現不一。

TUIC 的驗證與 UDP 轉送模式

TUIC 同樣以 QUIC 為基礎，將可靠資料流傳輸與 UDP 轉送納入同一套連線架構。不同協定世代的驗證參數與行為可能不同，因此訂閱中的類型、使用者識別、密碼及實作要求都必須相符。用戶端出現 TUIC 選項，只能表示具備某種程度的 TUIC 支援，不代表支援所有舊設定。向節點服務商確認協定世代與建議使用的用戶端，比嘗試刪除看不懂的驗證欄位可靠，尤其是將舊分享連結匯入新核心時。

TUIC 的 UDP 轉送模式會影響資料承載方式與封包遺失的處理。原生資料報方式與透過可靠資料流承載，不只是速度不同：前者較接近原始 UDP 的封包遺失特性，後者則可能因舊資料重傳而影響即時性。壅塞控制選項也必須符合實作支援範圍。線上遊戲、語音與一般下載對封包遺失和重傳的容忍度不同，應依實際應用測試，而不是照抄另一條線路的設定，選擇看起來較積極的模式。

QUIC 具備連線遷移等功能，但協定本身具備功能，不代表某個用戶端在任何網路切換情況下都能維持連線。系統網路擴充功能、伺服器端策略與應用程式逾時都可能中斷工作階段。若裝置經常在 Wi-Fi 與行動網路之間切換，應將實際切換測試納入選擇標準。選用 Hysteria2 或 TUIC 時，保留一個可靠的 TCP 類備用節點也很實用：網路環境改變時，可先恢復連線，再判斷是否受到 UDP 路徑限制。

連線速度、傳輸量與資源用量

把「快」拆成不同階段

測試節點時，最容易混淆的是連線耗時、首次回應與持續傳輸量。連線耗時包含位址解析、底層握手與驗證；首次回應還包括目標服務處理與回程；持續傳輸量則受壅塞控制、路徑容量與伺服器資源影響。用戶端的一次 URL 測試，通常只反映特定目標與測試方式下的部分流程。數值較小不一定代表下載較快，也不表示影片、語音或長連線會更穩定；應先確認想改善的是哪一種使用體驗。

SS 的常見封裝不會強制進行完整的外層 TLS 握手；Trojan、VLESS 的實際握手流程取決於安全層與傳輸方式的組合；Hysteria2、TUIC 則運用 QUIC 的連線機制。工作階段恢復與連線重用都可能影響握手階段，因此同一節點第二次存取比第一次順暢，不一定代表網路突然改善。比較時應區分冷啟動與已建立連線後的使用體驗，不要在一個節點已經預熱、另一個才剛啟用時就直接下結論。

傳輸量上限往往不在協定本身

持續下載的上限可能來自本地 Wi-Fi 訊號、伺服器出口、目標網站、裝置處理器或中間網路。在高封包遺失的路徑上，壅塞控制可能大幅影響結果；在往返時間短且穩定的路徑上，額外封裝與實作效率則可能更容易觀察。不能把某個協定單次測得的峰值當成普遍能力。若切換節點時連伺服器區域與電信線路也一併改變，就無法單獨判斷協定的影響，最多只能說目前這組節點更適合此次測試條件。

多重連線可減少重複建立連線的成本，但也會改變不同工作之間的相互影響。將多條邏輯連線集中到一條外層連線，可能減少握手次數，也可能讓排隊與故障影響集中；是否有改善，取決於外層協定與實作。伺服器未配合支援時，不要自行啟用多重連線，也不要認定不同用戶端中名稱相同的開關使用相同機制。分別測試網頁、多媒體與檔案傳輸，通常比只看開關說明中的「最佳化」更有效。

處理器、記憶體與背景工作

資源用量不只來自加密。使用者空間的協定處理、封包封裝、規則查詢、DNS 快取、記錄寫入與連線統計都會消耗資源。在低功耗裝置上，演算法是否支援硬體加速、核心編譯與實作是否有效率，可能比協定封包多幾個欄位更重要。路由器還須考量並行連線數與記憶體容量。桌機輕鬆處理的設定，移到小型裝置後可能讓處理器長時間維持高負載，導致傳輸量下降，但這不代表伺服器線路變慢。

觀察資源用量時，應維持相同負載：先記錄閒置時的背景狀態，再開啟固定數量的應用程式，最後測試持續傳輸。除錯記錄會增加寫入與格式化負擔，排查完成後請恢復正常記錄層級。若連線數持續增加，但實際工作已停止，應檢查應用程式是否不斷重試、DNS 是否解析失敗或策略是否形成循環，不要直接認定是協定「吃記憶體」。部分資源增加來自快取與連線生命週期，短時間截圖不能證明有長期記憶體洩漏。

策略群組也會影響觀察結果。url-test 通常依指定的探測結果自動選擇節點，fallback 著重依序選擇可用項目，load-balance 則可能將不同連線分配到不同節點。測試某種協定時，應暫時固定選擇單一節點，避免策略群組在背景變更出口。若要了解各種策略的適用範圍，可閱讀策略群組類型詳解；策略群組負責選擇節點，不會改變節點本身的協定實作。

結論應寫成有條件的判斷，例如「這台裝置在目前的 Wi-Fi 網路使用這個節點較穩定」，而不是「某種協定永遠最快」。網路或裝置改變後，舊結果就需要重新驗證。如果所有協定都無法連到相同目標，也應考量目標服務本身、DNS 與路由規則。將問題拆解到具體階段，可以避免只為追逐協定名稱而更換用戶端，卻沒有解決真正限制連線的環節。

行動裝置耗電與系統接管範圍

耗電來自整段工作流程

行動裝置的耗電表現取決於螢幕、無線通訊、處理器、背景排程與代理工作等多種因素，協定加密只是其中一環。行動網路持續收發資料與頻繁喚醒，會讓裝置維持較活躍的無線狀態；訊號微弱、重複傳輸與應用程式不斷重試，也會增加耗電。因此，不能為 SS、Trojan 或 QUIC 類協定排出固定的耗電名次。同一協定在 Wi-Fi 與行動網路，甚至在同一地點不同訊號條件下，都可能有不同表現。

維持連線與反覆重新連線的成本不同。長連線可減少重複驗證，但心跳過於頻繁會增加背景活動；心跳間隔過長，中間設備則可能釋放工作階段，讓應用程式下次存取時重新建立連線。QUIC、TCP 與不同代理實作的保活機制各不相同，不要直接照抄其他用戶端的心跳間隔。日常使用先採用服務商與用戶端提供的合理預設值；只有明確觀察到閒置斷線或背景頻繁喚醒時，再針對相關機制調整。

系統代理不等於完整接管流量

桌面系統代理主要影響遵循該設定的應用程式，不會自動接管所有 UDP 流量與自建網路堆疊的連線。TUN 模式透過虛擬網路介面接收流量，再交由核心處理，通常涵蓋範圍較廣，但也會增加路由、DNS 與權限等條件。兩者是流量進入代理的方式，不是代理協定。將系統代理切換為 TUN，不會把 VMess 變成其他協定，也無法修正伺服器密碼錯誤；它只會改變哪些連線能進入代理規則流程。

Android 用戶端通常透過系統 VPN 介面接收裝置流量，背景連線則會受到廠商電池策略、背景權限與應用程式休眠影響。若鎖定螢幕後斷線，先確認系統是否限制用戶端在背景執行，再檢查是否只有某個節點的閒置工作階段遭到回收。允許背景執行有助於維持連線，但也可能增加裝置保持活動的時間。調整時一次只變更一項，並實際觀察待機狀況，不必關閉所有電池限制。

iOS 用戶端依賴系統網路擴充功能運作，記憶體與背景行為由系統管理。選擇用戶端時可先考慮首推的 Clash Plus，再依實際訂閱支援與裝置使用方式評估；安裝入口請見iOS 用戶端專區。不要直接將桌面版的核心切換方法、程序管理習慣或本機檔案路徑套用到行動裝置。系統終止網路擴充功能、應用程式顯示已中斷，以及節點握手失敗，分屬不同層面，應分別查看系統狀態與用戶端記錄。

策略探測與記錄也會耗電

策略群組定時探測會主動發出請求；若設定中同時有大量健康檢查，即使沒有瀏覽網頁，裝置仍可能持續產生網路活動。縮短探測間隔不一定能讓服務更穩定，反而可能增加喚醒與請求負擔。請依實際需求保留必要的檢查目標與週期，並區分「背景檢查」與「主動測試所有節點」。訂閱與規則資料也應設定合理的更新週期，避免為了即時更新而在行動網路上重複下載大型檔案。

規則分流可以讓不需要代理的流量直接連線，減少不必要的代理封裝，但效果取決於規則是否正確。全域代理會將更多連線送往節點，不代表每個應用程式都會因此改善；直連模式也不代表用戶端完全沒有背景工作。應用程式排除、區域網路存取與 DNS 路由需要互相配合，避免流量走一條路徑、解析卻走另一條無法使用的路徑。若某個應用程式只在啟用代理後異常，可先確認連線是否進入核心，再查看套用的是哪條規則。

行動裝置的實用選擇順序是：先確保訂閱相容，再測試背景連線與網路切換後的恢復能力，最後觀察電量。經常使用語音或遊戲的使用者，還需要驗證 UDP 流量，不能只測試網頁瀏覽。如果 TCP 類節點在目前的行動網路表現穩定，就沒有必要只為了「新協定」改用 QUIC；反過來，若某個 QUIC 節點在弱網路環境更適合實際需求，也應以持續使用的表現為準，不要只因背景耗電標示較高就立即排除。

訂閱格式與設定相容性

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

訂閱 URL 是取得內容的網址，本身不是內容格式。伺服器可能依請求方式回傳節點分享連結、編碼後的連結清單、Clash 格式 YAML，或其他用戶端專用格式。某個網址能在一款應用程式匯入，不代表另一款應用程式收到的內容完全相同。匯入失敗時，先確認服務商是否提供適用於目前用戶端的入口，再檢查回傳內容是否為有效設定；登入頁面、錯誤訊息與流量到期通知，都可能被誤當成訂閱內容下載。

節點分享連結描述單一節點；節點清單提供可選伺服器；完整設定則可能包含策略群組、規則、DNS 與監聽設定。這三者不能混為一談。只匯入節點時，用戶端通常需要產生或補上路由架構；匯入完整設定時，則可能覆蓋原有設定。轉換服務可以改變格式表示方式，卻不能讓目標核心新增協定支援。若目標不支援某種傳輸組合，即使轉換後產生了合法 YAML，節點仍然無法運作。

轉換時最容易遺失的欄位

基本位址與連接埠通常容易保留，複雜選項則較可能在轉換時遺失，例如 TLS 伺服器名稱、WebSocket 要求標頭、gRPC 服務名稱、REALITY 參數、資料流處理方式與 UDP 相關設定。遇到「節點在原用戶端可用，轉換後卻無法使用」時，應比較同一節點中已遮蔽敏感資訊的參數，而不只是顯示名稱。有些轉換器會移除未知欄位，也有些會將欄位寫在目標核心不認得的位置；兩種情況都可能看似匯入成功，實際上卻無法連線。

將訂閱分享給第三方轉換服務，也涉及存取憑證。訂閱 URL 通常包含可識別帳號的路徑或參數，上傳完整網址可能讓對方取得相同的訂閱內容。請優先使用服務商直接產生的相容格式，或在可信任的環境中處理。向他人求助時，移除網址中的憑證、節點密碼與 UUID 等身分資訊，只保留排查所需的欄位結構。節點名稱與伺服器網域也可能透露個人使用資訊，請依實際需要遮蔽。

區分訂閱原始內容與本機覆寫設定

用戶端可能會合併訂閱內容、本機覆寫、全域設定與設定增強，產生核心實際執行的設定。直接修改訂閱快取，下次更新時通常會被覆蓋。若要長期保留 DNS、規則或策略調整，應使用用戶端明確支援的覆寫機制，並確認合併規則：清單可能是追加，也可能會整份取代。尤其規則會依順序比對，追加在兜底規則之後的項目可能永遠不會套用；不能只看到文字存在，就認定設定已生效。

以下是用來理解規則順序的 mihomo 設定片段，不包含節點定義。網域後綴規則會先處理指定網域，私有位址則直連，最後才套用兜底策略。這裡的 PROXY 必須在完整設定中對應到實際節點或策略群組。no-resolve 用來避免這條位址規則額外觸發網域解析，並不是關閉整份設定的 DNS 功能，也不保證連線過程的所有階段都不會發生解析。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

YAML 對縮排與資料型別有要求，建議使用空格縮排，不要在層級中混用定位字元。含特殊字元的值須正確加上引號；欄位拼字也必須符合核心要求。解析錯誤通常會指出附近的行號，但根本原因可能在前一行，例如引號未閉合或缺少清單標記。先修正語法再測試網路，避免設定根本尚未載入，卻反覆切換節點。如果用戶端仍保留舊的執行中設定，介面看起來還能連線，也不代表新設定已經套用。

更新設定前先保留可還原的副本；更新後先確認解析成功，再檢查策略群組引用與重要規則。若所有節點同時消失，應先檢查訂閱內容與篩選條件；若只有一種協定出錯，再檢查協定欄位與核心支援。若節點能連線，但流量走錯出口，則應查看規則套用結果與覆寫設定。將格式、協定與路由分成三個層面檢查，比把所有異常都歸因於「訂閱失效」更準確，也能減少與服務商來回確認。

依使用情境選擇與排查故障

先選擇容易維護的用戶端與完整設定

一般使用者首先需要的是參數完整、更新方式清楚，而且能在裝置上穩定運作的用戶端。可先評估首推的 Clash Plus，再依桌面管理、行動裝置背景執行或 Linux 使用需求選擇其他用戶端。Clash Verge Rev 適合需要管理桌面設定與查看連線的使用者；FlClash 支援多個平台；Clash Meta for Android 則提供 Android 用戶端選項。Surfboard 支援的匯入格式與功能應另外確認，不能因為它和其他用戶端列在同一下載頁，就推斷它支援所有 Clash YAML 擴充功能。

伺服器與路由器使用者可以直接執行 mihomo 核心，但需要自行處理服務啟動、檔案權限、路由與設定更新。桌面使用者通常更適合採用圖形介面用戶端，避免將時間花在與實際使用無關的程序管理上。安裝前先確認作業系統與處理器架構，安裝後再核對核心功能。選擇用戶端與選擇協定是兩件事：前者影響管理方式與系統整合體驗，後者決定節點如何通訊；不必只為了切換到現有環境已支援的協定，就重新安裝整套環境。

依使用情境選擇測試重點

日常瀏覽與辦公，應優先關注首次存取、連線穩定度與規則是否正確；已經穩定運作的 SS、VMess、Trojan 或 VLESS 節點都能繼續使用。傳輸大型檔案時，應觀察持續傳輸量、處理器負載，以及其他工作是否受到排隊影響。高往返時間或有封包遺失的路徑，可評估 Hysteria2、TUIC，但前提是 UDP 路徑可靠。會議、語音與遊戲則須驗證實際應用程式的資料流，不能只以瀏覽器能否載入網頁作為判斷標準。

經常存取區域網路裝置的環境，也應驗證私有位址、區域網路網域名稱與虛擬網卡路由。若使用 TUN，請檢查印表機、共用資料夾與本機服務是否仍能正常存取。遠端辦公軟體可能有自己的代理設定與憑證要求，請依應用程式文件設定。這類相容性問題往往與流量接管方式和路由有關，不一定需要更換節點協定；盲目切換協定可能暫時改變連線行為，卻留下尚未解決的路由衝突。

依故障階段逐步縮小範圍

從本機開始排查：確認目前已啟用正確設定、核心正在執行，而且應用程式確實經由代理入口連線。接著檢查 DNS 是否取得預期位址、伺服器連接埠是否可連，再查看安全握手與身分驗證。最後才檢查目標連線與規則套用結果。只有進入核心的連線，才有機會從記錄與連線頁判斷路由；如果完全看不到該應用程式的連線，應先檢查系統代理、應用程式設定或 TUN 流量接管，而不是修改節點密碼。

同一份訂閱中的所有節點同時失敗，應優先檢查本機網路、設定載入、訂閱狀態與共用 DNS 設定；只有單一節點失敗，先檢查伺服器與參數；只有某類協定失敗，則檢查核心支援與相應的傳輸路徑。節點已連線但部分網站無法使用，應檢查目標 DNS、規則與伺服器出口。依照這個分流順序，可以逐步縮小問題範圍，避免同時修改多個參數。其他本機問題請參考常見問題；首次測試方式請見系統代理設定。

向服務商回報問題時，請提供裝置系統、用戶端、核心名稱、協定類型與故障階段，並附上已遮蔽敏感資訊的相關記錄。保留原始錯誤訊息通常比只說「不能用」更有幫助，但不要提交整份訂閱或驗證資訊。節點逾時的詳細排查方式可參考由近到遠的排查順序。若正在比較不同協定，也請記錄測試時使用的網路，以及是否固定選擇單一節點，方便對方在相同條件下重現問題。