Clash DNS 設定詳解：nameserver、fallback 與 DNS 劫持參數怎麼填

先理清 Clash DNS 的處理流程

Clash 的 DNS 模組並非只是將系統查詢轉送給某一個公共 DNS。啟用後，它會監聽本機連接埠、讀取設定中的上游伺服器，再根據網域、規則與回傳位址決定採用哪個結果。啟用 TUN 與 DNS 劫持後，原本送往路由器或公共 DNS 的 53 連接埠請求，也能被導入這條流程。

一次常見的查詢可以分成四個步驟：應用程式詢問某個網域的位址；系統將請求交給 Clash；Clash 向 nameserver、符合條件的策略伺服器或 fallback 發起查詢；最後依據 fallback-filter 與增強模式，回傳真實位址或 Fake IP。網頁能否開啟、網域規則能否命中、代理節點網域能否解析，都可能受到這些步驟影響。

一份易讀的基本設定

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

這裡的 listen 使用 127.0.0.1:1053，表示僅在本機回送位址監聽 UDP/TCP 1053 連接埠。1053 是常見的非特權 DNS 監聽連接埠，可避免與系統現有的 53 連接埠服務衝突。若用戶端已自動管理監聽位址，就不應在訂閱檔案中重複加入另一套互相衝突的設定。

nameserver、default-nameserver 與 fallback 分別負責什麼

nameserver：預設的業務網域解析入口

nameserver 是大多數網域查詢的主要上游。可以填寫一般 UDP DNS，也可以在相容的 mihomo 核心中使用 DoH、DoT 等格式。家庭網路重視低延遲時，可選擇距離較近且回應穩定的伺服器；需要加密傳輸時，則可使用 HTTPS DNS 位址。

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

同一個清單放入多個伺服器，不代表每次都會嚴格從第一項開始等待。具體的並行與結果選擇行為由核心實作決定，因此不宜把四、五個回應特性差異很大的伺服器堆在一起。實際設定中保留 2 至 3 個穩定上游，更容易釐清問題。

default-nameserver：先解析 DNS 伺服器本身的網域

當 nameserver 使用 https://dns.alidns.com/dns-query 這類包含主機名稱的 DoH 位址時，核心必須先知道 dns.alidns.com 的 IP，才能建立 HTTPS 連線。default-nameserver 主要負責這類引導解析，也稱為 bootstrap DNS。

default-nameserver:
  - 223.5.5.5
  - 1.1.1.1

為避免「解析 DNS 伺服器還得先連線到 DNS 伺服器」的循環依賴，這裡優先填寫可直接連線的 IP 位址。若日誌持續出現 lookup dns server failed、context deadline exceeded，應先檢查這組位址能否在目前網路中連線，而不是直接增加更多 DoH 位址。

fallback：另一組並行的候選答案

fallback 通常用來提供與主要上游不同的解析視角。啟用後，Clash 會結合篩選條件，決定採用 nameserver 還是 fallback 的結果。它並非只有在 nameserver 逾時後才啟動，因此加入過多距離遙遠的 DoH 服務，可能增加連線與資源負擔。

如果網路環境中的主要 DNS 已經穩定，而且使用 Fake IP 模式搭配完整規則集，不一定非得設定 fallback。先讓簡單設定正常運作，再依據解析遭污染、地區結果錯誤或特定網域異常，增加候選流程，通常比複製一大段舊範本更可靠。

fallback-filter 如何選擇最終答案

fallback-filter 用來判斷是否需要替換主要結果。常見條件包括 GeoIP 國家代碼、特定網段與網域清單。不同核心版本對擴充欄位的支援可能不同，使用 mihomo 時應以目前核心文件與啟動日誌為準。

geoip 與 geoip-code

fallback-filter:
  geoip: true
  geoip-code: CN

這組設定會結合 GeoIP 資料，判斷回傳位址的地理歸屬。典型用途是：主要上游回傳符合本地區預期的位址時採用該結果；回傳位址不符合篩選條件時，改為考慮 fallback 的結果。判斷品質取決於用戶端使用的 GeoIP 資料是否及時更新，不能將國家代碼視為絕對準確的線路測速結果。

ipcidr：攔截明顯異常的位址範圍

fallback-filter:
  geoip: true
  geoip-code: CN
  ipcidr:
    - 0.0.0.0/32
    - 127.0.0.0/8
    - 240.0.0.0/4

ipcidr 可以標記不希望由一般公網網域回傳的位址範圍。例如，公網網站解析到 127.0.0.1 通常不合理。不過，公司內網、家用伺服器與實驗網路可能確實使用私有位址，因此不能不加區分地封鎖所有 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。

domain：優先對指定網域採用 fallback

fallback-filter:
  geoip: true
  geoip-code: CN
  domain:
    - '+.example.net'
    - '+.example.org'

網域清單適合處理少量且可重現的異常網站。+.example.net 這類寫法表示比對該網域及其子網域，實際語法需與所使用的核心版本相容。清單不應無限增長；如果數百個網域都需要手動指定，通常表示主要上游、規則集或網路出口的選擇需要重新檢查。

fake-ip 與 redir-host 該選哪一個

enhanced-mode 決定 Clash 要將哪種答案交給應用程式。常見值為 fake-ip 與 redir-host。兩者都能搭配代理轉送，但網域保留方式、相容性與診斷方法各不相同。

fake-ip：先回傳保留位址，再在核心中對映網域

enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16

Fake IP 模式會從保留位址池回傳一個暫時位址，例如 198.18.0.23。應用程式接著連線到這個位址，Clash 依據內部對映找回原始網域，再執行網域規則與代理策略。這能減少等待真實 DNS 結果後才建立連線的步驟，也讓只看得到目標 IP 的流量更容易還原為網域。

198.18.0.0/15 是供基準測試使用的保留網段，代理核心經常將它作為 Fake IP 位址池。若區域網路、企業 VPN 或實驗環境已使用相同網段，應改用核心允許且不會衝突的範圍。看到 ping 回傳以 198.18 開頭的位址，不代表網域解析錯誤，關鍵在於請求是否由 Clash 接管。

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

fake-ip-filter:
  - '*.lan'
  - localhost.ptlogin2.qq.com
  - '+.stun.*.*'
  - '+.stun.*.*.*'

區域網路裝置探索、印表機、部分遊戲連線、STUN、時間同步，以及需要讀取真實位址的應用程式，可能不適合 Fake IP。此時可以加入 fake-ip-filter。篩選項目應根據實際故障逐條新增，並在修改後清除系統 DNS 快取；直接複製過長的清單，會讓大量網域繞過 Fake IP，削弱網域對映效果。

redir-host：回傳真實 IP，相容性更直觀

enhanced-mode: redir-host

redir-host 會向應用程式回傳真實解析位址。它適合與 Fake IP 衝突且難以逐項篩選的舊版軟體或特殊區域網路環境，但網域規則能否穩定命中，更取決於嗅探、連線中繼資料與具體接管方式。排查時可以暫時從 fake-ip 切換至 redir-host：若問題立即消失，應優先檢查 Fake IP 位址池衝突與篩選清單。

TUN 模式下為什麼還需要 DNS 劫持

只將系統 DNS 設為 127.0.0.1:1053，並不能保證所有程式都會遵循。有些應用程式會直接向 8.8.8.8:53 傳送 UDP 請求，有些裝置則使用路由器下發的 DNS。TUN 模式負責接管 IP 流量，而 DNS 劫持會進一步將符合條件的 53 連接埠請求交給 Clash DNS 模組處理。

mihomo 設定中常見的 TUN 片段如下。欄位支援情況會隨核心與用戶端封裝方式改變；圖形化用戶端自動產生 TUN 設定時，應優先使用介面上的開關操作，避免介面設定與訂閱 YAML 互相覆蓋。

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

• enable 開啟 TUN 接管。
• stack: mixed 使用核心支援的混合網路堆疊。
• auto-route 自動寫入所需路由。
• auto-detect-interface 嘗試識別目前的出口網卡。
• any:53 比對被接管流量中的一般 53 連接埠 DNS 請求。

DNS 劫持主要涵蓋傳統 UDP/TCP 53 連接埠。應用程式內建的 DoH 使用 HTTPS 443 連接埠，從網路層看起來與一般 HTTPS 類似，不能只依靠 dns-hijack 一概改寫。若瀏覽器啟用了「安全 DNS」，排查時可暫時關閉此功能，以確認請求究竟由瀏覽器還是 Clash 解析。

一套適合日常使用的 mihomo 設定思路

日常桌面與手機環境可以從「本地上游負責常見解析、加密候選處理異常結果、Fake IP 負責網域對映、TUN 劫持傳統 DNS」這條路線開始。以下範例著重結構關係，不代表所有網路都應使用相同伺服器。

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
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8
      - 240.0.0.0/4
  fake-ip-filter:
    - '*.lan'
    - localhost
    - '+.stun.*.*'
    - '+.stun.*.*.*'

如果本地網路沒有 IPv6 出口，將 ipv6 設為 false 可避免應用程式取得 AAAA 記錄後，嘗試一條無法連線的路徑。若網路具備穩定的原生 IPv6，且代理節點與規則也能正確處理 IPv6，則可以啟用；不能只看電信業者是否分配 IPv6 位址，還要測試預設路由、DNS 回傳與代理出口是否完整。

mihomo 也提供 nameserver-policy、proxy-server-nameserver、direct-nameserver 等擴充欄位，可分別為特定網域、代理節點網域與直連請求指定解析器。這些欄位適合已經明確區分解析路徑的設定。基本設定尚未正常運作時，一次加入所有進階欄位，容易形成循環解析或讓節點網域走錯出口。

代理節點使用網域時要特別留意

訂閱中的伺服器位址可能是 node.example.com，核心必須先解析它，才能建立代理連線。如果解析該網域的 DNS 又被設定為必須透過尚未建立的代理存取，就會形成「需要代理才能解析節點、需要節點才能建立代理」的循環。mihomo 可透過 proxy-server-nameserver，為節點網域單獨指定可直連的解析器。

proxy-server-nameserver:
  - 223.5.5.5
  - https://dns.alidns.com/dns-query

DNS 異常的逐步排查方法

第一步：確認設定已由核心載入

1. 儲存 YAML 後執行用戶端的「重新載入設定」，不要只關閉編輯器。
2. 開啟核心日誌，搜尋 DNS、listen、timeout 與 parse。
3. 若出現 YAML 縮排錯誤，檢查 dns: 下是否統一使用空格縮排，以及清單項目前是否保留連字號。
4. 確認目前選取的訂閱沒有在自動更新後覆蓋本機修改。

YAML 對縮排相當敏感。以下這種將 fallback 意外縮排到 nameserver 清單中的寫法，無法表達預期結構。建議每一層使用 2 個空格，不要使用 Tab。

第二步：直接查詢 Clash 的監聽連接埠

Windows 可在 PowerShell 或命令提示字元中使用 nslookup，macOS 與 Linux 則可使用 dig。將查詢目標指向監聽位址，可以區分「Clash DNS 本身失敗」與「系統沒有將請求交給 Clash」這兩類問題。

nslookup example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

nslookup 通常預設存取 53 連接埠；若 Clash 只監聽 1053，應使用支援指定連接埠的工具，或由用戶端將系統 53 連接埠請求轉交至 1053。Fake IP 模式下取得 198.18.x.x 屬於預期現象；若持續逾時，則檢查連接埠占用、防火牆與上游可達性。

第三步：測量上游回應，不只看能否解析

一次成功回覆不代表流程穩定。可以連續查詢 20 次，觀察是否出現間歇性逾時。區域網路內的一般 DNS 常見回應約為 5 至 30 毫秒；跨區域 DoH 可能達到 80 至 250 毫秒。實際數值會受接入網路影響，重點是逾時率與波動，而不是追求單次最低值。

• 只有 DoH 逾時：檢查系統時間、TLS 連線與 DoH 網域的引導解析。
• 一般 UDP DNS 與 DoH 都逾時：檢查目前網路、預設路由與防火牆。
• 查詢成功但網頁無法開啟：繼續檢查代理規則、節點連線與 TUN 路由。
• 切換 redir-host 後恢復：檢查 Fake IP 網段衝突與篩選項目。
• 只有區域網路網域失敗：為內網網域設定專用解析策略，或加入必要的 Fake IP 篩選。

第四步：清除舊快取後重新測試

修改上游或增強模式後，系統、瀏覽器與 Clash 都可能保留舊答案。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches；瀏覽器也可能維護獨立的主機快取。清除完成後重新載入設定，再使用同一個網域重新測試，避免將舊記錄誤認為新設定的結果。

填寫這些欄位時的最終檢查清單

• enable 已開啟，監聽連接埠未與本機其他 DNS 服務衝突。
• default-nameserver 能在代理尚未建立時直接連線。
• nameserver 保留 2 至 3 個穩定上游，不堆疊大量重複服務。
• fallback 用來提供不同的解析視角，而不是機械式地充當逾時後的備用項目。
• fallback-filter 的 GeoIP、網段與網域條件符合目前網路環境。
• fake-ip-range 不與企業 VPN、家用區域網路或實驗網段衝突。
• fake-ip-filter 只加入確實需要真實位址的網域。
• 啟用 TUN 模式時，確認 dns-hijack 與用戶端自動設定沒有重複或衝突。
• 代理節點使用網域時，檢查節點網域的引導解析不會依賴尚未建立的代理。
• 每次修改只調整一組欄位，並記錄修改前後的查詢結果與日誌。

Clash DNS 設定的重點，不是尋找一段適用於所有網路的固定範本，而是將解析入口、候選結果、篩選條件、增強模式與流量接管串成一條可驗證的流程。先用最少欄位確認查詢可達，再逐步加入 Fake IP、fallback 與 TUN 劫持；發生問題時，就能準確定位到具體環節。