Clash 設定檔參考

CHAPTER 01

YAML 結構總覽

設定檔如何被讀取

Clash 設定檔本質上是一份 YAML 文件。核心啟動時會先解析語法，再讀取監聽連接埠、DNS、代理節點、策略組與規則等頂層欄位，最後建立本機代理入口與流量比對鏈。語法階段失敗時，用戶端通常無法進入可用狀態；語法通過但欄位關係錯誤時，則可能出現可以啟動、卻沒有可選節點或規則無法命中的情況。因此排查設定不能只看檔案能否開啟，還要依序確認 YAML 語法、欄位名稱、物件參照與執行環境。

常見頂層結構包括 port、socks-port、mixed-port、mode、log-level、dns、proxies、proxy-groups、rules、proxy-providers 與 rule-providers。並非每份設定都必須同時包含所有欄位。例如只使用 mixed-port 時，可以不另外設定 HTTP 與 SOCKS 連接埠；節點由遠端提供器載入時，proxies 可以是空的，但策略組必須透過 use 參照對應的提供器。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,節點選擇

上面的範例展示了最短的完整鏈路：本機程式連接 7890 連接埠，DNS 模組處理網域解析，proxies 定義一個出口，proxy-groups 將出口組織成可選擇的策略，rules 決定流量交給哪個策略。實際訂閱通常會包含更多節點與規則，但關係仍然是「入口—解析—出口—策略—比對」。理解這條鏈路後，遇到連線失敗時就能判斷問題屬於哪一層。

縮排、清單與資料型別

YAML 以縮排表示層級，建議統一使用兩個半形空格，不要使用 Tab。冒號後需要保留一個空格；清單項目以短橫線與空格開頭；同層欄位必須保持相同縮排。dns 是映射物件，內部欄位比它多縮排一級；nameserver 是清單，清單中的每個位址再多縮排一級。若將 enable 與 nameserver 錯誤縮排到不同層級，解析器可能直接報錯，也可能將內容解讀成與預期不同的結構。

布林值宜使用 true 與 false，連接埠寫成整數，名稱與位址寫成字串。內容包含冒號、井字號、逗號或容易被辨識為布林值時，使用引號更穩妥。例如密碼中出現井字號，未加引號時井字號後的部分會被當成註解；節點名稱寫成 on、off 等詞時，不同 YAML 解析器可能採用不同解讀。對於訂閱連結、正規表示式與複雜密碼，建議使用單引號；若字串需要跳脫字元，再使用雙引號。

名稱參照必須完全一致

策略組與規則會透過名稱參照其他物件，名稱會區分全形、半形、空格與大小寫。節點名稱是「香港 01」，策略組中寫成「香港01」就不是同一個物件；規則末尾寫「節點選擇」，但設定中只有「代理選擇」，也會形成懸空參照。修改訂閱時不要只改定義處，應同時搜尋所有參照。也要避免節點重名，因為介面可能只顯示一個名稱，難以判斷實際選中哪一項。

YAML 允許註解，但註解只適合說明欄位用途，不宜用來暫存大段失效設定。被註解的節點仍可能被策略組參照，刪除節點卻忘記清理參照也是常見錯誤。較穩妥的維護方式是保留一份基礎設定，將實驗欄位放在獨立副本中，確認能夠載入後再移入常用設定。使用 Clash Plus、Clash Verge Rev、FlClash 等圖形用戶端時，也可以先在用戶端內執行設定檢查，再切換為目前設定。用戶端入口與平台說明請見取得用戶端。

CHAPTER 02

通用欄位、連接埠與運作模式

本機監聽連接埠

port 提供 HTTP 代理入口，socks-port 提供 SOCKS5 入口，mixed-port 則在同一個連接埠接受 HTTP 與 SOCKS 請求。多數桌面環境只需要設定 mixed-port，再讓用戶端的系統代理功能將作業系統代理位址指向該連接埠。若某個開發工具只接受 SOCKS5，可以單獨啟用 socks-port；同時啟用多個欄位時，連接埠號碼必須不同，也不能與其他本機程式占用的連接埠重複。

port: 7890
socks-port: 7891
mixed-port: 7892
redir-port: 7893
tproxy-port: 7894

redir-port 與 tproxy-port 主要用於 Linux 路由轉送或透明代理。它們不是一般桌面軟體設定系統代理所必需的欄位，單獨寫入設定也不會自動建立防火牆與路由規則。使用透明代理時，還要在系統層設定流量轉送、策略路由與權限；如果目標是讓不遵循系統代理的程式也進入 Clash，通常應先了解 TUN 模式。相關原理與設定步驟可參考Clash TUN 模式啟用方法。

區域網路存取與監聽位址

allow-lan 決定其他裝置能否連線到目前裝置上的代理連接埠。設為 false 時，本機應用程式仍可使用代理，但區域網路中的手機、電視或另一台電腦不能將這裡當作代理伺服器。設為 true 後，還需要確認 bind-address、作業系統防火牆與網路類型。只在可信任的區域網路中使用時，可以將監聽範圍限制在特定內網位址，避免在所有網路介面上開放。

allow-lan: true
bind-address: 192.168.1.20
authentication:
  - local-user:your-password

啟用區域網路存取代表同一網路中的裝置可以嘗試連線監聽連接埠，因此不應只依靠網路環境名稱判斷安全性。在公共網路、臨時熱點與共享宿舍網路中，建議關閉 allow-lan。確實需要共享時，可以搭配驗證欄位，並在系統防火牆中只允許指定網段。遠端控制介面與代理入口是兩種不同服務，開放代理連接埠不代表也需要將控制介面暴露在區域網路中。

Rule、Global 與 Direct 模式

mode: rule 表示按照 rules 由上到下比對，是日常設定最常用的模式。global 會將連線交給全域策略組，不再逐條執行分流規則；direct 則直接連線。圖形用戶端中的模式切換可能在執行期間覆蓋設定檔的預設值，因此檔案寫著 rule，介面仍可能處於 Global。排查分流異常時，應同時查看設定欄位與用戶端目前狀態。

Global 模式適合短時間確認某個問題是否由規則引起，但不適合取代完善的規則設定。如果 Rule 模式下網站無法存取，而 Global 模式可以存取，通常表示網域被交給錯誤策略、規則順序不當，或目標策略組目前選中了不可用節點。Direct 模式適合確認本地網路本身是否可達；如果 Direct 也失敗，應先檢查網路、DNS 與目標服務，而不是反覆更換代理節點。

日誌、IPv6 與控制介面

log-level 常用值包括 silent、error、warning、info 與 debug。日常使用保持 info 通常已足夠；定位設定載入、DNS 查詢或連線握手問題時，可以暫時改為 debug。日誌可能包含存取網域、節點名稱與本機連線資訊，分享排錯截圖前應先檢查內容。問題解決後恢復正常等級，可減少無關輸出。

ipv6 不是簡單的「網路更快」開關。當地網路沒有穩定的 IPv6，但 DNS 回傳 AAAA 記錄時，程式可能先嘗試無法連線的位址；完全關閉 IPv6 又可能影響只提供 IPv6 的環境。應根據實際網路能力決定，並讓頂層 ipv6、DNS 模組與 TUN 設定保持一致。遇到同一網域時通時斷，可分別測試只回傳 IPv4 及同時回傳 IPv6 的結果，判斷是否存在位址族差異。

external-controller 為圖形介面或外部面板提供控制介面。桌面用戶端往往會自動管理此欄位，不需要手動開放。自行設定時，優先監聽回環位址，例如 127.0.0.1:9090，並設定控制密鑰。將它寫成 0.0.0.0:9090 會允許其他網路介面存取，只有明確需要遠端管理並完成存取限制時才應如此設定。external-ui 只是靜態面板檔案目錄，不會自動下載或更新介面。

external-controller: 127.0.0.1:9090
secret: your-control-secret
external-ui: dashboard

通用欄位應從「最少可用」開始加入。先確認一個混合連接埠、Rule 模式與基礎日誌能正常運作，再逐步啟用區域網路、TUN、控制介面或進階網路選項。一次加入大量欄位，雖然檔案看起來完整，卻會讓錯誤來源難以定位。不同 Clash 分支對進階欄位的支援範圍可能不同，使用圖形用戶端時應以其實際搭載的核心與設定檢查結果為準。

CHAPTER 03

DNS 設定與解析鏈路

DNS 模組能解決什麼問題

應用程式存取網域時，需要先取得目標位址，再建立連線。若網域解析繞過 Clash，而連線本身進入代理，就可能出現解析結果與代理出口不一致、直接使用遭污染的結果，或規則無法取得原始網域等問題。Clash 的 DNS 模組可以接收本機查詢，依指定上游進行解析，並在 Fake-IP 模式下建立虛擬位址與網域的對應，讓後續流量仍能依網域規則判斷。

dns.enable 控制模組是否啟用，listen 指定監聽位址，nameserver 是主要上游，fallback 可提供另一組解析來源。桌面用戶端可能透過 TUN 或系統設定自動將查詢導向內建 DNS；只在設定中寫入 listen: 127.0.0.1:1053，並不會自動修改作業系統 DNS。若一般系統查詢仍送往路由器，就需要檢查用戶端的 DNS 接管選項。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - time.*.com

Fake-IP 與 Redir-Host

enhanced-mode: fake-ip 會向應用程式回傳保留位址範圍中的虛擬 IP，並記錄其對應的原始網域。應用程式連線到該虛擬位址時，Clash 會還原網域並執行規則比對。這種方式通常更容易保留網域資訊，也能減少應用程式先自行解析再連線所造成的分流偏差。fake-ip-range 應使用專用保留位址區段，不應任意改成家用區域網路、公司網路或真實公網位址範圍，否則可能與既有路由衝突。

部分區域網路服務、遊戲裝置探索、印表機、時間同步或依賴真實位址的應用程式不適合收到 Fake-IP，可以透過 fake-ip-filter 排除。過濾項目不是越多越好：範圍過寬會使大量網域退回真實解析，削弱 Fake-IP 辨識網域的作用。遇到某個應用程式能開啟網頁卻無法探索本地裝置時，先從該應用使用的區域網路網域著手，而不是直接將所有網域加入過濾清單。

redir-host 回傳真實解析結果，相容路徑更接近傳統 DNS，但在複雜的透明代理環境中可能較難保留原始網域。選擇哪種模式取決於用戶端、作業系統與網路接管方式。一般桌面與行動圖形用戶端可先使用其預設模式；只有出現明確的相容性問題時再調整。切換增強模式後，舊 DNS 快取與連線可能仍會存在，測試前應在用戶端重新啟動 DNS 模組，必要時清除系統快取並重新開啟目標應用程式。

Nameserver、Fallback 與引導解析

nameserver 可以填寫一般 UDP DNS 位址，也可以填寫 DoH 位址。一般位址設定簡單，但查詢路徑取決於本地網路；DoH 使用 HTTPS 傳輸，需要先解析 DoH 伺服器本身的網域，因而產生引導解析問題。支援相關欄位的核心可使用 default-nameserver 提供純 IP DNS，用來解析其他加密 DNS 的主機名稱。此清單應填寫 IP 位址，不要再次填入需要網域解析的 DoH URL。

dns:
  enable: true
  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
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

proxy-server-nameserver 用於解析代理伺服器位址。節點的 server 若填寫網域，必須先取得該網域的 IP，才能建立代理連線；此時不能依賴尚未建立的代理通道完成解析，否則會形成循環。為代理伺服器準備可直接連線的解析器，可以將「解析節點位址」與「代理一般網域」分開。若訂閱節點全部使用 IP 位址，此欄位的影響會較小。

fallback 不是簡單地將所有查詢同時交給第二組伺服器。具體選擇邏輯會受到核心實作與過濾欄位影響。設定 fallback-filter 時，可根據地理資料庫、IP 範圍或網域判斷採用哪類結果，但過於複雜的過濾會提高排錯成本。對於基礎設定，應優先確保一組穩定的 nameserver 能正常運作，再考慮 fallback；如果所有解析器都無法連線，增加數量並不能解決網路路徑問題。

DNS 排錯順序

排查時先確認查詢是否進入 Clash，再確認 Clash 能否連線到上游，最後檢查回傳結果如何被規則與連線使用。日誌中完全沒有目標網域的 DNS 查詢，表示系統或應用程式可能使用了其他解析路徑；有查詢但持續逾時，應檢查上游位址、網路防火牆與代理依賴；查詢成功但存取失敗，則繼續查看規則命中、策略選擇與目標位址族。不要把所有連線問題都歸咎於 DNS，也不要在未確認鏈路前頻繁更換解析器。

瀏覽器可能啟用自己的安全 DNS，行動系統也可能使用私人 DNS，這些設定會改變查詢路徑。TUN 接管能涵蓋更多流量，但仍需處理系統權限與路由衝突。若問題表現為節點逾時、網域偶發失敗與系統代理狀態混雜，可依從訂閱到 DNS 的排查順序逐層檢查。DNS 設定的目標是讓解析路徑明確且可重現，而不是堆疊盡可能多的上游位址。

CHAPTER 04

代理節點欄位

所有節點共有的基礎關係

proxies 是節點物件清單。每個物件至少需要名稱、協定類型、伺服器位址、連接埠，以及該協定要求的驗證欄位。name 供策略組與介面參照，type 決定後續欄位如何解讀，server 可以是 IP 或網域，port 必須與伺服器監聽設定一致。節點資訊通常由訂閱提供，不應憑經驗將一種協定的欄位複製到另一種協定中。

節點能通過 YAML 檢查，只代表欄位結構可被讀取，不代表伺服器實際可達。伺服器位址錯誤、連接埠關閉、驗證不相符、系統時間偏差、TLS 主機名稱不一致與本地網路攔截，都可能造成連線失敗。排查時先確認原始訂閱是否仍有效，再檢查用戶端日誌中的失敗階段。若多個不同協定節點同時逾時，更可能是訂閱、DNS、本地網路或系統代理問題，而不是每個節點剛好同時失效。

Shadowsocks 與 Trojan 範例

proxies:
  - name: Example-SS
    type: ss
    server: ss.example.net
    port: 8388
    cipher: aes-128-gcm
    password: your-password
    udp: true

  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net
    skip-cert-verify: false
    udp: true

Shadowsocks 的 cipher 必須與伺服器一致，不能只根據用戶端支援清單任意更換。password 應作為字串處理，包含特殊字元時要加引號。udp 表示允許該節點承載 UDP，但最終能否使用仍取決於伺服器、網路路徑與用戶端運作模式。只有系統代理時，許多 UDP 流量不會自然進入代理；TUN 或透明代理環境才較常涉及 UDP 接管。

Trojan 通常透過 TLS 連線，sni 用於指定握手中的伺服器名稱。節點 server 寫 IP、但憑證簽發給網域時，正確的 SNI 尤其重要。skip-cert-verify: true 會跳過憑證驗證，不應被當作通用修復方法；若開啟後才能連線，應繼續檢查伺服器名稱、系統時間、憑證鏈與訂閱欄位是否正確。保持驗證開啟，才能發現握手目標與憑證身分不一致的問題。

VMess 與 VLESS 的傳輸欄位

proxies:
  - name: Example-VMess
    type: vmess
    server: vmess.example.net
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.net
    network: ws
    ws-opts:
      path: /proxy
      headers:
        Host: vmess.example.net

  - name: Example-VLESS
    type: vless
    server: vless.example.net
    port: 443
    uuid: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
    network: tcp
    tls: true
    servername: vless.example.net
    udp: true

VMess 與 VLESS 都會使用 UUID，但兩者不是同一種協定。WebSocket 傳輸還需要核對 network、路徑與 Host；伺服器要求特定路徑時，少一個斜線或大小寫不同都可能導致握手失敗。TLS 欄位名稱在不同設定格式與核心分支中可能存在差異，應優先保留訂閱產生的結構，不要為了「統一格式」批次改名。設定檢查能辨識未知欄位，卻無法驗證遠端反向代理是否依相同路徑轉送。

當節點使用 gRPC、HTTP/2、Reality 或其他擴充傳輸時，會出現額外的服務名稱、公鑰、短識別碼或流量控制欄位。這些欄位必須成套來自伺服器設定。缺少其中一項時，有時仍能通過語法檢查，但握手無法完成。手動移轉節點時，應移轉完整物件，不要只複製 server、port 與 UUID 三項。不同核心對擴充協定的支援也會變化，圖形用戶端應選擇與訂閱要求相符的核心。

DIRECT、REJECT 與內建出口

DIRECT 與 REJECT 是常用的內建策略，不需要在 proxies 中宣告。DIRECT 讓流量直接連線，REJECT 拒絕連線。它們可以出現在策略組的 proxies 清單，也可以直接寫在規則末尾。使用時仍要注意名稱是否被訂閱中的自訂節點占用，不要建立名為 DIRECT 的一般代理節點，以免閱讀與排錯產生混淆。

有些設定還會使用相容、拒絕丟棄封包或 DNS 相關的內建類型，其支援情況應以目前核心為準。為了讓設定能在 Clash Plus、Clash Verge Rev、FlClash 等用戶端之間移轉，基礎檔案宜優先使用常見欄位，將特定核心擴充放到獨立覆寫中。行動端與桌面端的系統接管方式不同，但節點物件本身應盡量保持一致，差異主要放在連接埠、TUN、DNS 監聽與介面設定中。

節點故障的分層判斷

延遲測試失敗不一定表示所有業務連線都失敗，延遲測試位址也不等同於實際存取目標。應先查看是 DNS 解析失敗、TCP 連線逾時、TLS 握手錯誤，還是驗證被拒絕。解析失敗時檢查 server 與代理伺服器 DNS；連線逾時時檢查網路與連接埠；TLS 錯誤時檢查 SNI、系統時間與憑證；驗證失敗則回頭確認訂閱資訊。不要先刪除整個用戶端設定，因為這會遺失能說明問題的日誌與目前欄位。

手動節點適合測試與理解欄位，長期節點清單則更適合由訂閱提供器管理。訂閱更新能統一處理節點增刪，但本地策略組與規則仍需穩定參照。下一章會說明如何將節點放入策略組，第七章則說明如何透過 proxy-providers 載入遠端節點。若首次匯入後不知道如何選擇與驗證節點，可先閱讀首次連線教學。

CHAPTER 05

策略組欄位與選擇邏輯

策略組是規則與節點之間的中間層

proxy-groups 將多個代理節點、其他策略組與內建出口組織成一個可供參照的名稱。規則通常不會直接指向某個具體節點，而是指向「節點選擇」「自動選擇」「串流媒體」等策略組。如此一來，節點變動時不必逐條修改規則，只需調整策略組成員或目前選擇。策略組也可以巢狀，但必須避免循環參照，例如 A 包含 B、B 又包含 A，會使設定關係無法成立。

最常用的類型是 select、url-test、fallback 與 load-balance。Select 由使用者明確選擇一個成員；URL-Test 定期測試並選擇符合條件的成員；Fallback 依序尋找可用成員；Load-Balance 在多個成員之間分配連線。不同類型解決的問題不同，不能簡單把「自動」理解成一定更快。延遲測試只反映測試目標與當時網路，實際服務可能經過不同路徑。

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - 故障轉移
      - Example-Trojan
      - Example-SS
      - DIRECT

  - name: 自動選擇
    type: url-test
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: 故障轉移
    type: fallback
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

Select 與自動測試組

select 的優點是結果明確。使用者在介面中選定節點後，策略會維持該選擇，適合需要固定出口、登入狀態或特定地區的服務。缺點是節點失效時不會自動替換，必須手動選擇。將自動測試組作為 Select 的第一個成員，可以同時保留自動與手動入口：日常選擇「自動選擇」，需要固定線路時再切換到具體節點。

url-test 使用 url 發起可達性測試，interval 控制週期，tolerance 用來避免多個延遲接近的節點頻繁切換。測試間隔過短會產生持續請求，也可能讓介面選擇不斷變化；間隔過長則無法及時發現故障。測試 URL 應回傳簡單、穩定的回應，不要使用需要登入、重新導向複雜或本地網路經常攔截的頁面。測試成功也只代表該節點能存取測試目標。

fallback 更強調成員順序。第一個成員可用時通常會持續使用，失敗後才切換到後續成員，適合有明確主備關係的線路。它與 URL-Test 的差異不在於是否測試，而在於選擇原則：URL-Test 偏向測試結果，Fallback 偏向順序與可用性。需要穩定工作階段時，頻繁在節點間變化可能引發登入狀態或位址變更，因此主備組往往比追求最低測試值更合適。

負載平衡與工作階段一致性

load-balance 可以讓不同連線分配到多個節點，但不代表能將單一下載工作的頻寬相加。一個網頁會建立多個連線，這些連線可能從不同出口發出；若目標服務要求同一工作階段維持相同來源位址，分散出口可能造成驗證碼、登入失效或請求被拒。支援相關策略欄位的核心可採用一致性雜湊，讓相同目標更穩定地分配到同一成員，但仍需依實際業務驗證。

  - name: 平衡出口
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

負載平衡更適合多個獨立目標或多個獨立連線，不宜作為所有規則的預設出口。設定前應先確認每個成員都能獨立運作，且地區、存取權限與協定能力相近。將差異很大的節點放入同一組，會讓同一服務的表現難以重現。若只是希望節點故障時自動切換，Fallback 通常更符合需求。

依節點名稱篩選成員

使用 proxy-providers 時，策略組可以透過 use 引入整個提供器，再用 filter 或 exclude-filter 依名稱篩選。篩選通常使用正規表示式，應先觀察訂閱中的實際命名。將篩選規則寫得過度依賴某個符號或固定前綴，訂閱服務調整名稱後，策略組可能突然變空。較穩妥的方法是從簡單關鍵字開始，並為重要組別保留手動選擇入口。

proxy-groups:
  - name: 香港節點
    type: select
    use:
      - remote-nodes
    filter: '(?i)香港|HK|Hong Kong'

  - name: 節點選擇
    type: select
    proxies:
      - 香港節點
      - DIRECT
    use:
      - remote-nodes

正規表示式中的括號、豎線與特殊字元應放在引號中。篩選結果為空時，先檢查提供器是否載入成功，再檢查名稱是否相符，不要直接判斷訂閱沒有節點。若用戶端介面能顯示提供器的原始節點清單，可以複製一兩個名稱進行最小測試。名稱篩選只是管理手段，不應被當作節點品質判斷依據；「高速」「專線」等名稱文字不能證明線路狀態。

策略組層級的維護原則

規則最外層宜參照少量穩定策略，例如「節點選擇」「直連服務」「攔截規則」。地區組、自動組與具體節點放在這些策略下方。層級過深會讓介面選擇路徑複雜，也讓規則命中後難以追蹤最終出口。一般兩到三層足以表達「業務策略—地區策略—節點」的關係。每增加一層，都應能回答它解決了什麼選擇問題。

修改策略組後，應檢查三個方向：所有成員是否存在、規則參照的策略是否存在、策略之間是否形成循環。訂閱更新還可能刪除已被手動組參照的具體節點，因此長期設定更適合透過提供器與篩選來參照，而不是把遠端節點名稱逐一複製到本地檔案。若用戶端顯示策略組但無法展開，通常應先檢查空組、參照錯誤與提供器載入狀態。

CHAPTER 06

規則語法與比對順序

規則由上到下執行

rules 是有序清單。每個連線從第一條開始檢查，命中後立即停止，不再繼續查看後面的規則。因此規則類型正確但順序錯誤，結果仍會偏離預期。範圍較具體的規則通常放在前面，範圍較寬的規則放在後面，MATCH 作為最終兜底放在末尾。將 MATCH 寫在中間，後續規則將永遠沒有執行機會。

rules:
  - DOMAIN,api.example.com,節點選擇
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,example,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

一條一般規則由規則類型、比對內容與目標策略組成，並以英文逗號分隔。策略名稱必須與 proxy-groups 中定義的名稱或內建策略一致。中文逗號、末尾多餘空格與名稱拼寫差異，都可能導致規則無法按預期載入。規則值本身若包含逗號，需要確認該規則類型是否支援相應跳脫，不應直接將複雜文字塞入一般三段格式。

網域規則的差異

DOMAIN 精確比對完整網域。例如 DOMAIN,api.example.com 只會比對該主機，不會自動比對 www.example.com。DOMAIN-SUFFIX 比對網域後綴，適合涵蓋主網域及其子網域。DOMAIN-KEYWORD 依關鍵字比對，範圍最寬，也最容易誤傷。能確定網域邊界時，優先使用 DOMAIN 或 DOMAIN-SUFFIX；只有目標網域分散且具有穩定關鍵字時，才考慮關鍵字規則。

網域規則是否可用，取決於核心能否在連線階段取得網域。應用程式如果直接連線到 IP，或 DNS 查詢完全繞過 Clash，DOMAIN 類規則可能沒有可比對的物件。Fake-IP、TUN 嗅探與系統代理都可能協助保留網域，但各自的路徑不同。發現網域規則沒有命中時，應先查看連線日誌中顯示的是網域還是 IP，再決定檢查 DNS、嗅探或規則本身。

規則涵蓋範圍需要從業務邊界出發。將頂層範圍過寬的後綴交給代理，可能讓無關服務一起變更出口；只寫一個登入網域，又可能遺漏靜態資源、API 與內容網域。可透過連線日誌觀察一次完整操作涉及哪些網域，再將屬於同一服務且需要相同策略的網域納入規則。不要只憑瀏覽器網址列推斷全部請求。

IP、網段與 no-resolve

IP-CIDR 比對 IPv4 網段，IP-CIDR6 比對 IPv6 網段。CIDR 後的數字表示網路前綴長度，例如 192.168.0.0/16 涵蓋常見的一個私有位址範圍。IP 規則適合處理區域網路、固定伺服器或資料庫提供的位址範圍，但服務使用動態位址與內容傳遞網路時，單一 IP 很快就可能變更。

no-resolve 表示執行這條 IP 規則時，不要為了取得 IP 主動觸發額外解析。對於區域網路網段與已以 IP 形式建立的連線，這可以避免不必要的 DNS 查詢。它不是所有 IP 規則都必須加入的裝飾欄位；如果前面的比對流程確實需要網域解析結果，應理解加入後的影響。排錯時可透過日誌確認規則看到的是原始 IP、解析結果還是 Fake-IP。

rules:
  - 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
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,節點選擇

區域網路直連規則通常應位於一般代理規則之前，避免印表機、路由器與內部服務被送往遠端節點。但公司網路可能使用與常見私有網路重疊的複雜路由，TUN 環境還涉及實際路由表。若存取內部位址失敗，除了規則，也要檢查系統是否將該網段正確路由到本地介面。Clash 只能處理進入其中的連線，不能取代缺失的底層網路路由。

GEOIP、規則集合與資料庫

GEOIP 根據本地位址資料庫判斷 IP 所屬地區。準確度取決於資料庫內容與更新狀態，不能將每個位址都視為永久不變。服務遷移、內容傳遞節點變更與資料庫延遲，都可能造成分類差異。若重要服務被 GEOIP 分到錯誤策略，應為它加入更具體的網域或 IP 規則，而不是等待寬泛的地理規則碰巧修正。

較大的規則庫適合透過 rule-providers 管理，再使用 RULE-SET 參照。如此一來，主設定只保留規則集合的順序與目標策略，具體項目由提供器更新。需要注意的是，不同規則集合可能重疊，仍然遵循主設定中的參照順序。廣告攔截、直連網域與代理網域若同時包含相同目標，排在前面的集合會決定最終結果。

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,proxy-domain,節點選擇
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

排查規則未命中

先在連線日誌中找到目標請求，記錄其顯示的網域或 IP、命中的規則與最終策略。若命中過寬的前置規則，調整順序或縮小範圍；若直接落入 MATCH，檢查規則內容是否與日誌物件一致；若命中正確策略卻使用錯誤節點，問題在策略組目前的選擇，而不在規則。將這三層分開，可以避免反覆修改規則卻沒有改變最終出口。

測試規則時一次只修改一個條件，並在修改後確認目前設定已重新載入。瀏覽器連線重用、DNS 快取與應用程式背景程序可能繼續使用舊連線，必要時關閉應用程式後重試。規則設計應盡量易讀：具體例外在前、規則集合居中、地區與最終兜底在後，並用簡短註解說明少數特殊項目的原因。大量沒有說明的臨時規則會讓後續維護越來越困難。

CHAPTER 07

訂閱、代理提供器與規則提供器

本地節點與遠端提供器的差異

將節點直接寫在 proxies 中，適合少量固定節點與臨時測試；使用 proxy-providers 則可從遠端位址定期更新節點清單，再由策略組透過 use 參照。提供器將「節點資料如何更新」與「節點如何參與策略」分開：遠端內容變更時，本地主設定的策略名稱與規則不必跟著改變。

提供器不是完整設定訂閱的同義詞。某些訂閱位址回傳整份 Clash 設定，其中包含連接埠、DNS、策略組與規則；proxy-providers 通常需要回傳節點集合格式。將完整設定位址直接填入 provider，可能因內容結構不符而載入失敗。用戶端的一般訂閱匯入與設定內部的代理提供器也屬於不同層級，應先確認伺服器提供的檔案類型。

proxy-providers:
  remote-nodes:
    type: http
    url: https://config.example.net/nodes.yaml
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 節點選擇
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

type: http 表示從遠端位址取得，url 是訂閱位址，path 是本地快取位置，interval 是更新間隔。快取讓用戶端在短暫無法存取遠端位址時仍可讀取上次成功的內容。路徑應位於用戶端允許寫入的設定目錄中，不要指向需要額外系統權限的位置。多個提供器不能共用同一個快取檔案，否則更新時會互相覆蓋。

訂閱位址通常具有存取權限，應避免寫入公開分享的日誌、截圖與範例檔案。本文範例使用無法用於真實服務的示例網域。訂閱載入失敗時，應查看 HTTP 狀態、TLS 錯誤、回應內容格式與本地檔案寫入權限，而不是只看策略組是否為空。遠端請求成功但內容不是預期的 YAML，同樣會導致解析失敗。

健康檢查與策略測試

health-check 可以定期檢查提供器中的節點是否能存取指定 URL。它與策略組的 URL-Test 有關聯，但並非同一層：提供器健康檢查維護節點可用狀態，策略組測試則決定組內如何選擇。兩處都設定過短的間隔，會產生重複測試。可根據節點數量與使用方式保留合理週期，不必持續高頻探測。

健康檢查失敗可能是節點無法使用，也可能是測試 URL 在目前網路或目標地區無法連線。若所有節點在同一時間對同一個測試位址失敗，應嘗試用實際目標與另一個穩定位址交叉驗證。測試 URL 回傳重新導向、驗證碼或較大的頁面時，也會增加誤判。簡單的空回應端點更適合進行可達性檢查，但仍不能取代業務存取驗證。

規則提供器結構

rule-providers 用於載入可更新的規則集合。常見欄位包括行為類型 behavior、格式 format、遠端位址、快取路徑與更新週期。behavior: domain 適合網域集合，ipcidr 適合 IP 網段，classical 則可容納帶有規則類型的經典項目。主設定中的 RULE-SET 參照必須與集合行為相符，IP 集合通常還會搭配 no-resolve。

rule-providers:
  direct-domain:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.net/direct-domain.yaml
    path: ./rules/direct-domain.yaml
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.net/private-ip.yaml
    path: ./rules/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,節點選擇

Domain 行為的 YAML 內容通常是網域項目清單，IPCIDR 行為則是網段清單。Classical 內容會帶有 DOMAIN-SUFFIX、IP-CIDR 等完整規則類型。將 Classical 檔案宣告為 Domain，解析器可能拒絕載入，或無法依預期解讀項目。建立自有規則集時，應先選定行為類型，再依對應格式編寫，不要把不同類型混在同一個簡化集合中。

更新、快取與失敗復原

遠端更新應視為一次設定變更。節點提供器更新後，目前選中的節點可能被刪除或改名；規則提供器更新後，同一網域可能命中不同集合。更新完成後應檢查提供器狀態、策略組目前選擇與關鍵服務的規則命中。自動更新不代表不必觀察，尤其在本地設定依賴名稱篩選時，遠端命名變化會直接影響組內成員。

提供器拉取失敗但快取仍存在時，用戶端可能繼續使用舊資料。這有助於維持連線，卻也容易讓人誤以為更新成功。查看狀態時應區分「載入了快取」與「剛完成遠端更新」。快取檔案損壞時，可以在確認遠端位址可用後刪除對應的單一快取並重新拉取，不應清空整個用戶端目錄。清空所有資料會同時遺失策略選擇、設定與排錯線索。

訂閱回傳空內容時，不要立即用空結果覆蓋長期使用的本地檔案。圖形用戶端一般會在解析失敗時保留舊設定，但不同實作的處理方式可能不同。手動腳本更新時更應先下載到暫存檔，通過 YAML 與設定檢查後再取代目標檔案。這種「先驗證、後取代」流程可以避免網路中斷或伺服器異常將可用設定變成空檔案。

敏感資訊與可移轉設定

設定中的訂閱 URL、節點密碼、UUID 與控制密鑰都屬於存取相關資訊。分享設定用於排錯時，應刪除這些值，同時保留欄位結構、協定類型與錯誤附近的縮排。單純改掉節點名稱並不能移除驗證資訊。日誌中也可能出現完整訂閱位址，應先處理後再傳送給他人。

為提高桌面與行動裝置之間的可移轉性，可以將遠端節點、通用策略組與規則作為基礎層，把連接埠、控制介面、TUN、DNS 監聽位址等裝置差異放在覆寫層。Clash Plus 作為全平台用戶端，可從下載頁依系統取得；其他用戶端對覆寫入口與本地目錄的呈現方式可能不同，但基礎 YAML 的參照關係應保持清楚。

CHAPTER 08

設定覆寫、合併與系統排錯

為什麼需要覆寫層

遠端訂閱通常由伺服器維護，更新時會重新產生設定。若直接在訂閱檔案中加入 DNS、策略組或規則，下次更新可能恢復為遠端版本。覆寫或合併的作用，是在不修改原始訂閱的前提下，將本地長期設定套用到更新結果上。不同用戶端可能將此功能稱為覆寫、合併、擴充設定或預處理，介面位置與支援語法並不完全相同。

設計覆寫時，應先區分「取代一個值」「向清單追加元素」「刪除既有元素」與「依名稱修改物件」四種操作。一般 YAML 合併只能表達物件鍵的覆蓋，不能自動理解兩個策略組名稱相同就應合併成員。用戶端內建的覆寫系統可能提供專用規則，但不能假設所有用戶端都採用相同語意。移轉設定前應查看實際產生的結果，而不是只查看覆寫來源檔案。

映射覆蓋與清單取代

映射欄位通常依鍵覆蓋。例如基礎設定中 mode: rule，本地覆寫寫入 mode: global，最終值一般以前者之後寫入的值為準。巢狀映射是否深度合併，則取決於工具：有的只覆蓋 dns 中指定的子欄位，有的會以整個新的 dns 物件取代舊物件。如果覆寫後 nameserver 突然消失，往往就是巢狀物件被整體取代。

# base.yaml
mixed-port: 7890
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5

# override.yaml
mode: rule
dns:
  ipv6: false
  fake-ip-filter:
    - '*.lan'

理想的深度合併結果會保留 enable、enhanced-mode 與 nameserver，再加入 ipv6 與過濾項目；整體取代的結果則只剩覆寫中的兩個欄位。不能僅憑檔名判斷是哪一種行為，應在用戶端中匯出或查看最終設定。首次設定覆寫時，選擇一個容易觀察的非敏感欄位進行測試，比一次加入整段 DNS 與策略組更容易確認語意。

清單處理更需要小心。rules、proxies 與 proxy-groups 都是清單。一般合併工具常會取代整個清單，另一些工具則允許前置、後置或依名稱插入。若本地規則需要優先於訂閱規則，應明確使用「前置規則」功能；簡單追加到 MATCH 後面不會生效。若用戶端只支援整體取代，則需要完整保留遠端規則或改用規則提供器，不能只寫新增的幾條。

YAML 錨點的適用範圍

YAML 錨點可以減少同一檔案中的重複欄位。例如多個自動策略組使用相同測試位址與間隔時，可以定義共用映射再合併。但錨點只在同一次 YAML 解析中有效，不能跨遠端訂閱與本地覆寫檔案自動共用。部分設定處理器還會在產生階段展開或移除錨點，因此使用前應確認用戶端最終能夠讀取。

group-test: &group-test
  type: url-test
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 80

proxy-groups:
  - name: 自動選擇
    <<: *group-test
    proxies:
      - Example-Trojan
      - Example-SS

  - name: 備用自動組
    <<: *group-test
    proxies:
      - Example-SS
      - Example-Trojan

錨點適合減少靜態重複，不適合掩蓋複雜層級。過度使用會讓讀者必須來回追蹤合併來源，也增加跨用戶端移轉的難度。需要長期維護的公開設定，寧可保留少量重複，也應讓每個策略組的核心行為清楚可見。若錨點展開後的最終設定不易檢查，應優先使用用戶端明確支援的覆寫機制。

依階段驗證最終設定

設定修改應分四個階段驗證。第一階段檢查 YAML 語法，確認縮排、引號與資料型別；第二階段檢查物件關係，確認節點、策略組、提供器與規則參照都存在；第三階段載入用戶端，確認連接埠、DNS 與控制介面沒有與系統資源衝突；第四階段使用實際連線驗證規則命中與最終出口。只完成第一階段，不能代表設定已經可用。

1. 保存基礎檔案與目前可用狀態

   保留原始訂閱、本地覆寫與最終產生設定的副本，並記錄修改前能正常使用的策略。復原時應能回到明確狀態，而不是依靠記憶逐項撤銷。

2. 一次修改一個設定層

   先修改通用欄位，再處理 DNS，接著加入策略組與規則。若同時更換節點、啟用 TUN 並重寫 DNS，發生錯誤後很難判斷是哪一層造成的。

3. 查看最終展開結果

   確認覆寫後是否仍保留原有清單、同名策略是否被取代、規則是否出現在 MATCH 之前，以及提供器快取路徑是否獨立。

4. 依連線鏈路測試

   依序測試直連、本地代理連接埠、DNS 查詢、單一節點、策略組與規則分流。每一步通過後再進入下一步，避免將所有現象歸咎於節點問題。

常見錯誤與處理順序

連接埠衝突可以透過作業系統網路工具確認。Windows 可在終端機中使用 netstat -ano 查看監聽連接埠，macOS 與 Linux 可使用 lsof 或 ss。找到占用程序後，應先判斷它是否是另一個正在執行的代理用戶端。不要同時開啟多個用戶端的系統代理與 TUN，否則即使連接埠各不相同，也可能因路由、DNS 或系統代理反覆覆蓋而產生循環。

# Windows：查看 7890 連接埠
netstat -ano | findstr :7890

# macOS：查看 7890 連接埠
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看監聽連接埠
ss -lntp | grep 7890

從最小設定復原

複雜設定無法定位問題時，可以建立一份最小測試檔案，只保留一個本地連接埠、一個已確認可用的節點、一個 Select 策略組與一條 MATCH 規則。先關閉 TUN、自訂 DNS、規則提供器與腳本覆寫，驗證基礎代理鏈路。基礎鏈路成功後，再依 DNS、提供器、策略組、規則與 TUN 的順序逐層加回。這比在數千行設定中隨機刪改更可靠。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Test-Node
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - Test-Node
      - DIRECT

rules:
  - MATCH,節點選擇

最小設定仍失敗時，應根據日誌判斷是本地連接埠、節點解析、伺服器連線還是 TLS 驗證問題。如果最小設定可用，而完整設定失敗，問題就在後來加入的某一層。每加回一層就保存一次可用狀態，便能得到清晰的二分邊界。需要更多現象對應的處理方法，可查看疑難排解；若尚未完成安裝與首次訂閱匯入，則返回快速入門依主線操作。

長期維護建議

穩定設定不以欄位數量衡量，而以關係清楚、更新可控與故障可復原為標準。基礎層保存通用連接埠、DNS 與少量穩定策略；遠端層負責節點與大型規則集合；裝置層負責 TUN、監聽位址與系統差異；覆寫層只保存需要長期保留的本地變更。每一層都應能單獨說明來源與作用。

訂閱或規則庫更新後，重點檢查提供器狀態、空策略組、目前節點與關鍵規則命中。用戶端升級後，先用設定檢查確認進階欄位仍受支援，再啟用日常設定。遇到問題時保留日誌、最終展開設定與最小重現片段，不要在多個設定檔之間來回切換卻不記錄結果。按照「語法—參照—連接埠—DNS—節點—策略—規則—系統接管」的順序檢查，通常能將問題縮小到明確層級。