Clash 協定詳解
mihomo 核心與相容性

連線分層：協定、傳輸與出口路徑

先分清四個設定層次

用戶端介面常將協定、節點和代理群組排在一起，但三者並非同一回事。協定規範用戶端如何向伺服器驗證身分及交換資料；節點是包含位址、連接埠、憑證與傳輸參數的設定項目；代理群組則負責從多個出口中選擇。規則會決定某條連線交由哪個代理群組處理。同一種協定可以有許多節點，同一個代理群組也能包含不同協定。因此，切換節點後速度改變，不能直接歸因於協定不同，也可能是線路、伺服器負載或目標網站造成的。

傳輸層也要分開辨認。有些協定直接使用 TCP 連線，有些可搭配 WebSocket 或 gRPC，另一些則以 QUIC 為基礎。TLS 提供身分驗證與加密通道，可與不同應用層協定組合。介面顯示 VLESS，不代表連線已啟用 TLS；顯示 WebSocket，也不代表使用了獨立的加密協定。查看參數時，應分別確認協定類型、底層傳輸、安全層與伺服器身分，不要只看名稱判斷功能。

應用程式流量如何進入核心

系統代理會透過作業系統設定，告知應用程式使用 HTTP 或 SOCKS 入口；應用程式是否遵循設定，則取決於自身實作。TUN 模式透過虛擬網卡與路由接管符合條件的流量，涵蓋範圍通常較廣，但也會牽涉權限、路由及 DNS 協調。入口方式與遠端協定彼此獨立：啟用 TUN 不會讓 SS 節點變成 QUIC 節點，關閉系統代理也不一定會停止已由 TUN 接管的連線。排查前先確認流量是否進入核心，再檢查遠端交握是否成功。

一次連線通常會經過網域名稱解析、規則比對、策略選擇、連線至伺服器及存取目標等環節。實際順序會受 DNS 模式、網域規則與既有解析快取影響。例如 IP 類規則可能觸發解析，帶有 no-resolve 的規則則會限制該規則主動解析網域名稱。若記錄顯示 DIRECT，問題可能出在規則或模式，而非節點協定；若顯示交握失敗，再檢查驗證、系統時間、憑證與傳輸欄位。

分開記錄延遲、吞吐量與可用性

節點延遲通常是用戶端透過代理存取某個測試位址所需的時間，可能包含建立連線、TLS 協商、伺服器轉送及網站回應。這不只是網路往返時間，也不代表大型檔案的下載速度。吞吐量則會受到路徑頻寬、壅塞控制、視窗大小、目標限速及裝置處理能力影響。可用性關注的是連線能否穩定成功。小型請求回應很快的節點，持續下載時可能受限；首次連線較慢的節點，也可能在重用連線後表現穩定。

比較協定時，最好固定伺服器所在地區、測試目標、用戶端版本與入口方式，並分別測試冷啟動請求、連續瀏覽及持續傳輸。如果無法統一這些條件，結果只能代表目前節點組合的表現，不能當成協定結論。記錄中的逾時也要區分解析逾時、連線逾時與讀取逾時：前者優先檢查 DNS，中者檢查路徑與連接埠，後者再觀察伺服器及目標網站。先建立這套分層概念，之後才能有依據地調整參數。

SS 與 VMess：輕量轉送與連線驗證

Shadowsocks 的設計重點

Shadowsocks 通常簡稱 SS，設計重點是以相對精簡的協定承載代理流量。常見設定包含伺服器、連接埠、密碼與加密方法，不像 HTTPS 一樣必須設定網域憑證。其歷史實作經歷不同世代，不能把所有 SS 節點都視為完全相同的線上協定。傳統串流加密、AEAD 與 Shadowsocks 2022，在金鑰處理、訊息格式及實作需求上都有差異。選擇時應先確認用戶端支援的具體加密方法，而不只是確認介面有 SS 選項。

AEAD 結合加密與完整性保護，金鑰長度、密碼衍生或編碼方式會因方法而異。Shadowsocks 2022 的金鑰有明確格式要求，不能直接以一般文字密碼取代。伺服器指定的方法必須與用戶端一致，憑證資訊也應照原樣使用。加密演算法的實際負載還取決於處理器指令支援；某種方法在桌上型裝置上運作輕快，不代表在較舊的手機或路由器上也有相同優勢。不要只依演算法名稱跨裝置比較效能。

TCP、UDP 與外掛不是同一個開關

SS 可承載 TCP，也有 UDP 轉送機制，但要能正常使用，仍需用戶端、伺服器與網路路徑同時支援。用戶端啟用 UDP，只代表允許相關轉送，無法補足伺服器缺少的功能。部分節點還依賴額外外掛提供傳輸封裝，外掛名稱、模式與參數都屬於設定的一部分。只複製位址與密碼，可能匯入成功，卻無法建立連線。若訂閱來源明確，應優先保留原始設定，不要憑經驗刪除看似陌生的外掛欄位。

若 TCP 瀏覽正常，但遊戲或語音異常，先確認應用程式確實進入代理、規則有套用到該節點，再檢查 UDP 支援與回程路徑。DNS 查詢成功不代表所有 UDP 應用都能運作，因為 DNS 可能由核心透過另一條路徑處理。遇到大封包異常，也要考慮路徑 MTU 與分片問題。此時單純更換加密方法通常無法對症下藥，反而會增加變數，甚至讓原本正常的 TCP 連線失效。

VMess 的背景與驗證限制

VMess 源自 V2Ray 生態系，協定本身負責驗證及資料保護，並可搭配多種傳輸方式。常見節點使用 UUID 識別使用者，舊版設定中也可能出現早期的驗證欄位。目前的實作多以 AEAD 為主，但舊訂閱及不同核心對歷史欄位的處理方式並不完全一致。不能因為某個舊用戶端曾接受某份設定，就認定所有新核心都會以相同方式解讀。遷移時應先取得適用於目標核心的設定，再處理歷史相容選項。

VMess 驗證與時間有效性有關，因此系統時間明顯不準時，可能會顯示驗證失敗。先開啟系統時間同步，再檢查 UUID 與伺服器設定。若節點使用 WebSocket，還要確認路徑與 Host；若啟用 TLS，則接著核對 SNI 與憑證。UUID 正確只是必要條件之一。若把所有連線失敗都當成憑證錯誤，容易忽略底層傳輸尚未建立，反覆重新匯入訂閱也不會改善。

在已知連線路徑上，SS 適合重視設定精簡與實作成熟度的使用者；VMess 則適合已有相應伺服器與傳輸設定的環境。這是維護成本上的取捨，不代表品質高低。若現有節點穩定，僅因協定推出較早就更換，並沒有充分理由；若需要較新的傳輸功能，也應先確認伺服器是否提供，而不是只在用戶端下拉選單中更改協定類型。

Trojan 與 VLESS：驗證與安全層的組合

Trojan 將安全工作交由 TLS 處理

Trojan 以 TLS 通道為基礎，在通道內完成代理驗證與資料交換。相較於由協定本身負責所有加密工作的方案，這種分工仰賴成熟的 TLS 實作與憑證機制。用戶端常見參數包含位址、連接埠、密碼與伺服器名稱。設定項目看似不多，但網域解析、憑證有效性與伺服器部署必須一致。能連上連接埠，不代表 TLS 身分驗證成功；TLS 交握成功，也不代表密碼驗證一定通過。

連線位址與 SNI 可以不同。連線位址用來找到伺服器；SNI 則在 TLS 交握時指出預計存取的服務名稱，憑證驗證也必須符合預期身分。伺服器採用多站台部署時，SNI 錯誤可能會讓請求連到另一組憑證或服務。直接將網域換成 IP 後若出現憑證錯誤，不要立刻關閉驗證；應先確認原設定是否要求獨立的伺服器名稱，以及該名稱是否與伺服器提供的憑證相符。

VLESS 的輕量來自職責拆分

VLESS 同樣源自 V2Ray 相關生態系，其設計移除了 VMess 協定層內建的加密負擔，將使用者識別與外部安全傳輸分開。UUID 主要用於驗證，不應視為加密金鑰。VLESS 連線若未設定適當的安全層，不能只憑協定名稱就認定通訊內容受到保密保護。實際使用時必須確認 TLS、REALITY 或其他部署需求，且相關功能需要用戶端核心與伺服器共同支援。

REALITY 是另一種需要特定支援的安全交握機制，不能簡單視為一般 TLS 的別稱。公鑰、短識別碼與伺服器名稱等參數各有特定用途，不能從一般憑證設定中任意拼湊。VLESS 的 flow 也不是通用加速開關，只有在指定傳輸方式與伺服器設定相符時才有效。若用戶端不認得相關欄位，刪除欄位後即使能匯入，也不代表設定仍然正確；較穩妥的作法是確認目標核心支援後，重新取得相符的設定。

WebSocket、gRPC 與多路複用的成本

WebSocket 會將雙向資料放在 HTTP 升級後的連線中，路徑、要求標頭與伺服器入口必須一致。gRPC 通常仰賴 HTTP/2，服務名稱、連線協商及反向代理設定也會影響結果。這些封裝方式可配合既有部署，但會增加協定層次與故障排查環節。原生 TCP、WebSocket 與 gRPC 沒有不受部署條件影響的固定速度排名；中間代理、連線重用與伺服器資源設定，往往比封裝方式更影響使用體驗。

多路複用能減少重複建立連線的成本，但共用連線也可能讓多個請求一起受到壅塞或底層連線異常影響。並非所有伺服器都支援相同的多路複用方式，也不是每種短連線工作負載都能受益。排查時可在伺服器允許的情況下，比較多路複用開關的差異，觀察新連線耗時、持續傳輸與錯誤恢復情況，不要只看一次節點延遲。不要同時修改多路複用、傳輸方式與 DNS，否則無法判斷改善來自哪項設定。

若已有正確的 TLS 部署，且希望維持清楚的驗證流程，Trojan 是合適選項；VLESS 則著重驗證與安全傳輸的彈性組合，但使用者需要確認更多搭配條件。兩者在用戶端的填寫方式可能相似，卻不能互換密碼與 UUID，也不能只改類型欄位就完成轉換。選擇前請保留原始訂閱，並在連線詳情中確認實際使用的出口類型；有需要時可參閱核心功能與設定相容性筆記，確認支援範圍。

Hysteria2 與 TUIC：QUIC 和 UDP 路徑

QUIC 改變傳輸方式，不會改變實體網路路徑

QUIC 以 UDP 為承載，在使用者空間實作可靠傳輸、壅塞控制與安全交握。它可減少不同資料流因單一資料流遺失封包而在傳輸層互相等待，但不代表封包遺失沒有代價，也無法突破路徑頻寬。所有資料流仍共用連線的壅塞狀態與實際網路資源。將 QUIC 簡化成「更快的 UDP」容易造成誤解：UDP 只是底層承載，可靠性、確認與流量控制仍須由協定實作負責。

Hysteria2 與 TUIC 都運用 QUIC，但兩者是不同協定，驗證欄位、轉送機制與參數意義並不相同。伺服器若只提供其中一種，用戶端不能只改類型就將它轉換成另一種。網路必須允許通往伺服器的 UDP 通訊；行動網路、企業閘道器、路由器或伺服器防火牆只要有一處限制 UDP，都可能造成連線失敗。瀏覽器能開啟一般 HTTPS 網站，只能證明 TCP 路徑基本可用，不能證明 QUIC 節點的 UDP 路徑正常。

Hysteria2 的頻寬參數應符合實際狀況

Hysteria2 以 QUIC 為基礎，提供適用於複雜連線的代理傳輸，並支援依預期頻寬選擇壅塞控制方式。不同模式下頻寬欄位的作用不盡相同，也可能受到伺服器策略限制。將上行與下行數值填得很大，不代表能取得更多頻寬；預期值設得過於積極，反而可能造成佇列堆積、封包遺失及其他應用程式延遲升高。請依目前的網路連線與伺服器限制保守設定，並觀察持續傳輸時互動請求是否也變慢。

上行能力尤其容易被忽略。家用寬頻或行動網路的上行速度可能明顯低於下行，確認封包、應用程式上傳與其他裝置都會共用這項資源。若只在下載時發生通話卡頓，應先確認是否有佇列堆積，而不是直接提高下載頻寬設定。Hysteria 和 Hysteria2 也不是可互換的同名寫法，匯入時要確認伺服器明確提供哪一代協定。驗證資訊、混淆設定與 TLS 參數都應一併保留，不能只轉移密碼欄位。

TUIC 的連線階段、憑證與實作相容性

TUIC 同樣使用 QUIC 承載代理連線，其實作可結合可靠資料流與資料報機制，處理不同類型的流量。設定時應確認實作支援的協定版本、UUID 與密碼等驗證參數，以及憑證和伺服器名稱。部分實作提供零往返、壅塞控制或 UDP 轉送模式選項，但這些並非可各自獨立使用的一組開關，必須配合伺服器功能。訂閱轉換工具若漏掉相關參數，節點即使成功出現在清單中，也可能無法正常轉送流量。

零往返可降低符合條件的恢復連線成本，但需要先前的連線狀態，也有重放攻擊相關限制，不能保證首次連線也能省下所有等待時間。行動裝置切換網路後能否順利恢復，還取決於連線遷移實作、位址變更、NAT 狀態與用戶端生命週期管理。QUIC 在協定層具備相關機制，不代表每個用戶端在 Wi-Fi 與行動網路切換時都不會斷線。應以實際應用程式測試恢復情況，而不是只根據協定介紹推測體驗。

若 UDP 路徑穩定、伺服器部署相符，這兩類協定都可列入候選。若經常使用網路狀況不明的訪客網路，應另外保留一個 TCP 類節點作為備援，而不是反覆修改同一份 QUIC 設定。備援的用途是因應不同路徑條件，並非預設某一種協定永遠比較好。

效能與耗電：測試方式及資源取捨

連線速度要拆分成不同指標

首次連線耗時包含 DNS、連線至伺服器的交握、協定驗證，以及建立目標連線；重用既有連線則可能省去其中部分步驟。網頁載入還仰賴多個網域與並行請求，因此單一測試位址的結果無法代表整個頁面。比較時應一併記錄首次回應時間、頁面載入完成時間、持續下載速度及錯誤次數。只有找出拖慢體驗的環節，才能判斷應更換節點、調整 DNS，還是檢查交握與連線重用，而非一味追求最低延遲數字。

測試吞吐量時，別把測試來源本身的限速算在節點頭上。優先使用固定且可信的測試目標，在相近時段進行多輪比較，測試期間暫停其他大量流量工作。伺服器位置與出口線路不同的兩份設定，只能用來選擇符合實際需求的方案，不能用來證明協定優劣。持續下載會消耗流量並提高裝置溫度，在行動網路下尤其要控制測試時間。記下網路類型、入口模式與裝置狀態，比只保存一個速度數字更有參考價值。

CPU、記憶體與 TUN 負載

加密、解密、封裝、封包處理與規則比對都會消耗處理器資源。高頻寬下，使用者空間的 QUIC 可能增加運算與封包處理負載；某些支援硬體加速的加密方法，則可能在特定裝置上效率更好。這些都要視條件而定。不能一概認定 TCP 協定比較省電，也不能說 QUIC 一定更耗記憶體。連線數量、緩衝區、核心實作與應用程式請求模式同樣會影響結果，應在目標裝置上實際觀察。

TUN 會增加虛擬網卡與協定堆疊處理；DNS 接管、流量嗅探及大量連線記錄也可能帶來額外負載。若系統代理已涵蓋日常使用的應用程式，可先用系統代理建立基準，再啟用 TUN 比較涵蓋範圍與資源變化。需要使用 TUN 時，不要為了降低少量負載而犧牲必要功能，但可確認是否啟用了不需要的偵錯記錄、過於頻繁的自動測速或重複 DNS 查詢。記憶體用量偏高也可能只是快取累積，應分辨穩定用量與持續成長。

行動裝置耗電常與喚醒頻率有關

手機耗電不只來自加密運算，也與無線模組持續運作、背景喚醒、訊號強弱及重新連線有關。保活頻率過高會增加喚醒次數，頻率過低則可能讓 NAT 對應逾時，導致下次請求必須重新建立連線。並沒有適用所有行動網路的最佳固定值。若鎖定螢幕後常常斷線，先檢查用戶端的背景權限與系統省電限制，再檢查連線保活；只把保活頻率調得很高，或許能改善表面上的連線可用性，卻可能明顯增加待機耗電。

比較耗電情況時，應盡量維持相近的螢幕亮度、網路類型、背景應用程式與工作負載，並分別觀察主動使用和鎖定螢幕待機。短時間內電量百分比的變化容易受電池估算誤差影響，不適合用來做細微排名。可搭配系統電池用量、背景活動時間、裝置溫度與連線記錄判斷。若用戶端不斷嘗試連線到無法連線的節點，即使實際傳輸量很少，也可能耗電；此時修正節點可用性與重試策略，通常比更換加密演算法有效。

可重複使用的測試流程如下：先在固定網路確認節點可用，再連續進行瀏覽、下載、語音或遊戲等實際工作，接著觀察鎖定螢幕後的恢復情況與網路切換，最後記錄電量和錯誤狀況。每次只更換協定或一項相關參數，並至少重複比較一次。若低延遲伴隨較高溫度與更頻繁的重新連線，應依實際用途權衡，不要認定測試數字較小的方案就一定最好。模式變數可參考規則、全域與直連模式說明。

核心系列：原版 Clash、Meta 與 mihomo

分開判斷用戶端介面與代理核心

圖形用戶端負責訂閱管理、系統代理、服務安裝、操作介面與平台整合；核心則負責解析設定、比對規則及執行出口連線。介面相似不代表功能相同，同一個用戶端換了核心後，表現也可能不同。詢問是否支援 VLESS 或 Hysteria2 時，應同時提供用戶端名稱與核心資訊。僅憑應用程式名稱中有 Clash，無法判斷它是否支援特定協定、TUN 或規則欄位，更不能保證設定檔能直接遷移。

原版 Clash 奠定了規則導向代理、代理群組與 YAML 設定的基本使用方式。Clash Premium 曾提供不同於一般開源版本的擴充功能，不能把它當成所有原版版本共通的功能清單。Clash.Meta 在相關生態系的基礎上擴充協定與設定功能，後續以 mihomo 名稱持續發展。Meta 與 mihomo 的關係較接近同一專案的延續，而非兩個必須並行安裝的服務。舊教學仍可能使用 Meta 這個名稱，閱讀時應依實際核心功能判斷。

語法相同不代表完全向下相容

代理、代理群組及規則等基本結構延續性較高，但新增協定、DNS 選項、規則類型與 TUN 欄位可能超出舊核心的支援範圍。舊設定匯入新核心後也不一定完全相同：欄位預設值、過時選項的處理方式與平台實作都可能有差異。解析成功只代表設定已被接受，不能證明連線路徑與以往一致。遷移後至少應測試訂閱節點、代理群組選擇、網域分流、區域網路存取及 DNS 行為，不要只把順利啟動當成完成。

作業系統也會影響功能範圍。TUN 權限、系統服務、虛擬網卡與路由實作都因平台而異；桌面端能使用的設定，不一定能原封不動套用到手機。部分圖形用戶端會產生或覆寫核心設定；若直接編輯執行中的檔案，訂閱更新或重新啟動後可能會還原預設內容。修改前應先確認用戶端提供的是設定覆寫、合併指令碼還是直接編輯原始檔的入口，並將長期自訂內容放在合適的層級，避免把介面行為誤認為核心不支援。

遷移前先檢查，再進行替換

若要獨立執行 mihomo，可使用下方指令檢查指定目錄中的設定。目錄內須有準備使用的 config.yaml 及相關本機相依檔案，指令路徑則依實際安裝位置調整。檢查無法取代實際連線測試，但能提前發現不少格式、引用與欄位問題。若圖形用戶端提供設定檢查功能，應優先使用該入口，因為執行目錄、合併流程與權限可能由用戶端管理；在其他目錄執行指令，不一定能重現實際環境。

mihomo -t -d ./profile

下載用戶端可先從 Clash Plus 開始比較，各平台下載入口請見下載中心。Windows 也可比較 Clash Verge Rev、FlClash、Clash Nyanpasu；macOS 可比較 Clash Verge Rev 與 FlClash；Linux 可比較 Clash Verge Rev 與 FlClash。Clash for Windows 和 ClashX Meta 已停止維護，可用於辨認舊有環境，不宜只因介面熟悉而忽略維護狀態。最終仍應依所選用戶端的實際核心、平台支援及現有設定決定，推薦順序不代表協定支援能力。

訂閱相容性：格式、欄位與覆寫方式

訂閱網址不代表統一的檔案格式

訂閱本質上是透過網址取得資料，回傳內容可能是完整 YAML、代理提供者內容，也可能是分享連結集合及其編碼文字。網址都以 HTTPS 開頭，只代表取得方式相同，不表示用戶端能以相同格式讀取。有些服務會依要求參數或用戶端識別資訊回傳不同內容；同一個網址複製到不同應用程式，結果可能不一樣。匯入失敗時應先確認回傳格式，不要立刻認定節點協定不相容，更不要反覆更換驗證資訊。

完整設定通常包含代理、代理群組與規則，也可能包括 DNS、監聽連接埠及控制介面等設定。代理提供者通常只提供節點集合，需要由主要設定引用；分享連結則主要描述單一連線，通常不包含規則和完整的 DNS 策略。將節點清單當成完整設定匯入，可能缺少分流架構；將完整設定放進只接受節點集合的入口，也可能解析失敗。請先分辨用戶端的訂閱匯入、設定匯入與提供者管理入口，再選擇相應格式。

轉換可以重整欄位，不能憑空增加功能

訂閱轉換工具可以解析分享連結、產生 YAML 或套用規則範本，但無法讓舊核心理解原本不支援的協定，也無法從缺少的資訊中可靠還原憑證、flow 或 QUIC 參數。轉換器不認得某些擴充欄位時，可能會顯示錯誤，也可能直接將欄位丟棄；後者更難察覺，因為節點看起來已成功匯入。遇到新協定時，優先使用服務提供方直接提供的目標核心格式，並比較轉換前後的參數，不要把節點數量正常顯示當成轉換完整的證明。

訂閱網址通常包含存取憑證，完整設定也可能含有節點密碼與 UUID。排查時只在本機查看必要欄位，分享記錄或截圖前先遮蔽敏感資訊，不要將完整訂閱提交給不明第三方服務。需要轉換時，先了解轉換過程是否會將原始網址與內容傳送至遠端。用戶端能讀取的設定本身也有功能範圍限制：規則提供者、外部資源與控制介面都可能改變網路行為，只匯入來源明確且用途清楚的內容。

本機覆寫與遠端更新應分層管理

訂閱更新後本機修改消失，通常不是儲存失敗，而是遠端內容覆蓋了同一層的檔案。適合長期保留的規則、DNS 設定或連接埠自訂，應透過用戶端支援的合併或覆寫機制管理。合併順序尤其重要：同名代理群組可能會取代原有成員，若將規則加在 MATCH 後方，可能永遠不會比對到。先確認欄位是整個取代、附加清單還是依名稱合併，再決定修改位置。名稱中的空格與大小寫也要一致，避免引用到不存在的項目。

以下片段用來說明規則結構，適用於已定義 Proxy 代理群組的設定。區域網路目標先直連，指定網域交由代理群組處理，其餘連線則由最後一行兜底。這不是完整的節點訂閱，不應單獨當成可連線設定匯入。no-resolve 只限制這條 IP 規則的解析行為，不會全域關閉 DNS。實際分流還應配合既有規則順序，不要直接整份覆蓋服務提供方的規則清單。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Proxy
  - MATCH,Proxy

維護時保留一份可用的設定備份，更新後先檢查解析結果，再測試代表性節點與常用規則。若只有少數新協定節點失敗，優先檢查欄位與核心；若所有節點都失敗，先查看訂閱取得結果、系統時間與本機入口；若連線正常但分流改變，則檢查規則和覆寫順序。詳細比對方式請參閱GEOIP 與 DOMAIN-SUFFIX 分流實務。將故障歸到正確層級，才能避免用更換協定來處理規則問題。

情境選擇：協定候選與驗證流程

日常瀏覽與桌面辦公

日常瀏覽應優先考慮連線穩定、訂閱維護清楚及規則可控，而非追求名稱較新的協定。若已有可靠的 SS、VMess 或 Trojan 節點，可先以此建立日常使用基準；需要 VLESS、Hysteria2 或 TUIC 時，再確認核心與伺服器的搭配。辦公網路若有明確代理規範，應遵守該網路的使用規則，並避免同時執行多個會搶用系統代理、路由或 DNS 的用戶端。挑選用戶端時可先看 Clash Plus，再依平台比較其他選項。

若瀏覽器正常、桌面應用程式卻無法連線，不要立刻更換協定。先檢查應用程式是否遵循系統代理、是否有獨立代理設定，以及用戶端記錄中是否看得到它的連線。確實需要涵蓋更多流量時，再評估 TUN。區域網路列印、檔案分享與開發服務需要保留合適的直連路徑，否則即使代理可用，也可能影響辦公效率。原理請參閱TUN 虛擬網卡接管說明；實際啟用步驟則請見教學頁面。

行動網路、即時通訊與持續下載

行動裝置應先測試網路切換、鎖定螢幕後恢復與待機活動。Android 可從 Clash Plus 開始，再比較 Clash Meta for Android、FlClash 或 Surfboard 實際支援的格式與功能；iOS 可查看 Clash Plus 的 App Store 下載入口，以及官方網站 clashplus.io。不要假設這些用戶端使用相同核心或完全相容的訂閱格式，尤其不能因為都能匯入同一個網址，就認定協定擴充與規則行為一致。

語音、遊戲等工作應留意抖動、封包遺失與 UDP 可用性，單次 HTTP 延遲不足以判斷。先確認應用程式使用正確的出口，再於實際連線期間觀察中斷、恢復與延遲變化。Hysteria2 或 TUIC 可列入候選；若網路限制 UDP，則應改用符合條件的其他方案。大型檔案下載則要留意持續吞吐量、裝置溫度，以及其他工作是否受到排隊影響；達到網路連線頻寬後，繼續提高預期頻寬通常沒有幫助，反而可能降低並行互動的流暢度。

路由器、伺服器與資源受限裝置

路由器和伺服器更重視長時間穩定運作、設定可重複部署與故障復原。獨立 mihomo 核心適合需要自行管理程序與設定的使用者；一般桌面使用者通常先用圖形用戶端較容易維護。處理器架構、可用記憶體、系統權限與 TUN 支援都要逐項確認；不能直接把桌面端的吞吐量測試結果套用到低功耗裝置。規則集大小、連線數量與記錄寫入也會影響資源使用，應先以簡單設定建立基準，再逐步增加功能。

裝置層級的代理會影響多個終端，變更前應先準備復原方案。保留原始設定與已驗證的節點，先用少量流量測試，再逐步擴大接管範圍。若 DNS 同時由路由器、用戶端及其他服務處理，應明確劃分各自職責，避免循環查詢。若伺服器出口受防火牆限制，應分別檢查 TCP 與 UDP，不要試圖透過降低憑證驗證要求解決。協定連線失敗與路由、權限問題屬於不同狀況，處理方式也不同。

最後可依固定順序決定：先排除核心或伺服器不支援的組合，再排除目前網路無法使用的傳輸方式，接著以實際工作比較延遲、吞吐量、溫度與恢復情況，最後保留一個使用不同傳輸路徑的備援節點。不要同時更改協定、DNS、TUN 與分流規則。每次調整後確認常用網站、區域網路與即時應用程式是否正常；若出現問題，還原上一份已驗證的設定。協定選擇不是一次性的排名，而是在明確條件下建立可說明、可維護的連線方案。