Clash 規則模式、全域模式與直連模式的差異與日常設定建議

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

日常使用建議優先選擇規則模式：需要代理的連線交由代理策略組處理，區域網路設備及適合直連的網站則維持直連。全域模式較適合短時間排查分流問題，直連模式則適合比較未經代理時的網路狀況。三種模式改變的是核心如何處理已接收的連線，並非網路加速等級。

先分清楚兩層設定：系統代理、TUN 或 Android VPN 決定流量如何進入核心；規則、全域、直連則決定流量進入後如何送出。只切換成全域模式，卻未啟用系統代理，也未讓目標程式使用代理，該程式仍可能直接連線。

三種代理模式的流量走向

規則模式：符合哪項策略，就使用哪個出口

規則通常依照設定中的順序由上往下比對，第一條符合的規則就會決定採用的策略。策略可以是 DIRECT、REJECT、某個節點，也可以是代理群組。規則模式不代表「所有海外網站都會自動走代理」；實際結果取決於訂閱提供的規則、規則集及預設策略。

例如，網域規則將某項服務交由 PROXY 處理，但該群組目前選的是 DIRECT，連線最後仍會直連。排查時必須同時查看「符合的規則」及「策略組目前選取的項目」，不能只看模式按鈕。

全域模式：仍須選擇 GLOBAL 的出口

切換至全域模式後，一般規則清單不再負責為這些連線分流，核心會使用 GLOBAL 目前選取的項目。不同用戶端可能顯示為「全域」或「GLOBAL」。如果此處選的是直連，切換全域模式也不會改走代理；如果選的是其他策略組，還要確認該組最後選取了哪個節點。

全域模式也無法修復過期訂閱、節點驗證失敗或伺服器無法連線等問題。原本用於區域網路直連的規則不會再依規則模式生效，存取印表機、NAS 或路由器管理頁面時可能因此受到影響；不過，已由 TUN 路由排除的流量本來就不會進入這個流程。

直連模式：不經代理節點，不代表核心停止運作

直連模式會讓進入核心的連線透過本機網路直接連線至目標。用戶端仍可能監聽連接埠、接收系統代理請求，以及執行 TUN 和 DNS 服務。因此，「切換為直連」和「結束用戶端並還原系統網路設定」並非相同的測試。如果懷疑 TUN 路由或 DNS 設定有問題，只切換直連並不足以排除這些因素。

YAML 中的 mode、rules 與策略組如何對應

設定欄位是頂層的 mode，常見值為 rule、global、direct。以下是規則片段，並非完整訂閱。使用前請確認現有設定中已有名為 PROXY 的節點或策略組；若實際群組名稱是「節點選擇」，請將兩處 PROXY 都替換成完全相同的群組名稱。

# 請合併至現有設定，勿使用此片段覆蓋完整訂閱。
mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

• DOMAIN-SUFFIX,example.com,PROXY：符合範例網域本身及其子網域，適合用來說明網域分流，並非針對任何實際服務的建議規則。
• IP-CIDR：此處涵蓋三段常見的私有 IPv4 網段，並非完整的本機位址例外清單。迴送位址、鏈路本地位址及 IPv6 等位址，須依網路環境另行處理。
• no-resolve：比對此 IP 規則時，不會主動進行網域解析；這不代表關閉整個用戶端的 DNS。
• MATCH,PROXY：接收前面規則都未符合的連線。若將 MATCH 放在第一條，後續規則就不會有比對機會。

切換至全域模式時，可將頂層欄位改為以下內容，但實際出口仍由執行時的 GLOBAL 選取項目決定：

mode: global

若要讓進入核心的連線直接連線，請使用：

mode: direct

Clash 與 Clash Meta（目前通常稱為 mihomo）支援的擴充欄位並不完全相同，尤其是 DNS、TUN 及程序比對相關功能。本文介紹的三種模式屬於基本概念；複製其他進階欄位前，請先在用戶端的「關於」或核心資訊中確認實際使用的核心，不要只看應用程式名稱。

日常選擇：規則模式的實際優點

規則模式的用途是讓不同連線使用合適的出口，而非保證每個網站都更快。代理節點的頻寬、線路品質、目標網站及本機網路都會影響使用體驗。妥善設定規則，可避免區域網路存取、不需代理的下載及需要特定出口的服務全擠在同一條線路上。

• 網頁與辦公服務：依網域分流；在中國大陸可直接連線的服務通常維持直連，需要代理的服務則使用指定策略組。
• NAS、印表機與路由器：依實際本機網段設定直連，並檢查 TUN 路由排除設定，避免本機連線被送往遠端出口。
• 帳號登入：讓同一服務的相關網域盡量使用一致的出口；登入期間頻繁切換節點，可能觸發額外驗證。
• 下載與大量傳輸：先在連線面板確認出口。使用全域模式時，這些工作也可能耗用代理線路的流量額度。

別為了「更徹底」而長期使用全域模式。這只會減少規則分流這個變因，不會提升節點品質，也不會擴大系統代理的接管範圍。如果規則模式下只有一個網站異常，通常應修正該網站的比對規則或策略組，而非長期改變所有連線的出口。

規則模式無法開啟、全域模式可以：依這五步驟排查

這是最適合暫時使用全域模式的情況。測試時請盡量維持相同的節點、網址及網路，只變更模式；否則無法判斷問題出在規則還是線路。

1. 記錄目前設定。記下目前模式、符合規則的群組及該組選取的節點。開啟用戶端的「連線」或「Connections」頁面，準備觀察新連線。
2. 在規則模式下重現問題。關閉目標網站的相關分頁後重新開啟，查看目標網域、符合的規則及最終連線路徑。留意是否意外符合 DIRECT、REJECT 或錯誤的預設群組。
3. 切換至全域並選取相同節點。在「代理」或「Proxies」頁面找到 GLOBAL，選取要比較的出口。不同用戶端的選單位置可能不同，請以介面實際顯示為準；不要把「系統代理」開關當成模式選擇。
4. 重新建立連線再比較。切換模式通常不會將現有 TCP 連線轉移至另一個出口。可在連線面板關閉目標連線，或完全結束相關應用程式後再重新啟動；請留意不要誤關仍在下載的工作。
5. 恢復規則模式並修正問題原因。若全域模式正常、規則模式失敗，請優先檢查規則順序、遠端規則集是否載入成功、群組名稱是否一致，以及相關子網域是否遺漏。修正後切回規則模式再次測試。

使用明確的代理連接埠確認請求是否進入核心

如果目前設定確實使用 mixed-port: 7890，可在桌面終端機執行以下命令，讓一次 HTTPS 請求明確透過本機 HTTP 代理送出。Windows PowerShell 建議使用 curl.exe，避免舊版環境中的同名命令別名造成參數差異。

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

Windows 的對應指令：

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

如果實際監聽的連接埠是 7891，命令也必須一併修改。此測試只能證明該次請求經由指定連接埠，無法證明所有應用程式都已被接管，也不能只憑回應狀態碼就認定使用了遠端節點。請搭配連線面板中的策略路徑判斷最終出口。若連線遭拒，先確認核心是否正在執行、連接埠是否一致，別急著修改規則。

切換模式後仍有異常：優先檢查 DNS、TUN 與既有連線

全域模式不會自動修復 DNS

代理模式和 DNS 設定並非同一個開關。使用 mihomo 時，解析行為也可能受 dns.enhanced-mode、nameserver、nameserver-policy 等欄位影響。切換至全域模式後，不能據此斷定所有 DNS 請求都會透過代理，更不能認定應用程式自行使用的加密 DNS 已被接管。

遇到「網域無法開啟，但網路似乎正常」時，先查看日誌是否出現解析逾時，再檢查目前的 DNS 設定是否遭到覆寫。不要同時更換模式、解析伺服器及節點；一次只變更一個項目，才有機會找出真正原因。

TUN 是流量入口，不是第四種代理模式

啟用 TUN 後，仍可選擇規則、全域或直連模式。桌面端請確認虛擬網卡及路由已建立；Android 端則要確認 VPN 權限已授予。若應用程式列於排除清單中，即使目前顯示全域模式，也可能不會經過核心。反之，直連模式下 TUN 仍可繼續接收並轉送流量。

直連失敗，不一定是代理規則造成的問題

如果規則、全域及直連模式都無法連線，請先檢查本機網路、目標服務狀態、連接埠監聽情況及核心日誌。若要完全繞過用戶端進行比較，請先關閉系統代理與 TUN，再正常結束用戶端，並確認系統未留下代理設定。只切換至直連，無法排除核心 DNS 及路由層的影響。