Clash 協定與核心
相容性與使用情境選擇

一、協定、傳輸與代理入口

節點名稱不能代表實際連線結構

客戶端中的一個節點，實際上是一組連線參數。伺服器位址與連接埠決定連線目的地；協定規範驗證與資料封裝方式；傳輸方式決定資料透過哪種通道送達；TLS 則可能負責通道加密與身分驗證。節點顯示名稱只是方便辨識的標籤；名稱中標示某種協定，不代表設定中的類型一定相同。判斷相容性時，應查看節點詳細資料中的實際類型，而不是依名稱、地區或圖示猜測。

這些層次常被混為一談。例如 VLESS 是代理協定，WebSocket 是傳輸方式，TLS 是安全通道機制，三者可以用在同一條連線中。QUIC 則建構於 UDP 之上，並整合安全交握與多工串流。若只說「比較 VLESS 和 QUIC」，就是把不同層次的項目放在一起比較。更準確的做法是比較完整組合，例如某種 VLESS 傳輸組合與某個 Hysteria2 節點，並註明客戶端和核心。

從應用程式到目標服務的四段路徑

一次代理連線可拆成四個環節：應用程式到本機入口、本機核心到代理伺服器、伺服器到目標服務，以及目標服務回傳資料。系統代理通常只影響遵循該設定的應用程式；TUN 則透過虛擬網卡與路由機制接收相應流量。這些設定決定流量如何進入核心，不會將 SS 節點轉換成 Trojan，也不會自動補上伺服器欠缺的 UDP 轉發能力。本機接管範圍與節點協定應分開檢查。

規則模式會在流量進入後，為連線選擇策略。符合 DIRECT 的連線會直接送出；符合代理策略組的連線才會使用對應節點。因此，「切換節點後網頁表現沒變」有時不是協定差異不大，而是該網頁一直走直連，或連線仍沿用舊工作階段。先在連線面板確認符合的規則、策略鏈與目標位址，再進行比較，才不會把規則設定錯誤誤認為協定效能問題。

選擇前應固定的條件

要公平比較協定，至少應固定代理伺服器所在網路、目標服務、測試裝置與大致測試時段。同一地區的兩個節點，可能使用不同線路、共用不同頻寬，也可能承受截然不同的負載。此時某個節點比較快，只能說明它在目前條件下更合適，不能據此推論它使用的協定普遍較快。若無法在同一伺服器上對照，仍可依實際體驗選擇節點，但結論應限於這組實際搭配，而非協定排名。

還要區分設定可解析、連線可建立、目標服務可正常使用這三種狀態。成功匯入設定，只代表語法與部分欄位已被接受；交握成功，只代表客戶端與伺服器完成驗證或建立通道；語音、遊戲或影片能否正常使用，還取決於 UDP、DNS、路由與目標服務。排查時應逐層進行，不要看到連線狀態顯示正常，就認為整條資料路徑都已驗證。

本頁採用的順序也是實際選擇順序：先確認伺服器端提供哪些功能，再檢查核心是否支援，接著評估網路條件與資源成本，最後驗證實際服務。協定不會憑空改善線路，客戶端也無法單方面啟用伺服器尚未部署的功能。先釐清這個界線，之後看到頻寬參數、壅塞控制或保持連線選項時，才不會把調整參數當成解決所有連線問題的捷徑。

二、Shadowsocks 與 VMess 的設計取捨

Shadowsocks：較精簡的代理封裝

Shadowsocks 通常簡稱 SS，早期便形成輕量加密代理的使用模式。其核心概念是將代理請求與資料加密封裝，再由伺服器解封裝並轉送至目標。客戶端設定通常以伺服器、連接埠、密碼和加密方法為主，概念較集中。不過，「SS」並非永遠不變的單一格式；不同世代的加密方案與擴充功能，在金鑰需求、實作支援及設定細節上都有差異，不能只因類型相同就直接互換欄位。

常見的 AEAD 方法會結合加密與完整性保護，不宜將舊式串流加密方案的使用經驗直接套用到新設定。SS 2022 另有不同的金鑰與協定需求，部分實作也支援多使用者相關結構。遇到指定方法時，應完整保留方法名稱與金鑰格式。一般密碼、編碼後的金鑰與多段金鑰並非相同輸入；客戶端能儲存字串，不代表伺服器會依預期方式解讀。

SS 的資源成本取決於實際加密演算法、硬體加速與實作品質。支援相關指令集的處理器，可能較適合某些 AES 方案；其他裝置則可能更適合 ChaCha20 類方案。這是裝置與實作搭配的結果，不宜只看手機品牌或處理器架構就下定論。日常瀏覽網頁、傳送小檔案與使用訊息應用程式時，線路等待時間往往比這類演算法差異更明顯；與其反覆更換方法，不如先確認連線穩定。

VMess：驗證與傳輸組合更多元

VMess 源自 V2Ray 生態系，作為代理協定，涵蓋使用者身分、驗證與資料傳輸，並可搭配不同傳輸方式。常見設定包含 UUID、加密相關選項、傳輸類型與 TLS 設定。適用範圍不能只看 VMess 這個名稱：直接使用 TCP 傳輸，與使用 WebSocket 加 TLS 的連線，在建立流程、額外標頭、反向代理部署及中介設備需求上都不同。

舊版 VMess 設定中的 alterId 與早期驗證機制相關；現今常見設定使用基於 AEAD 的驗證方式，通常會看到值為零的寫法。不要為了讓舊教學中的欄位「看起來完整」而改成非零數值，也不要把舊客戶端匯出的設定直接當成目前的伺服器範本。遇到驗證錯誤時，應優先核對伺服器提供的 UUID、驗證方式與系統時間，再檢查傳輸層，避免同時修改多個無關參數。

時間同步是 VMess 排查時容易忽略的一環。身分與連接埠都正確，但裝置時間明顯不準，仍可能導致驗證失敗；裝置從休眠恢復、手動設定時區或長時間離線時，尤其值得檢查。應核對實際系統時間，而不只是桌面顯示的時區名稱。另一方面，TLS 憑證錯誤也可能與時鐘有關，但屬於另一層驗證；記錄中的驗證失敗與憑證有效期限錯誤，不應混為一談。

何時選用，以及如何理解 UDP

若設定提供者已提供結構清楚、維護穩定的 SS 或 VMess 節點，且主要用途是瀏覽網頁與一般應用程式，就不必只因協定推出得早而更換。優先確認客戶端是否支援指定方法或傳輸方式，以及連線能否穩定維持。若需要透過反向代理部署，VMess 的具體傳輸參數就更重要；若希望設定項目較少，且伺服器已有合適實作，SS 的精簡結構可能更容易維護。

僅靠客戶端中的 UDP 開關，無法保證所有 UDP 服務都能使用。核心、伺服器、節點設定與目前的傳輸組合必須共同支援，遠端防火牆也必須允許相應通訊。遊戲連線失敗但網頁正常時，先使用明確需要 UDP 的服務單獨測試，並檢查連線記錄與伺服器能力。關閉 UDP 後網頁仍正常，不代表先前的 UDP 路徑曾正常運作，也不代表該協定天生不適合遊戲。

遷移這兩類設定時，最可靠的做法是保留一份原始訂閱，在新客戶端匯入後逐項核對類型、方法、身分、傳輸方式與 TLS，再測試一個簡單網頁和一條持續連線。協定名稱相同但連線行為不同，常是因為遺漏傳輸選項或外掛設定。並非每個核心都支援 SS 外掛；看到外掛欄位時，應先查閱目標核心文件，不要刪除欄位後期待伺服器自動相容。

三、Trojan、VLESS 與 TLS 的界線

Trojan：透過 TLS 通道建立代理連線

常見的 Trojan 部署會先透過 TLS 建立安全通道，再於通道內完成代理驗證與資料傳輸。對客戶端使用者來說，除了伺服器位址、連接埠和密碼，伺服器名稱與憑證驗證也很重要。這裡的「位址」用來找到伺服器，「伺服器名稱」則參與 TLS 交握與身分檢查；兩者可能相關，但不一定完全相同。使用 IP 位址連線，同時指定網域名稱進行驗證，就是必須保留這項區分的典型情況。

TLS 憑證驗證不只是檢查「有沒有憑證」，也會檢查憑證信任鏈、有效期限與名稱是否相符。連線位址可連通但驗證失敗時，通常應檢查系統時間、SNI、憑證網域名稱與伺服器憑證鏈。啟用略過驗證或許能讓連線繼續建立，卻會移除重要的身分保障；這無法修復憑證本身。長期使用的設定應以正確名稱與憑證解決問題，而不是把略過檢查當成通用相容選項。

Trojan 的表現也會受到 TLS 工作階段重用、底層 TCP 與部署方式影響。首次連線所需的往返時間，與沿用既有工作階段或保持連線後發出的請求並不相同。重新啟動客戶端後開啟網頁的體感，不能直接拿來和另一個已保持連線的節點比較。伺服器使用反向代理或不同傳輸擴充功能時，也可能增加額外層次；這些擴充功能需要核心支援，不能因為「支援 Trojan」就推論所有組合都可用。

VLESS：分開看待身分與安全通道

VLESS 源自 V2Ray、Xray 相關生態系，其設計重點之一是精簡代理協定本身，並將使用者身分與底層傳輸、安全機制分開。特別要注意，VLESS 本身不提供負載加密保護；實際部署通常依賴 TLS 或其他受支援的安全機制保護通道。因此，「VLESS 加密較輕」不代表可以省略安全設定。伺服器與客戶端約定的安全模式，必須納入完整連線方案一併評估。

即使都是 VLESS 節點，TCP、WebSocket、gRPC 等傳輸組合也會使用不同參數。WebSocket 常涉及路徑與請求標頭，gRPC 常涉及服務名稱，TLS 則涉及伺服器名稱與憑證驗證。這些欄位在分享連結、訂閱和 YAML 中可能有不同表示方式。手動遷移時應依語意對應，不要將某種傳輸方式的路徑欄位任意套用到另一種傳輸方式；若遇到不支援的欄位，應先查閱核心文件與設定結構。

REALITY、Vision 等名稱也經常與 VLESS 一起出現，但它們並不等同於 VLESS 本身。REALITY 涉及特定安全交握設定，Vision 則屬於特定流量控制組合。客戶端支援 VLESS，不代表也自動支援這些功能。相關公鑰、短識別碼、伺服器名稱與 flow 等資訊應以伺服器設定為準。不要從其他節點複製幾個欄位來補齊，也不要因為匯入器忽略了欄位，就認定連線仍保有原本的行為。

先從實際組合分析效能差異

Trojan 與 VLESS 的客戶端 CPU 使用量，不能只根據協定標頭大小推算。TLS 實作、連線重用策略、傳輸封裝、資料量與硬體指令集都會影響結果。短連線服務更容易受到交握與解析等待影響；長時間傳輸則更受線路容量、壅塞控制與伺服器轉發能力左右。選擇時應先確認完整組合仍有維護，再比較同一網路上的可重複表現，而不是把驗證方式當成速度等級。

若網頁正常但部分應用程式失敗，應回頭檢查本機入口與流量類型。應用程式可能不讀取系統代理設定，也可能使用 UDP，或有獨立的 DNS 行為。此時改用另一種 TLS 類協定，也許剛好避開某項設定差異，但不能證明問題出在協定設計。先參考常見問題區分系統代理、TUN 與 DNS，再依連線面板判斷失敗發生在哪個環節，排查才有依據。

四、Hysteria2、TUIC 與 QUIC 傳輸

使用 UDP 承載，不代表應用程式必須使用 UDP

Hysteria2 和 TUIC 都採用以 QUIC 為基礎的設計，底層依賴 UDP。這裡的 UDP 指客戶端與代理伺服器之間的承載通道，不代表只能代理 UDP 應用程式；它們也能傳送 TCP 流量。了解這項區別很重要：瀏覽器發出的 TCP 請求可以封裝在 QUIC 中傳送，但 UDP 遊戲是否順暢，仍取決於協定實作、資料轉發方式、路徑品質與伺服器支援，不能只從底層協定名稱判斷。

QUIC 將安全交握、串流管理與壅塞控制整合在使用者空間傳輸中。多條獨立串流不必因其中一條資料遺失，就全部等待同一串依序傳送的位元組；這是它與多種服務共用單一 TCP 連線時的重要差異。不過，同一串流中的可靠資料仍需要復原，所有串流也會共用連線層級的資源與壅塞額度。「減少跨串流的隊頭阻塞」不代表封包遺失沒有代價，更不代表壅塞時每個請求都能維持原有速度。

Hysteria2：頻寬參數應符合實際路徑

Hysteria2 著重複雜的連線條件，提供頻寬相關參數與相應的壅塞控制機制。常見設定中的上行與下行數值，是客戶端與伺服器協商及控制傳送的重要輸入，不是填入後就能取得的實際頻寬。若設定值遠高於網路接取能力，可能造成佇列堆積、封包遺失增加，並影響同一網路上的其他應用程式。使用哪種控制方式、參數是否生效，也須依伺服器策略與核心實作判斷。

選擇頻寬數值時，應以目前裝置到伺服器路徑可持續達到的能力為準，而不是寬頻方案標示的數字。手機切換到行動網路後，原本適合家用網路的參數未必仍合適。若服務提供者要求保留預設協商或指定參數，應先依照說明設定；只有在重複測試都能觀察到改善，且沒有明顯增加卡頓或搶占頻寬時，才保留修改。測試時一次只調整一個方向，方便判斷上行壅塞是否影響下行確認與互動。

TUIC：驗證、版本與工作階段行為

TUIC 同樣運用 QUIC 的串流與資料報能力來傳輸代理流量，著重可靠串流、UDP 轉發與連線管理的搭配。設定可能包含 UUID、密碼、壅塞控制與 UDP 轉發方式等內容。不同協定世代之間有相容性限制，客戶端與伺服器必須使用能互通的實作。分享說明只寫「TUIC」並不足以交代所有參數；匯入失敗或交握異常時，應核對伺服器要求的協定世代與核心支援範圍。

部分 QUIC 類設定允許調整連線保持、快速復原或交握相關行為。這些選項涉及既有工作階段狀態、伺服器接受策略與網路切換，不應解讀為每次首次連線都能免除等待。早期資料也有重放等安全限制，須由協定實作與應用服務共同處理。一般使用者宜先採用客戶端與服務提供者共同支援的預設組合，再考慮微調；這通常比複製一套追求最低交握次數的參數更穩妥。

高封包遺失情境與行動網路的限制

QUIC 類協定在部分高往返延遲且有封包遺失的線路中可能較有優勢，但前提是 UDP 路徑品質沒有明顯劣於 TCP。有些網路接取服務對 UDP 使用不同的佇列、限速或閒置逾時設定，結果可能相反。連線遷移也取決於協定實作、客戶端網路堆疊與接管方式；Wi-Fi 切換到行動網路後能否不中斷，不能只憑 QUIC 支援連線識別碼就保證，實際應用中的舊連線仍須另行驗證。

若小型網頁可用，但大檔案傳輸停住，還要考慮 MTU 與路徑上的分片處理。額外封裝會減少有效負載空間，某些路徑也不適合傳送大型 UDP 資料報。不要直接將 MTU 調得極低並長期使用；應先固定節點、排除其他變因，觀察問題是否只在特定網路出現。若同一裝置在另一個網路正常，可將問題範圍縮小至路徑；若所有網路都失敗，再核對驗證、TLS 名稱與伺服器連接埠設定。

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

先區分四種不同的「快」

連線速度至少包含建立代理通道所需的時間、收到目標首位元組的時間、持續傳輸速率，以及長時間運作的穩定性。網頁開啟緩慢，可能是 DNS、交握或目標服務回應所致；檔案下載緩慢，則更可能受到路徑容量、壅塞與出口負載影響。將這些結果合併成一個延遲數值，反而會掩蓋真正差異。節點測速顯示的毫秒數，通常只代表特定請求的一次結果，不能當成頻寬、遊戲延遲與所有網站體驗的總評分。

自動測速也會受到測試網址、連線重用與逾時門檻影響。同一節點先測和後測時，可能使用不同的連線狀態；目標網站也可能對請求採用不同路由。想了解測試數值，可閱讀Clash 節點延遲測試原理。手動選擇時，先用相同測試目標確認基本連通性，再以常用服務驗證，可避免為了追求較小數字，反而選到實際體驗較差的節點。

建立可重複的比較流程

比較兩種協定組合前，先暫停訂閱更新與自動策略切換，固定由同一策略組選擇出口。關閉大型檔案同步、系統更新等競爭流量，並記錄網路接取方式與裝置供電狀態。首次開啟和重複造訪要分開測試、分開記錄；更換節點後，結束舊連線或重新開啟應用程式，避免舊工作階段仍使用前一個出口。每組重複測試數次並交替順序，比只連續測試單一節點更能降低時段造成的偏差。

頻寬測試不必持續跑滿。使用相同目標、相近測試時間與相同並行條件，觀察速率是否穩定、互動是否明顯變慢即可。若測試期間路由器與手機都出現高延遲，可能是接取端佇列壅塞，而非協定頻寬不足。若只有一個遠端目標較慢，其他服務正常，應先檢查目標或出口路徑。任何結論都應註明目前裝置、網路與完整節點組合，不要將單次結果延伸成長期排名。

CPU、記憶體與電量不可混為一談

CPU 成本來自加解密、協定封裝、使用者空間網路處理、規則比對與記錄等多項工作。QUIC 的使用者空間實作路徑，與系統 TCP 堆疊不同；這不代表它一定更耗電，但在高吞吐量、小封包密集或實作最佳化不足時，差異可能擴大。記憶體使用量則更容易受到連線數、快取、規則集與客戶端介面影響。看到某個客戶端占用較多資源，不能立刻歸因於目前節點使用的協定。

行動裝置還要考量無線電維持連線的耗電。頻繁保持連線、自動測速與定期輪詢訂閱，可能讓裝置難以進入低功耗狀態；即使每次傳輸的資料不多，累積影響仍值得留意。行動網路訊號微弱時，相同資料傳輸可能需要更多重傳，並延長無線電活躍時間。比較待機耗電時，應盡量使用相近訊號強度、相同背景應用程式與相似使用時間，不要拿訊號滿格的 Wi-Fi 和訊號微弱的行動網路直接比較。

降低耗電可先從管理使用行為著手：減少不必要的高頻測速，避免反覆切換而重建連線，關閉長時間除錯記錄，並檢查是否同時執行多個網路接管工具。TUN 是否增加成本，須視接管流量規模與平台實作而定；它的主要用途是設定流量接管範圍，不是省電模式。涉及客戶端背景權限或系統代理設定時，請回到TUN 與代理入口教學確認設定範圍。

最後選出的組合不一定是峰值速度最快的。行動辦公可能更重視從休眠恢復、弱網重新連線與耗電；桌面下載可能更重視持續傳輸量；路由器則可能受單核心效能與記憶體限制。將需求寫成可驗證的條件，例如「鎖定螢幕後仍能收到訊息」或「下載時語音不會明顯斷續」，再比較結果，比替協定貼上輕量、極速或省電等固定標籤更可靠。

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

客戶端負責管理，核心負責連線

圖形化客戶端提供訂閱管理、策略選擇、記錄與系統整合；核心負責解析設定、比對規則、處理 DNS 與實際代理連線。兩者不是同一個層次。兩款介面不同的客戶端可能使用相同核心；一款客戶端也可能允許切換核心或個別更新。判斷能否使用某協定時，應先確認實際執行的核心與能力說明，再看客戶端能否完整保留相關欄位；介面上沒有某個按鈕，不一定代表核心不具備該功能。

原版 Clash 建立了廣泛使用的 YAML 設定與規則體系。生態系歷史上也有開源核心與 Premium 分支等差異，不能把過去所有標示為 Clash 的功能都視為同一標準。經典設定中的監聽連接埠、策略組與規則順序，至今仍影響使用習慣；但不能因此推論原版核心也支援較新的協定、安全組合與網路堆疊功能。舊客戶端能開啟新的設定檔，不代表能依照新的語意執行。

Meta 與 mihomo 有承襲關係，不能任意互換

Clash.Meta 在 Clash 生態系基礎上擴充協定與網路功能，之後以 mihomo 名稱持續發展。使用者在訂閱和教學中看到 Meta、Clash Meta、mihomo，通常是在描述同一條演進脈絡，但這些名稱本身不能精確界定功能範圍。實際安裝套件內含哪個建置版本、是否啟用特定實作，仍須查看客戶端資訊。不要只把設定檔標題中的 Meta 改成 mihomo，就認為已完成遷移。

mihomo 擴充的協定類型、DNS 設定、規則提供器與 TUN 行為，可能超出原版 Clash 的解析範圍。反過來說，許多基礎 Clash 設定仍可作為起點，但也需要檢查舊欄位、平台相關選項與行為變化。設定相容性不只有「支援」或「不支援」兩種情況；某個欄位可能遭拒、被忽略，或因預設值改變而產生不同結果。遷移時應查看記錄，不要只確認程序是否成功啟動。

最容易誤判的是客戶端產生設定的環節。有些客戶端會合併訂閱、全域設定與覆寫內容，最後交給核心的檔案可能與使用者看到的訂閱原文不同。節點明明包含某個欄位，實際運作卻沒有相應行為，可能是編輯器未保留欄位，或覆寫內容蓋掉了它。排查時應優先查看執行中的設定與啟動記錄；其中可能包含訂閱網址與驗證資訊，分享前請先移除敏感內容。

依平台選擇客戶端，再確認功能支援

一般使用者可以從下載中心的 Clash Plus 推薦入口開始，再依平台考慮 Clash Verge Rev、FlClash 等選擇。Windows 另有 Clash Nyanpasu；Android 也列有 Clash Meta for Android 和 Surfboard。不同客戶端不一定使用相同核心，也不一定接受相同訂閱。尤其 Surfboard 的設定體系不能直接當作 mihomo YAML 使用；選擇客戶端時，也應確認服務提供者支援的格式。

下載頁將 Clash for Windows 與 ClashX Meta 列為停止維護的封存專案，適合有明確舊環境需求的使用者辨識來源，不適合作為新協定相容性的預設選擇。遷移前可先透過客戶端比較評測確認平台、訂閱管理與流量接管方式；需要更細的選擇依據時，再閱讀圖形化客戶端功能比較。不要只因名稱相似，就推論套件內的實作相同。

升級核心後若發生問題，先用最精簡的設定確認新核心能否啟動，再逐步恢復規則提供器、DNS 與 TUN。不要一次匯入整個舊目錄，否則快取、舊指令碼與本機設定也可能一併進入測試。桌面與手機應分別驗證：相同 YAML 的邏輯可能相近，但權限、虛擬網卡、系統 DNS 與背景執行策略都不同。核心支援某項協定，只解決連線中的部分相容問題，平台整合仍須另外確認。

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

訂閱網址無法說明回傳內容的格式

訂閱可能回傳完整設定、僅含節點的 YAML、分享連結清單，或經過編碼的文字。網址結尾有沒有副檔名，無法可靠判斷格式；有些服務還會依請求參數或客戶端識別資訊回傳不同內容。因此，在瀏覽器中看到一段文字，不代表所有客戶端都能匯入。應在服務提供者頁面選擇明確適用於目標客戶端或核心的格式，避免把其他生態系的訂閱直接交給 Clash 設定解析器。

完整設定通常除了節點，還包含策略組、規則、DNS 與監聽設定；節點訂閱則只提供代理項目，需透過本機範本或 proxy-providers 機制匯入。兩者的更新行為差異很大。匯入完整設定後再切換到另一份設定，規則也可能一併改變；若只更新節點提供器，本機策略與規則通常會保留在主設定中。了解訂閱屬於哪一類，才能解釋為何更新後節點變了，模式或分流行為也跟著改變。

轉換分享連結可能遺失語意

分享連結適合傳遞單一節點，但不一定能表達完整策略、規則與 DNS。轉換器也可能因不認識某個新欄位而將它丟棄，或把協定參數對應到不完全等價的設定項目。尤其傳輸路徑、伺服器名稱、flow、安全交握與 UDP 方式等資訊，不能只核對位址和密碼就算完成遷移。轉換後應對照原始參數、查看記錄與連線行為，不要把「轉換成功」視為相容保證。

訂閱 URL 與節點驗證資訊都可能授予實際使用權限。不要將完整訂閱貼到公開轉換網站或問題截圖中，也不要直接把執行中的設定公開到討論區。確實需要轉換時，優先使用客戶端已支援的匯入方式，或在可信任的環境中處理。教學與排查只展示必要欄位；伺服器名稱可以保留格式，但請替換成示範網域。驗證資訊、訂閱參數與本機控制介面資訊都應從分享內容中移除。

先理解設定結構，再理解覆寫順序

以下是一段可單獨用來理解分流的最小 YAML，不包含遠端節點，只設定本機監聽與直連規則。這不是代理訂閱，執行後不會取得遠端出口。範例用於說明連接埠、模式、策略組與規則之間的關係：規則中的策略名稱必須對應已存在的出站或策略組；縮排須使用空格，列表層級也應一致。實際訂閱匯入與連線步驟，請以訂閱匯入教學為準。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,出口選擇

使用者覆寫是在訂閱更新之外加入本機自訂設定，但各客戶端的「覆寫」沒有統一的合併演算法。有些會整體取代欄位，有些會附加列表，也有些會透過指令碼產生最終設定。若 rules 被整體取代，訂閱中的原有規則可能全部消失；若新規則附加在 MATCH 之後，就可能永遠不會匹配。編輯前應先確認合併方式與插入位置，更新後再查看執行中的設定，不要只檢查編輯框內儲存的內容。

策略組名稱也屬於相互引用的關係。節點更新後，如果某個名稱遭到移除，靜態引用就可能失效；篩選規則太嚴格，也可能將提供器中的節點全部排除。此時設定不一定有 YAML 語法錯誤，但組內可能沒有可用成員。應依序檢查節點提供器是否成功取得內容、格式是否正確、篩選條件是否符合，以及策略組目前的選擇。若問題實際上是空列表或引用錯誤，反覆調整縮排並不能解決。

更新後突然失效時，先保留錯誤記錄並還原上一份可用設定，再比較節點類型、傳輸欄位與覆寫結果。若只是本機監聽失敗，應檢查連接埠衝突，而不是重新轉換訂閱；相關指令可參考Clash 監聽連接埠占用排查。將下載失敗、解析失敗、引用失敗與執行失敗分開處理，才能讓錯誤訊息對應到真正需要修改的位置。

八、依使用情境選擇協定與排查問題

桌面日常網路：先保留穩定基準

桌面瀏覽網頁、同步文件與日常開發，可先使用服務提供者維護成熟、且目前客戶端完整支援的節點組合。SS、VMess、Trojan 或 VLESS 都可能符合需求，重點是交握穩定、憑證或驗證正確，以及常用服務回應一致。保留一個已驗證的基準節點，再嘗試其他協定。若切換後只改善某個網站，結論應限於該路徑；不要因此刪除其他所有類型，以免失去後續排查的對照條件。

持續下載與高並行開發工作需要留意連線管理。多個相依套件下載、容器映像檔與背景同步工作可能同時占用線路，單一檔案的峰值速度無法代表整體表現。可在相同工作集合下觀察傳輸量、失敗重試與裝置溫度；若頻寬跑滿時互動明顯變差，應先檢查接取端佇列與並行流量，再討論協定。區域網路分享也涉及本機監聽與防火牆，相關設定範圍請參考允許區域網路與分享代理設定。

行動裝置：優先考量網路切換與耗電

通勤時，手機常在 Wi-Fi、行動網路與不同訊號強度之間切換。比起固定網路中的最佳速度，更應確認切換後能否恢復連線、鎖定螢幕後是否持續運作，以及訊息連線會不會頻繁重建。Hysteria2 或 TUIC 可作為控制變因的比較對象，但必須確認 UDP 路徑與伺服器設定；若某種網路接取方式下表現不穩，應保留切換回可靠 TCP 類組合的選項。不要為了只用一種協定，就強迫所有網路共用同一套參數。

語音與遊戲更重視抖動、連續封包遺失與工作階段恢復。先確認應用程式流量確實進入客戶端，再確認所選節點支援所需的 UDP 轉發。測一次網頁延遲，只能證明該請求成功完成，不能代表即時服務的連線品質。最好使用相同應用程式、相同伺服器與相近時段進行比較，並觀察背景下載是否影響體驗。若直連也有相同問題，代理協定可能不是主要變因，應先檢查本機無線網路與目標服務。

小型裝置：資源預算決定可用範圍

在伺服器或路由器上執行核心時，應將可用記憶體、單核心效能、儲存空間與架構支援納入考量。大量規則、頻繁記錄與密集連線會疊加資源成本，不能只看閒置時的使用量。先用精簡規則與單一出口確認可正常運作，再逐步加入提供器、DNS 與流量接管功能。一般裝置若需要圖形化管理，可從下載頁選擇客戶端；直接執行 mihomo 較適合能維護服務、權限與網路路由的使用者，並非每個人都需要這麼做。

依失敗發生的位置縮小範圍

第一種情況是設定尚未啟動：查看記錄中最早出現的解析、欄位或連接埠錯誤，先處理這一項，後續錯誤可能只是連帶結果。第二種情況是無法連到代理伺服器：檢查位址解析、連接埠與網路接取方式，再換用已知可用的節點作為對照。第三種情況是驗證或安全交握失敗：依協定核對密碼、UUID、系統時間、TLS 名稱與伺服器需求，不要把所有失敗都歸咎於網路逾時。

第四種情況是通道建立後，只有部分服務失敗：檢查規則命中情況、目標解析、UDP 與傳輸大小，再查看伺服器出口連線至目標的狀態。第五種情況是休眠或切換網路後失敗：結束舊工作階段、重新建立連線，並觀察問題是否只在某類協定上重現。若重新開啟客戶端後恢復，仍須進一步區分舊路由、DNS 快取與工作階段狀態；單次重新啟動成功只能提供排查線索，不能當成長期修復方案。

記錄問題時，請保留作業系統、客戶端名稱、實際核心、協定與傳輸組合、網路接取方式及可重現步驟。記錄只截取相關時段，並移除訂閱與驗證資訊。將「匯入後不能用」具體寫成「設定成功啟動、TLS 交握失敗、另一個節點正常」，討論才有明確方向。若仍不清楚相關術語，可查閱概念速查；需要依步驟恢復基本連線時，請回到快速設定教學，從可驗證的最小連線重新開始。