Clash config.yaml 設定檔解析：連接埠、DNS、proxy-groups 與 rules

先掌握設定的處理流程：應用程式將請求送至本機連接埠，核心再依目前模式處理；在規則模式下，rules 決定採用哪個策略，proxy-groups 再決定實際出口。dns 負責名稱解析，TUN 則會改變流量進入核心的方式。這些設定彼此相關，但並不是同一個開關。

本文依照設定檔常見的排列順序逐段說明。基礎欄位適用於 Clash 設定體系；涉及 TUN、DNS 擴充功能或新協定時，請以實際使用的核心為準。Clash Meta 後續改名為 mihomo，用戶端介面與核心的名稱也可能不同，不能只因用戶端名稱含有「Clash」，就認定所有欄位都受支援。

1. 修改前先確認檔案與生效位置

config.yaml 不一定就是用戶端目前載入的完整設定。圖形介面用戶端可能分別儲存訂閱原始內容、使用者設定、覆寫片段和最終執行設定。直接修改執行時產生的檔案，下次切換訂閱或重新啟動時可能會被重新產生。

開啟用戶端的「設定檔」或「Profiles」頁面，確認目前啟用的項目，而不只是查看最近匯入的項目。
透過該項目的「編輯」或「開啟檔案」功能，先另存一份修改前的內容。按鈕名稱可能因用戶端版本而異。
確認用戶端是否提供「覆寫」、「合併」或 Merge 功能。需要長期保留的本機規則，建議優先透過這些功能新增。
儲存後執行「重新載入設定」，或重新啟用該設定，並查看記錄是否出現解析錯誤。

先排除 YAML 語法問題

請使用空格縮排，不要使用 Tab。本文統一以兩個空格表示一層縮排。
鍵和值之間要留空格，例如 mode: rule，不要寫成 mode:rule。
清單項目以 - 開頭；同一層的節點、策略組與規則要對齊。
布林值請寫成 true 或 false。名稱、密碼和網址若含特殊符號，建議加上引號。

若出現 yaml: line 12: mapping values are not allowed in this context，請先檢查第 12 行及其上一行的冒號、引號和縮排。這時還沒進入網路連線階段，反覆更換節點通常無濟於事。

2. 連接埠與執行模式：請求從哪裡進入

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

mixed-port 可同時接收 HTTP 代理和 SOCKS5 代理請求。以上例來說，應用程式可將代理伺服器設為 127.0.0.1，連接埠設為 7890。這些只是範例值；若用戶端顯示其他連接埠，請以實際執行值為準。

欄位	用途	容易混淆之處
`port`	HTTP 代理監聽連接埠	不是 DNS 連接埠，也不是遠端節點的連接埠。
`socks-port`	SOCKS 代理監聽連接埠	應用程式必須選用相對應的代理協定。
`mixed-port`	HTTP 與 SOCKS 共用同一個入口	不必與其他監聽項目重複綁定相同的位址和連接埠。
`external-controller`	控制介面監聽位址	供介面控制核心使用，不是填入瀏覽器的代理入口。

mode: rule 代表依規則分流；global 使用全域策略；direct 則採直連。編輯 rules 後卻看不到變化，請先確認介面是否仍處於「全域」或「直連」模式。

allow-lan: false 用於限制區域網路裝置連入。若確實要讓同一個網路中的其他裝置使用，還需確認監聽位址、系統防火牆和驗證設定。不要只為了讓手機連上代理，就將控制介面直接暴露在公用網路上。

log-level: info 適合作為日常疑難排解的起點；暫時改用 debug 後應盡快恢復，因為記錄可能包含瀏覽過的網域。此處的 ipv6: false 不會關閉作業系統的 IPv6，不能取代系統網路設定。

3. dns：監聽、上游與 fake-ip 各自負責什麼

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query

enable 用來啟用核心的 DNS 模組；listen 則決定 DNS 服務在哪裡監聽。設定為 127.0.0.1:1053，只代表本機有這個 DNS 入口，不代表系統已將所有 DNS 請求送到這裡。一般系統 DNS 設定通常無法直接指定 1053 這類自訂連接埠，還需要搭配用戶端的 DNS 接管、轉送或 TUN 設定。

default-nameserver 不只是一般的備用清單

當 nameserver 使用網域名稱形式的加密 DNS 位址時，核心需要先解析該 DNS 伺服器的網域名稱。default-nameserver 主要負責這類引導解析；nameserver 才是一般查詢使用的上游伺服器。把所有位址隨意塞進同一份清單，只會讓問題更難排查。

fake-ip 回傳的是映射位址

fake-ip 模式會為網域名稱指派映射位址，協助核心將連線與網域名稱對應起來。看到 198.18.0.0/16 範圍內的位址，不必立刻判定為 DNS 污染。這些位址用於內部映射，並不是目標網站實際的公用 IP。

若區域網路服務、印表機或某個應用程式不相容，可在既有的 dns 區段中加入精確的 fake-ip-filter 項目。先確認出問題的網域，再依照所用核心支援的比對語法新增。不要直接排除所有網域，否則會改變整套 DNS 行為。

4. proxies 與 proxy-providers：節點來源

proxies 是直接寫在設定檔中的節點清單。每個節點的 type 會決定需要哪些欄位；常見欄位包括 name、server 和 port。不過密碼、UUID、TLS 與傳輸參數必須符合伺服器設定，不能直接套用其他協定的欄位。

proxy-providers 用來定義節點提供者，可透過遠端網址或本機檔案提供節點集合。並非任意訂閱連結都能直接放進去使用：提供者檔案格式、訂閱回傳內容和核心支援範圍都必須相符。包含 rules、dns 的完整設定，也不能直接當成純節點集合使用。

直接定義的節點，透過 proxy-groups 中的 proxies 引用名稱。
提供者中的節點，通常透過策略組的 use 引用提供者名稱。
名稱必須完全一致，空格、大小寫和符號都算在名稱內。
請勿在公開截圖或公開記錄中透露訂閱網址、密碼、UUID 和控制介面金鑰。

若記錄提示某個代理不存在，請先確認引用關係，再檢查訂閱是否成功更新。刪除節點或更改名稱後，舊策略組若仍引用原名稱，也會導致設定檢查失敗。

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

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT
  - name: 預設出口
    type: select
    proxies:
      - 手動選擇
      - DIRECT

這段範例只呈現引用結構，DIRECT 是內建的直連策略，不是代理節點。因此照抄後不會取得遠端代理功能。實際使用時，應將設定中已有的節點名稱或提供者引用加入策略組。

「預設出口」這個組名可供規則引用，組內也能引用「手動選擇」。這種分層方式能將應用規則與實際節點分開：規則長期指向固定的組名，要更換節點時只需在代理頁面調整組內選項，不必逐條修改規則。

類型	主要行為	設定注意事項
`select`	手動選擇一個候選出口。	候選項目可以是節點，也可以是其他策略組。
`url-test`	依據探測結果自動選擇出口。	需妥善設定探測網址、間隔和切換容差。
`fallback`	依照候選順序選擇可用出口。	重點在於優先順序與故障切換，不是挑選延遲最低的出口。
`load-balance`	依指定策略分配連線。	不會把多個節點的頻寬合併成單一下載連線。

自動組顯示的探測時間，只代表當下連線至探測目標的狀況，不等於所有網站的存取速度。探測間隔也不是越短越好；例如 interval: 300 代表 300 秒，設定前請先確認服務提供者的限制與實際需求。

也要避免循環引用，例如 A 組包含 B 組，而 B 組又包含 A 組。組名層級看似完整，核心卻無法判定有效的最終出口。

6. rules：由上往下比對，符合第一條規則後即停止

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
  - MATCH,預設出口

上例使用保留的範例網域說明語法，不代表實際應用的規則建議。DOMAIN 精確比對單一網域；DOMAIN-SUFFIX 比對該網域及其子網域；IP-CIDR 比對目標 IP 所屬的網段。第三個欄位是處理策略，可以是組名，也可以是 DIRECT、REJECT 等內建策略。

MATCH 必須放在兜底位置

MATCH 會處理前面規則都未比對到的請求。若將它放在第一行，後面的網域與網段規則就不會執行。要新增網域直連規則時，應放在可能先比對到該網域的廣泛規則之前，而不是直接加在檔案末尾。

no-resolve 不會關閉所有 DNS

IP-CIDR 後面的 no-resolve 表示不會只為了判斷這條 IP 規則而主動解析網域。若目標 IP 已知，仍可依 IP 進行比對。這不會停用 DNS 模組，也不會讓依賴網域解析的應用程式自動恢復連線。

使用 GEOIP 或依地理資料比對的規則時，也要確認相關資料檔可用，且格式受核心支援。相關錯誤可參考問題排查中的 GeoIP 疑難排解。規則集則需一併確認 rule-providers 的類型、內容格式，以及 RULE-SET 引用名稱。

7. TUN 與用戶端覆寫：設定檔寫對了，也要確認流量已接管

TUN 是虛擬網路裝置的流量入口，不是另一份代理節點清單。以下是 mihomo 常見的欄位組合；啟用前請確認用戶端的服務權限、系統路由和其他 VPN 的狀態。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route 用於自動設定路由，auto-detect-interface 用於自動選擇輸出介面。不同作業系統與核心版本支援的細節不盡相同；若無法建立虛擬網卡，請先檢查用戶端的服務模式或授權流程，不要任意增減 DNS 位址來處理權限錯誤。

dns-hijack 範例適用於進入接管路徑的傳統 53 連接埠 DNS 流量，並不等於攔截所有加密 DNS。瀏覽器內建的 DoH、其他 VPN 路由和應用程式本身的網路處理方式，都可能影響實際流量路徑。

此外，用戶端可能會以介面設定覆寫檔案中的 mixed-port、mode、dns 或 tun。若儲存後數值又恢復原狀，請查看用戶端提供的「執行設定」或同等功能，比較最終生效內容與訂閱原始內容。不要接連修改多個檔案，以免無法判斷是哪一層覆寫了另一層。

8. 儲存後的檢查順序：語法、載入、流量、規則

先確認設定能否解析。若使用 mihomo 命令列核心，可執行下方的檢查命令。使用圖形介面用戶端時，請優先使用內建的設定檢查功能。
確認重新載入成功。查看記錄中是否仍有舊錯誤，並確認監聽連接埠與目前模式。只儲存檔案不一定會觸發重新載入。
用一個請求確認入口。關閉 TUN 時，可明確指定本機 HTTP 代理進行測試，避免同時將系統代理是否啟用也納入排查。
查看連線詳細資訊。確認目標網域、命中的規則、策略組與最終節點。即使組名正確，只要組內選中 DIRECT，流量仍會直連。
最後確認設定能持續生效。重新啟動用戶端，再更新一次訂閱，確認覆寫設定仍然保留。若設定遺失，應修正合併方式，而不是重複手動補上。

# 在設定檔所在目錄執行；mihomo 必須已加入命令搜尋路徑
mihomo -t -f config.yaml

# 明確透過本機 7890 連接埠的 HTTP 代理送出請求
curl -I --proxy http://127.0.0.1:7890 https://example.com

命令列檢查應使用與用戶端相同版本的核心，並留意相對路徑依賴。設定檢查通過，只能證明該核心能接受這份設定，無法保證節點可連線、訂閱可更新或目標網站可存取。上方的 curl 請求也只驗證這一筆請求的代理路徑，不代表所有應用程式都已接管。

若出現 bind: address already in use，請先找出佔用連接埠的程序，或一併調整監聽連接埠和應用程式中的代理連接埠。若是節點連線逾時，請改為檢查節點位址、網路連通性與服務狀態，並參考連線逾時排查。

安全修改的關鍵是一次只調整一個部分：先處理連接埠與模式，再調整 DNS，接著設定策略組與規則，最後才考慮 TUN 接管。每次都保留可正常運作的版本，出問題時才能復原。若要重新確認訂閱啟用狀態、模式切換與本機連接埠，可依入門指南逐項檢查。