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

先選規則模式，再確認流量是否進入核心

日常使用建議先選規則模式（Rule），確認訂閱已啟用、目標策略組已選好節點，再前往要測試的網站。如果只有特定網站異常，可以暫時切換至全域模式比較；若要確認目前網路能否直接連上目標，再切換至直連模式。每次只調整一項設定，結果才容易判讀。

三種模式決定的是已進入 Clash 或 Clash Meta（mihomo）核心的連線要如何對外連線，而不是決定哪些應用程式一定會被接管。系統代理、應用程式內的代理設定和 TUN，負責將流量送進核心；規則、全域和直連，則負責處理送進來的流量。這兩層設定要分開檢查。

三種流量路徑：入口相同，出站決策不同

以下圖示以同一個已被接管的應用程式連線為例。圖中的「代理選擇」是範例策略組名稱，並非每份訂閱都會使用的固定名稱；實際設定可能稱為「節點選擇」、「自動選擇」或其他名稱。

規則模式：由上往下比對，第一個符合的規則生效

應用程式連線
  ↓ 系統代理 / 應用程式代理 / TUN
Clash 或 mihomo 核心
  ↓ 由上往下檢查 rules
  ├─ 符合直連規則 → DIRECT → 目標服務
  ├─ 符合代理規則 → 代理選擇 → 目前節點 → 目標服務
  ├─ 符合拒絕規則 → REJECT → 中止連線
  └─ 套用 MATCH 預設規則 → 指定策略 → 目標服務

規則不是「越具體就會自動優先」，通常會由上往下檢查，先符合的規則先執行。如果把涵蓋範圍很大的規則放在前面，後面更精確的網域規則可能就沒有機會生效。訂閱中的規則集，也要依照它在 rules 清單中的引用位置判斷。

全域模式：略過一般規則分流

應用程式連線
  ↓ 已被接管
Clash 或 mihomo 核心
  ↓ Global 模式
GLOBAL 策略組
  ↓ 目前選取的節點或其他可用出站
目標服務

切換至全域後，還要前往代理頁面檢查 GLOBAL。全域模式不等於「自動選最快的節點」，也不保證出口一定是代理節點。如果 GLOBAL 目前選的是 DIRECT，或選取的下一層策略組最後指向直連，連線仍會直接連出。部分用戶端會以本地化名稱顯示此策略組。

直連模式：仍可經過核心，但不會經過代理節點

應用程式連線
  ↓ 已被接管
Clash 或 mihomo 核心
  ↓ Direct 模式
DIRECT
  ↓ 目前裝置可用的網路出口
目標服務

直連模式不代表退出用戶端，也不等於關閉 TUN。核心仍可能處理連線和 DNS 請求，只是改由直連方式連出。因此，直連成功只能表示在目前的接管與解析環境下，這條連線可以直接連上目標；不能只憑這點就認定系統代理、DNS 和路由都已恢復成未啟動用戶端時的狀態。

規則如何搭配策略組：用最精簡的範例說明

以下是用來說明比對順序的 YAML 片段，不能取代完整訂閱。其中的「代理選擇」必須先在 proxy-groups 中定義。example.com 及其子網域僅用於示範寫法，不代表任何特定服務一定要使用代理。

mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,代理選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,代理選擇

• mode: rule：表示預設依規則處理。用戶端介面中的即時切換可能會覆蓋此值；重新載入設定後的行為，則取決於用戶端是否保留模式覆寫。
• mixed-port: 7890：在同一個入口連接埠接收 HTTP 與 SOCKS5 代理連線。7890 僅為範例，並非所有用戶端都使用此連接埠。
• DOMAIN-SUFFIX：比對指定網域及其子網域；符合後交由「代理選擇」處理，再由該策略組決定實際使用的節點。
• IP-CIDR：依目標 IP 網段比對。此處僅示範兩個常見的內網網段，並非完整的區域網路直連規則。
• no-resolve：避免只為了比對這條 IP 規則而主動解析網域；不代表整個連線不需要 DNS。
• MATCH：作為最後的預設規則。若放在前面，後續規則就無法再比對。

切換至全域或直連後，通常不會再依照這份一般的 rules 清單逐條決定出站。因此，「規則中設定了內網直連」不代表「全域模式也會依照同一條規則直連」。若要連線至本地印表機、路由器管理頁面和企業內網服務，日常使用規則模式會更容易明確控管。

何時暫時切換至全域，何時切回規則

只有特定網站無法連線：用全域模式交叉測試

1. 在用戶端的「代理模式」區確認目前選的是「規則」；部分用戶端會將入口放在系統匣選單的「代理模式」中，實際名稱請以介面顯示為準。
2. 開啟「連線」頁面，前往目標網站一次，記下目標網域、命中的規則及最後採用的策略鏈。
3. 切換至「全域」，並在 GLOBAL 中選擇已確認可用的節點。盡量沿用規則模式原本使用的節點，避免同時變更兩項條件。
4. 關閉目標網站的舊連線後再重新連線。必要時只中斷該網域的連線，不必立刻中斷所有應用程式。
5. 若全域模式正常、規則模式異常，請切回規則，優先檢查網域是否誤判為 DIRECT、規則集是否遺漏，以及預設規則是否指向不同的策略組。

這項比較無法直接下定論。即使使用同一個節點，兩種模式仍可能受到設定中依模式採用不同 DNS 行為等因素影響。若切換前後的解析結果不同，應一併排查 DNS，而不是直接將所有問題歸咎於規則。

測試統一出口：可短暫使用全域模式

若要查看某個代理節點的出口位置，或測試某項服務能否透過該節點連線，使用全域模式較容易排除規則分流的干擾。不過，在此期間，其他已被接管的應用程式也可能使用相同出口，包括系統更新和雲端硬碟同步。訂閱若按流量計費，尤其要留意背景下載。

日常瀏覽與本地服務：切回規則模式

測試結束後切回規則模式，並重新確認常用策略組。需要代理的網域走代理，本地可直接連線的服務使用 DIRECT，才能減少不必要的繞路。全域不是比規則「更進階」的模式，只是略過一般規則選擇，較適合短時間交叉測試。

系統代理、TUN 與 DNS：切換模式無法解決的問題

應用程式沒有進入核心，全域模式也無法接管

桌面用戶端啟用「系統代理」後，部分應用程式會讀取系統設定，另一些仍使用自己的網路設定。命令列程式也可能依賴環境變數。確認本機混合連接埠為 7890 後，可用以下命令明確指定代理入口，降低系統代理設定造成的不確定性：

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

在 Windows PowerShell 中，若要明確呼叫系統提供的 curl 程式，可將開頭改為 curl.exe。執行時也請查看用戶端的連線記錄：若出現這次請求，代表它確實進入該代理入口；只有 HTTP 回應，並不能證明使用了遠端節點，還要檢查最後採用的策略鏈。命令中的 10 秒是連線逾時，20 秒是總耗時上限，不是延遲測試結果。

TUN 會透過虛擬網路介面和路由接管更多 IP 流量，但實際範圍仍會受到路由、排除項目、權限及具體實作方式影響。啟用 TUN 不會讓節點自動支援 UDP，也無法修復節點本身無法連線的問題。若要接管不遵循系統代理的應用程式，請再依照用戶端教學檢查 TUN 權限和路由設定。

切換模式不代表清除 DNS 狀態

使用 Fake-IP 時，核心可能會回傳用於網域對應的虛擬位址給應用程式，再透過對應關係識別實際網域。這不代表連線真的被送往某個公網目標。DNS 上游、Fake-IP 排除項目、應用程式自己的加密 DNS，以及本機快取，都可能影響排查結果。

切換至全域後仍無法連線時，不要立刻同時修改 DNS、TUN 和訂閱。先確認連線記錄中有沒有出現，再檢查網域和策略鏈，最後查看解析結果及節點連線錯誤。同時修改多個層級，容易讓原本可重現的問題變成偶發狀況。

切換後沒有變化：逐項核對連線記錄

切換模式通常只會影響之後建立的新連線，不保證既有 TCP 長連線或 QUIC 工作階段會立即改道。重新整理網頁也可能沿用既有連線；若記錄仍顯示舊策略，請先關閉相關連線，再重新發出請求。進行中的下載、會議或遠端工作階段可能因此中斷，操作前請先確認影響範圍。

最後確認三件事：連線有進入核心嗎？最後走的是哪個出站？新連線是否使用預期模式？確認這三點後，再決定要修正规則、調整接管方式，還是更換節點。日常維持規則模式，排查時短暫切換至全域或直連，通常比反覆重裝用戶端更容易找出原因。