Clash DNS 設定詳解：nameserver、fallback 與 fake-ip 劫持完整說明

DNS 設定的四個環節

排查 Clash DNS 問題時，先區分查詢如何進入、解析模式、上游選擇與連線分流。應用程式將網域交給哪個 DNS 服務，取決於系統、瀏覽器及流量接管方式；Clash 收到查詢後，才會依據 dns 設定處理。最後的連線出口則由代理模式與 rules 決定，不是填入某個 DNS 位址就一定會走特定節點。

環節	主要欄位	檢查重點
查詢進入	`listen`、`tun.dns-hijack`	應用程式的查詢是否進入核心
解析模式	`enhanced-mode`	回傳真實位址或映射位址
上游選擇	`nameserver`、`fallback-filter`	採用哪一組解析結果
連線分流	`rules`、`proxy-groups`	實際連線使用哪個出口

訂閱原始內容、用戶端編輯器中的設定與最終執行設定，可能是三個不同檔案。若訂閱更新會覆蓋原始內容，請透過用戶端提供的覆寫或合併設定保留修改。合併後請檢查最終結果：同一個 YAML 映射中，不要重複寫入兩個 dns: 或兩個 tun:。

nameserver、fallback 與引導解析

nameserver：一般上游，不是代理節點

nameserver 是 DNS 解析上游清單，可填入一般 DNS 位址，也可使用核心支援的 DoH、DoT 位址。一般位址 223.5.5.5 通常代表使用 UDP 53；https://1.1.1.1/dns-query 則代表 DoH，通常透過 HTTPS 443 連線。上游必須能從目前的網路連線；使用特定協定名稱並不保證請求一定成功。

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:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

這段設定用來說明欄位之間的關係，並非完整的節點設定。127.0.0.1:1053 僅在本機監聽，方便直接測試查詢；作業系統不會因為這個監聽埠存在，就自動將所有 DNS 請求交給它。ipv6: false 控制此 DNS 模組對 AAAA 查詢的回應方式，不代表關閉作業系統的 IPv6，也不代表阻擋所有 IPv6 連線。

default-nameserver：解析 DNS 上游的網域名稱

如果上游寫成 https://dns.example.com/dns-query 這類網域名稱，建立連線前必須先取得它的 IP 位址。default-nameserver 負責這類引導解析。為避免形成引導迴圈，範例使用 IP 位址直寫。它不是「所有業務網域都先查一次」的預設伺服器，也不是專供代理節點使用的解析器。

mihomo 也提供 proxy-server-nameserver，用於解析代理節點的網域名稱。如果節點位址本身是網域名稱，且解析路由形成循環依賴，就需要另外檢查這一層。請勿將「網站網域解析失敗」和「節點網域無法解析」視為同一個問題。

fallback：備用解析結果，不是依序等待的清單

設定 fallback 後，常見處理方式是同時送出主要組與備用組的查詢，再依據過濾條件決定採用哪一組結果。不要將它理解成「先等 nameserver 逾時，再逐一嘗試 fallback」。多個位址的回應競速、快取與失敗處理方式會受核心實作影響，清單順序也不能直接視為嚴格的優先順序。

DoH 只代表連線至解析服務的這一段使用 HTTPS，不會自動啟用代理出口，也無法阻止瀏覽器使用自己的安全 DNS。DNS 請求是否遵循路由規則，須搭配核心欄位、最終設定與記錄確認。

fallback-filter：哪些結果會切換

fallback-filter 不會變更 IP 位址的地理歸屬，而是提供選擇備用結果的條件。在上述設定中，geoip: true 搭配 geoip-code: CN，表示主要組回傳的位址若不符合指定地區條件，就傾向採用備用組結果。這項功能仰賴 GeoIP 資料；資料過期、CDN 調度變動或位址歸屬不準確，都可能影響選擇結果。

geoip: false：停用這項地理歸屬判斷，不代表關閉所有過濾條件。
ipcidr：主要組結果落在這些位址範圍內時，改用備用結果。240.0.0.0/4 是常見的保留位址範圍過濾範例。
domain：符合指定網域時，直接採用備用組結果，不再依賴主要組位址是否符合地區條件。

  fallback-filter:
    geoip: false
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

這段設定應放在現有的 dns 下方，用來取代前例的 fallback-filter。example.com 是保留的文件範例網域，不是建議採用的實際業務清單。此處停用地區判斷，只保留位址範圍與網域條件，方便釐清問題。請勿未經驗證就過濾所有私有網段：企業內部網域、路由器管理頁面與家用 NAS，可能本來就應解析到私有位址。

另一個常見誤解，是把 fallback-filter.domain 當成代理規則。它只會控制 DNS 結果來源，不會建立 DOMAIN-SUFFIX 規則。即使網站使用備用解析結果，連線仍可能被 DIRECT 規則接手。

fake-ip 與 redir-host 的差異

fake-ip：先建立網域映射

enhanced-mode: fake-ip 會為符合條件的查詢回傳映射位址。應用程式連線至該位址後，核心便能找回原始網域，再進行規則比對與連線處理。因此，在命令列看到 198.18.x.x 不代表 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:
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query

198.18.0.1/16 位於基準測試專用的位址空間。使用前仍須檢查本機路由，避免與實驗網路衝突。回傳映射位址後，相關連線必須再次進入核心；如果 DNS 經過 Clash，但資料連線未被接管，應用程式就可能無法連線至這些位址。

fake-ip-filter 用來讓指定網域回傳真實解析結果。上述範例採用一般的黑名單過濾語意，不會同時設定其他過濾模式。內網服務可依實際網域加入清單；不過 .local 通常由 mDNS 處理，將它加入過濾清單並不代表 Clash 會代理所有多點傳送探索請求。

redir-host：回傳真實位址

redir-host 會回傳實際解析位址，並利用解析記錄將網域與連線關聯起來。這適合需要真實 IP 的相容性情境，但若多個網域共用同一位址、應用程式自行解析，或快取時間過長，網域關聯可能不完整。這兩種模式都不等同於嗅探：mihomo 的 sniffer 是透過後續連線資訊辨識網域的另一套機制。

TUN dns-hijack：讓查詢進入核心

dns-hijack 屬於 tun，不是 dns 的子欄位。mihomo 常見的設定方式如下；與上一節的 DNS 設定合併時，兩個頂層欄位必須保持同一層級。

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

any:53 會接管進入 TUN 的一般 UDP 53 查詢，tcp://any:53 則補上 TCP 53。接管後的查詢由核心 DNS 模組處理，不必要求系統將伺服器明確設為 127.0.0.1:1053。但前提仍是封包實際經過 TUN 路徑，且目前平台支援相應的路由與接管功能。

啟用 TUN 通常需要管理員權限或系統授權。建立虛擬網卡後，還須確認路由是否生效。
瀏覽器的 DoH 使用 HTTPS，Android 私人 DNS 通常使用 DoT；這些都不是一般的 53 埠查詢，無法透過上述兩行設定自動改寫。
只啟用系統 HTTP 代理，不保證應用程式的 DNS 查詢也會進入核心。有些應用程式會先透過系統 DNS 解析，再發起代理連線。
若同時執行多個 VPN、虛擬網卡或本機 DNS 服務，請先只保留一條接管路徑進行驗證，避免彼此修改路由。

請勿為了方便接管，就直接將 dns.listen 改為 0.0.0.0:53。這會變更監聽範圍，也可能與系統解析服務發生埠號衝突。只有確實需要為區域網路裝置提供 DNS 時，才應設定對外監聽，並同時限制防火牆來源與可存取的網路。

常見組合與設定選擇

適用情境	建議起始設定	重點驗證項目
優先排查解析上游	redir-host + 本機 1053 監聽	直接查詢能否取得真實位址
需要依網域穩定分流	fake-ip + TUN 接管	映射位址的連線是否進入核心
企業內網或家用服務較多	依網域指定 DNS 與過濾例外	內部網域沒有送往公用解析器
需要比較兩組解析結果	nameserver + fallback + 明確的過濾條件	採用的結果符合預設條件

mihomo 可透過 nameserver-policy 為特定網域指定上游。例如，公司 DNS 位於 192.168.50.1，且內部網域使用文件範例後綴 corp.example 時，可在現有的 dns 下方加入：

  nameserver-policy:
    '+.corp.example':
      - 192.168.50.1

實際使用時，必須換成真正的內部網域後綴與可連線的 DNS 位址，並確認相關網域是否也須加入 fake-ip-filter。網域策略、備用過濾與連線規則是不同層級的設定；排除問題時，先移除彼此重疊的策略，確認基本解析正常後，再逐項加回。

若希望 DNS 連線遵循分流規則，mihomo 的 respect-rules 須搭配 proxy-server-nameserver 等設定一併規劃，以免形成「解析節點需要先連線至節點」的迴圈。基本設定尚未驗證前，不建議一次加入此開關與多項網域上游策略。

驗證順序與故障排除

第一步：檢查設定與監聽

使用相對應的 mihomo 執行檔檢查語法，再透過用戶端重新載入設定。以下假設目前目錄中有實際設定檔 config.yaml，且已安裝 dig：

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

語法檢查通過，不代表所有上游都能連線。若 UDP 查詢成功、TCP 查詢失敗，請先確認監聽狀態與本機防火牆；若兩者都逾時，請檢查 dns.enable、埠號占用情況與最終執行設定。fake-ip 模式回傳映射位址，只能證明本機映射路徑正常，不能單靠這點確認真實上游運作正常。

第二步：檢查系統解析路徑

明確指定 127.0.0.1 與埠號，是在測試核心的監聽服務。接著執行 nslookup example.com，測試系統預設的解析路徑。兩者結果不同不一定代表故障；但若預期所有查詢都經過核心，就需要檢查系統 DNS、TUN 路由與瀏覽器安全 DNS 設定。

第三步：檢查連線與出口

清除快取，關閉舊分頁或舊應用程式連線，再重新連線測試。
在用戶端的連線清單中，檢查目標網域、符合的規則與最後採用的策略組。
若解析成功但連線逾時，請檢查節點連線狀態、代理協定與目標埠號，不要立即更換 DNS。
若只有內部服務無法連線，請分別查詢內部 DNS 與公用 DNS，確認是否缺少網域上游策略。
若懷疑 DNS 流量繞過接管，可搭配封包擷取檢查離開實體網卡的 UDP/TCP 53、853 埠，以及已知的 DoH 連線。公用測試頁顯示的解析器位置，無法單獨證明本機的請求路徑。

一次只調整一個環節：先確認核心能正常解析，再確認應用程式的查詢能進入核心，最後觀察連線規則。這樣才能區分上游無法連線、過濾條件錯誤、fake-ip 連線繞過接管，以及 TUN 未接管這四類問題。欄位的完整說明請參閱設定手冊；首次安裝與匯入流程請參閱使用教學。