很多人第一次接觸 Clash 的 DNS 設定時會有點懵：核心自己有一套 DNS 模組，用戶端還能選「系統代理」或「TUN」，網站到底是怎麼被解析出來的？這篇文章從原理講起，幫你把 dns 這一段設定真正讀懂。

為什麼代理工具還要管 DNS

如果網域解析走的是本地電信業者 DNS，即使流量最終透過節點轉發，解析結果也可能已經被汙染或回傳了不準確的 IP，導致規則分流命中錯誤的地區判斷（比如 GEOIP,TW 誤判）。所以 Clash 內建了 DNS 模組，接管解析過程，讓「解析」和「轉發」都在自己的可控範圍內。

兩種解析模式：redir-host 與 fake-ip

這是設定 DNS 前最需要搞清楚的一對概念，兩者的核心差異在於「用戶端拿到的 IP 是不是真實的」。

模式解析結果適用場景
redir-host真實公網 IP相容性最好，適合有些應用需要拿到真實 IP 做驗證的場景
fake-ip虛擬的私有段 IP解析速度快、避免 DNS 洩漏，是目前的主流建議設定
dns: enable: true enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter: - "*.lan" - "+.local"
區域網路裝置探索、部分遊戲區網連線或內網服務，如果解析異常，優先檢查是不是被 fake-ip 影響了，可以把對應網域加入 fake-ip-filter 排除。

接入 DoH / DoT，避免上游 DNS 被汙染

如果 nameserver 只設定了明文的 UDP DNS（如 8.8.8.8），請求本身在鏈路上還是可能被劫持或竄改。加密 DNS（DoH/DoT）把查詢包裝進 HTTPS/TLS，能有效降低被汙染的機率。

dns: nameserver: - https://cloudflare-dns.com/dns-query # DoH - tls://dns.google # DoT fallback: - tls://1.1.1.1 - tls://8.8.8.8 fallback-filter: geoip: true geoip-code: TW

nameserver 是預設解析群組，fallback 是當預設解析結果落在指定地區外（透過 fallback-filter 判斷）時才會用到的備用解析群組，通常設定為速度快、抗汙染能力強的境外 DNS。

nameserver-policy：按網域指定 DNS

如果只想讓特定網域走特定 DNS（比如內網網域走本地 DNS，其餘走加密 DNS），可以用 nameserver-policy 單獨指定：

dns: nameserver-policy: "example.internal": "192.168.1.1"

IPv6 雙棧環境下要注意什麼

如果本地網路同時具備 IPv4 和 IPv6，且電信業者的 IPv6 出口品質一般，很多時候反而會拖慢連線速度——瀏覽器按照 Happy Eyeballs 機制會同時嘗試兩種協定，但 Clash 預設可能沒有對 IPv6 解析做特殊處理。可以透過 ipv6 欄位明確控制是否解析並使用 IPv6 結果：

dns: ipv6: false # 關閉 IPv6 解析，避免走品質較差的 IPv6 連線

如果你的 IPv6 出口本身品質不錯，也可以保留開啟，並讓 fake-ip 同時涵蓋 IPv4/IPv6 兩套結果，具體取捨建議實際測速比較後再決定，而不是照抄某一份「萬能設定」。

DNS 與本機 hosts 的優先度

部分場景下（比如自建服務測試、暫時封鎖某個網域）會想直接編輯系統 hosts 檔案。需要注意的是，一旦 Clash 接管了 DNS（dns.enable: true），系統 hosts 裡的映射不一定會被核心感知到，因為解析請求可能根本沒有經過系統的 resolver。這種場景下更建議直接在 Clash 設定裡加一段 hosts 欄位，效果等同但作用範圍更明確：

hosts: "my.local.test": "192.168.1.20"
Clash 裡設定的 hosts 優先度通常高於常規的 DNS 解析流程，適合做本機開發環境的網域映射，而不必再去改系統層級的 hosts 檔案。

不同用戶端的 DNS 設定介面差異

圖形化用戶端通常會把 dns 這段設定封裝成「基礎」「進階」兩級開關：基礎模式下只暴露一個「增強模式」的下拉選擇（對應 enhanced-mode），進階模式才會顯示 nameserver、fallback 等具體欄位。如果你在用戶端介面上找不到某個欄位，一般還是可以透過直接編輯設定檔（或者叫「設定」裡的原始 YAML 編輯入口）來補充，用戶端讀取設定時並不會因為介面沒顯示而忽略這部分內容。

網域解析異常的排查思路

  1. 先確認 DNS 模組是否開啟：dns.enable 為 false 時，Clash 不會接管解析，交由系統處理。
  2. 檢查是否命中了錯誤的規則：部分網域規則寫在了 DIRECT 之前，導致該走代理的網域被直連解析。
  3. 懷疑 fake-ip 衝突：內網裝置、區網印表機、遊戲主機探索異常時，先把對應網域加進 fake-ip-filter。
  4. 用外部工具交叉驗證：在開啟／關閉代理兩種狀態下分別執行 nslookup 或存取線上 DNS 檢測工具，比較解析結果差異。
修改 DNS 設定後建議重啟核心或點擊用戶端裡的「重新載入設定」，部分用戶端不會自動熱更新 DNS 模組。

行動裝置要不要單獨調整

手機因為經常在 WiFi 和行動網路之間切換，DNS 快取的表現會比桌面端更「敏感」一些：切換網路後如果發現某個網站解析出的還是切換前的結果，往往不是設定問題，而是系統或用戶端本身快取了上一次的解析記錄，等待快取過期或手動重啟一次代理服務即可。行動應用程式商店裡的部分用戶端出於省電考量，會限制背景重連頻率，如果長時間掛起後遇到解析異常，也可以先嘗試完全退出用戶端再重新開啟。

TUN 模式下 DNS 的表現有什麼不同

開啟 TUN 模式後，系統層面所有流量（包括 DNS 查詢）都會經由虛擬網路卡接管，理論上比傳統的系統代理模式涵蓋更完整，能攔截到一些不遵循系統代理設定的應用（例如部分使用了自訂 DNS 解析函式庫的程式）。但這也意味著一旦 DNS 設定出錯，影響範圍會更大——因此建議先在系統代理模式下把 dns 設定調試穩定，再切換到 TUN 模式驗證效果，而不是一開始就在 TUN 模式下反覆試錯。

小結

日常使用直接用 fake-ip ＋加密 DNS 上游就已經能涵蓋絕大多數場景；只有遇到內網探索、特定協定異常時才需要細緻調整 fake-ip-filter 或 nameserver-policy。把這套邏輯理清楚後，「網頁打不開卻能測速」這類問題基本都能自己排查定位。