Clash DNS 設定完整解析：nameserver、fallback 分組與 fake-ip 劫持

先說結論：分開檢查 DNS 上游、回傳位址與流量接管

Clash DNS 設定最容易混淆的其實是三件事：向哪個伺服器查詢網域名稱、回傳什麼位址給應用程式，以及應用程式的 DNS 查詢有沒有進入核心。nameserver 和 fallback 負責第一件事；enhanced-mode 負責第二件事；系統 DNS、監聽連接埠和 TUN 的 dns-hijack 則決定第三件事。只切換成 fake-ip，不會自動接管整台裝置的 DNS。

以下主要設定以 mihomo 為目標。Clash 是用戶端生態系中常見的稱呼，圖形介面相似，不代表底層欄位完全相同。原版 Clash、不同歷史分支與目前的 mihomo，對 TUN 和 DNS 擴充欄位的支援各有差異。請先從用戶端顯示的核心資訊或啟動記錄確認實際實作；命令列部署可執行 mihomo -v 查看目前環境，別只憑介面版本推測核心功能。

• 成功匯入訂閱：只代表設定檔可以讀取，不表示系統已使用該 DNS。
• 節點延遲測試成功：只測試了指定目標，不代表所有網域都能正確解析。
• 回傳 198.18 網段位址：在 fake-ip 模式下可能是預期結果，不應直接判定為 DNS 污染。

nameserver 與 default-nameserver：一般解析與引導解析

dns.nameserver 是一般網域解析使用的上游清單。上游可以是一般 DNS 的 IP 位址，也可以是核心支援的 DoH、DoT 位址。這份清單並非「永遠優先使用第一台，只有斷線時才啟用第二台」的固定佇列；核心會依自身的查詢與回應選擇邏輯處理多個上游，不宜仰賴排列順序來實現嚴格的主備切換。

設定了 DoH，為什麼還會用到一般 DNS？

例如 https://dns.alidns.com/dns-query 是 DoH 服務位址，但建立 HTTPS 連線前，必須先取得 dns.alidns.com 的 IP。default-nameserver 負責解析這類 DNS 服務網域名稱，作為引導解析。以下使用 223.5.5.5 和 119.29.29.29，目的是清楚呈現依賴關係，不代表這兩個位址適用於所有網路。

DoH 加密只涵蓋用戶端到該解析服務的這一段，不代表查詢自動經過代理節點。上游是否可連線、DNS 連線使用哪條出站路徑，以及一般連線如何匹配規則，都需要分別確認。mihomo 也提供 proxy-server-nameserver 等擴充欄位，可另外處理代理伺服器的網域解析；不清楚依賴關係時，別讓解析節點網域名稱的查詢又依賴該節點本身。

fallback 與 fallback-filter：篩選候選結果，不是規則策略群組

fallback 雖然常被稱為「備用 DNS」，但不只是等到 nameserver 完全逾時才啟用的備援清單。設定 fallback 後，核心可以同時向一般組和 fallback 組送出查詢，再依篩選條件選擇結果。這裡的「分組」是 DNS 上游集合，和 proxy-groups 裡選擇節點、執行自動測速的策略群組不是同一層。

geoip、ipcidr、domain 分別判斷什麼？

• geoip: true 搭配 geoip-code: CN：判斷一般組回傳位址的地區；結果不符合指定地區時，會觸發改用 fallback 結果的機制。此功能需要核心具備可用的地理資料。
• ipcidr：將某些回傳位址範圍視為需要篩除的結果，例如 240.0.0.0/4。它檢查的是解析結果，不會替一般連線新增代理規則。
• domain：讓符合條件的網域使用 fallback 結果。這是網域層級的指定條件，不必等一般組回傳異常 IP 才生效。

這些條件並非必須全部符合才會依序觸發。別把「網域在清單中、位址不屬於 CN，而且同時落在保留網段」誤認為唯一的觸發方式。還有一項容易忽略的限制：如果錯誤回傳的位址剛好也被地理資料判定為 CN，單靠 geoip 未必能辨識異常。fallback 是結果選擇機制，不是解析正確性的保證。

需要明確指定某類網域使用哪台 DNS 時，mihomo 的 nameserver-policy 通常更直觀。它決定解析上游，rules 則決定一般連線的出站方式，兩者不能互相取代。即使某個網域是透過海外 DNS 解析，一般連線也不會因此自動套用代理策略。

fake-ip 與 redir-host：回傳虛擬位址還是實際位址

fake-ip：透過對應表保留網域資訊

enhanced-mode: fake-ip 會對符合條件的查詢回傳虛擬位址，並在核心中保留網域與虛擬位址的對應關係。應用程式接著連線到這個位址時，連線必須進入同一個核心，核心才能依據對應關係還原目標。範例使用 198.18.0.1/16，這是供效能基準測試使用的保留位址範圍，不是遠端網站的實際伺服器位址。

這種方式有助於在連線階段保留網域資訊，也能避免部分連線在建立前等待解析實際目標位址。但這不代表「所有網域都不再需要真實 DNS」：直連目標、IP 類規則判斷，以及各核心的具體處理流程，仍可能觸發實際解析。若把 fake-ip 當成完全不需要上游 DNS，可能導致難以排查的連線失敗。

redir-host：回傳實際位址，須留意網域關聯

redir-host 會回傳上游提供的實際 IP，核心再利用 DNS 快取等資訊關聯網域。這種模式較容易相容於需要取得實際位址的程式，但無法排除 DNS 結果異常，也不能保證每條連線都能完整保留網域資訊。應用程式自行解析、快取逾期或連線繞過核心，都可能影響規則匹配結果。

• 日常使用桌面 TUN：可以先測試 fake-ip，讓 DNS 和後續連線都由同一個核心處理。
• 區域網路裝置、印表機或內部服務異常：先檢查區域網路 DNS 和篩選清單，再考慮切換模式。
• 特定程式需要實際 IP：可將對應網域加入 fake-ip-filter，不必立刻將所有應用程式改用 redir-host。

fake-ip-filter 的意思是「這些網域不回傳 fake-ip」，而不是「這些網域不經過代理」。以下範例排除 localhost、*.lan 和 *.local。不過，排除網域並不會讓公共 DNS 自動解析路由器的私有網域；內部網域仍需要可用的區域網路解析器。.local 常與 mDNS 有關，也不能只靠更換一般 DNS 上游解決。

可直接套用的 DNS 設定片段：先在 127.0.0.1:1053 測試

以下只取代完整設定中的 dns: 區段，不包含節點、策略群組或一般規則。請保留現有訂閱的其他內容；如果設定中已有 dns:，請合併或取代，避免出現重複的頂層索引鍵。圖形用戶端可能在啟動時覆寫訂閱欄位，請透過用戶端提供的持久化覆寫功能儲存變更，並確認最終生效的設定。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/8

這裡使用回環位址監聽，是為了先將測試範圍限制在本機；不會直接監聽 0.0.0.0:53，也不會向區域網路開放 DNS 解析服務。ipv6: false 是為了縮小這次 DNS 驗證的範圍，不代表關閉作業系統的 IPv6，也不能據此認定所有 IPv6 連線都會遭到阻擋。

先檢查語法，再確認監聽狀態

命令列環境可在設定檔所在目錄執行以下檢查。如果圖形用戶端自行管理設定檔路徑，別直接用命令取代它的啟動參數；請使用用戶端提供的設定檢查功能，並確認記錄中顯示 DNS 服務已成功啟動。

mihomo -t -f config.yaml

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

example.com 是用來驗證查詢流程的公開範例網域。支援 fake-ip 時，查詢回傳 198.18.x.x 可能是正常現象；如果 UDP 和 TCP 都逾時，請先檢查監聽狀態、連接埠衝突與核心記錄。Windows 若尚未安裝 dig，可在互動式 nslookup 中指定伺服器和連接埠：

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

TUN DNS 劫持的生效條件：53 連接埠的請求必須經過核心

作業系統的一般 DNS 通常使用 UDP 或 TCP 的 53 連接埠。前文的 1053 是測試用監聽連接埠，系統不會自動將 53 的請求轉送到這個連接埠。多數系統的 DNS 設定介面也無法填入自訂連接埠。若要接管一般 DNS，可使用用戶端的 TUN DNS 接管功能，或設定明確的本機轉送；別只把系統 DNS 設為 127.0.0.1，就以為它會連到 1053。

在支援以下欄位的 mihomo 環境中，可將這段合併到現有的 tun: 設定中。啟用前，請依用戶端或作業系統的要求授予建立虛擬網卡及修改路由的權限。如果用戶端已管理 TUN，請優先使用其設定入口，以免介面設定和手動設定互相覆寫。

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

any:53 用來匹配 UDP DNS，tcp://any:53 則涵蓋 TCP DNS。這裡的劫持是將進入 TUN 處理路徑的 DNS 請求交給核心 DNS 模組，並非單純把所有請求改寫到本機 1053 連接埠。請求能否進入這條路徑，還取決於系統路由、其他 VPN、介面選擇和平台限制。

只設定 dns-hijack 不會接管以下所有流量

• 瀏覽器內建的 DoH：通常會以 HTTPS 流量傳輸，無法直接透過 53 連接埠規則辨識為一般 DNS。
• 系統或應用程式使用的 DoT：通常使用 853 連接埠，不在這兩條 53 連接埠規則的匹配範圍內。
• 未進入 TUN 的流量：例如由其他 VPN 接管、採用獨立路由，或受平台實作限制的請求。
• 已快取的結果：應用程式可能不會發出新查詢，而是繼續使用舊位址或既有連線。

系統代理和 TUN 也不能混為一談。瀏覽器透過 HTTP 代理提交網域名稱時，可能由代理端處理目標解析；不遵循系統代理設定的應用程式則可能直接使用系統 DNS。排查時可暫時關閉瀏覽器內建的安全 DNS，建立可控的基準環境，確認後再恢復所需設定。

故障排查對照：依症狀定位，一次只調整一個變數

切換模式時也要一併清除快取

從 fake-ip 切換到 redir-host，或關閉 TUN 後，應用程式仍可能快取虛擬位址。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。這兩個命令各有適用條件，並非跨平台通用命令。瀏覽器自己的 DNS 快取和連線池也需要另外處理；必要時請完全關閉應用程式後重新開啟。

驗證時請選一個固定網域，先送出查詢，再開啟對應網頁，同時查看連線面板中的目標網域、匹配規則和出站策略。別只靠公共 IP 查詢頁判斷 DNS：出口位址只能說明該次網頁連線的出口，無法完整呈現 DNS 查詢使用了哪台伺服器。

如需重看訂閱匯入與基本連線步驟，請參閱入門指南的訂閱說明；如需了解 DNS 與規則之間的關係，請查看使用手冊的 DNS 章節。核心原則不變：先確認請求是否進入核心，再檢查上游和篩選條件，最後調整相容性清單。