Clash config.yaml 設定檔逐段解析：從 port 到 rules

先看架構：五個設定區段如何串接

閱讀設定檔時，先確認連線入口，再檢查 DNS 解析、節點、策略組與規則。config.yaml 不是逐行執行的指令碼：頂層欄位通常可以調整排列順序，但清單內的順序可能直接影響運作，尤其是 rules。將檔案整理成五個主要區段，是為了方便閱讀與排錯，並不表示核心會依序執行五個階段。

本文主要以採用 Clash 設定格式的 mihomo 核心為例。Clash 用戶端是圖形操作介面，核心則負責解析設定與處理連線；不同用戶端可能會再合併或覆寫連接埠、DNS、TUN 等欄位。因此，編輯前除了確認目前使用的核心，也要確認修改的是訂閱原始檔、覆寫檔，還是用戶端最後交給核心的執行設定。

最常見的引用關係是：rules 指向某個策略組，策略組再引用節點名稱，節點則提供伺服器位址、連接埠與驗證資訊。DIRECT 與 REJECT 是內建策略，不必另外在 proxies 中定義。

通用欄位：port、模式與監聽範圍

三種代理連接埠，不代表有三個節點

port 是 HTTP 代理的監聽連接埠，也支援常見的 HTTPS CONNECT 通道；socks-port 是 SOCKS 代理的監聽連接埠；mixed-port 則能在同一個連接埠接收 HTTP 與 SOCKS 代理請求。這些都是本機連線入口，與遠端節點的 port 不同。

port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

這段設定以三個不同連接埠示範欄位關係，實際使用時不必全部啟用。若只需要混合入口，可以只保留 mixed-port: 7892。瀏覽器或系統的 HTTP 代理設定應填入 127.0.0.1:7892；支援 SOCKS 的應用程式也能連到同一個混合連接埠。修改核心連接埠後，也要同步更新應用程式端的設定，避免它繼續連到舊的 7890。

mode 與 allow-lan 各自控制什麼

• mode: rule：依規則清單分流，適合日常按網域或 IP 區分連線出口。
• mode: global：主要透過全域策略選擇出口，不會依一般規則清單逐條分流。
• mode: direct：使用直連模式，不代表關閉用戶端或清除系統代理設定。
• allow-lan: false：不向區域網路裝置開放代理入口。需要共用時，再進一步設定監聽位址、驗證方式與防火牆。

dns：上游解析與流量接管

dns 區段負責核心的網域解析設定，但「啟用核心 DNS」和「所有系統 DNS 請求都交由核心處理」是兩回事。以下範例會在本機 1053 連接埠啟用 DNS 監聽、使用 Fake-IP 模式，並指定一般 DNS 上游伺服器：

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

四個容易混淆的欄位

• listen 是核心接收 DNS 查詢的位址與連接埠，不是上游伺服器位址。一般系統 DNS 設定通常不能直接填入 1053 這類自訂連接埠。
• nameserver 是 DNS 上游伺服器。範例使用一般 DNS，是否能連線，以及解析結果是否適合目前的網路環境，都需要依實際情況判斷。
• enhanced-mode: fake-ip 會在適用情況下由核心回傳虛擬位址，並記錄網域對應關係；這些位址不是網站實際的公網 IP。
• fake-ip-filter 用來指定不採用 Fake-IP 回應的網域範圍，可用於處理區域網路名稱或特定相容性需求。

使用 TUN 時，還需要透過用戶端或設定中的 DNS 劫持、路由接管等功能，將請求導入核心。單寫 dns.enable: true 不會自動修改系統路由；只啟用系統代理，也不保證所有應用程式的 DNS 查詢都會交由核心處理。應用程式內建的加密 DNS 也可能使用自己的解析通道。

若將上游改為網域格式的 DoH 位址，例如 https://dns.alidns.com/dns-query，就要考慮上游網域本身如何解析。mihomo 的 default-nameserver 可用於這類引導解析；proxy-server-nameserver 則用來解析代理節點的網域。兩者用途不同，請勿混為一談；不了解連線路徑時，也不要同時疊加多層 DNS 轉送。

proxies：節點定義與訂閱檔注意事項

proxies 是由節點物件組成的清單。每個節點通常包含 name、type、server、port，其他驗證與傳輸欄位則視使用的協定而定。節點的遠端連接埠可能是 443，也可能是服務端指定的其他值；不能因為本機代理監聽 7890，就把節點連接埠也改成 7890。

編輯節點時，依欄位來源逐一檢查

1. 先確認 type 與服務端使用的協定一致。支援哪些協定取決於核心版本；能匯入設定檔，不代表每種協定都能成功建立連線。
2. 伺服器位址、密碼、UUID、加密方式等連線參數，應以服務提供者提供的設定為準，不要只憑欄位名稱猜測。
3. 傳輸層、TLS 與憑證名稱都必須與服務端設定一致。遇到憑證錯誤時，應先確認網域名稱與系統時間，不要直接關閉憑證驗證。
4. name 建議設定為唯一值。策略組會依名稱引用節點；重新命名節點後，也要同步修改相關引用。

沒有節點也能建立合法設定：proxies: [] 代表空清單。這適合用來檢查檔案結構，但不會自動產生代理出口。下方的完整範例使用空清單與 DIRECT，因此僅用於確認設定載入與規則關係。

proxy-groups：名稱引用與策略選擇

策略組會將節點、內建策略或其他策略組整理成可供引用的出口。以下定義一個手動選擇組，僅包含直連與拒絕兩個內建成員，不需要任何節點驗證資料：

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - DIRECT
      - REJECT

type: select 表示手動選擇成員。在用戶端的代理頁面選取 DIRECT 後，引用「出口選擇」的規則會採用直連；選取 REJECT 後，對應連線則會遭到拒絕。這不代表規則消失，而是同一個規則目標的實際行為會隨著組內選擇而改變。

三種常見策略組

自動測試結果反映的是連線到指定測試位址的測量值，不等於所有網站的實際下載速度。若只是要了解架構，先用 select 確認引用關係會更直接。需要巢狀策略組時，也要避免 A 引用 B、B 又引用 A 的循環依賴。

若設定使用 proxy-providers，策略組通常會透過 use 引用提供者名稱，而不是將提供者名稱放進 proxies 清單。兩個欄位指向的物件不同；遇到「找不到代理」時，應先確認引用的是節點、策略組，還是節點提供者。

rules：先比對具體規則，再設定預設規則

在規則模式下，連線會依清單順序比對；符合適用規則後，就會使用該規則指定的目標。設定中的策略名稱必須與前面定義的名稱完全相同，包括大小寫、空格與中文字元。以下四條規則分別處理區域網路網域、範例網域、私有位址與其他連線：

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選擇

• DOMAIN-SUFFIX,lan,DIRECT 會比對 lan 及其子網域，不會比對任意包含「lan」的字串。
• DOMAIN-SUFFIX,example.org,出口選擇 會將範例網域及其子網域交由「出口選擇」處理。example.org 僅用於說明規則語法。
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 會比對這個私有 IPv4 網段；no-resolve 表示不會為了比對此規則而主動解析網域。
• MATCH,出口選擇 用來處理前面都未比對成功的連線，應放在清單最後。

no-resolve 不會停用整份設定的 DNS，也不代表連線過程絕不進行解析。它只會影響相關 IP 類規則是否主動觸發解析。已取得目標 IP 的連線仍可進行 IP 比對。

若將 MATCH,DIRECT 放在第一行，後續規則就無法再處理已被它接收的連線。需要設定更精確的網域例外時，應將例外規則放在範圍較廣的後綴規則之前。使用 GEOIP、GEOSITE 或 RULE-SET 時，也要確認對應的地理資料庫或規則提供者可正常使用；不要只複製規則，卻忽略資料來源。

完整架構：兩格縮排與最小設定

以下設定不包含外部節點，預設會將符合條件的流量交給僅有 DIRECT 成員的策略組。適合先確認 YAML 結構、監聽連接埠與組名引用；這不是能直接取得遠端代理能力的訂閱，也沒有啟用 TUN。核心 DNS 會在 127.0.0.1:1053 監聽，但仍須額外設定系統或用戶端，才能接收系統 DNS 查詢。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

proxies: []

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

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選擇

YAML 四種常見錯誤

1. 使用 Tab 縮排。請統一使用空格；上例每一層增加兩格，同一層的欄位必須對齊。
2. 將頂層欄位縮排到上一個區段底下。proxies、proxy-groups 與 rules 都必須從行首開始，不能縮排到 dns 底下。
3. 漏掉清單項目前的短橫線。nameserver、策略組成員與規則都使用清單格式，每個獨立項目都要以 - 開頭。
4. 重複定義相同的頂層鍵。不要在檔案結尾再新增第二個 dns 區段或第二個 rules；應合併到原本的位置，避免不同解析器對重複鍵採取不同處理方式。

名稱中含有 #、冒號後接空格等特殊內容時，應使用引號，避免被解析為註解或映射語法。一般規則字串不必為了中文字元額外加引號，但用標準引號括住整條字串也可以。不要把網頁上的全形冒號「：」當成 YAML 半形冒號 :。

載入驗證：從語法檢查到實際連線

設定成功儲存，只代表編輯器已將內容寫入檔案；核心能載入，也只代表結構與必要欄位通過檢查。節點能否連線、DNS 是否依預期路徑處理，以及應用程式是否使用代理，都需要分別驗證。

建議依四個步驟檢查

1. 先備份目前可用的檔案，複製一份獨立的 config.yaml 再進行編輯；每次只修改一個設定區段，方便復原。
2. 使用目前實際執行的 mihomo 二進位檔測試設定。在 Linux 或 macOS 中，若二進位檔位於目前目錄，可執行下方指令。
3. 在用戶端重新載入或啟用設定，查看記錄中是否出現連接埠遭占用、找不到名稱引用或規則資料缺失等錯誤。
4. 先明確指定代理並測試連線入口，再查看用戶端連線記錄中的規則與策略鏈，最後才驗證系統代理或 TUN 的全域接管效果。

./mihomo -t -f ./config.yaml

curl --proxy http://127.0.0.1:7890 --head https://example.org/

若設定依賴相對路徑的規則檔、節點提供者或資料庫，測試時也要使用與實際執行環境相同的工作目錄；可透過核心的 -d 參數指定設定工作目錄。若找不到指令，應先確認二進位檔路徑，而不是修改 YAML 欄位。上方的 curl 請求只能驗證指定的 HTTP 代理入口與目標連線，無法證明 UDP、系統 DNS 或 TUN 已正常運作。