策略組類型與實際選擇
策略組會決定符合規則的連線最後交由哪個節點或出口處理。排查分流時，先看規則指向的組名，再確認該組目前選取的成員；只看代理清單中哪些節點顯示可用，無法判斷這條連線實際會使用哪個節點。常見設定會先將節點放進「手動選擇」，再讓「自動選擇」、「故障轉移」等組別引用相同節點，最後由流量規則指向這些上層組別。組名必須與規則最後指定的目標完全一致，包括大小寫與空格。訂閱更新加入新節點後，也要確認節點篩選條件仍能符合預期名稱。
四種選擇邏輯
select 會保留使用者指定的成員，適合需要固定出口的登入或遠端存取情境；即使測試結果改變，也不會自動切換節點。url-test 會依測試 URL 的回應時間選擇成員，適合可接受出口變動的一般瀏覽。fallback 會依成員順序使用第一個可用項目，適合優先使用主要線路、故障時才切換的情境。load-balance 會將不同連線分配給不同成員；若網站登入需要固定出口，先不要讓登入流量經過負載平衡組。測試成功只表示測試網址可連線，不代表所有目標網站都能使用；遇到特定網站連線失敗，仍須檢查實際連線記錄。
| 類型 | 出口何時變更 | 優先檢查項目 |
|---|---|---|
select | 使用者手動選擇成員時 | 目前選取項目、成員名稱 |
url-test | 定期測試後選出較快的成員時 | 測試網址、間隔、容差 |
fallback | 前面的成員測試失敗時 | 成員順序、測試狀態 |
load-balance | 新連線進入組別時 | 分配策略、目標網站工作階段 |
將節點加入方便檢查的組別
以下假設設定中已有名為「節點甲」與「節點乙」的代理。實際使用時，請以訂閱提供的節點名稱替換這兩個成員，並避免建立兩個同名策略組。interval 的單位是秒；tolerance 是自動選擇時允許保留目前成員的延遲差值，可減少測試結果相近時頻繁切換。測試 URL 應選擇目前網路可穩定連線、且會回傳簡短回應的網址，不建議使用需要登入的網站作為測試目標。
proxy-groups:
- name: 手動選擇
type: select
proxies:
- 節點甲
- 節點乙
- DIRECT
- name: 自動選擇
type: url-test
proxies:
- 節點甲
- 節點乙
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 故障轉移
type: fallback
proxies:
- 節點甲
- 節點乙
url: http://www.gstatic.com/generate_204
interval: 300
rules:
- DOMAIN-SUFFIX,example.org,手動選擇
- MATCH,自動選擇選擇邏輯還有一個容易忽略的差異：節點測試是針對組內成員進行，實際請求則會先比對規則。若直連規則排在範例的網域規則之前，該請求根本不會進入「手動選擇」。診斷時開啟用戶端的「連線」頁面，找到目標網域與命中的規則，確認規則指向哪個組別；接著到「代理」頁面檢查組內成員及選取狀態。變更後若舊連線仍顯示原本的出口，請中斷該連線後重新發出請求，因為已建立的連線通常不會在途中切換路徑。
最後檢查兜底規則。MATCH 通常應放在規則清單末尾，負責處理前面規則都未命中的流量。若將它放在前面，後續的細分規則就不會生效。若要暫時確認規則是否生效，可讓明確指定的網域指向手動組別，建立新連線並查看記錄，而非直接將所有流量切換為全域模式。測試後刪除診斷規則，並還原原有順序與選取項目，讓每次變更都能追蹤。
以規則集管理訂閱規則
規則集可將經常變動的網域或 IP 項目從主要設定中分離，由 rule-providers 指定來源、格式與本機快取位置，再於 rules 中使用 RULE-SET 引用。這樣更新規則內容時，不必逐條修改主要設定，但也多了一段載入流程：下載、解析、快取與引用規則集，任何一步出錯都可能導致分流未如預期。先確認需要的是遠端規則集，還是少數長期不變的本機規則；自訂網域只有幾條時，直接寫在 rules 中會更容易維護。
辨別規則集內容格式
behavior: domain 用於網域項目，behavior: ipcidr 用於網段，behavior: classical 則可包含完整的傳統規則表示式。format: yaml 與 format: text 必須符合下載內容，不能只看檔案副檔名。YAML 規則集通常會在 payload 下列出項目；傳統規則集則可能包含 DOMAIN-SUFFIX 等類型前綴。若將傳統規則文字當成網域規則集載入，或把網頁錯誤訊息當成規則檔快取，都會造成解析失敗。首次引用遠端網址前，先用瀏覽器確認回傳的是規則內容，而不是登入頁或重新導向後的說明頁。
範例以文件網站的網域展示欄位關係，該網址並非可訂閱的規則來源。實際使用時請換成信任的規則集網址，並依檔案內容調整 behavior 與 format。快取的 path 請使用設定目錄下的相對路徑；不同 provider 不應共用同一個檔案。interval 控制檢查更新的週期，不代表每次請求都會重新下載。
rule-providers:
work-domains:
type: http
behavior: domain
format: yaml
url: https://example.com/rules/work-domains.yaml
path: ./rules/work-domains.yaml
interval: 86400
rules:
- RULE-SET,work-domains,手動選擇
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,自動選擇對應上例的 work-domains.yaml 可採用以下格式。網域規則集只需列出網域項目，不必每行都加入主要設定 rules 清單中的策略組名稱；出口由引用它的 RULE-SET 規則指定。同一規則集也可由多條規則引用，但須留意排列順序：前一條規則命中後，後面的規則就不會再參與判斷。
payload:
- example.net
- '+.example.org'依載入流程排錯
更新後先確認用戶端是否回報規則集下載或解析錯誤，再檢查快取檔是否存在、內容格式是否正確。若下載成功但規則未生效，請檢查 RULE-SET 指定的 provider 名稱、對應的策略組名稱，以及該規則在 rules 中的位置。網域規則需要取得可供比對的網域資訊；只有目標 IP 的連線不一定會符合預期的網域規則。IP 規則也要留意 DNS 解析及 no-resolve 等選項對比對流程的影響，不要為了讓單一規則命中，就一次改動所有 DNS 設定。
訂閱本身也可能提供規則與規則集。若用戶端每次更新訂閱都會覆蓋主要設定，直接修改下載後的設定只會是暫時變更；請改用用戶端的覆寫功能，或在自行維護的設定中固定規則來源。遷移規則時，先保留一個已知且可驗證的網域，重新載入後到「連線」確認它命中新的 RULE-SET，再批次遷移其他項目。不要同時啟用兩套作用重疊、優先順序不明的遠端規則；先確認規則排列順序及各自的兜底用途。
DNS 設定與解析流程
DNS 設定會影響兩件不同的事：目標網域如何解析，以及代理伺服器本身的網域如何解析。先確認瀏覽器送出的 DNS 查詢是否會進入用戶端，再檢視解析伺服器清單。系統代理通常會接管應用程式的 HTTP 或 SOCKS 流量，但不代表系統中的所有 DNS 查詢也都會經過代理；TUN 模式及其 DNS 劫持設定則是另一條路徑。若網域已成功解析卻仍無法連線，應一併檢查規則命中、節點連線狀態與目標連線記錄，不能只憑「網頁無法開啟」就判定是 DNS 問題。
認識幾種伺服器欄位
default-nameserver 主要用於引導階段，例如解析 DNS 伺服器本身的網域，建議使用可直接連線的 IP 位址。nameserver 是一般查詢使用的伺服器清單；proxy-server-nameserver 可單獨指定解析代理節點網域的伺服器，避免節點解析受到業務網域分流設定影響。nameserver-policy 則可依網域指定解析器。請勿混淆伺服器 URL、一般 IP 與含連接埠的位址格式：填入的通訊協定格式必須符合目前核心支援的 DNS 上游，且相關網路必須能連線至上游伺服器。
以下片段展示最基本的分工，並不表示必須將所有解析器都換成範例位址。啟用前請確認目前網路可連線至這些位址，尤其是在網路受限，或需要透過內部 DNS 解析辦公網域的環境。respect-rules 等會進一步影響 DNS 出站路徑的選項，應在確認基本解析正常後再評估，避免解析器與代理節點的網域解析互相依賴。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 1.1.1.1
nameserver:
- 1.1.1.1
- 8.8.8.8
proxy-server-nameserver:
- 1.1.1.1
fake-ip-filter:
- '*.lan'
- localhost.ptlogin2.qq.comipv6: false 只是範例設定，並不表示所有網路都應停用 IPv6。如果本機、上游解析器與代理連線都能正常使用 IPv6，請依實際需求決定是否啟用。fake-ip-filter 可讓特定網域取得真實解析結果，適合需要區域網路探索或無法使用 Fake-IP 的應用程式；項目越多，就越需要確認是否意外避開預期的比對流程。內部網域最好交由能解析該網域的內部 DNS 處理，不要期待公共解析器回傳區域網路位址。
用一筆請求找出問題
先確認用戶端的 DNS 功能已啟用，重新載入設定後查看記錄是否顯示上游無法連線。接著使用目標網域建立新連線，確認取得的是真實位址、Fake-IP，還是完全沒有回應。若用戶端記錄中沒有該次查詢，請檢查應用程式是否使用自己的安全 DNS、系統是否仍指向其他解析器，以及目前代理模式是否會接管這類請求。若記錄有查詢但回應不符預期，請檢查 nameserver-policy 命中項目、Fake-IP 篩選設定與本機快取；變更設定後，可依用戶端提供的方式清除快取並重新測試，以免將舊答案誤認為新設定的結果。
DNS 伺服器回應正常，不代表後續連線也一定正常。測試時最好選擇網域與出口策略都明確的請求，並在「連線」中查看最後命中的規則；若命中 DIRECT，就沿著直連網路繼續檢查；若命中策略組，則再確認該組所選的節點。辦公網路尤其需要保留內部網域的解析路徑：先記下原本的 DNS 設定，再逐項調整，不要在排錯時同時修改 DNS、規則與 TUN。如此才能確認問題從哪次變更開始出現。
TUN 模式與 Fake-IP 搭配
系統代理與 TUN 的涵蓋範圍不同。系統代理要求應用程式遵循作業系統的代理設定；TUN 則會建立虛擬網路介面，讓更多不會主動讀取代理設定的流量進入用戶端。啟用 TUN 並不能自動解決所有問題：路由安裝、DNS 劫持、其他 VPN、區域網路存取與系統權限都可能影響結果。初次啟用前，先確認一般系統代理已能正常連線，並記錄目前的 DNS 與路由狀態；這樣啟用 TUN 後若發生問題，才能分辨是原有設定有誤，還是新的接管路徑造成。
從最精簡的設定開始
auto-route 會讓核心嘗試設定路由，auto-detect-interface 用於識別實際的出站介面；網路介面經常變動的裝置尤其需要確認識別結果。dns-hijack 中的 any:53 表示接管符合條件的傳統 DNS 查詢，但不保證能接管應用程式自行建立的加密 DNS 連線。不同用戶端可能透過介面開關寫入這些欄位，也可能需要系統授予網路擴充功能或虛擬介面權限；請以用戶端顯示的生效設定為準，不要只看開關表面上是否開啟。
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/16stack: mixed 是可供測試的網路堆疊選項。若特定應用程式的交握或區域網路存取異常，請先記錄問題，再比較用戶端支援的其他堆疊，不要同時調整所有路由參數。若裝置上已有企業 VPN、其他透明代理或虛擬機器網橋，請留意路由優先順序與介面衝突：兩套軟體都試圖接管預設路由，可能造成連線反覆中斷，甚至讓原本應走內網的位址走錯出口。可先暫停另一套接管工具進行比對，再決定是否需要排除路由或調整介面。
了解 Fake-IP 的對應關係
Fake-IP 不會立即將目標網域解析為真實位址，而是先提供合成位址給應用程式，並由核心保留網域與該位址的對應關係。後續連線送達時，核心會據此還原網域，讓網域規則能參與比對。此機制仰賴 DNS 查詢與後續連線都經過可關聯的路徑進入用戶端；若應用程式使用另一條 DNS 通道，或快取了舊位址，網域與連線可能無法對應。若某個應用程式只顯示 IP、未命中網域規則，請先確認該應用的 DNS 查詢與連線是否都出現在記錄中。
區域網路裝置探索、印表機、投放功能，或某些只接受真實位址的應用程式，可能不適合使用 Fake-IP。先針對明確的網域新增篩選項目，再測試裝置探索與連線，不宜大範圍排除整個網域後綴清單。若仍無法連線至區域網路 IP，請確認規則是否將私有位址送進代理組，並檢查作業系統防火牆與本機網路權限；Fake-IP 篩選只能處理解析結果，不能取代路由規則。完成診斷後，分別測試瀏覽器、不遵循系統代理的應用程式，以及一項區域網路服務，確認 TUN 確實接管了需要的流量，同時仍可存取本機網路。
網域嗅探與規則命中
當用戶端只看得到目標 IP，卻需要依網域規則判斷出口時，網域嗅探可嘗試從連線交握中取得網域。它主要檢查 HTTP 請求或 TLS、QUIC 交握中可見的資訊，不會讀取網頁內容，也無法憑空得知所有加密連線的原始網域。是否以嗅探到的網域取代連線目標，以及是否用於路由判斷，取決於相關選項。啟用前先查看「連線」頁面：若目標網域原本就完整顯示，而且規則命中正常，就不必為了顯示更多網域而擴大嗅探範圍。
限制通訊協定與連接埠
以下範例只涵蓋常見的 HTTP、TLS 與 QUIC 連線。ports 用來限制檢查範圍，override-destination 則決定是否依嗅探結果覆寫目標；先保留符合目前應用程式的連接埠，再針對異常連線進行測試。QUIC 使用 UDP；若你的網路或用戶端未接管相關 UDP 流量，單獨新增 QUIC 嗅探項目也不會讓這些連線進入核心。HTTP 使用非標準連接埠時也一樣，須依實際服務連接埠逐一確認。
sniffer:
enable: true
sniff:
HTTP:
ports:
- 80
- 8080-8880
override-destination: true
TLS:
ports:
- 443
QUIC:
ports:
- 443
skip-domain:
- '+.lan'範例略過區域網路網域，是為了避免對明確應走本機網路的目標進行額外判斷。實際設定還應依應用程式調整：有些程式透過 IP 連線至伺服器，卻在 TLS 交握中帶入與連線目標不同的網域；若強制以嗅探結果覆寫目的地，可能改變原本的路由行為。若特定服務只有在啟用嗅探後才連線失敗，先比較啟用前後的目標位址、命中規則與錯誤記錄，再為該目標設定排除條件，不要直接關閉所有規則分流。
將嗅探納入完整排錯流程
一條連線能否依網域分流，至少要確認三件事：DNS 是否提供可供對應的網域、嗅探是否取得並採用該網域，以及規則清單是否在兜底規則之前命中相應的網域項目。若「連線」頁面只顯示 IP，先確認應用程式是否原本就使用固定 IP；若有顯示網域但出口仍不正確，應優先檢查規則順序與策略組，不要繼續增加嗅探通訊協定。若使用 Fake-IP，也要確認應用程式的 DNS 查詢與連線是否都經過同一條接管路徑。
網域嗅探不適合當成「將所有 IP 轉成網域」的通用開關。並非所有通訊協定都有可辨識的主機名稱，通訊協定更新也可能改變交握中可見的欄位。記錄中沒有嗅探結果，不代表用戶端沒有處理該連線；應回頭檢查可驗證的連線目標、規則命中與最終出口。調整時依應用程式測試，每次只修改一個通訊協定或排除項目，先中斷舊連線再重新發出請求。若問題只出現在瀏覽器，也要確認瀏覽器是否啟用獨立 DNS 或 QUIC，以及它的流量路徑是否與其他應用程式相同。
本機覆寫與多訂閱合併
訂閱檔由提供者更新，直接編輯下載後的副本，通常只會保留到下次更新。本機覆寫可將自行維護的連接埠、DNS、規則與策略組調整，和持續更新的節點資訊分開。不同用戶端的覆寫方式不盡相同：有些會在匯入設定後套用補丁，有些會依欄位合併，也有些會透過指令碼產生最終 YAML。先在用戶端介面尋找「覆寫」、「設定合併」或類似功能，了解套用順序，再挑一個容易觀察的欄位進行測試。不要假設陣列一定會追加；若規則或策略組遭到整批取代，原有分流可能就會消失。
先確認最終生效的檔案
可靠的檢查對象不是編輯器中的片段，而是用戶端載入後的完整設定。請確認 mixed-port、mode、dns、proxy-groups 與 rules 都只保留預期內容。以下範例是可放入自行管理設定檔的頂層設定示意；若用戶端覆寫介面只接受特定補丁格式，請依介面要求轉換，不能將此範例視為所有用戶端通用的覆寫檔。若連接埠發生衝突，先確認是哪個程序占用了該連接埠，再修改設定並同步更新使用該連接埠的應用程式。
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info合併多份訂閱時也要留意節點命名。兩份訂閱可能都提供「自動選擇」、「預設節點」或相同的地區名稱；若合併工具依名稱覆蓋，最終設定可能會引用到另一份訂閱的成員。合併前先保留原始訂閱，記下各自的節點命名與更新頻率；合併後檢查最終 proxies、proxy-providers、proxy-groups 的名稱引用。節點清單只是原料，仍須明確設定由誰負責選擇節點、規則指向哪個組別，以及訂閱更新後新節點如何加入組別。
固定更新後的驗證步驟
先讓每份訂閱各自完成一次更新，確認原始設定可以解析；接著套用本機覆寫，確認最終設定能正常載入。然後檢查一條直連規則、一條代理規則與最後的 MATCH 規則，分別建立新連線確認命中結果。最後再更新一次訂閱並重新測試：若第一次成功、更新後失效，請優先檢查覆寫是否重新套用，以及組內成員篩選條件是否符合更新後的節點名稱。記錄問題發生於下載、合併、解析或連線階段，就不容易把不同類型的問題混在一起處理。
規則清單最好明確由單一位置負責安排最終順序。若訂閱甲的 MATCH 排在訂閱乙的細分規則之前，乙的規則就永遠不會執行；若合併工具直接拼接多個同名組別，也可能造成引用不明。請保留一份可正常連線的原始設定，並在每次大幅修改前複製目前可用的覆寫內容。若要了解訂閱連結提供的是完整 YAML 還是節點清單，請參閱訂閱格式與轉換說明；轉換格式不代表原有規則與策略組一定能完整保留。
外部控制面板與設定檢查
外部控制介面可讓相容的面板讀取連線、規則與策略組狀態，也可能支援切換策略或重新載入設定。它與混合代理連接埠是不同服務：mixed-port 接收應用程式流量，external-controller 則提供管理介面。診斷設定時，可透過面板確認目前選取的組別、檢視實際連線與規則；不過面板顯示的結果仍以正在執行的核心為準。若用戶端內建介面已提供這些資訊，可先使用內建介面，不必額外開放網路管理入口。
先綁定本機位址
若只在目前電腦上使用面板，請將控制介面綁定至 127.0.0.1，不要為了連線至本機面板而改成監聽所有網路介面。範例中的空白 secret 只適用於隔離的本機測試；若確實需要讓區域網路裝置存取，請設定專用的管理密鑰、限制可存取的網路，並檢查系統防火牆。不要將訂閱連結、管理密鑰或包含節點憑證的完整設定貼到來源不明的線上面板。
external-controller: 127.0.0.1:9090
secret: ""
mixed-port: 7890
mode: rule控制介面位址由核心提供，面板本身也必須知道連線位址。有些用戶端內建面板會自動讀取，有些獨立面板則要求手動輸入。若無法連線，先確認核心確實載入了這段設定，再確認連接埠未被其他程序占用、面板連線的是同一台裝置，以及瀏覽器或系統代理沒有將本機控制請求送往遠端。修改連接埠後，也要一併更新面板儲存的位址。若出現驗證錯誤，請檢查控制介面的密鑰設定，不要誤填節點訂閱密碼。
從面板結果回頭檢查設定檔
面板能顯示某個組別，不代表規則已引用它；組別可以切換，也不代表新連線一定會使用該組。逐項檢查時，先在「設定」確認目前載入的檔案及其更新狀態，再到「規則」檢查目標網域對應的規則，最後在「連線」查看該次請求的比對結果。若用戶端切換設定後面板仍顯示舊組別，可重新整理面板，並確認控制介面是否連到另一個正在執行的核心執行個體。不要只根據面板快取的內容修改設定。
設定載入失敗時，先查看記錄中指出的欄位與行號，再檢查 YAML 縮排、重複的頂層鍵、規則指向的組名，以及 provider 的本機路徑。YAML 以空格表示層級，清單項目的連字號必須位於正確層級；從網頁複製設定時，若混入定位字元或全形標點，也可能導致解析失敗。先還原已儲存且可用的設定，再逐段加入本頁範例並重新載入，比在已失效的完整檔案中反覆猜測更穩妥。若是初次安裝後不清楚如何建立連線，請返回快速入門；若要更換圖形化用戶端，可在下載頁面依平台選擇，Clash Plus 為優先推薦選項。