Clash DNS 設定欄位解析：nameserver、fallback 與 DNS 劫持

先釐清 DNS 解析、DNS 請求接管與代理分流

Clash DNS 設定需要釐清三件事：由誰解析網域名稱、應用程式的 DNS 請求如何送進核心，以及連線最後經由哪個出口。nameserver 用來選擇上游解析器，tun.dns-hijack 接管符合條件的 DNS 流量，rules 則決定連線的出口。這三者彼此相關，但不能互相取代。

本文主要適用於使用 mihomo 核心的用戶端。舊版 Clash、不同分支及用戶端的設定產生器，支援的欄位可能各不相同；介面中的「DNS 覆寫」也可能取代訂閱中的整個 dns 區段。排查時應檢查用戶端產生並實際交給核心的設定，而不只是訂閱編輯框中的內容。

• 核心 DNS：只有啟用 dns.enable，核心才會依照該區段設定提供解析服務。
• 系統 DNS：作業系統目前使用的解析入口；只開啟 HTTP 系統代理，不代表所有 DNS 請求都會進入核心。
• 代理規則：網域名稱或 IP 符合哪一條規則，決定連線直連或經代理；使用某個地區的 DNS，不等於選擇該地區的代理節點。
• 應用程式內建 DNS：瀏覽器的安全 DNS或應用程式內建的 DoH，可能會繞過系統的傳統 DNS 設定。

此處的「DNS 劫持」是指將指定 DNS 流量重新導向本機核心，並非電信業者竄改解析結果。是否成功接管，必須透過查詢結果與連線記錄驗證。

nameserver 與 default-nameserver：一般解析與引導解析

先建立可單獨測試的 DNS 監聽入口

以下是供合併至既有 mihomo 設定的 DNS 片段，並非包含節點與規則的完整設定。監聽位址限定為本機，使用 1053 埠，避免直接與系統的 53 埠衝突。此時系統不會自動使用這個入口，後續會先透過明確指定伺服器的查詢進行測試。

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

nameserver 是一般網域查詢使用的上游清單，可包含傳統 DNS 位址、DoH（DNS over HTTPS）或核心支援的其他協定。列出兩個位址不代表設定了嚴格的「主要、備用」順序，不應依賴清單順序來實現故障切換。

default-nameserver 主要用來解析 DNS 上游伺服器本身的網域名稱。例如，連線至 https://dns.alidns.com/dns-query 前，必須先取得 dns.alidns.com 的 IP。明確指定 IP 格式的引導解析器，可避免「解析 DNS 伺服器的網域名稱，卻又仰賴該伺服器」的循環依賴。

節點網域解析與 DNS 流量出口要分開檢查

mihomo 的 proxy-server-nameserver 可專門用來解析代理節點伺服器的網域名稱。若節點位址本身無法解析，即使一般網域的 DNS 正常，也無法建立代理連線。啟用 respect-rules，讓 DNS 上游連線遵循路由規則時，更要正確設定節點網域的解析路徑，避免解析器依賴代理，而代理又依賴同一個解析器。

排查時不要一次加入所有進階欄位。先確認所選 DoH 能在目前網路環境中成功連線，再新增依規則選擇出口等設定。DoH 通常使用 TCP 443 埠，但「使用 HTTPS」不代表「會經過代理」，實際連線路徑仍取決於核心設定與路由條件。

fallback 與 fallback-filter：篩選解析結果，而非逾時備援

fallback 常被誤認為只有主要 DNS 逾時時才會使用的備用清單。實際上，核心會搭配 nameserver 與 fallback 進行查詢，再依據 fallback-filter 判斷採用哪一類結果。它既不是代理節點備援群組，也不會確保特定網域經由代理連線。

以下片段示範明確的篩選條件，需合併至前述 dns 區段，不可在檔案中再寫入第二個同名頂層區段。範例停用 GeoIP 篩選，並使用文件範例網段與指定網域說明判斷方式；這些網段並非完整的異常位址清單。

  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/8
      - 192.0.2.0/24
      - 198.51.100.0/24
      - 203.0.113.0/24
    domain:
      - '+.github.com'

若設定 geoip: true 與 geoip-code: CN，意思並非「中國大陸網站直連」，而是依解析 IP 的地理位置判斷是否採用該結果。CDN 位址、地理資料更新狀況與網路出口都可能影響判斷；代理出口仍由規則決定。若要指定特定網域使用固定解析器，通常以 nameserver-policy 設定會比層層疊加地理篩選條件更清楚。

fallback 上游也必須能夠連線。若所選上游在目前網路環境中逾時，強制某些網域使用 fallback 只會擴大故障範圍。應先單獨確認上游可連線，再啟用篩選。

fake-ip 與 redir-host：回傳虛擬位址或真實位址

fake-ip 透過位址映射保留網域名稱資訊

在 fake-ip 模式下，核心可向應用程式回傳 198.18.0.0/16 範圍內的虛擬 IPv4 位址，並保存網域名稱與虛擬位址的對應關係。應用程式接著連線至該位址時，流量必須再次進入同一個核心，核心才能還原網域名稱、比對規則並建立實際連線。此網段屬於保留的網路測試位址空間，並非網站的公網位址。

因此，查詢得到 198.18.x.x 不代表 DNS 遭到污染。真正需要排查的是：DNS 已交由核心處理，但連線卻經由一般路由送出；或切換用戶端、清除映射後，系統仍快取舊的虛擬位址。只接管 DNS，卻沒有接管後續連線，是 fake-ip 無法連線的常見原因。

redir-host 回傳真實 IP，仍須正確接管連線

redir-host 模式通常會回傳上游解析出的真實 IP，不要求應用程式連線至虛擬位址。它與部分仰賴真實位址的程式相容性較佳，但網域名稱與連線的關聯可能受到快取、共用 IP 等因素影響。此模式名稱也不代表必須啟用 Linux 的 REDIRECT 防火牆規則，更不代表會自動完成透明代理。

• 使用 TUN 並希望保留網域規則比對資訊時，可先測試 fake-ip。
• 區域網路探索、特定裝置或遊戲發生相容性問題時，先找出相關網域，再評估設定 fake-ip-filter。
• 在預設的 blacklist 過濾模式下，加入 fake-ip-filter 的網域不會取得虛擬位址；其他過濾模式的作用，請依目前的 mihomo 設定確認。
• 切換增強模式後，請重新啟動受影響的應用程式並清除 DNS 快取，避免混用兩種模式留下的舊結果。

dns.ipv6: false 控制核心 DNS 如何處理 AAAA 查詢，不等於關閉系統所有 IPv6 連線。若瀏覽器使用自己的 DoH，或應用程式已快取 IPv6 位址，仍可能透過其他路徑建立連線。

tun.dns-hijack：接管 53 埠的範圍與限制

dns-hijack 必須寫在 tun 區段內，而非 dns 區段。以下是 mihomo 常見的 TUN 片段；設定會變更路由，操作遠端伺服器前，請先準備好主控台或其他復原方式。桌面用戶端通常透過服務模式或授權輔助程式管理 TUN 權限；不了解權限來源時，不要重複啟動第二個核心。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用來比對進入 TUN 的 UDP 53 DNS 流量，tcp://any:53 則補上 TCP 53。它們不是掃描或攔截整個網路的開關：流量必須先經過 TUN，才能由核心處理。路由排除項、作業系統行為與本機迴圈解析服務，都可能讓部分請求未經此路徑。

• DoH：通常使用 HTTPS 的 443 埠，不會因為設定 any:53 就變成核心 DNS 查詢。
• DoT：通常使用 TLS 的 853 埠，不在傳統 53 埠的接管範圍內。
• Ubuntu 本機解析：127.0.0.53 通常是 systemd-resolved 的本機存根位址；看到它不能直接判定 DNS 未被接管。
• 區域網路裝置：本機啟用 TUN 不會自動接管路由器或其他裝置的 DNS；若要部署為閘道，還需要額外規劃轉送與防火牆。

不要為了解決本機 DNS 問題，就把監聽位址改成 0.0.0.0:53 並開放公網存取。若確實需要服務區域網路，應限制允許連線的網段，並分別檢查 UDP、TCP 防火牆規則。

Ubuntu 排查順序：監聽、查詢、接管、出口

第一步：確認實際設定與監聽程序

純命令列部署時，可針對實際設定目錄執行測試。以下以 /etc/mihomo/config.yaml 為例；若使用桌面用戶端，應檢查用戶端提供的執行中設定，不要以此範例路徑取代實際目錄。

mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
sudo ss -lntup 'sport = :1053'
resolvectl status

設定測試主要用來找出語法與設定問題，不代表上游網路一定可連線。使用 ss 確認 1053 是否由正確的程序監聽；若發生位址已被使用的情況，先找出另一個 DNS 服務，不要貿然停止系統解析服務。

第二步：繞過系統解析器，直接測試核心

Ubuntu 的 dig 來自 dnsutils 套件。先明確指定伺服器位址進行查詢，區分「核心 DNS 本身失效」和「系統請求未進入核心」。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp
dig @127.0.0.1 -p 1053 example.com AAAA

檢查回應狀態、回答紀錄及是否逾時。在 fake-ip 模式下，A 查詢可能只能證明核心能分配虛擬位址，無法充分證明真實上游解析成功；還需搭配實際連線與記錄確認。若設定 dns.ipv6: false，AAAA 查詢沒有位址回覆也不一定是故障。

第三步：驗證系統入口與實際連線

resolvectl query example.com
curl -I --connect-timeout 10 https://example.com
curl -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com

最後一行假設現有設定的 mixed-port 為 7890，並透過明確指定的 HTTP 代理建立 HTTPS 通道；單靠這項測試，無法證明系統 DNS 已被接管。第二行也可能受到環境變數代理影響，比較結果前應先檢查終端機環境。若明確指定代理後可以連線，但一般應用程式仍失敗，應優先檢查系統代理的涵蓋範圍、TUN 路由及應用程式內建 DNS。

第四步：清除快取並逐項還原

sudo resolvectl flush-caches

清除 systemd-resolved 快取後，請關閉並重新開啟瀏覽器；瀏覽器自己的 DNS 快取與既有連線池不一定會隨系統快取一併清除。暫時提高核心記錄層級，觀察 DNS 逾時、節點網域解析失敗及規則比對情況，再恢復原本的記錄層級。記錄中可能包含瀏覽過的網域，分享前請刪除訂閱網址、認證資訊與個人瀏覽紀錄。

常見狀況與最小變更原則

較可靠的調整順序是：先讓一個 DNS 監聽入口可以正常查詢，再確認一個上游可連線，接著確認系統請求與實際連線都進入核心，最後才加入 fallback、依網域解析的策略及 TUN 接管規則。每次只變更一個項目，並記錄修改前後的查詢結果。如此才能判斷問題出在解析、路由還是節點，而非將所有異常都歸咎於「DNS 污染」。

想了解埠號、代理群組與規則之間的整體關係，請繼續閱讀入門指南；確認設定欄位時，可參閱協定參考。本文的 DNS 與 TUN 片段都應合併至既有設定，保留原有節點與規則，切勿用片段覆蓋整份訂閱。