Clash config.yaml 設定檔逐段解析：從連接埠設定到 rules 的閱讀順序

先確認核心與設定檔來源

config.yaml 是提供給代理核心讀取的設定檔。核心負責建立連線與執行分流；用戶端則提供匯入、切換設定檔及檢視記錄的介面。同一款用戶端可能會在載入前合併連接埠設定、覆寫規則等，因此編輯的檔案未必包含最後生效的所有設定。

本文主要介紹 mihomo（原 Clash Meta 核心）的常見欄位。傳統 Clash 與 mihomo 共用部分語法，但並非所有功能都能通用，尤其是 TUN、DNS 和較新的代理協定。請先在用戶端的「關於」或核心資訊頁確認核心名稱與版本，再參照相應文件；不要只看視窗上標示 Clash 就認定相容。

閱讀時掌握三個重點

• 流量入口：連接埠與 TUN 決定流量如何進入核心。
• 流量出口：proxies 定義連線，proxy-groups 則將連線組成可供選擇的策略群組。
• 流量分流：rules 依網域、IP 等條件，將連線交由特定策略群組或內建動作處理。

檔案由上而下的排列主要是為了方便閱讀。頂層的 rules 不必因為引用策略群組，就緊接在群組後面；真正重要的是名稱相符、欄位層級正確，以及規則清單的排列順序。

可供檢視結構的完整 config.yaml 範例

以下是一份用於閱讀與本機測試的 mihomo 設定檔。它沒有遠端代理節點，所有正常放行的連線都會直連，無法用來確認遠端代理是否可用。這樣安排是為了先釐清連接埠、DNS、策略群組與規則之間的關係，不讓無法連線的示範伺服器干擾判讀。

# 本機代理入口
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1

# 運作模式與記錄
mode: rule
log-level: info
ipv6: false

# 本機 DNS 服務
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

# 暫不啟用虛擬網卡接管流量
tun:
  enable: false

# 遠端代理節點清單為空
proxies: []

# 策略群組引用內建直連動作
proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - DIRECT

# 由上而下比對，最後一條作為兜底規則
rules:
  - DOMAIN-SUFFIX,example.com,出口選擇
  - 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,出口選擇

example.com 是保留的示範網域，僅用來展示網域規則。兩台 DNS 伺服器是實際的公共解析服務，不代表在所有網路環境中都能連線。載入前也請確認本機的 7890 和 1053 未被其他程式使用。

先看 YAML 縮排，再看欄位

YAML 透過縮排表示欄位的從屬關係。範例統一使用兩個空格，請避免使用 Tab。dns: 頂格書寫，enable: 比它多縮排一層，表示後者屬於 DNS 設定。清單項目前的 - 表示一個項目；[] 則代表空清單。

• 冒號後通常要加一個空格，例如 mode: rule。
• 同一層的欄位要維持相同縮排，不要把頂層的 rules: 縮排到策略群組內。
• 字串含有 # 等特殊字元時應加上引號，避免後面的內容被當成註解。
• 同一層不要重複定義 dns 或 rules；不同解析器可能會拒絕重複鍵，或只保留其中一份。

連接埠與模式：先讓應用程式連上正確入口

mixed-port: 7890 表示在同一個連接埠接受 HTTP 代理與 SOCKS5 代理連線。手動設定應用程式代理時，位址填入 127.0.0.1、連接埠填入 7890，再依應用程式提供的選項選擇協定。這裡的數字僅為範例，並非所有用戶端的固定預設值。

mode: rule 才是本文討論的規則模式。全域模式通常會將流量交由全域策略處理，直連模式則直接連線；在這兩種模式下，修改一般規則不會產生預期效果。若用戶端介面覆寫了模式，仍應以實際執行狀態為準。

log-level: info 適合日常檢視。需要排查問題時，可暫時改用 debug，重現問題後再改回來；詳細記錄可能包含瀏覽過的網域等資訊，分享前請先清除敏感內容。

DNS 與 TUN：分別檢視網域解析和流量接管

DNS 負責將網域名稱解析為 IP 位址。範例啟用核心的 DNS 服務，並監聽 127.0.0.1:1053；但這不代表作業系統的所有 DNS 查詢都會自動轉交給它。系統設定、用戶端整合方式及 TUN 接管都會影響實際流量路徑。

nameserver 與解析模式

nameserver 是用來解析網域的上游伺服器清單。範例中的純 IP 位址使用一般 DNS，沒有加密傳輸；若需要 DoH，也就是透過 HTTPS 傳送 DNS 查詢，請依目前核心支援的格式設定服務位址，並確認連線路徑及啟動時的解析需求。

enhanced-mode: redir-host 會在解析時回傳實際位址。另一種常見模式 fake-ip 則會回傳供應用程式使用的對應虛擬位址，再由核心將其連回網域；兩者並不是「速度等級」。切換模式後，舊的 DNS 快取與既有連線可能影響觀察結果，必要時請清除快取並重新啟動相關應用程式。

TUN 不是另一種代理節點

TUN 是虛擬網路介面，用來接收由系統路由導入的流量。範例只設定 tun.enable: false，因此未啟用這種流量接管方式。開啟系統代理不等於啟用 TUN：前者主要影響遵循系統代理設定的應用程式；後者則可在路由與權限設定正確時接收更多流量。

• 先在應用程式中手動設定代理 127.0.0.1:7890 並確認可用，再測試系統代理，最後才考慮啟用 TUN。
• 需要使用 TUN 時，請依用戶端與作業系統的要求設定系統管理員權限、虛擬介面與路由。
• dns-hijack 用來接管符合條件的 DNS 流量，但不一定能攔截所有加密 DNS；應用程式內建的 DoH 可能會透過其他連線傳送。
• 範例停用 IPv6 是為了縮小排查範圍，不應視為適用於所有網路的永久設定。

proxies 與策略群組：依名稱追蹤流量出口

proxies 是實際代理連線的清單。真實節點通常包含名稱、協定類型、伺服器、連接埠與驗證參數，不同協定也有各自的欄位。伺服器位址與密碼必須取自實際服務設定，不要混用不同協定的欄位來拼湊節點。

本例的 proxies: [] 明確表示沒有遠端節點。策略群組中的 DIRECT 是核心內建的直連動作，不需要在節點清單中另外宣告。同樣地，REJECT 是拒絕連線的內建動作。

select 只負責選擇，不會測速

proxy-groups 可將一個或多個出口組成群組。範例中的 type: select 表示手動選擇，群組名稱為「出口選擇」。日後加入實際節點時，必須將節點的正確名稱加入該群組的 proxies 清單，才能在群組中選取。

rules 中的「出口選擇」
        ↓ 名稱必須相符
proxy-groups 中 name 為「出口選擇」的群組
        ↓ 目前選取的項目
DIRECT，也就是直接連線至目標

url-test 才是依測試結果選擇出口的策略群組類型；它需要適當的測試網址與測試間隔。測得的延遲只代表連到特定目標時的觀察值，不等於下載頻寬，也不保證所有網站都能連線。

訂閱中也可能出現 proxy-providers，代表從檔案或遠端來源載入節點集合。策略群組通常透過 use 引用提供器名稱，而不是將提供器名稱當作單一節點放進 proxies。遇到這類設定時，請接著檢查來源、更新路徑與健康檢查設定。

rules：從第一條一路讀到 MATCH

規則通常依清單順序比對，第一條符合的規則會決定流量去向。因此，具體條件放前面，較寬泛的條件放後面，最後再放兜底規則。若把 MATCH 放在第一條，後續一般規則就無法處理新連線。

網域規則與 IP 規則要分開理解

DOMAIN 用於比對完整網域名稱，DOMAIN-SUFFIX 則用於比對網域及其子網域。規則中應填入網域名稱，而非完整網址；例如 https://example.com/path 含有協定與路徑，不能直接作為網域條件。

IP-CIDR 中的 CIDR 是以前綴長度表示 IP 範圍的格式。結尾的 no-resolve 表示不要為了檢查這條 IP 規則而主動觸發網域解析；若連線資訊已有目標 IP，仍可依此比對。它不是「停用整個 DNS」的開關。

範例只列出部分常見本機網段，並非完整的特殊位址規則。若無法連線到印表機、路由器或企業內網，請查看實際目標位址與規則命中記錄，不要假設所有內網都只使用 192.168.0.0/16。

遇到 RULE-SET 時，繼續追查規則提供器

RULE-SET 引用的是 rule-providers 中定義的規則集合，不是代理節點集合。必須一併確認提供器名稱、來源、格式與 behavior 類型；成功下載只代表取得內容，不代表內容格式一定符合目前設定。

載入前檢查與生效驗證

設定通過語法檢查，不代表網路運作已符合預期。建議分成「能讀取、能監聽、能比對、能連線」四個步驟驗證；每次只修改一個地方，出錯時才容易還原到上一個可用狀態。

1. 檢查檔案。將測試副本儲存為 UTF-8 編碼的 config.yaml，確認副檔名沒有變成 .yaml.txt。檢查縮排、重複鍵與策略名稱。
2. 驗證核心設定。使用用戶端提供的檢查功能；也可以在已安裝 mihomo 命令列程式的環境中執行下方測試命令。在 Windows 中，若程式位於目前目錄，通常需要寫成 .\mihomo.exe。
3. 載入並檢視記錄。確認沒有語法錯誤、找不到策略或連接埠遭占用等提示。若用戶端會改寫設定，也要檢視實際產生的設定內容。
4. 透過明確指定的入口送出請求。先明確指定代理連接埠，排除系統代理開關與瀏覽器設定造成的干擾。
5. 確認連線記錄。檢查測試連線命中的規則、策略群組與最終出口，再逐步啟用原本的 DNS 或 TUN 設定。

# 檢查設定；此命令不會正常啟動長時間執行的代理服務
mihomo -t -f ./config.yaml

# 設定載入且核心執行後，測試本機 HTTP 代理入口
curl --proxy http://127.0.0.1:7890 --head https://example.com

第二條命令測試的是從本機代理入口連到示範網站的路徑；本例最後使用 DIRECT，即使請求成功，也無法證明遠端代理節點可用。在 Windows 上，若終端機將 curl 解讀為其他命令，可明確使用已安裝的 curl.exe。

後續維護時，繼續依相同順序閱讀：入口參數、運作模式、DNS、流量接管、節點、策略群組、規則。需要進一步了解各欄位時，可參閱本站的 YAML 手冊；從匯入到啟用的操作流程則請看使用指南。保留一份已驗證可用的設定檔，比每次出錯後從頭重寫更省事。