Clash DNS 實際處理了什麼
造訪網站時,應用程式通常會先將網域交給系統 DNS,再使用回傳的 IP 建立連線。若系統已提前完成解析,Clash 可能只能看見目標 IP,網域規則、GeoSite 規則,以及必須透過嗅探才能還原的網域資訊,都可能因此失效。啟用 Clash 內建 DNS 後,解析請求可由同一套代理核心處理,網域、規則比對與出站選擇之間的關係也會更加清楚。
DNS 設定不是單純填入一個公共 DNS 伺服器。一次查詢可能涉及啟動解析器、一般解析器、代理節點網域解析器、備援解析器、網域策略與 TUN 劫持。不同欄位負責不同階段,重複填寫不會自動提高可靠性,反而可能造成解析循環或結果不一致。
一次查詢的主要路徑
- 瀏覽器或應用程式要求解析網域,例如
www.example.com。 - 系統 DNS、TUN 劫持或手動指定的本機連接埠會將查詢交給 Clash。
- 核心會先檢查快取、hosts、fake-ip-filter 與 nameserver-policy。
- 若未命中特定策略,查詢會交給 nameserver;啟用 fallback 時,還會結合 fallback-filter 判斷結果。
- 核心會回傳真實 IP,或在 Fake-IP 模式下回傳
198.18.0.0/16範圍內的對映位址。 - 應用程式發起連線後,Clash 再依據網域規則、IP 規則與代理群組決定出站。
nameserver、default-nameserver 與 proxy-server-nameserver
nameserver:一般網域解析入口
dns.nameserver 是預設解析器清單。未命中 nameserver-policy,且不需要由 fallback 接手時,一般網域會交給這裡的伺服器。它可以使用傳統 UDP DNS,也可以使用 DoH、DoT 等加密協定。UDP DNS 通常填寫 IP 位址,預設連接埠為 53;DoH 使用完整 HTTPS 位址;DoT 通常使用 tls://主機名:853。
dns:
enable: true
listen: 127.0.0.1:1053
nameserver:
- 223.5.5.5
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
同一份清單可以放入多個伺服器,但「多個」不代表會嚴格依序故障轉移。不同核心版本可能會並行查詢,並採用最先回傳或符合條件的結果。若希望中國大陸網域與其他網域固定使用不同解析器,應使用 nameserver-policy,而不要依賴清單順序。
default-nameserver:解析 DNS 伺服器自身的網域
當 nameserver 寫成 https://dns.alidns.com/dns-query 時,核心必須先知道 dns.alidns.com 的 IP,才能建立 HTTPS 連線。default-nameserver 就負責這個啟動階段,也常稱為 bootstrap DNS。這裡優先填寫可直接連線的 IP 型解析器,避免形成「先解析解析器網域」的循環依賴。
dns:
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
default-nameserver 並不是所有網站的強制解析出口。正常啟動後,業務網域仍由 nameserver、fallback 或 nameserver-policy 處理。它產生的查詢次數通常很少,但在網路切換、快取到期或解析器重新建立連線時,仍會再次使用。
proxy-server-nameserver:專門解析節點網域
代理節點位址可能不是固定 IP,而是 node.example.net 這類網域。若解析節點網域也依賴尚未成功建立的代理,就會形成循環:連線代理前需要先解析節點,而解析節點又要求先連線代理。mihomo 提供 proxy-server-nameserver,可將節點伺服器網域交給能夠直接連線的 DNS。
dns:
proxy-server-nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
節點網域解析失敗時,記錄中常見 lookup、no such host、i/o timeout 等訊息。此時即使一般網頁網域能夠解析,代理節點仍可能全部顯示逾時。排查時應分別檢查 nameserver 與 proxy-server-nameserver,不能只靠瀏覽器能否開啟網頁來判斷。
fallback 與 fallback-filter 怎麼設定
fallback 是備援解析器群組,常見用途是篩選不同網路路徑取得的 DNS 結果。它不是「nameserver 逾時後才查詢」的簡單備援清單。經典 Clash 方案經常並行查詢 nameserver 與 fallback,再由 fallback-filter 判斷是否採用備援結果。mihomo 保留了相容寫法,但若要更精確地進行網域分流,通常適合改用 nameserver-policy。
fallback-filter 的四類條件
geoip:啟用根據 IP 地理資料庫進行結果判斷。geoip-code:指定參考地區代碼,例如CN。此邏輯取決於本機 GeoIP 資料是否及時更新。ipcidr:當主要解析結果落入指定網段時,依篩選邏輯選擇 fallback 結果,常用於排除明顯異常的位址區段。domain:指定網域直接使用 fallback 端的結果,支援網域後綴寫法。
dns:
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.githubusercontent.com
這類設定較適合需要區分本地解析與另一組解析結果的網路環境,但不適用於所有地區。若裝置不在中國大陸網路中,仍將 geoip-code 固定為 CN,篩選邏輯可能會與實際連線位置不一致。對於長期移動或跨地區使用的裝置,依網域明確指定解析器通常更容易維護。
nameserver-policy 精確指定網域解析器
mihomo 的 nameserver-policy 可以依網域比對結果指定 DNS。它比「主要解析器加地理位置篩選」更直接:符合規則的網域交給指定伺服器,未符合的網域則回到 nameserver。設定中可以填寫完整網域、網域後綴,也可以在支援 GeoSite 資料的核心中使用 geosite: 進行比對。
dns:
enable: true
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
nameserver-policy:
"geosite:cn":
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
"+.example.cn":
- https://dns.alidns.com/dns-query
"intranet.example.net":
- 192.168.1.1
最後一項展示內網情境:公司或家庭內部網域只能由區域網路 DNS 解析,因此應為該網域單獨指定 192.168.1.1,而不是將區域網路 DNS 放進所有網域共用的 nameserver。如此既能保留內部服務解析,也不會讓所有公網網域都經過路由器。
如果設定引用 geosite:cn,需要確認 GeoSite 資料存在,且格式與核心相容。啟動記錄出現規則集載入失敗、資料庫遺失或 matcher 錯誤時,應先更新核心資料檔案。若要減少對外部資料的依賴,也可以只使用 +.example.com 這類網域後綴規則。
網域策略與代理規則不是同一回事
nameserver-policy 決定「向哪一台 DNS 查詢」,代理規則決定「連線透過哪個出站」。某個網域使用本地 DoH 解析,不代表連線一定是 DIRECT;某個網域透過遠端 DNS 取得結果,也不代表連線一定會走代理。兩套規則應分開檢查,避免將 DNS 選擇誤認為代理群組選擇。
Fake-IP、redir-host 與篩選清單
enhanced-mode 常見值為 fake-ip 和 redir-host。Fake-IP 模式不會急著將真實位址回傳給應用程式,而是先回傳一個對映位址。應用程式連線到該位址後,Clash 能將連線準確還原至原始網域,再套用網域規則。預設對映網段通常使用 198.18.0.1/16,此網段保留供基準測試使用,不屬於一般公網位址。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "+.local"
- "localhost"
- "time.*.com"
- "ntp.*.com"
區域網路裝置探索、印表機、投放、NTP 校時,以及部分依賴真實 IP 的應用程式,可能不適合 Fake-IP。將相關網域加入 fake-ip-filter 後,這些網域會回傳真實解析結果。篩選範圍不應直接擴大到所有常見頂級網域,否則 Fake-IP 在網域識別與分流方面的幫助會明顯降低。
redir-host 會直接將真實 IP 回傳給應用程式,相容路徑較直觀,但連線進入核心後可能只保留 IP 資訊。此時網域規則是否生效,還取決於連線中繼資料、DNS 對映快取與網域嗅探。桌面系統使用 TUN 且規則以網域為主時,可以先測試 Fake-IP;若區域網路服務異常較多,再逐項補充篩選,而不是立即關閉整個模式。
TUN 模式中的 DNS 劫持
只啟用 dns.enable 不代表所有程式都會主動使用 Clash DNS。瀏覽器可能啟用自己的安全 DNS,系統仍可能將 UDP 53 查詢傳給路由器,部分應用程式也可能繞過系統代理。TUN 模式下的 dns-hijack 用於攔截指定連接埠的 DNS 流量,並交由核心處理。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
any:53 會涵蓋一般 UDP 53 查詢,tcp://any:53 則涵蓋使用 TCP 53 的查詢。它們不會自動攔截應用程式直接發出的 DoH 請求,因為 DoH 運作於 HTTPS,通常使用 443 連接埠。若瀏覽器自行指定 DoH,解析請求可能不會進入 Clash DNS;排查時可暫時將瀏覽器安全 DNS 改為「使用系統設定」,再比對記錄。
TUN 啟用後仍需要系統權限。Windows 通常需要核心建立虛擬網卡與路由,macOS 會要求網路延伸功能或 VPN 設定權限,Linux 則需要存取 TUN 裝置並修改路由。記錄出現 permission denied、無法建立介面或新增路由失敗時,應先處理權限問題,不要反覆修改 nameserver。
listen 連接埠怎麼選
listen: 127.0.0.1:1053 適合本機測試,不會直接對區域網路中的其他裝置開放。若必須讓其他裝置使用這台電腦作為 DNS,可以監聽區域網路介面,但還需要設定系統防火牆與固定位址。連接埠 53 可能已被系統解析服務、虛擬機器軟體或其他 DNS 程式佔用;1053、5353 等高位連接埠較適合排錯,但要注意 5353 也可能與 mDNS 服務衝突。
mihomo 建議設定範例
以下是一份適合桌面端入門使用的 mihomo 設定。它採用 Fake-IP、兩台 DoH 解析器、獨立的節點網域解析器與 TUN DNS 劫持。實際 DNS 應依所在網路的可達性調整,不必為了「完整」而保留無法穩定連線的位址。
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
proxy-server-nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
nameserver-policy:
"+.local":
- 192.168.1.1
"+.lan":
- 192.168.1.1
fake-ip-filter:
- "*.lan"
- "+.local"
- "localhost"
- "time.*.com"
- "ntp.*.com"
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
此範例將 ipv6 設為 false,適用於本地 IPv6 路由不穩定或代理節點不支援 IPv6 的情況。如果寬頻、區域網路與節點都能正確處理 IPv6,可以改為 true,並同時檢查規則是否包含 IPv6 位址區段。只開啟 DNS 的 IPv6 回應,卻沒有可用的 IPv6 出站,常見結果是應用程式優先嘗試 AAAA 位址後逾時。
匯入前先複製目前可用的設定。常見桌面客戶端可以從「設定」進入目前訂閱或本機設定的編輯入口;訂閱設定更新時可能會覆蓋手動修改,因此更穩妥的方式是使用客戶端提供的覆寫、擴充設定或 Mixin 功能。儲存後查看核心啟動記錄,確認沒有 YAML 縮排錯誤、未知欄位或連接埠佔用。
確認 DNS 是否依預期運作
第一步:檢查核心記錄
儲存設定並重新啟動核心後,先觀察 30 秒的記錄。應重點搜尋 DNS、lookup、timeout、connection refused、address already in use 與 failed to parse。如果 127.0.0.1:1053 已被佔用,可以先關閉佔用程式,或將 listen 改為尚未使用的連接埠。
第二步:直接查詢本機監聽連接埠
已安裝 dig 的系統可以繞過瀏覽器快取,直接測試 Clash DNS。以下指令會明確指定本機位址與 1053 連接埠:
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA
Fake-IP 模式下,A 記錄可能回傳 198.18.0.0/16 內的位址,這是預期行為。加入 fake-ip-filter 的網域應回傳真實位址。若兩類網域的結果完全相同,應檢查 enhanced-mode 是否生效、設定是否被訂閱覆蓋,以及目前執行的是否為剛編輯的設定。
第三步:比對規則與連線記錄
開啟一個用於測試的網域,確認連線記錄中能看到網域,而不只是目標 IP。接著檢查命中的規則與代理群組。DNS 查詢成功但連線失敗,問題通常已進入節點、路由或規則階段;若 DNS 記錄直接逾時,則應繼續檢查解析器可達性、代理節點網域與防火牆。
第四步:測試切換網路
分別在家用寬頻、手機熱點或其他可用網路上測試,每次切換後等待 10 至 30 秒,讓介面、路由與 DNS 快取完成更新。若只在某個網路失敗,通常表示該網路攔截了特定 DNS 協定、IPv6 路由異常,或 DoH 伺服器無法連線。此時可暫時保留一台 UDP DNS 與一台 DoH 進行比對,而不要一次替換所有參數。
常見錯誤與處理順序
錯誤一:節點全部逾時,但網頁網域能解析
優先檢查 proxy-server-nameserver。節點位址若使用網域,普通 nameserver 正常不代表節點網域一定經由可用路徑解析。還要確認節點網域沒有被 nameserver-policy 指向只能在代理建立後存取的 DNS。
錯誤二:啟用 TUN 後區域網路裝置無法開啟
將路由器、NAS、印表機與投放服務使用的網域加入 fake-ip-filter,並為內部網域設定 nameserver-policy。區域網路常見後綴包括 .lan 與 .local,但實際名稱應以路由器 DHCP 或內部 DNS 設定為準。不要只加入裝置目前的 IP,因為 DHCP 租約更新後位址可能改變。
錯誤三:瀏覽器可以開啟,命令列程式卻失敗
瀏覽器可能使用自己的 DoH,而命令列程式依賴系統 DNS;也可能是瀏覽器使用系統代理,命令列程式只經由 TUN。先關閉瀏覽器獨立的安全 DNS 進行比對,再用 dig 查詢 Clash 監聽的連接埠。若本機查詢正常,繼續檢查系統代理、TUN 路由,以及該命令列程式是否固定指定了解析器。
錯誤四:規則偶爾以 IP 而非網域進行比對
確認 DNS 查詢確實經過 Clash,並檢查 enhanced-mode。若使用 redir-host,可以啟用核心支援的網域嗅探功能,但嗅探並非能還原所有協定的網域。對高度依賴網域規則的桌面環境而言,Fake-IP 搭配合理的篩選清單通常更穩定。
錯誤五:設定更新後手動修改消失
訂閱更新通常會重新寫入設定檔。DNS 自訂項目應放在客戶端的覆寫、擴充腳本或 Mixin 中,或維護獨立的本機設定。編輯前記錄「設定」→「核心」中顯示的實際核心,並在「記錄」中確認載入檔案路徑,避免修改到目前設定未使用的副本。
設定取捨總結
- 一般網域解析放在 nameserver,啟動 DoH 所需的基礎解析放在 default-nameserver。
- 代理節點使用網域時,設定可直接連線的 proxy-server-nameserver,避免循環依賴。
- 固定網域分流優先使用 nameserver-policy;fallback-filter 更適合相容傳統的雙解析器篩選方案。
- TUN 環境使用 dns-hijack 接管 UDP 53 與 TCP 53,但不會自動接管應用程式自行發出的 DoH。
- Fake-IP 有助於保留網域資訊;區域網路、校時與裝置探索異常時,再逐項加入 fake-ip-filter。
- 每次只修改一組參數,重新啟動核心後查看記錄,並透過本機連接埠查詢驗證,避免同時更換 DNS、規則與節點。
一份容易維護的 Clash DNS 設定不需要堆疊大量伺服器。先確認一般網域、節點網域與內部網域分別由誰解析,再決定是否需要 fallback、Fake-IP 與 TUN 劫持。路徑清楚後,解析失敗、規則誤判與區域網路衝突都能從對應欄位開始定位。