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

1. 設定檔結構與實際生效順序

config.yaml 描述連線入口、網域名稱解析、可用出口及出口選擇規則。閱讀時可以沿著「應用程式流量 → 本機連接埠或 TUN → 規則比對 → 策略群組 → 節點或直連」的順序理解。DNS 負責支援網域解析，但並非所有連線都一定先經過同一條 DNS 路徑。

本文依常見的檔案排列順序說明。YAML 頂層欄位通常可以調整位置，dns 寫在 rules 前面，不代表它的優先級高於規則；真正需要依序排列的是 rules 裡的規則清單。協定支援與部分欄位則取決於核心，傳統 Clash 與 Clash Meta（現名 mihomo）的設定能力並不完全相同。

頂層對應：dns:、proxies: 等欄位從行首開始。
巢狀縮排：建議每層縮排 2 個空格，不要使用 Tab；清單項目前保留 - 。
名稱引用：策略群組名稱與節點名稱必須完全相符，大小寫及空格都要一致。
用戶端處理：訂閱、覆寫、合併腳本與介面開關可能共同產生執行中的設定；編輯磁碟上的某個 YAML 檔案，不一定會立即改變核心行為。

2. 連接埠、執行模式與控制介面

連接埠欄位指定用戶端在本機接收連線的位置，不是遠端節點的伺服器連接埠。以下以混合代理入口 7890 為例；這些數字僅供示範，實際設定請以執行中的設定與連接埠使用情況為準。

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

欄位	用途	使用須知
`port`	HTTP 代理入口	支援 HTTP 代理與 CONNECT 通道，不是網頁伺服器連接埠。
`socks-port`	SOCKS 代理入口	應用程式必須明確選擇 SOCKS 代理類型。
`mixed-port`	HTTP 與 SOCKS 共用入口	同一個監聽連接埠可接受兩種代理連線；設定應用程式時仍須選擇正確的協定。
`allow-lan`	是否允許區域網路連線	區域網路分享還取決於監聽位址、系統防火牆及存取驗證。
`mode`	執行模式	`rule` 依規則選擇出口，`global` 使用全域策略，`direct` 則採用直連。
`external-controller`	管理 API 監聽位址	用於查詢狀態及切換策略，不是應用程式的代理入口。

為什麼 7890 和 9090 不能混用

如果執行中的設定將 mixed-port 設為 7890，瀏覽器手動代理應填入主機 127.0.0.1、連接埠 7890。若另有 external-controller: 127.0.0.1:9090，其中的 9090 是管理 API；填入瀏覽器代理設定會造成連線失敗。

管理介面應優先綁定迴圈位址，並設定獨立的 secret。啟用區域網路代理時，也不要順手將管理介面公開至所有網路介面卡。系統代理通常由用戶端介面管理，單獨修改 mixed-port 無法保證所有應用程式都會自動改用新連接埠。

3. dns：解析伺服器、監聽位址與 Fake-IP

dns 區段負責管理核心的 DNS 功能。enable 控制是否啟用，listen 設定 DNS 監聽位址，nameserver 指定上游解析伺服器。DNS 監聽連接埠與 HTTP、SOCKS 連接埠屬於不同服務，不能將代理連接埠當成 DNS 伺服器連接埠使用。

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

此範例在迴圈位址的 1053 連接埠提供 DNS 服務，列出的 IP 上游使用一般 DNS，不代表採用加密解析。啟動監聽不會自動變更作業系統的 DNS；應用程式、系統解析流程或 TUN 的 DNS 劫持都需要另外設定。

Fake-IP 回傳的位址不等於真實伺服器位址

fake-ip 模式會從設定的位址範圍分配合成位址，核心會記錄位址與網域的對應關係，讓後續連線能依網域處理。若看到以 198.18. 開頭的解析結果，應先確認連線是否仍由核心接管，不能直接判定為遠端網站的真實 IP。

應用程式相容性：部分裝置探索、遊戲或依賴真實解析結果的應用程式，需要針對 fake-ip-filter 進行檢查；一開始不要加入範圍過大的萬用字元。
上游連線能力：先確認目前的網路可以連上所選 DNS。新增加密 DNS 時，也要考慮伺服器網域名稱的引導解析。
進階欄位：mihomo 的 respect-rules、proxy-server-nameserver 等欄位各有路由與解析用途，應依實際核心文件設定，避免混淆 DNS 請求的出口策略與一般流量規則。

排查時，可在支援指定連接埠的環境執行 dig @127.0.0.1 -p 1053 example.com，確認是否收到回應。此命令只檢查指定的 DNS 監聽是否有回應，無法單獨證明系統流量已由核心接管或節點可以連線。

4. proxies：節點定義與協定參數

proxies 是節點物件清單。每個物件通常包含 name、type、server 和 port，其他欄位則依協定而定。例如 Shadowsocks 使用 cipher、password；其他協定可能需要 UUID、TLS 或傳輸層參數，不能只修改 type 就完成協定轉換。

proxies:
  - name: "本機測試節點"
    type: ss
    server: 127.0.0.1
    port: 8388
    cipher: aes-128-gcm
    password: "local-demo-only"

分別確認節點名稱與伺服器位址

name 是供策略群組引用及介面顯示的識別名稱；server 才是連線目標。將「本機測試節點」改名後，也必須同步修改引用它的策略群組。節點中的 port: 8388 指向伺服器端，與本機入口 mixed-port: 7890 的數值無關。

包含冒號、井號或容易被解讀為布林值的字串，建議加上引號。認證資訊欄位也應以字串處理。分享設定或記錄檔時，請隱藏密碼、權杖與完整訂閱 URL；只修改節點顯示名稱，無法移除這些敏感資訊。

5. proxy-groups：規則與節點之間的策略層

proxy-groups 將節點或其他策略群組組成可供引用的出口。規則通常指向穩定的群組名稱，訂閱更新時再替換群組內的節點。如此一來，「哪些流量走這個出口」和「目前選用哪個節點」就能分開管理。

proxy-groups:
  - name: "手動出口"
    type: select
    proxies:
      - "本機測試節點"
      - DIRECT

select：由使用者或管理 API 選擇成員，適合明確指定出口。
url-test：依探測結果自動選擇成員；探測 URL、間隔與容差都會影響選擇結果，結果不等於實際下載速度。
fallback：依清單順序選用可用成員，適合主備切換，不會依延遲由低至高排序。
load-balance：依支援的分配策略為連線選擇成員，不會自動將一般連線的頻寬合併到多個節點。

上方清單引用了上一節定義的「本機測試節點」，以及內建出口 DIRECT。刪除該節點卻保留引用，會造成設定錯誤。群組可以引用其他群組，但要避免循環相依，例如 A 引用 B，而 B 又引用 A。

訂閱節點不一定會直接寫在 proxies 中

使用 proxy-providers 的設定可以從提供者載入節點，策略群組則透過 use 引用提供者名稱。因此，看到頂層的 proxies: []，不能立刻斷定沒有節點。還要檢查提供者是否載入成功、群組是否設定 use，以及介面是否套用了篩選條件。

6. rules：由上而下比對，符合後選擇出口

在 mode: rule 模式下，核心會依清單順序判斷規則，符合後便使用規則指定的策略。常見結構為「規則類型、比對內容、目標出口」；MATCH 不需要比對內容，通常放在最後處理尚未符合其他規則的連線。

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

規則	比對範圍	檢查重點
`DOMAIN`	完整網域名稱	`example.com` 不會自動涵蓋其子網域。
`DOMAIN-SUFFIX`	網域及其子網域	`example.org` 可涵蓋 `www.example.org`。
`IP-CIDR`	目標 IPv4 網段	`no-resolve` 可阻止此規則主動解析網域，不會停用所有 DNS。
`RULE-SET`	引用規則提供者	必須存在對應的 `rule-providers` 定義，且其中包含可用規則。
`MATCH`	其餘連線	若放在前面，後續規則就沒有比對機會。

「區域網路直連」不能只靠範例中的 192.168.0.0/16 涵蓋所有環境；實際網路也可能使用 10.0.0.0/8、172.16.0.0/12 或 IPv6 位址。請依本機網段與服務探索方式補充規則，不要將範例視為完整的規則集。

若將 MATCH,手動出口 移到第一行，後面的網域規則就不會執行。排查「規則已設定卻沒有生效」時，先確認目前使用規則模式，再檢查排在前面的規則與用戶端追加的覆寫內容，最後查看連線記錄中的命中規則及實際出口。

7. 最小完整範例與 TUN 的適用範圍

以下是用來確認結構的最小設定：啟用混合連接埠、核心 DNS 與規則模式，並保留一個只包含直連成員的策略群組。這份設定不提供遠端代理功能，適合先確認 YAML 是否能載入、連接埠是否正在監聽，以及群組名稱引用是否一致。

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

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

proxies: []

proxy-groups:
  - name: "手動出口"
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手動出口

TUN 負責接管流量入口，不會取代分流規則

TUN 透過虛擬網路介面接管流量，常用於不遵循系統代理設定的應用程式。TUN 不屬於 proxies，也不會自動修正錯誤的節點認證資訊。以支援相關欄位的 mihomo 為例，可在現有設定中另外加入以下片段；這不是所有傳統 Clash 核心都通用的設定。

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

實際啟用仍需要作業系統權限、可用的虛擬網卡支援及正確的路由設定。dns-hijack 用於處理進入此接管路徑的相關 DNS 流量，不代表所有應用程式內建的 HTTPS 加密 DNS 都會遭到攔截。若用戶端已透過介面管理 TUN，請先查看產生後的設定，避免在多處維護彼此衝突的設定。

8. 修改、驗證與還原順序

保留副本：匯出目前使用的 Profile，並記下所選的策略群組成員。分別備份訂閱原始檔與本機覆寫設定。
一次只修改一類設定：先修改連接埠並確認運作，再處理 DNS，最後調整節點、群組與規則。不要同時更換核心、啟用 TUN，又整套替換 DNS 設定。
檢查設定：若使用 mihomo 命令列，且設定檔位於目前目錄，可執行 mihomo -t -f ./config.yaml；其他核心請先使用 -h 確認可用選項。命令列檢查通過，不代表網路連線一定可用。
確認實際執行的設定：重新載入後查看記錄，確認沒有 YAML 解析失敗、節點引用不存在或監聽位址已被占用等錯誤。
逐層驗證：依序確認本機入口、DNS 回應、節點連線與規則命中。查看連線記錄時，也一併記下目標網域、命中規則、策略群組及最終選用的成員。
發生問題時還原：切回上一份可用的 Profile，恢復原本的系統代理或 TUN 開關，再逐一確認差異。不要連續匯入多份來源不明的設定，以免掩蓋最初的問題。

依錯誤狀況定位欄位

載入時顯示行號：先檢查縮排、引號、冒號與清單格式，再確認錯誤行的上一行是否缺少必要結構。
提示找不到代理或策略：確認 rules、proxy-groups 與 proxies 之間的名稱引用。
提示位址已被占用：檢查 7890、1053 等目前設定的連接埠，是否已被其他程序或另一個核心占用。
可以解析但無法連線：接著檢查節點伺服器、協定參數、目前選用的成員與對外網路，不要只是不斷修改 DNS。
手動修改在更新後消失：確認修改的檔案是否為訂閱快取檔，並將需要保留的設定移至用戶端支援的覆寫或合併機制。

閱讀設定時，先確認入口連接埠，再追蹤規則引用的群組及群組成員，最後分別檢查 DNS 與 TUN 的接入條件。理解這幾層關係後，才能分辨「檔案成功載入」、「規則已命中」和「連線確實可用」這三種不同結果。更多操作步驟請參閱進階設定，欄位說明可對照術語表。