Clash 設定進階指南

設定層級與 Clash 連接埠設定

修改前先確認實際生效的是哪一份設定。訂閱下載檔、用戶端儲存的設定，以及合併後的執行設定，通常不是同一個檔案。訂閱提供代理與基本策略；用戶端偏好設定可能接管連接埠、模式、DNS 或 TUN；本機覆寫則可補充規則。在編輯器中看到欄位，不代表核心已採用該設定。請一併查看執行設定、介面選項與啟動記錄，確認最終值。若用戶端沒有執行設定入口，至少記下相關代管選項是否已啟用。

YAML 縮排與欄位層級

YAML 以空格表示層級，同一層的欄位必須對齊，清單項目則以連字號開頭。請勿混用定位字元，也不要在同一層重複設定兩個 dns 或 rules；重複鍵可能會被拒絕，也可能只保留後面的值。名稱含特殊字元時建議加上引號，尤其是包含冒號或空格的文字。修改時請保留原檔結構，只調整目標欄位；若把整份訂閱壓成一行，縮排錯誤與設定覆蓋問題會更難找出。

先將檔案備份到本機，再執行設定檢查。使用命令列核心時，可執行以下命令；./config.yaml 指目前目錄中的設定檔，若檔案不在此處，請調整路徑。檢查通過只代表語法及基本參照可以載入，不代表伺服器可連線、系統權限足夠或 DNS 路徑正確。若用戶端提供設定驗證按鈕，請先驗證再套用，避免連原本可用的連線也一併中斷。

mihomo -t -f ./config.yaml

混合連接埠與監聽位址

mixed-port 讓 HTTP 代理與 SOCKS 代理共用同一個監聽連接埠。它是本機應用程式連接核心的入口，不是遠端節點的伺服器連接埠，也不是控制面板連接埠。以下設定只監聽迴路位址，適合單機使用。瀏覽器通常透過系統代理連線；命令列工具則可能需要另外設定代理環境變數。是否自動設定系統代理由用戶端負責，不是設定 mixed-port 就會自動完成。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

連接埠發生錯誤時，先確認入口是否被其他代理程式或殘留核心占用。請勿直接結束名稱不明的系統程序。關閉重複執行的用戶端，確認程序已結束後再重新啟動；若要更換連接埠，也要同步修改系統代理、瀏覽器擴充功能與終端機環境變數。若只改 YAML、卻保留舊的系統代理，常見情況是核心正常運作，瀏覽器卻顯示連線遭拒。相關命令可參閱連接埠占用排除教學。

建立可復原的修改流程

每次只調整一類設定，例如先改監聽連接埠，再調整 DNS，最後才啟用 TUN。套用後請建立新連線進行驗證，不要只依賴已建立的瀏覽器長連線。記下修改前後的欄位、發生問題的應用程式與記錄時間，才能在復原時判斷該還原哪個層級。若要向他人求助，只需分享最小設定片段；請移除訂閱網址、認證欄位與個人網路資訊，保留欄位結構及錯誤情境。

要確認設定是否生效，應查看新連線是否進入核心、命中了哪條規則，以及選用了哪個出口。開關已開啟、檔案儲存成功、設定檢查通過，各自只能證明不同階段完成。分開觀察這些層級，才能避免把連接埠問題誤判為訂閱問題，或只因介面顯示錯誤就重寫整份設定。

策略組類型與實際分流

規則決定流量交給哪個策略，策略組則決定從哪些出口中選擇。先為不同用途建立固定的組名，再讓節點在組內變動；訂閱更新時，就不必反覆修改規則。組名必須與規則目標完全相同，包括大小寫、空格與標點。策略組可以參照另一個組，但不能形成循環參照。例如，手動選擇組包含自動組很常見；若自動組反過來包含手動組，就會形成無法正常解析的依賴關係。

手動選擇與自動選擇

select 適合需要固定出口的情境，由使用者在用戶端選擇成員。url-test 會定期比較候選出口的測試延遲，適合希望自動調整的情境；fallback 依清單順序選擇可用成員，適合明確的主備配置；load-balance 會將不同連線分配給不同成員，不會直接合併單次下載的頻寬。請先依需求選擇合適的行為，再考慮測試頻率；不要只因自動組看起來方便，就把所有應用程式都交給它。

以下是用來理解參照關係的最小片段。成員只有內建的 DIRECT，因此不會提供代理出口；匯入有效訂閱後，才能將訂閱中已存在的代理或其他組加入成員清單。此範例著重於清楚呈現結構，而不是用虛構伺服器營造可連線的假象。實際使用時，請保留穩定的組名，並透過訂閱或本機設定管理具體成員。

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

rules:
  - DOMAIN-SUFFIX,example.com,出口選擇
  - MATCH,DIRECT

測速參數不等於使用體驗指標

自動測試通常需要 url、interval 等參數；tolerance 可減少延遲小幅變動造成的頻繁切換。測試網址應是所有候選出口都能穩定存取的輕量資源。範例網域只用於示範欄位位置，不能直接當作可靠的測速服務；正式設定前，請依自身網路挑選可存取的網址。測試太頻繁會增加請求量與行動裝置耗電；測試太稀疏則會延遲更新故障狀態，請依使用情境取得平衡。

測試成功表示出口能完成特定請求，不代表所有網站都能存取。某個出口可能連線交握很快，但尖峰時段頻寬有限；也可能適合瀏覽網頁，卻不適合對延遲抖動敏感的語音通話。比較自動組時，請使用相同測試目標、相近時段與新連線進行驗證。延遲的意義與測量範圍可參閱節點延遲測試與實際網速的差異，不要只根據毫秒數決定長期使用的出口。

將業務組與節點來源分開

長期維護的設定可分成兩層：底層組負責彙整節點、自動測試或主備切換；上層組則負責網頁、工作服務等業務選擇。規則只參照上層組，節點名稱變動時只需調整底層。使用 proxy-providers 時，策略組可透過 use 參照已定義的來源；來源名稱不等於節點名稱，必須先在完整設定中宣告。若用戶端會自動產生策略組，請先確認是否保留自訂組，避免更新時覆蓋同名設定。

需要維持穩定登入狀態的服務，優先使用手動組或明確的主備組。頻繁更換出口可能觸發額外驗證，也會改變以來源位址為依據的存取判斷。切換組成員後，既有連線通常仍沿用原路徑，只有新連線才會採用新選擇；必要時請在連線清單中關閉相關工作階段，不要誤以為切換未儲存。啟用負載平衡前，尤其要確認服務是否允許不同請求來自不同出口。

完成設定後，先用一條明確的網域規則測試業務組，再檢查兜底規則。全域模式可能略過原有的規則分流；直連模式也不會依預期使用業務組。因此，排查策略組行為時，請先確認目前使用的是規則模式。用戶端清單中看得到某個組，不代表流量已參照它；連線詳情中的規則與路徑才是最終依據。

以規則集管理訂閱

規則集用來管理規則來源與更新，不負責提供代理節點。rule-providers 用來宣告規則資料，rules 則決定何時參照，以及參照後採用哪個目標策略。兩者分工不可混淆：只下載規則檔、沒有設定 RULE-SET，規則就不會自動參與比對；設定了參照，來源卻未載入，則可能導致設定直接失敗。先讓少量本機規則正常運作，再加入遠端維護的集合，更容易分辨格式問題與網路問題。

行為類型與檔案格式

behavior 用來說明集合中包含哪種類型的規則。domain 適合網域集合，ipcidr 適合網段集合，classical 則儲存含有規則類型的項目，例如 DOMAIN-SUFFIX,example.com。規則目標通常由外層的 RULE-SET 指定，不要再把策略組名稱寫入 classical 集合項目。format 用來描述檔案格式；YAML、純文字與二進位格式無法只靠更改副檔名互換，行為類型也必須符合該格式支援的範圍。

以下範例使用本機 YAML 檔案，適合先驗證結構。相對路徑通常以核心的工作目錄為基準；GUI 用戶端可能使用自己的設定目錄，或設有檔案存取限制，不一定等於編輯器目前所在的目錄。請先在相應目錄建立 rules 資料夾並儲存規則檔，再將 provider 宣告合併至完整設定。業務規則要放在兜底規則之前；範例以直連為目標，不依賴外部代理組。

rule-providers:
  local-domains:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

上方範例的規則檔內容如下。檔案只包含比對條件，不包含代理伺服器、策略組定義或全域 DNS 設定。若使用 domain 類型，內容必須符合該類型的網域集合語法；不能只改一個欄位，就把同一份 classical 檔案當成另一種類型。載入失敗時，請先核對 provider 的行為類型與格式，再檢查檔案內容，最後才確認規則本身是否符合預期。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.net

從本機檔案改用遠端來源

改用遠端維護時，請將來源類型設為 http，填入有效的規則網址，並保留獨立的快取路徑與合理的更新間隔。interval 的單位是秒，不是分鐘。每個 provider 都應使用不同路徑，避免一個集合更新後覆蓋另一個集合。遠端來源必須指向規則檔的實際內容，而非網頁預覽頁面；即使下載成功，若回傳的是 HTML 登入頁或存取提示頁，也不能當成規則資料載入。

選擇來源時，應考量維護範圍、項目類型與更新方式，而非集合大小。涵蓋範圍過廣的集合可能改變原本預期的流量分流，尤其會影響工作網路、內網網域或特定應用程式的登入行為。首次加入時，請將個人例外規則放在集合之前，先用少數目標測試，再逐步擴大範圍。保留最近一次可用的本機設定；快取行為則依實際核心與用戶端而定，不要假設離線後一定能從空快取啟動。

規則順序與解析副作用

規則會由上而下比對，命中後即停止。精確網域例外要放前面，範圍較廣的網域後綴與規則集放後面，並以 MATCH 作為最後的兜底。IP 類規則可能需要先解析網域，增加一次解析等待；適用規則上的 no-resolve 可避免為了判斷該規則而主動發起解析，但不是所有規則都適用的通用開關。若要依網域決定策略，通常應先安排網域規則，再安排必須依位址判斷的規則。

特定目標的分流異常時，先從連線詳情確認實際命中的規則。若命中前面的廣泛集合，後面的個人例外就不會執行；若只命中兜底，請檢查網域資訊是否存在、規則檔是否已載入，以及目標是否使用了其他相關網域。若記錄顯示規則下載失敗，再檢查來源存取狀況與快取目錄權限。不要只因一個目標比對錯誤就更換所有規則集，否則只會擴大排查範圍。

長期維護時，建議為每個來源記錄用途與預期的目標策略。刪除 provider 前，先搜尋所有 RULE-SET 參照；變更組名時，也要同步修改參照目標。以本機小型集合保存個人例外，用遠端集合維護通用分類，可將更新風險限制在明確範圍內。若要理解複雜分流的術語，可參閱名詞速查，再回到連線記錄確認結果。

DNS 路徑與解析最佳化

先確認由誰負責解析，再選擇解析伺服器。應用程式可能使用系統 DNS、瀏覽器內建的加密 DNS，或直接連線至自己的解析服務；核心也可能為了查詢代理伺服器位址與判斷規則而另行發出請求。這些查詢不一定會走同一條路徑。若只修改 nameserver，但應用程式仍繞過核心解析，即使介面欄位設定正確，也不會改變實際結果。排查時應先確認目標查詢是否進入核心，再檢查選用了哪個上游。

預設解析、上游與節點網域

default-nameserver 主要用於解析 DNS 上游的網域名稱，通常會選擇可直接連線的 IP 位址。nameserver 是一般上游清單；proxy-server-nameserver 可用來解析代理伺服器網域，避免解析代理網域時又依賴尚未建立的代理路徑。不同網路可連線的解析伺服器各不相同；公共解析位址僅供參考，使用前應確認是否能連線並取得正確結果。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

此處的本機監聽連接埠只提供 DNS 服務，不是 HTTP 代理入口。設為 1053 不會自動讓系統 DNS 使用它；作業系統的一般 DNS 設定通常使用標準連接埠，要接入其他連接埠，則需要用戶端整合、轉送或 TUN 劫持。請先確認用戶端如何接管系統查詢，再設定監聽位址。不要為了讓另一台裝置存取而任意改成監聽所有位址；DNS 服務也必須限制存取範圍。

依網域指定解析路徑

nameserver-policy 適合處理內網網域、特殊服務，或必須由特定解析器回答的網域。公司內網網域可能只有公司 DNS 能解析，若傳送至公共解析器，可能會得到不存在的結果；公共服務則可能需要穩定的加密解析路徑。策略比對必須符合該欄位支援的網域語法，不要直接貼入完整的 rules 項目。先為明確的網域後綴建立策略，確認回應正常後再擴大範圍。

若啟用 respect-rules，DNS 上游請求也會依規則選擇路徑，因此必須準備可靠的代理伺服器網域解析方式。否則可能形成循環：建立代理前要先解析伺服器，存取解析器時卻又要求代理已經可用。排查循環時，請將代理伺服器解析交給可直接連線的上游，再確認 DNS 服務是否恢復。解析器清單越長不代表越可靠；多個上游還會增加結果差異與排查難度。

快取、IPv6 與問題排查

修改 DNS 後，瀏覽器、作業系統與核心都可能保留舊快取。驗證時請關閉相關舊連線，依用戶端支援的方式清除快取，再發起新查詢。不要根據舊頁面的一次重新整理，就判定新設定無效。使用系統查詢工具看到的結果，也只反映該工具使用的解析路徑；若瀏覽器啟用了獨立的安全 DNS，結果可能不同。必要時可暫時統一解析路徑，測試完成後再恢復日常設定。

IPv6 設定需要同時考量 DNS 是否回傳 IPv6 位址、系統是否有可用路由、代理節點是否支援相應的目的位址，以及 TUN 是否接管相關流量。只關閉一個 DNS 欄位，不代表其他應用程式就不會再發出 IPv6 請求。若部分網站要等待一段時間才開啟，請觀察連線是否先嘗試無法到達的位址，之後才改用另一個位址族。確認原因後再調整，不要把所有等待都歸咎於節點延遲。

記錄出現 DNS 逾時時，先檢查上游位址是否可連線，以及是否形成解析循環；若有回傳位址卻連線失敗，再檢查規則出口與目標服務。只有內網名稱異常時，優先檢查網域策略與內網 DNS，不要先更換整個代理組。依序檢查查詢入口、上游選擇、位址回應與業務連線，通常比不斷更換公共解析器有效。更詳細的記錄排查方式請參閱執行記錄解讀。

TUN 全域接管與 Fake-IP

TUN 是流量入口，Fake-IP 則是 DNS 映射方式，兩者不是同一個開關。TUN 會建立虛擬網路介面並調整路由，讓部分不遵循系統代理設定的程式也能將流量交給核心；Fake-IP 則會為網域回傳映射位址，核心收到連線後再還原對應網域。兩者搭配使用有助於保留網域資訊，但不代表適合所有裝置與應用程式。若瀏覽器已能正常使用系統代理，請依實際需求決定是否啟用 TUN。

啟用條件與最小接管設定

桌面平台通常需要管理員權限、服務模式或網路設定權限；行動平台則仰賴系統 VPN 介面。權限不足、服務未執行，或另一個 VPN 正占用網路介面，都會影響接管。請先在用戶端確認服務狀態，再啟用 TUN；不要只把 enable 改成 true，就期待路由自動設定完成。以下是 mihomo 常見欄位；是否由 YAML 控制，須先確認用戶端是否已接管同名設定。

tun:
  enable: true
  stack: system
  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
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route 負責自動設定接管路由，auto-detect-interface 用來識別出口介面；在多網卡、虛擬機與企業 VPN 環境中，仍可能選到不合適的介面。dns-hijack 針對可攔截的一般 DNS 請求，不會自動解密應用程式自己的 DoH。stack 涉及網路堆疊的實作方式；system、gvisor 或其他支援方式是否可用，取決於平台與核心建置版本，不應只看名稱就判斷速度。

Fake-IP 映射與相容性例外

Fake-IP 位址不是目標伺服器的真實位址，不適合用來判斷一般公網位址是否可連線。它仰賴核心保存網域與映射位址之間的對應關係，因此 DNS 查詢與後續連線應交由同一套處理機制。若應用程式快取了舊映射，但核心中的映射狀態已變更，可能會短暫出現存取異常。修改位址範圍或切換解析模式後，請視需要清除快取並重新建立連線，避免將映射失配誤判為規則故障。

部分區域網路服務、裝置探索、遊戲，或必須讀取真實位址的應用程式，需要加入 fake-ip-filter。上方範例只有常見的本地域名後綴，無法涵蓋所有內網情境；請依實際遇到問題的網域新增例外，不要直接排除所有網域。排除後通常會回傳真實解析結果；分流能否繼續依網域判斷，還取決於查詢路徑、快取關聯與嗅探能力。這是相容性調整，不是強制直連規則。

依流量、DNS 與路由分層檢查

啟用後先確認新連線是否進入核心。完全沒有連線記錄時，優先檢查權限、路由與應用程式排除清單；有連線但只看到位址時，檢查 DNS 是否走預期路徑；能辨識網域卻使用錯誤出口時，再檢查規則順序與策略組。只有部分 UDP 應用程式異常時，還要確認節點協定與伺服器端是否支援相關流量；網頁能開啟不代表所有協定都可用。

停用 TUN 後仍無法上網時，先確認核心是否正常結束、系統路由是否已復原，以及 DNS 設定是否仍指向已停止的服務。請優先透過用戶端關閉服務並重設網路設定，不要一開始就刪除所有虛擬網卡。若想了解底層接管原理與不同網路堆疊的取捨，可參閱TUN 虛擬網卡接管詳解，再依平台確認設定範圍。

可靠的驗收應涵蓋一般網頁、原本不會走系統代理的目標程式、區域網路服務，以及裝置休眠後的連線恢復。每項測試都應使用新連線，並確認實際命中的規則與出口。TUN 擴大了流量入口，問題範圍也會跟著增加；只接管確實有需要的程式並保留適當例外，比將所有流量一律導入更容易維護。

網域嗅探與規則比對修正

網域嗅探用來補充連線目標資訊，不會讀取所有加密內容。若應用程式直接連線至位址、DNS 查詢未經核心處理，或目標網域關聯遺失，規則可能只會看到 IP。嗅探會嘗試從協定交握或要求標頭擷取主機名稱，例如 HTTP 的 Host、部分 TLS 的 SNI，以及可辨識的 QUIC 交握資訊。擷取結果會受協定實作與隱私機制影響，無法保證每條連線都能取得網域。

先確認缺少的是網域資訊

只有當連線記錄長期只顯示位址，且相關網域規則沒有命中時，才需要優先考慮嗅探。若記錄中已有正確網域，問題更可能出在規則順序、策略組選擇或目標存取能力。啟用嗅探前，請先確認 DNS 與入口設定合理；嗅探只能補充資訊，無法取代 DNS 服務，也無法修復未進入核心的連線。將它視為補充層，才能維持清楚的排查順序。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

上述連接埠表示嘗試解析相應協定的範圍，不是監聽連接埠，也不會將範圍內的所有流量轉換成該協定。parse-pure-ip 允許對純 IP 目標嘗試嗅探，force-dns-mapping 則涉及 DNS 映射情境下的嗅探行為。override-destination 控制是否以嗅探到的網域覆寫連線目標；先設為 false，有助於避免同時改變目標資訊與連線方式，確認需求後再調整。

覆寫目標與僅補充辨識資訊的差異

覆寫目標可能讓後續連線依新網域重新處理，在某些分流情境中很有用，但也可能改變應用程式原本選定的位址。相同網域在不同解析器下可能對應不同入口，應用程式選定的位址不一定與核心重新解析後的位址相同。排查存取變化時，應同時查看嗅探出的網域、原始位址與最終出口；不要只因規則從 IP 規則變成網域規則，就認定修改正確。

應用程式若採用加密用戶端問候等會隱藏交握主機名稱的機制，或協定資料不符合嗅探器支援的格式，核心可能無法取得有效網域。此時即使擴大所有連接埠的範圍，也不一定有用，反而可能增加等待時間與誤判機率。若目標本身就是字面 IP 位址，可能也沒有可還原的主機名稱。可保留必要的 IP 規則，或依應用程式需求調整入口，不要把每次嗅探失敗都當成設定錯誤。

略過例外與驗證方式

內網裝置、特殊 TLS 服務，以及對初始交握時序敏感的程式，可依實際網域加入嗅探略過清單。請先重現問題，再新增精確範圍，避免為了一個例外就略過整類公共服務。例外清單只會影響嗅探，不等於直連規則；需要直連的流量仍應在 rules 中明確設定目標。不同用戶端可能未開放所有嗅探欄位；使用介面選項時，請以最終執行設定為準。

驗證時先停用嗅探並儲存目標應用程式的新連線記錄；接著啟用相同範圍，重新建立連線，比較網域、規則與存取結果。若使用瀏覽器測試，請避免沿用既有連線池。只有新連線取得預期網域，且存取行為穩定後，才適合擴大使用範圍。必要時可暫時提高記錄詳細程度；測試結束後請恢復一般層級，以減少輸出量及個人瀏覽記錄的留存。

QUIC 辨識也取決於 UDP 流量是否確實進入核心。系統代理通常無法讓所有應用程式的 UDP 都經過代理；TUN 或應用程式本身支援，才可能提供合適入口。若同一網站的 TCP 連線可被辨識，UDP 連線卻沒有記錄，請先檢查入口，不要反覆修改嗅探連接埠。若應用程式只在特定協定下發生異常，記錄連線協定會比只記網域更有幫助。

最終應保留一套即使缺少嗅探資訊也有合理兜底的規則結構。網域規則負責主要分類，必要的網段規則處理明確的位址範圍，最後的兜底規則則接手無法辨識的連線。嗅探可提升分類準確度，但不應成為整份設定唯一的辨識來源；如此一來，即使應用程式更新、網路環境改變或協定的隱私保護能力提升，設定行為仍然容易理解。

本機覆寫與多訂閱合併

個人規則應放在本機覆寫中，訂閱原始內容則交由更新流程管理。直接修改下載後的訂閱，下一次更新時可能全部遺失；將訂閱內容複製成永久本機檔案，又會失去正常更新能力。較容易維護的做法，是分清來源層、用戶端偏好層與覆寫層：代理資料隨訂閱更新，連接埠、業務組與個人例外則保持穩定。相關功能可能稱為覆寫、擴充、合併或腳本，不要只看介面名稱就假設合併方式相同。

物件、清單與合併順序

物件欄位可能遞迴合併，也可能整個取代；清單則可能附加、置前或直接覆蓋。尤其是 rules，若將個人例外加在 MATCH 之後，就不會生效。請先用一條容易辨識的網域例外測試置前行為，再批次加入規則。修改 dns 時，也要確認原有上游與策略是否保留；不能只因新增欄位存在，就假設舊設定仍然有效。

以下片段示範最終預期的規則順序，不是通用的用戶端覆寫檔語法。先放個人例外，中間保留既有業務規則，最後只留一條兜底規則。若用戶端要求使用專屬的 prepend 或 append 格式，請依該用戶端的說明操作；不要把最終執行設定片段當成所有用戶端都支援的擴充格式。執行設定才是檢查合併結果的共同依據。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

合併多個訂閱，先處理命名衝突

不同來源經常使用相同的策略組名與節點名，直接合併可能讓參照對象變得不明確。合併前應為各來源設定固定識別名稱，並確認重名時的處理方式。自動加上前綴後，手動成員清單與篩選條件也要一併更新；若只改顯示名稱、不改參照，策略組就可能找不到成員。不要把暫用測試名稱當成長期業務目標，最好讓業務規則一律參照本機定義的穩定上層組。

使用 proxy-providers 可分開管理不同來源，再由策略組透過 use 參照來源。provider 的 URL 是敏感訂閱資訊，請保留在個人設定中，不要放進公開截圖或求助資料。以下範例使用本機代理資料來源，須由使用者預先準備有效內容；它不是完整訂閱，也沒有提供任何可用節點。若來源沒有代理項目，請先處理來源本身，不要期待策略組自動產生出口。

proxy-providers:
  personal-source:
    type: file
    path: ./providers/personal.yaml

proxy-groups:
  - name: 訂閱出口
    type: select
    use:
      - personal-source

遠端代理來源應提供核心支援的代理集合格式；完整的 GUI 設定不一定能直接作為 provider 內容。訂閱轉換與用戶端匯入流程可能會負責擷取代理，但實際能力取決於實作方式。若來源載入成功卻沒有成員，請檢查資料結構、篩選條件與重新命名規則，不要先修改 DNS。篩選條件太寬會納入不希望使用的成員，太嚴格則可能讓整個來源變成空集合。

覆寫腳本的適用範圍

腳本適合用來去除重複項目、統一命名及批次插入規則，但輸入與輸出的範圍應清楚明確。修改陣列前先確認欄位是否存在；插入規則前先確認是否已加入，避免每次更新都多出一份重複規則。來源變動時，腳本應保留可供診斷的錯誤資訊，而不是回傳空設定。不同用戶端的腳本介面各不相同；只為了設定固定連接埠，沒有必要導入複雜腳本。

完成合併後，請驗收三種情況：個人例外是否排在一般規則之前、業務組是否包含預期來源，以及訂閱更新後覆寫是否仍然保留。再測試空來源或來源下載失敗的情境，確認介面不會把不可用的結構當成正常設定。多個訂閱代表更多獨立故障點；保留一份單一來源的可用設定，發生問題時就能迅速縮小範圍。

從舊用戶端遷移時，先搬移訂閱網址與必要的業務規則，再逐項恢復 DNS、TUN 與腳本。舊檔案中的介面欄位或擴充語法可能不受新用戶端支援，不能只因副檔名相同，就整份直接替換。舊版 Clash for Windows 與 ClashX Meta 已停止維護，可參考停止更新後的設定遷移指南；平台選擇則請參閱用戶端比較。

外部控制面板與執行診斷

外部控制器提供核心管理介面，面板透過它讀取狀態、切換策略組並查看連線。它不是代理入口，也不是 DNS 監聽服務。將瀏覽器代理指向控制器連接埠，不會建立正常的代理連線；將面板連線位址設為混合連接埠，也無法管理核心。設定面板前，請先確認各連接埠的用途。多數桌面使用者直接使用用戶端內建面板即可；只有伺服器或獨立核心等情境，才需要另外開放管理方式。

本機監聽與存取驗證

一般單機設定建議優先監聽迴路位址。範例中的 secret 是明確標示的教學假值，使用前請自行設定高強度隨機值，並僅保存在個人設定中。secret 用於保護控制介面，不能取代區域網路代理的認證。即使只監聽本機，也要考量其他本機程式的存取風險；需要遠端維護時，優先透過受控通道連線，不要直接公開管理連接埠。

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
log-level: info

用戶端可能會自動設定控制器位址與認證，手動輸入的欄位不一定是最終生效值。連線至面板前，請先查看執行設定或用戶端提供的管理入口資訊。面板設定中的主機、連接埠、協定與認證，必須對應同一個核心執行個體。電腦上若同時執行多個用戶端，面板可能連到舊執行個體，讓人誤以為切換策略沒有作用；請先確認目前連線的執行個體，再檢查介面是否正常。

面板檔案與瀏覽器存取限制

external-ui 用於指定本機面板資源目錄，目錄中應包含完整頁面及相關靜態檔案。不要任意填入不存在的資料夾，也不要把用戶端安裝目錄當成面板目錄。部署於伺服器時，面板資源、核心設定與快取路徑應分別管理權限；升級面板後，請確認資源路徑仍然正確。只使用內建面板的使用者通常不必自行設定此欄位。

瀏覽器顯示連線失敗，原因可能是認證錯誤、跨來源限制或混合內容攔截。HTTPS 頁面存取 HTTP 控制器可能會被瀏覽器拒絕，即使連接埠可連線，也無法正常發出請求。來自不同來源的獨立面板，也必須符合核心的跨來源設定；不要為了方便而允許所有來源並暴露控制器。最容易驗證的方式是使用用戶端提供的本機入口或同源面板；先確認運作正常，再擴充遠端存取方案。

透過執行記錄完成排查

先查看連線清單：目標網域或位址、命中的規則、策略組路徑與出口，是判斷設定效果的關鍵。接著查看同一時間點的記錄，區分 DNS 逾時、撥號失敗、連線遭拒與規則比對失敗。若將記錄層級從 info 暫時調高至 debug，只需重現一次目標問題，收集必要資訊後就應恢復設定。長期啟用詳細記錄會增加儲存用量，也會保留更多連線中繼資料。

完整重現問題時，請記錄時間、應用程式、目標、目前模式、入口方式與預期策略。網頁無法開啟，但連線清單完全沒有記錄時，先檢查應用程式入口與系統代理；有記錄卻缺少網域時，檢查 DNS 與嗅探；規則正確但撥號失敗時，檢查節點與遠端目標；切換後仍走舊出口時，檢查長連線。依照這個順序排查，才能避免 DNS 有問題卻不斷更換節點，或節點有問題卻反覆修改路由。

分享診斷資料時，優先截取相關連線與短時間的記錄，並隱藏訂閱網址、認證資訊及個人連線記錄。規則名稱與組名通常可保留，用來說明連線路徑結構；代理伺服器資訊則依實際隱私需求處理。不要直接上傳完整執行目錄，裡面可能同時包含快取、訂閱與用戶端設定。提供最精簡的重現資料，既能降低資訊外洩風險，也有助於他人正確判讀問題。

維護完成後，請回到可用基準：確認規則模式、一般記錄層級、預期監聽範圍與備用設定都已恢復。重新啟動一次用戶端，確認設定不只在目前工作階段有效；再檢查訂閱更新後個人規則是否仍然保留。初次設定仍有疑問，可返回系統代理入門步驟；需要查詢欄位意義，請使用名詞速查。進階設定的目標是行為清楚、修改可驗證、故障可復原，而不是盡可能增加開關。