Clash 進階設定手冊

設定分層與編輯入口

開始逐段調整參數之前，先弄清楚一份生效設定由哪些層組成。理解分層，才知道自己改的內容會不會被訂閱更新覆蓋，以及自訂內容該寫在哪一層。

四層設定的優先順序

Clash Verge 的執行期設定由四層疊加，由低到高依序是：

• 訂閱設定：從訂閱連結抓取的原始 YAML，或手動匯入的本機檔案。這一層由服務商或自己維護，客戶端每次更新訂閱都會用新內容整體替換。
• 本機設定：客戶端內建的基本片段，通常只提供連接埠、模式等欄位，可編輯但用途有限。
• 覆寫設定：對訂閱設定做增量修改的 YAML，支援 prepend / append 合併指令。訂閱更新後覆寫仍然生效，是長期使用中最重要的自訂層。
• 指令碼設定：一段 JavaScript，在合併完成後對最終設定做程式化修改，適合需要條件判斷或批次產生的情境。

執行期最終設定 = 訂閱 → 本機 → 覆寫 → 指令碼，後一層覆蓋前一層的同名鍵。看到「改了沒生效」時，先依這條鏈檢查是不是有更高層把值蓋回去了。

設定檔存放與備份

各平台預設路徑：

• Windows:%APPDATA%\clash-verge\profiles\
• macOS:~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
• Linux:~/.config/clash-verge/profiles/

每個訂閱對應一個以 UUID 命名的目錄，裡面的 config.yaml 是抓取後的原始內容，merge.yaml 與 script.js 分別是覆寫與指令碼。備份時複製整個 profiles 目錄即可。需要手動調整時，建議在「設定」頁選擇對應訂閱，點「編輯」進入覆寫或指令碼，而不是直接改抓下來的 config.yaml——下次更新訂閱會把直接修改沖掉。

通用欄位速查

以下欄位由 mihomo 核心直接讀取，寫在設定頂層，任何訂閱都會用到：

設定範例 · 頂層通用欄位

port: 7890              # HTTP 代理連接埠
socks-port: 7891        # SOCKS5 代理連接埠
allow-lan: false        # 是否允許區網裝置連線
mode: rule              # rule / global / direct
log-level: info         # silent / error / warning / info / debug
ipv6: false             # 是否處理 IPv6 流量
external-controller: 127.0.0.1:9090
secret: ""              # 控制 API 存取權杖

• mode: rule 依規則分流；global 全部走代理；direct 全部直連。日常保持 rule。
• log-level 調成 debug 時，日誌會顯示每條連線命中的規則，排錯很好用，排完記得改回 info。
• allow-lan 開啟後，同一區網的手機、平板可以手動設定代理指向這台電腦，前提是系統防火牆放行對應連接埠。

編輯與驗證

編輯完 YAML 後，先點「設定」頁的偵錯按鈕，或直接看日誌視窗有沒有解析錯誤。常見錯誤三類：縮排用了 Tab（必須用空格）、冒號後少了空格、引號沒有閉合。mihomo 的報錯會精確到行號，按行號回查即可。整份設定的逐段結構，可以對照《Clash 設定檔 YAML 結構逐段解析》閱讀。

策略組類型與實戰

策略組（proxy-groups）決定一組節點以什麼邏輯被選中。規則最終指向的往往不是單一節點，而是一個策略組；把組設定好，規則層就簡單了。

五種內建類型

select：手動選擇，面板裡點哪個用哪個，適合「主力節點」這類需要隨時切換的組。

設定範例 · select 組

- name: 主力
  type: select
  proxies:
    - 香港 01
    - 日本 01
    - 直連

url-test：自動測速，定時對所有成員發起測試請求，選中延遲最低的節點。interval 是測速間隔（秒），tolerance 是容差（毫秒）——兩個節點延遲差小於容差時保持目前節點，避免來回橫跳。

fallback：依列表順序使用，目前節點不可用時自動切到下一個。適合「首選某條線路，掛了才換」的情境。

load-balance：負載平衡，把連線分散到多個節點。strategy 支援 consistent-hashing（同一網域固定到同一節點，相容性最好）、round-robin（輪流）、sticky（工作階段保持）。下載、大流量情境用這個組可以跑滿多線。

relay：鏈路代理，流量依組內順序經過每一站，常用於「落地」組合。relay 對協定支援有限，部分機場節點不支援鏈式轉發，啟用前先在面板裡逐站驗證。

特殊組與巢狀

DIRECT 與 REJECT 不是策略組，但可以出現在 proxies 列表裡，分別表示直連與拒絕。策略組可以巢狀：外層組引用內層組，規則只需指向最外層。mihomo 還支援 include-all: true 自動包含設定裡所有節點，以及 include-other-group 引用其他組的成員。訂閱節點經常變動時，用這兩個參數可以少維護很多。

一組實戰範本

設定範例 · 串流 / 遊戲 / 下載三組範本

proxy-groups:
  - name: 串流
    type: url-test
    proxies: [香港 01, 香港 02, 日本 01]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 遊戲
    type: fallback
    proxies: [香港 01, 日本 01, 直連]
  - name: 下載
    type: load-balance
    proxies: [香港 01, 香港 02]
    strategy: consistent-hashing
  - name: 主力
    type: select
    proxies: [串流, 遊戲, 下載, 直連]

• 串流組用 url-test 自動挑最快線路，tolerance 給 50ms，防止延遲差幾毫秒就切換導致播放中斷。
• 遊戲組用 fallback：首選線路延遲升高但沒斷時 url-test 會切走，fallback 只在真正不可用時才切換，對長連線更友善。
• 測試 URL 用 http://www.gstatic.com/generate_204，它回傳 204 不產生流量；連不上就換成 http://cp.cloudflare.com/generate_204。

常見誤區

• tolerance 設成 0：延遲差 1ms 就切換，短連線情境會頻繁斷線。
• select 組裡堆幾十個節點：面板選擇列表會很長，建議用自動組承接節點，select 只引用組。
• 忽略預設開啟的 lazy：首選項不會立刻測速，面板顯示的延遲是佔位；需要立即看數值就手動點測速。
• 組名大小寫不一致：規則裡引用組名是大小寫敏感的，寫錯不會報錯，流量會掉進兜底策略。

規則集訂閱化管理

規則（rules）是設定裡最容易膨脹的部分。幾百條規則寫進主設定，既難讀，又會跟著訂閱更新被覆蓋。規則集（rule-providers）把規則拆成獨立檔案，單獨更新，主設定只保留引用。

規則集的三種行為

behavior 決定規則集如何被解析：

• domain：內容是網域列表，每行一個網域，+ 開頭表示後綴符合。適合自維護的網站清單。
• ipcidr：內容是 IP 或 CIDR 區段，用於 IP 規則。
• classical：完整規則語法，每行一條 DOMAIN,xxx,策略 或 IP-CIDR,1.2.3.0/24,策略，最彈性。

遠端與本機規則集

設定範例 · rule-providers 兩種來源

rule-providers:
  geosite:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/geosite.yaml"
    path: ./rules/geosite.yaml
    interval: 86400
  my-custom:
    type: file
    behavior: classical
    format: text
    path: ./rules/custom.txt

• type: http 表示遠端抓取，interval 是自動更新間隔（秒），86400 即每天一次。path 是本機快取路徑，抓取失敗時核心會用快取繼續運作。
• type: file 表示本機檔案，適合自己維護的規則，不參與遠端更新。
• format: yaml 時內容要寫成 YAML 列表；format: text 時每行一條，更接近純文字習慣。

在 rules 中引用

設定範例 · RULE-SET 引用

rules:
  - RULE-SET,geosite,串流
  - RULE-SET,my-custom,直連
  - MATCH,主力

RULE-SET 第一個參數是規則集名稱，第二個參數是命中的策略組。規則集內部如果是 classical 行為且每條規則自帶策略，第二個參數可以省略。

更新與維護

• 遠端規則集在「訂閱」頁可以單獨點更新，也可以等 interval 到期自動更新。
• 訂閱更新不會碰規則集：規則集是獨立檔案，這正是把規則從主設定拆出來的核心好處。
• 規則集檔案裡不要寫列表之外的額外內容，format: yaml 模式下頂層必須是列表，格式寫錯會導致整個規則集載入失敗，對應規則全部失效，流量掉進兜底策略。
• 判斷規則集是否生效：日誌視窗搜 rule-provider 能看到載入與更新紀錄；debug 日誌能看到每條連線命中的規則。

分流思路

常見做法是「網域規則集 + IP 規則集 + 兜底」三層：先把廣告、追蹤網域 REJECT，再把串流網域指向串流組，接著把國內網域直連，最後 MATCH 走主力組。mihomo 依從上到下的順序比對，第一條命中的規則生效，所以 REJECT 與直連規則要放在前面。

DNS 設定最佳化

DNS 是分流品質的分水嶺。網域解析結果直接決定連線走代理還是直連，設定不當會出現「該走代理的走了直連」「DNS 洩漏」和「解析逾時」三類問題。

dns 區段基礎結構

設定範例 · 國內 DoH 主解析 + 國外 DoH 兜底

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geosite: geolocation-!cn

• default-nameserver 只用於解析 DNS 伺服器自身的網域，必須寫 IP 位址，否則啟動時會先卡在 DNS 解析。
• nameserver 是主解析通道，國內 DoH（阿里、騰訊）速度快，國內網域解析準確。
• fallback 是備用通道，當主通道回傳的結果被 fallback-filter 判定為異常時使用。geoip: true 配 geosite: geolocation-!cn 的含義是：nameserver 回傳的 IP 屬於國外、而網域不是國內網域時，改用 fallback 重新解析，這是防止國內 DNS 污染國外網域解析的標準做法。
• ipv6: false 時，即使系統有 IPv6，mihomo 也只請求 A 紀錄；需要 IPv6 出口再開啟。

enhanced-mode 怎麼選

fake-ip：網域不真實解析，直接對應到 fake-ip-range（預設 198.18.0.1/16）裡的虛擬 IP。應用程式連線虛擬 IP，核心在轉發時還原網域做規則比對。速度快、防 DNS 洩漏，是 TUN 模式下的推薦選擇。

redir-host：真實解析後回傳結果，規則比對用真實 IP。相容性更穩，但每次連線都要等解析完成，且結果可能被污染。

劫持與快取

dns-hijack 在 tun 區段設定，把發往 53 連接埠的 DNS 請求劫持到核心自己的 DNS 服務：

設定範例 · DNS 劫持與快取

tun:
  dns-hijack:
    - any:53

cache:
  enabled: true
  size: 4096
  ttl: 300

cache 區段快取解析結果，減少重複查詢。ttl 是快取秒數：太短快取沒意義，太長網域換 IP 後延遲會變大，300 秒是常用值。

排錯分支

• 開啟網頁常要等幾秒才載入：檢查 nameserver 是否用了 DoH，以及網路能否直連 DoH 伺服器；某些網路環境連國外 DoH 不穩，把備選 DoH 放進 nameserver 列表。
• 國內網站解析成國外 IP：fallback-filter 的 geosite 規則沒生效，確認核心能抓到 geosite 資料來源，或手動指定 geox-url。
• 訂閱自帶的 dns 區段與覆寫衝突：在覆寫裡整段覆蓋 dns 鍵，不要逐欄位合併。

TUN 模式與 Fake-IP

系統代理只接管「主動讀取代理設定」的應用程式，命令列工具、遊戲、UDP 流量常常繞開它。TUN 模式在系統裡建立一張虛擬網卡，把全部 IP 流量拉進核心，是「全域接管」的正解；Fake-IP 則是 TUN 模式下 DNS 與規則比對的搭檔。

系統代理與 TUN 的差異

系統代理透過修改系統設定告訴應用程式「把流量送到 127.0.0.1:7890」，應用程式不讀這個設定就失效。TUN 模式運作在 IP 層，虛擬網卡收到所有對外 IP 封包，不依賴應用程式配合。差異直接表現在：

• 命令列工具、curl、git 預設不讀系統代理，TUN 模式下無需逐個 export。
• 遊戲與 UDP 應用程式，系統代理基本無能為力，TUN 可以接管。
• TUN 接管的是 IP 封包，應用程式先發 DNS 查詢再建立 TCP 連線，所以 TUN 必須配合 DNS 劫持，否則網域解析仍走系統 DNS，規則比對拿不到網域。

tun 區段完整設定

設定範例 · tun 區段

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

• stack：封包處理堆疊。system 相容性最好但效能一般；gvisor 效能好、資源占用低，但部分舊系統不相容；mixed 讓核心依平台自動選擇，新版建議先用它。
• auto-route：自動新增路由，讓虛擬網卡接管預設路由，必須開著。
• auto-detect-interface：自動偵測對外網卡，多網卡（有線 + 無線 + 虛擬機）環境建議開啟，否則可能選錯對外介面導致斷網。
• strict-route：Windows 上開啟後嚴格接管路由表，能防止「部分流量漏出」，但也更容易與 VPN、虛擬網卡衝突，排錯時可先關掉試試。

Fake-IP 運作機制

開啟 enhanced-mode: fake-ip 後，核心收到網域解析請求，不向真實 DNS 查詢，而是從 fake-ip-range（預設 198.18.0.1/16）裡回傳一個虛擬 IP，並把「網域 ↔ 虛擬 IP」的對應記在記憶體裡。應用程式連線虛擬 IP 時，核心依對應還原網域，再走規則比對。好處有兩個：解析不再等待真實 DNS 往返，建立連線更快；規則比對始終基於網域，不會被 IP 污染帶偏。

fake-ip-filter 用於排除不需要虛擬 IP 的網域，常見的是本機服務、需要真實 IP 直連的網站：

設定範例 · fake-ip 範圍與過濾

dns:
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*"

各平台注意事項

• Windows：需要以服務模式執行，安裝時勾選「安裝服務」，或之後在設定裡開啟服務模式；系統防火牆要放行核心程序。
• macOS：開啟 TUN 需要管理員授權，首次啟用會跳出密碼框；系統更新後授權可能失效，重新開關一次 TUN 即可。
• Linux：需要 cap_net_admin 權限，以一般使用者執行時確保二進位檔有對應 capability，或用 systemd 服務啟動。
• Android：Clash Meta for Android 等客戶端同樣支援 TUN，需要系統 VPN 權限，與系統代理是互斥的兩種運作方式。

排錯分支

• 開啟 TUN 後完全斷網：先關 strict-route，再換 stack: system，檢查 auto-detect-interface 是否選中正確的網卡。
• 能上國內但國外逾時：TUN 與 DNS 劫持配合出了問題，確認 tun 區段有 dns-hijack: [any:53] 且 dns.enable 為 true。
• 某些應用程式連線被重置：應用程式可能驗證了目標 IP，把該網域加入 fake-ip-filter 讓它走真實解析。

網域嗅探

TUN 模式接管的是 IP 封包，當應用程式直接連線 IP、或連線的是已解析過的位址時，核心拿不到網域，規則比對只能靠 IP。網域嗅探（sniffing）從連線內容裡把網域「認」出來，補上這一環。

什麼情境需要嗅探

• 應用程式自帶 DNS 解析（部分遊戲客戶端、某些 App 直連 IP）：流量到達 TUN 時只有 IP，沒有網域。
• QUIC / HTTP3 連線：UDP 流量沒有傳統 DNS 查詢可劫持。
• 連線重用：同一 TCP 連線上後續請求沒有再發 DNS，規則只能依 IP 比對。

設定範例

設定範例 · sniffing 區段

sniffing:
  enable: true
  override-destination: false
  force-doman: true
  parse-pure-ip: true
  skip-dest-address:
    - 192.168.0.0/16
    - 198.18.0.1/16

• enable：總開關。
• override-destination：嗅探到網域後，是否把連線目標改寫為網域。開啟後規則比對更準確，但部分協定（如 QUIC）不支援改寫，建議保持 false，讓核心只在能安全改寫時才改。
• force-doman：強制規則比對使用嗅探到的網域，即使設定裡寫的是 IP 規則。
• parse-pure-ip：對純 IP 連線也嘗試解析出網域（透過 TLS SNI 等欄位）。
• skip-dest-address：跳過不需要嗅探的目標網段，通常把內網段與 fake-ip-range 排除，避免對虛擬 IP 做無意義的嗅探。

嗅探與規則比對的順序

連線進入後的比對順序是：先看連線是否命中 Fake-IP 對應（有網域直接用網域），再看是否被 skip 跳過，然後嘗試嗅探，嗅探出網域後依「網域規則 → IP 規則 → 兜底」的順序比對。因此，DOMAIN 開頭的規則在嗅探開啟後涵蓋範圍會變廣；IP 規則仍然有效，但排在網域規則之後。

注意事項

• 嗅探只讀取連線前幾個封包，對效能影響很小；但 override-destination 開啟後，部分應用程式會因目標位址被改寫而報錯，遇到「某個 App 開了 TUN 就連不上」時，優先關掉這一項。
• 非 TLS 的明文 HTTP 流量能嗅探 Host 標頭；TLS 流量讀取 SNI；QUIC 流量讀取 CHLO 中的 SNI，但 UDP 工作階段沒有穩定的「連線」概念，部分實作會限制嗅探範圍。
• 與 Fake-IP 的關係：Fake-IP 在 DNS 層已經拿到網域，嗅探主要補「沒走 DNS 劫持」的流量。兩者同時開啟不是重複勞動，而是涵蓋不同入口。

本機覆寫與多訂閱合併

直接改訂閱抓下來的設定，更新一次就全部遺失。覆寫（merge）是 Clash Verge 提供的增量修改層：訂閱更新後，覆寫裡的改動自動重新套用。多訂閱並存時，覆寫還能把不同訂閱的節點合併進同一個策略組。

覆寫語法

覆寫檔案本身是 YAML，支援兩類指令：

• 覆蓋鍵：直接寫目標鍵和值，替換訂閱裡的同名鍵。DNS、TUN 這類整段重寫的情境用覆蓋。
• 追加指令：prepend- 與 append- 前綴的鍵，把內容插到訂閱對應列表的前面或後面。支援 prepend-proxies、append-proxies、prepend-proxy-groups、append-proxy-groups、prepend-rules、append-rules 等。

設定範例 · 追加指令

prepend-rules:
  - DOMAIN-SUFFIX,company.com,直連
append-rules:
  - GEOIP,CN,直連
  - MATCH,主力
prepend-proxy-groups:
  - name: 工作
    type: select
    proxies:
      - 公司專線
      - 主力

一個完整的覆寫範例

設定範例 · 合併節點 + 自訂規則 + 固定 DNS

# 覆寫：合併兩個訂閱的節點，追加自訂規則，固定 DNS
prepend-proxy-groups:
  - name: 全部節點
    type: select
    proxies:
      - 訂閱A節點
      - 訂閱B節點
      - 直連
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,直連
  - RULE-SET,my-custom,主力
append-rules:
  - MATCH,全部節點
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

注意：覆寫裡寫 dns 鍵會整體替換訂閱的 dns 區段。想保留訂閱的 DNS 又只改一處，要嘛把訂閱的完整 dns 區段複製過來改，要嘛用 prepend-dns/append-dns 對列表追加——但 dns 區段的欄位是巢狀物件，追加指令只對列表生效，最穩妥的做法是整段覆蓋。

多訂閱合併

• 在「設定」頁新增多個訂閱，每個訂閱獨立更新，互不干擾。
• 用「全部節點」這類策略組把多個訂閱的節點收進來，透過 include-all 或覆寫裡的 proxies 引用組名。
• 切換訂閱時，目前生效的 profile 整體切換，覆寫與指令碼始終疊加在「目前訂閱」之上，所以覆寫裡引用節點名時，要保證每個訂閱裡都存在同名節點，否則策略組會引用空成員。
• 指令碼模式（script.js）適合更複雜的合併邏輯：例如依訂閱名稱前綴自動分組、過濾掉名稱含「過期」的節點。指令碼在覆寫之後執行，接收 config 物件，回傳修改後的物件。

維護建議

• 覆寫內容依用途分區，用註解標出「規則」「策略組」「DNS」，半年後再看也一眼能懂。
• 每次更新訂閱後，先看日誌有沒有 merge 失敗類提示，確認覆寫語法沒被訂閱內容衝突。
• 規則優先用法則集管理，覆寫只放少量個人化規則，避免覆寫本身膨脹成第二份主設定。

外部控制面板

日常切節點、看連線，客戶端介面夠用；但要批次操作、看規則命中、遠端管理，就要用 mihomo 的外部控制 API。面板透過 HTTP 與核心對話，設定好 external-controller 就能用。

基礎設定

設定範例 · 外部控制監聽與權杖

external-controller: 127.0.0.1:9090
secret: "your-long-random-token"

• external-controller 格式是「位址:連接埠」。只在本機存取就寫 127.0.0.1:9090；想從區網存取，改成 0.0.0.0:9090 並設定好防火牆，但不要直接暴露到公網——面板能切換代理、讀取連線資訊，裸奔的公網連接埠等於把代理控制權交給任何人。
• secret 是存取權杖，面板和 API 請求都要帶。用夠長的隨機字串；Verge 的設定頁也能產生並儲存 secret。
• 修改 external-controller 或 secret 後需要重新啟動核心才生效。

常用面板

mihomo 官方倉庫提供 Yacd、MetaXD 等面板，建置後放在核心同目錄的 ui 資料夾，瀏覽器存取 http://127.0.0.1:9090/ui 即可開啟。面板首次開啟會要你填後端位址與 secret。Verge 的「設定 → 外部控制」裡也有面板入口，開啟就能用。

REST API 常用端點

呼叫範例 · curl 讀取與切換

curl -H "Authorization: Bearer your-long-random-token" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer your-long-random-token" \
  -d '{"name":"香港 01"}' \
  http://127.0.0.1:9090/proxies/主力

• 用 GET /connections 排查「這條連線為什麼走了直連」：回傳裡帶 rule 與 rulePayload 欄位，直接顯示命中的規則。
• PUT /configs 適合快速切模式：{"mode":"global"} 暫時全域代理，用完切回 rule。
• 所有介面都要求 Authorization 標頭，格式為 Bearer <secret>。

安全建議

• 面板與 API 只監聽回環位址，或透過 SSH 隧道存取區網外的機器。
• secret 不要寫進會被同步的筆記，也不要在命令列歷史裡反覆明文出現；用環境變數或客戶端內建的 secret 管理。
• 定期用 GET /configs 檢查 mode 是否被改過——如果發現 mode 被改成 global 且不是你改的，先懷疑連接埠暴露，再更換 secret。