Clash config.yaml 設定檔逐段解析：proxies、proxy-groups 與 rules 規則寫法

先確認核心版本，再看設定檔的引用關係

設定檔的核心是三層關係：節點定義連線出口，策略組管理出口，規則決定連線交由哪個出口處理。proxies 不是規則清單，proxy-groups 也不會自動讓所有連線都走代理。只有連線由用戶端接管，並符合相應規則時，設定的選擇才會生效。

Clash 是這類設定生態常用的統稱，但不同核心支援的欄位不盡相同。本文的完整範例適用於 mihomo，也就是原 Clash.Meta 核心；其中內嵌規則集等寫法，不代表所有舊版 Clash 核心都支援。請先在用戶端的「關於」或核心資訊頁確認核心名稱，再對照設定文件。

• proxies：存放單一節點的協定、伺服器、連接埠與驗證參數。
• proxy-groups：透過節點名稱或其他策略組名稱，將出口整理成可選擇的策略。
• rule-providers：定義可重複使用的規則集，內容可來自檔案、HTTP 或內嵌清單。
• rules：依序比對連線，並指定 DIRECT、REJECT 或策略組。

可正常載入的 config.yaml 結構範例

以下是完整的 mihomo 示範設定，不含遠端代理節點，預設出口為 DIRECT，用途是觀察設定載入、策略組選擇與規則比對，無法憑空提供代理線路。確認結構可正常載入後，再加入服務商提供的真實節點。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

proxies: []

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - DIRECT
      - REJECT

rule-providers:
  local-demo:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,example.org

rules:
  - DOMAIN,example.com,DIRECT
  - RULE-SET,local-demo,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選擇

閱讀順序不等於實際執行順序

頂層欄位依「通用設定 → DNS → 節點 → 策略組 → 規則集 → 規則」排列，方便閱讀；但不必一定照這個順序撰寫。真正直接影響結果的是 rules 清單的排列順序，以及策略組的初始選項。引用名稱必須完全一致，包括空格、大小寫與中文字。

YAML 使用空格縮排，請勿混用 Tab。本文每層縮排 2 個空格，清單項目以連字號加空格開頭。名稱或密碼若含特殊字元，建議加上引號；只有數字的密碼也應以字串格式填寫，避免解析後變成其他資料型態。

通用欄位：連接埠、運作模式與流量接管範圍

mixed-port: 7890 只表示核心準備在這個連接埠提供代理服務，不代表系統和所有應用程式都已使用它。一般應用程式可能遵循系統代理設定，也可能忽略；TUN 則透過虛擬網路介面接管更多流量，能否使用仍取決於系統權限、路由與用戶端實作。

本文未啟用 TUN，只要將測試應用程式的 HTTP 代理設為 127.0.0.1:7890，即可確認代理入口是否正常。若連接埠已被其他程式使用，記錄檔通常會出現 address already in use。此時請關閉占用中的程式，或同步修改設定檔與應用程式的代理連接埠，例如都改為 7891。

dns：DNS 解析結果如何配合規則比對

dns 區段負責管理核心的網域解析。範例啟用 fake-ip，並使用 198.18.0.1/16 作為虛擬 IP 位址池；這些位址用於網域映射，不是網站的真實伺服器位址。核心保留映射關係後，可在後續連線中還原網域，協助比對網域規則。

1053 是監聽連接埠，不是上游 DNS 位址

listen: 127.0.0.1:1053 表示本機 DNS 服務的入口；nameserver 中的兩個 IP 才是上游解析器。本例使用一般 DNS，方便了解設定結構；選擇上游時，也要考量目前網路是否可連線及隱私需求，不能把某個公共 DNS 當成適用所有網路的固定答案。

• 只啟用 dns.enable，不會自動將系統的所有 DNS 要求都導入核心。
• 系統 DNS 設定通常無法直接填入 127.0.0.1:1053 這種含自訂連接埠的位址；要接管 DNS，需搭配用戶端或本機轉送設定。
• TUN 中的 DNS 劫持屬於另一層設定。請勿為了讓 DNS 生效，就直接照抄其他系統的 TUN 參數。
• 應用程式內建的加密 DNS 可能改變網域解析路徑。如果網域規則沒有命中，也應一併檢查瀏覽器的安全 DNS 設定和實際連線記錄。

本例未加入 fake-ip-filter。若某個區域網路服務或應用程式不適用虛擬位址，可依據記錄檔將特定網域加入過濾清單，再重新建立連線測試。請勿直接加入範圍過大的萬用字元，否則可能改變大量連線的解析行為。

proxies：節點參數必須與伺服器端一致

proxies: [] 表示節點清單目前是空的。要新增節點，請將它替換為清單。以下僅示範 Shadowsocks 的欄位結構：192.0.2.10 是文件專用的示範位址，密碼也只是範例文字，無法用來實際連線。真實參數請從訂閱或服務商後台取得，不要只改伺服器位址，卻保留其他欄位不變。

proxies:
  - name: "SS-範例"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "demo-only-not-a-real-password"
    udp: true

name 是後續策略組引用的識別名稱；server 與 port 指向遠端服務；cipher 和 password 必須與伺服器端相符。這裡的 8388 是遠端連接埠，與本機的 7890 不同。

udp: true 表示允許此節點使用相應的 UDP 功能，但不保證整條連線都支援 UDP。伺服器端、協定、流量接管方式與目標網路都可能影響結果。其他協定也有各自的欄位，不能把 VMess、VLESS 或 Trojan 的參數硬填在 type: ss 底下。

避免節點名稱重複

建議使用容易辨識的精簡名稱，例如以地區搭配用途命名，並確保名稱不重複。訂閱更新後若節點名稱改變，手動撰寫的策略組可能會引用失效的舊名稱；節點數量較多時，可進一步使用 proxy-providers 管理節點來源。請注意，這項功能管理的是節點，別和負責管理比對條件的 rule-providers 混淆。

proxy-groups：將節點組成規則可引用的策略組

將真實節點加入 proxies 後，還需要把它加入策略組。以下的組別會依名稱引用上一節的節點；只有換成有效的節點參數後，選取該項目才可能正常連線。

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "SS-範例"
      - DIRECT

select 是手動選擇策略組。用戶端通常會在「代理」或策略組頁面顯示此組，點選其中一個成員即可選擇出口。初次載入且沒有先前選擇記錄時，通常會使用清單中的第一個項目；如果啟用選擇記錄持續保存，重新載入後可能會還原上次的選擇，而非回到第一個項目。

策略組也能引用其他策略組，但不能形成循環。例如「日常出口」引用「手動選擇」沒有問題；但「日常出口」與「手動選擇」彼此引用就應避免。若遇到 proxy not found 這類錯誤，請優先確認名稱是否完全一致，以及被引用的項目是否確實存在。

rule-providers 與 rules：定義規則集並安排比對順序

完整範例中的 local-demo 是內嵌規則集，behavior: classical 表示內容採用含規則類型的寫法。其中的 DOMAIN-SUFFIX,example.org 會比對 example.org 及其子網域。規則集只儲存比對條件；最終使用哪個出口，則由 rules 中的 RULE-SET,local-demo,DIRECT 指定。

三種規則集行為不能任意混用

• classical：項目需包含規則類型，例如 DOMAIN-SUFFIX,example.org。
• domain：項目是網域或支援的網域比對表示法，不應直接套用 classical 的完整行格式。
• ipcidr：項目為 IP 網段，例如 192.168.0.0/16。

若改用 type: http，還需設定實際可連線的 url，並依使用格式設定快取路徑、更新間隔等欄位。例如 interval: 86400 代表 86400 秒，也就是 24 小時。遠端內容必須符合宣告的行為與格式；成功下載不代表內容一定能順利解析。

rules 由上往下比對，命中第一條後即停止

範例第一行會精確比對 example.com 並直連，第二行引用規則集，接著處理幾個本機網段，最後以 MATCH,手動選擇 作為兜底規則。MATCH 會接手其餘連線，因此應放在最後；若提早放在第一行，後續規則就沒有比對機會。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,手動選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選擇

DOMAIN 是精確網域比對，DOMAIN-SUFFIX 則是網域後綴比對，兩者不可混用。IP 規則後的 no-resolve 表示不會為了判斷這條規則而主動解析網域；若連線本身已有目標 IP，仍可據此比對。它不是停用整個 DNS，也不是強制讓該網段直連的額外開關。

另外請留意：在規則中使用 GEOIP 或 GEOSITE，會依賴相應的地理資料。本文的最小範例刻意不採用這兩類規則，避免首次載入時受到資料檔缺漏或更新失敗影響。

儲存、驗證與載入：分三步找出錯誤

第一步：使用核心檢查語法與引用

若已安裝獨立版 mihomo，可在設定檔所在目錄執行以下命令。在 Windows PowerShell 中，目前目錄裡的程式通常寫作 .\mihomo.exe；實際執行檔名稱請以本機為準。

mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

檢查通過只表示目前的核心接受這份設定，不代表節點連線正常、密碼正確或 DNS 可連線。若命令檢查通過但用戶端仍失敗，請繼續確認兩者使用的核心和檔案是否相同，以及用戶端是否另外套用了其他設定。

第二步：載入後確認實際運作設定

1. 在用戶端的「設定檔」頁面匯入本機 YAML，並選取該設定檔；若介面提供「編輯」入口，修改後請儲存並重新載入。
2. 在「代理」頁面找到「手動選擇」組，確認成員已列出。尚未加入真實節點時，請維持 DIRECT。
3. 將運作模式設為「規則」，並確認實際混合連接埠是否為 7890。不同用戶端的選單名稱可能略有差異。
4. 使用明確經過代理入口的要求進行測試，再查看「連線」和「記錄」頁面；不要只確認瀏覽器能否開啟網頁。

curl -I --proxy http://127.0.0.1:7890 https://example.com

# 在 Windows 中使用 curl.exe，避免命令別名差異
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com

依照範例，這項要求應符合 DOMAIN,example.com,DIRECT。能否收到 HTTP 回應也取決於本機網路；要判斷規則是否正確，應優先查看連線詳細資訊中的規則與最終出口。這個命令測試的是 HTTP 代理入口，不是 TUN 或系統 DNS 接管狀態。

第三步：依錯誤類型逐項檢查，一次只改一處