進階配置 2026-07-19 預計閱讀 9 分鐘

Clash DNS 配置詳解:nameserver、fallback 與 DNS 劫持參數怎麼填

Clash 配置檔裡的 dns 段決定了網域解析走哪條路徑、會不會被污染、能不能配合規則分流。本文逐項拆解 nameserver 與 fallback 的分工、fake-ip 與 redir-host 兩種解析模式的差異、常見 DNS 劫持相關參數的作用,並提供可以直接套用的配置片段與驗證步驟。

為什麼 Clash 要自己處理 DNS

一般上網流程裡,裝置發起網域請求後先經過系統或路由器配置的 DNS 伺服器解析出 IP,再拿著 IP 去連接目標伺服器。如果這一步的 DNS 請求本身沒有被代理,電信業者或中間網路設備就有機會看到你在查詢哪個網域,甚至回傳錯誤的解析結果,這就是常說的 DNS 污染或 DNS 劫持。規則分流也依賴準確的網域資訊:如果客戶端拿到的網域對應的 IP 不可信,基於 DOMAIN-SUFFIX、GEOIP 等規則做出的分流判斷就會失真。

Clash 與 Clash Meta(核心 mihomo)在配置檔裡內建了一個獨立的 DNS 模組,可以把網域解析這一步也納入代理體系統一管理,而不是把解析權完全交給系統網路設定。這個模組由 dns 欄位整體控制,其中 nameserver、fallback、enhanced-mode 是最核心的三個配置項,搭配得當才能既保證解析速度,又避免被污染或劫持。

DNS 段是否生效、生效到什麼程度,與客戶端具體實作相關,建議先確認使用的客戶端(Clash Verge Rev、FlClash、mihomo 核心等)版本對 dns 欄位的支援範圍,再照抄配置。

nameserver 與 fallback:兩組網域伺服器各管什麼

Clash 的 DNS 段裡通常會看到兩組伺服器位址,分別寫在 nameserver 和 fallback 欄位下,它們不是簡單的主備關係,而是承擔不同職責的兩套解析通道。

nameserver:預設解析通道

nameserver 是日常解析走的第一條通道,配置裡填寫的伺服器位址會被用來解析絕大多數網域請求,包括規則判斷本身也會用到這裡回傳的結果。台灣本地場景下通常填寫電信業者 DNS 或公共 DNS(如 168.95.1.1、1.1.1.1),保證存取本地站點時解析速度足夠快,不必繞一圈代理再回來。

fallback:兜底與境外網域解析通道

fallback 是一條兜底通道,配合 fallback-filter 使用時,常見做法是:先用 nameserver 解析網域,再檢查回傳的 IP 是否落在 fallback-filter.geoip-code 指定的國家段內(通常填 TW 或 CN);如果不在本地 IP 段,說明這個網域很可能是需要走代理的境外站點,這時改用 fallback 裡配置的境外 DNS(如 1.1.1.1、8.8.8.8)重新解析,避免用本地 DNS 解析境外網域時出現的回應慢或解析結果不準確的問題。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

其中 default-nameserver 是一條更基礎的通道,專門用來解析 nameserver 與 fallback 欄位裡那些以網域形式書寫的 DNS 伺服器位址(比如某些寫成網域的 DoH 位址),必須填純 IP,不能再依賴尚未建立好的解析鏈路去解析自己。

fake-ip 與 redir-host:兩種解析模式怎麼選

enhanced-mode 決定了 Clash 把解析出來的網域資訊如何交給後續的代理和規則模組處理,常見取值是 fake-ip 與 redir-host,兩者的運作方式和適用場景差別很大。

fake-ip 模式

在 fake-ip 模式下,Clash 不會把網域解析出的真實 IP 直接交給應用程式,而是先回傳一個虛擬的、位於私有位址段內的假 IP。應用程式拿著這個假 IP 發起連接後,流量會先進入 Clash,由 Clash 在內部把假 IP 映射回原始網域,再根據規則決定真正的出口和目標位址。這種模式的好處是解析速度快、能配合 TUN 模式做到全域透明代理,幾乎是目前桌面客戶端和路由器場景的預設選擇。缺點是部分對 IP 有強依賴的應用程式(比如某些需要驗證直連 IP 的服務、區域網路裝置探索)可能出現異常,這時通常需要在配置裡為對應網域或 IP 段單獨設定直連規則,或者把這些網域加入 fake-ip-filter 排除清單,讓它們跳過假 IP 處理。

redir-host 模式

redir-host 模式則是舊式做法:Clash 直接把網域解析成真實 IP 回傳給應用程式,代理判斷依賴的是應用程式連接時攜帶的 Host 標頭或 SNI 資訊。這種模式相容性更好,不容易出現假 IP 帶來的相容性問題,但解析和轉發效率不如 fake-ip,且對不攜帶明確網域資訊的協定(比如部分基於純 IP 通訊的應用程式)分流準確度會下降。目前主流 Clash Meta / mihomo 核心客戶端已經把 fake-ip 作為推薦配置,redir-host 更多是歷史配置或特殊相容場景下的備選項。

切換 enhanced-mode 後建議重啟客戶端或重新載入配置,部分實作下解析快取不會自動清空,可能出現切換後短時間內解析結果仍是舊模式的現象。

DNS 劫持相關參數怎麼理解與配置

除了 nameserver 與 fallback 的基本分工,Clash 的 DNS 段還提供了幾個專門用於對抗 DNS 劫持、提升解析安全性的參數,理解它們的作用能幫助排查「網頁打不開但代理明顯在運作」這類問題。

使用加密 DNS 協定

直接用一般的 udp:// 明文 DNS 請求,依然存在被中間網路設備竄改或阻斷的風險。把 nameserver 或 fallback 裡的位址換成 tls://(DNS over TLS)或 https://(DNS over HTTPS)前綴,可以讓 DNS 請求本身走加密通道,減少被劫持竄改的機會。例如 https://1.1.1.1/dns-query 或 tls://8.8.8.8:853 都是常見寫法,大多數 mihomo 核心客戶端都原生支援這兩種前綴。

listen 與劫持區域網路 DNS 請求

dns.listen 欄位用來指定 Clash 內建 DNS 服務監聽的本機埠(比如 0.0.0.0:1053),配合系統代理或 TUN 模式的 DNS 劫持開關,可以把裝置本身發出的 DNS 請求強制攔截並轉交給 Clash 處理,而不是繞過 Clash 直接打到系統配置的 DNS 伺服器上。如果發現某些應用程式的網域請求完全沒有走代理規則,往往就是因為這個劫持環節沒生效,應用程式用了硬編碼的 DNS 位址,繞開了系統解析入口。

nameserver-policy 精細化分流

對於個別網域需要走特殊 DNS 伺服器解析的場景(比如公司內部網域必須用內部 DNS,不能走公共 DNS 解析出錯誤結果),可以用 nameserver-policy 針對具體網域或網域後綴單獨指定解析伺服器,優先度高於全域的 nameserver 配置:

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.internal":
      - 10.0.0.53

這類配置常用於混合辦公、內外網並存的環境,避免內部服務因解析走錯通道而無法存取。

驗證 DNS 配置是否真正生效

寫完配置後不能只靠「網頁能打開」這種模糊判斷,建議按下面的步驟逐項核實。

  1. 查看客戶端的連接日誌或 DNS 查詢記錄:多數圖形化客戶端(如 Clash Verge Rev)在「連接」或「日誌」面板裡能看到即時的網域解析請求,確認目標網域確實經過了 Clash 處理,而不是繞過。
  2. 用命令列工具核對解析結果:在終端機執行 nslookup 目標網域 127.0.0.1 -port=1053(埠需替換為實際 dns.listen 設定的埠),看回傳的是假 IP 還是真實 IP,與預期的 enhanced-mode 一致即可。
  3. 測試本地與境外站點的分流是否符合預期:分別存取一個明確的本地站點和一個明確的境外站點,結合規則日誌確認前者走了直連、後者走了代理節點,而不是兩者都走同一條路徑。
  4. 檢查是否存在解析洩漏:部分應用程式會內建自己的 DNS 邏輯繞開系統設定,如果懷疑某個應用程式洩漏了真實解析請求,可以暫時關閉該應用程式的網路權限或用防火牆規則單獨觀察其 DNS 流量,確認是否真的被劫持進了 Clash。
配置項作用常見取值
nameserver預設解析通道,處理大部分請求223.5.5.5、119.29.29.29
fallback兜底通道,配合過濾器處理境外網域tls://1.1.1.1:853
fallback-filter判斷解析結果是否需要切到 fallbackgeoip-code: CN
enhanced-mode決定 fake-ip 或 redir-host 解析模式fake-ip
nameserver-policy為特定網域指定專用解析伺服器按網域/後綴映射

建議先用一份成熟客戶端自帶的預設 DNS 配置作為基準,確認基礎規則正常運作後,再按自己的網路環境逐項微調 fallback 與 nameserver-policy,避免一次改動過多參數導致排查困難。

常見誤區與排查思路

實際配置過程中,幾個誤區容易反覆出現,提前了解可以省掉不少排查時間。

  • 把 fallback 當成主 DNS 使用:如果 fallback-filter 配置不當或缺失,可能導致所有請求都被判定為需要走 fallback,本地站點解析速度反而變慢,這種情況需要檢查 geoip-code 是否正確填寫。
  • 混用未加密與加密 DNS 卻沒有統一逾時策略:加密 DNS 請求耗時通常略高於明文請求,如果客戶端逾時設定過短,可能出現解析間歇性失敗,可以適當調整客戶端的 DNS 逾時參數或減少 fallback 清單裡的伺服器數量。
  • 忽略 IPv6 對解析結果的影響:部分網路環境啟用了 IPv6,如果 Clash 的 ipv6 欄位與系統實際網路狀態不匹配,可能出現解析出的 IP 類型與實際可用連接方式不一致,建議按自己的網路環境明確宣告 ipv6: true 或 false,不要留空。
  • 規則裡用了 IP 段判斷但解析模式是 fake-ip:fake-ip 模式下應用程式拿到的是假 IP,如果規則嚴重依賴真實 IP 段(如 GEOIP),需要確認客戶端核心在做規則比對時是否已經把假 IP 還原成真實 IP 再判斷,不同實作的處理順序可能有差異,遇到比對異常時可以先切到 redir-host 模式對比驗證。

DNS 段的配置不需要一次到位,先用基礎的 nameserver + fallback + fake-ip 組合跑起來,再根據實際使用中遇到的具體問題(某個應用程式連不上、某個內部服務解析錯誤)逐項加參數修正,通常比一開始就堆砌所有可選欄位更容易維護。

下載客戶端