為什麼要先把 YAML 結構弄清楚？

無論你使用的是傳統 Clash 核心或 mihomo（Clash Meta），設定檔本質上都是一份結構化的 YAML。圖形介面可以幫你匯入訂閱、切換節點，但一旦遇到「特定網域要走直連」「某個 App 必須走指定節點」「Fake-IP 開啟後部分區網服務異常」這類問題，最終仍要回到文字設定檔裡調整。把 proxies、proxy-groups、rules 與 dns 四個區塊的關係釐清，你才能真正掌控流量怎麼走，而不是被預設規則牽著走。

本文以實務可讀性為優先：先說明各區塊在執行時的邏輯順序，再談策略組類型與規則匹配，最後集中處理 Fake-IP 與 DNS 的協同設定。若你正在從舊版核心遷移，也可一併參考站上的Clash Meta 升級完全指南，先把用戶端與核心版本對齊，再回來微調 YAML，整體會順很多。

設定檔骨架：頂層欄位與閱讀順序

一份常見的 Clash 設定檔會在頂層宣告連接埠、執行模式與日誌等基礎參數，接著才是節點、策略組與規則。閱讀或修改時，建議先在腦中建立「資料從哪裡來、規則如何指到策略組、策略組再指到哪些節點」這條鏈條，而不是從某一行規則片段開始硬改。

例如 port 與 socks-port 決定本機代理服務監聽位置；mode 常見為 rule（依規則分流）、global（全走同一策略組）或 direct（全直連）。多數使用者會維持 rule，讓下方 rules 決定去向。log-level 則影響除錯資訊量：排查規則命中問題時可暫時調高，穩定後再降回 info 或 warning 以免日誌過大。

external-controller 則提供 REST API，讓圖形介面或腳本能切換策略組、重新載入設定。若你只在 GUI 內操作，通常不必手動改這個欄位；但若你要用外部儀表板監控節點延遲，就會需要正確的監聽位址與存取控制設定。

proxies：節點定義與命名慣例

proxies 陣列中每一筆都是一個獨立節點，包含類型（如 ss、vmess、trojan、vless 等）、伺服器位址、連接埠與協定所需參數。mihomo 對新協定的支援比舊核心完整，但欄位命名仍須與官方文件一致，否則解析階段就會直接報錯。

每個節點的 name 會被後續 proxy-groups 與 rules 引用，因此建議使用簡短、唯一、可辨識的名稱，避免空白與特殊符號。若訂閱自動產生的名稱過長，可在用戶端重新命名，或在轉換訂閱時套用模板統一格式。這樣在做「依國家／依延遲自動選擇」時，才不會因名稱混亂而難以維護。

proxy-groups：策略組類型與實務選擇

proxy-groups 是 Clash 最有特色的設計之一：它把「使用者可切換的選項」抽象成一個組，再由規則把流量導向不同組。常見類型包含 select（手動選擇）、url-test（依延遲自動選擇）、fallback（依可用性依序嘗試）、load-balance（負載平衡）以及 relay（鏈式代理）。

select 最直覺：組內列出多個節點或其他策略組，使用者或 API 指定當前要使用哪一個。適合「我想手動決定走哪條線」的情境。url-test 會週期性對指定 URL 發送測試請求，選延遲最低者；可設定 interval、tolerance 等參數，避免節點在臨界值附近頻繁跳動。fallback 則適合「只要有一個能用就好」：按照列表順序檢查，找到第一個可用節點即採用，常用於自動容錯。

relay 會將流量依序經過多個節點，鏈路較長、除錯較難，僅在確實需要多跳轉時使用。load-balance 則需理解哈希策略與會話一致性：並非所有網站都適合在多節點間分散連線。實務上，多數使用者會以 select + url-test 組合完成八成需求。

策略組可以互相嵌套：例如「手動選擇 → 自動測速組 → 具體節點」。嵌套過深會讓除錯變困難，因此建議維持兩到三層以內，並在命名上標示層級（如 PROXY 作為總出口、Auto 作為自動選擇、下層才是各機場節點）。

rules：由上而下匹配，沒命中才繼續往下

rules 是分流的核心：Clash 會從第一條規則開始檢查，一旦命中即停止，不再看後面的條目。這代表「順序」本身就是策略的一部分——把最精確、最例外的規則放在前面，把最通用的規則放在後面。許多範本會把廣告攔截、區網直連、國內 IP 直連放在前段，最後才用 MATCH 交給總策略組。

常見規則類型包括基於網域名稱的 DOMAIN、後綴匹配的 DOMAIN-SUFFIX、關鍵字 DOMAIN-KEYWORD、IP 段 IP-CIDR、地理資料庫 GEOIP，以及處理程序名稱 PROCESS-NAME（桌面環境）等。若你使用規則集（rule-providers），實際展開後仍會變成大量單條規則，匹配原則不變。

請特別留意：規則只決定「這筆連線要交給哪個策略組或直連／拒絕」，真正走哪個節點仍由該策略組當下的選擇決定。因此若你發現「規則明明寫了走代理，卻仍像直連」，要先檢查策略組是否選在 DIRECT，或 url-test 是否選到延遲最低的直連節點（若誤設）。

rule-providers：規則集與更新節奏

當規則數量很大時，手寫 rules 難以維護，此時會改用 rule-providers 引用外部規則集檔案或遠端 URL。mihomo 亦支援內嵌規則集格式，重點仍是：規則集載入後與手寫規則一併參與「由上而下」匹配，因此載入順序與主規則表中的 RULE-SET 插入位置同樣關鍵。

實務上會為不同用途拆分規則集：例如廣告封鎖、隱私追蹤、國內網域直連、海外影音分流等。更新頻率則需平衡：過於頻繁可能增加啟動與重載時間；過舊則可能漏掉新網域。建議搭配用戶端的手動更新與排程，並在網路不穩時保留本機快取，避免規則拉取失敗導致整體載入失敗。

DNS 與 Fake-IP：為什麼「解析」會影響分流

在 rule 模式下，許多規則依賴網域名稱或 IP 判斷。若 DNS 請求繞過 Clash，可能出現「規則看起來命中，實際連線卻未走代理」的現象，也就是常說的 DNS 洩漏。為此，Clash 內建 DNS 模組，並提供 redir-host 與 fake-ip 兩種增強模式。

Fake-IP 的核心概念是：對本機應用程式回傳一個虛擬位址（常見為 198.18.0.0/16 區段），讓連線先進入 Clash，再由核心依網域名稱與規則決定實際出口。這樣做的好處是域名資訊不會在 DNS 階段就流失，對分流與防洩漏較有利。缺點則是部分應用程式或區網服務若依賴真實 IP 行為，需要設定 fake-ip-filter 將特定網域排除在 Fake-IP 之外。

以下是一段常見的 Fake-IP 相關設定骨架（實際 nameserver 請依你的網路環境調整）：

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
  nameserver:
    - https://dns.google/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

nameserver 作為主要解析來源，fallback 則在主要無法滿足條件時啟用；fallback-filter 常搭配 GeoIP 判斷，避免國內網域錯誤走到海外 DNS。若你發現某些純區網裝置無法透過名稱存取，優先檢查是否需加入 fake-ip-filter，或改以 DOMAIN 規則明確直連。

常見誤區與排查順序

第一類問題是「規則寫對了但感覺沒生效」：請先確認模式是否為 rule，再確認命中的是哪一條規則（可藉由提高日誌層級或使用用戶端內建的連線預覽）。第二類是「DNS 與規則不一致」：關閉 Fake-IP 後若恢復正常，多半要調整 fake-ip-filter 或 DNS 上游。第三類是「策略組選到錯誤節點」：檢查 url-test 的測試 URL 是否被攔截、tolerance 是否合理。

另一個常見情境是使用者複製了範本，卻未將範本中的策略組名稱與自身節點名稱對齊，導致引用不存在的名稱而啟動失敗。建議在儲存前用用戶端的語法檢查或核心的驗證輸出確認無誤。若你希望我們用圖形介面完成安裝與訂閱匯入，可先前往用戶端下載頁取得對應平台版本，再回頭對照本文調整進階 YAML。

結語：結構清楚，分流才穩

Clash 的威力來自「節點、策略組、規則、DNS」四者的協同，而不是單一捷徑參數。把 YAML 當成可維護的專案文件：命名一致、規則分層、策略組不過度嵌套，再配合 Fake-IP 與合理的 DNS 上游，就能在大多數網路環境下獲得穩定的分流體驗。相比僅依賴預設訂閱範本，願意理解結構的使用者往往能更快定位問題，也更容易依自身需求擴充規則。

若你正在尋找內建 mihomo 核心、並提供視覺化訂閱與規則管理的桌面用戶端，不妨直接前往下載頁取得安裝套件，用圖形介面驗證每一條規則與策略組是否符合預期；當需要進階調整時，再回到 YAML 微調即可。→ 立即免費下載 Clash，開啟流暢上網新體驗