Clash DNS 設定教學：nameserver、fallback 與 DNS 劫持

先釐清 DNS 解析、規則分流與流量接管

Clash 的 DNS 設定負責將網域名稱解析為 IP 位址，或在 Fake-IP 模式下建立網域名稱與虛擬位址的對應關係。規則決定連線使用哪個策略；系統代理與 TUN 則決定哪些連線會進入核心。這三個層面彼此相關，卻不能互相取代：填入公共 DNS 位址，不代表瀏覽器請求已經透過代理；啟用 TUN，也不代表所有加密 DNS 都會被接管。

本文主要說明由 Clash Meta 後續發展而來的 mihomo 核心。傳統 Clash 與不同用戶端支援的欄位並不完全相同，尤其是 tun、proxy-server-nameserver 等設定。排查前，請先在用戶端的「關於」或核心資訊頁面確認實際的核心名稱與版本，不要只看用戶端名稱。

• DNS 請求入口：應用程式、系統解析器，或由 TUN 接管的 53 埠流量。
• DNS 上游：nameserver、fallback 等清單中設定的 DNS 解析服務。
• 連線出口：由 rules 與代理策略決定，不會直接由 DNS 伺服器所在區域決定。

dns 設定區塊：從可驗證的最小範例開始

除錯時建議先使用 redir-host 查看實際位址，確認上游可連線後，再依需求切換至 Fake-IP。以下範例在本機 127.0.0.1:1053 提供 DNS 服務；1053 是範例監聽埠，並非要求所有用戶端都改用的預設值。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

listen: 127.0.0.1:1053 僅接受本機連線，適合桌面環境除錯。改成 0.0.0.0:1053 會擴大監聽範圍；若確實需要讓區域網路裝置使用，還必須限制防火牆允許的來源，避免解析服務暴露在不受信任的網路中。

default-nameserver 不是一般查詢的「第三組備用伺服器」。當上游設定為 https://dns.alidns.com/dns-query 時，核心必須先取得該主機名稱對應的 IP。範例使用數字位址進行引導，避免解析器必須依賴自身才能啟動。一般 UDP 引導查詢不具備 DoH 的傳輸加密特性，請依所在網路的隱私與連線需求選擇。

nameserver 與 fallback：候選解析結果，不是單純的主備關係

nameserver 提供一般解析結果

nameserver 是一般上游清單。若未另外設定網域策略，一般查詢會由這組伺服器處理。設定多個位址不代表會嚴格依照第一項、第二項的順序逐一嘗試；核心可能同時向多個上游查詢，再採用可用結果，因此不要依賴清單順序來實現網域分流。

fallback 提供另一組候選結果

啟用 fallback 後，不要將它理解為「只有 nameserver 逾時才會查詢」。在常見的 nameserver/fallback 機制中，兩組解析可能會同時進行，最後再依據 fallback-filter 決定採用哪組結果。這樣可以縮短需要改用另一組結果時的等待時間，但也代表另一組服務可能會收到查詢。

是否透過代理連線是另一回事。將 https://1.1.1.1/dns-query 設為 fallback，不會自動讓這條 DoH 連線經過代理節點；實際的連線出口會受到核心版本、DNS 上游指定方式及相關路由設定影響。如果目前網路無法連線至該服務，應先排除連線問題，而不是反覆更換過濾條件。

• 只想確認基本解析：先保留一組可連線的 nameserver，暫時移除 fallback 及其過濾器。
• 確實需要從兩組結果中擇一：再加入 fallback，並明確設定過濾條件。
• 特定網域必須交由指定解析器處理：使用 nameserver-policy，不要靠清單順序猜測。

fallback-filter：geoip、ipcidr 與 domain 的判斷方式

fallback-filter 用來判斷何時採用 fallback 結果。它不是防火牆規則，也不是指定一般流量代理方式的規則。設定 geoip-code: CN，不代表中國大陸網站一定會直連，更不代表其他地區的網站一定會走代理。

geoip：檢查 nameserver 回傳位址的歸屬

當設定 geoip: true、geoip-code: CN 時，通常會保留歸屬於 CN 的 nameserver 結果；不符合此歸屬條件時，則傾向採用 fallback 結果。判斷依據是核心使用的 GeoIP 資料，而不是 DNS 服務商所在的地理位置。資料缺漏、過舊或 CDN 位址歸屬變動，都可能影響判斷結果。

ipcidr：針對特定位址範圍切換結果來源

範例中的 240.0.0.0/4 會將命中此範圍的 nameserver 結果交由 fallback 處理。這只是可疑位址範圍的範例，無法涵蓋所有錯誤解析。請勿直接將 192.168.0.0/16 等私有網路範圍全部加入過濾器：企業內網、路由器管理介面與本地域名，原本就可能需要回傳私有位址。

domain：指定網域使用 fallback

網域過濾條件與 IP 條件不同，可以直接指定在網域層級採用 fallback。以下使用獨立範例，停用 GeoIP 判斷，只對保留用作範例的網域 example.com 及其子網域套用此選擇邏輯；實際部署時，請填入確實需要此設定的網域。

dns:
  fallback-filter:
    geoip: false
    domain:
      - '+.example.com'

domain、ipcidr 與已啟用的 GeoIP 判斷，各自都可能觸發 fallback，並非必須同時符合三項條件。如果希望「只有這些網域使用另一組上游」，就應明確停用不需要的 GeoIP 條件，並確認完整設定中沒有保留其他過濾項目。

nameserver-policy 與節點網域：避免解析鏈路形成循環

區域網路網域通常不適合送往公共解析服務。在 mihomo 中，可以使用 nameserver-policy 為特定網域指定上游。以下的 192.168.1.1 僅適用於該位址確實是本地 DNS 服務的網路；若閘道是 192.168.50.1，就不能直接照用。

dns:
  nameserver-policy:
    '+.home.arpa':
      - 192.168.1.1
  proxy-server-nameserver:
    - 223.5.5.5
    - 119.29.29.29

home.arpa 是家庭網路使用的特殊網域空間。單獨指定策略即可將它交由本地解析器處理，不必依賴公共 fallback 猜測區域網路記錄。命中 policy 後會採用相應的專用解析路徑，因此不要再假設該網域仍完全遵循一般 nameserver/fallback 的選擇流程。

proxy-server-nameserver 用來解析代理節點伺服器本身的網域名稱。這與「透過哪個節點查詢目標網站」是兩個不同的問題：如果 DoH 必須依賴代理才能連線，而代理節點的網域又只能依賴這個 DoH 解析，就會形成啟動依賴循環。為節點網域準備可連線的獨立解析路徑，有助於降低這類循環風險；實際支援情況請以使用中的 mihomo 版本為準。

不要為了修正一個解析循環，就同時加入多組路由選項。請先確認節點網域能解析、節點連線可建立，再決定一般 DNS 是否要遵循業務規則。修改後應查看用戶端最終產生的執行設定，確認訂閱覆寫沒有刪除新欄位。

TUN 模式下 dns-hijack 的正確層級與協定寫法

dns-hijack 屬於頂層的 tun 設定區塊，不屬於 dns。它會將符合條件且已進入 TUN 的 DNS 流量轉交給核心 DNS 模組。以下是 mihomo 常見的寫法；啟用前，請確認用戶端具備建立虛擬網卡及修改路由所需的權限。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - 'any:53'
    - 'tcp://any:53'

• any:53：符合進入 TUN 的 UDP 53 埠 DNS 請求。
• tcp://any:53：另外涵蓋 TCP 53 埠，適用於 TCP 查詢及部分截斷回應後的重試。
• auto-route：自動設定相關路由；無法保證所有平台上的區域網路流量都會進入 TUN。
• auto-detect-interface：嘗試識別出口介面；在多張網卡、使用其他 VPN 或路由環境複雜時，仍須確認實際出口。

dns-hijack 不會將系統 DNS 位址改成 127.0.0.1:1053，也不需要將劫持目標改寫為 1053。前者會比對原本送往 53 埠的請求；dns.listen 則是獨立的 DNS 服務監聽入口。兩者用途不同，但可以搭配使用。

為什麼啟用劫持後，仍會看到其他 DNS 連線？

DoH 通常使用 HTTPS 443 埠，DoT 常用 TCP 853 埠，DoQ 則常用 UDP 853 埠。這些都不是一般的 53 埠 DNS，無法透過上述兩項設定直接攔截並解密。若瀏覽器啟用了「安全 DNS」、Android 啟用了「私人 DNS」，或應用程式內建了解析器，查詢仍可能以加密的網路連線傳送。

此外，送往同一網段路由器的流量可能直接經由實體介面傳送，並未進入 TUN。請依據平台路由與系統 DNS 位址確認接管路徑，不要只看開關是否已啟用。若為了排查而暫時關閉應用程式的加密 DNS，請先記下原本設定，驗證後再依需求還原。

使用指令驗證：先測試監聽，再測上游，最後檢查接管

以下指令用來重現測試步驟，不代表任何特定網路環境的實測結果。請先保留範例中的 redir-host，避免 Fake-IP 虛擬位址干擾對實際解析結果的判斷。每次只調整一組欄位，再重新載入設定。

第一步：直接查詢核心 DNS 監聽埠

在具備 dig 的 macOS 或 Linux 終端機中，分別測試 UDP 與 TCP。Windows 可在安裝相關工具的環境中執行相同指令；也可以使用系統內建的 nslookup，進入互動模式後設定埠號。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

若收到 NOERROR，且 ANSWER 中有 A 記錄，表示該次查詢已完成位址解析；SERVFAIL 代表解析鏈路處理失敗，若逾時則還需檢查監聽、上游與防火牆。只有 NOERROR 卻沒有 A 記錄，不能直接判定失敗，因為該網域可能沒有相應記錄。

第二步：分開排查上游與過濾器問題

1. 暫時移除 fallback，只保留一組 nameserver，重新查詢相同網域。
2. 暫時將待測的 fallback 服務設為唯一的 nameserver，確認它本身可以完成解析。
3. 恢復兩組上游，再逐項啟用 GeoIP、IP 範圍或網域條件，觀察結果變化。
4. 根據記錄中的上游連線錯誤、逾時與設定載入錯誤定位問題，不要把所有異常都歸因於 DNS 污染。

第三步：驗證 TUN，而非再次測試監聽埠

直接查詢 127.0.0.1:1053 只能證明監聽入口可用，不能證明 TUN 劫持成功。要測試接管，需讓系統或應用程式向一般 DNS 位址的 53 埠送出請求，同時查看核心記錄與連線資訊；若能封包擷取，還要確認實體網路出口是否仍送出原始查詢。測試時請排除瀏覽器 DoH，並留意本機快取可能導致查詢根本沒有發生。

Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取；macOS 可使用 sudo dscacheutil -flushcache 與 sudo killall -HUP mDNSResponder。Linux 的快取服務會因發行版而異；若使用 systemd-resolved，可執行 resolvectl flush-caches。這些指令不會清除所有瀏覽器快取，也不能取代用戶端內部的 DNS 快取清除功能。

常見狀況與設定檢查

完成設定時，只保留用途明確的欄位即可：nameserver 負責一般解析；fallback 搭配過濾器選擇另一組結果；nameserver-policy 處理特定網域；dns-hijack 接管已進入 TUN 的傳統 DNS 請求。最後請檢查訂閱更新後的執行設定，並還原除錯期間暫時變更的瀏覽器、系統 DNS 與記錄層級設定。能逐層驗證的精簡設定，比不斷疊加公共 DNS 位址更容易維護。