三種運行模式的流量走向差異
Clash 及其衍生核心 Clash Meta（mihomo）在用戶端設定裡通常提供三種運行模式：規則模式（Rule）、全局模式（Global）與直連模式（Direct）。這三種模式決定的不是節點本身，而是「一條網路請求發出後，先經過什麼判斷，再走向哪裡」。理解這一層判斷邏輯，比記住每個模式的名稱更重要。
- 規則模式：每一條請求先與設定檔中的
rules清單逐條比對，根據網域、IP 段、GEOIP 歸屬地等條件，把流量分配給對應的代理群組或直連；未命中任何規則的請求，最終交給規則清單末尾的預設策略（通常是MATCH或FINAL）處理。 - 全局模式：跳過規則比對，所有流量（不論網域或 IP）統一發往目前選中的代理群組或節點，出站行為高度一致但缺乏區分度。
- 直連模式：跳過代理，所有流量都走本機網路直接出站，等同於暫時關閉代理功能。
三者的關鍵差異在於「判斷環節是否存在」以及「存在時判斷的粒度」。規則模式保留了精細判斷，全局模式和直連模式都放棄了判斷，只是放棄後流量的終點不同——一個終點是代理節點，一個終點是本機網路。
| 模式 | 是否比對規則 | 流量終點 | 典型耗時特徵 |
|---|---|---|---|
| 規則模式 | 是 | 依規則分配到直連或不同代理節點 | 命中直連規則的請求延遲低，命中代理規則的請求延遲取決於節點 |
| 全局模式 | 否 | 統一發往目前選中節點 | 所有請求延遲一致，取決於該節點線路品質 |
| 直連模式 | 否 | 本機網路直接出站 | 不經過代理，延遲等同於未使用 Clash 時的原始網路 |
說明：直連模式不等於「規則模式裡全部走直連」。直連模式是在用戶端層面整體關閉代理判斷邏輯，即便設定檔裡寫了大量代理規則，也不會生效；而規則模式下即使某條規則明確寫了直連，其餘規則仍會正常把流量導向代理節點。
規則模式的典型適用情境
規則模式是絕大多數日常使用情境下的建議設定，原因在於它能同時滿足「本地服務保持低延遲直連」和「境外或特定服務走代理」兩種需求，不需要使用者手動切換。常見的規則維度包括：
- 網域後綴與關鍵字比對：例如把常見的台灣本地影音、支付、政府類網域歸入直連策略，避免不必要的繞行。
- GEOIP 地理位置比對：把解析結果落在特定國家或地區的 IP 歸入對應策略，常用於區分本地 CDN 與境外伺服器。
- 區域網路與私有位址段直連：確保存取路由器管理頁面、區域網路內的印表機或 NAS 裝置時不經過代理，這類規則通常寫在規則清單靠前的位置。
- 行程與埠號維度的規則（部分 Clash Meta 核心支援）：按發起請求的應用程式名稱比對，實現「只讓某個應用走代理，其餘應用直連」的精細控制。
一份典型的規則片段大致如下：
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- DOMAIN-KEYWORD,examplecdn,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT
- MATCH,Proxy這類設定的核心思路是：先把明確應該直連的流量攔截下來，再把不確定的流量統一交給最後一條 MATCH 規則處理。規則模式適合長期掛載使用、需要兼顧存取速度與穩定性的情境，例如日常辦公、瀏覽網頁、使用即時通訊工具等。規則檔案通常由訂閱提供方維護，使用者也可以在用戶端的「設定」頁面裡查看目前生效的規則集，或使用「覆寫」功能追加自訂規則而不必修改原始訂閱內容。
全局模式的典型適用情境與風險
全局模式的價值在於「可預測性」：所有流量走同一條線路，不存在因規則誤判導致某個網站存取異常的問題。這在以下幾種情境下比規則模式更合適：
- 排查規則是否生效異常：當懷疑某個網站存取緩慢或連線失敗是規則比對錯誤導致時，切到全局模式並強制所有流量走代理節點，如果問題依然存在，說明故障點在節點本身或網路環境，而不是規則設定。
- 需要統一本地與境外存取口徑：部分企業內網測試、跨境資料比對等情境，要求所有請求都從同一出口位址發出，全局模式能確保這一點，而規則模式下本地流量直連會導致出口位址不一致。
- 暫時驗證某個節點的整體表現：想集中測試某個新增節點在各類網站上的連通性和速度，全局模式可以避免規則分流帶來的干擾變數。
注意：全局模式下，本地網站的存取也會經過代理節點，這通常意味著額外的延遲增加，以及部分依賴本機真實 IP 歸屬地的服務（如地圖定位、部分支付驗證）可能出現異常。長期使用全局模式並非節省流量或提升速度的做法，建議只在排查問題或有明確出口一致性需求時短暫啟用。
另外需要留意，全局模式下選擇的「目前節點」是單一節點或單一代理群組，如果該節點本身不穩定，所有流量會同時受到影響，風險相比規則模式下的分散分流更集中。
切換模式後需要注意的快取與連線狀態問題
模式切換看似只是用戶端介面上的一個開關，但底層涉及連線表、DNS 快取與核心狀態的重建，處理不當會出現「切換後網頁打不開」「顯示已連線但實際不通」等現象。以下是幾個需要留意的細節：
- 已建立的長連線不會自動重新分流：模式切換前已經打開的 TCP 連線（例如正在播放的影音串流、正在下載的檔案）通常會沿用原來的出站路徑，直到該連線自然結束。如果需要立即生效，建議手動中斷對應應用程式的連線或重新啟動應用程式。
- DNS 快取可能導致網域仍解析到舊結果：規則模式下大量分流依賴 GEOIP 判斷，而 GEOIP 判斷的前提是先完成網域解析。如果用戶端或系統層面的 DNS 快取裡保留了模式切換前的解析結果，短時間內規則比對可能仍按舊的 IP 歸屬地判斷。此時可以在用戶端裡手動清除 DNS 快取，或等待快取自然過期。
- 代理群組的健康檢測狀態不會因模式切換而重置：如果某個代理群組在規則模式下因為延遲測試失敗被標記為不可用，切到全局模式後如果仍選中該代理群組，同樣會連線失敗，這與模式本身無關，需要先確認節點連通性。
- 瀏覽器與部分應用程式有自己的連線池：瀏覽器為了效能會重複使用已建立的 HTTP/2 或 HTTPS 連線，模式切換後瀏覽器不一定會立即感知變化，遇到頁面載入異常時，先嘗試強制重新整理或重新啟動瀏覽器程序，而不是直接判斷代理設定出了問題。
建議：切換模式後，優先用一個新開的瀏覽器分頁存取一個明確的測試位址，觀察連線狀態卡片裡的目前協定與節點資訊是否已經更新為預期值，確認無誤後再繼續其他操作，避免被殘留連線的舊狀態誤導判斷。
如何在用戶端中快速切換與驗證
不同用戶端（如 Clash Verge、Mihomo Party、FlClash）在介面呈現上略有差異，但操作路徑基本一致：
- 打開用戶端主介面，找到「模式」或「運行模式」相關的分段控件，通常直接以「規則 / 全局 / 直連」三個選項呈現。
- 點擊對應模式完成切換，多數用戶端會在狀態列或連線狀態卡片裡同步顯示目前生效的模式名稱，例如連線狀態卡片頂部的協定資訊中標註
rule或global。 - 切換後打開日誌面板，觀察最近幾條請求命中的具體規則或策略，確認流量走向與預期一致。這一步對排查規則設定是否生效尤其有用。
- 如果只是暫時驗證節點連通性，驗證結束後記得切回規則模式，避免長期處於全局模式帶來的延遲增加和出口異常風險。
對於日常使用者，規則模式配合一份維護良好的訂閱規則集，基本可以覆蓋絕大部分情境，無需頻繁手動切換模式；全局模式更多是排查工具和特殊情境下的暫時選擇；直連模式則適合完全不需要代理時，作為快速關閉代理功能的開關使用。