Clash DNS 設定教學：nameserver、fallback 與 DNS 劫持設定

先釐清 DNS 解析、流量分流與 DNS 劫持

網頁無法開啟，不一定是節點故障。可能是網域解析失敗、解析到錯誤的 IP 位址，或應用程式根本沒有使用用戶端的 DNS。排查前先釐清三個環節：由誰接收 DNS 請求、哪個上游回傳位址，以及後續連線符合哪條代理規則。

• DNS 解析：dns 設定會決定核心向哪些解析器查詢，以及如何處理回傳結果。
• 流量分流：rules 與策略群組會決定連線使用 DIRECT、代理節點或其他出口。DNS 回傳海外 IP，不代表連線就會自動經過代理。
• DNS 劫持：本文指 TUN 核心主動接管指定連接埠的 DNS 流量，並交由內建解析器處理；這與網路業者竄改 DNS 回應並非同一回事。

修改前請匯出目前可用的設定。如果設定來自訂閱，建議使用用戶端提供的覆寫、擴充設定或合併功能；直接修改訂閱產生的檔案，可能會在下次更新時被覆蓋。每次只調整一個環節，重新載入後再確認實際生效的設定。

nameserver 與 default-nameserver 的用途

nameserver 是一般網域查詢使用的上游清單。直接填 IP 通常代表一般 DNS，預設連接埠為 53；https:// 代表 DoH，通常使用 TCP 443；tls:// 代表 DoT，通常使用 TCP 853。加密協定能保護傳送至解析器的查詢，但無法保證解析器始終連線正常，也不能取代連線分流。

上游網域也需要先解析

使用 https://dns.alidns.com/dns-query 時，核心必須先取得 dns.alidns.com 的位址，這就是引導解析的用途。不要把 default-nameserver 當成所有查詢失敗時的備用清單；它和 fallback 的用途不同。

也不要在這裡填入核心本身的監聽位址，例如 127.0.0.1:1053。上游查詢若又回到同一個解析入口，可能形成迴圈。指定其他本機解析服務時，也要確認該服務不會再把請求轉回 Clash。

fallback 不只是逾時時的備用解析器

設定 fallback 後，對符合條件的查詢，核心通常會平行送出主要與備用解析請求，再依據 fallback-filter 判斷採用哪一側的結果。不能把它理解成「等 nameserver 失敗 5 秒後，才開始查詢 fallback」。實際調度也會受到快取、網域策略與核心實作影響。

fallback-filter 如何篩選結果

• geoip: true：啟用 GeoIP 判斷；搭配 geoip-code: CN 時，如果主要解析器回傳的位址不屬於指定地區，就會改用 fallback 的結果。
• ipcidr：如果主要解析結果符合列出的 IP 網段，就改用 fallback。範例中的 240.0.0.0/4 用於辨識不應作為一般公網目的地的保留位址範圍。
• domain：列出的網域會直接採用 fallback 一側的解析策略，適合少數已確認主要解析器不可靠的網域。

GeoIP 判斷仰賴核心可用的地理資料，判斷的是位址所屬區域，並非驗證答案真偽。海外位址可能是正常的 CDN 結果；中國大陸位址也不一定就是正確回應。啟用這項篩選前，請確認地理資料庫可用，並了解它會使更多查詢依賴 fallback 的網路連線狀態。

可合併使用的 mihomo DNS 設定

以下僅列出頂層 dns 區段，不包含節點、訂閱與代理群組。請保留現有可用的出口設定，整段替換原有 DNS 設定，或透過覆寫功能合併；同一個 YAML 檔案不可出現兩個頂層 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
  fake-ip-filter:
    - "*.lan"
    - "+.local"

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  fallback:
    - https://1.1.1.1/dns-query

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

此設定的適用範圍

範例中的公共解析器是具體的設定選擇，不代表在所有網路環境都能直接連線。如果無法連線至 1.1.1.1:443，請先不要啟用這組 fallback 設定。可暫時移除 fallback 與 fallback-filter，確認主要解析正常後，再加入已確認可用的備用解析器。

dns.ipv6: false 會讓內建 DNS 不提供一般 AAAA 解析結果，但不等於關閉作業系統的 IPv6，也不會阻止所有應用程式自行建立 IPv6 連線。若要保留雙堆疊連線，請先確認 IPv6 路由、節點與 TUN 支援狀況，再啟用此設定。

在 Fake-IP 模式下，核心會先回傳 198.18.0.0/16 範圍內的虛擬位址給應用程式，並透過映射保留網域資訊。看到這類位址通常不代表 DNS 污染；實際解析與連線流程仍取決於出口類型和規則。fake-ip-filter 中的網域不會使用虛擬回應，但仍需要合適的真實解析器；加入篩選並不會讓公共 DNS 突然能解析內網主機。

dns-hijack 應設在 TUN 區段，而非 dns 區段

只設定 listen: 127.0.0.1:1053，不會讓系統自動將所有 DNS 請求送到這個連接埠。系統 DNS 設定通常只接受 IP 位址，無法填入自訂的 1053 連接埠。測試時可以指定連接埠；日常使用則需要透過 TUN 接管、系統轉送服務或其他明確的 DNS 接入方式。

以下片段是獨立的頂層 tun 區段，應與 dns 同層。如果用戶端已產生 TUN 設定，只需合併需要的欄位，請勿重複建立同名區段。

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

• any:53 用於接管進入 TUN 的一般 UDP DNS 請求；第二項則補上 TCP 53。
• auto-route 用於自動設定路由，但實際接管範圍仍受系統權限、網路介面與平台實作限制。
• Windows 通常需要用戶端服務或管理員權限；macOS 必須允許相應的網路元件；Android 則通常透過系統 VPN 授權建立接管通道。
• 如果用戶端提供 TUN 開關，請同時確認介面狀態與執行記錄，避免 YAML 設定和介面覆寫互相衝突。

讓 DNS 上游走代理：先處理節點網域的引導解析

使用 DoH 不代表請求必定經過代理。在 mihomo 中，respect-rules 可讓 DNS 上游連線遵循路由規則；啟用後，還須設定 proxy-server-nameserver，用來解析代理節點本身的網域。否則容易形成「連線至 DNS 需要代理，連線至代理又需要 DNS」的依賴迴圈。

dns:
  respect-rules: true
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

這些只是要合併至現有 DNS 區段的新增欄位，並非取代上一節的完整設定。代理節點網域解析器也必須在代理尚未建立時就能使用。啟用後請檢查 rules：如果 DoH 目標仍符合 DIRECT 規則，就會直接連線；如果目標符合代理群組，則還需要確保群組中的節點可用。

為內網網域指定專用解析器

公司網域、NAS 與路由器管理網域通常應交由內網 DNS 解析。可使用 nameserver-policy 指定實際可用的內網解析器，但位址必須依目前網路環境取得，不可照抄其他環境的閘道器。同時請確認 TUN 接管 53 連接埠時，不會再把上游請求送回核心，以免形成迴圈。

如果只有少數固定設備，也可以使用明確的 hosts 對應。不要只為了解析一個內網網域，就把所有公共網域都改由區域網路路由器解析；同樣也不要期待公共 DoH 能解析企業內部專用網域。

分四個步驟驗證，釐清逾時、DNS 污染與接管失敗

步驟一：確認設定是否確實載入

重新載入後查看記錄，先排除 YAML 縮排、欄位型別、連接埠占用與未知設定項目。YAML 請使用空格縮排，不要使用 Tab。如果啟動記錄顯示監聽失敗，先確認 1053 連接埠是否被其他程序占用；如果介面顯示修改成功，但記錄中的行為沒有改變，請確認用戶端是否以訂閱覆寫取代手動設定。

步驟二：直接查詢內建 DNS

macOS 或 Linux 安裝 dig 後，可指定監聽位址與連接埠。第一個指令用來檢查 A 記錄，第二個用來確認 AAAA 查詢行為。在 Fake-IP 模式下，第一個指令若回傳虛擬位址，只能證明本機入口有回應，無法單獨證明 fallback 正常運作。

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

Windows 可進入 nslookup 互動模式並指定連接埠。請逐行輸入下列指令；結束時輸入 exit。

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com

步驟三：確認系統請求是否進入核心

啟用 TUN 後，執行不指定伺服器的系統查詢，並查看核心記錄。如果直接查詢 1053 正常，但系統查詢異常，請優先檢查路由、TUN 授權與應用程式本身的 DNS 設定，而不是繼續更換 nameserver。瀏覽器能開啟網頁也不足以證明設定正常：它可能使用獨立的 DoH 或既有快取。

步驟四：分別檢查解析與連線

選擇一個先前發生異常的網域，檢查 DNS 錯誤、符合的規則與最後使用的出口。需要短時間除錯時，可暫時提高記錄等級，完成後請恢復原設定。分享記錄前，先移除訂閱網址、權杖與節點憑證。更換上游後，請清除相關快取或重新啟動核心，再比較同一網域的首次與再次請求，避免把快取命中誤認為解析器變快。

建議依序調整：先讓單一 nameserver 正常運作，再確認系統 DNS 已接入，接著新增 fallback 篩選，最後處理 DNS 上游的代理路由。每個步驟都能獨立驗證，才能判斷問題出在解析入口、上游傳輸，還是後續連線。