代理協定與核心參考

核心系列與設定界線

用戶端、核心與設定檔

圖形介面用戶端負責安裝服務、匯入設定、顯示策略群組及申請系統權限；核心則負責解析規則、建立出站連線、處理 DNS 與轉送資料。介面上有某個開關，不代表目前執行的核心已具備所有相關功能。判斷協定是否可用，應同時查看用戶端說明、核心識別資訊與設定載入結果。只比較應用程式名稱，很容易混淆介面功能與網路能力。

原版 Clash 建立了規則、代理、策略群組等設定結構，許多用戶端沿用這些欄位。Meta 分支在此架構上擴充協定與網路功能，後來以 mihomo 名稱持續維護。在相關資料中，Clash Meta 與 mihomo 通常指向同一條演進路線，並非兩個完全獨立、互不相容的設定體系。名稱變更也不代表所有舊設定都能原封不動地移轉，仍須依個別欄位判斷。

相容性不只是欄位名稱相似

原版設定中的基本規則與部分代理類型通常容易移轉，但 Meta 擴充的協定、DNS 選項或傳輸設定，不能想當然地認為原版也能識別。較舊的用戶端也可能搭配較舊的 mihomo 核心，因此「基於 mihomo」只是第一個條件。遇到未知代理類型、未知加密方式或不支援的傳輸參數，應先確認實際核心的功能，而不是不斷更換節點密碼。

相容性可分為語法可解析與行為一致兩個層面。設定能載入，只代表解析器接受其內容；若某個欄位遭用戶端覆寫，最終行為仍可能不同。例如，訂閱設定了 DNS，但用戶端又套用全域 DNS 覆寫；檔案中停用了 TUN，介面卻透過獨立設定將其啟用。比較兩台裝置時，應查看最終生效的設定與記錄，不要只比對下載到本機的原始檔案。

升級與移轉的驗證順序

移轉時先保留原設定的副本，只匯入一份已知可用的設定。確認可以載入後，選擇一個手動策略群組測試連線，最後再逐項還原規則集、自動選擇、DNS 與 TUN。這樣才能區分協定不受支援、設定引用缺漏與系統路由問題。一次匯入多層覆寫與多個遠端資源，任何一項失敗都可能讓用戶端看似「無法使用」，卻難以找出原因。

用戶端與核心之間也有封裝及執行環境上的關聯。任意將某個執行檔替換到應用程式目錄，可能破壞啟動參數、權限服務或程序管理機制。建議優先使用用戶端支援的更新方式；若需手動管理核心，請先了解設定路徑、工作目錄與記錄位置。伺服器上使用獨立核心，與在桌面使用圖形介面用戶端，是兩種不同的維護方式，操作步驟不可直接互換。

選擇 Clash Plus、Clash Verge Rev 或 FlClash 時，請先確認作業系統支援情況與設定管理習慣，再檢查目前版本是否支援所需協定。已封存的 Clash for Windows、ClashX Meta 可用來辨識舊設定的來源，不應只因舊教學使用它們，就把它們當成新裝置的預設選擇。開源授權也須分清層次：mihomo 核心採用 GPL-3.0，不代表周邊所有應用程式也自動採用相同授權。

SS 與 VMess：加密與封裝

Shadowsocks 的輕量架構

Shadowsocks 通常簡稱 SS，核心概念是透過預先約定的金鑰與加密方式承載代理流量，基本形式不需要額外再套一層 TLS。連線路徑相對直接，部署容易，用戶端支援也廣泛。這裡的「輕量」指的是協定架構，不代表所有 SS 節點都比其他協定快。若伺服器線路壅塞或裝置加密效能不足，較小的協定標頭也無法消除這些瓶頸。

設定 SS 時，加密方式必須與伺服器完全一致。傳統 AEAD 方式與 Shadowsocks 2022 系列不能只更改名稱就互相轉換；後者對金鑰格式與長度有明確要求。伺服器提供的金鑰應作為完整設定的一部分保存，不可將一般密碼任意填入要求特定編碼金鑰的欄位。若驗證失敗，先核對加密方式、金鑰與連接埠，而非降低本機安全設定。

SS 的 TCP 與 UDP 轉送須分別確認。網頁能正常開啟，不代表即時語音或其他 UDP 應用也能透過該節點連線；伺服器、防火牆與用戶端出站設定都可能影響 UDP。若設定還使用外掛，必須確認用戶端與核心支援相應外掛及選項。含外掛的 SS 與基本 SS 已有不同的連線條件，測試時應另外考量外掛造成的握手與封裝負載。

VMess 的驗證與傳輸組合

VMess 源自 V2Ray 協定體系，將使用者身分、工作階段驗證與資料傳輸整合在協定內。現代設定應採用伺服器支援的 AEAD 方式；舊資料中的歷史驗證選項不宜直接套用。使用者識別碼、加密設定與系統時間都可能影響連線，尤其裝置時間明顯不準時，應先校正時間。不要把所有驗證錯誤都歸因於網路品質不佳，重複測速也無法修正身分資訊錯誤。

VMess 可搭配不同傳輸方式。直接使用 TCP，與外層採用 WebSocket 或其他受支援的傳輸方式，握手路徑和中間設施需求都不同。使用 WebSocket 時，路徑、請求主機名稱與 TLS 伺服器名稱各有不同用途；即使在某份設定中三者剛好相同，也不能視為同一個欄位。缺少其中一項，可能出現連接埠可連線，但代理請求失敗的情況。

適用條件與比較方式

若已有維護正常、設定明確的 SS 服務，日常瀏覽不必只因協定名稱較舊就更換。若現有服務使用 VMess，並依賴特定傳輸方式部署，也應優先確保用戶端與伺服器參數相符。選擇時真正要確認的是能否穩定連線、是否支援所需 UDP，以及設定是否容易維護，而不是單純把協定名稱依新舊排列成效能等級。

比較這兩種協定時，盡量使用同一台裝置、位置相近的伺服器與相同的應用程式請求。一次只變更協定或傳輸方式中的一項，分別記錄首次連線、持續瀏覽與長連線的表現。若兩份設定來自不同線路，測試結果通常反映的是整條連線路徑的差異，無法歸因於 SS 或 VMess 本身。尤其不要只憑單次網頁測速截圖，就下結論認定某種協定效率較高。

移轉舊訂閱時，也要留意用戶端可能將名稱相似的項目顯示為不同標籤。判斷依據應是最終設定中的代理類型與參數，而不是節點備註上的「高速」、「專線」等字樣。若某個代理單獨失敗，先手動選取該代理並查看記錄；若策略群組自動切換到另一個代理，網頁表面上能正常開啟，也不能證明原代理已恢復。

Trojan 與 VLESS：TLS 與身分驗證

Trojan 的 TLS 基礎

Trojan 以 TLS 作為安全傳輸基礎，在加密連線內承載代理請求與驗證資訊。用戶端通常需要伺服器位址、連接埠、密碼及正確的伺服器名稱。TLS 負責保護傳輸並驗證對端身分，Trojan 密碼則用於服務授權，兩者不能互相取代。因此，即使密碼正確，只要憑證驗證失敗，仍不能視為已正確建立連線。

伺服器名稱用於 TLS 握手期間的名稱協商與憑證驗證。連線位址可以是網域名稱，也可以是 IP，但憑證涵蓋的名稱必須符合設定預期。網域解析結果改變，不代表憑證名稱可以任意修改。若記錄出現憑證過期、名稱不符或信任鏈異常，應核對系統時間、伺服器憑證與設定，不要把略過憑證驗證當成日常解決方式。

Trojan 也有不同的傳輸組合與實作擴充，不能因為兩個節點都標示 Trojan，就假設欄位完全一致。基本 TLS 連線與經額外傳輸封裝的連線，對路徑、主機名稱或中間服務的要求可能不同。匯入設定後若只能完成握手，卻無法傳送請求，還要核對伺服器使用的傳輸類型，以及訂閱轉換是否保留了相應選項。

VLESS 將安全性委由外層處理

VLESS 的設計著重簡化身分與請求封裝，本身不提供等同於獨立加密傳輸的保護，通常搭配 TLS 或 REALITY 等機制使用。這裡的「簡化」不代表可以忽略傳輸安全。用戶端中的身分識別碼只是驗證要素之一，外層安全機制、傳輸網路與伺服器設定仍須完整相符。將一份設定的身分識別碼貼到另一個節點，通常無法建立可用連線。

REALITY 與一般 TLS 設定的驗證條件不同，會用到公開金鑰、短識別碼、伺服器名稱等參數；這些值應由服務提供者提供，不能從網域名稱或身分識別碼推導。有些 VLESS 設定也會使用特定流控方式，流控欄位與外層安全機制及傳輸方式的組合有關。並非所有網路傳輸都適合填入相同流控值，任意新增欄位只會造成伺服器與用戶端理解不一致。

如何理解額外握手

TLS 通常會在建立連線階段增加往返交握與運算，但不代表使用 TLS 的協定在所有情境下都比較慢。連線重用、工作階段恢復、伺服器處理能力與請求數量，都會改變實際體驗。反過來說，封裝層較少也不保證首次載入頁面更快，因為網域解析、應用程式本身的連線及遠端服務回應可能占去更多時間。應從完整請求路徑理解延遲，而不是計算設定欄位的數量。

日常選擇時，若伺服器提供維護完善的 Trojan 設定，且裝置具備完整的憑證信任環境，通常容易依 TLS 錯誤類別進行疑難排解。使用既有 VLESS 服務時，則應著重確認目前核心是否支援其安全方式與傳輸參數。兩者沒有脫離環境的固定優先順序；穩定的部署、明確的參數來源與可持續更新的用戶端，比名稱上是否輕量或新舊更重要。

若桌面可用、行動裝置卻無法連線，應先比較最終設定，不要立即歸因於手機效能。行動裝置上的訂閱轉換可能遺失安全擴充，系統時間或憑證環境也可能不同。先在兩端使用同一份受支援的設定，關閉自動切換的干擾，並確認實際選取的是同一個代理。接著依序核對解析、握手、驗證與請求傳輸，才能區分協定差異與平台差異。

Hysteria2 與 TUIC：QUIC 傳輸

為何使用 UDP 與 QUIC

Hysteria2 與 TUIC 都利用以 UDP 為基礎的 QUIC 建立代理傳輸，但兩者不是同一種協定，不能共用驗證欄位後直接互換。QUIC 將可靠傳輸、壅塞控制與安全握手等功能整合在使用者空間的實作中，並可在單一連線中承載多個資料流。這能減少不同資料流因傳輸層依序交付而產生的部分阻塞，但同一資料流內仍須處理封包遺失與資料順序。

在部分往返時延較高或有封包遺失的連線路徑上，這種架構可能具備優勢，前提是網路能穩定傳送 UDP。若路徑限制 UDP、連線映射不穩定，或對相關流量施加嚴格速率限制，連線可能直接失敗，也可能比 TCP 更不穩定。因此，看到 QUIC 不要立刻認定速度更快；應先確認基本連線能力，再觀察長時間傳輸時的遺失復原與公平共享表現。

Hysteria2 的頻寬與壅塞控制

Hysteria2 著重改善不理想網路中的傳輸效率，設定可能包含頻寬提示、驗證、TLS 與選用的混淆功能。頻寬數值不是加速開關，也不是節點方案標示的速率。應配合本地上傳、下載與實際連線路徑能力來判斷；設定過於樂觀可能造成佇列、封包遺失，並影響同一網路上的其他應用程式。伺服器也可能限制用戶端可使用的傳輸策略。

填寫頻寬參數前，請先閱讀目前實作對單位與預設行為的說明；不同介面可能會將輸入值轉換成不同的核心欄位。先採用服務提供者給的合理設定，必要時再進行受控調整。混淆密碼與身分驗證密碼用途不同，不可混用；啟用混淆後，伺服器也必須設定相符。Hysteria 與 Hysteria2 屬於不同協定世代，名稱相近不代表設定可以直接沿用。

TUIC 的工作階段與轉送設定

TUIC 同樣以 QUIC 為基礎，常見設定包含身分識別碼、密碼、TLS 名稱與應用層協定協商。壅塞控制、UDP 轉送模式及連線存活設定會影響資源消耗與相容性，但前提是伺服器支援。尤其不要將其他核心設定中的欄位原樣複製到 mihomo：相同概念在不同實作中可能有不同名稱、預設值與支援範圍，應依目標格式轉換。

行動網路與連線移轉

QUIC 具備支援連線移轉的機制，但代理連線能否在 Wi-Fi 與行動網路之間順暢延續，仍取決於用戶端實作、伺服器設定與作業系統。協定具備某項能力，不代表應用程式體驗一定有保障。切換網路後若短暫中斷，請觀察是否重新握手、舊連線是否結束，以及應用程式是否重試。若工作需要不中斷，實際測試網路切換比單次下載測試更重要。

此外，外層使用 UDP，不代表其中所有業務都變成不可靠傳輸。瀏覽器的可靠位元組串流仍須完整交付；代理承載業務 UDP 時，則可能採用不同的轉送方式。疑難排解時應區分外層傳輸與內層業務：外層 UDP 不通會影響整條 QUIC 連線；只有某項業務無法使用，則也可能是伺服器權限、目標限制或規則選擇造成。

準備在行動裝置上長期使用時，應另外測試待機、背景執行與弱訊號狀態。頻繁傳送保活封包或許能維持連線映射，卻也可能增加裝置喚醒與無線電啟用時間；過於積極地關閉連線則會增加重新連線的次數。沒有適用於所有裝置的固定參數組合。保留一個已驗證的 TCP 類出站作為對照，遇到網路變化時就能快速判斷問題是否集中在 UDP 路徑。

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

將速度拆分為不同階段

「快」至少包含 DNS 解析時間、首次建立連線、請求回應與持續傳輸量四個面向。用戶端顯示的延遲測試，通常是依指定方式完成一次探測，並不等同於所有網站的載入時間。瀏覽小型檔案更受往返時延與握手影響；長時間下載則更受頻寬、封包遺失復原與壅塞影響。兩條代理可能各自在不同指標上較好，因此不宜只用單一數值決定所有用途。

資源使用量也不是協定名稱的固定屬性。加密實作、硬體指令支援、並行連線數、封包大小與記錄等級都會改變處理器負載。大量短連線可能把時間耗在握手與狀態管理；持續傳輸大量資料則更容易顯現加密、資料複製與網路堆疊的負載。同一協定在電腦與低耗電手機上的表現不同，往往反映裝置與實作差異，而不只是協定設計本身。

耗電主要來自哪些環節

行動裝置耗電同時受到處理器與無線網路狀態影響。訊號微弱、頻繁喚醒、密集傳送心跳封包、反覆重新連線，以及多個應用程式在背景發出請求，都可能讓無線電長時間保持啟用。即使代理流量不大，長時間頻繁傳送小封包也可能明顯耗電。反過來說，若較高的瞬間處理器負載縮短了傳輸時間，整體能耗未必會增加。因此，不能直接把「處理器使用率低」等同於省電。

TUN、DNS、規則集與策略群組探測，也會增加用戶端整體負載。若讓數十個代理頻繁自動測速，維持連線所需的負擔就會疊加在協定本身。行動裝置上應先減少不必要的探測頻率與背景工作，再比較不同協定，結果才有意義。需要除錯時可暫時提高記錄詳細程度；問題重現後再恢復日常等級，以免將大量寫入記錄與介面更新誤認為協定的固定負載。

建立可重複的對照測試

測試時應固定裝置、位置、網路、目標網站與使用情境，並盡量在相近時段交替驗證兩組設定。先完成小型請求，再測試持續傳輸，最後觀察實際應用程式的表現。每輪只改變一個變因，例如只更換協定，或只更換 DNS 方案。比較協定時，不要同時啟用 TUN、更換規則集並調整系統省電模式；否則即使體驗改善，也無從判斷是哪項變更造成。

比較耗電時，也應盡量維持螢幕亮度、訊號強度與背景應用程式相近，並觀察較長時間的實際使用情況。應用程式安裝後首次啟動、系統索引或集中同步，都可能造成短期耗電波動。系統電池用量統計只能協助觀察趨勢，不能直接推算各協定的絕對能耗。若用戶端在背景執行時連線反覆遭系統中止，應先檢查背景權限與省電限制，再考慮調整協定保活設定。

自動選擇不等於評估實際使用品質

自動測速策略群組通常依指定的探測目標與規則選擇代理；探測目標可用，不代表實際使用的網站也能連線。切換週期過短，可能因結果相近而反覆更換選擇，既干擾長連線，也增加測試請求。疑難排解期間應改用手動選擇，確認單一連線的實際表現；穩定後再恢復自動策略，並設定合理的容差與間隔，避免沒有實際效益的切換。

若瀏覽正常但影片播放卡頓，先確認目標連線實際使用的出站，再區分持續傳輸量不足、伺服器限制與應用程式快取問題。若下載速度快但網頁開啟緩慢，應檢查解析與短連線握手。若只有切換網路時失敗，則應留意連線重建與系統路由恢復。依現象拆分問題後，協定比較才有明確目標；一味更換協定名稱，反而容易忽略真正的瓶頸。

首次連線的觀察順序，可參考節點選擇、延遲測試與代理生效驗證。結論應以實際測試條件為限：某個協定在目前裝置與網路上的表現合適，不代表在所有平台都有相同優勢。能穩定重現、方便維護且符合應用需求，才是長期使用時更可靠的選擇標準。

訂閱格式與設定相容性

訂閱是入口，不是統一格式

訂閱連結只是取得遠端內容的網址，回傳內容可能是完整 YAML 設定、節點連結集合，也可能是特定用戶端專用的資料格式。連結能在瀏覽器中開啟，只代表請求收到回應，不代表內容適用於 mihomo。若回傳的是登入頁面、到期通知或其他結構，用戶端可能會顯示解析失敗。檢查時應留意內容類型與錯誤摘要，不要公開分享含有授權資訊的完整連結。

完整設定通常包含代理、策略群組與規則，有時也會引用遠端規則集或代理提供者。節點集合主要描述出站連線，不一定會告訴用戶端如何分流。匯入後只看到節點、卻沒有預期的策略群組，可能是訂閱類型不同，而非節點遺失。使用 proxy-providers 時，主設定還須正確引用提供者；遠端內容取得成功，也不代表策略群組已經使用其中的代理。

轉換可能遺失協定語意

不同生態系的設定檔，不能只把副檔名改成 YAML 就完成轉換。身分驗證、傳輸路徑、TLS 名稱、流控與協定擴充都須逐項對應，目標核心也必須支援相關功能。若轉換工具只識別基本協定，可能保留伺服器位址卻漏掉附加欄位，造成「節點存在但無法連線」的情況。使用新協定與複雜傳輸組合時，尤其要核對原始設定與轉換結果。

完整設定與局部覆寫的優先順序也很重要。訂閱更新可能會取代遠端檔案，直接編輯快取內容通常無法持續保留。需要新增規則時，優先使用用戶端提供的覆寫或合併入口，並確認訂閱更新後仍會套用。若同時存在全域覆寫、個別設定覆寫與核心預設值，應先釐清最終優先順序，避免每次更新後都用不同設定進行測試。

先驗證結構，再啟用自動更新

首次匯入後，先確認設定名稱與來源，再檢查代理類型、策略群組引用及規則是否完整。手動選擇一個代理並完成驗證後，才設定更新間隔與自動選擇。更新失敗時，可依序檢查位址解析、請求連線、回應內容與設定解析。若舊設定仍可連線，應先保留它，避免為了重新匯入而刪除唯一可用的設定與診斷線索。

更新流程本身也可能依賴目前使用的代理。例如，某個遠端提供者透過一個策略群組取得資料，但該群組又依賴尚未更新成功的代理集合，就可能形成啟動依賴問題。應先確認資源首次載入時可使用哪個出站，以及是否有可用快取。不要只憑介面上的更新按鈕一直轉圈，就判定核心故障；主訂閱、代理提供者或規則提供者的載入失敗，處理方式各不相同。

以下片段只示範基本執行選項，可合併到已包含有效出站、策略群組與規則的設定中。這不是完整訂閱，也不會建立任何遠端代理。除錯時先保留明確的執行模式與記錄等級，有助於釐清介面設定與檔案內容之間的差異；若用戶端會覆寫這些欄位，仍應以最終生效的設定為準。

mode: rule
log-level: info
allow-lan: false
ipv6: false

多設定管理與復原

多份設定適合分開管理不同來源或測試方案，但每次應只啟用一份明確的設定。策略群組上次選取的項目可能由用戶端保存，切換設定後不可假設它會自動恢復成預期代理。每次測試都應重新確認目前設定、模式與所選出站。移轉協定時，為設定取一個能辨識用途的名稱，比把所有節點混在一起更容易比較與復原。

更新成功後也要檢查實際行為：新增規則可能改變應用程式的出站，節點改名可能使原有策略選擇失效，遠端資源引用也可能變更。保留可復原的副本，並了解用戶端是否支援還原舊版設定。關於檔案、連結與更新的關係，可參閱Profile 與多設定管理；常見更新錯誤則可從FAQ進一步查閱。

DNS、TUN 與流量入口

代理出站不代表應用程式流量已進入

代理協定處理的是用戶端如何與伺服器傳輸資料；系統代理與 TUN 處理的則是應用程式流量如何進入用戶端，兩者屬於不同層面。系統代理通常仰賴應用程式遵循作業系統的代理設定，但部分應用程式會忽略設定；TUN 則透過虛擬網路介面與路由接管更大範圍的流量。某個應用程式直連，不一定是節點協定不支援，也可能是它的流量根本沒有經過核心。

同樣地，啟用 TUN 不代表所有流量必然使用遠端代理。流量進入核心後，仍須經過規則判斷；符合直連規則的請求會直接出站。檢查時應分開確認入口、規則與出站：先找出連線記錄，再查看命中的規則與策略群組，最後確認使用的代理。若記錄中完全沒有目標應用程式，應先處理流量入口與權限，而不是修改遠端協定的驗證參數。

Fake-IP 與真實位址解析

Fake-IP 模式會為網域名稱回傳虛擬位址，保留網域與連線之間的對應關係，讓核心在後續處理流量時能識別目標名稱。它不是遠端代理伺服器，也不會自動變更出站策略。redir-host 則較接近直接回傳實際解析位址的方式，兩者對網域識別、快取與應用程式相容性的影響不同。選擇哪種模式應依應用程式行為與目前規則需求判斷，而非只看名稱。

部分裝置探索、區域網路服務或特定應用程式可能依賴真實解析結果，此時可考慮使用 fake-ip-filter 針對性排除。過濾不應演變成排除所有網域，否則會改變使用 Fake-IP 的原本目的。調整模式後，系統、瀏覽器與應用程式可能仍保留舊快取；應視情況清除快取或重新啟動相關應用程式，避免新舊解析結果交錯而造成誤判。

解析路徑與啟動依賴

連線到代理伺服器本身也可能需要 DNS。如果解析伺服器位址必須先經過尚未建立的代理，就會形成啟動依賴。加密 DNS 上游的主機名稱解析、代理節點網域解析與一般業務網域解析，也可能由不同設定項目處理。疑難排解時，先確認失敗的網域屬於哪一層，再檢查相應的解析路徑；不要把所有解析問題都歸結為同一個 DNS 開關。

IPv6 是另一條需要獨立檢查的路徑。系統可能優先使用 IPv6，但代理入口、規則或遠端支援不完整，導致部分網站連線逾時後才回退。關閉某項 IPv6 設定有助於縮小問題範圍，但不一定適合作為所有情境的長期解法。應檢查系統位址、路由、DNS 回應記錄與代理伺服器能力是否一致，並確認測試涵蓋實際使用的位址類型。

規則順序與平台差異

規則通常由上而下比對，第一個符合的項目會決定後續策略。因此測試節點時，應確認請求沒有先被前面的直連規則攔截。程序規則、網域規則與位址規則仰賴的資訊各不相同；平台能提供的程序資訊也可能有限。尚未識別的網域、變動的解析路徑或已快取的連線，都會讓觀察結果與預期不同，不能只交換兩條規則的順序，就認定問題已經解決。

桌面啟用 TUN 可能需要服務權限、虛擬網卡與路由設定；行動裝置通常需要系統 VPN 授權，也會受到背景管理限制。多個網路工具同時執行時，也可能爭用系統代理、DNS 或預設路由。測試時暫時只保留一個負責接管流量的工具，記下原有設定後再逐項恢復。Windows 市集應用程式的特定迴圈存取問題，可參閱UWP 迴圈存取豁免說明。

這些流量入口與解析因素，說明了為什麼更換協定後有時看似恢復正常：切換操作可能同時重建連線、更新快取或重新啟動網路堆疊，未必是協定本身修復了 DNS。要得出可靠結論，應在不更換協定的情況下，單獨重新載入相關設定並觀察能否重現相同變化。只有區分不同層面，才能判斷該修改節點、規則、解析設定還是系統權限。

依使用情境選擇與分層疑難排解

依限制條件縮小候選範圍

桌面日常瀏覽，優先選擇參數完整、服務穩定且易於維護的出站。若已有可用的 SS、VMess 或 Trojan 服務，不必只為追求較新的名稱而移轉。需要特定 VLESS 安全組合時，先確認目前核心與訂閱轉換流程支援。選擇圖形介面用戶端可先從 Clash Plus 開始，再依作業系統支援、設定管理方式與實際功能需求，比較下載頁列出的其他用戶端。

行動裝置通勤時，還須考量網路切換、背景執行與耗電。先選擇能在常用 Wi-Fi 與行動網路上穩定連線的設定，再觀察待機與重新連線情況。若目前網路的 UDP 表現不可靠，Hysteria2 或 TUIC 就不宜作為唯一選擇；若延遲高且封包遺失明顯，但 UDP 連線穩定，則可將兩者納入比較。結論應以日常通勤路線上的實際應用表現為準，而不是短時間的實驗室式測速。

傳輸大型檔案時，應留意持續傳輸量、伺服器限額與網路共享；即時語音則更重視延遲變化、封包遺失，以及業務 UDP 是否確實可用。伺服器或路由器還須考量處理器架構、記憶體、記錄保留與自動啟動，通常直接管理 mihomo 核心會較合適。桌面圖形介面用戶端的便利選項，不一定存在於獨立核心中；部署前應先確認由誰負責產生設定與恢復服務。

依連線階段縮小故障範圍

第一層先確認設定是否載入。若有未知欄位、代理類型錯誤或策略群組引用不存在，應先修正設定結構；此時尚未進入網路連線階段。第二層確認伺服器位址是否能解析，以及目標連接埠是否能透過相應傳輸方式連線。TCP 連接埠探測成功，不代表 UDP 可用，也不代表 TLS、協定驗證與實際代理請求都成功，仍須繼續往下確認。

第三層檢查安全握手與驗證。憑證錯誤應核對時間、名稱與信任鏈；驗證錯誤則核對密碼、身分識別碼、金鑰格式與協定世代。第四層檢查業務轉送：查看請求命中的規則、策略群組與最終出站，區分所有目標都失敗或只有單一目標失敗。若只有部分業務異常，再檢查 DNS、位址類型、伺服器權限或目標應用程式特性，不要把所有設定從頭更換。

保留最小重現案例與復原方式

疑難排解時，使用一份可復原的設定、一個手動策略與一個明確的目標，暫時減少自動選擇與複雜覆寫。記下每次變更與結果，失敗時才能回到上一個狀態。除錯記錄有助於辨識故障階段，但分享前應刪除訂閱網址、驗證資訊與敏感目標。公開問題描述保留用戶端名稱、核心識別資訊、作業系統、協定類型與錯誤類別，通常已足以進行初步判斷。

若兩種協定在同一時間都變慢，應先檢查本地網路、伺服器狀態與共用依賴；若只有一種失敗，再比較該協定特有的傳輸與驗證要求。若同一份設定在另一台裝置上正常，優先檢查本機時間、憑證、權限與最終覆寫。若更換網路後恢復，則著重調查原有連線路徑。這種交叉驗證，比不斷重新整理訂閱更能找出有依據的結果。

完成調整後，不要只測試一個網頁。請重新檢查日常應用程式、業務 UDP、休眠後恢復與網路切換，並確認關閉系統代理或 TUN 後，也能恢復預期的網路狀態。最後將記錄等級、更新間隔與自動策略恢復至合適設定，並清除暫存的測試設定。長期維護的目標不是保留最多參數，而是能說明每項設定的用途，並在發生問題時知道該從哪一層開始檢查。