Clash YAML 設定手冊

設定結構與 YAML 語法

Clash 設定檔描述核心如何監聽請求、解析網域及選擇出口，不等於完整的用戶端介面偏好設定。視窗位置、選單列圖示、開機啟動等項目通常由圖形化用戶端另行儲存。閱讀設定前，先確認目前執行的是哪種核心，以及用戶端實際載入了哪份設定。檔名為 config.yaml，不代表它一定是生效中的檔案；訂閱設定、本機設定與執行時產生的檔案可能同時存在。

映射、清單與縮排層級

YAML 映射以鍵和值表示，清單項目則以連字號開頭。頂層的 dns 是映射，proxies、proxy-groups 和 rules 通常是清單。子欄位的縮排必須比父層多，建議統一使用兩個空格，避免使用定位字元。同一層的欄位應對齊。解析錯誤指向某一行時，真正原因也可能出在上一行，例如引號未閉合，或清單項目漏了連字號。

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

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query

proxies: []

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選擇

這是一份僅包含直連出口的結構範例，不含可連線的遠端代理節點。適合用來檢查 YAML 層級、策略組引用與規則兜底關係，不能取代服務提供者提供的節點設定。不要把各章範例直接首尾拼接成同一個檔案：同名頂層欄位應合併至同一處，尤其不可重複加入兩段 dns 或兩段 rules，再期待核心自動判斷合併方式。

字串、布林值與特殊字元

值中含有冒號後接空格、井字號，或容易產生型別歧義時，建議加上引號。井字號在一般文字中可能表示註解起始，導致後面的內容不再被視為密碼或名稱。布林值直接寫成 true 和 false，連接埠則使用整數。節點名稱、策略組名稱與規則目標都是字串，引用時必須完全一致；可以使用中文名稱，但名稱前後的空格也可能成為字串的一部分。

使用雙引號時請留意反斜線跳脫；一般不需跳脫的字串可使用單引號。編輯器若自動換成彎引號，檔案可能仍能解析，卻讀取出非預期的字串。排查引用失敗時，應比對原始文字，而不只看介面上外觀相近的名稱。不要讓兩個節點或策略組使用相同名稱，也不要用 DIRECT、REJECT 等內建出口名稱替自訂物件命名。

設定來源與驗證方式

訂閱連結回傳的內容不一定是完整 YAML：有些會回傳編碼後的節點清單，有些需要伺服器端轉換，也有些會依請求方式回傳不同格式。匯入失敗時，先在用戶端確認設定類型，再查看解析記錄。網頁回傳的登入頁、錯誤頁或過期提示，即使儲存時加上 YAML 副檔名，也不是有效設定。訂閱網址可能含有存取憑證，不應貼到公開討論區或截圖中。

若裝置已安裝獨立的 mihomo 命令列程式，可在終端機執行下列語法測試。圖形化用戶端內建的核心未必位於 shell 搜尋路徑，因此出現找不到命令，不代表設定檔已損毀。測試時應使用與用戶端相近的核心及相同資源目錄；引用外部規則檔的設定，也需要確認對應檔案存在。測試通過只表示可載入，不能證明遠端節點可連線，或分流結果符合預期。

mihomo -t -f ./config.yaml

建議保留一份可正常連線的原始設定，每次只修改一組相關欄位，並記錄預期變化。發生問題時，便能釐清是語法錯誤、用戶端覆寫、網路無法連線，還是規則比對異常。一次加入大量無關的網路範例，容易讓錯誤互相掩蓋，也會失去可供比較的回復基準。

監聽連接埠與存取範圍

連接埠欄位決定本機應用程式將代理請求交給核心的入口。這些連接埠不等於遠端節點連接埠，也不等於控制介面連接埠。瀏覽器連上本機混合連接埠後，核心才會依規則選擇遠端節點或直連出口。遠端節點的伺服器連接埠則設定在對應節點下。混淆這兩個層級，常見結果是把系統代理指向遠端伺服器，或誤將遠端節點位址改成回送位址。

HTTP、SOCKS 與混合連接埠

一般桌面使用只設定一個混合連接埠即可。範例使用 7890，不代表所有用戶端都採用這個數值；介面顯示、執行設定與系統代理設定必須彼此一致。若分別啟用多個獨立監聽入口，應使用不同連接埠，避免同一位址發生監聽衝突。關閉不需要的入口，比設定所有連接埠欄位更容易理解，也方便確認應用程式目前使用哪個入口。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule

回送位址與區域網路分享

127.0.0.1 是目前裝置的 IPv4 回送位址。手機填入這個位址時，連線的是手機本身，不會連到 Mac。若要將 Mac 的代理分享給區域網路裝置，應明確允許區域網路連線、設定合適的監聽位址，並在其他裝置填入 Mac 實際的區域網路位址。開放監聽後，也要留意防火牆、網路隔離與存取驗證，不能只打開開關就忽略存取範圍。

allow-lan 控制是否允許區域網路請求，bind-address 則用來限制監聽位址。實際能否連線取決於這些欄位的組合、核心行為與系統防火牆。桌面自用建議維持回送位址存取；分享時應限定可信任的網路，不要在路由器上將本機代理連接埠直接轉送至公網。公共 Wi-Fi 中的其他裝置，不會因為位於同一網段就變得可信。

macOS 系統代理欄位

macOS 的網頁代理和安全網頁代理通常都填入本機 HTTP 入口；安全網頁代理這個名稱，不代表本機入口必須另外啟用 TLS。HTTPS 網站通常透過 HTTP CONNECT 建立通道。若用戶端使用混合連接埠，網頁代理、安全網頁代理與 SOCKS 代理可以指向相同的回送位址和連接埠；若使用獨立連接埠，則必須分別對應，不可直接照抄範例數值。

下列指令可查看名為 Wi-Fi 的網路服務目前設定。裝置上的服務名稱可能不同，可先用清單指令確認。系統有多個網路服務時，應檢查實際承載連線的服務；外接網卡、有線網路或服務重新命名，都可能讓檢查對象與實際出口不一致。指令輸出的位址正確，也不表示用戶端確實正在監聽，因此還要檢查本機程序。

networksetup -listallnetworkservices
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi
lsof -nP -iTCP:7890 -sTCP:LISTEN

連接埠遭占用時，先確認是哪個程序正在監聽，不要直接結束不熟悉的系統程序。兩個代理用戶端同時執行，可能爭用連接埠，也可能輪流修改系統代理。退出其中一個後，仍須確認系統設定沒有殘留。更換連接埠後，也要同步更新 shell 環境變數、編輯器代理設定及其他手動填入代理位址的應用程式；否則瀏覽器恢復正常，部分應用程式仍可能連到舊位址。

執行模式與流量入口

執行模式決定請求進入核心後如何選擇出口；系統代理與 TUN 則決定請求如何進入核心。這是兩個不同的問題。啟用規則模式不會自動接管所有應用程式，啟用 TUN 也不代表所有流量都必須經過遠端代理。說明連線行為時，應先確認應用程式使用哪個入口，再確認核心目前採用哪種執行模式，最後查看該連線的比對結果。

規則、全域與直連模式

mode: rule 依規則清單的順序選擇策略；mode: global 使用全域策略；mode: direct 則採用直連方式。這些模式不是連線品質等級，也不是網路權限層級。全域模式適合短暫用於比對測試，協助判斷問題是否與規則有關，但不應把它當成解決所有問題的開關。若選取的遠端節點本身無法連線，切換全域模式通常不會改善結果。

mode: rule
log-level: info
ipv6: false

圖形化用戶端通常可在介面中切換模式，但介面狀態可能是透過控制介面修改執行中的核心，不一定會寫回原始 YAML。重新載入設定後，模式能否保留取決於用戶端的儲存方式。排查時應同時檢查檔案與即時介面，不能只憑編輯器中的 mode 值判定目前狀態。用戶端的執行記錄、連線頁面與產生的設定檔，是更直接的觀察依據。

系統代理與終端機環境變數

系統代理主要影響遵循系統代理設定的應用程式。許多命令列程式有自己的代理設定邏輯，預設不會讀取 macOS 網路設定。可在目前的 shell 暫時設定環境變數，再進行比對測試；新開的終端機視窗不會自動繼承另一個視窗之後新增的變數。不同工具支援的變數名稱與大小寫可能不同，遇到問題時應查閱該工具的說明文件，而不是反覆切換系統代理。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com

unset http_proxy https_proxy all_proxy

此處的 socks5h 表示支援這種寫法的工具會將目標網域交由代理端解析，與先在本機解析再傳送位址不同。環境變數只會影響讀取它們的程式，不會改變整個作業系統的網路路由。有些工具同時提供命令列參數與設定檔，優先順序也可能高於環境變數；驗證時應盡量減少重複設定，避免無法判斷究竟是哪一層生效。

TUN 設定與權限範圍

TUN 透過虛擬網路介面接收更廣泛的 IP 流量，通常需要用戶端安裝輔助服務或取得相應權限。以下是 mihomo 常見的欄位組合，不是所有圖形化用戶端都採用相同的設定方式。有些用戶端會接管 TUN 欄位、自動選擇介面或產生排除路由，建議優先使用該用戶端支援的設定入口。完整啟用步驟請參閱TUN 模式教學。

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

auto-route 會讓核心嘗試建立相應路由，auto-detect-interface 用於自動辨識出口介面。切換無線網路、連接擴充基座或啟動其他 VPN 後，出口介面與路由可能改變。連線中斷時應檢查介面與路由狀態，不要立刻歸咎於節點。企業 VPN、虛擬機器和其他網路延伸功能可能同時修改連線路徑，搭配使用時應逐一啟用並觀察。

DNS 劫持規則也有適用範圍：上述設定針對一般 DNS 連接埠的流量，不代表會自動接管所有應用程式內建的加密 DNS。啟用 TUN 後若只有部分網域異常，應一併檢查 DNS 模式、應用程式自身設定及路由排除項目。關閉用戶端前，也應讓它正常解除接管，避免強制結束程序後留下暫時無法使用的網路狀態。

排查時可依固定順序比對：先關閉其他 VPN，只用系統代理測試；確認入口可用後再啟用 TUN；最後重新啟用其他網路工具。每次只變更一個條件，並記錄瀏覽器、終端機與特定應用程式的差異。Windows 的應用程式回送是另一種平台機制，並非 macOS TUN 的同義詞，相關補充請參閱Windows 應用程式回送說明。

DNS 欄位與網域解析路徑

DNS 設定需要釐清三件事：應用程式的查詢是否進入核心、核心使用哪個解析器，以及解析結果如何影響後續連線。只填入一個公共 DNS 位址，不代表所有應用程式都會使用它。在系統代理情境中，應用程式可能先呼叫系統解析器；透過 HTTP CONNECT 或遠端解析的 SOCKS 請求則可能保留網域名稱。TUN、應用程式內建的加密 DNS 與本機快取，也會改變實際觀察到的路徑。

基本解析器與引導解析

dns.enable 用來啟用核心 DNS 模組，nameserver 則指定一般上游解析器。若加密 DNS 位址使用網域名稱，就需要先解析該網域；default-nameserver 可用於這類引導解析，適合填入明確的 IP 位址。不要讓所有解析器都依賴彼此的網域名稱，再期待它們透過尚未建立的代理鏈路完成首次連線。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

此範例用來說明欄位之間的關係，不代表某個公共解析器適用於所有網路。選擇上游解析器時，應考量目前網路能否直接連線、組織內部網域是否需要專用解析器，以及遠端節點所在網路的解析需求。proxy-server-nameserver 用於解析代理伺服器網域，可將節點位址解析與一般網站解析分開處理，降低啟動時發生循環依賴的風險。

fake-ip 與真實位址模式

fake-ip 模式會為符合處理條件的網域回傳合成位址，核心再利用對應關係還原原始網域，進行連線與規則判斷。範例網段屬於基準測試用途的位址空間，不是遠端代理伺服器位址。應用程式看到這類位址，不一定代表解析錯誤；但若取得合成位址後繞過核心，連線就可能失敗，因此解析入口與流量入口必須一致。

使用真實位址回應的模式較接近傳統 DNS 行為，但網域與連線之間的關聯可能受到應用程式快取、共用 IP 或連線方式影響。兩種模式沒有絕對優劣。區域網路探索、遊戲、裝置管理，或某些會明確驗證位址的應用程式，可能需要排除 fake-ip。新增過濾項目之前，應先確認問題確實來自位址相容性，而不是遠端節點或目標服務無法連線。

依網域選擇解析器

nameserver-policy 可為指定網域選擇解析器，適合將公司內部網域交由內部 DNS 解析。以下以範例網域和私有網路位址說明結構，實際使用時必須換成組織提供的正確值。若內部 DNS 只能透過企業 VPN 存取，也要確保路由允許查詢送達該位址。將內部網域交給公共解析器，通常無法取得有效結果，也可能暴露不必要的查詢資訊。

dns:
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.10.1

這段設定應合併至現有的 dns 映射，不能再追加第二段同名的頂層欄位。引入依規則選擇 DNS 出口的進階設定前，應先建立可正常運作的基本解析鏈。某些 DNS 路由選項會讓解析請求也參與規則判斷；若規則判斷本身又需要 DNS，就應依核心文件處理相依關係，而不是一味增加解析器數量。

DNS 問題的觀察順序

先確認用戶端記錄中是否出現對應查詢，再檢查回應位址與連線最後選擇的出口。一般的 dig 測試通常無法證明應用程式內建的加密 DNS 行為；瀏覽器能開啟網頁，也不代表終端機使用相同的解析路徑。修改設定後，瀏覽器、系統與核心可能各自保留快取；需要關閉舊連線並重新發出請求，必要時再依用戶端提供的方法清除快取。

IPv6 也需要分層理解：頂層開關、DNS 是否回傳 IPv6 位址，以及作業系統是否有可用的 IPv6 路由，是不同條件。關閉其中一個欄位，不能一概解釋所有 IPv6 問題。遇到連線緩慢或首次請求等待時，應比對解析時間、建立連線的時間與所選出口，並依照網速緩慢的分層排查方法繼續定位，避免把所有等待都歸咎於 DNS。

代理節點欄位與遠端服務提供者

代理節點描述一種具體的遠端連線方式，核心欄位包括協定類型、伺服器位址、伺服器端連接埠與驗證參數。策略組負責選擇節點，規則負責選擇策略組，三者不能互相取代。服務提供者提供的節點欄位應是主要依據，不要只根據節點名稱猜測協定。例如名稱中出現某種協定字樣，也只是標籤；核心實際採用的協定仍由 type 欄位決定。

通用欄位與協定專用欄位

name 用於供策略組引用，server 是伺服器網域名稱或 IP，port 是遠端服務的監聽連接埠。驗證方式依協定而異：有些使用密碼，有些使用使用者識別碼，有些則同時需要 TLS 與傳輸參數。欄位名稱相似，不代表可以跨協定照搬。以下的 Shadowsocks 範例僅說明結構，其中的網域與密碼是教學用假資料，無法直接建立遠端連線。

proxies:
  - name: "範例出口"
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

加密方式、密碼與伺服器端連接埠必須與服務端一致。連接埠使用常見的網頁服務連接埠，不代表該節點就是 HTTPS 服務，也不代表一般瀏覽器可以直接連線。udp: true 只表示設定允許相應功能，實際能否使用仍取決於協定實作、服務端支援、上游網路與應用程式的請求路徑。UDP 無法連線時，應檢查整條鏈路，而不是反覆切換這個欄位。

TLS、伺服器名稱與傳輸參數

對於啟用 TLS 的協定，需了解連線位址與憑證驗證名稱可能不同。server 決定連線目標；部分協定中的 servername 等欄位則用於傳送及驗證伺服器名稱，實際名稱取決於協定設定格式。WebSocket 路徑、請求標頭、gRPC 服務名稱等，也必須與服務端一致。漏掉這些參數時，TCP 連接埠可能可連線，但上層交握仍會失敗。

發生憑證錯誤時，應先檢查系統時間、伺服器名稱、憑證鏈與服務端部署。略過憑證驗證會改變安全範圍，不應當成通用排錯方式。也不要在不清楚用途時自行加入指紋、傳輸最佳化或連線重用欄位；某個欄位在其他協定中有效，不代表目前協定支援。解析器接受了未知或無關欄位，也不代表這些欄位會產生預期效果。

遠端節點集合與健康檢查

proxy-providers 可將節點來源與主設定分開，適合定期更新節點集合。提供者檔案必須符合節點提供者的結構，不能任意將包含完整規則與 DNS 的訂閱當成相同類型的輸入。以下展示遠端來源的寫法，連結僅供教學示範；正式設定應使用可信任的來源，並將存取憑證視為機密資訊，不要提交至公開儲存庫。

proxy-providers:
  remote-pool:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote-pool.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

interval 表示更新間隔，健康檢查間隔則用來控制可用性測試，兩者用途不同。路徑是相對於核心的工作目錄；圖形化用戶端可能使用專用資料目錄。更新失敗時，應區分遠端回應異常、格式不符與本機目錄無法寫入；既有快取是否仍可使用，也要依記錄判斷。未備份前不要直接刪除快取，以免一併清除原本仍可運作的節點集合。

節點名稱與引用穩定性

訂閱更新可能變更節點名稱。手動策略組若逐一引用舊名稱，更新後可能找不到對應節點。透過提供者的 use 引入整個集合，通常比複製大量節點名稱更容易維護，但篩選條件也需要配合命名方式調整。合併多個來源時應避免名稱重複；重名不只是顯示問題，也會讓策略選擇、記錄閱讀與覆寫定位變得不明確。

節點清單顯示出來，不代表已完成可用性驗證。排查應依序檢查網域解析、伺服器連線、協定交握，再到目標存取。單一節點失敗時，先與同一策略組中的其他節點比較；所有節點都失敗時，再檢查本機網路、入口、系統時間與設定來源。測速結果也不代表所有網站、協定與時段的實際表現。

選擇用戶端時，可先查看macOS 下載入口中的 Clash Plus，再依功能需求比較 Clash Verge Rev 與 FlClash。用戶端介面相似，不代表支援的核心欄位完全相同。若想了解圖形化用戶端與核心的分工，可繼續閱讀Clash 開源生態與 mihomo 的關係，再決定應在哪一層維護設定。

策略組欄位與健康檢查

策略組會將節點整理成可供引用的出口名稱。規則通常指向策略組，而非經常變動的個別節點，這樣更換節點時就不必重寫整套規則。一個策略組也能引用另一個組，形成手動選擇與自動選擇的層次。不過，引用關係不可形成循環，組名必須唯一，且所有被引用的物件都必須存在於最終執行設定中。若節點只存在於原始訂閱，卻被覆寫移除，同樣會造成問題。

手動選擇組與巢狀關係

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - 自動選擇
      - DIRECT

  - name: "自動選擇"
    type: url-test
    use:
      - remote-pool
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

範例中的 remote-pool 對應上一章定義的提供者。proxies 列出指定節點或組名，use 則引入提供者集合。使用 select 時，實際出口取決於使用者目前的選擇；清單中的某個節點發生連線問題時，不會自動改選，除非使用者選的是內部具備自動選擇功能的子組。清單順序也不代表目前的選擇狀態。

多層巢狀適合拆分地區、用途與選擇方式，但層數過多會降低可讀性。連線頁面顯示命中某個規則目標後，仍須沿著策略組目前的選擇確認最終節點。排錯時可先建立一個直接引用已知節點的簡單選擇組，確認節點本身可用，再恢復自動組與較複雜的巢狀結構。這樣能區分策略邏輯與遠端連線問題。

自動選擇、故障切換與負載平衡

url-test 的結果反映的是存取指定測試網址的表現，不是下載頻寬，也不是對所有目標服務的綜合評分。tolerance 用來減少小幅差異造成的頻繁切換，單位是毫秒；它不代表固定延遲保證。候選節點品質相近時，適度容許差異通常比追求每次測量的最低值更能維持出口穩定。

fallback 依候選順序表達優先順序：前面的節點可用時優先採用，而不是永遠選測試值最低的節點。load-balance 則依設定的分配策略處理連線，不會把單一連線拆成多條線路來疊加頻寬。涉及登入狀態、地區判定或工作階段一致性的應用程式，應考量多出口可能造成的影響，不要只因名稱中有負載平衡就預設啟用。

探測網址、間隔與延遲檢測

測試網址應穩定、回應輕量，並能代表需要觀察的連線狀況。若某個節點無法存取測試網站，卻能存取實際目標，自動策略仍可能依目前的測試條件判定該節點不適用。反過來說，測試通過也不代表所有服務都能使用。選擇測試網址時應了解這些限制，不要把它當成整個網際網路的健康狀態指標。若發生誤判，應比對實際目標請求與記錄。

縮短 interval 會提高探測頻率，也會增加請求數量與裝置資源消耗，不會直接提升節點頻寬。提供者健康檢查與策略組測試同時啟用時，還可能重複探測。有些策略組支援延遲檢測，未使用時會減少檢查；因此剛切換到該組時，可能需要等待狀態更新。應依使用習慣設定間隔，不要一律改成極短時間。

篩選條件與選擇狀態

使用 filter 或排除條件篩選提供者節點時，先確認名稱確實包含預期內容。正規表示式中的括號、直線符號與特殊字元各有意義，不能把一般描述直接當成可靠的篩選條件。訂閱改名後，策略組可能變成空組；調整篩選條件後，應展開清單檢查，而不只是確認組標題仍在。候選清單為空，通常是自動組異常的重要線索。

若用戶端或設定啟用了選擇狀態儲存，重新載入設定後可能會還原上次的手動選擇；名稱變更後則可能無法還原。測試 YAML 清單順序時，應先確認目前實際選擇的項目，不要以為永遠會使用第一項。三種自動策略的細節與使用情境，請參閱url-test、fallback 與 load-balance 比較，再決定是否需要調整現有策略組。

規則語法與比對順序

規則清單是一個依序執行的決策流程。核心由前往後檢查，命中後就採用對應出口，因此即使規則相同，順序不同也可能得到不同結果。撰寫規則時，應先列出明確例外，再加入範圍較廣的規則，最後設定兜底規則。不要把 MATCH 放在清單開頭，再期待後面的網域規則生效；兜底規則已接收所有未受限制的請求。

網域、後綴與關鍵字規則

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選擇
  - DOMAIN-KEYWORD,example,出口選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,出口選擇

DOMAIN 比對完整網域，適合設定單一主機的例外；DOMAIN-SUFFIX 比對網域本身及其子網域；DOMAIN-KEYWORD 則依包含關係比對，範圍更廣，也更容易命中無關服務。規則中的網域不應附加 https://、路徑或查詢參數，因為此處處理的不是完整網頁網址。需要區分特定主機時，應優先使用範圍明確的規則。

每條規則最後指定的目標，必須是已存在的節點、策略組或內建出口。中文逗號不能取代英文逗號，名稱中多出的空格也會讓引用難以核對。目標不存在時，不要只檢查規則本身，也要確認前面的節點合併或策略組覆寫是否改變名稱。對於經常更新的節點集合，指向穩定的策略組名稱通常比直接指向單一節點更容易維護。

IP 規則與解析副作用

IP-CIDR 和 IP-CIDR6 依據位址網段判斷。若請求只有網域名稱，有些 IP 類規則可能需要先解析網域再進行比對。加入 no-resolve 可避免該規則為了比對而主動發起解析，但不能簡單理解為忽略所有 IP 請求：若連線已帶有目標 IP，仍可能依該位址比對。這個選項控制的是解析行為，不是直連或代理行為。

私有網段規則適合用來保護區域網路存取，但實際網路也可能包含其他位址範圍與特殊路由。不要只因某次查詢發現目標使用某個位址，就把整個寬廣的公網網段設為直連。大型服務可能共用位址，解析結果也會隨網路改變。能以明確網域設定的策略通常較穩定；若必須依 IP 分流，應了解網段範圍與更新來源。

遠端規則集與宣告方式

rule-providers:
  local-services:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-services.yaml

rules:
  - RULE-SET,local-services,DIRECT
  - MATCH,出口選擇

對應的規則檔採用下列結構。此處的 behavior: domain 表示載荷是網域比對內容，不是完整的逐條規則敘述。若提供者使用 classical，載荷格式與可用規則類型也會不同。規則提供者的宣告方式、檔案格式與實際內容必須一致；副檔名相同不代表內部結構相同，下載失敗時回傳的網頁也不能當成規則集載入。

payload:
  - "+.example.org"
  - "router.example.com"

規則集只儲存比對內容，實際採用哪個出口，則由主設定中的 RULE-SET 規則決定。規則集成功載入，不代表其中每個網域都會使用預期出口：前面的規則可能已先命中。更新規則集後，也要觀察連線頁面顯示的實際規則類型與目標。不要只為了修正一個網域，就把整組遠端規則移到最前面，以免改變原本需要優先保留的區域網路與業務例外。

連線重用與驗證方式

修改規則通常只會影響新建立的連線；既有長連線、瀏覽器連線集區與應用程式工作階段，可能繼續沿用原本的路徑。驗證時應關閉相關連線，再向明確的目標發出請求，同時觀察比對規則、策略組與最終節點。單一網頁可能存取多個網域；主文件、圖片、登入與 API 請求未必使用相同路徑。僅憑網頁能否開啟，無法判定每個子請求的策略都正確。

並非所有連線入口都能直接取得網域資訊。應用程式直接連線至 IP、使用自有解析機制或重用既有連線時，規則可取得的資訊可能不同。嗅探功能可在適用情境補充網域資訊，但無法辨識完整網址，也不保證能從所有加密連線還原資訊。排查時應以連線記錄實際顯示的中繼資料為準，不要假設核心已看到瀏覽器網址列中的所有內容。

設定覆寫、合併與驗證流程

覆寫可在保留訂閱更新能力的同時，維持本機連接埠、DNS、規則或策略選擇。關鍵不在於額外寫了一份 YAML，而在於用戶端如何合併多個來源，產生最終設定。原始訂閱、本機覆寫、用戶端偏好與執行時 API 修改，可能位於不同層級。哪一方最後決定某個欄位，沒有適用所有用戶端的通用答案，應以目前用戶端的合併說明和實際產生結果為準。

純量、映射與清單的差異

純量欄位通常由後者覆蓋前者，例如混合連接埠從一個數值變更為另一個數值。映射可能採用深度合併，也可能整段取代；清單則可能取代、插入前端、附加至後端，或交由專用指令碼處理。不要把某個用戶端的合併經驗直接套用到另一個用戶端。尤其是規則清單，整段取代會遺失原有規則；附加至後端則可能落在 MATCH 之後，導致規則無法實際比對。

區分訂閱內容與本機差異

節點憑證與遠端節點集合適合隨可信任的訂閱更新；監聽連接埠、區域網路權限與本機 DNS 例外則適合保留在本機。不要直接修改臨時下載的快取檔，再期待下次更新時修改內容仍會保留。也不要將目前裝置的網卡名稱、絕對路徑與本機監聽位址同步到所有裝置；不同作業系統與用戶端的資料目錄、權限機制及支援欄位都可能不同。

# 本機欄位範例；合併方式以用戶端說明為準
mixed-port: 7890
allow-lan: false
log-level: info

profile:
  store-selected: true

此範例只表示希望保留的本機欄位，不會定義規則合併演算法。profile.store-selected 用於儲存策略組選擇，與用戶端是否儲存訂閱檔是兩回事。若用戶端已有相應設定，應確認介面產生的值與覆寫值何者優先。同一欄位若在多處維護，容易出現編輯器中的值和介面顯示不一致，增加後續排錯成本。

檢查最終設定與精簡修改

開始修改前，先匯出或備份目前可用的設定，並記錄使用的用戶端、核心類型與重要開關。修改後查看最終執行設定，確認目標欄位是否存在、是否被其他層級覆蓋，以及引用的組名是否仍然有效。原始訂閱未變，但執行設定有變化，是正常的產生流程；若原始檔案修改成功，執行設定卻沒有變化，可能是編輯了錯誤的項目，或尚未觸發重新產生。

驗證可分成四個層次：先檢查 YAML 語法與核心載入狀況，再確認本機連接埠正在監聽，接著測試明確的代理請求，最後觀察規則與最終出口。每個層次都有不同的判斷依據。語法通過不代表節點可連線，節點可連線不代表系統代理已設定，瀏覽器可用也不代表終端機走代理。逐層確認，才能避免在錯誤的設定區域反覆嘗試。

mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --proxy http://127.0.0.1:7890 -I https://example.com

命令列測試應與用戶端的實際環境比對。獨立核心的工作目錄、規則快取與權限可能不同，不能只因獨立測試成功就排除用戶端產生設定時的問題。重新載入設定後，請留意記錄中的解析失敗、物件不存在與監聽失敗，並優先處理最早出現的明確錯誤。後續大量連線失敗往往只是前面的載入錯誤所致，不宜逐一當成獨立的網路故障處理。

回復、分享與常見問題

若修改後導致連線中斷，先還原上一份可用設定，停用新加入的覆寫，再逐項重新加入差異。保留原始訂閱，不要用臨時測試檔覆蓋唯一副本。跨裝置同步時，只分享確實通用的內容，將本機路徑、網路介面與裝置專屬規則留在裝置端；訂閱網址與節點密碼應存放在受控位置。具體作法請參閱多裝置設定同步說明。

維護設定的目標，是讓每個欄位都有明確來源、每條規則都有合理順序，且每次變更都有可還原的基準。遇到問題時先縮小範圍，再逐步增加細節。需要重新安裝或比較用戶端時，請前往下載頁；需要依序完成匯入、模式選擇與連線驗證時，請返回快速入門教學，不要把參考手冊當成必須一次啟用所有欄位的清單。