Clash 協定與 mihomo 核心參考

一、協定選擇：先分清用戶端、核心與傳輸

介面顯示的協定名稱，只代表連線的一部分

代理連線通常包含本機接入、規則比對、代理協定、底層傳輸及遠端出口等環節。瀏覽器先將要求送至本機連接埠，核心再依網域或位址選擇代理群組，並透過選定的節點連線至伺服器。協定名稱主要說明用戶端與伺服器之間如何驗證、封裝及轉送資料，並不直接決定出口頻寬、遠端負載或目標網站的回應速度。

用戶端負責訂閱管理、介面設定、背景執行及系統整合；核心負責解析設定、建立連線、處理 DNS 與執行規則。同一個用戶端名稱不代表永遠採用相同核心，不同用戶端也可能使用同一核心家族。因此，判斷能否使用某類節點，應一併確認用戶端搭載的核心、相關功能選項及伺服器端要求，不能只憑介面相似就推斷相容。

分別記錄協定、傳輸方式與安全參數

例如，VLESS 是代理協定，WebSocket 是可能採用的傳輸封裝，TLS 是安全連線機制，而伺服器名稱則會用於憑證驗證或交握選擇。這些項目屬於不同層次。訂閱會將相關欄位組合成一筆節點資料；只看到一個名稱時，很容易把所有差異都歸因於協定。比較之前，應先展開節點詳細資料，記錄協定類型、傳輸方式、遠端連接埠及安全選項。

TCP 提供可靠且有序的資料流；UDP 則提供資料封包，不會替應用程式保證重傳或順序。QUIC 架構在 UDP 之上，並在協定內實作安全連線、可靠資料流及壅塞控制。節點使用 UDP，不代表所有應用程式流量都會變成不可靠傳輸。反過來說，節點透過 TCP 建立連線，也不代表它一定支援轉送應用程式送出的 UDP 資料封包；兩件事要分開確認。

先建立可重複驗證的比較條件

合理比較時，應盡量固定裝置、網路連線、目標服務及測試時段。若兩個節點位於不同地區或使用不同線路，測試結果反映的是整體路徑，而非單純的協定差異。日常選擇不必追求實驗室等級的測量，但至少應分別觀察首次開啟頁面、持續傳輸、語音通話及待機後恢復情形，別用單一測試按鈕代表所有使用體驗。

用戶端顯示的延遲通常來自對指定網址發出一次要求，結果可能包含解析、交握及伺服器回應等不同階段。各用戶端的測試方式不一定相同，數值也不宜直接橫向比較。測試通過只代表當下的測試路徑可用；目標應用程式可能使用不同網域、協定或獨立的 DNS 邏輯，仍須實際開啟應用程式驗證。

本頁討論的設定能力，以實際核心實作為準。訂閱服務提供者決定伺服器支援哪些協定與參數，用戶端無法單方面將 SS 節點改成 TUIC 節點。需要改用另一種協定時，應取得伺服器提供的對應資料，而不是只修改本機的類型欄位。後續各章的比較，也都以驗證正確、伺服器可用且參數相符為前提。

二、Shadowsocks 與 VMess：輕量轉送與協定演進

Shadowsocks 的取捨在於協定層次較少

Shadowsocks 常簡稱為 SS，設計用途是加密代理轉送。典型設定包含伺服器位址、連接埠、加密方式及密碼。直接使用時，它不要求每條連線都額外建立通用的網頁傳輸封裝，因此結構較簡潔。不過，用戶端仍須執行加密、驗證及位址封裝；「輕量」不代表沒有運算負擔，也不保證在任何網路環境下都更快。

SS 的加密方式不是可以隨意替換的裝飾欄位。傳統串流加密、AEAD 方法及較新的 Shadowsocks 2022 系列，各有不同的實作要求，部分方法也對金鑰格式有明確限制。節點詳細資料出現某種加密方式，不代表舊版核心就能載入。若遇到不支援加密方式的錯誤，應確認核心功能及原始設定，不要自行改成較熟悉的名稱。

SS 可承載 TCP，也可在相應實作及伺服器設定下轉送 UDP。兩者的網路可達性可能不同：網頁瀏覽正常、通話卻有問題時，應檢查是否支援並允許 UDP。部分設定也會使用外掛擴充傳輸，這會增加額外相依項目；完整節點資料須保留外掛名稱及選項。只複製伺服器、連接埠和密碼，可能漏掉真正決定連線方式的資訊。

VMess 的驗證方式與傳輸組合須一併檢視

VMess 源自 V2Ray 生態系，提供身分驗證及代理資料封裝，並可搭配不同傳輸方式。其設計演進涉及驗證與安全機制的變化，因此即使同為 VMess，舊版設定也不一定能互通。辨識設定時，除了使用者識別碼，還應查看傳輸類型、是否啟用 TLS、對應路徑及要求主機等欄位，不能把分享連結中的一長串內容當成完整設定說明。

較舊的 VMess 設定可能包含與舊版驗證流程有關的參數。現代設定通常採用 AEAD 驗證方式，歷史欄位的預設解讀則可能因實作而異。遷移時不要照抄過時教學中的固定參數組合，也不要為了消除錯誤而盲目增刪欄位。系統時間明顯不準也可能影響驗證或憑證判斷，因此反覆修改帳號前，應先確認裝置日期、時間及自動校時狀態。

VMess 的實際效能常受外層傳輸影響。直接使用 TCP，與透過 WebSocket、TLS 或其他中介層承載的設定，在交握流程、標頭封裝及連線重用方面都可能不同。若兩個節點的傳輸層次不同，即使協定名稱相同，首次要求時間及持續傳輸表現也可能有差異。分析時應進一步釐清「VMess 節點較慢」究竟是解析、連線、驗證還是應用程式要求階段較慢。

如何判斷是否適合在用戶端繼續使用

匯入後先確認節點沒有被核心略過，再透過代理群組選取該節點，完成一般網頁要求及一次實際業務測試。若用戶端顯示節點存在卻始終無法連線，請查看記錄中最早出現的錯誤。不支援加密方式、驗證失敗及連線逾時屬於不同問題：前者較可能是相容性問題，驗證失敗應核對憑證資料與時間，逾時則還要檢查位址、連接埠及目前網路。

若現有 SS 或 VMess 服務穩定，就不必只因另一種協定名稱較新而遷移。真正值得更換的原因包括目前核心停止維護、不支援所需傳輸方式，或現有組合在業務使用時出現可重現的問題。桌面瀏覽及一般下載可先保留熟悉且正常運作的設定；涉及即時通話時，則應另外確認 UDP 轉送能力，不要用網頁能否開啟來代替判斷。

這兩種協定也可作為遷移時的基準。更換用戶端後，先載入一筆參數明確且過去可正常運作的設定，確認本機接入及規則流程正常，再測試新協定。若所有類型都同時失敗，應優先檢查設定是否已啟用、代理群組是否選對，以及系統代理是否生效，而非逐一修改每個節點。如此可避免把用戶端接入問題誤判為協定問題。

三、Trojan 與 VLESS：驗證、TLS 與外層傳輸

Trojan 將 TLS 連線作為重要基礎

Trojan 的常見實作會以 TLS 承載代理通訊，並在安全連線中完成密碼驗證及要求轉送。設定通常包含伺服器、連接埠、密碼與伺服器名稱。它採用成熟的 TLS 機制保護傳輸，因此憑證鏈是否可信、名稱是否相符，以及裝置時間是否正確，都是成功連線的重要條件。只確認密碼正確，還不足以排除交握階段的問題。

伺服器位址與 TLS 伺服器名稱可能各自負責不同用途。前者決定連線目標，後者通常會影響伺服器憑證選擇及用戶端名稱驗證。有些部署會以位址連線、以網域驗證，訂閱必須保留相關欄位。若遷移時遺失伺服器名稱，用戶端可能改用其他名稱驗證憑證，導致舊版用戶端正常、新版用戶端交握失敗。這類差異不應直接歸因於協定實作速度。

憑證驗證失敗時，應先檢查節點要求的名稱、伺服器憑證及系統信任狀態，不要把略過憑證驗證當作一般修復方式。略過驗證會改變安全界線，也可能掩蓋設定錯誤。若伺服器使用特定信任機制，應依該服務的明確說明設定，而非從無關節點複製選項。記錄中的名稱不符、憑證過期及連線逾時，也應分別處理。

VLESS 的輕量驗證不等於完整安全方案

VLESS 主要負責身分識別及代理封裝，不應單獨視為完整的加密傳輸方案。實際部署常搭配 TLS、REALITY 或其他外層機制，採用哪種組合由伺服器端決定。使用者須核對使用者識別碼、傳輸方式及配套安全參數。只看到 VLESS 就斷定連線必定採用某種保護機制，或認為所有 VLESS 設定都能被同一個舊版核心辨識，都是不準確的。

部分 VLESS 設定包含 flow 選項，部分 REALITY 組合還涉及公鑰、短識別碼及伺服器名稱。這些不是可有可無的備註，也不能在不同伺服器之間互換。flow 的可用值取決於具體組合；刪除訂閱欄位以求順利解析，可能只讓設定成功載入，實際連線驗證仍會失敗。需要確認的是整套組合是否受支援，而非單看某個協定名稱。

WebSocket、gRPC 等傳輸方式也會改變連線建立及資料封裝方式。路徑、要求主機及服務名稱等欄位若與伺服器端路由不一致，連線可能已抵達伺服器，卻無法進入對應服務。此時的錯誤表現與密碼錯誤不盡相同。排查順序應為確認伺服器可連線、TLS 或其他安全交握成功、傳輸路由正確，最後才檢查代理驗證，避免同時修改多個層次的參數。

連線重用與 UDP 能力不能只看協定標籤

常見實作中的 Trojan UDP 轉送會透過可靠的位元組資料流封裝；VLESS 的 UDP 承載方式也取決於具體設定及實作。應用程式能否正常通話，除了協定本身允許，還受用戶端轉送方式及伺服器支援影響。可靠資料流上的資料封包可能因封包遺失重傳而排隊，但不代表所有即時服務都無法使用，仍須依實際網路測試。

連線重用可讓多個要求共用底層連線，減少重複建立連線的成本，但共用也代表故障及壅塞可能互相影響。並非所有伺服器都接受特定重用選項，開啟後也不保證速度提升。對現有訂閱，建議優先保留服務提供者的設定；若要比較重用效果，應固定同一節點與業務，只變更一項設定，並觀察短要求、長連線及恢復過程。

選擇時，若已有相符的 TLS 服務且希望參數關係明確，可考慮 Trojan；使用 VLESS 則須更仔細確認外層組合及核心功能。兩者沒有脫離伺服器端條件的通用優劣。即使用戶端回報解析成功，仍應實際發出要求驗證；若需要補充欄位，先向訂閱來源確認原始參數，不要拼湊相似節點的資料，製作出看似完整的設定。

四、Hysteria2 與 TUIC：QUIC 的優勢與限制

QUIC 改變的是傳輸組織方式

Hysteria2 與 TUIC 都利用 QUIC 建立代理傳輸。QUIC 架構在 UDP 之上，並在協定本身處理安全交握、資料流管理及壅塞控制。相較於將多種業務簡單串接在同一條 TCP 位元組資料流上，QUIC 可減少不同資料流之間因有序交付而產生的部分相互等待。不過，各資料流仍共用鏈路容量與壅塞狀態，不能把多資料流理解成每個要求都有獨立頻寬。

某條資料流遺失資料時，其他資料流不一定要等它完成有序交付，這是理解 QUIC 多資料流的重要角度。但若網路整體壅塞、伺服器出口飽和或無線鏈路品質變差，所有資料流仍可能受影響。QUIC 不會讓底層封包遺失消失，而是透過自身的確認、重傳與壅塞控制演算法因應路徑變化。因此，持續傳輸的優勢必須配合路徑條件討論，不能只依協定名稱排名。

由於底層仰賴 UDP，目前網路必須允許相應資料封包往返。有些網路可正常瀏覽一般網頁，卻會限制特定 UDP 通訊；此時 Hysteria2 與 TUIC 可能無法建立連線，或在閒置後無法正常恢復。排查時可先用已知可用的 TCP 類設定比對，再切換網路測試，不要一味增加逾時時間。逾時設定只能延後錯誤發生，無法改變底層的連線可達性。

Hysteria2：留意頻寬參數與伺服器端限制

Hysteria2 提供代理傳輸所需的驗證、TCP 資料流及 UDP 轉送能力，並採用與壅塞控制相關的設計。實際可用頻寬取決於實作、路徑、伺服器策略及採用的控制方式。設定中的上傳、下載頻寬提示，不等於購買方案的總流量，也不是填得越高越好；不切實際的數值可能增加排隊、封包遺失及其他應用程式的競爭壓力。

部分設定會提供特定混淆選項，用戶端與伺服器端必須保持一致。密碼、混淆設定、TLS 名稱及憑證信任屬於不同層次，任何一項不符都可能導致連線失敗。不同世代的 Hysteria 也不能只靠改寫類型名稱就互通。若訂閱來源明確標示 Hysteria2，應使用確實支援該協定的核心並保留原始驗證欄位，不要套用舊版協定教學。

使用者通常不必自行調整所有進階參數。先使用訂閱服務提供者的設定完成連線，再依可重現的現象評估是否需要修改。例如持續下載導致其他要求明顯變慢時，應先排除鏈路滿載及伺服器限速，再考慮頻寬提示；若連交握都未完成，則應檢查網路及驗證。用吞吐量參數修復驗證問題，通常只會增加變因。

TUIC：版本與資料封包轉送方式須相符

TUIC 同樣以 QUIC 為基礎，著重代理連線及資料轉送，並提供驗證、壅塞控制、連線保持及 UDP 轉送相關設定。不同協定世代或實作之間可能存在相容限制，不能只憑 TUIC 這四個字判斷能否互通。用戶端核心必須支援伺服器實際使用的協定格式，訂閱轉換工具也必須正確輸出相應的身分及驗證欄位。

UDP 轉送模式會影響資料封包的封裝方式及可靠性處理方式。透過 QUIC 資料封包轉送，與借助可靠資料流轉送，各有不同取捨；應用程式封包大小、容忍封包遺失的程度及網路路徑都會影響結果。若伺服器只支援其中一種模式，用戶端就不能任意切換。即時應用程式表現異常時，應先確認伺服器端說明，再檢查轉送模式，不要只看網頁連線測試是否通過。

QUIC 支援連線遷移等機制，但切換無線網路後能否維持服務，仍取決於用戶端實作、連線識別碼、伺服器策略及系統網路介面變更。無法保證從 Wi-Fi 切換至行動網路時所有應用程式都不會中斷。會議或遠端連線應實際測試網路切換及休眠後恢復；若服務無法自動重新連線，也須留意應用程式本身的恢復機制。

因此，選擇 Hysteria2 或 TUIC 時，合理的前提是已有相應服務、目前網路允許 UDP，而且實際業務在該路徑下運作良好。它們不是能替任何舊節點加速的開關，也無法取代足夠的伺服器容量與良好網路路徑。若問題只在目前網路頻繁發生，應歸類為路徑相容性問題，而不是一概認定用戶端設定損毀。

五、連線速度、資源使用與手機耗電

分開測量首次連線與持續傳輸

首次開啟頁面時，可能依序經歷網域解析、建立連線、安全交握、代理驗證及目標服務回應。協定交握只是其中一個環節。快取命中、重用既有連線或應用程式預先連線，都可能讓第二次瀏覽明顯快於第一次。比較不同節點時，應分別觀察冷啟動與連續使用情形，不要直接拿已重用連線的要求和全新連線相比。

持續傳輸更容易受到瓶頸頻寬、壅塞控制、封包遺失及伺服器資源影響。下載速度逐漸提升，不一定代表協定切換成功，也可能是連線正在擴大可用傳送視窗；速度忽快忽慢則可能來自無線干擾、遠端資源競爭或目標網站限制。若要區分原因，應在相近時段存取相同目標，並留意其他裝置是否同時使用網路，不要用不同網站的下載結果代替協定比較。

連線重用可減少重複交握，但也可能讓多種業務共用同一故障範圍。大型下載與多個短要求共用傳輸時，排隊與排程可能影響互動體驗。多資料流協定能改善部分等待情形，但無法突破共用出口的容量。日常辦公時，頁面回應穩定、工作階段可正常恢復，往往比短時間的最高傳輸量更重要；測試任務應符合實際工作，而非只下載大檔案。

加密負擔與裝置實作共同決定資源需求

CPU 使用率會受到加密演算法、硬體加速、核心實作、資料吞吐量及連線數量共同影響。同一種協定在桌上型處理器與低功耗裝置上的表現可能不同。額外封裝、資料複製、使用者空間協定堆疊及詳細記錄也會增加資源消耗。因此，無法脫離裝置條件，直接指定一種固定的「最省資源協定」，更不能把某台電腦的結果直接套用到手機或路由器。

記憶體使用量也包含連線狀態、快取、規則集、DNS 資料及用戶端介面等部分。啟用 TUN 後，應用程式流量進入核心的路徑會改變，資源使用情況也可能不同，但 TUN 本身不會把節點協定換成另一種類型。更換用戶端後若耗電增加，應分別確認接管範圍、背景常駐、記錄層級及訂閱更新頻率，再判斷是否與協定實作有關。

低功耗裝置尤其應避免長時間進行無意義的完整探測。自動檢查大量節點、頻繁更新訂閱及過密的健康檢查，都會喚醒網路。即使每次要求傳輸的資料很少，長時間讓無線模組保持活動也可能影響待機時間。先將檢查範圍縮小至實際使用的代理群組，並採用符合需求的檢查間隔，比反覆切換協定名稱更容易得到可解釋的結果，也更能省電。

手機使用還應測試待機與網路切換

手機無線模組有不同的運作狀態，維持連線及封包喚醒都會影響活動時間。保活間隔太短可能增加耗電，間隔太長則可能讓中間網路設備回收閒置連線對應資訊。這是連線恢復能力與待機耗電之間的取捨，沒有適用所有電信業者與網路環境的固定間隔。使用訂閱預設值仍有問題時，應記錄螢幕關閉時間、網路類型及恢復情形，再針對性調整。

系統背景執行策略可能暫停用戶端，電池最佳化也可能限制網路活動，因此所有協定都可能在鎖定螢幕後出現異常。先確認用戶端是否取得維持連線所需的系統權限，再檢查是否有其他 VPN 類應用程式接管連線。排查時可先在前景重現問題，再關閉螢幕測試；若只有背景執行時失敗，應優先檢查系統生命週期，而不是直接更改節點的加密方式或傳輸連接埠。

建議建立簡短的測試紀錄，註明裝置、網路、節點組合、測試工作及異常階段，不必記錄敏感的驗證資料。每輪只變更一項設定，並在相近使用條件下重複測試。若某種組合吞吐量較高卻持續發熱，而另一種組合能滿足需求且待機後恢復穩定，應優先選擇後者。選擇的目標是滿足具體需求，而不是替所有協定排出永久有效的名次。

六、Clash、Clash Meta 與 mihomo 的核心關係

沿用相似的設定結構，不代表功能完全相同

原版 Clash 建立了常見的 YAML 設定結構，包含代理項目、代理群組、規則及 DNS 等部分。Clash Meta 在相關生態系中擴充協定及功能，mihomo 則延續這個分支的後續發展。名稱變化容易讓人以為這是三種毫不相關的用戶端，實際上此處討論的主要是核心家族；圖形化用戶端則會在核心之上提供設定管理及系統整合功能。

歷史上的 Clash Premium 與原版開源核心也要有所區別。部分舊教學以 Premium 的特定功能為前提，但不能因此認定任何名稱含有 Clash 的程式都具備相同功能。遷移時應確認目前實際執行的核心名稱與功能，不要逐一照抄舊用戶端介面中的所有開關。TUN、規則集與 DNS 的支援及預設行為，都應依目標核心及用戶端整合方式確認。

mihomo 保留許多熟悉的設定編排方式，並擴充協定與網路功能，但相容舊有結構不代表相容所有歷史欄位、私有擴充及錯誤寫法。有些舊設定依賴寬鬆解析，有些功能的預設行為也已改變。正確做法是先讓目標核心檢查設定，再分層驗證執行結果；若程式提示未知欄位，應查明欄位來源，不要以為忽略提示後功能仍然存在。

用戶端顯示的設定不一定等於最終執行設定

圖形化用戶端可能會合併遠端訂閱、本機設定、覆寫規則及執行時連接埠，再交由核心處理。使用者編輯的檔案只是其中一種來源。常見問題之一是訂閱指定了某個連接埠，介面實際使用的卻是另一個連接埠；這不一定是核心不相容，也可能是用戶端設定的優先順序較高。排查時應查看執行設定或用戶端提供的設定預覽，確認最後生效的內容。

規則順序也可能在合併過程中改變結果。代理項目能被辨識，不代表所有要求都會送到該項目；前面的規則可能已選擇直連或其他群組。遷移後若網頁出口改變，應檢查命中的規則與群組，而不是先更換協定。DNS 與路由設定更應分開核對，因為解析結果和接管路徑一旦改變，即使節點參數完全相同，存取行為也可能不同。

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

以上僅示範本機接入及執行模式欄位，並非包含代理服務的完整設定。混合連接埠供支援相應代理方式的應用程式接入；規則模式仍須提供適用規則。即使將這些欄位寫入訂閱，也可能被用戶端介面設定覆蓋，因此應以實際執行狀態為準。這些欄位不會自動啟用系統代理，也不會自動設定終端機環境變數。

遷移時逐層還原，不要一次複製整個資料夾

建議先備份訂閱網址、本機 YAML、覆寫內容及需要保留的選擇紀錄。接著在新用戶端匯入一份設定，確認節點與代理群組，再測試 DNS、系統代理及 TUN。用戶端資料夾可能包含快取、資料庫或與舊程式綁定的狀態，不能以為整個資料夾複製過去就完成遷移。保留來源檔案通常比保留所有執行快取更有價值。

選擇用戶端時，可先從安裝檔下載頁面的 Clash Plus 開始，再依平台及設定習慣比較 Clash Verge Rev、FlClash 等選項。需要保留舊有工作環境時，應避免同時使用兩個用戶端修改系統代理或啟用 TUN。歷史用戶端可用來理解舊設定，但不應只因介面熟悉，就忽略其維護狀態及新協定的相容範圍。

遷移後若只有某類節點失敗，應優先核對該協定新增或變更的欄位；若所有節點正常，但應用程式沒有經過代理，應檢查系統接入；若只有規則模式異常，則應檢查規則引用及群組名稱。依層次分類能減少無效嘗試。若要了解核心家族關係及設定差異，也可閱讀原版、Meta 與 mihomo 核心比較，對照概念與實際執行記錄。

特別要留意，協定支援也可能受用戶端內附核心的更新速度影響。用戶端程式與核心的更新不一定完全同步，介面中有某個選項，也不代表目前的執行檔支援所有相關功能。查看執行中的核心資訊時應記錄實際結果，但不必為追求較新的名稱而頻繁更換。先確認確實需要目標功能，再依用戶端支援的更新方式操作。

七、訂閱格式與 YAML：能下載不代表能載入

先辨識取得的是哪一種內容

訂閱網址只是取得內容的入口，不代表回傳格式必然相同。常見內容包括完整的 Clash YAML、只含代理項目的提供者檔案，以及由分享連結組成或經過編碼的清單。完整設定可以定義規則及代理群組；代理提供者通常負責載入節點集合。兩者用途不同，不能將任何可下載的文字直接放進同一個匯入入口。

完整設定通常透過 proxies 定義本機節點，或以 proxy-providers 引入外部節點，再由 proxy-groups 編排選擇關係，最後由 rules 決定要求的去向。提供者檔案通常只有 proxies 清單，不一定包含執行所需的其他項目。若將提供者檔案當成完整設定啟用，可能會遇到沒有可用群組或缺少規則的情況，這不代表節點密碼已失效。

分享連結則是另一種表示方式，欄位可能經過編碼，不同協定也各有格式約定。訂閱轉換工具必須先解析這些欄位，再映射為目標核心的語法。能輸出 YAML 只代表產生了文字，並不保證路徑、伺服器名稱、UDP 模式或安全參數都完整保留。涉及複雜傳輸方式時，優先使用訂閱來源明確提供的目標核心格式，減少中間轉換造成的資訊遺失。

提供者引用必須具備完整的相依關係

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxxx"
    path: ./providers/my-sub.yaml
    interval: 86400

proxy-groups:
  - name: PROXY
    type: select
    use:
      - my-sub

rules:
  - MATCH,PROXY

這段範例說明提供者、代理群組與最終規則之間的引用關係。範例中的網域和權杖都是虛構資料，無法直接取得節點；實際使用時，必須替換為合法且回傳代理提供者格式的來源。interval 的單位是秒，代表預定更新間隔，不是連線逾時時間。path 用於本機快取，實際儲存位置由用戶端執行目錄及權限決定，不要假設所有平台都會存到相同位置。

這裡的 MATCH 會將符合條件的要求交給 PROXY，並不是適用所有需求的分流方案。實際設定若需要區分直連與代理，應在最後的比對規則之前加入相應規則。提供者名稱、代理群組 use 中的名稱，以及規則指向的群組名稱必須一致。只更改顯示名稱卻漏改引用，可能造成載入錯誤或規則找不到目標，這與節點協定無關。

分開檢查訂閱取得失敗與連線失敗

訂閱更新失敗時，首先應確認是否取得正確的回應。網址失效、驗證失敗、回傳登入頁面或錯誤說明，都可能使用戶端收到非設定內容。不要將完整訂閱網址貼到公開求助頁面，因為查詢參數可能具有帳號存取權限。分享記錄前應遮蔽權杖、帳號及專用網址，只保留錯誤類型、回傳內容類別及必要的設定結構。

成功取得文字後，再檢查 YAML 語法與設定語意。縮排應使用空格，同層欄位維持一致的層級；包含特殊字元的值，應依語法需求加上引號。語法檢查通過只代表結構可解析，仍須確認核心認得協定類型、必填欄位齊全且代理群組引用存在。若提示不支援某個協定，應回頭檢查核心功能，不要反覆修改無關的縮排。

設定成功載入後，仍可能只有個別節點連線失敗。此時應著重檢查伺服器可達性、驗證及傳輸參數。反過來說，訂閱更新失敗也不一定會讓已快取的節點立即無法使用，既有設定可能仍在執行。應分別記錄更新時間、目前啟用的設定及實際連線狀態，避免看到更新提示就認定所有存取問題都來自同一原因。

覆寫也有其限制。取代整份清單與新增一條規則，產生的結果可能不同；不同用戶端的合併策略也未必一致。每次更換設定來源後，都應檢查最終執行設定，尤其是群組名稱與規則位置。若要了解遠端訂閱、本機檔案及多份設定的管理方式，可繼續閱讀Clash Profile 與多設定檔管理，避免將更新行為誤以為是核心隨機修改設定。

八、依使用情境選擇協定並驗證結果

桌面瀏覽與行動裝置使用的優先考量不同

日常桌面瀏覽應優先選用現有服務中穩定、參數完整且用戶端支援的設定。SS、VMess、Trojan 或 VLESS 都可能符合需求，關鍵在於實際路徑及傳輸組合。若沒有可重現的問題，不必為了追求某種協定而更換所有設定。安裝用戶端可先考慮 Clash Plus，再前往下載頁面依作業系統比較其他用戶端；後續選擇協定時，仍須留意用戶端的相容範圍。

行動裝置還應觀察鎖定螢幕後的恢復情形、無線網路切換及背景執行限制。持續傳輸表現良好的 QUIC 類節點，在某些網路中可能遇到 UDP 可達性問題；TCP 類節點則可能因閒置連線遭回收而需要重新建立。適合手機的設定，應同時滿足前景存取及日常待機需求，不能只憑剛開啟用戶端時的一次測試下結論。

語音通話、會議及遊戲應留意應用程式的資料封包轉送、抖動與封包遺失，而不只是檔案下載速度。先確認應用程式是否由代理接管，再確認節點支援所需的 UDP 轉送。部分應用程式會同時連線至多個服務，成功登入不代表媒體通道正常。測試時應實際進行雙向通話或建立工作階段，並留意持續使用及切換網路後的恢復情形。

伺服器與低功耗裝置應先處理執行環境限制

伺服器或路由器通常直接執行核心，需要自行處理服務啟動、設定路徑、權限及監聽範圍。這與使用圖形化用戶端的工作方式不同，不建議只為了少一個介面就更換部署方式。裝置處理能力有限時，應先減少不必要的完整檢查及複雜接管，再比較協定負擔；無法正確處理流量入口的核心，即使支援完整的協定，也不會自動代理整個網路。

區域網路分享也會帶來新的存取界線。允許其他裝置連線時，必須確認監聽位址、防火牆及驗證策略，不能把本機可用直接等同於區域網路可用。協定選擇處理的是用戶端至遠端伺服器之間的連線；區域網路裝置如何連到本機代理連接埠，則是另一段路徑。其他裝置無法上網時，應先檢查本機接入，不必立即更換遠端協定。

依固定順序確認問題所在層級

第一步確認設定已成功載入、代理群組中有目標節點，並手動選取該節點。第二步查看記錄，判斷是解析錯誤、連線逾時、驗證失敗或安全交握失敗。第三步確認應用程式確實經過用戶端，可查看連線頁面或規則命中記錄。若瀏覽器正常但終端機異常，應轉而檢查接入方式，參考瀏覽器與終端機系統代理問題排查。

第四步再進行交叉比較：相同節點切換網路、相同網路改用不同傳輸類型，或將相同設定換到已確認相容的用戶端。每次只變更一項條件，並記錄結果。若只有底層採用 UDP 的協定失敗，應優先檢查目前網路路徑；若某種安全組合始終失敗，則核對該組合的欄位；若所有協定都能通過連線測試，但應用程式仍失敗，應著重檢查規則、DNS 及應用程式本身的代理設定。

DNS 問題尤其容易被誤認為協定問題。目標網域解析錯誤、回傳無法連線的位址，或解析要求沒有依預期路徑送出，都可能造成存取失敗。用戶端的 Fake-IP 與真實位址模式，也可能影響部分應用程式的行為。不要在沒有記錄的情況下，同時切換 DNS 模式、TUN 及節點協定；應先確認網域解析成功，再檢查後續連線的去向。

最後，保留一份已驗證的基準設定及必要備份。更換協定或覆寫規則後，使用同一組工作重新測試，並確認訂閱更新後仍能載入。若修改沒有改善問題，應還原基準設定，而不是繼續疊加開關。需要逐步操作時，請返回快速入門；需要依錯誤現象查找排查方向時，請前往說明中心。協定參考的用途是縮小問題範圍並說明各種取捨，不是為所有網路提供同一套固定參數。

可靠的選擇結論應能描述具體條件，例如在目前裝置、網路連線及指定應用程式下，某筆設定連線穩定且恢復正常。這樣的結論可以重新測試，也能在環境變更後重新評估。單純宣稱某個協定最快、最省電或最適合所有使用者，不僅忽略實作差異，也難以協助下次排查。保留適用條件與驗證過程，比記住一份沒有適用範圍的排名更有用。