進階功能 約 9 分鐘閱讀

Clash DNS 配置與防洩漏設置實操指南

講解 fake-ip 與 redir-host 兩種 DNS 模式的取捨、上游 DNS 伺服器的選擇原則，以及驗證 DNS 請求是否繞過代理洩漏的實用方法。

DNS 解析在代理鏈路中的位置

代理軟體本身只處理已經建立的網路連線，而網域名稱解析發生在連線建立之前。如果 DNS 請求走了系統預設的解析器而不是 Clash 內建的 DNS 模組，會出現兩個問題：一是本機的 DNS 請求直接發往電信業者或本地網路的解析伺服器，暴露訪問過哪些網域，即所謂的 DNS 洩漏；二是規則引擎裡的 DOMAIN、DOMAIN-SUFFIX 等網域類規則可能匹配不到正確的目標，因為用戶端拿到的 IP 和規則預期的網域對應關係不一致，導致分流出錯。

Clash 和 Clash Meta（mihomo 核心）都提供獨立的 dns 配置區塊，接管用戶端的網域解析流程，不再依賴系統 hosts 或系統網路設定裡配置的 DNS。這個模組的核心配置項包括 enhanced-mode（解析模式）、nameserver（上游 DNS）、fallback（備用 DNS）以及是否開啟 fake-ip 相關的過濾規則。理解這幾個欄位的作用，是排查分流異常和 DNS 洩漏的前提。

說明：只有開啟了 dns.enable 且用戶端處於系統代理或 TUN 模式接管流量的狀態下，DNS 模組才能真正攔截請求。單獨開啟 DNS 配置而不接管系統代理，效果有限。

fake-ip 與 redir-host 兩種模式的取捨

Clash 的 enhanced-mode 支援兩種取值，工作原理和適用場景差異很大，選錯模式是很多分流異常和訪問失敗問題的根源。

fake-ip 模式

用戶端查詢某個網域時，DNS 模組不去真正解析這個網域，而是從一個預先劃定的位址段（例如 198.18.0.1/16）裡分配一個虛構的 IP 回傳給系統。應用程式拿著這個假 IP 發起連線，Clash 在建立 TCP/UDP 連線時再根據這個假 IP 反查出原始網域，交給規則引擎判斷走哪條代理線路，真正的網域解析在這一步才發生。這種方式的優點是不會向任何上游 DNS 洩漏真實訪問記錄，規則匹配也更精確，因為規則引擎拿到的是原始網域而不是解析後的 IP。缺點是依賴假 IP 到網域的對應表，某些嚴格檢驗用戶端 IP 的服務、局域網裝置探索通訊協定，以及部分需要真實解析結果的場景（比如某些下載軟體的多執行緒測速）可能出現異常，需要用 fake-ip-filter 把這些網域排除在假 IP 之外，改用真實解析。

redir-host 模式

這種模式下，DNS 模組直接用配置的上游伺服器把網域解析成真實 IP 回傳給系統，用戶端拿到的就是真實位址。它的歷史用途是配合早期的透明代理（iptables REDIRECT、TPROXY）場景，代理伺服器需要靠 Host 標頭或 SNI 還原目標網域再匹配規則，因為透明代理攔截的是 IP 連線而不知道網域。這種模式的局限也很明顯：真實解析結果會經過 Clash 配置的上游 DNS，如果上游選得不當，解析出的 IP 可能和實際就近節點不匹配，對 CDN 多線路服務不友善；同時因為用戶端直接拿到真實 IP，部分基於 IP 段做識別的偵測機制更容易發現代理痕跡。

綜合來看，現在的主流做法是優先使用 fake-ip，只在極少數確實需要真實 IP 的場景裡用 fake-ip-filter 做局部例外，而不是整體切換到 redir-host。redir-host 更適合沒有網域偵測能力的老舊透明代理鏈路，一般用戶在 TUN 模式或系統代理模式下幾乎不需要用到它。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - 'time.*.com'
    - 'ntp.*.com'

上游 DNS 伺服器的選擇原則

nameserver 欄位決定網域最終解析用哪個伺服器完成，fallback 欄位則作為備用解析來源，通常配合 fallback-filter 的地理位置判斷使用。選擇上游 DNS 時可以參考以下幾條原則：

  • 優先使用支援加密的通訊協定。普通的明文 UDP 53 埠查詢容易被中間網路節點觀察甚至竄改，條件允許時優先配置 DoH（DNS over HTTPS）或 DoT（DNS over TLS），格式分別是 https://網域/dns-query 和 tls://網域:853。
  • 區分台灣本地與海外的解析路徑。訪問台灣本地站點建議走本地公共 DNS 保證解析速度和 CDN 就近效果，訪問海外站點則走海外或加密 DNS，避免本地解析結果指向了不適用的節點。這一步通常靠 nameserver-policy 按網域尾碼分流，或者靠 fallback-filter.geoip 判斷解析結果是否屬於本地 IP 段來決定是否採用。
  • 避免使用代理節點所在地區與解析伺服器地區嚴重不匹配的組合。如果所有網域都統一走海外 DNS 解析，本地網站可能被解析到不利於訪問的節點，出現訪問緩慢或驗證碼頻繁觸發的情況。
  • 保留至少一個 fallback。主 DNS 無法連線或逾時時，fallback 能保證解析不中斷，建議主備使用不同電信業者或不同通訊協定，避免同時失效。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - tls://223.5.5.5:853
  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    'geosite:cn': 'https://doh.pub/dns-query'
    'geosite:geolocation-!cn': 'https://1.1.1.1/dns-query'

上面範例的思路是：預設走本地加密 DNS，命中海外網域分類（geosite 規則集）時改走海外 DNS，同時用 fallback-filter 兜底判斷解析出的 IP 是否屬於本地位址段，避免因為網域分類庫未及時更新而誤判。這套組合基本能兼顧本地站點訪問速度和海外站點的正確分流。

驗證 DNS 請求是否繞過代理洩漏

配置好 DNS 模組後，需要用實際手段確認請求真的走了 Clash 而不是系統預設解析器，常見方法如下。

方法一：查看用戶端連線日誌

大多數 Clash 圖形用戶端（Clash Verge、Mihomo Party、FlClash 等）都帶有連線日誌或活動連線面板，正常情況下每一條經過代理的連線都會顯示對應的目標網域，而不是裸露的 IP。如果發現大量條目只顯示 IP 沒有網域，說明這些請求在到達代理引擎之前網域資訊已經遺失，通常是因為系統代理沒有覆蓋到發起請求的應用程式，或者該應用程式使用了不走系統代理設定的直連方式，這類流量建議改用 TUN 模式統一接管。

方法二：抓包核實是否有明文 DNS 流量外洩

用抓包工具（如 Wireshark 或命令列 tcpdump）過濾 UDP 53 埠和常見 DoH 埠，觀察本機網卡上是否存在發往非 Clash 配置的上游伺服器的查詢封包。如果在開啟代理的情況下依然能捕獲到系統網路設定裡配置的電信業者 DNS 位址的查詢記錄，說明存在旁路洩漏，需要檢查系統代理是否覆蓋了 UDP 流量，或者是否需要切換到 TUN 模式接管全部網路層流量。

方法三：命令列直接比對解析結果

在終端機裡分別使用系統預設解析器和指定 Clash 配置的上游伺服器解析同一個網域，比對回傳的 IP 是否一致，以及請求耗時是否吻合預期路徑。

# 使用系統預設解析器
nslookup example.com

# 強制指定伺服器解析，對比結果是否一致
nslookup example.com 223.5.5.5

如果開啟 fake-ip 後用系統自帶工具查詢網域，得到的應該是 fake-ip-range 範圍內的位址而不是真實公網 IP，這是正常現象，說明假 IP 機制生效，並不代表解析失敗。

方法四：使用線上 DNS 洩漏檢測頁面

瀏覽器訪問專門的 DNS 洩漏檢測網站，頁面會列出實際發起解析請求的伺服器資訊。正常情況下應該只顯示配置的上游 DNS 或對應的加密解析節點，如果清單中出現本地網路電信業者的解析伺服器資訊，說明部分流量繞開了代理直接查詢，需要回頭檢查系統代理範圍、TUN 模式開啟狀態，或者瀏覽器本身是否啟用了獨立的 DoH 設定和 Clash 的 DNS 模組產生衝突。

常見誤區：部分瀏覽器自帶的安全 DNS 功能會繞過系統代理直連指定的加密 DNS 伺服器，即便 Clash 配置正確也會造成網域查詢繞過代理。排查洩漏時記得同時檢查瀏覽器本身的 DNS 設定是否已關閉或調整為跟隨系統。

常見配置問題與排查思路

實際使用中遇到的 DNS 相關問題大多集中在以下幾類，逐一排查可以快速定位。

  1. 規則分流命中不準確。多數情況下是因為使用了 redir-host 或未開啟 fake-ip，規則引擎拿到的是解析後的 IP 而不是原始網域，導致按網域配置的規則失效。切換回 fake-ip 通常能解決。
  2. 局域網裝置無法互相探索或訪問。這是 fake-ip 模式的典型副作用，需要把局域網相關網域（如 *.lan、路由器管理網域）加入 fake-ip-filter，讓這些請求走真實解析而不是假 IP。
  3. 本地站點訪問變慢或觸發額外驗證。通常是本地網域走了海外 DNS 解析出了不適用的 IP，需要檢查 nameserver-policy 或 fallback-filter 的地區判斷是否配置正確。
  4. 解析長時間逾時。檢查配置的上游 DNS 伺服器本身是否可連線，加密通訊協定（DoH/DoT）在部分網路環境下可能被干擾，可以先換成明文 UDP 伺服器驗證是否是通訊協定層面的問題，再決定是否保留加密配置。
  5. 系統代理模式下 UDP 類應用程式（遊戲、視訊通話）解析異常。系統代理通常只接管 TCP 流量，UDP 請求包括部分 DNS 查詢可能不受控制，這類場景建議直接使用 TUN 模式，從網路層統一接管所有通訊協定的流量和解析請求。

把 DNS 模式選對、上游伺服器按地區分流配置好，再用連線日誌、抓包和線上檢測三種手段交叉驗證，基本可以確認解析路徑沒有繞開代理，規則引擎也能拿到準確的網域資訊用於分流判斷。

配置好 DNS 之後，記得同步檢查用戶端整體設置

下載對應平台的最新用戶端，或查看完整的安裝與配置教學，確認代理模式、訂閱規則和 DNS 設定協同生效。

前往下載頁 查看教學
下載用戶端