搜尋意圖先對齊：您要的到底是不是「分域解析」？
若你的目標只是在客戶端「開加密 DNS」，通常只要設定好 nameserver 列表與 fallback，再確認 dns-hijack 與 TUN 搭配無誤就能收斂。當你開始出現這些情境，才值得把 nameserver-policy 納入預設範本：同一台電腦會大量存取「必須回境內 CDN 答案」與「必須回國際公開解析結果」的網域；你希望少數金融、郵件、特定 API 網域永遠走固定 DoH；或你發現某類服務在預設上游下頻繁得到「看似成功、實則與路由規則不一致」的位址，懷疑是解析出口不同所導致。換句話說，它是把「DNS 路由」寫進設定檔的一種方法，而不是取代 rules 裡的連線決策。
反過來，如果你遇到的說法是「開了代理卻仍洩漏 DNS」，請先回到 DNS 防洩漏長文把管線與是否由核心接管釐清；若症狀是內網名稱、*.local、路由器後台在 FakeIP 下失效，則應優先檢視 fake-ip-filter 與內網規則是否一致。把這幾條路分開，才不會在 YAML 裡越補越亂。
nameserver、fallback 與 nameserver-policy 的分工
實務上可以把三者想成一個兩層決策：沒有特別理由時，查詢走 nameserver；當你啟用 fallback 機制且命中異常條件時，改走 fallback；而 nameserver-policy 則在「此查詢屬於某個網域模式／分類條件」時，直接把整筆查詢改送到你指定的另一組上游。它的價值在於「把少數關鍵後綴抽離全域預設」，讓你不必為了服務那幾個網域而整組替換預設解析器。當然，政策命中後那一段上游行為，仍要遵守同一份 dns 區塊裡的加密、並行、超時與策略細節；差別只在於「誰被叫到」。
也因此，寫 policy 之前請先決定你的「預設故事」：預設 nameserver 要不要放一個延遲較低、對在地網站友善的 DoH；fallback 要不要放更強調可信與防汙染的節點；以及哪些後綴一定要從這個故事裡豁免出去。這樣你在除錯時才能用一句話描述預期：例如「一般查詢走 A，命中 +.svc.onprem 改走內網轉發，命中 geosite:google 改走某一組國際 DoH」。
小結：rules 決定連線走哪個策略組；dns 決定解析先問誰。nameserver-policy 只負責後者裡的「分域改道」，別把它拿來當 proxy 規則的替身。
1先搭好可用的預設 DNS 骨架（再掛 policy）
在進入分域之前，請確認 dns.enable 已開啟，且客戶端在 TUN 或系統代理場景中，應用程式的查詢確實會進到核心；若此層不成立，後面政策寫得對也不會生效。接著放一份「多數網域都合理」的 nameserver 列表，並保留 fallback 作為保險絲：當你懷疑預設上游回傳被汙染、或出現離群延遲時，仍有第二條路可以接手。這份骨架與 防洩漏指南中的建議一致，本文不重複論證每一種 fallback 策略，只強調：政策表是建立在可靠預設之上的增補，而不是取代預設。
若你使用 FakeIP，也請在調整 policy 的同時留意哪些名稱必須拿到真實紀錄；否則規則看到的世界與應用程式以為的世界仍可能錯位。更多放行細節請交叉閱讀 fake-ip-filter 專文。此外，TUN 模式下若 dns-hijack 未覆蓋到某些本機軟體，可能出現「以為改了 policy、實際查詢仍繞過核心」的現象；可對照 TUN 模式教學把攔截範圍一次收斂。
2撰寫 nameserver-policy：從「最明确的后缀」開始
nameserver-policy 的本體是一張映射表：左側是「查詢名稱所匹配的模式」，右側是一組上游（可以與 nameserver 相同型別，例如 DoH、DoT、dhcp#system 等，實際可用型別以你的核心版本為準）。實務寫法會先列少數你確定要隔離的後綴，再視需求加入以 geosite: 或類似分類條件表達的集合。請避免一開始就複製超大表：那不是維護友善，而是把自己推向「升級一次就爆一次」的路。
下列片段示範常見拼裝方式：預設走一組公共 DoH，境內站點集合改走境內友善解析，特定國際服務後綴改走你指定出口的 DoH；註解一律使用英文以利版本控管。請把範例中的 URL 換成你信任且在你網路環境可觸達的端點。
dns:
enable: true
# enhanced-mode and fake-ip settings omitted here; keep them aligned with your profile
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- https://dns.google/dns-query
nameserver-policy:
# Route CN-focused sites to a resolver that matches your routing intent
"geosite:cn":
- https://doh.pub/dns-query
# Example: split a sensitive suffix to a dedicated DoH endpoint
'+.example-saas.com':
- https://dns.google/dns-query
# On-prem only resolvable names; often paired with fake-ip-filter
'+.corp.internal':
- 192.168.1.53
幾個落地習慣：政策鍵名的大小寫與引號要與官方範例一致；混合使用 IP 直連與 HTTPS URL 時，注意你的核心是否要求特定寫法（例如 https:// 後面接 IP 可能要處理憑證與 SNI）。當某條政策對應多個上游時，可視為小池化：實際並行與選路細節依版本而定，但「不要把互相否定假設的解析器擺在同一政策裡賭運氣」這件事是通用的。若你使用訂閱轉換器產生的設定，確認合併後 dns 區塊沒有被後載片段覆寫。
提醒：policy 只改「問誰」，不保證「連線走哪」。若規則把流量導向某節點，但 DNS 仍指向另一個地區的 CDN，體感會像「解鎖不稳定」；請讓解析出口與你在 rules 裡對該網域的故事一致。
3為什麼分域時優先考慮 DoH／DoT
在分域場景裡，明文 UDP/TCP DNS 仍可能在中途被觀察或插入；把關鍵後綴改送到 DoH 或 DoT，至少能把「應用程式到解析器」這一段納入 TLS 保護。當然，TLS 也不是魔法：你仍要信任終端解析器的運營方，也要確認本機根憑證與時間正確。若你在公司網路，還要評估中間設備對 ESNI／ECH、或對特定 DoH 主機的攔截是否會造成連線失敗；這類問題往往要與 IT 政策共存，而不是僅靠 YAML 就能消滅。
另一個實務點是延遲：多一跳 HTTPS 往往比傳統 53 端口慢一些，因此不建議「所有後綴通通掛重型政策」。把政策保留在**真的需要一致性或隱私邊界**的集合上，讓一般瀏覽與更新流量繼續享有較簡潔的路徑，長期比較穩。若你同時在前台執行大量短連線服務（某些 IDE 外掛、容器註冊表），也可以為其主機名做窄後綴，以免被全域 fallback 的保守策略拖慢。
4與 FakeIP、fake-ip-filter 的協同注意點
在 enhanced-mode: fake-ip 底下，應用程式看到的回應位址可能是虛擬位址池；核心會在稍後階段再與真實解析協作。當你為某網域指定政策上游時，仍需回答兩個問題：這個名稱是否應該拿到真實紀錄（若是，是否在 fake-ip-filter 中放行）；以及即便拿到真實紀錄，連線規則有沒有同步把該網域導到預期策略組。很多人只改了 policy，卻沒改規則前段的 DOMAIN／DOMAIN-SUFFIX 保障，於是「解析對了、連線仍歪」。
對內網與僅在特定 DNS 上可解析的後綴，政策常會指向內網轉發器，此時 fake-ip-filter 與 IP-CIDR 規則幾乎一定要成對出現；僅寫其中一層，問題會以「偶發」形式存在，升級路由器或換了搜尋網域後又復發。若你正在排查雙堆疊環境下的詭異超時，亦可交叉閱讀 IPv6 與 DNS 雙堆疊除錯，避免把純網路層症狀誤判成 policy 失效。
5驗證：用最小對照組證明「政策真的命中」
建議準備三組樣本：一個應命中境內政策、一個應命中國際固定 DoH、一個則應完全沒命中而回到預設 nameserver。變更設定後先重載，再開啟核心的 DNS 相關日誌（實際欄位名稱依版本與 GUI 而異），觀察同一筆查詢是否由預期上游回答。若看不見細節，可暫時把查詢導到你控制的本機轉發器做對照，但請記得測完撤回，以免製造新的單點故障。
在作業系統層，也可以用熟悉的查詢工具對「經核心轉發後」的效果做抽樣：關鍵不是工具本身，而是確認測試流量真的經過 Mihomo 的 DNS 入口。若你同時開著公司 VPN，還要釐清是哪一張路由表勝出，否則你會錯把「分分流」誤判成「政策無效」。完成一輪驗證後，把樣本與預期行為記在筆記裡，標上設定檔版本號；半年後升級核心時，這會省下大量重演成本。
常見問題（正文補充）
Q：政策表順序需要像 rules 一樣「從上到下」操心嗎？
與連線規則不同，DNS 政策表通常在內部會做更後綴化／專用化的匹配；仍建議把你最在意、最窄的條目維護在可讀的區塊，並透過日誌驗證而不是靠猜。若同一階層出現衝突感，幾乎都應回到「實際查詢名稱長什麼樣子」與「搜尋網域是否偷偷改寫」這兩點。
Q：可以混用 system／dhcp 與 DoH 嗎？
可以，且常見於「一般走加密 DNS，但內網仍需路由器公告的搜尋域」這類家庭場景。但要意識到 system 出口的隱含前提：核心得能像你期望的那樣觸達那台解析器，且不會在 TUN 全量接管時形成環路。遇到懷疑時，先把 policy 收窄到單一台內網 IP 做 A/B 測試。
Q：nameserver-policy 能取代 VPN 或規則裡的地區選擇嗎？
不能。它既不負責加密傳輸層，也不負責把 TCP 連線送到指定節點；最多讓「名字對到位址」這一步更一致。地區感知體感來自解析、路由、出口節點三者的組合，請分別驗收。
常見誤區
誤區一：把政策表當成「廣告阻擋」或Hosts替代方案。阻擋應在規則或專用清單層處理，DNS 政策搞太大會提高成本並模糊責任邊界。誤區二：為「錯開 lastmod 或看起來像有進展」而頻繁改上游，卻沒有日誌證明問題與解析出口相關。誤區三：從社群整包複製巨型 geosite: 映射，結果一半條目在你的網路根本不可達，造成隱性失敗。維持可驗證的小表永遠比較安全。
開源資訊與取得方式
Mihomo 持續演進，同步語法請以對應 Release 說明為準；若你要在圖形客戶端中管理，建議將「範本片段」與「個人私密後綴」分檔維護，降低誤提交風險。安裝與升級仍建議優先參考 本站下載頁 與 設定說明，把「拿二進位」與「寫 YAML」分成兩條工作流程，日後比較不會混線。
結語
nameserver-policy 的本質很單純：讓「這個名字」去「那組解析器」問。把境內／境外、企業內網與少數關鍵 SaaS 的 DNS 故事分開寫，你的 rules 會更好維護，也比較不會出現「連線策略與解析結果各說各話」的體感。與 防洩漏、fake-ip-filter 搭配使用時，請永遠用日誌與三組對照樣本驗證，而不是只靠頻繁重載猜運氣。
相較於手動在系統裡反覆切換 DNS 伺服器，以 Clash Meta 單一設定檔集中管理分域策略，長期更容易向家人或同事交代「為什麼這條一定要存在」。若你也在找能把 GUI 與 YAML 編輯樂趣結合的客戶端，可以免費下載 Clash，沿用本文片段逐步收斂；多數進階 DNS 選項在圖形介面裡都有對應入口，但仍建議保留可 diff 的文字範本以利除錯。