Clash DNS 實際處理了什麼

造訪網站時,應用程式通常會先將網域交給系統 DNS,再使用回傳的 IP 建立連線。若系統已提前完成解析,Clash 可能只能看見目標 IP,網域規則、GeoSite 規則,以及必須透過嗅探才能還原的網域資訊,都可能因此失效。啟用 Clash 內建 DNS 後,解析請求可由同一套代理核心處理,網域、規則比對與出站選擇之間的關係也會更加清楚。

DNS 設定不是單純填入一個公共 DNS 伺服器。一次查詢可能涉及啟動解析器、一般解析器、代理節點網域解析器、備援解析器、網域策略與 TUN 劫持。不同欄位負責不同階段,重複填寫不會自動提高可靠性,反而可能造成解析循環或結果不一致。

一次查詢的主要路徑

  1. 瀏覽器或應用程式要求解析網域,例如 www.example.com
  2. 系統 DNS、TUN 劫持或手動指定的本機連接埠會將查詢交給 Clash。
  3. 核心會先檢查快取、hosts、fake-ip-filter 與 nameserver-policy。
  4. 若未命中特定策略,查詢會交給 nameserver;啟用 fallback 時,還會結合 fallback-filter 判斷結果。
  5. 核心會回傳真實 IP,或在 Fake-IP 模式下回傳 198.18.0.0/16 範圍內的對映位址。
  6. 應用程式發起連線後,Clash 再依據網域規則、IP 規則與代理群組決定出站。

nameserverdefault-nameserverproxy-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

節點網域解析失敗時,記錄中常見 lookupno such hosti/o timeout 等訊息。此時即使一般網頁網域能夠解析,代理節點仍可能全部顯示逾時。排查時應分別檢查 nameserver 與 proxy-server-nameserver,不能只靠瀏覽器能否開啟網頁來判斷。

fallbackfallback-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-IPredir-host 與篩選清單

enhanced-mode 常見值為 fake-ipredir-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 秒的記錄。應重點搜尋 DNSlookuptimeoutconnection refusedaddress already in usefailed 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 劫持。路徑清楚後,解析失敗、規則誤判與區域網路衝突都能從對應欄位開始定位。