Clash 協定與核心參考指南

一、選擇協定：先釐清連線的不同層次

協定、傳輸與客戶端各自負責什麼

在客戶端選擇一個節點，實際上同時選定了伺服器位置、驗證方式、代理協定與底層傳輸。Shadowsocks、VMess、Trojan、VLESS 主要描述代理連線的組成方式；TCP、UDP、TLS、WebSocket 等則代表不同層次的承載方式。Hysteria2 與 TUIC 則以 QUIC 為基礎設計傳輸。若把這些名稱放在同一欄直接比較，很容易將協定差異誤認為線路差異。

客戶端是設定與控制入口，核心則負責解析設定、建立連線及執行規則。介面能顯示某種節點，不代表目前的核心能處理該節點的所有選項；核心支援某種協定，也不代表訂閱轉換器會保留相關欄位。選擇時應依序核對「伺服器要求—訂閱內容—核心功能—客戶端設定」，而不是只看節點名稱中的縮寫。

也要區分應用程式流量與代理隧道的傳輸方式。遊戲傳送 UDP 資料，不代表任何標示 UDP 的節點都能正確承載；瀏覽器連線至 HTTPS 網站，也不代表代理外層一定使用 TLS。一次連線可能經過多層封裝，各層的加密、壅塞控制與逾時設定各自生效。疑難排解時，先確認問題出在應用程式請求，還是客戶端連往代理伺服器的連線。

先確認相容性，再比較效能

實際選擇順序如下：確認伺服器允許使用哪些協定，檢查目前系統上的客戶端與核心是否支援，再比較同一服務商、相近地區與相近時段的表現。若伺服器只提供 Trojan，將節點類型改成 VLESS 並不會建立有效連線。協定不是客戶端能單方面切換的外觀選項，驗證欄位與傳輸參數都必須符合伺服器設定。

也不要把「支援 UDP」、「支援多工」和「支援 TUN」視為相同功能。UDP 轉送取決於協定與伺服器功能；多工是連線組織策略；TUN 則是本機流量的接入方式。啟用 TUN 可以接管部分不使用系統代理的應用程式流量，但不會讓伺服器新增 UDP 轉送功能，也無法修正錯誤的密碼或憑證網域。

安全性與維護狀態也是選擇條件

優先使用仍在維護的客戶端與核心，保留憑證驗證，並從可信來源取得設定。代理連線加密不代表應用程式可以傳送未加密的敏感資訊：資料離開代理伺服器後的保護，仍取決於應用程式使用的協定。登入帳號、付款或使用管理後台時，仍應透過有效的 HTTPS 連線；代理外層加密不能取代網站本身的安全連線。

訂閱網址通常包含存取憑證，設定檔也可能包含密碼、UUID 或管理介面金鑰。分享截圖時請遮蔽網址與驗證欄位；回報問題只需提供協定類型、錯誤類別及必要的非敏感參數。需要他人協助時，不要將完整訂閱檔上傳到公開討論區；節點名稱也可能透露服務商或個人命名資訊。

二、Shadowsocks 與 VMess：兩種加密代理的組成方式

Shadowsocks：架構精簡，設定方法必須相符

Shadowsocks 通常簡稱 SS，最初採用相對輕量的加密代理設計。它透過伺服器位址、連接埠、加密方式與密碼建立代理連線，常見設定簡潔，適合需要明確管理少量節點的情境。輕量指的是協定組成方式，不代表所有裝置與加密方式的 CPU 負擔都相同，也不表示伺服器必然支援所有選用擴充功能。

選用 SS 時，最重要的是確認加密方式與密碼。現代部署應採用伺服器與客戶端共同支援的認證加密方案，不要為了相容舊版軟體而任意降級至過時方式。部分較新的 SS 方案對金鑰格式、長度與多使用者設定有特定要求，不能直接填入任意文字密碼。匯入後若出現金鑰長度錯誤，應先檢查來源格式，而不是反覆修改連接埠。

SS 的 TCP 與 UDP 轉送需要分別驗證。網頁瀏覽正常，只能證明相關 TCP 請求已完成；語音、遊戲或部分 DNS 請求仍可能失敗。若伺服器未啟用 UDP、網路路徑限制 UDP，或應用程式未由本機代理入口接管，只開啟客戶端的 UDP 選項仍無法補足條件。應先從記錄確認請求是否進入核心，再檢查伺服器與傳輸設定。

部分 SS 部署還需要外掛程式。外掛程式會改變外層連線方式，並增加類型、路徑或 TLS 參數，因此「支援 SS」不代表「支援這組外掛程式設定」。轉換訂閱後若只留下位址與密碼，節點可能看似匯入成功，實際上卻無法使用。行動裝置尤其需要確認核心是否內建相應外掛程式功能，不能直接照搬桌面版外接外掛程式的用法。

VMess：分別核對驗證資訊與外層傳輸

VMess 源自 V2Ray 生態系，透過身分驗證與代理資料傳輸組成連線。節點通常使用 UUID 等驗證資訊，並可能搭配 TCP、WebSocket 或其他受支援的傳輸方式。VMess 的實際行為比單看協定標籤更依賴整組參數。同一個 UUID 搭配不同路徑、主機標頭或 TLS 設定，也可能產生完全不同的連線結果。

舊資料常混有歷史驗證方式與過時欄位，不應直接視為目前的建議設定。遇到訂閱中的舊參數，請先確認服務提供者的要求與核心說明，不要照著搜尋到的片段逐個嘗試。裝置時間也值得檢查：驗證機制可能依賴合理的時間狀態，若系統時鐘明顯不準，應先恢復自動校時，再判斷節點是否失效。

使用 WebSocket 時，請分別確認連線連接埠、請求路徑、Host 標頭與 TLS 伺服器名稱。Host 是 HTTP 層的資訊，伺服器名稱會用於 TLS 連線與憑證驗證；兩者可能相關，但不能認定一定相同。反向代理部署中，路徑必須符合伺服器的轉送規則；路徑錯誤時，記錄可能先顯示 HTTP 回應異常，而非驗證失敗。

如何比較這兩種協定才有意義

SS 的參數較集中，適合希望減少外層組合的部署；VMess 的組合方式較多，方便接入既有傳輸架構，但疑難排解項目也會增加。這不代表前者一定較省電、後者一定較慢。加密實作、CPU 指令集支援、網路往返時間與連線是否重用都會影響結果；低階路由器和新款手機的表現也可能不同。

比較時，盡量固定出口地區、伺服器資源與目標檔案。若兩個節點來自不同主機，結果主要反映這兩個節點的整體品質。對日常使用者而言，更有參考價值的指標包括網頁初次開啟是否順暢、持續傳輸是否穩定、閒置後能否迅速重新連線，以及切換網路後是否恢復；單次測試的連線時間只能作為輔助線索。

三、Trojan 與 VLESS：TLS、驗證與傳輸組合

Trojan：完整檢查 TLS 條件

Trojan 將代理驗證與資料傳輸放在 TLS 連線中，常見部署採用密碼驗證。其設計取捨是使用成熟的 TLS 傳輸保護，再於其中承載代理請求。對客戶端使用者而言，節點位址、連接埠、密碼與伺服器名稱是主要檢查項目；憑證鏈是否可信、系統時間是否正確也會影響連線，不能只檢查密碼欄位。

憑證驗證的目的是確認伺服器身分，而不只是確認「有沒有加密」。連線位址可以是 IP，也可以是網域，但憑證必須符合用於驗證的名稱。部分部署要求另外指定伺服器名稱，應依服務提供者提供的參數填寫，不能以節點顯示名稱代替。憑證過期、網域不符或憑證鏈不完整時，應由設定來源或伺服器維護者修正。

略過憑證驗證會削弱身分驗證，不應作為日常修復方式。若只有某台裝置出現憑證錯誤，先檢查該裝置的時間、系統信任存放區、網路中間設備與客戶端記錄；若所有裝置同時失敗，則應優先檢查伺服器憑證與部署變更。修改驗證選項可能讓錯誤訊息消失，卻無法證明實際連線的是預期伺服器。

Trojan 的 UDP 功能也不能簡單視為原生 UDP 傳輸。常見實作會將 UDP 資料封裝在可靠連線中，實際路徑取決於核心與設定。這種方式可以提供應用程式需要的轉送功能，但發生封包遺失時，可能受到外層可靠傳輸等待的影響。語音或遊戲的使用體驗應透過實際應用程式測試，不要只依節點的 UDP 標示判斷。

VLESS：輕量驗證不代表本身具備加密

VLESS 的設計著重將驗證與外層傳輸保護分開，協定本身不會加密內容。實際部署通常搭配 TLS、REALITY 等受支援的安全傳輸機制，因此不能把 VLESS 節點理解成只要填入 UUID 即可。伺服器採用的安全層、傳輸方式與特定流控要求，都需要客戶端支援相應組合；缺少任何一項都可能導致連線失敗。

REALITY、Vision 與 VLESS 不是三個可以互換的協定名稱。VLESS 是代理協定，REALITY 是安全傳輸機制，Vision 則是特定流控方案。訂閱中的公鑰、短識別碼、伺服器名稱與流控欄位各有用途，不能因介面沒有顯示就認為可以刪除。客戶端支援基本的 VLESS 連線，也不代表支援所有這些擴充功能。

VLESS 搭配 WebSocket 等傳輸方式時，仍須確認路徑、主機標頭與 TLS 條件；搭配特定流控時，則要確認伺服器與客戶端所選的傳輸方式符合要求。不要將某種部署的流控欄位複製到另一種部署。遷移設定時，先保留原有組合並確認連線正常，再考慮調整；避免同時變更協定、傳輸與 DNS，以免無法定位問題。

使用相同安全層時，仍須實際測試差異

Trojan 與 VLESS 都可能使用 TLS，因此握手與憑證處理的部分成本相近。但兩者的驗證、封裝與擴充功能不同，不能將所有效能差異都歸因於 TLS。實際首位元組時間還包括 DNS 解析、TCP 建立連線、安全握手與目標網站的回應時間。只測試單一輕量探測位址，無法完整反映網頁中大量資源的載入表現。

若服務提供者同時提供這兩類節點，先選擇欄位完整且目前核心明確支援的設定，再觀察日常應用程式的表現。需要多種傳輸方式接入既有服務架構時，確認組合的意義遠大於比較協定名稱；若只是要穩定使用現有訂閱，無須為了更換標籤而手動重建節點。伺服器維護品質、憑證續期與設定更新是否及時，都會直接影響長期可用性。

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

QUIC 改變了哪個層次

QUIC 以 UDP 承載，並整合安全握手、可靠資料流與連線管理功能。Hysteria2 和 TUIC 以這些功能組織代理流量，目標包括減少部分連線負擔、改善並行處理及適應複雜網路。不過，UDP 只是承載基礎，不代表路徑一定更好；如果目前網路對 UDP 限速、丟棄封包或設定嚴格逾時，QUIC 類節點可能比 TCP 類節點更難維持穩定。

QUIC 的多條可靠資料流可減少因傳輸層依序交付而造成的流間等待，但同一資料流中的遺失資料仍須處理，所有資料流也可能共用壅塞視窗與底層線路。它無法消除無線訊號波動，也不能突破伺服器頻寬限制。網頁資源並行載入較多時可能受益；單一檔案下載則仍主要受可用容量、封包遺失與壅塞控制影響。

連線識別資訊為網路路徑變更提供了機制基礎，但行動網路切換後能否順利恢復，仍取決於協定實作、伺服器狀態、NAT 與客戶端行為。不要將 QUIC 等同於永不斷線。手機從 Wi-Fi 切換至行動網路後，應觀察原有應用程式是否恢復、核心是否重新握手，以及系統是否允許應用程式在背景執行，再分別判斷問題所在。

Hysteria2：頻寬參數不是加速倍數

Hysteria2 著重於在網路條件不理想時提供可調整的傳輸策略。常見設定包含驗證資訊、TLS 及選填的頻寬宣告等，實際壅塞控制行為取決於雙方設定。上行與下行宣告用於描述線路條件，不是填得越大越好。若將有限的上行容量誤填成很高的數值，可能造成佇列堆積、重傳與其他應用程式回應變慢，反而影響整體體驗。

核對頻寬參數時，先確認填寫方向與單位，再評估實際可用容量。家用網路標示的頻寬不等於代理路徑可持續使用的頻寬；行動網路更會隨訊號與負載變化。若無法合理估算，建議沿用可信設定來源的參數與核心預設值，不要照抄網路上的誇大數值；調整後也要同時觀察傳輸量、互動回應與封包遺失情況。

Hysteria2 與早期 Hysteria 的設定並非只要改名就能相容。訂閱轉換器若混淆類型、驗證欄位或混淆設定，可能產生可匯入卻無法連線的節點。若使用混淆、連接埠跳躍等選用功能，核心與伺服器都必須支援。疑難排解時先使用服務提供者給的完整設定，確認基本連線正常，再逐項檢查這些擴充條件。

TUIC：並行處理與 UDP 轉送需要雙方支援

TUIC 同樣利用 QUIC 建立連線，並設計了與驗證、資料流轉送及 UDP 轉送相關的機制。不同實作或設定版本對驗證欄位與參數的要求可能不同，因此不能只依 TUIC 標籤判斷相容性。匯入時應確認目前核心明確支援服務提供者使用的設定格式；遇到未知欄位時，先查看核心記錄與訂閱目標格式，不要直接刪除欄位。

TUIC 的壅塞控制、UDP 轉送方式與連線保活等選項都會改變運作行為。可靠轉送與不可靠資料報各有適用情境：前者重視送達，後者更適合可容許遺失、但重視即時性的應用程式。最終效果仍取決於雙方實作，不能只看選項名稱就推斷所有遊戲都會受益。即時應用程式應透過實際通話或遊戲，觀察延遲抖動、中斷情況與恢復時間。

兩類 QUIC 節點都需要留意 MTU、路徑上的 UDP 條件與路由器狀態。若小型請求正常、大量傳輸卻卡住，可以懷疑路徑分片或封包長度問題，但不應直接將所有逾時都歸因於 MTU。先換用其他網路，確認是否只有 QUIC 節點失敗，再依客戶端文件調整；同時保留可用的 TCP 類節點作為對照，避免失去判斷基準。

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

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

連線「快」至少包含首次回應、持續傳輸量、互動延遲抖動與斷線後恢復等面向。首次回應會受 DNS、建立連線、安全握手與目標服務處理時間影響；持續傳輸量則受容量、封包遺失、壅塞控制與伺服器負載影響。首次開啟網頁較快的節點，不一定適合長時間下載；下載速度較高的節點，也可能在視訊會議中出現明顯延遲抖動。

客戶端的連線測試通常會連到指定目標，只能反映該探測路徑的結果。測試目標不同、是否重用連線不同，數值就不適合直接比較。自動選擇策略也可能因探測結果波動而頻繁切換節點，影響長連線應用程式。先了解測試方式，再決定是否啟用自動選擇；對需要穩定連線的使用情境而言，固定使用合適節點通常更容易找出問題。

進行對照測試時，固定裝置、網路、目標資源與規則，關閉會占用頻寬的背景工作，每次只變更一個條件。先測試網頁初次載入，再測試持續傳輸，最後測試閒置後的恢復情況；交替進行多輪測試，避免把尖峰時段的變化誤認為協定差異。若節點出口或伺服器不同，應記錄為節點使用體驗，不要宣稱已證明某種協定整體更快。

CPU 與記憶體主要耗用在哪裡

CPU 負載來自加解密、封裝、資料複製、規則比對與協定堆疊處理。新型裝置的硬體加速可能降低某些加密方式的成本，舊款路由器則可能先受限於單核心效能。QUIC 的使用者空間處理、頻繁的小型封包與大量並行連線也可能增加負載。發現傳輸量不足時，應同時檢查處理器使用率與線路條件，不要只是不斷更換節點。

記憶體用量會受連線數、緩衝區、規則集合、DNS 快取與客戶端介面影響。應分開觀察介面程序與核心程序，並將記錄等級恢復正常，避免長期詳細記錄增加負擔。連線重用可能減少重複握手，但也需要維護額外狀態；增加並行連線數或擴大緩衝區不一定有幫助，尤其是記憶體較少的路由器和背景執行受限的手機。

TUN 會增加本機接入與處理環節；DNS 劫持、程序辨識與規則比對也可能改變資源負擔。因此，系統代理與 TUN 的測試結果不能直接當成協定比較。如果應用程式在兩種接入方式下套用不同規則，實際出口甚至可能不同。比較前應查看連線記錄，確認相同應用程式與目標確實使用同一節點及策略。

耗電取決於喚醒、訊號與實際流量

行動裝置耗電不只來自加密運算。行動網路無線電維持啟用、弱訊號重傳、背景保活與應用程式頻繁連線，往往也有很大影響。協定維持連線較久，可能減少握手次數，也可能延長無線電啟用時間；較短的逾時設定可能降低閒置耗電，卻讓後續請求反覆重新建立連線。沒有適用於所有手機的固定省電排名。

比較耗電量時，固定螢幕亮度、訊號條件、使用中的應用程式與測試時間，並分別觀察閒置和持續使用狀態。系統電池統計會受耗電歸因方式影響：使用 VPN 介面的流量有時會集中計入客戶端，但不代表全部耗電都來自代理運算。應結合總耗電量、流量與背景活動判斷，不要只看客戶端在電池用量清單中的排名就下結論。

日常最佳化可先減少不必要的高頻檢測與詳細記錄，保留合理的訂閱更新間隔，並檢查是否有應用程式持續請求失敗後不斷重試。系統的省電限制若過於嚴格，也可能終止背景連線，因此需要在續航與持續連線之間取捨。Android 請檢查背景執行權限；iOS 請檢查 VPN 狀態與隨選連線設定。這些系統行為無法只靠更換協定完全解決。

六、原版、Clash Meta 與 mihomo：核心與客戶端的關係

系列名稱相近，功能不能混為一談

Clash 最初指的是代理核心專案，後來也常用來泛稱相關設定與客戶端生態系。原版開源核心、過去的 Premium 分支，以及後續的 Meta 路線，並非使用同一套功能。舊教學若只寫「Clash 支援」，可能省略了分支版本的前提。遇到規則類型、TUN 或協定擴充功能時，應確認明確的核心名稱，不要只看介面標題。

Clash Meta 是在原有生態系上擴充協定與功能的核心路線，mihomo 延續了這條路線。許多客戶端與訂閱仍保留 Meta 字樣，因此名稱不同不一定代表設定體系完全不同。不過，名稱沿革相近也不代表任何版本都支援所有新欄位；實際功能應以目前執行的核心及其文件為準，不能根據最新資料推定舊版安裝檔的能力。

Premium 曾提供不同於開源原版的功能，不應預設其專有設定或指令碼機制可以直接遷移至 mihomo。部分欄位用途相似，但實作與語法可能不同，直接保留可能導致解析失敗或行為改變。遷移舊設定時，先建立最小可執行設定，再逐項還原規則集、DNS、TUN 與自動化選項，避免整套照搬過往功能。

客戶端負責介面，核心負責執行

客戶端提供訂閱管理、節點選擇、系統代理與記錄檢視，也可能內建設定覆寫與核心更新機制。介面設定通常會產生或修改執行設定，因此磁碟上的原始訂閱不一定等同核心最後載入的內容。疑難排解時應查看客戶端提供的執行設定或合併結果，特別留意 DNS、連接埠、策略群組與 TUN 是否被介面選項覆寫。

新手可依平台優先查看 Clash Plus，再按需求比較 Clash Verge Rev、FlClash 等客戶端。Windows 使用者也可比較 Clash Nyanpasu；Linux 使用者則可在 Clash Verge Rev 與 FlClash 之間選擇。優先推薦某款客戶端，不代表各平台的內部實作完全相同；若需要特定協定擴充功能，仍應確認該平台版本的功能與參數支援情況。

Android 上的 Clash Meta for Android 與 Surfboard 也應分別評估其功能。Surfboard 使用自有設定格式，不能只因同屬代理客戶端就直接套用 Clash YAML。iOS 使用者可前往下載頁查看 Clash Plus 的 App Store 連結與官方網站 clashplus.io。跨系統遷移時，應比較具體設定與功能，而不只是應用程式名稱。

停止維護的軟體、核心更新與遷移限制

本站下載清單已將 Clash for Windows 與 ClashX Meta 標示為停止維護，適合有明確相容需求的使用者查閱。封存的客戶端可能缺少後續協定欄位、系統相容調整與安全修補，不應只因熟悉舊教學截圖就作為新安裝首選。相關差異請參閱封存客戶端說明，再決定要保留舊環境或遷移。

更新客戶端與更新核心可能是兩項操作，也可能由客戶端一併管理。更新前請備份本機規則、覆寫設定、策略群組名稱與系統接入選項；更新後驗證訂閱解析、規則命中、DNS 與常用應用程式。不要在同一次變更中同時更換客戶端、訂閱格式與所有節點，否則發生問題時很難判斷是哪一層改變所致。

直接執行 mihomo 適合伺服器、路由器及需要自行管理服務的使用者，還須處理程序權限、啟動方式、記錄與設定檔路徑。桌面使用者通常透過 GUI 操作更方便。直接執行核心不會自動完成透明代理，也不能取代路由、DNS 與防火牆設計；部署前應先釐清哪些裝置的哪些流量需要進入核心。

七、訂閱格式、YAML 設定與遷移相容性

分享連結、節點清單與完整設定並不相同

訂閱是一種取得設定的方式，不代表統一的檔案格式。同一個連結可能回傳編碼後的分享連結集合、完整 Clash YAML，或其他客戶端使用的設定。分享連結通常描述單一節點；完整設定還包含策略群組、規則、DNS 與監聽連接埠。匯入後看到節點清單，不代表原有的分流邏輯也完整保留，還要檢查策略群組與規則。

選擇訂閱目標格式時，應請服務提供者輸出符合實際客戶端需求的內容。傳統 Clash 格式、支援 mihomo 擴充功能的格式，以及其他應用程式格式，不能一概互換。格式轉換通常能處理常見欄位，但可能忽略新協定擴充、特殊傳輸與外掛程式參數。轉換後應核對節點類型與重要參數，不能將「轉換成功」視為端對端驗證完成。

訂閱回傳內容也可能因請求方式、帳戶狀態或服務提供者設定而改變。更新後若突然沒有節點，先查看回傳的是網頁、登入提示還是錯誤說明，再判斷是否為 YAML 語法問題。不要立即刪除原設定；保留可用副本有助於比較差異。分享疑難排解資料時，只提供已移除驗證資訊的結構與錯誤內容，不要公開原始訂閱 URL。

設定層次會影響覆寫與更新行為

Clash 風格的設定中，節點、代理集合、策略群組與規則各有不同用途。代理集合可從其他來源載入節點；策略群組決定如何選擇出口；規則則依序將請求分派至策略。規則引用的群組名稱必須存在，名稱變更可能導致啟動失敗或分流改變。訂閱更新新增節點後，也不一定會自動將它們加入手動指定的策略群組。

客戶端覆寫通常用於保留本機偏好，避免每次更新訂閱後都要重新設定。但合併方式可能是取代、附加或依名稱合併，不能假設所有客戶端的行為都相同。尤其要檢查新增規則的位置：若放在最終兜底規則之後，通常不會生效。先閱讀覆寫說明，再查看實際執行設定，確認結果符合預期。

以下規則片段可放入相應的設定區段；範例中的 PROXY 必須對應到已存在的策略群組。網域規則排在前面，接著是區域網路與地區規則，最後由兜底規則處理未符合的連線。這段內容只示範規則順序，不包含節點或完整 DNS 設定；地區規則也需要有相應資料才能使用，實際比對結果應搭配解析資訊與連線記錄確認。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

遷移時先驗證語法，再確認運作結果

YAML 對縮排與資料型別有要求，縮排應使用空格。密碼、特殊字元與容易被誤判的資料，應依來源要求正確加上引號；複製時不要把英文標點換成中文標點。若解析失敗，先檢查錯誤行附近的縮排、清單標記與鍵值關係；若遇到未知欄位或不支援的類型，再確認核心功能，不要把所有錯誤都當成格式問題。

遷移可分三個階段驗證：先確認設定能載入，再確認一個明確節點能正常存取，最後還原自動策略與複雜規則。若基本節點可用但網域連線失敗，檢查 DNS；若單一節點可用但自動群組無法使用，檢查群組成員與探測條件；若系統代理正常但 TUN 失敗，檢查本機接入與權限。依序檢查可減少不同問題互相干擾。

訂閱更新間隔應配合服務提供者的變更頻率。更新過於頻繁可能觸發來源限制，也會增加行動裝置的背景活動；長期不更新則可能保留失效節點或過時的憑證參數。更新失敗時，先確認連結與帳戶狀態，再檢查網路及回傳內容。規則資料與節點訂閱可能來自不同來源，應分別確認更新時間與載入記錄。

八、依使用情境選擇並建立疑難排解順序

桌面辦公與行動裝置的選擇起點

桌面辦公應優先確保瀏覽器、開發工具與會議軟體的連線路徑清楚。先在 Clash Plus 等合適的客戶端匯入完整訂閱，再以規則模式確認常用目標的命中情況。若應用程式支援明確指定代理，可先用系統代理或應用程式內的代理功能驗證；只有需要接管更多應用程式時再考慮 TUN，避免同時引入權限、路由與協定問題。

手機日常使用應優先考量連線恢復能力與背景穩定性，而不只是比較下載峰值。保留可信設定的預設傳輸方式，分別測試 Wi-Fi 與行動網路；若 QUIC 節點只在某種網路下失敗，保留 TCP 類節點作為備用。弱訊號環境下，應先改善訊號或更換網路，一味提高頻寬宣告通常無法解決重傳與無線電耗電問題。

使用即時語音或遊戲時，應確認應用程式的 UDP 流量確實進入核心，再檢查節點與伺服器是否支援轉送。優先觀察延遲抖動、封包遺失與連線持續性，不要用大型檔案的下載速度取代判斷。部分遊戲也依賴區域網路探索、專用連接埠或地區服務策略；代理只能處理其承載範圍內的連線，不能因為網頁存取成功就認定整個遊戲網路已設定完成。

路由器、旁路由與大量並行連線

在路由器上使用 mihomo 時，先確認硬體架構、可用記憶體與 CPU 效能，再選擇協定與規則規模。較複雜的傳輸組合、較多並行連線與較大的規則資料，都可能增加資源負擔。若全屋裝置同時變慢，先檢查路由器負載與連線狀態，避免將裝置效能不足誤判為所有節點品質下降。

使用旁路由時，也要釐清閘道、DNS 與回程路徑。某台裝置可以存取、另一台卻不行，可能是接入方式不同，而非代理協定不相容。不要先替所有裝置更換協定；先確認預設閘道、DNS 方向與路由規則，再測試相同目標。部署範圍可參閱路由器與旁路由執行 mihomo 概覽，並搭配本頁的協定選擇內容閱讀。

依錯誤發生階段逐層縮小範圍

第一步檢查載入情況。若核心無法啟動或節點未出現，請檢查 YAML、訂閱格式、未知協定與欄位支援。第二步檢查與伺服器的連線：位址解析失敗時查看 DNS；連線遭拒時檢查位址與連接埠；逾時則比較其他網路與傳輸方式。第三步檢查安全握手與驗證：依來源逐項核對憑證名稱、系統時間、密碼、UUID 與擴充參數。

第四步檢查目標存取。若已連上伺服器但仍無法使用，查看規則命中了哪個策略、目標網域如何解析，以及是否只有特定類型的請求失敗。若網頁正常但應用程式異常，優先確認接入方式；若網域連線異常但 IP 可用，則重點檢查 DNS。不要長期關閉憑證驗證、任意新增直連規則或刪除錯誤欄位來掩蓋根本原因。

第五步才調整效能。先更換相同條件下的節點，再更換傳輸類型，最後逐項調整頻寬宣告、連線重用或 TUN 設定。每次都記錄變更內容與觀察結果，並保留還原方式。若要回報問題，請提供作業系統、客戶端、核心名稱、錯誤階段與已去除敏感資訊的記錄；不要在公開附件中放上原始訂閱、密碼或完整設定。

最終選擇應是容易理解、能夠還原且穩定可用的組合，而不是參數最多的組合。若要繼續處理速度問題，可依節點、線路與本機設定三層定位法逐項檢查；安裝與權限問題請回到快速入門教學，零散錯誤則查看常見問題，避免跨層盲目修改。