Clash 協定與核心指南

協定選型的四個層面

用戶端、核心、協定與網路線路

Clash 生態系中的名稱分屬不同層面。用戶端負責視窗介面、訂閱管理、系統代理與權限要求；核心負責建立連線、比對規則與處理 DNS；協定規範用戶端和伺服器如何驗證身分、封裝及傳輸資料；線路則決定資料實際經過哪些網路。選擇用戶端，不代表同時選定了協定。安裝支援 mihomo 的圖形介面後，仍須確認訂閱中的節點類型與伺服器端參數。

這四個層面都可能各自出問題。介面能匯入設定，只代表檔案已載入管理工具，不保證核心能識別所有欄位；節點顯示連線成功，只代表一次連線測試完成，不代表適合影音串流、下載或即時通話。名稱相同的兩個協定節點，也可能使用不同的伺服器、出口、傳輸層與頻寬策略。因此比較協定時，應盡量讓伺服器位置、測試目標與時段一致，否則結果往往反映的是線路差異。

先確認限制條件，別急著看排名

先列出裝置系統、用戶端核心、伺服器端協定，以及目前網路允許的傳輸方式。辦公室網路可能允許 TCP 連線，卻限制 UDP；行動網路可能在切換基地台後改變 IP 位址；舊裝置也可能缺少高效率的密碼運算能力。如果伺服器只提供一種協定，用戶端無法只靠修改類型欄位就把它變成另一種。兩端的協定必須相符，連接埠、驗證資訊與傳輸選項也都要一致。

接著確認主要用途。瀏覽網頁較在意首次回應速度與短連線成本；傳輸大型檔案則更看重持續吞吐量；語音通話與遊戲則在意抖動、封包遺失及 UDP 轉送能力。遠端桌面還需要兼顧操作延遲與連線恢復。一套長時間下載表現穩定的設定，未必適合弱網通話；針對某項測試所做的最佳化，也可能增加背景流量與手機耗電。

分開評估安全性與連線品質

加密與驗證用來確認連線對象是否可信，以及如何保護傳輸內容；速度測試則反映目前路徑能提供的服務品質，兩者不能互相取代。使用憑證的設定應驗證憑證鏈與伺服器名稱；使用預先共用憑證的設定，則應確認憑證來源可靠。不要只因某個節點測速較快，就長期關閉驗證；也不要只憑較新的協定名稱，就認定安全性更高。

本指南不提供固定的速度排名。協定負擔會受到處理器、加密實作、路徑最大傳輸單元、封包遺失與伺服器負載等因素影響。閱讀後續章節時，可為每個候選節點記錄三項資訊：目前核心是否完整支援、目前網路是否允許其底層傳輸，以及實際用途是否有所改善。只要有一項尚未確認，就先保留已驗證的設定，不必一次修改多個參數。

SS 與 VMess：獨立加密代理的設計取捨

Shadowsocks 的精簡封裝

Shadowsocks 通常簡稱 SS，採用相對精簡的代理架構：用戶端接收本機連線，將目標位址與應用程式資料封裝後傳送給伺服器，再由伺服器建立目標連線。並非所有部署都需要使用網頁傳輸或憑證機制，基本設定主要包含伺服器、連接埠、加密方式與驗證資訊。這種架構容易跨平台實作，排查時也能從較少的必要欄位著手，但不代表所有 SS 節點的特性都相同。

SS 的加密方式不能任意互換。較早期的串流加密方案、常見的 AEAD 方案，以及後續的 Shadowsocks 2022 方案，都有不同的金鑰格式與實作需求。伺服器端採用哪種方案，用戶端就必須支援相應方式；部分方案要求特定長度與編碼的金鑰，不能使用任意密碼。遇到匯入錯誤時，應先確認加密方式名稱與金鑰格式，不要只嘗試更改伺服器連接埠。

SS 可承載 TCP；若用戶端、伺服器與網路都支援，也能轉送 UDP。用戶端的 UDP 開關只代表本機允許，伺服器、訂閱設定與網路路徑也必須符合條件。如果網頁正常，但遊戲或通話異常，應檢查這些流量是否確實經過代理、伺服器是否具備相關能力，以及目前網路是否限制 UDP。單次網頁連線測試無法證明 UDP 轉送可用。

VMess 的身分驗證與傳輸組合

VMess 源自 V2Ray 生態系，使用使用者識別碼進行驗證，並採用自己的協定加密與封裝機制。實際節點可能搭配 TCP、WebSocket 等傳輸方式，也可能同時使用 TLS。比較時必須完整說明各項組合，不能只說 VMess 比另一種協定快。直接傳輸與經過額外閘道的連線，在握手次數、封裝成本及中介設備支援方面都可能有明顯差異。

時間同步是排查 VMess 問題時值得檢查的項目。驗證機制對裝置時間有要求，系統時間偏差可能導致驗證失敗，但介面上往往只顯示逾時或連線中斷。應先讓作業系統自動同步時間，再檢查使用者識別碼與伺服器記錄。舊訂閱也可能包含歷史相容參數，欄位意義取決於核心實作，不能照抄過時教學中的數值。

WebSocket 路徑、請求主機名稱與 TLS 伺服器名稱分屬不同層面。路徑會用於應用層握手；請求主機名稱用於 HTTP 路由；TLS 名稱則參與握手與憑證驗證。這些名稱有時相同，但沒有必須相同的通用規定。伺服器經過反向代理時，漏填路徑或設錯請求標頭，可能導致連上伺服器，卻無法建立代理工作階段。這類問題與分流規則無關。

實際選擇與維護考量

在已確認可用的 TCP 網路與資源有限的裝置上，架構較簡單的 SS 設定適合作為基準；若已有完整的 VMess 部署，也不必只因名稱較舊就立刻遷移。真正值得評估的是伺服器維護狀況、加密設定、用戶端支援與日常用途表現。增加傳輸封裝可以滿足特定部署需求，但也會增加必須保持一致的欄位，並不會自動提升速度。

如果 SS 設定包含外掛參數，應另外確認用戶端是否實作該外掛及其指定模式。支援基本 SS，不代表支援所有外掛；節點轉換工具也可能遺失外掛選項。VMess 同樣有傳輸組合的相容限制。保留原始連結與設定來源，逐項比對轉換後的欄位，會比反覆切換執行模式更有效。遇到匯入問題，可先查看常見問題中的安裝與設定說明。

Trojan 與 VLESS：驗證、TLS 與傳輸分工

Trojan：以 TLS 建立安全通道

Trojan 的常見部署會以 TLS 作為外層安全通道，在通道內進行代理驗證與資料轉送。它不要求使用者另外維護一套獨立的應用程式加密演算法清單，設定重點則轉為密碼、憑證、伺服器名稱與伺服器監聽設定。這種簡化來自職責分工：TLS 負責保護傳輸，代理協定則描述目標與驗證方式。部署是否可靠，仍取決於憑證驗證與伺服器設定是否正確。

連線位址可以與憑證名稱不同。例如，用戶端透過某個位址連線至伺服器，但伺服器憑證是簽發給網域名稱，此時必須正確設定 TLS 伺服器名稱，並確認憑證確實符合該名稱。SNI 是在握手時傳送伺服器名稱的機制；憑證驗證則用來檢查身分與信任鏈。兩者相關，但並非同一件事。填入一個看似合理的網域名稱，不會讓錯誤的憑證變得可信。

排查 Trojan 連線失敗時，先區分 TCP 無法建立、TLS 握手失敗與代理驗證失敗。第一種通常與位址、連接埠和網路路徑有關；第二種應檢查系統時間、憑證有效期限、名稱是否相符與信任鏈；第三種才應著重檢查密碼與伺服器驗證設定。用戶端可能將多種失敗都顯示為逾時，因此要根據記錄判斷失敗階段，而不是直接修改所有 TLS 選項。

VLESS：輕量協定不等於具備獨立加密層

VLESS 同樣來自 V2Ray 相關生態系，設計上減少協定本身的部分負擔，將安全保護交由搭配的傳輸安全機制處理。不能將它理解為只填入使用者識別碼，就自然具備完整的加密保護。常見設定會使用 TLS 或 REALITY 等方案，但是否支援取決於用戶端核心與所選的傳輸組合。訂閱缺少安全層相關欄位時，應向設定提供者確認，不要自行猜測預設行為。

REALITY 的設定與一般憑證式 TLS 不同，通常涉及公鑰、短識別碼、伺服器名稱等相互對應的參數。即使使用者識別碼正確，只要這些欄位不相符，連線仍會失敗。部分 VLESS 部署也會指定流量控制方式，例如伺服器要求特定的 Vision 流量控制；這是兩端協商與實作上的限制，不是通用的加速按鈕。應依伺服器實際要求保留設定，不能看到相關欄位就套用到所有節點。

同一種 VLESS 節點也可能採用不同傳輸方式。用戶端支援基本 VLESS 協定，不代表支援伺服器使用的每一種傳輸、安全層與流量控制組合。節點分享連結也未必能呈現所有擴充欄位。確認相容性時，應查閱目前核心文件中的組合限制，並以實際產生的設定為準。光看用戶端名稱或一份協定支援清單，無法確認所有相容範圍。

憑證驗證與連線重用策略

停用憑證驗證會削弱用戶端辨識伺服器身分的能力，不應作為長期的修復方式。使用自簽憑證的環境，應依用戶端能力設定可信憑證或相應的身分限制；使用公開憑證時，則應修正名稱與憑證鏈。若只有一台裝置連線失敗，也應檢查系統時間、信任儲存區及安全軟體是否介入連線。同一節點在不同裝置上的表現可能不同，原因可能是本機環境，而非協定本身。

連線重用可讓多個邏輯請求共用底層連線，減少重複建立連線，但也可能改變壅塞競爭情形與故障影響範圍。共用連線發生阻塞時，多個請求可能同時受影響；若伺服器不支援相應的重用方式，也可能出現看似隨機的斷線。選擇 Trojan 或 VLESS 時，先以伺服器明確支援的最精簡設定完成測試，再評估連線重用、傳輸封裝與流量控制，通常比一開始就疊加選項更容易排查問題。

Hysteria2 與 TUIC：以 QUIC 為基礎的連線模型

QUIC 改變了哪個層面

QUIC 通常運作於 UDP 之上，結合加密握手、可靠傳輸與多路串流等能力。這裡的 UDP 是底層傳輸方式，不代表應用程式資料一定以不可靠方式傳送：網頁與檔案內容仍可透過可靠串流傳遞。與多個邏輯串流共用單一 TCP 位元組串流相比，QUIC 能減少不同串流間因依序交付造成的阻塞；不過，共用連線仍受同一路徑的壅塞狀況與可用頻寬限制，無法突破實體網路的容量。

Hysteria2 與 TUIC 都採用 QUIC，但並非同一種協定的不同名稱，驗證欄位也不能互換。伺服器若監聽 Hysteria2，用戶端就必須使用 Hysteria2 建立工作階段；TUIC 的不同協定版本也需要相應支援。用戶端介面顯示「支援 QUIC」，不足以證明能連線至任何以 QUIC 為基礎的代理服務，仍須確認節點類型與實作範圍。

Hysteria2 的頻寬估算與壅塞取捨

Hysteria2 適用於封包遺失較多或鏈路條件複雜的傳輸需求，並提供與頻寬設定相關的壅塞控制選項。設定中的上傳與下載頻寬通常代表用戶端預期的可用能力，不應直接照抄伺服器網卡標示的速度。若高估可用頻寬，可能增加排隊、競爭與封包遺失，影響網頁互動及同一網路中的其他裝置；估得太低，則可能限制持續傳輸速度。

伺服器端也可能限制頻寬或影響協商結果，因此不能只憑用戶端填入的數值判斷最終行為。應先採用維護者建議的設定，再透過持續下載與互動用途一併觀察。某些選用的混淆設定要求兩端一致，但不能取代憑證驗證與身分驗證。修改後若完全無法完成握手，應先還原這些選項，不宜立即將問題歸因於頻寬不足。

TUIC 的串流、資料報與連線維護

TUIC 同樣以 QUIC 承載代理工作階段，設定可能包含使用者識別碼、密碼、壅塞控制、UDP 轉送方式與連線維護參數。TCP 代理串流與 UDP 應用流量的處理方式不同；選擇可靠轉送或資料報方式時，應考量應用程式對即時性與完整性的不同要求。即時通話通常更在意是否能及時捨棄過期資料；檔案內容則要求依序可靠抵達，不能只用籠統的「穩定」來概括。

保活與閒置逾時設定決定連線在沒有資料傳輸時如何維持。行動網路中的位址轉換設備可能很快回收 UDP 對應紀錄，適當的保活有助於後續資料抵達；但過於頻繁的保活會增加無線網路喚醒次數與背景流量。網路切換後連線能否延續，還取決於實作、伺服器與網路路徑，不能把 QUIC 的連線遷移能力理解成任何用戶端都能保證工作階段不中斷。

UDP 路徑並非始終可用

如果目前網路明顯限制 UDP，這兩類協定可能比以 TCP 為基礎的方案更難建立連線。增加重試次數通常無法解決底層網路無法連通的問題。也要留意封裝後的封包大小：額外代理層、通道或接入網路可能縮小路徑可用的傳輸單元，導致小型請求正常、大量傳輸卻停滯。應透過記錄與不同網路的對照逐層確認，不要任意調低所有裝置的系統參數。

適合的評估方式是準備一組已驗證的 TCP 設定作為對照，在同一網路中分別測試網頁、持續傳輸與閒置後恢復。QUIC 方案在某些封包遺失的網路路徑上可能更合適，也可能受到電信業者網路的速率限制。選擇時應看實際用途是否能重複改善，而非單次峰值。後續調整也要兼顧伺服器承載能力及共享網路中的其他應用程式。

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

將一次測速拆成多個階段

使用者感受到的等待時間，包含網域名稱解析、底層連線、協定握手、目標網站回應與內容傳輸。節點延遲測試通常只涵蓋其中一部分，不等於每個網站的首頁載入時間。節點測試回應很快，仍可能因出口到目標網站的路徑不佳而下載緩慢。判斷協定差異時，應分別記錄首次造訪、重複造訪與長連線用途，避免把快取與工作階段重用帶來的變化誤當成協定優勢。

持續吞吐量會受到傳送視窗、壅塞控制、往返時間與封包遺失影響。往返時間較長的高頻寬鏈路，需要足夠的資料在途才能充分利用容量；發生封包遺失後，不同控制策略的恢復速度也各不相同。不過，更積極地傳送資料不一定比較好，可能塞滿接入鏈路的佇列，讓互動延遲升高。因此評估下載速度時，也應同時開啟常用網頁或進行語音通話，觀察是否犧牲其他用途的可用性。

處理器負擔來自整個處理流程

加密只是資源成本的一部分。使用者空間網路堆疊、資料複製、傳輸封裝、連線重用、規則比對與記錄輸出都會消耗處理器資源。不同處理器對特定密碼演算法的硬體支援也不同，不能直接把桌上型電腦的測試結果套用到手機或路由器。低功耗裝置若持續處於高負載，應分別比較系統代理與 TUN、精簡設定與完整設定，找出瓶頸所在。

記憶體使用量通常也會受到連線數、規則集合、訂閱規模、快取與介面程序影響。只比較兩個用戶端的總記憶體用量，未必能看出核心效率差異：其中一個可能載入更多規則，另一個可能沒有開啟連線面板。比較時應維持規則與用途一致，並分開觀察圖形介面與核心程序。路由器的記憶體餘裕尤其重要；記憶體不足導致程序結束，容易被誤認為協定斷線。

手機耗電與無線網路喚醒

手機耗電不只來自加密，也來自維持無線連線、背景喚醒、重新連線與流量測試。頻繁檢查所有節點、保活間隔過短或持續輸出詳細記錄，都可能讓裝置難以維持閒置狀態。協定名稱本身無法決定固定的耗電排名。應使用同一支手機、同一網路與相近的流量進行比較，結果才有參考價值；螢幕亮度與訊號強度也應盡量一致。

行動作業系統通常透過 VPN 或網路延伸機制接管流量，實際方式由平台與用戶端決定。用戶端顯示的 TUN 名稱，不一定代表它與桌面環境採用相同實作。系統省電策略可能暫停背景活動，恢復後則需要重新建立工作階段。若鎖定螢幕後才出現異常，而前景使用正常，應先檢查背景權限與網路恢復行為，再調整協定。盲目縮短保活間隔或許能掩蓋問題，卻會增加日常耗電。

建立可重現的比較紀錄

每次只改變一項因素：保持節點地區與目標網站一致，固定是否啟用 TUN，暫停自動節點測試，再分別觀察短請求、大型檔案與閒置後恢復。不要在下載途中同時更新訂閱、切換 DNS 與修改壅塞參數，否則無法判斷結果原因。建議記錄發生時段、網路類型、錯誤階段與實際用途表現，不要只留下一張峰值截圖。

若只有特定應用程式異常，也要檢查分流規則與解析路徑。Fake-IP 是網域映射機制，不是加速協定；TUN 擴大流量接管範圍，也不保證所有連線都變快。啟用後表現改變，可能只是原本直連的流量改走代理。可查看連線記錄，確認命中的規則與出口，再參閱網速慢的三層排查方法，依序檢查節點、線路與本機。

原版 Clash、Clash Meta 與 mihomo

專案沿革與功能來源

原版 Clash 建立了以 YAML 描述代理、策略群組與規則的使用方式，許多圖形介面用戶端也沿用這套設定模型。原版專案停止維護後，既有安裝仍可能正常執行，但不應期待它持續取得新協定支援與相容性修正。舊用戶端能識別常見設定，不代表能處理後來新增的協定欄位。遇到不認識的類型時，應先確認實際負責建立連線的核心，而不是只看視窗標題。

Clash Meta 是以 Clash 相關技術為基礎發展出的擴充核心分支，後來以 mihomo 名稱持續維護。使用者所說的 Meta、設定檔中的擴充功能，以及目前的 mihomo 文件，往往都指向同一段發展脈絡，但舊安裝套件仍可能保留過時實作。名稱只能說明專案來源，不代表所有標示 Meta 的用戶端都具備相同功能，仍須查看用戶端提供的核心資訊與維護說明。

mihomo 擴充了協定、規則、DNS 與網路流量接管等功能，成為多款桌面與行動用戶端的連線基礎。圖形介面通常另外負責訂閱下載、設定覆寫與權限管理。因此，某項功能可能分散在兩個部分：核心能讀取相關欄位，但介面沒有對應選項；或者介面提供了選項，目前的核心卻不支援相應寫法。查閱文件時，應分別核對介面與核心的說明。

支援設定結構，不等於支援所有欄位

三者之間的延續性，常見於代理清單、策略群組與規則等基本結構；但擴充協定、規則行為與 DNS 欄位並非完全向下相容。將新設定交給舊核心，可能直接載入失敗，也可能忽略部分欄位；舊設定交給新核心，也可能因欄位限制更嚴格而暴露問題。成功載入只是第一步，還要確認規則實際作用方式、網域解析結果與 UDP 流量。

用戶端選擇與舊環境遷移

初次選擇時，可先從下載頁推薦的 Clash Plus 開始，再依作業系統確認支援範圍與設定方式。桌面環境也可比較 Clash Verge Rev、FlClash 與 Clash Nyanpasu；行動裝置則可依下載頁查看 Clash Meta for Android、FlClash 或 Surfboard 支援的格式。不同用戶端未必使用相同的設定語法，尤其不能因為都能接收訂閱連結，就認為能直接共用完整設定檔。

Clash for Windows 與 ClashX Meta 在下載清單中列為停止維護的封存版本。遷移前應保留原始訂閱網址、個人規則、覆寫內容與必要的本機設定；不要直接覆蓋舊資料夾。先在新用戶端匯入訂閱，再分別測試系統代理、TUN 權限、開機啟動與連接埠。舊環境中的可執行指令碼不宜直接複製執行，應先了解它修改了哪些設定欄位。

只有在用戶端明確支援時，才應切換核心。不同核心套件可能依賴特定控制介面、啟動參數與權限管理方式，手動替換檔案可能導致介面狀態與實際執行內容不一致。若要確認切換是否成功，應查看執行程序與啟動記錄中的核心資訊，再檢查設定載入結果。不要只根據設定選單顯示的選項判斷，殘留程序可能仍占用舊連接埠。

遷移時建議分兩階段排查：先以最精簡的訂閱設定建立連線，再逐項還原規則與覆寫內容。發生異常時，便能判斷問題來自協定相容性或個人化設定。專案關係的進一步說明請見三代核心功能與相容性比較；從舊桌面環境搬遷時，可參考Clash for Windows 遷移步驟，避免把用戶端管理層的問題混入協定測試。

訂閱格式、欄位保留與設定合併

訂閱網址不代表固定的檔案格式

訂閱是一種更新入口，回傳內容可能是完整的 Clash YAML、節點清單、編碼後的分享連結集合，或其他用戶端專用設定。同一個網址也可能依請求方式回傳不同格式。因此，「連結能開啟」不代表「目前用戶端能解析」。先確認訂閱提供者標示的目標用戶端，再查看匯入提示。若回傳的是網頁、登入頁或錯誤文字，應先處理存取與授權問題，而不是修改 YAML 縮排。

完整設定可以包含代理、策略群組、規則與 DNS；節點訂閱通常只描述連線端點，策略與分流則須由本機設定提供。混淆兩者容易造成規則突然消失或策略群組找不到節點。部分用戶端匯入時會自動產生範本，讓問題暫時不明顯，直到換用其他用戶端才浮現。閱讀設定時，應先辨認頂層結構，再檢查其中的協定欄位，不能只搜尋節點名稱。

轉換只能改變格式，無法補齊未知資訊

格式轉換工具通常會將已知欄位對應至另一種語法，但無法憑空還原來源資料中沒有的公鑰、憑證名稱、外掛參數與傳輸路徑。目標格式不支援某項功能時，也可能直接捨棄相關欄位。轉換完成後，應確認協定類型、位址、連接埠、身分資訊、TLS 與傳輸選項是否完整，尤其要留意 Hysteria2、TUIC 及包含擴充組合的 VLESS 節點。

分享連結適合傳送單一節點，但完整設定還包含規則順序、策略群組相依項目與本機解析行為。將一組節點連結匯入另一款用戶端，不代表原本的網路策略也一併遷移。Surfboard 等用戶端採用的設定架構也有各自要求，不能只修改副檔名就使用 Clash YAML。若格式不相容，應向提供者索取適用於目標用戶端的訂閱，不要不斷轉換，徒增不確定性。

分開管理遠端更新與本機策略

訂閱更新通常會取代由遠端管理的內容；若直接修改下載的檔案中的節點或規則，下次更新時可能就會遺失。較穩妥的作法是由訂閱提供節點來源，本機覆寫則管理個人規則、DNS 與分組；不過，實際合併順序取決於用戶端。有些會以本機欄位覆蓋遠端欄位，有些則會附加或取代清單。操作前應查閱合併說明，並檢查最後交給核心的設定。

以下片段僅示範可解析的最小規則結構，不含遠端節點。適合用來說明頂層欄位之間的關係，不應取代現有訂閱。實際使用時，代理群組名稱必須指向確實存在的節點或內建策略；規則會依序比對，較寬泛的規則若排在前面，可能遮蔽後續較精確的條件。修改後先執行用戶端提供的設定檢查，再查看連線記錄是否命中預期規則。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: 預設策略
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,預設策略

解析設定也屬於設定相容範圍

Fake-IP 透過虛擬位址映射保留網域資訊，搭配規則與流量接管使用；它不是節點協定的一部分。匯入訂閱後若同時更改 DNS 模式，即使代理節點完全相同，應用程式的表現也可能改變。應確認由誰接收解析請求、是否有系統或應用程式內建的加密 DNS，以及流量接管範圍是否涵蓋預期流量。只看單一 DNS 開關，無法確認完整的解析路徑。

排查設定合併問題時，先保留原始內容與最終設定的副本，隱去訂閱憑證後再比較相關欄位。不要把訂閱網址上傳至不明的轉換服務，也不要在公開記錄中保留驗證資訊。若遇到網域相關異常，可參閱DNS 請求路徑與 Fake-IP 設定說明。每次只調整一組設定，確認正常後再繼續，避免更新、合併與解析問題彼此交疊。

依使用情境選擇協定並完成驗證

桌面瀏覽、開發與持續傳輸

日常瀏覽網頁與使用開發工具，可先採用伺服器維護狀況明確、用戶端完整支援的設定，不必一開始就追求複雜的傳輸組合。瀏覽器通常會遵循系統代理，因此較容易確認流量走向；命令列工具與獨立執行環境則可能需要另外設定代理。若終端機連線失敗但網頁正常，應先檢查該程式是否使用代理，而不是立刻更換協定。容器、虛擬機器與遠端開發環境也可能有獨立的網路設定。

下載大型檔案時，應觀察持續吞吐量與恢復能力，不要只看開始時的峰值。如果 TCP 方案穩定，就保留作為基準；若網路路徑有明顯封包遺失且 UDP 可用，可比較測試 Hysteria2 或 TUIC。測試期間也要留意互動回應與裝置負載。調整頻寬參數後若有改善，應確認不會影響其他用途；短時間占滿整條網路，不代表這就是普遍最佳設定。

行動通勤與即時應用程式

手機通勤時經常遇到網路切換、訊號變化與背景休眠。應優先測試鎖定螢幕後的恢復情形、從 Wi-Fi 切換至行動網路，以及長時間閒置後的首次請求。底層機制若支援連線遷移，或許能改善部分情況，但仍須確認用戶端與伺服器是否確實啟用。若某種設定在固定網路下速度很好，卻在每次切換後都必須手動重新連線，可能不適合目前的行動使用情境。

遊戲與通話需要確認 UDP 轉送、規則命中情形與出口位置。節點顯示可用，不代表即時流量確實使用該節點；有些應用程式會同時連線至驗證、媒體與更新服務，這些連線可能分別命中不同規則。應先查看個別連線，再判斷是否需要調整協定。遠端桌面還要留意畫面更新、鍵盤滑鼠回應，以及短暫封包遺失後的恢復能力，不能只以檔案下載速度作為判斷依據。

伺服器、路由器與受限網路

伺服器與路由器通常適合直接管理 mihomo 核心，但也需要自行維護程序、權限、設定更新與記錄輪替。資源有限時，應控制規則規模與連線測試頻率，避免除錯記錄長期占用儲存空間。遠端修改設定前，應保留可用的復原管理通道，先檢查設定再重新載入服務。將桌面用戶端產生的完整設定搬到路由器時，也要檢查檔案路徑、監聽位址與權限差異。

若辦公室或訪客網路限制 UDP，應優先測試可用的 TCP 設定，不要持續重試 QUIC。需要經過額外代理或閘道時，也應確認是否出現多層封裝與位址解析差異。如果某個節點只在一種接入網路中失敗，先改用另一個網路重新測試，再檢查本機設定。反過來說，如果所有網路都在相同驗證階段失敗，通常應優先檢查憑證、憑證驗證與協定欄位。

統一的驗收與復原順序

首次驗收時，先檢查設定能否載入，再建立基本連線，接著確認規則、DNS 與目標應用程式。每個步驟都應留下明確結論：核心識別了哪種協定、請求命中了哪項策略，以及實際出口是否符合預期。發生失敗時，回復至最近一次正常的設定，不要同時切換核心、訂閱來源與網路模式。用戶端異常結束與協定握手失敗也要分開排查；前者可參閱啟動閃退與記錄排查。

1. 確認伺服器端協定與用戶端核心，檢查身分、傳輸與安全層欄位。
2. 在已知可用的網路上測試一般網頁，確認實際命中的策略。
3. 分別測試持續傳輸、即時應用程式與閒置後恢復，並記錄失敗階段。
4. 一次只調整一項變數，重複相同測試，再決定保留或還原。

最後應準備一套主要設定，以及一套經過驗證的替代設定。替代方案最好採用不同的底層傳輸條件，避免兩者依賴同一條故障路徑，同時也要確認憑證與設定來源可信。需要安裝用戶端時，請從下載頁選擇對應平台，優先推薦 Clash Plus；操作方式請參閱使用指南，一般故障排查則可查看常見問題。協定只是連線方式，無法保證在任何網路環境下都有相同結果。