Clash 設定檔完整參考

01 / Structure

YAML 結構總覽

設定檔由哪些部分組成

Clash 設定檔本質上是一份 YAML 文件。mihomo 核心讀取後，會先建立監聽連接埠與 DNS 服務，再載入代理節點、策略組、規則集與執行參數。常見檔案可分為六個層次：通用執行欄位、DNS、節點或節點提供器、策略組、規則提供器、規則。它們在文字中的先後順序通常不影響解析，但引用關係有明確方向：規則引用策略組，策略組引用節點或其他策略組，Provider 則向策略組與規則提供可更新資料。

以下是一份方便理解層級的最小骨架。它使用本機 HTTP 與 SOCKS 連接埠，定義手動策略組，並讓未命中的流量直連。範例中的節點位址與密碼只是教學用假值，不能直接用於連線。

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

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

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

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

頂層鍵必須從行首開始。屬於某個鍵的子項需要統一縮排，通常使用兩個空格。YAML 不要求固定使用兩個空格，但同一層級必須一致；Tab 字元不適合作為縮排。列表項以連字號開頭，鍵和值之間使用半形冒號及至少一個空格。節點名稱、策略組名稱可以包含中文，但名稱在所有引用位置都必須完全一致，包括空格、大小寫與標點。

映射、列表與純量

理解三種資料形態，就能快速看懂絕大多數設定。映射是一組鍵值，例如 dns: 下的 enable: true；列表是一串有順序的項目，例如 rules: 下每行一條規則；純量則是字串、數字、布林值或空值。true、false 應寫成布林值，不要加引號。連接埠應寫成數字。含有冒號、井字號、前後空格，或容易被 YAML 解讀為其他型別的字串，建議加上引號。

井字號表示註解起點。若密碼或名稱本身含有井字號，必須使用引號，否則井字號後的內容會被當成註解丟棄。設定中重複出現同一個頂層鍵時，不同解析器可能保留前一項或後一項，也可能直接報錯，因此不要依賴重複鍵覆蓋。編輯訂閱檔案時尤其要注意：把新的 dns: 區段直接貼到原有 dns: 區段後面，不代表已完成合併。

名稱引用與載入順序

策略組名稱是規則的最終目標。例如規則寫成 DOMAIN-SUFFIX,example.org,自動選擇，設定中就必須存在名為「自動選擇」的策略組，或存在同名的內建動作。DIRECT、REJECT 等動作由核心識別；其他名稱都需要在 proxy-groups 中宣告。策略組也可以引用另一個策略組，但應避免形成 A 引用 B、B 又引用 A 的循環關係。

客戶端匯入設定時，可能先儲存原始訂閱，再套用本機覆寫，最後交由核心解析。因此你在介面中看到的最終設定，未必與訂閱伺服器回傳的文字完全相同。排錯時應確認目前執行的是哪一份設定、最後一次更新是否成功，以及客戶端是否啟用了腳本或合併規則。若只是想完成訂閱匯入與首次連線，不需要手動編寫整份 YAML，可先依照快速入門文件操作。

02 / General

通用欄位：連接埠、模式與日誌

監聽連接埠的選擇

port 提供 HTTP 代理連接埠，socks-port 提供 SOCKS5 代理連接埠，mixed-port 則允許同一個連接埠同時接收 HTTP 與 SOCKS 流量。在桌面系統中，系統代理常使用 HTTP 或 mixed 連接埠；需要單獨指定 SOCKS5 的命令列工具則可使用 socks 連接埠。多數情況下選擇 mixed-port 能減少連接埠數量，但若現有腳本固定引用 7890 與 7891，就應維持原本的連接埠規劃。

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

同一台裝置上的兩個程式不能同時監聽相同的位址與連接埠。客戶端顯示「address already in use」時，先關閉另一套代理軟體或更換連接埠，不要把問題歸咎於節點。連接埠範圍為 1 至 65535，低號連接埠在部分桌面系統上可能需要額外權限。修改連接埠後，還要同步修改瀏覽器、終端機環境變數或區域網路裝置中的代理位址。

區域網路存取與繫結位址

allow-lan 控制其他裝置能否存取目前裝置提供的代理連接埠。僅在本機使用時設為 false，可以減少不必要的暴露。需要讓同一個 Wi‑Fi 下的電腦、電視或測試機連線時，將它設為 true，並使用代理主機的區域網路位址。此時還要確認系統防火牆允許對應連接埠、兩台裝置位於可互相存取的網路，並避免在公共網路中開啟。

bind-address 決定監聽哪些本機位址。星號通常表示所有可用介面，迴路位址則只允許本機存取。不同客戶端可能透過圖形介面管理這些參數，介面中的「允許區域網路」開關可能在執行時產生對應欄位。iOS 的網路延伸運作方式與桌面連接埠代理不同，應用程式匯入同一份設定時，不一定會向其他裝置開放這些監聽連接埠，因此跨裝置共享應以客戶端實際功能為準。

rule、global 與 direct

mode: rule 會依規則列表由上到下決定每個連線的去向，是日常使用最常見的模式。global 讓流量統一交給全域策略組處理，適合短時間確認某個節點是否可用，但不會呈現細分規則的結果。direct 讓連線直接存取目標，可用來比較代理前後的網路表現。切換模式只是改變分流入口，不會自動修復無效節點或錯誤 DNS。

當客戶端介面提供「規則模式」「全域模式」「直連模式」時，介面選擇通常會覆蓋設定檔中的預設 mode。排查規則未生效時，應同時檢查 YAML 與目前介面狀態。若一直停留在全域模式，修改 rules 自然看不到變化；若處於直連模式，策略組中的節點選擇也不會承擔主要流量。

日誌、控制介面與設定儲存

log-level 常用 info，可以看到連線、規則命中與部分錯誤。日誌太少時難以定位問題，長期保持過於詳細的除錯輸出又會增加閱讀成本。遇到連線失敗時，先記錄目標網域、命中的規則、選取的策略組與錯誤類型，再對照設定進行修改；不要只憑「無法開啟」這個現象反覆更換所有設定。

external-controller 用於為相容的控制介面提供 API，例如監聽在本機迴路位址。若設定了 secret，控制端連線時需要使用一致的憑證。行動客戶端通常已經管理好控制介面，不建議為了套用桌面教學而任意開放到區域網路。設定中的憑證應使用自己的值，並避免把包含訂閱位址、節點密碼或控制金鑰的完整檔案公開貼到論壇。

profile 下的儲存選項可用於保留策略組選擇或 Fake IP 對映。客戶端是否支援、何時寫入，取決於其核心整合方式。升級客戶端或更換設定後，如果某個策略組仍保留舊選擇，先確認是否啟用了選擇記憶，再判斷是否為設定未重新整理。系統要求與可用客戶端可在下載頁依平台查看。

03 / DNS

DNS 設定：解析鏈路與劫持

DNS 區段解決哪些問題

DNS 區段決定網域如何轉換為位址，以及解析請求是否由核心統一接管。代理節點可用不代表 DNS 一定正確：網域解析可能仍由系統網路直接完成，也可能被路由器、電信網路或另一套 VPN 接管。常見表現包括部分網域無法開啟、規則命中與預期不一致、切換網路後短時間異常，或代理已連線但應用程式仍提示無法存取。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

enable 控制內建 DNS 是否啟用。listen 是 DNS 服務的監聽位址，在桌面或路由環境中可供系統轉送；行動端通常由網路延伸接管，不應只根據監聽連接埠判斷是否生效。ipv6 控制是否回傳及處理 AAAA 結果。如果本地網路的 IPv6 路徑不穩定，暫時關閉有助於判斷問題是否來自雙堆疊網路，但不應把關閉 IPv6 當成所有 DNS 故障的固定解法。

nameserver 與 bootstrap 的關係

nameserver 是主要解析器列表，可以使用傳統 UDP 位址，也可以使用加密 DNS URL。設定 DoH 時，DoH 伺服器本身的網域也需要先解析，這會形成啟動階段的依賴。mihomo 的不同設定方式可透過 default-nameserver 或專用的伺服器解析項目處理初始解析。這裡應放置能直接連線的 IP 形式解析器，避免初始解析再次依賴尚未建立的代理鏈路。

proxy-server-nameserver 主要用於解析代理伺服器網域。它與一般目標網域解析分開，可以降低「要連線到代理伺服器，卻必須先透過該代理解析伺服器網域」的循環依賴。若節點的 server 已經是 IP 位址，這個環節的影響較小；若訂閱中大量節點使用網域，設定一組目前網路可直接連線的解析器會更穩妥。

加密 DNS 不會自動代表所有查詢都經過代理。解析器 URL 可以直連，也可以依據核心支援的位址參數指定透過某個策略處理。設計解析鏈路時，先確定目標：是避免本地解析干擾、讓規則取得一致結果，還是要求特定網域透過特定解析器。目標不同，設定也不同。不要同時堆入大量公共 DNS，期待核心自動判斷哪個最適合；解析器回應內容不同，反而可能增加不確定性。

fake-ip 與 redir-host

fake-ip 模式會先向應用程式回傳保留位址池中的對映位址，核心再根據對映還原原始網域並執行規則。它的優勢是規則比對能保留網域資訊，對透明接管情境也更直接。redir-host 則回傳真實解析結果，某些區域網路服務或對位址行為敏感的程式更容易相容，但網域資訊的保留方式與比對路徑會有所不同。

fake-ip-range 應使用專門規劃的位址區段，不要與家庭網路、公司網路、容器網路或 VPN 已使用的網段重疊。若存取某個區域網路網域後取得 Fake IP，表示它沒有被排除。可將明確需要真實解析的網域加入 fake-ip-filter，例如區域網路後綴、裝置探索網域或特定登入網域。過濾項應盡量具體；將過寬的萬用字元加入列表，會讓大量請求繞過 Fake IP，削弱統一接管效果。

nameserver-policy 與分域解析

nameserver-policy 可以讓特定網域或規則集使用指定解析器。例如將內部網域交給公司 DNS，其他網域使用公共加密解析器。匹配項越具體越容易維護。若一個網域同時符合多條策略，應配合核心的匹配優先順序檢查最終結果，並透過日誌確認，而不是只根據設定排列猜測。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://223.5.5.5/dns-query
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "+.internal.example"
    - "*.lan"

內部解析器通常只能在指定 Wi‑Fi、企業網路或 VPN 內存取。離開該網路後，如果策略仍將內部網域傳送給無法連線的位址，查詢會等待逾時。行動裝置頻繁在行動網路與 Wi‑Fi 之間切換，建議將這類設定放在相應的隨選連線條件或獨立設定中，不要讓一份強綁定辦公網路的 DNS 設定覆蓋所有情境。

DNS 排錯順序

先分別使用網域與 IP 測試：IP 可存取但網域失敗，重點檢查解析；兩者都失敗，再檢查策略組、節點與系統網路。接著查看日誌中的 DNS 逾時、連線拒絕或解析器握手錯誤。再確認系統是否同時啟用了其他 VPN、私人 DNS、過濾應用程式或路由器 DNS 重寫。最後才調整 enhanced mode、解析器或 IPv6。每次只修改一個變數，並清除應用程式或系統的短期快取後重新測試。

如果問題表現為「已連線但無法上網」，可以搭配閱讀由上而下的排查清單。需要逐欄位理解 fallback、過濾與 DNS 劫持時，可繼續查看DNS 設定詳解。不同客戶端可能會將部分欄位圖形化封裝，最終應以執行日誌與匯出的生效設定為準。

04 / Proxies

代理節點欄位

通用欄位與引用名稱

proxies 是靜態節點列表。每個節點至少包含 name、type、server 與 port，其餘欄位取決於協定。name 是設定內部的引用識別，不負責網路連線；server 才是伺服器網域或位址。策略組引用節點時使用名稱，因此重新命名節點後，必須同步更新所有直接引用它的策略組。

節點名稱最好簡短且穩定。訂閱更新時，如果服務端更改名稱，客戶端記住的策略組選擇可能找不到舊項，並退回預設節點。需要長期固定選擇時，可以讓策略組透過 Provider 使用篩選規則選取某類節點，或在本機覆寫中維持統一命名。不要只靠名稱中的地區詞判斷線路品質，實際可用性還會受到本地網路、入口、傳輸參數與服務端狀態影響。

Trojan 範例

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

Trojan 通常使用 TLS。sni 是 TLS 握手中的伺服器名稱，應與服務端憑證及部署設定一致。password 必須完整保留特殊字元，使用引號會更穩妥。udp 控制節點是否承載 UDP 流量，但只有客戶端、核心與服務端都支援時才真正可用。skip-cert-verify 關閉憑證驗證會削弱身分驗證，正常部署應保持為 false；憑證錯誤應從伺服器名稱、憑證有效性、系統時間與網路劫持方向修正。

Shadowsocks 範例

proxies:
  - name: Example-SS
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

Shadowsocks 的核心欄位是加密方法與密碼，兩端必須一致。cipher 不能依個人偏好任意替換，服務端設定什麼，客戶端就填寫什麼。連線失敗時應核對位址、連接埠、方法與密碼四項，再確認伺服器防火牆及本地網路是否允許對應流量。把另一種協定的欄位複製進來不會提升相容性，未識別欄位可能被忽略，也可能導致設定驗證失敗。

VMess、VLESS 與傳輸層參數

VMess 常使用 uuid、alterId、cipher 等欄位；VLESS 使用 UUID，並依部署方式選擇 TLS、Reality 或其他傳輸設定。WebSocket、gRPC 等傳輸層通常還有路徑、Host、服務名稱與請求標頭。欄位層級必須符合 mihomo 支援的格式，不能把其他客戶端匯出的 JSON 欄位逐字搬進 YAML。

  - name: Example-VMess-WS
    type: vmess
    server: ws.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: ws.example.com
    network: ws
    ws-opts:
      path: /network
      headers:
        Host: ws.example.com

這裡的 server 決定連線目標，servername 或相應的 SNI 欄位會影響 TLS，WebSocket 的 Host 則影響上層請求。三個網域在簡單部署中可能相同，在經過反向代理或分離入口的部署中也可能不同。任何一項拼寫錯誤，都可能表現為 TCP 可以建立但握手失敗。排錯時應依「網域解析、TCP 連接埠、TLS、傳輸層、協定驗證」的順序逐層定位。

節點層級網路選項

interface-name 可指定出口網卡，routing-mark 常用於 Linux 策略路由，行動客戶端通常不需要手動設定。ip-version、prefer-ipv6 等選項會影響節點伺服器網域如何選擇位址，具體支援情況取決於核心。只有在確認雙堆疊解析選錯位址時才應調整，避免把一般線路故障誤判為 IP 版本問題。

節點欄位正確但仍無法使用時，先將該節點放入簡單的 select 組，並暫時切換至全域模式測試，以排除複雜規則的影響。測試結束後回到規則模式。如果所有節點同時失效，優先檢查訂閱狀態、系統時間、DNS 與本地網路；只有單一節點失效時，再集中核對它的協定參數。客戶端選擇與平台差異可在下載頁查看，Clash Plus 作為全平台首選，適合先完成基礎連線，再逐步調整設定。

05 / Policy

策略組欄位與選擇邏輯

select：將決定權交給使用者

策略組位於節點與規則之間。規則通常不會直接寫入某個具體節點，而是指向策略組；你在客戶端介面更換組內選擇後，所有指向該組的規則都會使用新的結果。select 是手動選擇組，適合作為「節點選擇」「串流媒體」「下載」等可明確控制的入口。組內可以放置節點、其他策略組或 DIRECT。

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

列表順序會影響介面預設顯示與回退體驗。將最常使用的選項放在前面，但不要讓上層組與下層組形成循環。例如「節點選擇」包含「自動選擇」是合理的；若「自動選擇」又把「節點選擇」當作候選，就會形成無法解析或執行的循環。複雜設定最好先畫出引用方向，再決定分層。

url-test：依探測結果自動選擇

url-test 會使用指定 URL 測試候選節點的連線能力，並選擇表現較合適的節點。它衡量的是對測試目標的請求表現，不等同於所有網站的實際速度。測試 URL 應穩定、回應內容小，並能代表主要使用的網路。測試頻率過高會增加背景活動與伺服器請求，在行動裝置上也可能造成額外耗電。

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

interval 是測試間隔，單位通常為秒；tolerance 用於避免候選結果只因微小差異就頻繁切換；lazy 可讓測試更接近按需執行。設定這些欄位時，重點是穩定而非持續重新整理。若業務連線需要維持同一個出口，頻繁切換節點可能導致工作階段變更，因此應提高容差與間隔，或改用手動組。

fallback 與 load-balance

fallback 會依列表優先順序使用節點，當目前節點探測失敗時切換至後續候選。它適合「優先使用首選線路，不可用時再切換」的情境。與 url-test 不同，它不以最低測試結果作為唯一目標，而是保留順序偏好。排錯時若總是切換到第二個節點，應檢查首選節點是否能連線至測試 URL，而不只是檢查一般網頁。

load-balance 會依策略將不同連線分配至多個節點。它不等於將單一下載任務的頻寬簡單相加，也可能因出口位址變化而影響登入狀態、風控判斷或長連線。需要固定來源位址的網站不適合任意使用負載平衡。具體策略可按照雜湊或輪詢概念分配，選擇前應先理解目前客戶端核心支援的欄位。

透過 Provider 選取節點

當節點來自 proxy-providers 時，策略組可以使用 use 引用 Provider，而不必將每個節點名稱寫入 proxies。如此一來，訂閱更新增刪節點後，組內候選也會同步變更。還可以使用 filter 依名稱篩選，例如只納入名稱含有某個地區標識的節點。過濾規則通常使用正規表示式，應考慮大小寫、全形符號及服務端重新命名帶來的變化。

  - name: 行動網路
    type: select
    use:
      - provider-main
    filter: "(?i)mobile|行動"
    exclude-filter: "(?i)expire|剩餘|到期"

名稱過濾只依據文字，不會驗證節點的實際所在地、協定或線路屬性。訂閱命名規則變更後，組可能突然變空。維護設定時，應為重要策略組準備可見的回退項，並在更新訂閱後檢查候選數量。若客戶端介面顯示策略組為空，先檢查 Provider 更新是否成功，再檢查過濾表達式，最後檢查 Provider 名稱是否寫錯。

策略組設計不宜過深。常見的三層已足以涵蓋大多數需求：底層是節點池與自動測試組，中層是「節點選擇」等總入口，上層則是影片、下載或特定服務策略。層級越多，就越難在日誌中追蹤最終出口。規則命中後，應沿著「規則目標組—目前組選擇—下層組選擇—具體節點」逐級確認。

06 / Rules

規則語法與匹配順序

由上到下，命中即停止

rules 是有順序的列表。核心從第一條開始檢查連線，命中後使用該條指定的策略，不再繼續檢查後續規則。因此具體規則應放在寬泛規則之前，最終兜底則放在末尾。若將 MATCH 提前，後面的網域與位址規則永遠沒有機會執行。排查「規則已寫入但未生效」時，首先查看日誌實際命中了哪一條，而不是繼續追加重複規則。

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

每條經典規則通常由規則類型、匹配內容與策略目標組成，使用半形逗號分隔。策略目標必須是現有策略組、節點名稱或內建動作。規則行中的額外空格可能成為內容的一部分，最好維持統一格式。網域匹配不包含 URL 路徑；若想依網頁路徑分流，僅靠 DOMAIN 類規則無法完成。

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

DOMAIN 會精確匹配完整網域。例如 DOMAIN,api.example.com 只匹配該主機，不會自動包含 www.example.com。DOMAIN-SUFFIX,example.com 匹配該根網域及其子網域，適合涵蓋同一服務的一組主機。DOMAIN-KEYWORD 只要網域中出現指定文字就可能命中，涵蓋範圍較廣，容易誤傷名稱相似但無關的網站。

規則設計應優先使用精確網域與後綴，只有確實無法整理網域集合時才使用關鍵字。服務可能依賴多個網域，包括登入、介面、圖片與媒體網域，只處理網頁主網域不一定能涵蓋完整請求。可以觀察連線日誌逐步補全，但不要把每個臨時 CDN 主機都硬編碼進主設定；規模較大的網域集合更適合放進規則集 Provider。

IP-CIDR 與 no-resolve

IP-CIDR 匹配 IPv4 網段，IP-CIDR6 匹配 IPv6 網段。CIDR 後綴表示網路前綴長度，例如 /24 涵蓋相鄰的一段 IPv4 位址。IP 規則無法穩定表達經常變化的雲端服務網域，因此不要把一次解析出的位址當作長期規則。只有在服務提供穩定網段、區域網路位址或明確網路範圍時，IP 規則才更適合。

no-resolve 表示判斷此 IP 規則時不要額外觸發網域解析。當連線已經具有目標 IP 時可以直接匹配；若只有網域，核心不會為了這條規則特別進行解析。它能減少不必要的查詢與潛在循環，但也可能讓依賴解析結果的 IP 規則無法命中。是否使用，應根據請求進入核心時已掌握的資訊決定。

rules:
  - 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
  - IP-CIDR6,::1/128,DIRECT,no-resolve

區域網路直連規則通常放在較前位置，避免印表機、路由器與檔案伺服器被送進遠端代理。公司網路可能使用更大的私有位址規劃，家庭網路也可能與 VPN 網段重疊。遇到區域網路服務無法存取時，先確認目標實際位址，再判斷是規則錯誤、Fake IP 過濾不足，還是系統路由沒有指向本地介面。

GEOIP、GEOSITE 與規則集

GEOIP 依目標 IP 所屬資料庫分類，適合進行區域級 IP 分流，但資料庫判斷不等於業務歸屬判斷。本地品牌也可能使用其他地區的雲端節點，海外服務也可能在本地部署邊緣位址。GEOSITE 使用網域分類資料，涵蓋方式取決於規則資料庫內容。兩者都依賴資料更新，不應被理解為永遠準確的固定事實。

mihomo 常見的規則集匹配還包括 RULE-SET。規則集可以載入 domain、ipcidr 或 classical 行為的資料，引用時必須與 Provider 的 behavior 對應。將 classical 格式的完整規則放入 domain 行為規則集，或為 IP 規則集使用錯誤行為，都會導致解析失敗或匹配結果異常。

程序規則與平台限制

PROCESS-NAME、PROCESS-PATH 等程序規則依賴作業系統提供程序資訊。桌面系統在具備權限時可能可用，iOS 網路延伸通常不能以桌面方式讀取任意程序路徑。編寫跨平台設定時，不應讓關鍵分流完全依賴程序規則。更穩妥的主線仍是網域、IP 與規則集，再將程序規則作為特定桌面環境的補充。

同一份設定在 Windows、macOS、Android 與 iOS 上出現差異，常見原因並非 YAML 語法變化，而是系統接管方式、權限與網路堆疊不同。可以將平台相關規則放入本機覆寫，讓訂閱主體維持通用。如此訂閱更新時，不會把桌面專用的程序規則強行帶到行動端。

REJECT、DIRECT 與最終兜底

DIRECT 讓連線直接存取，REJECT 拒絕連線。攔截規則要精確，過寬的關鍵字或網域後綴可能阻斷登入、付款與基礎介面。最後一條通常使用 MATCH 指向總策略組或直連，具體取決於設定目標。沒有最終兜底時，未命中流量的行為可能由核心預設邏輯決定，設定意圖不夠清晰。

修改規則後應涵蓋主要分支進行測試：一個應直連的網域、一個應代理的網域、一個區域網路位址與一個規則集目標。只測試單一網頁，無法證明完整規則鏈正確。速度問題則應區分節點、線路與本機設定，可參考速度緩慢的三層排查方法，避免把所有效能問題都歸因於規則數量。

07 / Providers

Proxy Provider 與 Rule Provider

為什麼使用 Provider

Provider 將經常更新的資料從主設定中拆分出來。proxy-providers 提供節點列表，rule-providers 提供規則集合。主設定負責引用名稱、選擇更新週期與定義策略，遠端檔案則負責實際內容。如此訂閱更新時不必重寫整份主設定，也能讓多個策略組共用同一個節點池。

Provider URL 往往包含存取憑證，應將完整設定視為敏感資料。排錯時可以公開刪除憑證後的結構，但不要公開真實訂閱位址。遠端檔案無法存取時，客戶端可能繼續使用本機快取，也可能因首次下載失敗而使對應組為空。看到舊節點仍存在，不一定代表更新成功，應查看更新時間與 Provider 日誌。

節點提供器設定

proxy-providers:
  provider-main:
    type: http
    url: "https://subscription.example/path?token=xxxx"
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      lazy: true

type: http 表示從遠端取得，url 是資源位址，path 是本機快取路徑，interval 控制更新間隔。路徑應避免多個 Provider 共用同一個檔案，否則更新時可能互相覆蓋。客戶端處於沙盒環境時，實際儲存位置由應用程式管理，相對路徑通常由核心工作目錄解析，不應照搬桌面絕對路徑。

health-check 用來檢查 Provider 內節點的可用性。它不會自動改變所有策略組的選擇，只有 url-test、fallback 等組會依據探測結果作出相應選擇。檢查頻率需要兼顧即時性與背景開銷；在 iPhone 上設定大量 Provider 並進行高頻檢測，會增加網路延伸的工作量。可配合隨選連線與實際使用頻率調整。

Provider 回傳內容應符合代理提供器格式，而不是完整的 Clash 設定。常見內容以 proxies: 開頭，內部包含節點列表。如果遠端回傳 HTML 登入頁、錯誤提示或一般文字，即使 HTTP 狀態看似成功也無法解析。更新失敗時應檢查回應內容類型、重新導向、存取權限與系統時間。

規則提供器設定

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: "https://rules.example/private-network.yaml"
    interval: 86400

  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/service-domains.yaml
    url: "https://rules.example/service-domains.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT,no-resolve
  - RULE-SET,service-domains,節點選擇
  - MATCH,節點選擇

behavior 決定規則集項目的解讀方式。domain 用於網域集合，ipcidr 用於位址網段，classical 則可容納包含類型與參數的經典規則。format 必須與遠端檔案一致。YAML 規則集通常以 payload: 包裹列表；文字或二進位規則集則使用相應格式。副檔名不能單獨證明內容格式，最終仍要以實際資料結構為準。

payload:
  - "+.example.com"
  - "api.example.net"
  - "*.service.example"

domain 行為規則集中的萬用字元表示方式，應符合 mihomo 規則集語義，不要直接混用瀏覽器匹配模式或正規表示式。classical 規則集則可以寫成 DOMAIN-SUFFIX,example.com 這類完整項目。引用時若加入 no-resolve，應確認規則集確實是 IP 行為，且不需要額外解析。

更新、快取與回退

Provider 更新應是可觀察的獨立步驟。節點突然消失時，先確認遠端檔案是否變更，再查看過濾條件與策略組引用。規則行為突然改變時，記錄規則集更新時間，並檢查資料來源是否調整分類。將所有問題歸因於主設定，會忽略外部資料的變化。

首次執行時必須能夠取得 Provider 檔案，否則引用它的組或規則集無法完整建立。既有快取只適合作為臨時回退，不應長期掩蓋失效 URL。若遠端無法連線，可以在網路允許時完成更新後再啟用對應設定；也可以將關鍵的區域網路與最終兜底規則保留在主設定中，避免基礎連線完全依賴外部規則集。

更新間隔並非越短越好。節點訂閱可能一天更新數次，穩定的規則集可能一天一次或更低頻。高頻更新會增加請求、寫入與解析次數，在行動網路下尤其沒有必要。設定更新失敗時，可依照「位址可存取—回傳內容正確—本機路徑可寫入—格式與 behavior 一致—引用名稱正確」的順序檢查。

08 / Override

覆寫、合併與設定排錯

訂閱、本機覆寫與最終設定

多數客戶端不會直接執行訂閱原文。常見流程是下載訂閱、解析基礎設定、套用本機覆寫或腳本、產生最終設定，再交給 mihomo 核心。理解這一層很重要：你在訂閱網頁看到某條規則，不代表最終執行設定仍維持原樣；同樣，本機編輯過的欄位也可能在下次訂閱更新時被替換。

適合放在訂閱中的內容包括服務端維護的節點、基礎策略組與一般規則。適合放在本機覆寫中的內容包括連接埠、區域網路開關、裝置專用 DNS、個人規則與平台差異。不要直接在自動更新的訂閱檔案中長期維護大量個人修改，否則每次更新都要重新比對。

覆蓋與深度合併並不是同一回事

覆蓋通常表示新值取代舊值；深度合併則會繼續進入映射內部，只替換指定的子鍵。列表的處理差異更大：有些合併器會整段替換列表，有些則支援前置、後置或依名稱修改。不能只憑「merge」一詞判斷行為，應查看客戶端的覆寫說明，並匯出最終設定確認。

# 基礎設定
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

# 預期修改
dns:
  ipv6: false
  nameserver:
    - https://8.8.8.8/dns-query

如果採用深度合併，最終 DNS 可能保留 enable 與 enhanced-mode，同時替換 ipv6 與 nameserver。如果採用頂層覆蓋，原有 DNS 區段可能整體消失，只剩覆寫中的兩個欄位。若列表採用追加策略，兩個 nameserver 可能同時存在。只有查看最終結果，才能知道客戶端採用哪種語義。

規則的前置、後置與刪除

個人規則通常應前置於訂閱規則之前，因為規則命中後就會停止。例如希望某個內部網域直連，就要將它放在可能涵蓋該網域的寬泛代理規則前面。追加到 MATCH 後面不會生效。若覆寫工具支援 prepend 與 append，應將精確例外放到 prepend，並把最終兜底留給主設定。

# 邏輯示意：前置規則
rules-prepend:
  - DOMAIN,router.example,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT

# 邏輯示意：後置內容不能放在 MATCH 之後
rules-append:
  - DOMAIN-SUFFIX,archive.example,節點選擇

上面的鍵名屬於合併邏輯示意，並非所有客戶端都能直接識別。實際操作應使用客戶端提供的覆寫介面，或遵循其文件規定的鍵。刪除規則比新增規則更容易受到文字差異影響：空格、策略組名稱或參數不同，都可能導致精確刪除失敗。更穩妥的方法是用範圍更具體的前置規則覆蓋舊結果，而不是依賴脆弱的字串刪除。

用最小設定定位故障

複雜設定出現問題時，不要同時修改 DNS、節點、策略組與規則。先製作一份最小設定，只保留一個已知節點、一個 select 組與一條 MATCH。若最小設定能夠連線，表示問題位於被移除的層級；接著依 DNS、Provider、策略組、規則的順序逐段加回。若最小設定仍然失敗，則集中檢查節點參數、系統權限與目前網路。

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

proxies:
  - name: Test
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

proxy-groups:
  - name: TEST
    type: select
    proxies:
      - Test
      - DIRECT

rules:
  - MATCH,TEST

在行動端測試時，還要考慮系統 VPN 狀態。先關閉其他可能佔用網路延伸的應用程式，重新啟用目前設定，再觀察客戶端是否成功建立系統 VPN。Wi‑Fi 正常而行動網路失敗時，檢查應用程式的行動數據權限、隨選連線條件與 DNS 可達性；只有某個 Wi‑Fi 失敗時，則檢查該網路的驗證頁面、路由器過濾與私有位址策略。

依錯誤類型分層處理

儲存、回滾與變更記錄

修改前保留一份能正常運作的設定，並為本機副本使用清晰的檔名。每次只修改一類欄位，記錄修改目的與測試結果。發現問題後直接回到上一份可用設定，比憑記憶撤銷多處編輯更可靠。訂閱位址與節點憑證不應放入公開程式碼儲存庫；如需記錄結構，可將伺服器、密碼與存取參數替換成明顯的教學用假值。

完成編輯後依四個層次檢查。第一層是 YAML：縮排、冒號、列表與重複鍵；第二層是引用：策略組、Provider、規則目標名稱一致；第三層是執行：連接埠沒有衝突，DNS 與 Provider 能夠載入；第四層是行為：直連、代理、區域網路與最終兜底分別命中預期。四個層次全部通過，才算設定完成。

從參考手冊回到實際操作

如果目標只是完成首次連線，回到使用文件依序匯入訂閱、選擇模式、建立連線並完成驗證即可。需要更換或安裝客戶端時，可在下載頁選擇 Windows、Android、iOS、macOS 或 Linux 的對應入口。設定已載入但網頁仍提示憑證異常時，可閱讀HTTPS 憑證錯誤的原因與處理方式；iPhone 背景耗電異常則可參考網路延伸背景機制與省電設定。

設定維護的重點不是把所有欄位都寫入同一個檔案，而是保持引用清楚、更新來源可追蹤，並隔離平台差異。主設定負責穩定結構，Provider 負責可更新資料，本機覆寫負責裝置與個人需求。遇到問題時，沿著 YAML、DNS、節點、策略組、規則、系統網路逐層縮小範圍，比整份替換設定更容易找出真正原因。