Clash DNS 設定完全指南：Fake-IP、DNS 汙染與自建解析
規則寫得再精確，如果網域解析出來的 IP 本身就是錯的，分流也無從談起。這篇把 DNS 汙染的原理、Clash 兩種解析模式的差異、加密 DNS 與依網域分流解析的策略講透，幫你從根本排查「規則明明對了，卻還是走錯線路」的問題。
為什麼 DNS 常常是分流失敗的元兇
很多人調了半天規則，發現某個網站還是走錯線路，第一反應是「規則寫錯了」，但真正的原因往往在更前面一步——網域解析。
規則分流的前提是「先知道這個網域/IP 該不該走代理」，而這個判斷有兩種輸入：網域本身（DOMAIN、DOMAIN-SUFFIX 等規則）和解析出的 IP（IP-CIDR、GEOIP 等規則）。如果 DNS 解析這一步就出了問題，後面所有基於 IP 的判斷都會跟著錯：
- DNS 汙染／劫持：部分網路環境會對特定網域返回錯誤、甚至無法存取的 IP，常見於被封鎖或限制的網域。
- ISP DNS 就近解析：出於 CDN 加速目的返回的 IP 未必是你期望連線的端點，可能影響
GEOIP判斷。 - 本機 hosts／快取汙染：系統或路由器層面快取了錯誤結果，重開客戶端也沒用，因為問題不在 Clash 裡。
排查「規則不生效」問題時，DNS 應該是除了規則語法本身之外，第一個要檢查的環節，而不是最後一個。
Fake-IP 與 Redir-Host：兩種模式的取捨
Clash 的 dns.enhanced-mode 決定了解析行為的底層邏輯，兩種模式各有取捨：
Fake-IP 模式
- 給每個網域分配一個虛假、僅本機可見的 IP，真正解析延後到實際發起連線時才做
- 規則比對可以直接按網域進行，相容性最好，是 TUN 模式下的預設建議
- 缺點：某些依賴「拿到真實 IP 做驗證」的程式（部分遊戲、企業內網用戶端）可能不相容
Redir-Host 模式
- 直接返回真實解析結果，行為更接近傳統網路
IP-CIDR/GEOIP規則判斷會更準確，路由器／閘道情境更常用- 缺點：需要真的發一次 DNS 查詢才能決定走哪個代理，多一次往返延遲
沒有絕對的「更好」，一般建議：桌面用戶端＋TUN 模式優先用 fake-ip；如果發現某個特定應用連線異常，可以在 fake-ip-filter 裡把它的網域單獨排除，而不是直接切換整個模式。
用加密 DNS 對抗汙染：DoH 與 DoT
傳統 DNS 查詢是明文的 UDP 53 埠通訊，容易被路徑上的網路裝置識別並竄改結果，這正是「DNS 汙染」的常見成因之一。解法是把 DNS 查詢包裹在加密通道裡：
| 方式 | 全稱 | 特點 |
|---|---|---|
DoH | DNS over HTTPS | 偽裝成一般 HTTPS 流量，抗識別能力強，寫法形如 https://1.1.1.1/dns-query |
DoT | DNS over TLS | 使用獨立的 853 埠加密，特徵比 DoH 明顯一些，寫法形如 tls://8.8.8.8 |
| UDP（傳統） | DNS over UDP | 明文、速度最快，但完全暴露給路徑上的網路，用在你本來就信任的網路（例如你的 ISP 自身 DNS）沒問題 |
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 9.9.9.9
- 208.67.222.222
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.8.8
fallback-filter:
geoip: true
geoip-code: TW思路和進階手冊裡介紹的一致：nameserver 用快速的一般 DNS 保證平時解析速度，fallback 用加密 DNS 保證準確性，fallback-filter 負責判斷什麼時候該切換到 fallback。geoip-code 請填你自己所在的國家/地區代碼——fallback-filter 會用它來判斷解析結果是否不像你所在地區，藉此決定要不要切換到加密 DNS。
依網域分流解析：nameserver-policy
有時候「主要／備援」這種粗粒度的分法不夠用，而是想給特定網域指定專用的 DNS 伺服器——比如公司內網網域必須用內網 DNS 才能解析成功，這時候需要 nameserver-policy：
dns:
nameserver-policy:
'geosite:private': '9.9.9.9'
'+.internal.company.com': '10.0.0.1'
'+.google.com': 'https://1.1.1.1/dns-query'nameserver-policy 的比對優先度高於全域的 nameserver / fallback，可以理解成「針對某幾個網域的例外規則」，非常適合公司內網、自建服務等有專屬解析需求的情境。
內網網域如果被 Fake-IP 接管、又沒有走到正確的內網 DNS，會導致內網服務「看起來能連上，但一直逾時」，遇到這種情況先檢查 nameserver-policy 和 fake-ip-filter 是否把內網網域排除在外。
怎麼驗證解析結果是否正確
光靠「感覺網速慢／連不上」很難判斷問題出在 DNS 還是別處，更可靠的方式是直接查看實際解析到的位址：
- Dashboard 面板：幾乎所有 Clash 用戶端的控制面板都能看到每條連線實際使用的目標 IP，是最直接的排查入口，不需要額外工具。
- 命令列工具：Windows 下用
nslookup 網域，macOS/Linux 下用dig 網域或nslookup 網域，可以比對開啟 Clash 前後同一個網域解析出的 IP 是否一致。 - Fake-IP 模式下的特殊情況：這種模式下系統層面
nslookup拿到的是虛擬 IP（通常落在198.18.0.0/16這個網段），這是正常現象，不代表解析出錯，只有實際發起連線時核心才會去做真正的解析。
判斷「是不是 DNS 汙染」最簡單的辦法：暫時把系統 DNS 或 Clash 的 nameserver 換成一個加密 DNS（比如 DoH），如果同一個網域換了 DNS 之後就能正常存取，基本可以確認是原來的 DNS 被汙染或劫持。
要不要自建 DNS 伺服器
對大多數人來說，用公開的加密 DNS（如 1.1.1.1、8.8.8.8）已經足夠解決汙染問題，不需要自己架一套。但如果你在維護家用閘道、路由器這類需要統一給多台裝置提供解析服務的情境，自建 DNS（比如搭配 AdGuard Home、dnsmasq）會更合適：
- 可以在閘道層統一做廣告過濾和分流解析，不需要每台裝置單獨設定
- 可以自訂本機網域名稱解析（例如給內網裝置取好記的名字），配合 Clash 的
nameserver-policy指向自建 DNS - 可以做請求日誌與統計，方便排查哪些裝置、哪些網域的解析請求異常
如果只是單機日常使用，直接用 Clash 內建的 DNS 模組配好 nameserver / fallback 就完全夠用，自建 DNS 更多是閘道層級使用者才需要考慮的進階選項。
三步排查 DNS 相關問題
- 打開 Dashboard 的連線詳情，確認出問題的連線實際解析到了哪個 IP，判斷是「解析錯了」還是「解析對了但規則沒比對上」。
- 暫時把
enhanced-mode從fake-ip切到redir-host（或反過來）做對比測試，縮小問題範圍。 - 確認
fallback-filter.geoip是否開啟、geoip-code是否填的是你所在地區，這是最容易被忽略的一處細節。
如果以上都排查過依然無法定位，建議參考常見問題裡的連線故障排查清單，或對照進階手冊的 DNS 章節重新檢查一遍完整設定。