Clash DNS 設定詳解：nameserver、fallback 與 DNS 劫持設定方式

先釐清 Clash DNS 的處理流程

Clash DNS 設定不只是把系統 DNS 換成另一個位址。啟用內建 DNS 後，客戶端會接收網域查詢，再根據 nameserver、fallback、規則與增強模式決定解析方式。建立連線時，Clash 還必須將網域、解析結果與代理規則互相對應，因此 DNS 設定會直接影響規則命中、首次開啟速度，以及部分 App 的可用性。

一次常見的查詢可分成四個步驟：App 對 example.com 發出查詢；系統或 TUN 將 53 埠請求交給 Clash；Clash 使用設定中的上游伺服器進行解析；連線請求再依照網域規則、IP 規則或最終規則選擇直連或代理。任何一步繞過 Clash，都可能造成網域規則未命中、解析結果被快取，或網頁能開啟但 App 連線失敗。

enable、listen 與基本欄位怎麼設定

enable：啟用內建 DNS

enable: true 代表啟用 Clash 的 DNS 模組。設為 false 後，其餘 dns 欄位便不會依預期參與解析。設定成功載入，不代表查詢已經進入該模組，還需要搭配系統代理、TUN 或客戶端的網路擴充功能判斷。

listen：提供本機 DNS 監聽連接埠

listen: 127.0.0.1:1053 代表僅在本機迴路位址的 UDP/TCP 1053 連接埠提供 DNS 服務。1053 是常見的非特權測試連接埠，也能避免與系統使用中的 53 連接埠衝突。若寫成 0.0.0.0:1053，同一個區域網路中的裝置可能存取該連接埠，因此行動裝置的日常設定通常優先使用迴路位址，或交由客戶端自動管理監聽。

listen 只是「在哪裡等待查詢」，不是「把查詢攔截過來」。在啟用 TUN 的桌面環境中，通常還需要設定 tun.dns-hijack；在 iOS 中，DNS 接管往往由客戶端的 Network Extension 完成，部分客戶端會忽略 YAML 中的 tun 區段，改用 App 本身的開關。

可作為起點的設定範例

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  fallback:
    - https://8.8.8.8/dns-query
    - tls://1.0.0.1:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

這份範例適合支援 Clash Meta 或 mihomo 語法的客戶端作為基礎範本。不同客戶端可能會對 DoH、DoT、IPv6 或 TUN 欄位進行額外處理，匯入後應先查看設定驗證結果。若使用較舊的設定核心，也要確認它是否能辨識 geoip-code、DoT 位址與增強模式欄位。

nameserver、default-nameserver 與 fallback 的差異

default-nameserver：為加密 DNS 位址進行啟動解析

當 nameserver 使用 https://dns.alidns.com/dns-query 這類包含網域名稱的 DoH 位址時，Clash 首先必須知道 dns.alidns.com 對應哪個 IP。default-nameserver 主要負責這類啟動解析，也稱為 bootstrap DNS。這裡優先填入可直接連線的 IP 位址，避免出現「需要先解析 DoH 網域，但解析本身又依賴 DoH」的循環。

如果所有上游都以網域名稱填寫，且 default-nameserver 本身無法連線，記錄中常見的現象包括 DNS 請求逾時、設定剛啟動時無法連網，或反覆出現上游網域解析失敗。排查時可先保留一個目前網路能存取的純 IP DNS，再驗證 DoH 位址。

nameserver：日常查詢的主要來源

nameserver 是一般查詢的主要上游。可以填入傳統 UDP DNS、TCP DNS、DoT 或 DoH。UDP 位址例如 223.5.5.5，DoT 可寫成 tls://1.1.1.1:853，DoH 可寫成 https://1.1.1.1/dns-query。混用協定有助於排查網路限制，但上游數量不是越多越好；兩個穩定且路徑明確的伺服器，通常比堆疊六、七個位址更容易定位問題。

fallback：依過濾條件選擇備用結果

fallback 很容易被理解為「nameserver 逾時後才使用的備用 DNS」，但實際行為通常更接近並行取得候選結果，再由 fallback-filter 判斷採用哪一組結果。不同核心版本在並行、快取與結果選擇上有細節差異，但不能把它視為傳統的主備切換。

例如啟用 geoip: true 並設定 geoip-code: CN 後，如果主要解析結果不符合過濾條件，核心便可能採用 fallback 回傳的結果。domain 中明確列出的網域也可以優先使用 fallback 結果。規則庫版本、GeoIP 資料與上游回傳的 CDN 位址都會影響判斷，因此不建議只因「IP 看起來不在本地」就認定設定錯誤。

fallback-filter 各項條件如何生效

geoip 與 geoip-code

geoip: true 會啟用基於 IP 地理資料的篩選，geoip-code: CN 指定用於判斷的地區代碼。它依賴客戶端隨附或下載的 GeoIP 資料，並非即時查詢服務。資料檔案遺失、過舊或路徑設定錯誤時，篩選結果可能與預期不同。

ipcidr

ipcidr 使用 CIDR 網段標記需要採用 fallback 候選結果的位址。常見範例 240.0.0.0/4 涵蓋保留位址範圍，可用來排除明顯異常的解析結果。不要任意加入大範圍的公網網段，否則正常網站也可能持續使用 fallback。

domain

domain 用於指定網域。mihomo 常見的 +.example.com 寫法可匹配該網域及其子網域。若只想為少數網站指定獨立上游，較新的 mihomo 設定也可以考慮 nameserver-policy，將特定網域直接對應到指定 DNS；其邏輯通常比大範圍的 fallback 篩選更清楚。

dns:
  nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "+.example.net":
      - https://1.1.1.1/dns-query
    "geosite:cn":
      - https://dns.alidns.com/dns-query

nameserver-policy 是否支援規則集寫法，取決於使用的核心與客戶端打包版本。使用 mihomo v1.19 系列設定時，應以客戶端顯示的核心版本與設定驗證結果為準。若客戶端仍使用較早期的 Clash 核心，可以改用一般網域清單，避免直接複製不受支援的規則集語法。

fake-ip 與 redir-host 怎麼選

fake-ip：先回傳保留位址，再對應真實網域

enhanced-mode: fake-ip 會從指定位址池回傳一個對應位址，常見範圍為 198.18.0.1/16。App 之後連線到該位址時，Clash 會根據內部對應關係還原原始網域並執行規則。這能減少部分情境下的額外解析等待，也有助於保留網域規則資訊。

在測試環境中執行 dig @127.0.0.1 -p 1053 example.com A，若回傳 198.18.x.x，通常表示請求已進入 fake-ip 流程。這個結果不是網站的真實公網 IP，不應拿來與公共 DNS 的查詢結果逐項比較。

fake-ip-filter：讓區域網路與特殊網域回傳真實位址

印表機、路由器、區域網路探索，以及部分依賴真實 IP 的服務可能不適合 fake-ip。可以使用 fake-ip-filter 排除本地域名，但應從實際發生問題的網域開始新增，不要直接複製上百條來源不明的清單。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "router.asus.com"
    - "time.apple.com"

*.local 通常與 mDNS 及區域網路探索有關。在 iOS 上使用 AirPlay、隔空列印或探索家庭裝置時若出現異常，可先檢查這些網域是否被 fake-ip 接管，同時確認客戶端是否允許存取區域網路。iOS 26 中可前往「設定」→「隱私權與安全性」→「區域網路」查看相關權限。

redir-host：直接回傳真實解析結果

redir-host 通常會向 App 回傳真實 IP，連線相容性較直觀，但網域與連線的關聯能力取決於流量接管方式。遇到銀行類 App、區域網路裝置或特殊協定與 fake-ip 不相容時，可以暫時切換至 redir-host 進行對照。若切換後立即恢復，應優先完善 fake-ip-filter，而不是同時更換節點、規則與 DNS。

DNS 劫持與 TUN 模式怎麼設定

這裡所說的 DNS 劫持，是指客戶端將發往其他 DNS 位址的 53 連接埠請求轉交給 Clash 內建 DNS。它解決的是 App 繞過系統 DNS、直接存取固定 DNS 伺服器的問題。僅設定 listen 並不會改變這些封包的目的地。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用於接管常見的 DNS 請求，tcp://any:53 則涵蓋 TCP DNS。DoH 使用 HTTPS 的 443 連接埠，DoT 通常使用 853 連接埠，無法依靠一般的 53 連接埠劫持並完整辨識。若 App 內建 DoH，還需要透過網域規則、連線策略或 App 本身的設定處理。

在 iPhone 與 iPad 上，客戶端通常會透過 iOS Network Extension 建立 VPN 設定。YAML 中的 tun 欄位是否生效，取決於客戶端的實作。遇到系統狀態與 App 狀態不一致時，可前往「設定」→「一般」→「VPN 與裝置管理」→「VPN」確認目前連線；接著返回客戶端，查看記錄中是否出現 DNS timeout、no such host 或上游連線失敗。

設定後的驗證步驟

1. 先進行語法驗證。 YAML 使用空格縮排，不可混入 Tab。dns、tun 應位於正確層級，清單項目前保留連字號。
2. 查看監聽狀態。 桌面版可確認 1053 連接埠是否由核心監聽。若連接埠已被其他程式佔用，請改用 1054，並同步修改測試指令。
3. 查詢一個尚未快取的網域。 在可使用命令列的裝置上執行 dig @127.0.0.1 -p 1053 example.com A。fake-ip 模式應看到 198.18.0.0/16 範圍內的位址，redir-host 模式則應看到公網位址。
4. 比較首次與再次查詢。 在相同測試環境中，首次查詢若為 1800 毫秒、再次查詢為 20 毫秒，通常表示快取正常，但建立上游連線較慢；若每次都超過 2000 毫秒並逾時，應檢查 DoH 路徑與 default-nameserver。
5. 檢查規則命中狀態。 開啟一個具有明確網域規則的網站，在客戶端連線記錄中確認顯示的是網域規則，而不是意外套用 IP-CIDR 或 MATCH。
6. 清除舊快取後重新測試。 修改增強模式後，應重新啟動核心，或使用客戶端提供的清除 DNS 快取功能。只重新整理網頁，可能仍在使用 App、系統或瀏覽器儲存的舊結果。

常見誤區與建議調整順序

以為上游越多就越穩定

上游伺服器越多，路徑差異、並行結果與記錄雜訊也會越多。排查期間先使用一個 UDP DNS 和一個 DoH，確認兩者都能連線後，再決定是否保留。行動網路、公司 Wi-Fi 與家用寬頻對 53、853、443 連接埠的限制可能不同，穩定性應以目前網路的實測結果為準。

同時啟用 fallback、policy 與大量過濾條件

fallback-filter、nameserver-policy 與代理規則可能共同影響一次存取。一次加入大量條件後，很難判斷最後是哪項設定在發揮作用。建議順序是：先讓 nameserver 正常運作，再選擇 fake-ip 或 redir-host，接著加入少量 policy，最後才導入 fallback 篩選。

把 DNS 問題誤認為節點問題

DNS 查詢會在連線至節點之前或與其並行發生。更換代理節點後暫時恢復，可能只是快取被清除，或上游連線重新建立。判斷時應查看記錄：解析階段出現 context deadline exceeded、no such host 時，應優先處理 DNS；已取得目標 IP 但代理握手逾時，才繼續檢查節點與線路。

忽略 IPv6 設定前後不一致

ipv6: false 通常表示 DNS 模組不回傳 AAAA 結果，但系統、TUN 與代理節點仍可能各自具有 IPv6 設定。若網路只有不穩定的 IPv6 路由，可以先關閉 DNS IPv6 進行對照；若必須存取 IPv6-only 服務，則需同時確認本地網路、節點與規則都支援 IPv6，不能只將該欄位改為 true。

穩定設定的關鍵在於路徑清楚：使用 default-nameserver 完成啟動解析，以少量 nameserver 處理主要查詢，確實有地區篩選需求時再加入 fallback，透過 fake-ip 或 redir-host 維持網域與連線的關聯，最後由 TUN 或 iOS 網路擴充功能接管實際流量。依照這個順序調整，通常就能分層定位 DNS 逾時、規則未命中與區域網路異常。