Clash 規則模式、全域模式與直連模式怎麼選？三種代理模式比較

三種模式的差異：決定連線出口，不決定流量接管範圍

日常需要同時存取本地服務與需經代理的網站，通常先使用規則模式；暫時略過分流規則、測試節點時，使用全域模式；想比較本地網路的直連狀況時，則使用直連模式。這三個選項決定的是「連線交給 Clash 後如何處理」，而不是「哪些應用程式的流量會進入 Clash」。

Clash 系列用戶端的介面可能顯示 Rule、Global、Direct，也可能顯示相應的中文名稱。Clash Meta 後續改用 mihomo 名稱，常見用戶端在這一層仍沿用這三種模式。規則功能會隨核心版本而異，但「接管流量」與「選擇出口」應分開理解。

規則模式：依序比對，再交由策略組處理

規則模式會依照設定中的規則，由上而下判斷連線。一般規則符合後，就會依指定目標處理；目標可以是 DIRECT、REJECT，也可以是實際存在的策略組。接著由策略組決定使用哪個節點或下層策略。因此，追查連線時要確認兩個層次：符合哪一條規則，以及該規則指向的策略組最後選了什麼。

規則順序比規則數量更重要

以下是規則片段範例，並非可直接匯入的完整訂閱。「節點選擇」必須替換為目前設定中已定義的策略組名稱；若保留範例名稱卻沒有相應策略組，可能會導致設定載入失敗。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,節點選擇

• DOMAIN-SUFFIX,example.com 會比對該網域及其子網域，不能因此推斷任何包含這段字元的網域都會符合。
• 192.168.0.0/16 與 10.0.0.0/8 是常見的私有 IP 位址範圍；範例並未列出所有本地位址範圍。
• no-resolve 表示不只為這條 IP 規則主動解析網域；目標已是 IP 時，仍可參與比對。
• MATCH 是預設兜底規則。若將它放在前面，後續規則就沒有比對機會。

適合日常使用，但需要維護分流依據

例如，區域網路儲存裝置應設為直連，特定外部網站交由代理策略組處理，其餘流量再交給兜底組。規則模式可以同時滿足這些需求。不過，網站的登入、圖片與影片可能使用不同網域：主頁符合規則，不代表所有子請求都會走相同路徑。

遇到「網頁打得開，圖片卻沒有顯示」時，先查看失敗請求的網域與符合的規則。不要直接把所有流量改走代理後就長期維持，也不要只根據瀏覽器網址列中的主網域新增規則。還需要一併確認規則來源、訂閱更新狀態與核心支援範圍。

全域模式：適合測試節點，不等於整台裝置都走代理

全域模式會將已接管的一般連線交由 GLOBAL 策略處理。切換後，請再開啟用戶端的代理或策略組頁面，確認 GLOBAL 目前選擇的目標。有些介面會隱藏該組，或另外顯示全域選擇器；請以連線詳細資料中的出口為準。

全域模式不保證流量一定經過遠端節點。如果 GLOBAL 選擇 DIRECT，連線仍會直連；如果 GLOBAL 指向另一個策略組，還需確認該組最後選擇的目標。規則模式常用的「節點選擇」策略組，也不一定會與 GLOBAL 同步。

用全域模式區分節點問題與規則問題

1. 記下規則模式下失敗請求的網域、符合的規則與出口節點。
2. 切換至全域模式，並將 GLOBAL 設為相同的待測節點。
3. 關閉相關舊連線，再重新發出請求；不要只觀察仍在重複使用的頁面連線。
4. 若全域模式可用、規則模式不可用，優先檢查分流規則、目標策略組與 DNS 差異；若兩種模式都失敗，再檢查節點與本機流量接管路徑。

這項比較只能協助縮小問題範圍，不能直接當作定論。遠端服務的流量限制、DNS 快取、連線重用與測試時間差都可能影響結果。請盡量維持相同網路、目標與節點，只變更模式。

直連模式：適合比較網路狀況，不等於關閉用戶端

直連模式下，進入核心的連線通常會直接連至目標，不再依一般規則選擇代理節點。它適合用來釐清一個問題：「這次連線失敗是否與代理節點有關？」例如，同一項資源在直連時可用、使用指定代理節點時失敗，就可以接著檢查該節點的連線狀況，或目標網站對出口的限制。

不過，切換為直連後，系統代理仍可能指向本機監聽連接埠，TUN 虛擬網卡也可能繼續運作。用戶端的 DNS 監聽、快取與相關解析路徑也不一定會停用。因此，直連模式只能作為不使用代理節點的比較基準，不能完全代表退出用戶端後的原始網路狀況。

• 只想暫時不使用節點：切換至直連模式，再確認連線詳細資料中的出口為 DIRECT。
• 要測試完全不經過用戶端：先關閉系統代理與 TUN，再視需要退出用戶端，並確認系統沒有殘留手動代理設定。
• 退出後所有網頁都無法開啟：檢查系統是否仍指向 127.0.0.1 代理連接埠，但該連接埠的監聽服務已停止。

直連也不代表所有目標都能存取。目標服務是否可連線，仍會受到本地網路、路由、DNS 與伺服器端策略影響。某個網站直連失敗，不能單獨證明用戶端設定有誤。

系統代理與 TUN：決定哪些連線會進入核心

系統代理通常透過作業系統的代理設定，讓遵循該設定的應用程式將請求送至本機 HTTP 或 SOCKS 入口。瀏覽器通常支援系統代理，但命令列工具、遊戲及部分獨立應用程式可能使用自己的網路設定。TUN 則透過虛擬網卡與路由接管符合條件的流量；實際範圍仍取決於路由、排除項目、權限與核心設定。

先確認監聽連接埠，再測試流量接管路徑

以下指令假設用戶端的 HTTP 或混合監聽連接埠為 7890。這只是示範值，並非所有用戶端的預設值；執行前請先在用戶端的連接埠設定中確認。Windows 可使用 curl.exe，macOS 與 Linux 通常使用 curl。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com

第一條指令會明確經過本機代理入口，第二條則讓 curl 不使用應用程式層代理。若 TUN 仍啟用，第二條流量仍可能由虛擬網卡接管，因此不能視為完全繞過用戶端的測試。請搭配連線面板確認兩次請求是否進入核心，以及最後使用的出口。

指令收到 HTTP 回應，只能表示這次請求有收到回應，不能證明影片、遊戲 UDP 或整個系統都已正常使用代理。HTTP 代理測試與 UDP 接管是兩回事；後者還取決於入口方式、節點協定與伺服器端支援。

切換模式後連線異常：依序檢查五個項目

1. 確認目前設定與最終出口

先確認目前啟用的是哪份訂閱或本機設定，再查看模式與策略組。訂閱更新可能會變更規則與策略組名稱；介面上先前選擇的節點，也不一定仍是目前連線使用的節點。規則模式查看符合的規則，全域模式查看 GLOBAL，直連模式則查看 DIRECT。

2. 關閉舊連線後再測試

切換模式通常只會影響新建立的連線；既有 TCP 連線與部分 UDP 工作階段可能仍沿用原本路徑。瀏覽器的 HTTP/2、HTTP/3 連線重用會讓這種情況更明顯。可在用戶端的連線面板中結束目標連線，再重新開啟頁面；結束所有連線會中斷下載、會議等工作，請先儲存進度。

3. 分開檢查 DNS 與流量出口

解析失敗時，切換至全域模式不一定能解決問題。查看記錄中是否有 DNS 逾時、目標解析錯誤或 fake-ip 相關異常。對 mihomo 而言，DNS 上游、解析策略與是否遵循規則，取決於實際設定；不能簡單認為「全域模式下所有 DNS 都會經過節點」。修改前先備份，也不要同時更換 DNS、節點與模式。

4. 檢查系統代理、TUN 與其他網路工具

若明確指定代理的測試正常，但瀏覽器沒有相應的連線記錄，請優先確認瀏覽器是否使用獨立代理設定。若啟用 TUN 後發生故障，則檢查執行權限、路由排除設定與其他 VPN 是否衝突。每次只保留一種待測的流量接管方式，避免系統代理與多張虛擬網卡互相影響判斷。

5. 依相同條件記錄，不要只看延遲

節點延遲測試通常只會探測特定位址一次，不能代表目標網站的傳輸速度。可在相同網路下記錄三次請求的模式、節點、目標網域、結果與錯誤訊息。例如記下「規則模式符合 DIRECT，連線逾時；全域模式選擇節點 A，回應 HTTP 200」，比只寫「節點顯示 80 ms」更有助於排查。這裡的數值只是記錄格式範例，並非本站實測結果。

日常使用建議：以規則模式為主，全域與直連用來比較

• 同時使用辦公、瀏覽與區域網路裝置：優先使用規則模式，並確認私有 IP 位址與常用服務實際符合的規則。
• 懷疑分流設定有誤：暫時切換至全域模式，明確選擇待測節點，關閉舊連線後比較同一個目標。
• 懷疑節點或遠端線路異常：使用直連模式進行比較；若要建立原始網路基準，再關閉系統代理與 TUN。
• 只有某個應用程式異常：先確認它是否進入核心，不要一直切換三種模式來取代流量接管方式的檢查。

可靠的排查順序是：流量是否進入核心、目前模式如何處理流量，以及最終出口是否符合預期。確認這三件事後，再調整規則或節點。若要確認安裝與匯入步驟，請參閱Clash 使用教學；若要了解規則欄位，請繼續查閱協定手冊。