Clash 進階設定指南

設定檔與生效順序

分清訂閱檔案、產生的設定與執行狀態

Clash 用戶端通常會管理三種內容：遠端下載的訂閱檔案、經用戶端處理後產生的最終設定，以及核心已載入的執行狀態。修改訂閱副本後介面沒有變化，不一定代表參數無效，也可能是用戶端仍在使用另一份產生的設定檔。開始修改前，先確認目前啟用的設定名稱、核心類型，以及用戶端提供的最終設定預覽位置，再記下現有模式、連接埠與策略組選擇。

訂閱可能包含節點、策略組、規則與 DNS，也可能只提供節點清單。用戶端還可能依系統代理、TUN 開關與覆寫設定補入欄位，因此磁碟上的原始 YAML 不等於最終生效結果。建議將遠端內容視為輸入、本機覆寫視為轉換、執行設定視為檢查對象。發現差異時，沿這條路徑逐層比對，不要同時修改三個位置，否則下次更新訂閱後，很難判斷是哪一層保留了變更。

以最精簡設定確認基本行為

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

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

這份最精簡範例僅供理解結構：混合連接埠同時接受 HTTP 與 SOCKS 代理請求，規則模式依規則表處理連線，最後的兜底規則交由手動選擇組處理。範例沒有加入代理節點，組內只有直連，因此不會自動取得代理出口。實際使用時，請保留自己的有效節點或代理集合，並將它們加入策略組。不要為了套用範例而刪除訂閱中的驗證欄位、傳輸層設定或伺服器要求的參數。

YAML 使用空格縮排，不使用定位字元。同一層的清單項目應對齊；名稱和密碼若含特殊符號，建議加上引號。頂層的 dns、rules、proxy-groups 不應在同一份文件中重複定義；重複鍵可能遭解析器拒絕，也可能被後面的值取代。複製程式碼後先檢查縮排，再確認名稱引用；YAML 能成功解析，不代表策略組引用和規則語義一定正確。

先檢查語法，再進行受控重新載入

直接使用核心的使用者可以執行 mihomo -t -f config.yaml 檢查設定；如果用戶端沒有將核心加入命令搜尋路徑，請改用它實際提供的執行檔路徑。測試時也要使用與執行環境相同的工作目錄，因為規則集快取和其他相對路徑會受目錄位置影響。語法檢查主要用來找出結構與引用問題，不能取代實際連線測試，也無法保證遠端規則集一定下載成功。

修改前先備份一份確認可用的完整設定，並記錄用戶端覆寫設定。每次只調整一個主題，檢查通過後再重新載入；涉及監聽位址、虛擬網卡與路由的欄位，請依用戶端提示重新啟動核心。重新載入成功不代表所有既有連線都已切換：連線可能仍沿用原本的出口。驗證時應主動重新建立目標連線，並查看日誌中的設定載入結果，不要只觀察開關狀態。

如果核心無法啟動，先還原上一份設定，再區分解析錯誤、連接埠被占用與權限不足。連接埠問題可參考混合連接埠占用排除指南；結構問題可對照YAML 設定分段解析。恢復基本連線後再繼續進階設定，比在失效設定上不斷疊加修補更容易找出原因。

策略組類型與分流實作

規則決定目標，策略組決定出口

規則清單負責將連線交給某個策略，策略組則負責從候選項目中選出實際出口。候選項目可以是節點、其他策略組，也可以是內建的 DIRECT 或 REJECT。這兩個層次應分開設計：先依用途定義手動選擇、自動選擇、工作服務等組別，再讓規則引用這些固定名稱。節點增刪留在底層處理，可減少訂閱更新時反覆修改整份規則的工作。

select 由使用者在介面中選擇候選項目，適合作為總入口，也適用於需要固定出口的服務。除非使用者選中的本身就是自動組，否則節點無法使用時，這個組不會自動改選其他候選項目。需要維持登入位置或長時間工作階段時，手動固定通常比頻繁切換更容易掌握。組名不只是介面標籤，也是規則中的引用識別名稱；修改名稱後，必須同步修改引用它的規則與上層策略組。

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

url-test 適合從同類型節點中自動選擇，但探測網址只反映連線至該目標的狀況，不等同於所有網站的實際使用體驗。fallback 更重視候選項目的順序：排序靠前的項目符合可用條件時便優先使用，適合主備關係明確的情境。兩者都依賴探測；如果目標網站無法連線、憑證異常或受到網路限制，可能會將原本可用的候選項目誤判為故障。排除問題時，請另外確認探測目標是否正常。

load-balance 分配的是不同連線，不會將單一連線拆成多條來合併頻寬。採用輪詢分配時，同一業務的多條連線可能使用不同出口；使用一致性雜湊也無法保證所有相關網域都落在同一個節點。支付、登入及對來源位址敏感的服務，適合另外放入固定出口組。連線途中變更策略通常也不會轉移已建立的傳輸；重新連線後才能確認新的選擇。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - 主要節點
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 代理入口
    type: select
    proxies:
      - 自動選擇
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,代理入口
  - MATCH,代理入口

範例假設已有名為「主要節點」的代理集合；use 引用的是集合名稱，不是訂閱連結。探測網址可替換成自己確認可連線且回應穩定的目標。間隔以秒為單位，容差用來減少細微差異造成的反覆切換，不代表實際業務回應一定良好。節點數量較多時，請控制探測頻率，先以預設或較保守的間隔觀察，再依裝置資源與網路狀況調整。

檢查空組、循環引用與業務命中情況

策略組篩選後沒有候選項目，常見原因包括集合尚未載入、名稱拼錯，或正規表示式沒有匹配到節點。先暫時移除篩選條件，查看實際候選項目，再恢復過濾表達式。組別之間可以分層引用，但不能形成循環；例如總入口包含自動組，而自動組又引用總入口，出口解析便無法完成。維持「業務組 → 選擇組 → 節點或集合」的單向結構，更容易檢查。

驗證時先固定一個已知可用的候選項目，連線至目標服務，確認規則確實交由預期的組處理，再測試自動選擇。否則連線失敗可能源自規則、解析或節點本身，自動組只是表面上被懷疑的對象。需要比較各平台的介面與核心功能時，可查看用戶端比較；組別類型能否直接在介面編輯，則應以所用用戶端的設定入口為準。

以訂閱方式管理規則集

分開維護匹配資料與處理策略

網域與網段清單逐漸增加時，將每個項目都寫在主設定中會提高閱讀和更新成本。rule-providers 可將匹配資料獨立為規則集，主設定只保留集合來源與呼叫順序。規則集用來指定哪些目標屬於某個類別，RULE-SET 規則則指定這個類別應交由哪個策略處理。如此一來，更新目標清單不必變更策略組，調整出口也不必重寫整份網域資料。

規則依序由上而下匹配，通常由第一條符合的規則決定連線去向。特定網域的例外應放在涵蓋範圍較廣的規則之前，MATCH 則放在最後兜底。規則集的呼叫位置與其中的資料同樣重要：正確的拒絕清單若放在兜底規則之後便不會生效；若將範圍過廣的直連條件放在業務代理規則之前，也可能提早攔截連線。調整規則前，先釐清優先順序，再修改檔案。

選擇正確的行為與資料格式

rule-providers:
  內部網域:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/internal.yaml

rules:
  - DOMAIN-SUFFIX,github.com,代理入口
  - RULE-SET,內部網域,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,代理入口

以上主設定引用的是本機檔案，並假設「代理入口」策略已存在。對應的 rules/internal.yaml 可使用以下格式。這裡採用專供範例使用的網域，不依賴真實服務；+.example.com 代表根網域及其子網域。實際部署時，請替換成需要管理的目標，並將檔案放在核心允許存取的位置。若用戶端使用受限的設定目錄，建議優先透過用戶端的匯入或規則集管理功能操作。

payload:
  - '+.example.com'
  - '+.example.org'

behavior: domain 適用於網域資料，ipcidr 適用於 IP 網段，classical 則可容納不同類型的規則表達式。這三種資料格式不可混用：網域集合中不應直接放入完整的 DOMAIN-SUFFIX 規則列。傳統規則格式的集合通常只需列出匹配條件，再由呼叫它的 RULE-SET 指定策略；不要照搬主規則清單，在每個集合項目後面都附上目標策略。

格式欄位也必須與內容相符。YAML 格式通常使用 payload 清單，文字格式則依相應規範逐行存放資料；二進位規則格式需要搭配相符的行為類型與產生工具。下載成功只代表取得回應內容，不代表內容能正確解析。錯誤頁面、登入頁面或重新導向後的 HTML 都可能被存入快取，因此更新失敗時應查看解析日誌，並檢查檔案開頭與實際回應，不要只確認網路請求是否完成。

遠端更新、快取與啟動相依性

改用遠端規則集時，請設定 type: http、可信且實際可用的下載網址、快取路徑與更新間隔。不同集合應使用不同快取檔案，避免更新時互相覆寫。若首次啟動時必須透過代理連線才能存取規則來源，而代理連線又依賴尚未下載的規則，就會形成啟動相依性；可為規則下載明確指定可用出口，或先準備本機快取。不要用無限重試掩蓋相依循環，應先確認精簡規則下的基本代理功能正常。

若 IP 規則只需根據已有的目標位址進行匹配，可視需求使用 no-resolve，避免為了測試這條規則而額外解析網域。代價是只有網域資訊、尚未取得實際 IP 的連線可能會略過這條規則。這不是通用的加速開關，而是會改變匹配時機的語義選擇。網域規則、DNS 策略與 IP 規則應一併檢查，尤其在 Fake-IP 模式下，不要將合成位址當成伺服器真實位址來規劃網段分流。

回歸測試至少應涵蓋一個應走代理的目標、一個應直連的目標，以及一個明確拒絕的測試目標。查看連線詳細資料中的規則類型、集合名稱與最終策略，不要只憑網頁能否開啟來判斷。規則命中正確但服務仍異常時，再檢查策略組出口、DNS 回應與舊連線快取；不要立刻增加更多重複規則，否則日後排除問題時，會被越來越長的例外清單拖慢。

DNS 設定最佳化與解析路徑

先釐清解析請求會經過哪些環節

DNS 設定需要同時考慮三個問題：應用程式將查詢交給誰、核心如何選擇上游，以及上游網域本身又由誰解析。系統 DNS、瀏覽器安全 DNS、應用程式內建解析器與 mihomo DNS 可能同時存在，因此調整某個上游不一定會改變所有應用程式的行為。開始最佳化前，先確認目前連線是否經過核心，以及日誌中是否出現相應查詢。若請求沒有進入核心，反覆調整核心快取與上游順序通常無法解決問題。

nameserver 用來指定一般解析上游，default-nameserver 主要用於解析 DNS 上游本身的網域，屬於引導解析環節。若上游使用加密 DNS 網址，其主機名稱仍須先解析為實際位址；引導環節失敗時，整條解析鏈可能都會逾時。請選擇目前網路確實能連線的引導解析器，並區分它與業務網域解析的職責，避免上游位址反過來依賴尚未建立的代理連線。

保留一條容易驗證的基本解析路徑

dns:
  enable: true
  listen: 127.0.0.1:1053
  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
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'

範例讓 DNS 僅監聽本機，並為範例網域指定獨立上游。監聽連接埠不會自動改變系統 DNS，也不會自動接管其他裝置的查詢；只有系統設定、用戶端網路接管或應用程式代理路徑將請求送入時，這個監聽才會發揮作用。上游能否連線取決於目前網路，應先確認基本解析路徑正常，再加入依網域區分的策略。區域網路內部網域應使用包含內部紀錄的解析器，而不是一律交由公共上游處理。

nameserver-policy 會依網域選擇解析上游，改變的是解析路徑，不是連線出口。指定 DNS 回傳位址後，連線仍須經過規則匹配，才能決定走代理或直連。反過來說，網域命中代理規則，也不代表它的 DNS 一定透過相同的代理出口。將解析策略與路由策略分成兩份清單分別核對，可避免把「指定 DNS」和「指定代理節點」誤認為同一項設定。

代理節點解析與備用解析的界線

節點伺服器若使用網域名稱，其解析屬於建立代理連線前的準備工作。若需獨立處理，可使用 proxy-server-nameserver 為代理伺服器網域指定上游，避免節點網域解析依賴節點本身。若採用依規則選擇 DNS 出口的功能，也應一併檢查這項設定。混用多層代理、遠端集合下載與加密上游時，最重要的是避免形成循環相依，而不是讓所有請求都套用相同路徑。

fallback 與 fallback-filter 必須搭配理解：後者會參與判斷哪些結果適合使用備用解析，不能單純視為「主要 DNS 失敗就一定切換」的順序佇列。過於寬泛的過濾條件會讓許多網域改用備用結果，也可能增加查詢負擔。沒有明確需求時，先採用容易驗證的單一路徑；只有能具體說明哪些網域、哪些位址結果需要特殊處理時，再逐一增加過濾條件。

加密 DNS 可以保護查詢傳輸過程，但不能取代正確的出口選擇，也無法保證遠端解析結果適合本地連線。IPv6 同樣需要完整鏈路支援：系統取得 IPv6 位址，不代表代理節點、路由與目標服務都具備可用路徑。若只有部分網站需要等待，請檢查 AAAA 回應與實際 IPv6 連線狀況，再決定是否調整核心 DNS 的 IPv6 設定，不要直接把所有問題都歸咎於解析器品質。

確認查詢入口與快取影響

測試時分別查詢系統預設 DNS 與指定監聽連接埠，比較兩者是否使用相同路徑。支援指定連接埠的工具可執行 dig @127.0.0.1 -p 1053 example.com；該工具需另外安裝，用戶端不一定會附帶。Fake-IP 模式下出現合成位址可能是預期結果，不應只因它與公共解析器的回應不同就判定設定錯誤。更可靠的依據是查詢日誌、映射關係，以及後續建立的連線是否一致。

完成修改後，重新建立應用程式連線；必要時清除應用程式自己的 DNS 快取，並確認瀏覽器安全 DNS 是否繞過系統解析。測試記錄應註明查詢入口與使用的上游，避免直接比較兩條不同路徑的結果。若只有內部網域失敗，優先檢查本機解析器與分域策略；若所有網域都失敗，先檢查上游引導、監聽連接埠與網路可達性。

TUN、Fake-IP 與網路接管

分清系統代理與虛擬網卡接管

系統代理通常會提供 HTTP 或 SOCKS 代理入口給遵循系統設定的應用程式，但不保證所有連線都會經過核心。TUN 則透過虛擬網卡與路由規則接收流量，適合無法直接設定代理的應用程式。兩者並非互斥概念，但同時啟用時，必須清楚各類連線從何處進入。TUN 開關顯示已啟用，只代表用戶端嘗試開啟相關功能；仍須確認網卡、路由、DNS 與權限是否一併生效。

桌面作業系統通常需要管理員權限、服務模式或輔助元件，才能管理虛擬網卡與路由；實際操作入口由用戶端提供。Android 的網路接管通常透過 VpnService 實作，能否在背景持續執行也會受到系統省電策略影響。不要將桌面版 YAML 的所有路由欄位原封不動套用到行動版介面，也不要在企業 VPN 或其他網路接管工具運作時直接疊加設定；應先了解各自控制的路由範圍。

從較保守的 TUN 設定開始

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

範例展示網路接管與 DNS 的關聯；實際使用時，應合併至既有的 tun 與 dns 區段。auto-route 用於自動設定路由，auto-detect-interface 用於辨識出口網卡；堆疊類型則應依平台支援與核心日誌選擇。若用戶端已管理這些欄位，請透過用戶端入口調整，避免本機覆寫與介面開關互相覆蓋。不能只因範例採用某種堆疊，就認定它適用於所有裝置。

dns-hijack 的用途是將符合條件的傳統 DNS 請求交給核心解析器處理，範例不代表所有 DNS 都能被接管。應用程式若透過 HTTPS 或其他加密通道查詢，流量就不再是一般的目標連接埠 DNS 請求，需搭配路由與應用程式設定判斷。內部解析器、路由器網域與特殊網路可能仍需設定例外。先觀察查詢入口，再決定接管範圍；不要用擴大接管範圍取代問題定位。

Fake-IP 使用映射位址，並非服務的真實位址

Fake-IP 會為網域指派合成位址，核心則保存網域與位址的對應關係，之後再將應用程式連線對應回原始網域。這種方式可減少部分情境下預先解析真實位址的需求，也有利於網域規則運作。合成位址不是遠端伺服器位址，不適合用來設定遠端防火牆允許清單，也不應由未經過同一核心的其他裝置直接使用。若應用程式快取了映射，但連線沒有回到對應核心，就可能無法存取服務。

fake-ip-filter 用於指定網域不分配 Fake-IP，適合區域網路探索、內部服務或確實不相容的業務。套用過濾後會回傳真實解析結果，但連線仍須由路由與規則處理，不會自動變成直連。應從實際發生問題的網域開始加入例外，同時確保這些網域能正確解析。若將所有常用網域都加入過濾清單，會改變模式的運作方式，也會讓網域關聯更依賴其他資訊來源。

內部網段、容器網路與企業 VPN 可能和合成位址範圍或自動路由衝突。發現某段位址無法連線時，先檢查系統路由表與現有網卡，不要立刻更換所有 DNS。自訂位址池前，應確認不會與既有網路重疊，再依用戶端支援情況設定路由排除。排除某個網段代表該範圍的流量可能不再進入核心，後續也無法依靠核心規則分流，應事先釐清這項界線。

依網卡、路由、解析、連線的順序排除問題

啟用 TUN 後完全無法連線時，先關閉 TUN 恢復原本網路，再確認核心權限與虛擬網卡是否建立成功。接著檢查預設出口辨識是否錯誤，尤其是在多網卡、熱點共享與 VPN 並存的裝置上。基本路由確認無誤後再測試 DNS；網域能解析但連線失敗，則查看命中的規則與節點協定支援。每一層都用一個可重現的請求驗證，不要連續切換多種堆疊與 DNS 後才開始查看日誌。

若只有 Android 在背景執行時斷線，請繼續檢查系統授權與省電策略，可參考Android VpnService 與背景執行設定說明。若只影響區域網路裝置，請另外檢查共用代理連接埠、防火牆與監聽位址；電腦本身的 TUN 運作正常，不代表其他裝置已連上代理。

網域嗅探與規則辨識

嗅探補充網域資訊，不取代 DNS

連線進入核心時，不一定會帶有可用的網域名稱。例如應用程式直接連線至 IP，或 DNS 查詢發生在核心之外，規則引擎可能只能看到目標位址。網域嗅探會嘗試從連線初始資料擷取主機資訊，補足規則匹配所需的網域線索。它不負責提供通用名稱解析，也無法保證辨識所有連線。排除問題時，應先確認網域資訊究竟在哪個環節缺失，再判斷是否需要啟用嗅探。

常見資訊來源包括 HTTP 請求中的主機欄位，以及 TLS 交握中可見的伺服器名稱。QUIC 辨識也取決於協定支援與資料是否能解析。加密用戶端問候、非標準交握、沒有網域的協定及已建立的連線，都可能限制辨識效果。因此嗅探成功率不能作為判斷設定是否正確的唯一標準；未辨識的連線仍需要適當的 IP 規則與兜底策略，不能依賴嗅探補足所有資訊。

先限制協定與連接埠，再考慮覆寫目標

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
      override-destination: false
  skip-domain:
    - '+.example.com'

範例只對常見的 HTTP 與 TLS 連接埠啟用辨識，並維持關閉目的位址覆寫；略過清單使用範例網域，實際使用時應替換為確有相容性需求的目標。連接埠清單是辨識範圍，不是開放防火牆連接埠，也不會自動將這些連線指定給代理。連線去向仍由規則清單決定。先在有限範圍內確認效果，比一開始就在大量連接埠啟用辨識更容易判斷是哪類協定改變了行為。

override-destination 涉及是否以嗅探到的網域覆寫連線目的地，與「取得網域供規則匹配」並非同一層級。原本依 IP 連線的服務，覆寫後可能觸發重新解析，最後連到不同位址；對固定位址服務、特殊 CDN 調度或內部閘道而言，這種變更可能造成相容性問題。應先維持保守設定，確認特定業務確實需要覆寫後，再逐步依協定或網域範圍調整。

處理誤判與業務例外

有些服務會重複使用連線、使用與存取入口不同的交握名稱，或透過中間閘道承載業務。嗅探取得的名稱不一定是使用者最初輸入的網域，規則因此可能將連線分到另一個類別。若啟用後特定服務才出現異常，先記錄嗅探前後的網域、目的位址與策略，再為該目標加入略過項目。不要立刻關閉所有網域規則，也不要將整個服務生態系統一律強制直連，否則變更範圍會過度擴大。

force-domain、純 IP 連線辨識等功能屬於進階控制項，是否需要取決於實際入口與核心支援情況。不宜從所有網域開始強制辨識；合理需求應能具體描述為「某個應用程式缺少某網域的對應資訊，需要補上辨識」。若無法指出受影響的連線，請先檢查 DNS 入口與 Fake-IP 映射。許多看似需要強制嗅探的問題，根本原因是 DNS 與連線未經過相同路徑。

嗅探也會參與連線初期的處理。對時序敏感的應用程式而言，協定等待與辨識失敗可能改變連線建立狀況，因此測試應涵蓋業務實際使用的傳輸協定。只在瀏覽器開啟首頁，無法證明應用程式內的語音、影片或其他長連線都正常。日誌只應在問題定位期間暫時提高詳細程度，完成後恢復一般等級，避免長時間收集不必要的網域與連線資訊。

將辨識結果放回完整分流路徑驗證

驗證時選擇一個可重複操作的目標，先關閉嗅探建立基準，再開啟嗅探並重新連線，比較規則命中是否如預期改變。若目的地沒有網域資訊，但 IP 規則已正確處理，就不必為了讓介面顯示網域而增加複雜設定。若辨識到網域後仍命中兜底規則，請繼續檢查規則順序、拼寫與規則集內容；辨識成功不會自動建立該網域的分流規則。

涉及固定 IP、憑證異常或代理閘道的服務，也應檢查應用程式層的錯誤，而不只是確認代理連線是否建立。核心通常不會因嗅探而解密業務本文，也無法修復伺服器憑證或帳號權限問題。將「取得網域線索」、「選擇策略」、「連線目的地」與「應用程式請求成功」視為四個獨立結果記錄，可避免把後續業務失敗誤判為嗅探失敗。

對於需要保留原始目的位址的內部系統，優先採用明確的網域規則、內部 DNS 與有限的嗅探略過清單。複雜業務不能只靠一個全域開關取得一致結果。若決定停用嗅探，也應重新驗證原本仰賴嗅探辨識的連線是否落入適當的兜底規則，不要刪除設定後就停止檢查。基本術語可在名詞解釋中查閱。

本機覆寫與多訂閱合併

釐清遠端輸入與本機維護的界線

更新訂閱通常會重新下載遠端內容，直接修改下載副本很容易在下次更新時遺失。需要長期保留的設定，應放在用戶端提供的覆寫、合併或指令碼入口；但這些入口並非 mihomo 統一規定的介面功能。Clash Plus、Clash Verge Rev、FlClash 等用戶端的處理時機與欄位合併方式可能不同，操作前應檢查最終設定，不要因入口名稱相似，就假設它們採用相同的覆寫規則。

適合在本機維護的內容包括監聽範圍、DNS 偏好、內部網域規則與固定的策略組結構；適合遠端更新的內容則包括節點參數與外部規則資料。將兩者分開後，本機設定才不會隨每次節點更新反覆變動。若遠端設定已包含完整規則，應先決定要保留遠端架構，還是改用自己的架構，再設定覆寫，避免兩套結構互相巢狀，卻無法釐清哪一套擁有最終控制權。

以代理集合管理多個節點來源

proxy-providers:
  來源甲:
    type: file
    path: ./providers/source-a.yaml
  來源乙:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 訂閱甲
    type: select
    use:
      - 來源甲
  - name: 訂閱乙
    type: select
    use:
      - 來源乙
  - name: 代理入口
    type: select
    proxies:
      - 訂閱甲
      - 訂閱乙
      - DIRECT

範例使用本機代理集合，兩個檔案都應包含有效的 proxies 清單。這種結構會先分別驗證來源，再透過上層入口選擇來源。完整 Clash 設定、僅含節點的 YAML、Base64 清單與協定分享連結並非可互換的檔案類型；將任意訂閱網址填入集合，不代表核心一定能辨識。請先確認回傳格式，必要時使用可信任的本機處理流程，詳見訂閱格式說明。

使用遠端代理集合時，需設定實際訂閱網址、快取路徑與更新間隔，並考量啟動時透過哪條路徑下載。訂閱網址通常包含帳戶憑證，應只保存在本機私人設定中，不要貼到公開轉換頁面或問題截圖。教學與分享範例應移除真實網址、驗證資訊及可還原帳戶的參數。即使沒有公開節點密碼，完整訂閱連結本身也可能具備存取權限，不應當成一般公開網頁連結。

清單合併不只是簡單串接文字

字典欄位可以依鍵值覆寫，清單則可能採取取代、前置新增或後置新增等不同語義。將本機規則加在遠端 MATCH 後面，通常無法達成例外優先的目的；直接取代 DNS 清單，也可能遺失原設定中的內部解析器。設定覆寫前，應先釐清預期操作，再確認用戶端是否支援。若用戶端只支援整段取代，就必須維護完整的目標區段，不要只提交一小段，並假設其他項目會自動保留。

多個來源可能包含同名節點與同名策略組。介面出現重複名稱會增加辨識難度，規則與組別引用也可能產生歧義。優先在來源層清楚區分名稱，並只在用戶端確實支援時使用名稱修飾；不要只修改介面顯示名稱，卻保留舊引用。合併後也要檢查正規表示式篩選，因為新增前綴、來源變更或名稱語言改變，都可能讓原本有效的表達式匹配不到任何項目。

健康檢查也要區分層級。代理集合可以檢查節點狀態，自動策略組也可能發起探測；重複設定會增加請求。不是每個手動選擇組都需要再進行一輪自動測試。先釐清要確認的是「集合中的節點是否可連線」，還是「自動組應選擇哪個候選項目」，再設定相應檢查。多個訂閱同時啟用時，各來源個別可用不代表共用的上層組也正確，仍須驗證最終候選項目與規則引用。

建立可重複執行的更新與復原流程

完成一次合併後，依序檢查 YAML 解析、集合載入、策略候選項目、規則順序與 DNS 結果，並保存最終設定預覽。接著手動更新一次訂閱，再重複相同檢查，確認本機設定確實保留。只有經過更新驗證的覆寫，才能視為持久設定；僅在目前工作階段生效的介面選擇，可能還取決於用戶端是否保存執行狀態，應另外確認重新啟動後的行為。

若打算從舊用戶端遷移，先匯出本機覆寫與必要的策略選擇記錄，再匯入新用戶端逐段驗證。不要假設介面設定資料庫能直接跨用戶端使用。可前往下載頁選擇目前平台的用戶端；建議先完成單一訂閱連線，再新增第二個來源，最後恢復複雜規則，讓每次變更都有明確的驗證範圍。

外部控制面板與介面安全

控制連接埠與代理連接埠用途不同

混合連接埠用於轉送應用程式連線，外部控制連接埠則用於讀取狀態與執行管理操作。面板透過控制介面查看策略組、連線與日誌，也可能切換模式或重新載入設定。它不是另一個可供瀏覽器填入的代理連接埠。兩個監聽不能在相同位址上使用同一連接埠；遇到啟動衝突時，應分別檢查代理監聽、DNS 監聽與控制監聽，不要只修改系統代理填入的數字。

控制介面的權限高於一般狀態頁面，因為能存取介面的程式可能改變流量處理方式。桌面端通常只需綁定本機迴路位址；遠端管理則應優先考慮具驗證機制的通道或受控網路。將控制位址改為監聽所有網卡，只會擴大存取範圍，不會自動建立存取控制；面板介面沒有顯示給其他人看，也不代表連線安全。實際安全界線由監聽位址、防火牆與驗證機制共同決定。

本機監聽與驗證設定

external-controller: 127.0.0.1:9090
secret: "your-controller-password"

範例密碼僅供教學使用，實際部署時請在本機換成獨立且高強度的密碼，不要沿用節點驗證資訊或其他帳戶密碼。用戶端可能會自行管理控制位址與驗證欄位；若手動覆寫後面板無法連線，先檢查介面儲存的連線參數是否一致，不要直接清除驗證設定。變更監聽或驗證後，也要同步更新現有面板連線；多個面板保存了不同的舊值時，可能會間歇性連線失敗。

若本機面板由用戶端內建提供，請優先使用用戶端支援的開啟方式。直接執行核心時，可透過 external-ui 指向事先準備好的本機靜態面板目錄，但目錄本身必須包含有效的頁面資源；填入路徑不會自動產生面板。相對目錄需依核心工作目錄判斷，移動設定檔位置後也應檢查資源路徑。不要為了讓頁面載入而任意放寬整個設定目錄的檔案權限。

區分網路無法連線、驗證失敗與瀏覽器限制

面板連線失敗時，先確認核心正在執行，且控制位址確實處於監聽狀態，再檢查面板填入的通訊協定、主機、連接埠與驗證值。本機可連線但其他裝置無法連線，通常需要檢查綁定範圍與防火牆；能建立連線卻收到未授權回應，則應優先檢查驗證設定。面板能開啟但狀態空白，也可能是頁面資源正常、介面連線失敗；不能只根據頁面外觀判斷控制通道已建立。

瀏覽器也可能受到跨來源政策與混合內容限制。以 HTTPS 開啟的面板若向明文 HTTP 控制介面發出請求，瀏覽器可能在請求抵達核心前就將其封鎖。請查看瀏覽器網路面板中的具體原因，再決定採用同源部署、用戶端內建入口或受保護的轉送方式。不要將所有瀏覽器錯誤都歸咎於核心不支援，也不要為了消除錯誤就全面放寬允許來源與網路監聽範圍。

確實需要跨來源存取時，應依核心與面板支援的方式限制允許來源，並保留驗證機制。透過反向代理提供遠端入口時，也要確認 WebSocket 等連線能正確轉送，否則一般請求可能正常，實時日誌卻會持續中斷。保護入口時，應同時考量傳輸加密與存取範圍；不能只在面板前加上登入頁，卻將底層控制連接埠直接暴露於不可信任的網路。若不清楚部署邊界，維持本機監聽較合適。

透過連線詳細資料完成故障排除

控制面板最有用的資訊包括連線入口、目標網域或位址、命中的規則與最終策略鏈。排查失敗請求時，先重新建立連線，在清單中找到對應項目，再確認是否進入預期的業務組。若完全沒有記錄，優先檢查應用程式是否經過代理或 TUN；若有記錄但規則不符，回頭檢查規則順序；規則正確但無法建立傳輸時，再檢查節點、DNS 與協定支援。依照這個順序，就能將問題限定在可觀察的層次。

切換策略只會影響後續選擇，舊連線可能仍沿用原本的出口。驗證時只需結束相關測試連線，再重新發出請求，不必一次中斷所有業務。暫時提高日誌詳細程度時，應記錄重現時間與目標，完成後恢復一般等級。截圖或匯出日誌前，請移除訂閱網址、驗證欄位、內部網域與不必要的目標資訊；診斷需要的是與故障相關的證據，不是完整的私人網路記錄。

最終維護流程可固定為：保存可用設定、單項修改、檢查語法、受控重新載入、驗證命中、更新訂閱、再次驗證並記錄復原點。每次發生問題時，依序檢查入口、解析、匹配與出口四個層次，不必同時重新安裝用戶端並更換訂閱。常見安裝與使用問題可繼續查閱說明中心；需要重新確認匯入與連線流程時，請回到快速入門指南。