Clash config.yaml 設定檔結構解析：逐一看懂連接埠、DNS、proxy-groups 與 rules

1. 先確認設定來源、核心與 YAML 結構層級

config.yaml 是常見的設定檔名稱，但並非所有用戶端都固定使用這個檔案。訂閱下載的設定、本機設定，以及用戶端產生的執行設定，可能分別存放在不同位置。編輯前，先到用戶端的設定清單確認目前啟用的項目，再查看實際執行中的設定；修改未啟用的檔案，不會影響目前的連線。

Clash 是一套代理設定架構，Clash Meta 後續改名為 mihomo。許多基礎欄位可以沿用，但協定支援、DNS 選項與 TUN 參數會因核心及版本而異。本文先說明通用結構，再另外標示 mihomo 擴充項目。各用戶端的介面名稱不盡相同，不能只憑軟體圖示判斷目前使用的核心。

讀 YAML 時，先掌握這三點

縮排表示層級。本文統一使用 2 個空格，不使用 Tab。頂層的 dns、proxies、rules 都靠左對齊。
冒號用來分隔鍵和值。請寫成 mode: rule，不要使用全形冒號。行首的 - 代表清單項目。
名稱會互相引用。規則指定的策略群組必須存在；群組內引用的節點或其他群組也都必須找得到。

2. 連接埠與模式：先決定流量如何進入核心

檔案前段通常會列出監聽連接埠、執行模式與記錄層級。連接埠負責接收要求，模式則決定要求進入後如何選擇出口。這是兩個獨立環節：即使規則設定正確，應用程式若沒有將流量交給用戶端，也不會建立預期的代理連線。

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

欄位	範例說明	檢查重點
`mixed-port`	7890 同時接收 HTTP 與 SOCKS 代理要求	應用程式設定的連接埠必須一致，且未被其他程序占用
`allow-lan`	false 表示不允許其他區域網路裝置連線	若要共用，還要確認監聽位址與防火牆設定
`mode`	rule 依規則清單比對連線	全域模式無法用來驗證 rules 的比對順序
`log-level`	info 輸出一般執行資訊	暫時排錯可改用 debug，完成後記得還原
`ipv6`	false 會關閉核心對應的 IPv6 支援	不代表關閉作業系統的所有 IPv6 流量

mixed-port、port 和 socks-port 該怎麼選？

port 是 HTTP 代理連接埠，socks-port 是 SOCKS 代理連接埠；需要統一入口時，可使用 mixed-port。例如，應用程式設定 HTTP 代理為 127.0.0.1:7890，核心就必須在 7890 接收對應要求。不同監聽項目不可使用相同的位址與連接埠。

mode: rule 依規則分流；global 使用全域策略；direct 則是直接連線。切換模式不會自動變更瀏覽器的系統代理設定。初次測試時，建議先使用系統代理，確認基本連線正常後再啟用 TUN，避免同時排查多個流量入口。

如果看到 external-controller: 127.0.0.1:9090，這通常是控制 API 的監聽位址，不是上網用的代理連接埠。不要把 9090 填入瀏覽器的代理設定，也不要為了方便而將控制介面公開至網際網路。

3. dns：分清解析伺服器、監聽位址與 fake-ip

dns 決定核心如何處理交由它處理的網域名稱解析要求。以下以 redir-host 說明基本架構；兩個 IP 是解析伺服器範例，不一定適用於所有網路。使用前請確認所在網路可以連線，並考量 DNS 要求的隱私需求。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable: true 會啟用核心的 DNS 功能，但不會自動將整個系統的 DNS 要求全部導入核心。
listen 用來指定本機 DNS 監聽位址。範例使用 1053，而非系統常用的 53；若沒有額外的轉送設定，系統不會自動查詢這個連接埠。
nameserver 是上游解析伺服器清單。傳統 DNS 通常使用連接埠 53，DoH 與 DoT 則使用各自的協定位址。
dns.ipv6: false 控制此 DNS 模組如何處理 AAAA 查詢，不是作業系統層級的 IPv6 防火牆。

fake-ip 為什麼會回傳以 198.18 開頭的位址？

enhanced-mode: fake-ip 會為網域名稱配置映射位址，再由核心將連線對應回原始網域。設定中常見的 fake-ip-range: 198.18.0.1/16 就是用於這類映射，並非網站伺服器實際的公網位址。因此，看到這個網段，不代表 DNS 一定遭到污染。

部分區域網路服務、裝置探索功能，或依賴實際解析位址的程式可能需要例外處理。請依實際情況設定 fake-ip-filter，不要一次加入大量範圍過廣的網域。redir-host 與 fake-ip 的行為不同，切換後請建立新連線再測試。

留意 mihomo 對節點網域名稱的解析

代理伺服器本身也可能使用網域名稱。mihomo 提供 proxy-server-nameserver 等欄位，用來設定節點網域的解析方式；若上游 DoH 位址本身是網域名稱，也可能需要透過 default-nameserver 進行引導解析。如果解析節點網域需要代理，而建立代理又依賴該網域，就會形成循環依賴。啟動後若所有節點都逾時，應先查看記錄中的網域解析錯誤，而不是只修改規則。

4. proxies：節點參數不等於訂閱連結

proxies 是節點定義清單。每個節點通常包含 name、type、server、port，其他驗證與傳輸參數則依協定而異。策略群組會引用節點名稱；伺服器連接埠則是遠端服務的連接埠，別和本機的 7890 搞混。

本文不會捏造伺服器位址或密碼。理解結構時，可用 proxies: [] 表示空的節點清單，再讓策略群組暫時引用內建的 DIRECT。這份設定可以示範直接連線分流，但不會憑空提供代理服務。若要實際使用代理，必須加入服務供應商提供、且目前核心支援的節點參數。

訂閱網址應該放在哪裡？

完整設定訂閱：在用戶端的訂閱或設定頁面匯入。回傳內容可能已包含節點、策略群組與規則。
節點集合訂閱：可由支援的 proxy-providers 機制讀取，再由策略群組透過 use 引用。
單一節點分享連結：需要用戶端辨識或轉換，不能直接當成 YAML 節點物件貼入 proxies。

一般網頁、登入頁或過期提示頁都不是節點清單。匯入後若出現解析錯誤，請先確認回應內容，而非反覆調整縮排。也要分清完整設定與 provider 所需的節點集合格式：副檔名同為 YAML，不代表內部結構可以互換。

使用 proxy-providers 時，常見的 interval: 3600 表示每 3600 秒更新一次資源；策略群組健康檢查中的 interval: 300 則表示每 300 秒檢測一次。兩者用途不同，都不是延遲門檻，也不能取代用戶端對完整訂閱的更新設定。

5. proxy-groups：將節點整理成可選擇的出口

規則通常會指向策略群組，再由群組選擇節點或其他出口。如此一來，更換節點時就不必逐條修改規則。以下範例的群組名稱是「出口選擇」，內容只有內建的直連出口，適合用來檢查引用關係。

proxies: []

proxy-groups:
  - name: 出站選擇
    type: select
    proxies:
      - DIRECT

三種常見策略群組的差異

類型	選擇方式	使用須知
`select`	由使用者手動選擇群組內的出口	適合先固定節點，用於排查規則與連線狀況
`url-test`	依測試結果自動選擇延遲較低的出口	測試網址的回應時間不等於下載速度
`fallback`	依清單順序選擇可用的出口	優先順序取決於清單排列，不是依最低延遲排序

url-test 和 fallback 通常還需要設定測試網址、檢測間隔等參數。測試網址必須能從目前的環境連線；若測試網站故障，多個正常節點也可能同時顯示無法使用。不要只憑一次延遲測試就刪除節點。

群組名稱與節點名稱應保持唯一且易於辨識。假設規則引用「出口選擇」，改名為「代理出口」後，也必須同步修改規則。群組可以分層，但不能讓 A 引用 B、B 又引用 A；循環引用會導致出口選擇無法正常完成。

6. rules：由上往下比對，MATCH 放在最後

在規則模式下，連線通常會依清單順序比對，由第一條命中的規則決定使用哪個策略。規則不會自動讓「越精確的項目優先」：如果範圍較廣的規則排在前面，後面的精確規則可能永遠不會執行。先列出明確例外，再列範圍較廣的規則，最後放上兜底規則，會比較容易檢查。

rules:
  - DOMAIN,example.com,出站選擇
  - DOMAIN-SUFFIX,example.org,DIRECT
  - 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,出站選擇

DOMAIN 用來精確比對網域名稱。範例只會比對 example.com，不會自動包含它的所有子網域。
DOMAIN-SUFFIX 會比對該網域及其子網域。範例涵蓋 example.org 與 www.example.org。
IP-CIDR 用來比對目標 IP 網段。範例列出三個常見的私有 IPv4 網段，並非所有特殊用途位址的完整清單。
no-resolve 表示不會只為了比對這條 IP 規則而主動解析網域，並非關閉整條連線的 DNS。
MATCH 作為兜底規則，接收前面都未命中的連線，應放在清單最後。

GEOIP、RULE-SET 與規則提供者

GEOIP,CN,DIRECT 會依據 IP 地理位置資料庫比對，不是根據網域文字判斷所在地。資料庫遺失、更新失敗，或解析結果取得不同地區的 IP，都會影響比對結果。遇到資料庫錯誤，可前往疑難排解手冊的 GEOIP 檢查項目繼續排查。

RULE-SET 引用的是 rule-providers 中定義的規則集合，和存放節點的 proxy-providers 不同。使用前請確認規則集合的格式、行為類型，以及目前核心是否支援。匯入規則集合後，還要在 rules 中加入引用；定義資源本身不代表它已參與比對。

7. 建立最小設定，再逐步加入 TUN 與訂閱節點

以下將前述基礎欄位組合成一份本機學習用設定。這份設定不含代理伺服器，所有出口最後都會直接連線；用途是驗證 YAML 層級、連接埠監聽與策略引用。若用戶端會自動覆寫連接埠或 DNS，請以執行中的設定與記錄為準。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

proxies: []

proxy-groups:
  - name: 出站選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,example.com,出站選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出站選擇

為什麼不直接加入 TUN？

TUN 是另一種流量入口，不是代理節點，也不是能讓規則自動正確的開關。mihomo 常見的設定項目包括 tun.enable、stack、auto-route 和 dns-hijack，但實際效果還取決於作業系統、服務權限、網路介面卡與路由環境。不要把平台資訊不明的 TUN 設定直接複製到所有裝置。

建議先完成「應用程式代理 → 7890 → 規則 → 出口」的驗證，再透過用戶端支援的方式啟用 TUN。若啟用後無法連線，請優先檢查路由、DNS 接管及是否與其他 VPN 衝突，而不是立刻重寫 proxies。基本接管步驟可參考入門指南的 TUN 模式說明。

8. 儲存後設定未生效：依序檢查語法、引用與執行狀態

確認編輯的是目前啟用的項目。查看設定清單中的目前項目與更新時間，再重新載入設定。用戶端可能儲存了多個同名檔案。
檢查語法錯誤所在行。若看到 yaml: line 相關提示，除了檢查該行，也要檢查上一行的冒號、引號、清單符號與縮排。含特殊字元的密碼，應依 YAML 字串規則加上引號。
檢查頂層是否有同名鍵。不要在檔案末尾再加上第二個 dns: 或 rules:。重複的鍵可能會遭到拒絕，也可能覆蓋原值，視解析方式而定。
檢查出口引用。若提示代理或策略不存在，請逐字核對群組名稱、節點名稱與大小寫。YAML 可以解析，不代表引用關係正確。
檢查監聽與流量入口。若出現 address already in use，請確認 7890 或 DNS 監聽連接埠是否已被占用；修改系統代理位址無法解決連接埠衝突。
檢查實際命中的規則。確認目前使用 rule 模式，並以新連線查看規則詳細資訊。若應用程式繞過系統代理，請先處理流量入口，或視需要使用 TUN。

使用核心內建的設定檔測試功能

若能直接使用 mihomo 命令列，可在設定檔所在目錄執行以下命令。設定檔測試可能也需要讀取外部資源與資料庫，因此請使用與實際執行相同的工作目錄及資源環境。

mihomo -t -f config.yaml

測試通過表示核心接受這份設定，不代表節點憑證有效、所有上游服務都能連線，或網站一定會走預期的出口。接下來仍須檢查連線記錄。排錯時一次只修改一個環節，並記錄修改前後的錯誤訊息，通常比同時切換 DNS、規則與 TUN 更容易找出問題。

看懂設定的關鍵，是依序核對「入口連接埠 → 網域解析 → 規則命中 → 策略群組 → 最終出口」。想了解更多規則排錯方法，可查看config.yaml 設定檔檢查；準備更換用戶端時，請先確認新用戶端使用的核心及支援的欄位範圍，再移轉設定。