Clash DNS 設定解析：nameserver、fallback 與 dns-hijack 的用途

先釐清 DNS 查詢入口、上游伺服器與結果篩選

排查 Clash DNS 問題時，應沿著查詢流程逐步檢查：應用程式將查詢送往何處、核心是否收到查詢、核心選用哪個上游伺服器，以及最後回傳給應用程式的結果。只修改 nameserver，無法確保瀏覽器的查詢已進入 Clash；啟用 TUN，也不代表應用程式內建的加密 DNS 會被一般連接埠的攔截功能接管。

本文設定以 mihomo 核心為準。舊版 Clash 與不同用戶端支援的欄位及覆寫方式不盡相同。請先在用戶端的核心資訊中確認實際執行的核心，再檢查最終生效的設定。用戶端介面中的開關名稱不能取代 YAML 欄位。

欄位	所在層級	負責處理的問題
`enable / listen`	`dns`	是否啟用內建 DNS，以及接收查詢的位址與連接埠。
`nameserver`	`dns`	一般網域名稱解析所使用的主要上游伺服器。
`fallback`	`dns`	參與備援解析，供篩選邏輯選用的上游伺服器。
`fallback-filter`	`dns`	判斷何時採用 fallback 的解析結果。
`dns-hijack`	`tun`	將 TUN 路徑上符合條件的 DNS 流量交由內建 DNS 處理。

nameserver：核心使用的解析上游伺服器

nameserver 是內建 DNS 使用的主要解析伺服器清單。可填入一般 DNS 位址，也可使用核心支援的 DoH、DoT 位址。這裡填寫的是 DNS 解析服務，不是代理節點；填入節點伺服器位址，通常無法取得有效的 DNS 回應。

從可驗證的最精簡設定開始

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

以下是可合併至現有設定的 DNS 片段，並非完整的代理設定。1053 是內建 DNS 的測試監聽連接埠，與常見的混合代理連接埠 7890 不同。回送位址僅供本機存取，適合先用來驗證解析流程；若要提供 DNS 服務給區域網路裝置，還必須另外考量監聽位址、防火牆與存取範圍。

redir-host 方便檢視實際解析結果，適合本文的初步測試，但不代表必須長期使用此模式。
ipv6: false 是為了簡化本例中 AAAA 記錄的排查，不等於停用作業系統的 IPv6，也不代表封鎖所有 IPv6 連線。
列出多個上游伺服器，不代表一定會依序等待第一個、第二個伺服器，也無法據此判斷每次查詢實際使用了哪個伺服器。

DoH 位址也可能需要先解析

若將上游伺服器改為 https://dns.alidns.com/dns-query，核心首先必須取得 dns.alidns.com 的位址。default-nameserver 用來解析 DNS 伺服器本身的網域名稱，屬於引導解析，並非一般網站使用的預設解析清單。使用不需透過網域名稱引導解析的 IP 位址作為引導伺服器，可減少啟動時的相依循環。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query

DoH 加密的是用戶端與該解析服務之間的 DNS 傳輸，不會自動讓所有應用程式的連線都經過代理。仍須分別確認上游伺服器是否可連線、解析查詢如何送出，以及網站連線會符合哪條規則。

fallback 與 fallback-filter：備援結果不只是故障切換

不宜將 fallback 理解為「第一個 DNS 逾時後才啟用的第二個 DNS」。設定後，核心可以同時向主要與備援上游伺服器發起解析，再依據 fallback-filter 的條件決定採用哪一方的結果。實際查詢次數也會受到快取、解析策略與核心實作影響。

篩選條件可指定網域，也可檢查主要解析結果的 IP。網域符合指定條件時，可直接採用 fallback；IP 條件則用來判斷是否應以備援結果取代主要結果。兩者都不是連線分流規則：選用 fallback 解析，不代表該網站的連線一定會經過代理。

明確指定 IP 條件，避免一開始就加入地區判斷

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8

本例明確停用 GeoIP 篩選，只將兩個位址範圍設為篩選條件：主要上游回傳的位址若符合 0.0.0.0/32 或 127.0.0.0/8，就採用備援解析結果。這是方便理解的範例，並非辨識所有異常 DNS 回應的完整規則。部署前也要確認目前網路確實能連線至兩個備援 DoH 服務。

回送位址也可能是本機開發、廣告封鎖或組織內部政策所預期的結果。因此，不要看到特殊位址就一概認定為錯誤；也不要把整個私有位址範圍都加入篩選，然後期待內網網域仍能維持原本的解析行為。

geoip 與 domain 分別控制什麼

設定 geoip: true 並搭配 geoip-code: CN 時，會依據主要解析結果的 IP 地理位置進行篩選；不屬於指定地區的結果可能改用 fallback。判斷依據是 IP 地理資料，而非網頁內容。
GeoIP 判斷仰賴相應的資料。資料缺漏、過舊，或位址歸屬與實際服務位置不符，都會影響判斷結果；不能把地區判斷當成解析正確的證明。
domain 可列出應採用 fallback 的網域模式，例如 +.example.com。此處的 example.com 是語法範例，實際使用時只加入確有需求的網域。
fallback-filter 不會篩除備援上游回傳的所有不良內容，也不是廣告封鎖清單。

dns-hijack：將 53 埠的查詢交給內建 DNS

設定好上游伺服器後，還需確認應用程式的查詢確實進入核心。在 TUN 模式下，dns-hijack 用來比對經過 TUN 的 DNS 流量，並交由內建 DNS 處理。它解決的是查詢入口問題，不能取代 nameserver，也無法修復原本就無法連線的上游伺服器。

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

此片段要與前面的 dns: 區段並列合併。any:53 用來比對 UDP 53 埠的查詢，tcp://any:53 則補上 TCP DNS。一般 DNS 不只使用 UDP；遇到回應遭截斷後的重試，或部分應用程式的行為時，也可能使用 TCP。

auto-route 用來自動設定流量進入 TUN 的路由，通常需要相應的系統權限。用戶端可能透過服務模式或授權流程啟動核心，具體方式視平台而定。若路由建立失敗，僅看到介面顯示「已啟用 TUN」，不足以確認接管成功。

作業系統平台也會影響接管範圍。傳送至本機網路 DNS、回送位址或特定介面的查詢，可能不會經過預期的 TUN 路徑。尤其是使用路由器位址作為系統 DNS 時，應透過實際查詢與記錄確認，不要將 any 誤解為涵蓋作業系統中的所有 DNS 請求。

Fake-IP 與訂閱覆寫：兩種容易誤判的情況

回傳 198.18 開頭的位址，不一定代表解析異常

使用 enhanced-mode: fake-ip 時，核心可以先回傳映射位址給應用程式，再透過映射關係將網域與後續連線對應起來。常見設定會使用 fake-ip-range: 198.18.0.1/16。看到這個位址範圍時，應先確認目前使用的增強模式，而不是立刻更換 fallback。

Fake-IP 回應不代表核心完全不需要實際解析；後續是否解析及使用哪個上游，仍取決於連線處理方式與策略。fake-ip-filter 用來控制哪些網域不採用 Fake-IP 回應，與篩選上游結果的 fallback-filter 是不同功能。需要真實位址的內網應用程式，應先檢查網域例外與內網解析路徑。

編輯訂閱快取內容，更新後可能會遺失

許多用戶端會將訂閱、本機覆寫與介面設定合併為執行設定。直接編輯從訂閱下載的檔案，下次更新時可能會被覆蓋；同時保留多個 DNS 設定入口，也可能導致最終生效的值不是剛才編輯的那一份。

先備份目前可正常運作的設定，並記錄系統代理與 TUN 的開關狀態。
選用用戶端支援的持久覆寫方式，只保留一個明確的 DNS 設定來源。
重新載入設定後，檢查最終生效的 dns 與 tun 區段，並確認監聽連接埠及縮排層級。
更新一次訂閱，再確認覆寫設定是否仍然存在。不要只測試首次匯入。

驗證順序：先測試內建 DNS，再測試系統接管

若同時更換上游、啟用 Fake-IP 與 TUN，會很難判斷故障來源。建議先使用 redir-host 與 127.0.0.1:1053 驗證解析服務，再逐項恢復實際需要的功能。以下命令僅供檢查，並非本網站網路環境的實測結果。

第一步：檢查設定並直接查詢監聽連接埠

mihomo -t -f config.yaml

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

第一個命令要求本機能直接執行 mihomo，並指定實際使用的設定檔；由用戶端管理的核心則應使用相應的設定檢查方式。後兩個命令適用於已安裝 dig 的系統，分別用來測試 UDP 與 TCP 查詢。請留意 status、ANSWER SECTION 及實際回應，而不只是命令是否正常結束。

在 Windows 上可啟動 nslookup 進入互動模式，再指定連接埠與伺服器。此處必須設定為 DNS 連接埠 1053，不能指向 HTTP/SOCKS 混合代理連接埠。

nslookup
set port=1053
server 127.0.0.1
example.com
exit

第二步：比較直接查詢與系統預設查詢

若直接查詢 1053 逾時，先檢查核心是否已啟動、連接埠是否正在監聽，以及記錄中是否有上游連線錯誤。
若直接查詢正常，但未指定伺服器的 nslookup example.com 失敗，請優先檢查系統 DNS、TUN 路由與攔截範圍。
若命令列查詢正常，只有瀏覽器失敗，請檢查瀏覽器安全 DNS、代理設定與快取。解析正常也不能證明目標網站的 TCP 或 TLS 連線正常。
若剛修改設定仍取得舊結果，請重新載入核心並清除相關應用程式的快取。在 Windows 上可執行 ipconfig /flushdns 清除系統 DNS 快取，但這不會清除核心或瀏覽器各自維護的所有快取。

狀況	優先檢查	不要先做的事
1053 埠沒有回應	`enable`、監聽埠衝突、核心記錄	反覆修改連線分流規則
主要上游可用，但 fallback 逾時	備援服務是否可連線，以及其流量的出站路徑	繼續加入更多無法連線的上游伺服器
只有內網網域解析失敗	內網 DNS、網域指定解析與 Fake-IP 例外	將所有查詢都交給公共 DNS
回傳 Fake-IP，但網頁無法開啟	後續連線是否仍進入同一個核心	僅憑映射位址就認定 DNS 遭污染

最後可將檢查歸納為三個問題：查詢是否進入內建 DNS、上游是否回傳可用結果，以及後續連線是否依預期處理。nameserver 與 fallback 負責解析來源，fallback-filter 負責選擇結果，dns-hijack 負責接管 TUN 查詢入口。依照這些界線逐項修改，才能對應設定變更與故障現象。若要進一步調整策略組與 TUN，請參閱mihomo 進階設定手冊。