規則模式、全域模式、直連模式怎麼選？Clash 分流原理入門

三種模式：決定流量進入核心後的出口

日常使用建議選擇規則模式；排查特定網站的分流問題時，可短暫切換全域模式；想確認本地網路能否直接連線時，再使用直連模式。這三者不是速度等級，而是 Clash 或 Clash Meta（mihomo）對已接管連線採取的不同路由方式。

先釐清兩個環節：系統代理和 TUN 負責讓流量進入核心；規則、全域、直連則決定流量進入後如何送出。只切換全域模式，並不會讓原本不使用系統代理的遊戲自動經過代理。啟用 TUN，也不代表所有連線都會使用遠端節點。

規則模式：第一條符合就採用，不是最精確的規則優先

在規則模式下，核心會依目前連線可取得的資訊進行比對，例如目標網域、目標 IP、連接埠，以及依平台支援情況而定的程序資訊。找到符合條件的規則後，就會採用該規則指定的策略，不會繼續往下比較哪條「更精確」。

先看一組有順序的規則

以下是用來說明規則順序的設定片段，並非完整訂閱內容。網頁出口策略組必須已存在於設定中；example.com是示範網域，實際使用時請換成需要分流的網域。

mode: rule

rules:
  - DOMAIN,account.example.com,DIRECT
  - 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,網頁出口

• account.example.com 符合第 1 條，使用直連。
• docs.example.com 不符合第 1 條，但符合第 2 條，因此交由「網頁出口」處理。
• 目標位址為 192.168.1.20 的連線符合第 3 條，通常用來存取區域網路裝置。
• 先前的規則都不符合時，連線會套用最後一條 MATCH，交由「網頁出口」處理。

如果把第 2 條移到第 1 條之前，帳號網域也會先被後綴規則涵蓋，導致第 1 條無法處理該網域。因此，帳號、辦公系統等範圍較小的例外規則，通常應排在適用範圍較廣的網域規則之前；兜底用的 MATCH 則放在最後。

規則的目標可以是策略組，不一定是節點

DIRECT 是直接連線策略，REJECT 是拒絕連線策略；「網頁出口」這類名稱通常代表策略組。策略組可能再指向另一個策略組，最後才會連到特定節點或直連。看到記錄顯示符合某個策略組時，還要確認組內目前選取的項目，不能直接認定流量已使用遠端節點。

no-resolve 表示不會為了比對這條 IP 規則而主動觸發網域解析。若連線已有可用的目標 IP，仍可進行 IP 比對；若只有網域名稱，且沒有可用 IP，這條規則就無法透過主動解析取得比對條件。這不代表「停用整份設定的 DNS」。

全域與直連：適合用來比對，不等於接管開關

全域模式要確認 GLOBAL 實際選取的項目

切換至全域模式後，請開啟客戶端的代理或策略組頁面，確認 GLOBAL 目前選取的項目。如果選的是 DIRECT，流量仍會直接連線；如果選的是其他策略組，還要確認該組最後使用的節點。全域模式不會自動修復失效節點，也不會補上節點不支援的 UDP 轉送能力。

一種實用的比對方式是：保持節點不變，將規則模式切換為全域模式，再重新建立故障網站的連線。若全域模式可用、規則模式不可用，應優先檢查符合的規則及策略組選取項目；若兩種模式都不可用，再檢查節點、DNS、流量接管路徑和目標服務。這只能縮小排查範圍，不能只憑一次連線就判定故障原因。

直連模式仍可能保留本地代理入口

在直連模式下，瀏覽器仍可將請求送到本地代理連接埠，再由核心直接連線至目標。這和「關閉系統代理」、「關閉 TUN」或「結束客戶端」並不是同一回事：本地監聽、DNS 設定及流量接管機制可能仍在運作。

若要完全停止代理接管，請先在客戶端關閉系統代理或 TUN，再結束程式。否則系統可能仍指向已停止監聽的本地連接埠，造成客戶端一關閉，瀏覽器也無法連網。排查時應先確認要測試的是「核心直連」，還是「不經過核心的系統網路」。

系統代理與 TUN：先確認流量是否進入核心

系統代理主要供遵循作業系統代理設定的應用程式使用。瀏覽器通常會遵循這類設定，但遊戲、使用自有網路堆疊的程式，以及部分命令列工具未必會使用。TUN 透過虛擬網路介面接管符合路由條件的 IP 流量，涵蓋的應用程式較多，但仍會受路由排除項目、其他 VPN、權限和 DNS 設定影響。

1. 先檢查接管方式：在客戶端確認系統代理或 TUN 是否已啟用。不同客戶端的選單名稱可能不同，別把「已選取規則模式」當成「已啟用系統代理」。
2. 接著建立新連線：開啟測試網站或重新連線至遊戲伺服器，同時查看客戶端的「連線」頁面。若能找到對應目標，便是流量已進入核心的重要證據。
3. 最後檢查對外連線路徑：確認符合的規則、策略組，以及最終出口。節點清單上的延遲數字只代表該次測試，無法證明瀏覽器目前正使用該節點。

日常瀏覽、遊戲與辦公的模式選擇

測遊戲延遲不能只看節點測試

客戶端的延遲測試通常會連線至設定指定的測試網址，並不等於遊戲伺服器的往返時間。即使測試成功，遊戲仍可能因為不支援 UDP、伺服器區域不符，或流量根本沒有進入核心而無法連線。請檢查實際遊戲連線和遊戲內的網路數據，不要把全域模式當成遊戲加速按鈕。

辦公網路直連也要考量網域與 DNS

內網服務可能使用只有組織內部才能解析的網域。只新增一條 DOMAIN-SUFFIX 直連規則，不代表公用 DNS 就能解析該網域。此時應搭配組織提供的 DNS 和 VPN 方案處理；如果網域解析已經失敗，繼續調整節點選擇通常沒有幫助。

透過連接埠與連線記錄確認模式是否生效

以下以 127.0.0.1:7890 示範明確指定代理的測試方式。7890 是範例連接埠，不是所有客戶端的固定值。請先確認目前生效的設定或客戶端連接埠設定中的 HTTP 代理連接埠或混合連接埠，再修改指令。若客戶端只提供 SOCKS 連接埠，就不能直接套用這裡的 HTTP 代理寫法。

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

macOS、Linux 可在終端機執行上述指令；Windows PowerShell 可將指令開頭改為 curl.exe，避免某些環境中的同名別名影響參數解讀。此處的連線逾時上限為 10 秒，整體請求上限為 20 秒。這些是測試參數，不代表節點效能保證。

1. 選取規則模式並執行一次指令，查看 example.com 的連線記錄，記下符合的規則和最終對外連線路徑。
2. 切換至全域模式，確認 GLOBAL 使用預期的節點，再執行一次指令，比較對外連線路徑。
3. 切換至直連模式，再執行一次指令，確認連線是否透過 DIRECT 送出。
4. 比對完成後，請恢復規則模式，並將發現的錯誤規則修正至持久設定中，不要長期依賴全域模式繞過問題。

明確指定代理的測試只能證明「這項請求透過指定的本地連接埠進入核心」，無法證明系統代理或 TUN 已涵蓋其他應用程式。收到目標伺服器的 HTTP 回應，代表請求已抵達可回應的一端，但仍應以連線記錄確認實際出口；有些服務會拒絕 HEAD 請求，不能只憑回應狀態碼就判定節點故障。

常見誤判與復原方式

切換模式後，網頁看起來沒有變化

切換模式通常主要影響後續建立的新連線。瀏覽器可能重複使用 HTTP/2、HTTP/3 或其他長連線，既有連線不一定會立即更換出口。請先關閉相關頁面，再重新送出請求；必要時可在客戶端的連線頁面關閉對應連線。不要在同一條重複使用的連線上反覆重新整理，再據此判斷切換是否無效。

規則改過了，訂閱更新後又恢復原狀

直接編輯由訂閱下載產生的設定，可能會在下次更新時被覆蓋。建議使用客戶端提供的覆寫、合併或持久規則功能，並確認新增規則的插入位置。若規則排在 MATCH 後面，即使設定能載入，也無法接管已被兜底規則比對的連線。

全域模式可以連線，規則模式卻選到直連

先查看目標連線實際符合的規則，不要立刻刪除所有規則。常見原因包括：網域先符合適用範圍過廣的後綴規則、策略組目前選取 DIRECT，或某個規則集的涵蓋範圍與預期不同。將必要的小範圍例外規則移到對應的廣泛規則之前，再用新連線重新測試。

完成日常設定後，通常建議保留規則模式，較容易同時處理本地服務、區域網路和遠端代理需求。需要完整的匯入與流量接管步驟，請繼續閱讀入門指南；需要確認設定結構和規則設定，請參閱完整文件。