01 · RULES
依序比對網域、IP 與兜底規則
規則模式的重點不在規則數量,而在比對順序。網域規則通常放在 IP 類規則之前,廣告分類、指定網域與區域網路位址應優先處理,最後再由 MATCH 接住未命中的連線。客戶端的規則頁適合確認目前設定包含哪些規則,並查看連線最後進入了哪個策略群組。
修改設定時,也要檢查規則名稱與策略群組名稱是否完全一致。規則指向不存在的策略群組會導致載入失敗,過早出現的寬泛規則則可能讓後續規則失效。相較於只提供開關的普通代理工具,Clash 的規則鏈可將網域、地理資料與程序等條件組合成清楚、可複查的流量路徑。
查看協定與規則參考 →
config.yaml · rules
已載入
DOMAIN-SUFFIX github.com節點選擇
DOMAIN-KEYWORD google節點選擇
GEOSITE category-ads-allREJECT
GEOIP CNDIRECT
MATCH 兜底節點選擇
02 · ROUTING
區分系統代理與 TUN 模式
系統代理會將本機代理位址寫入作業系統設定,適合瀏覽器及會主動讀取系統代理的桌面應用程式。終端機程式、部分遊戲及自行管理網路連線的軟體可能忽略這項設定。遇到瀏覽器可用但命令列無法連線時,先確認應用程式是否遵循系統代理,再決定設定環境變數或使用涵蓋範圍更廣的 TUN 模式。
TUN 模式透過虛擬網路介面接管流量,適合需要統一處理更多應用程式的情境,但也更依賴權限、路由與 DNS 設定。兩種方式不必同時反覆切換。先從系統代理開始,確認設定與節點運作正常,再依應用程式涵蓋範圍啟用 TUN,排查時會更容易找出問題所在。
閱讀連線步驟 →
網路設定
本機
系統代理 寫入作業系統代理設定
TUN 模式 透過虛擬網路介面接管連線
允許區域網路連線 允許同一網路中的裝置存取
混合連接埠 HTTP 與 SOCKS 共用入口 7890
IPv6 依目前網路環境決定
03 · DNS
將網域解析納入同一條分流鏈
當規則以網域為條件時,DNS 處理方式會直接影響比對結果。客戶端可交由核心處理查詢,並依規則選擇解析路徑。若作業系統、瀏覽器與客戶端分別採用不同解析方式,可能出現網域命中與預期不符、連線繞過代理或解析結果快取尚未更新等情況。
排查 Clash DNS 洩漏時,不應只查看一個測試頁面。先確認目前模式、設定中的 DNS 開關、瀏覽器安全 DNS 設定與系統快取,再檢查日誌是否出現相應查詢。修改 nameserver、fallback 或 fake-ip 相關設定後,需要重新載入設定,並關閉既有連線後重新測試。如此才能區分舊快取、瀏覽器獨立解析與核心設定問題。
查看 DNS 常見問題 →
DNS 設定
mihomo
enable true
listen 0.0.0.0:1053
enhanced-mode fake-ip
respect-rules true
ipv6 false
解析方式需要與規則模式、網路環境及應用程式行為一併檢查。
04 · LOGS
用日誌確認連線走向
日誌頁適合回答三個問題:請求是否進入核心、命中了哪條規則,以及最後使用了哪個策略。排查時先將日誌層級維持在一般資訊範圍,再重現一次問題。大量除錯行不會自動帶來更清楚的結論,反而可能淹沒關鍵連線。依時間、網域與錯誤關鍵字縮小範圍通常更有效。
如果日誌中完全沒有目標連線,問題多半發生在流量進入 Clash 之前,應檢查系統代理、TUN 權限或應用程式自己的代理設定。若日誌顯示規則命中正確但連線失敗,再檢查策略群組選擇、訂閱狀態與目標網路。將入口、比對、出口分成三段查看,比反覆更換節點更容易找出穩定的原因。
閱讀瀏覽器與終端機排查流程 →
執行日誌
INFO
10:21:08 INFO 設定檔載入完成
10:21:11 INFO 系統代理設定已更新
10:21:17 INFO github.com 命中 DOMAIN-SUFFIX
10:21:17 INFO 策略:節點選擇
10:21:24 INFO 規則模式連線已建立