為什麼要以 dns: 模組當主線

連線問題的最後一哩，常常卡在名字先錯了：規則還沒出手，解析就已經指向錯誤的 IP、或被污染成黑洞位址。只看日誌裡的 lookup、NXDOMAIN 能幫你確認症狀，卻不一定告訴你該改哪一段 YAML。Clash Meta DNS（Mihomo 同脈設定）把「誰來解析、何時換備援、Fake-IP 下誰必須拿到真實位址」寫在同一個 dns: 區塊；把它配清楚，後面的 rules: 與策略組才不會建立在沙上。

你可以把設定想成兩層：解析層決定應用程式拿到的 IP；路由層決定這條連線走哪個出站。若解析層在 Fake-IP 模式下對「該真實解析」的域名仍回虛擬位址，路由層再聰明也會出現「看似命中規則、實際連錯對象」的體感。本文先給一組可複製骨架，再談欄位取捨；細部欄位名稱請務必對照你所用的核心版本說明，因為發行版之間會有小幅差異。

enhanced-mode、Fake-IP 與規則的關係

enhanced-mode 常見取值包含 fake-ip 與 redir-host（或等價命名）。Fake-IP 的核心好處，是讓核心先拿到域名再做規則匹配，避免「先解析成單一 IP、規則只能看 IP」時的資訊損失；代價則是你必須明白：應用程式 socket 看到的位址，未必是目標站的真實 IP。因此 fake-ip-filter 這類名單不是可有可無，而是把「必須真實解析」的業務與內網場景從 Fake-IP 流程裡摘出來。

redir-host 路線則較偏向讓解析結果與傳統認知一致，對某些依賴真實 IP 的軟體較直觀，但在複雜規則與 CDN 場景下，你要更注意規則與 SNI／Host是否對齊。實務上多數教學範本採 Fake-IP，是因為與域名規則協同較順；一旦你遇到路由器管理頁、區網主機名、mDNS、或必須直連的 STUN／VoIP 類主機名，就要回頭檢查 filter 與 DIRECT 規則是否一致。更完整的區網與路由器情境可延伸閱讀 Fake-IP 與區網／路由器 專文。

nameserver：預設要問誰

nameserver 是主要解析入口：沒有被判定要升級到 fallback 之前，核心會優先用這裡的伺服器取得答案。實務上常見寫法是先放延遲低、可達性高的本機或電信商 DNS，再放加密協議（DoT／DoH）作為日常預設之一，視你的網路對明文 UDP 53 的態度而定。

下面是一段結構示意（協議前綴與欄位請以你的版本文件為準；註解使用英文）。

dns: nameserver skeleton (illustrative) 
dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - tls://dns.google
  # proxy-server-nameserver:
  #   - https://dns.alidns.com/dns-query

當你的代理節點本身是域名（例如 example.com:443）時，要小心「雞生蛋」：連代理所需的解析若仍走可能污染的通道，會讓整條鏈在啟動階段就卡住。部分版本提供 proxy-server-nameserver（或等價欄位）把「為了連上代理而做的解析」單獨指定到可信 DNS；這與一般上網流量的 nameserver 可以分開思考。若你不確定語意，請先查你所用核心的 Changelog 與範例，再寫進正式檔。

dns.fallback 鏈與 fallback-filter

dns 底下的 fallback 是解析備援列表，不是 proxy-groups 裡的 type: fallback。它的用途是：當主要 nameserver 回傳的答案看起來不可信或不符合條件時，改向備援重新問一次。典型觸發條件包含「答案落在私有／保留位址」「命中特定 GeoIP」「被判定為污染模式」等，實際行為由 fallback-filter 與核心實作共同決定。

ℹ 名詞釐清：本文若寫「DNS fallback」，指 dns.fallback 伺服器鏈；若討論代理主備，會明確寫「策略組 type: fallback」。兩者都用到 fallback 一詞，但層級完全不同。
dns: fallback + fallback-filter (illustrative) 
  fallback:
    - tls://1.1.1.1
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/32

設計重點在於讓「日常解析」保持簡單，同時保留一條可信的二次確認路徑。若你把過於激進的條件塞進 filter，可能導致幾乎每次都落進 fallback，延遲上升還算小事，更麻煩的是與本地直連策略打架：某些在本該 DIRECT 的域名上，被錯誤地引向不符合預期的答案。調整時請一次只改一個維度，並用連線日誌觀察解析階段與規則命中是否同步變化。

fake-ip-filter：誰不要走虛擬 IP

fake-ip-filter 是一份域名模式清單：命中者通常會改以真實解析流程處理（語意依版本略有出入，但使用者目標一致：不要對這些名字回 Fake-IP 池內的位址）。實務上優先會放：

fake-ip-filter examples (illustrative) 
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*"
    - geosite:private

清單不是越長越好；過度膨脹會讓 Fake-IP 的優勢被沖淡。比較穩的維護方式是：遇到哪個域名在 Fake-IP 下行為異常，再用日誌確認後補一條，並在旁邊用英文註解記錄原因（方便六個月後的你自己）。若你使用規則集／geosite 類條目，請確認對應資料檔已載入且版本與核心相容；規則集更新節奏可參考 規則分流最佳實踐。

與 TUN、系統 DNS 的協同與縫隙

開啟 TUN 後，作業系統層的預設閘道與 DNS 往往會被改寫，讓應用程式以為自己在用「系統 DNS」，實際上卻由 Clash 在虛擬介面側攔截並轉交核心處理。理想情況下，這能顯著減少「應用繞過系統代理」造成的縫隙；但若你同時開著瀏覽器 DoH、公司 VPN、或其他會註冊路由的軟體，就可能出現多個解析權威互相覆蓋，表面症狀仍是「偶發連不上」，根因卻在 DNS 優先順序。

實務上建議你把變因收斂成可敘述的一句話：「這台機器上，最終由誰回答 DNS？」若答案是 Clash，就讓系統 DNS 指向 Clash 監聽位址，並避免再疊一層強制 DoH；若答案不是 Clash，就不要期待 dns: 區塊能拯救所有應用。TUN 與堆疊路由的細節可再讀 TUN 模式深度解析，把「誰劫持、誰回填、誰優先」畫成你自己的小圖，之後除錯會快很多。

DNS 洩漏：該檢查什麼、別誤判什麼

廣義的 DNS 洩漏，指的是客戶端最終把查詢送到了你未預期的解析路徑，使隱私或合規預期破功。Clash 場景下，常見誤判是把 Fake-IP 池或 供應商內建的健康檢查域名當成「洩漏證據」。判讀時請分三步：先確認查詢是不是你主動業務產生；再確認應答是否仍由本機 Clash 處理；最後才談出口是否與威脅模型一致。

若你需要對外驗證，請在固定測試方法下對比「關閉／開啟 TUN」「關閉瀏覽器 DoH」兩種組態，並避免在測試同時進行大量背景更新。站內 常見問題 亦整理多組與 DNS、代理路徑相關的問答，可作為檢查清單的延伸。

常見坑與建議除錯順序

  1. bootstrap 循環：代理域名解析失敗導致無法建立隧道，隧道未建立又無法用「經代理的 DNS」——請把代理相關解析放到可信的獨立通道或調整順序。
  2. DoH 與 Clash DNS 疊床架屋：瀏覽器、系統、核心各有一套，症狀是間歇性「只有某個瀏覽器正常」。
  3. fallback-filter 過敏：幾乎每次都進 fallback，延遲升高且與本地路由策略衝突。
  4. fake-ip-filter 漏補：路由器後台、區網主機、或特定登入域名異常，卻去改規則而不改解析。
  5. 以為是 DNS、其實是 TLS 或路由：可搭配 連線日誌與逾時 一文，先判斷錯誤發生在 lookup 之後還是之前。
⚠ 合規提示：請在合法授權的網路環境下使用 Clash，並遵守在地法規與服務條款。本文僅說明技術設定，不鼓勵規避合規管控。

自檢清單

  1. dns.enable 是否為 true，且 listen 未與系統或其他服務衝突。
  2. enhanced-mode 是否與你預期的規則型態一致（域名規則為主或 IP 規則為主）。
  3. nameserver 與 fallback 是否分工清楚：日常 vs 可信二次確認。
  4. fallback-filter 條件是否過寬或過窄；修改後用日誌觀察 5～10 分鐘。
  5. fake-ip-filter 是否覆蓋區網、路由器與已知需要真實解析的域名。
  6. TUN 開啟時，系統 DNS 與瀏覽器 DoH 是否收斂到同一敘事；必要時暫時關閉一層對照。
  7. 代理本身是域名時，是否為其準備了獨立、可信的解析路徑。

結語

把 Clash Meta DNS 寫清楚，本質是在回答三個問題：平常問誰（nameserver）、什麼情況改問誰（fallback 與 fallback-filter）、以及 Fake-IP 模式下誰必須拿到真實答案（fake-ip-filter）。這三件事對齊後，TUN 與規則才有穩固地基；你也比較不容易把「解析問題」誤修成「節點問題」，或把「Fake-IP 正常行為」誤判成 DNS 洩漏。

相較於只在故障時翻日誌，一份註解完整、結構分層的 dns: 區塊能把排查時間壓在幾個固定檢查點上；搭配能顯示連線與解析關聯的客戶端，你會更快從「感覺哪裡怪怪的」走到「知道下一行要改什麼」。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用結構清楚的 DNS 與規則設定，把解析、路由與出口敘事收斂到同一套可維護的檔案裡。