一、先對齊現象：解析慢、污染與線路對調
Clash DNS 區段調不好時，問題常常不是全域斷線，而是一組「混在一起」的典型症狀：瀏覽器狀態列長時間卡在「查找主機」，或要等好幾秒才開始載入資源列；只有你所在網路才會對特定網域回傳明顯不合常理的紀錄位址（常見的描述是劫持或污染感）；另有讀者是跨境或兩岸混用環境時，發現國內與國外 CDN對調解析，例如該離你近的邊緣節點沒有被選取，視訊卡在錯區域的來源。nameserver 若不可達會表現為整體卡住；若主線回傳了「可疑答案」而你沒備好fallback 或過濾條件，體驗就只會更不穩定。
實務上建議先做兩種分流：其一是區分問題出在本機對系統／瀏覽器的 DNS，還是真正走到 Clash 內建的解析鏈——若你已把系統指向 Clash DNS 監聽位址（或 TUN 模式下由核心接管），異常多半是 dns: 設定與劫持互動所致。其二是區分問題是否僅發生在代理命中主機名時，這往往與 enhanced-mode、fake-ip 與規則中「出站」對齊有關。若僅在未開代理的行動數據上重現，則多半是上游 DoH／DoT 被擋或非標準埠被過濾，而不是節點延遲本身。
若你已遇到「改了規則卻像沒變」的情境，也值得交叉閱讀本站 fake-ip 與 fake-ip-filter 排障一文：該篇以相容性問題為主軸，與本篇「如何把 nameserver／fallback／policy 寫對」相加，就能把多數奇怪的解析症狀收斂到可復現的流程。
二、釐清鏈條：nameserver、fallback 與規則的關係
在 Mihomo／Clash.Meta 這類相容 Meta 規格的核心裡，dns: 區段可以理解成：nameserver 清單是日常主要的上游組，當結果被視為異常或被判定需要第二意見時，核心會再並行或順序地使用fallback 組去補位；而 nameserver-policy 會在規則層對「這個網域該問誰」做覆寫。fallback-filter（以及相關的 geoip／網域條件）則決定「哪些答案算不可信」，直接影響 fallback 是否真的會接上。
這條鏈路和你在 RULE 裡配置的「直連或經由代理出站」並不是同一語意：DNS 只決定紀錄位址或其前置資訊（在 fake-ip 下又會再走不同的延遲路徑），而規則才決定封包離開機器後走哪張表、經哪個節點。若只有 DNS 對了、規則卻把所有流量導錯區域，結果仍會像「載入對但速度怪」或「對站點可連卻拿不到正確國別庫」，因此本篇在後段會把 DIRECT 流量是否仍會經過 Clash DNS 一起放在同一張檢查清單裡面。
三、第一步：收斂主要 nameserver（可連線、延遲合理）
第一步永遠是可連線性與來回延遲。不要一開始就往最複雜的 policy 與規則集塞滿：nameserver: 裡如果只放對你目前環境並不可用的 DoH 位址（例如 HTTPS 被查、SNI 被干擾、企業對特定雲 DNS 限速），再多的 fallback 都只會在多條不可用路線之間打轉。A／B 的方法很直接：備一組_udp 格式的公共解析或另一套 DoT／DoH，僅調整這一段後重新載入，觀察啟網時間是否按比例改善。
對桌機來說也可搭配作業系統層的命令列對照：對同一主機名作直連查詢，再與 Clash 監聽位址的答案比對，若兩邊紀錄差異過大而你又必須直連國內或海外其中一側，就能把「污染」問題從節點或 TLS 問題中剝離。若你會在WSL／Windows／macOS／Linux來回切環境，可先讀 WSL2 與本機 localhost DNS 專題，避免只看到「宿主機對、子系統錯」的假象。
dns:
enable: true
# Prefer resolvers reachable on YOUR network; names are placeholders
nameserver:
- "https://cloudflare-dns.com/dns-query"
- tls://dns.google
# - udp://ISP-or-office-resolver-if-needed上面片段只做示意——實際條目不應複製論壇全集，而是依你所在地的連線結果裁剪；並注意合併訂閱時避免重複的 dns: 鍵衝突。若客戶端提供「劫持開關」或「自動改系統 DNS」類選項，改完 YAML 請確保你已套用設定並清空快取，否則舊紀錄仍會混入觀察。
四、第二步：加上 fallback 與 fallback-filter
當環境中存在回傳虛假或固定攔截頁對應之 IP 的中间解析路徑時，單線 nameserver 很難自癒。fallback 的價值在於準備不依同一營運商或地理位置的備援視角；而fallback-filter 決定何時要相信備援的答案。許多複製來的規則把 geoip／網域條件寫得非常激進：過鬆會導致幾乎不啟動 fallback，過緊會在邊際網域名上來回抖動——兩種都會讓人覺得「莫名其妙慢」。
操作上建議：先保持 filter 為官方範本建議級別，僅對你確認有必要的主機名作微調；每改一類條件就記錄變更前後的時間範例（例如十位常訪問站點的首次連線毫秒數），避免將暫時的網際擁塞誤認為規則成功。對於懷疑劫持的紀錄，也可以把異常紀錄位址對照為公有黑名單或已知的劫持模式，協助你判斷是該強化過濾還是該換問答路線。
dns:
fallback:
- "https://dns.google/dns-query"
- "https://1.1.1.1/dns-query"
fallback-filter:
geoip: true
# Keep domain / ipcidr lists aligned with your threat model
geoip-code: CN
# domain / ipcidr entries edited per upstream docs ...dns 區段重複定義而造成合併後語意漂移。
五、第三步：nameserver-policy 做分域／分線路
當日常使用國內與國外站並重時，將所有查詢丟進單一二遞迴往往不是最穩的——某些後綴在境內邊緣節點回應會快且貼近實際路由，另一些則適合交到跨境延遲低、對污染抵抗力較好的上游。nameserver-policy 可把指定網域或後綴映射到具名的解析器組（常見為先定義在 proxy-server 或對應的 DNS 區塊內可用的上游鍵）。這能降低「國內站卻跨海問」「境外站被迫走易受劫持路徑」兩種極端的機率。
撰寫 policy 的同時請同步檢查GEOIP／規則裡對該域名的出站標籤：DNS 對了但規則把流量導錯區域時，CDN 視角仍會顯得像故障。若你希望更完整理解為何瀏覽器測試仍顯露真 IP，可對照本站 WebRTC／DNS 專題，區分是真正的解析外洩還是多路徑測試的誤讀。
| 你看到的情況 | 優先拉回 YAML 的哪一段 |
|---|---|
| 僅在行動數據上慢 | nameserver／DoH 主機是否在該運營環境仍可連；必要時準備可被接受的 UDP／DoT backup |
| 極端像污染或對錯國別 | fallback 是否真的被叫到；fallback-filter 是否過鬆／過緊 |
| 境內外站點體驗對調 | nameserver-policy 是否缺漏對應後綴；並核對 GEOIP／策略組的出口語意一致 |
六、fake-ip 與直連／代理出口的對齊
在fake-ip 模式中，對多數程式而言，紀錄階段回傳的是保留區段位址，再由核心在發起連線時處理實際目標。fake-ip-filter 與本篇主線不同，但它的存在會影響「哪些主機仍需走可信上游」：若你希望某類主機對國內與國外解析策略都保持敏銳，通常會將其加入 filter，使解析走真 IP，再配合 policy 對齊對應的 nameserver。DIRECT（直連）路徑下，紀錄正確不代表封包就一定能走對實體電路——仍要對照規則中「繞過中國大陸」「排除本機區域網」「TUN／系統 DNS 委派」這些並行機制。
與規則層對齊的實用做法：對於你判定應為境內直連的流量，確保其首跳解析與國內 GEOIP／策略順序相容；對於必須走代理的出口，理解代理節點所在區域對該 CDN 的解析未必與你用戶端地理一致——那不一定是 DNS 規則寫錯，而是國際視角本就不同。將「紀錄層」（DNS）與「包轉發層」（規則與出站）分欄紀錄在筆記中，可避免每次只靠直覺重刷訂閱。
若需要更細的 fake-ip／嗅探相容討論，仍以 fake-ip-filter 全文 為優先後援；本篇只要求你在調整 YAML 後不要忘記對齊這兩層的一致性。
七、YAML 套用到核心後如何驗證
- 重新載入或重啟：以你正在使用的桌面／行動端客戶端提供的「套用設定」「重啟核心」入口操作，並關閉瀏覽器或應用在背景快取的舊紀錄（必要時清空暫存的 DNS／重開應用）。
- 對照連線紀錄：在日誌中搜尋出問題網域名稱，比對被查詢到的上游標籤、回應碼是否符合預期的 nameserver／fallback 順序——若紀錄關鍵資訊被精簡，可暫開除錯層級觀察一輪再關。
- 系統對照：以作業系統原生命令對同一主機名查詢，核對在非 fake-ip／或 fake-ip-filter 下的差異是否合理；對照項目應固定在相同網卡與時間窗內進行。
- 漸進還原：若在驗證期間發現新的卡頓，優先復原上一版已知良好的
dns:段落，再在副本檔案中做第二輪試驗，避免在主設定裡來回無版本控管地塗改。
對希望系統掌握整個模組對應表的讀者，建議再打開本站 設定與詞彙說明的文件區，把本章提到的鍵值與你客戶端顯示的介面詞彙互相比對——介面語系與訂閱供應商命名各有不同，對照詞彙能顯著減少誤會。
八、小結與後續閱讀
Clash／Mihomo 的DNS 並非只靠單一串上游就能兼顧速度與對抗劫持。nameserver、fallback、fallback-filter 與 nameserver-policy 是一組配套：先把主要上游收斂到在你網路上真正可用，再準備可被觸發的備援與過濾，最後對境內外常用後綴做分域對齊。完成後請把它們放回與規則、fake-ip／filter 一起看，否則常見的「對了紀錄、錯在出站」問題仍會讓人以為規則全失效。
若你依序完成上述調整並以日誌與系統查詢交叉驗證，多半能把解析慢／污染／線路錯配的「毛邊」壓到低於主觀門檻。與社群腳本的即插即用模板相比，自己理解每一條上游與過濾的用途，將讓長期維護成本降到最低。
相較其他同級工具，Clash 全家在規則敘述、DNS 與多協定整合上的文件資源較為齊備；將 DNS、分流與用戶端模式放在同一張心智圖上管理，日常載入時間與穩定性會有明顯體感的提升。