Clash Meta 進階設定手冊

01

策略組類型與實務

策略組是設定中的決策層。代理節點解決「如何建立連線」，策略組則解決「這類流量應交給誰」。一份易於維護的設定，通常不會讓規則直接指向特定節點，而是先建立「日常選擇」「自動測速」「故障轉移」「下載分流」等穩定名稱，再由規則引用這些名稱。如此一來，更換訂閱或節點名稱後，規則層不必跟著重寫。策略組名稱可以使用中文，但必須在 proxy-groups、rules 及其他群組的 proxies 中完全一致，空格、大小寫與符號都不能省略。

select、url-test、fallback 與 load-balance

select 是手動選擇組，適合需要明確指定出口的情境。它本身不會判斷節點品質，只會保存目前的選擇。將自動組、故障轉移組與少量常用節點放入一個 select 組，可在穩定性與人工控制之間切換。url-test 會依設定的間隔存取測試網址，從可用節點中選擇測得延遲較低的項目；適合網頁瀏覽、API 請求等重視回應速度的短連線。測速結果只代表目前裝置到測試目標的表現，不等於所有網站與串流服務都有相同速度。

fallback 依清單順序檢查可用性，優先使用前面的節點，只有目前節點不可用時才切換到下一項。適合固定主要線路與備援線路的結構，也適合登入狀態或出口地區不宜頻繁變動的服務。load-balance 會將不同連線分配給多個節點，可用於並行下載或存取多個目標；但同一網站的多條連線若從不同出口送出，可能觸發登入驗證。因此負載平衡不應直接取代日常預設組，而應由獨立規則精確引用。

一套易於維護的分層結構

以下結構將節點來源交由代理提供者管理，把自動選擇與故障轉移做成底層群組，再由「預設代理」統一提供給規則使用。include-all: true 會將可用代理提供者中的節點納入群組；如果客戶端或現有設定不使用代理提供者，也可以改為明確列出 proxies。interval 是健康檢查或測速間隔，單位為秒；tolerance 表示新結果必須比目前節點好多少才會切換，設定適當容差可避免兩個延遲接近的節點頻繁來回跳轉。

proxy-groups:
  - name: 預設代理
    type: select
    proxies:
      - 自動選擇
      - 故障轉移
      - DIRECT

  - name: 自動選擇
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 故障轉移
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300

測試網址應回傳內容量小且狀態穩定的回應。若目前網路會將目標重新導向、套用快取或無法存取，群組內的節點可能全部顯示失敗。此時先在日誌確認是 DNS 解析失敗、連線逾時還是 TLS 錯誤，再考慮替換測試網址。不要為了取得更小的數字而將測速間隔設得過短；頻繁測試會增加連線數與耗電量，也可能讓行動網路持續喚醒。

依用途拆分群組，而不是堆疊節點

長期設定較適合依用途命名，例如「串流服務」「開發服務」「大型檔案下載」，而不是把所有地區與節點都攤成幾十個入口。用途組可以引用地區組，地區組再引用自動測速組，形成清楚的兩到三層關係。層級過深會增加故障排除難度，也可能形成循環引用；若 A 組包含 B，而 B 又包含 A，設定檢查就會失敗。修改後應先使用客戶端的設定檢查功能或 mihomo 的測試啟動方式確認語法，再觀察日誌中規則最後命中的策略組。關於三種自動組的判斷差異與搭配案例，可繼續閱讀策略組類型選擇指南。

02

規則集訂閱化管理

規則決定請求進入直連、代理、拒絕或某個用途策略組。將數千條網域與 IP 直接寫入主設定雖然可以執行，但更新、審閱與定位都會變得困難。rule-providers 會將規則內容拆成獨立檔案，由主設定宣告來源、行為類型、儲存路徑與更新間隔，實際規則只需使用 RULE-SET 引用。如此可分別更新媒體規則、內網規則或開發服務規則，也能在規則來源暫時無法使用時繼續採用本地快取。

behavior 與 format 必須符合內容

behavior 描述規則集儲存的內容形式。domain 用於網域項目，適合完整網域、網域後綴與關鍵字集合；ipcidr 用於 IPv4、IPv6 網段；classical 儲存帶有類型前綴的完整規則，例如 DOMAIN-SUFFIX,example.org 或 IP-CIDR,192.0.2.0/24。三者不能只靠修改欄位名稱互相轉換，遠端檔案的實際結構必須與宣告一致。format 常見值為 yaml、text 或 mrs，使用哪種格式取決於規則來源提供的檔案，不能將一般文字連結宣告為二進位規則格式。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.com/private-domains.yaml
    path: ./ruleset/private-domains.yaml
    interval: 86400

  private-networks:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.com/private-networks.yaml
    path: ./ruleset/private-networks.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - RULE-SET,private-networks,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,預設代理

範例網域僅用於說明結構，實際使用時應替換為可信規則來源提供的完整檔案網址。path 是核心工作目錄下的快取位置，不同客戶端選用的工作目錄各異；手動執行 mihomo 時，應確保程序具備該目錄的寫入權限。規則檔案首次下載失敗且本地沒有快取時，對應提供者就無法參與比對。若先前曾成功下載，核心通常可以繼續讀取快取，但不會取得遠端新增內容。

規則依序由上而下比對

rules 的順序具有決定性：請求命中第一條適用規則後，就會停止繼續比對。因此範圍較小、意圖明確的規則應放在前面，寬泛規則放在後面，MATCH 只能作為最後的兜底。例如公司內部網域需要直連，就應置於通用代理網域集合之前；區域網路網段也應在寬泛 IP 規則之前處理。若將大範圍代理集合放在最前面，後面的直連例外即使語法正確也永遠不會觸發。

no-resolve 用於 IP 類規則，表示比對階段不要為了取得目標 IP 而主動發起額外 DNS 解析。它能減少無意義的查詢，也可避免網域尚未解析時改變比對路徑。但並非每條規則都應機械式加入；網域規則本身依賴網域，程序只提供 IP 且沒有嗅探結果時，也需要後續 IP 規則負責判斷。分析規則問題時，應同時查看日誌中的目標主機、規則類型與最終策略，而不只是看策略組名稱。

更新失敗與回復處理

規則集更新失敗通常有四類原因：遠端網址失效、DNS 無法解析、下載必須經過代理但目前策略尚未就緒、快取目錄無法寫入。先查看日誌中的 HTTP 狀態或網路錯誤，再用瀏覽器或命令列從同一裝置存取規則網址。若只有核心無法存取，應檢查規則提供者是否需要透過代理下載，以及啟動初期 DNS 是否能解析規則來源網域。目錄權限問題則會出現建立檔案、重新命名暫存檔或寫入失敗的提示。

遠端規則不代表每次啟動都必須連線取得。適合正式環境的做法是保留最近一次可正常工作的快取，更新前檢查檔案格式，並控制變更範圍。一次同時替換所有規則來源、DNS 設定與策略組，出錯後很難判斷是哪一層造成。較穩妥的順序是先新增提供者但不引用，確認下載成功；再加入一條 RULE-SET 並觀察命中情況；最後刪除舊規則。需要回復時恢復主設定引用即可，快取檔案可保留以供核對。

規則數量不等於設定品質

更多規則不會自動帶來更精準的分流。重複集合會增加載入時間，也可能讓同一網域在不同集合中得到互相衝突的結論。應先依需求確定少量用途組，再選擇涵蓋這些用途的規則集。遇到「某網站走錯群組」，先在日誌中找出實際命中的第一條規則，再調整順序或加入精確例外；直接更換整套規則往往會引入新的未知變化。GeoIP 或規則提供者更新異常的進一步檢查，可前往常見問題查看對應故障分支。

03

DNS 設定最佳化

DNS 層負責將網域轉換為位址，也直接影響規則能否看見正確目標。常見的「節點可用但網頁打不開」「同一網域偶爾直連、偶爾代理」「日誌只顯示 IP、無法判斷網域」等問題，往往不是節點速度，而是 DNS 請求路徑、快取結果與流量接管方式沒有對齊。設定 DNS 時需要先回答三個問題：由誰接管查詢、送往哪些解析器、解析器本身的網域又如何解析。釐清這三層關係後，再決定是否啟用 Fake-IP。

nameserver、default-nameserver 與代理專用解析

nameserver 是一般網域查詢的主要解析器，可以填寫傳統 UDP/TCP DNS，也可以使用 DoH 等加密形式。default-nameserver 主要用於解析 DoH 伺服器網域、代理伺服器網域等啟動階段的依賴項，適合填寫可直接存取的 IP 形式解析器，避免「必須先解析 DNS 服務網域才能使用該 DNS 服務」的循環。proxy-server-nameserver 可專門處理代理節點伺服器網域，將節點位址解析與一般業務網域分開，降低業務規則反過來影響代理連線的可能性。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

範例展示欄位關係，不代表所有網路都適合同一組解析器。選擇 DNS 服務時應考量目前網路的可達性、回傳結果與隱私需求。若某個 DoH 服務必須透過代理才能存取，而啟動階段又把它設為唯一解析入口，可能形成代理尚未建立、DNS 卻已等待代理的依賴環。保留能直接存取的基礎解析路徑，並讓代理伺服器網域獨立解析，通常更穩定。

nameserver-policy 的比對用途

nameserver-policy 可依網域、規則集合或 geosite 分類指定解析器。例如將本地域名交給距離較近的解析器，其他網域交給另一組解析器。它解決的是「查詢送給誰」，不是「最終流量經過哪個代理組」；連線策略仍由 rules 決定。DNS 政策與路由規則可以採用相似分類，但不必完全相同。若將大量互相重疊的網域集合同時寫入策略，排查時會難以確定實際使用了哪個解析器，因此仍應維持從精確到寬泛的順序。

respect-rules: true 表示 DNS 連線本身遵循路由規則。啟用後應確保 DNS 伺服器的網域與位址具備可完成啟動的路徑，否則解析器請求可能被送往尚未可用的策略組。修改此項後若所有網域都解析失敗，應先暫時使用可直接存取的解析器驗證，再檢查 DNS 服務網域命中了哪條規則。

IPv6、快取與結果差異

ipv6: false 通常表示 DNS 模組不回傳 AAAA 結果，適合裝置或出口沒有穩定 IPv6 連線能力的情況。如果本地網路與代理節點都具備可用 IPv6，則可以開啟，但需要同時檢查 TUN、系統路由與規則對 IPv6 網段的處理。只在 DNS 中開啟 IPv6，而 TUN 或出口不支援，可能導致應用程式優先嘗試 IPv6 後長時間等待，再回退至 IPv4。

變更 DNS 後，舊結果可能仍存在於作業系統、瀏覽器、客戶端與核心快取中。排查時先重新啟動相關客戶端或清除系統 DNS 快取，再對同一網域進行重複測試。瀏覽器也可能啟用獨立的安全 DNS，繞過系統解析路徑；如果系統工具解析正常而只有瀏覽器異常，應檢查瀏覽器本身的設定。反過來，瀏覽器正常、終端機異常，則更可能是系統 DNS、環境變數或終端程式沒有經過預期的流量入口。

04

TUN 與 Fake-IP

系統代理依賴應用程式主動讀取代理設定，瀏覽器通常支援良好，但部分終端程式、遊戲、系統服務與使用自訂網路堆疊的應用程式可能完全忽略。TUN 模式透過虛擬網路卡與系統路由接管更廣泛的 TCP、UDP 流量，再交由 mihomo 處理。Fake-IP 則在 DNS 階段為網域分配保留位址，應用程式連線至該位址時，核心會依映射還原原始網域，讓網域規則在更多情境下生效。兩者經常搭配使用，但職責不同：TUN 負責接管，Fake-IP 負責網域映射。

TUN 基本設定與平台權限

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

stack 決定由哪種網路堆疊處理 TUN 封包，mixed 是常見的相容選擇；實際可用值與效果取決於核心能力及平台實作。auto-route 會自動新增必要路由，auto-detect-interface 會依預設出口辨識實體網路卡，在有線、無線、手機熱點或 VPN 之間切換時尤其實用。dns-hijack 會將符合條件的 DNS 請求交給核心 DNS 模組，避免系統繼續向原解析器發送查詢。strict-route 會更嚴格限制繞過路徑，可減少洩漏與路由偏差，但也更容易暴露虛擬機、區域網路共享或其他 VPN 的路由衝突。

建立虛擬網路卡與修改路由通常需要系統管理員權限。Windows 客戶端可能透過服務模式完成權限操作；macOS 會要求網路延伸功能或系統權限；Linux 直接執行核心時需要相應的網路能力，也要注意 systemd 服務的權限設定。啟用後若整台裝置斷網，第一步不是更換節點，而是關閉 TUN，確認系統基礎網路能否恢復，再檢查虛擬網路卡是否建立成功，以及預設路由是否遭到錯誤覆蓋。

Fake-IP 的運作路徑

在 enhanced-mode: fake-ip 下，DNS 模組會從 fake-ip-range 中的位址為網域回傳 Fake-IP。應用程式隨後連線至該位址，核心從映射表取得原始網域，再依網域規則選擇策略並解析真實目標。198.18.0.0/15 屬於基準測試用途的保留位址範圍，常用於此類映射；不要將 Fake-IP 位址誤認為遠端伺服器的真實位址。在封包擷取或日誌中看到該網段，不代表 DNS 被劫持至陌生主機，而是映射鏈路正在運作。

Fake-IP 的優點是能較完整保留網域資訊，讓規則判斷更直接，也減少應用程式提前取得真實 IP 後繞過網域規則的情況。代價是少數應用程式會驗證 DNS 回應、依賴區域網路探索、使用特殊 UDP 協定，或將解析結果傳給不經過同一核心的程序，這些情境可能不適合映射。此時應透過 fake-ip-filter 為特定網域回傳真實位址，而不是完全關閉 Fake-IP。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - geosite:private

blacklist 模式表示清單內的網域不使用 Fake-IP，其餘網域繼續進行映射。過濾範圍應盡量精確。直接加入過寬的萬用字元，會讓大量請求回到真實 IP 模式，削弱網域規則效果。區域網路裝置探索異常時，可以先針對裝置使用的 .local、私人網域或廠商服務加入例外，再觀察日誌，不應一次排除整個常見頂級網域。

與其他 VPN、虛擬機及區域網路的衝突

TUN 與企業 VPN、遊戲加速工具、虛擬機網路卡、容器網路同時運作時，衝突通常發生在路由優先順序、DNS 接管或相同保留網段。先記錄未開啟 TUN 時的預設路由與 DNS，再逐一啟用網路元件，就能找出是哪個步驟改變了出口。公司 VPN 只允許特定網段通過時，應為這些網段保留正確路由，並將內部網域交給企業 DNS；否則即使代理節點可用，內部服務仍可能因解析與路由分離而無法連線。

區域網路存取失敗時，檢查私人網段是否被規則設為 DIRECT、TUN 是否保留區域網路路由，以及系統防火牆是否允許虛擬網路卡存取。路由器或旁路閘道部署還要避免客戶端流量回到自身而形成迴圈。Linux 可透過 ip route 與 ip rule 查看路由及策略規則，Windows 可使用 route print，macOS 可使用 netstat -rn；僅為觀察而執行這些命令時，不需要修改系統設定。

# Linux：查看路由與策略規則
ip route
ip rule

# Windows：查看 IPv4 與 IPv6 路由
route print

# macOS：查看目前路由表
netstat -rn

如果只需要讓瀏覽器與常見桌面程式使用代理，系統代理的結構更簡單，也更容易定位問題；只有確實存在不讀取系統代理的應用程式時，再啟用 TUN。兩種機制的生效範圍、權限與效能差異，可參閱TUN 模式與系統代理比較。

05

網域嗅探

並非所有連線進入核心時都帶有網域。應用程式可能先自行解析 DNS，再直接連線至目標 IP；透明代理或閘道部署也經常只能看見位址。網域嗅探會讀取連線早期的協定特徵，從 HTTP Host、TLS SNI 或 QUIC 握手資訊中擷取網域，再用於規則比對。它不能解密業務內容，也不是對任意協定都有效；它只利用握手階段原本可見的目標識別，補足路由判斷所需的資訊。

依協定與連接埠限制範圍

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.org"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip 允許對原始目標為 IP 的連線嘗試嗅探，適合透明接管情境。force-dns-mapping 會結合 DNS 映射尋找網域資訊，通常與 Fake-IP 搭配使用。不同協定可以分別限定連接埠，避免在明顯不是 HTTP、TLS 或 QUIC 的連線上進行多餘判斷。連接埠範圍應依實際應用調整；將所有連接埠都交給所有嗅探器，不會提升準確率，反而可能增加誤判與故障排除成本。

override-destination 表示使用嗅探取得的目標覆蓋原始目標資訊。啟用後網域規則更容易命中，但錯誤嗅探也會直接影響連線去向，因此通常只應對明確協定啟用。force-domain 可要求特定網域採用嗅探結果，skip-domain 則用於已知不相容的服務。網域比對寫法需要遵循核心支援的萬用字元規則，修改後應在日誌中確認擷取到的網域與實際請求一致。

嗅探、DNS 與規則的先後關係

一次連線可能包含三類目標資訊：應用程式提交的網域、DNS 映射保存的網域、嗅探取得的網域。若應用程式透過一般代理協定提交網域，通常不需要額外嗅探；若應用程式只連線 IP，核心才需要從映射或握手中還原網域。規則引擎最終使用哪種資訊，取決於接管方式與設定。排查時可觀察日誌中的目標是否從 IP 變為網域、命中了哪條規則，以及最後連線的真實位址。

嗅探不能取代 DNS。它發生在連線開始後，節點伺服器網域、規則提供者網址與某些不帶可識別握手的協定，仍依賴正常解析。它也不能取代規則設計：擷取到網域後，仍需要相應的 DOMAIN、DOMAIN-SUFFIX 或規則集，將連線送往正確的策略組。若日誌已顯示正確網域但仍走錯組，應回到規則順序排查，而不是繼續擴大嗅探連接埠。

常見誤判與例外處理

某些應用程式會在非標準連接埠上使用自訂協定，資料開頭可能剛好類似 HTTP 或 TLS；也有服務使用共享位址與前置網域，握手網域不一定等於使用者介面中的業務網域。若開啟嗅探後連線失敗、關閉後恢復，應先記錄目標 IP、連接埠、嗅探出的網域與命中規則。確認是單一服務後，將它加入略過清單，通常比關閉所有嗅探更合適。

QUIC 建立於 UDP 之上，受網路、防火牆與代理節點 UDP 能力影響較大。瀏覽器存取同一網站時可能在 QUIC 與 TCP/TLS 之間切換，因此問題會呈現偶發性。可以在日誌中比較兩種連線的目標與策略；若節點不支援 UDP，應調整策略或讓應用程式回退，而不是把所有 UDP 問題都歸因於 DNS。行動裝置從休眠恢復、網路由 Wi-Fi 切換至行動數據後，也可能保留舊連線，需要重新建立連線才能觀察新設定。

用日誌建立可重現的樣本

調整嗅探設定時，每次只變更一個欄位，並固定測試同一個應用程式、同一個網域與同一個網路。記錄關閉與開啟時的目標表示、規則命中及錯誤類型。若錯誤是 timeout，需要進一步區分目標無法連線、策略節點無法連線或 UDP 不可用；若錯誤是憑證網域不相符，則應重點檢查覆蓋後的目標是否正確。日誌欄位與常見連線錯誤的閱讀方式，可參考Clash 執行日誌定位指南。

06

本地覆寫與多訂閱合併

訂閱通常負責提供節點、基礎策略組與部分規則，但使用者自己的區域網路例外、DNS 偏好與 TUN 設定，不適合直接寫回遠端訂閱。訂閱更新時，客戶端會重新產生設定，直接編輯產生檔案的內容可能遭到覆蓋。較穩妥的結構是將遠端內容視為「輸入」，把需要長期保留的本地設定放入覆寫、合併腳本或獨立主設定。不同客戶端對「覆寫」「擴充」「合併」的名稱與語法不完全相同，使用前應確認客戶端實際執行的是替換、淺層合併還是深層合併。

區分替換、追加與深層合併

YAML 映射與清單的合併行為不同。映射中的 dns.enable 可以依鍵值覆蓋，但 rules、proxies、proxy-groups 都是清單。許多工具遇到清單時會整體替換，而不是自動追加；如果只寫入一條本地規則，卻把訂閱原有規則全部替換，最後可能只剩本地項目。也有客戶端提供 prepend、append 等明確操作，將規則插入清單前端或末尾。開始使用前，應先用一條容易辨識的測試規則匯出最終設定，確認它出現的位置以及原有內容是否保留。

本地覆寫適合保存連接埠、日誌等級、DNS、TUN、嗅探與少量規則例外；節點及經常變動的遠端規則，則較適合繼續由訂閱或 provider 管理。不要在多個層級同時修改同一欄位，例如訂閱轉換範本、客戶端覆寫與啟動參數都設定 mixed-port，最終值會取決於套用順序，排查時很難還原。

# 本地主設定示意：節點由 provider 更新，
# 規則與策略名稱保持穩定。
proxy-providers:
  work-subscription:
    type: http
    url: https://subscription.example.com/work.yaml
    path: ./providers/work.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 預設代理
    type: select
    use:
      - work-subscription
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,預設代理

範例網址僅用於展示 provider 結構。實際訂閱網址通常包含存取憑證，不應複製到公開日誌、截圖或共用設定中。use 引用的是 proxy-providers 的名稱，而不是節點名稱。provider 更新後，引用它的策略組會取得新節點，而規則仍指向穩定的「預設代理」，因此訂閱端增刪節點不會破壞路由層。

多訂閱合併的命名與去重

同時使用工作、個人或不同來源的訂閱時，最常見的問題是節點名稱重複。兩個提供者都包含「香港 01」時，直接攤平到同一個清單可能無法辨識來源。較好的方式是讓每個 provider 分別保存，再透過 filter、exclude-filter 或客戶端支援的名稱前綴加以區分。篩選運算式應從簡單關鍵字開始，確認群組內節點數量合理後再增加條件。過於複雜的正規表示式容易將所有節點篩掉。

多訂閱不代表要把所有節點放入同一個自動測速組。可以建立「工作線路」「日常線路」兩個底層組，再由頂層手動組選擇。工作服務規則只指向工作組，日常流量指向預設組，避免自動測速時將業務出口切換到不符合要求的來源。若不同訂閱包含名稱相同的策略組，應在本地主設定中統一重新命名，不要依賴遠端組名長期不變。

更新前檢查與失敗回復

更新訂閱前先保留上一份可正常工作的最終設定，而不只是保存原始訂閱。更新完成後檢查四項：設定能否通過解析、關鍵策略組是否仍存在、組內是否有節點、規則末尾是否保留兜底，接著再進行連線測試。若更新後客戶端無法啟動，可以先恢復上一份最終設定，再比較節點、組名與清單縮排，不必在失效設定上持續修改。

YAML 對縮排敏感，清單項目必須位於正確層級。定位字元、全形標點與看似相同的特殊空格，都可能造成解析失敗。訂閱轉換工具產生的設定也應視為一般設定進行檢查，不能因為是自動產生就跳過驗證。涉及 provider 的路徑要確認目錄存在且可寫入；涉及多個檔案時，移動主設定後也要同步檢查相對路徑。

在不同客戶端間遷移設定

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客戶端都可圍繞 mihomo 設定運作，但介面層的覆寫方式、設定目錄與服務模式各不相同。遷移時先匯入不含裝置專用路徑的核心 YAML，再於新客戶端介面設定系統代理、TUN 權限與開機啟動。不要直接複製舊客戶端的整個資料目錄，以免將快取、鎖定檔案與平台路徑帶入新環境。客戶端選擇與平台差異可在橫向評測中核對。

07

外部控制面板

mihomo 提供外部控制介面，用於查看連線、切換策略、更新提供者與讀取日誌。桌面客戶端內建的介面通常已連接這個介面；伺服器、路由器或純命令列部署，則可以搭配獨立 Web 控制面板使用。控制介面具備修改執行狀態的能力，應將其視為管理入口，而不是一般網頁服務。安全設定的核心是限制監聽範圍、設定存取憑證，並由可信任網路或反向代理負責遠端存取。

監聽位址與存取範圍

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui
external-ui-name: dashboard

127.0.0.1:9090 只接受本機連線，適合桌面客戶端或控制面板與核心在同一裝置上執行的情況。若改為 0.0.0.0:9090，區域網路中的其他裝置也可能存取，必須同時設定防火牆與強式存取憑證。範例中的憑證是教學用假值，實際部署應使用獨立且難以猜測的值，不要與訂閱網址或其他帳戶共用。

external-ui 指向靜態控制面板檔案目錄，目錄中應包含面板入口檔案。external-ui-name 用於區分或指定介面目錄名稱，具體下載與更新方式取決於採用的控制面板及核心設定。若介面可連線但頁面顯示空白，應檢查靜態檔案路徑與程序工作目錄；若頁面能開啟但提示無法連線核心，則應檢查控制介面位址、協定、瀏覽器同源限制與憑證。

區域網路與遠端存取界線

進行區域網路管理時，可以讓控制介面監聽內網位址，並只允許管理裝置所在的網段存取。不要將控制埠直接暴露在公網上。需要遠端管理時，較合適的方式是先進入可信任 VPN，或透過具備身分驗證與 TLS 的反向代理存取。反向代理還應限制允許的方法、請求本文大小與來源，避免任何能存取網頁的人都能操作核心。

控制面板中的策略切換會改變目前的執行狀態，但不一定會寫回原始設定。重新啟動後是否保留選擇，取決於 profile.store-selected 等持久化設定與客戶端實作。若希望策略選擇在重新啟動後恢復，可啟用相應的持久化功能；若伺服器要求每次啟動都回到固定出口，則應關閉保存，並在設定中明確指定預設順序。

profile:
  store-selected: true
  store-fake-ip: true

log-level: info
unified-delay: true
tcp-concurrent: true

store-selected 會保存策略組目前的選擇，store-fake-ip 會保存 Fake-IP 映射，有助於重新啟動後維持部分連線行為。保存檔案仍需要工作目錄的寫入權限。log-level: info 適合日常觀察；排錯時可暫時提高詳細程度，但長期保留大量詳細日誌會增加磁碟寫入與資訊暴露範圍。unified-delay 用於讓延遲測試採用較一致的計算方式，tcp-concurrent 會並行嘗試目標位址，以改善部分雙協定堆疊的連線建立過程，是否適用應依裝置資源與網路表現測試。

控制面板中的正確排查方式

連線清單適合回答三個問題：應用程式連線到哪個目標、命中了哪條規則、最後使用哪個策略。遇到網站無法開啟時，先依目標網域篩選連線，確認請求是否出現；沒有連線記錄，表示流量可能沒有進入核心，應檢查系統代理或 TUN。出現記錄但目標只有 IP，可繼續檢查 DNS 與嗅探。規則與策略正確但連線逾時，再檢查節點與目標的可達性。

策略組頁面的延遲測試只是一種健康檢查，不是線路評分。某節點對測試網址回應很快，但對特定服務仍可能無法使用，應結合實際連線日誌判斷。提供者頁面更新失敗時，查看失敗的是代理提供者還是規則提供者，並分別檢查訂閱網址、規則網址、DNS 與寫入權限。一次點擊連續觸發多次更新會產生重疊請求，等待目前工作完成後再重試，更容易取得清楚的日誌。

設定變更的安全流程

透過控制介面重新載入設定前，應先在獨立位置完成語法檢查。在遠端伺服器上修改監聽位址、TUN 或預設路由時，保留目前的管理工作階段，並準備能夠恢復舊設定的服務命令。systemd 部署可以先檢查服務日誌，再執行受控重新啟動；在確認新設定可讀取前，不要刪除舊檔案。若服務進入反覆啟動失敗，應停止自動重新啟動，直接查看第一次失敗的錯誤行，後續錯誤通常只是前一個問題的連鎖結果。

# 查看服務狀態與最近日誌
systemctl status mihomo
journalctl -u mihomo -n 100 --no-pager

# 確認設定後再重新啟動
sudo systemctl restart mihomo

系統服務名稱可能取決於實際安裝方式，執行前應核對本機單元名稱。純命令列部署需要更多系統管理知識；希望直接管理訂閱、策略與系統代理的桌面使用者，建議優先從Linux 客戶端或其他對應平台的 GUI 客戶端開始。Linux 桌面與 systemd 兩種部署路線可繼續閱讀Clash Linux 安裝指南。