Clash DNS 設定詳解：nameserver、fallback、fake-ip 與 DNS 劫持

先確認核心，再修改 DNS 設定

Clash DNS 設定是否生效，取決於兩件事：目前使用的核心是否支援這些欄位，以及應用程式的 DNS 查詢是否確實進入核心。只把 dns.enable 改成 true，不代表 Windows 上所有應用程式都會改用這組 DNS；開啟系統代理，也不等於自動接管系統的 UDP 53 查詢。

Clash for Windows 已停止維護。它是用戶端介面，實際處理連線的是所使用的核心；傳統 Clash、Clash Premium 與 Clash Meta（現名 mihomo）的功能範圍並不完全相同。本文先說明常見 DNS 欄位，再另外提供 mihomo 的 TUN 範例。請勿將新核心的整段設定直接覆蓋到舊版用戶端。

1. 在用戶端的 General（一般）頁面查看核心資訊；若介面未顯示，請在 Logs（記錄）中檢查啟動記錄。
2. 在 Profiles（設定檔）中確認目前選用的設定檔，並先另存一份副本。訂閱更新可能會覆蓋直接修改的內容。
3. 確認是否啟用了 Mixin 或設定覆寫功能。排除問題時，應檢查最終生效的設定，而不只是訂閱原始檔。
4. 每次只修改一組參數，重新載入後檢查記錄。若出現未知欄位、啟動失敗或監聽失敗，請先還原至上一份可用設定。

DNS 基礎欄位：監聽、上游與引導解析

以下是方便排除問題的 DNS 基礎設定片段，使用 redir-host 回傳實際 IP 位址。這不是完整的訂閱設定，請合併至既有設定的最上層；同一個檔案只保留一個 dns: 區塊，避免重複鍵造成覆寫或解析錯誤。

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

勿混用 1053、53 與 7890

一般 DNS 查詢通常使用連接埠 53。範例使用 1053，方便避免與既有服務衝突，但 Windows 網卡的 DNS 位址欄位通常無法指定這類自訂連接埠。請使用支援指定連接埠的查詢工具測試，或透過 TUN 將 DNS 查詢交給核心處理。代理連接埠（例如 7890）則用於處理 HTTP/SOCKS 等代理連線，不能當作 DNS 連接埠。

DoH 可加密傳輸，但不保證連線可達

https://dns.alidns.com/dns-query 是 DNS over HTTPS 位址。核心必須先取得解析器網域名稱對應的 IP，才能建立 HTTPS 連線，因此需要引導解析。DoH 會加密查詢內容，但伺服器仍看得到送出的查詢；若路由不通、憑證驗證失敗或系統時間錯誤，DNS 查詢仍會失敗。

別為了「更快」一次加入十幾個上游。先保留一至兩個在台灣本地網路或目前網路環境中穩定可用的解析器，確認回應正常後再增加其他設定。此處的位址僅用於示範正確寫法，不保證在任何電信業者網路下都能使用或有理想延遲。

nameserver 與 fallback：依解析結果篩選，不只是逾時備援

fallback 常被理解為「第一台 DNS 斷線後才查第二台」，但 Clash 的這套機制也會搭配 fallback-filter，判斷應採用哪一組結果。設定兩組上游時，核心通常會平行查詢；一般查詢優先考慮 nameserver 的結果，再依篩選條件決定是否採用 fallback 的結果。

以下片段示範傳統的 GeoIP 篩選寫法。請將它合併至上一節的 dns 區塊，不要另外新增第二個最上層的 dns。範例中的 GeoIP 判斷取決於核心實際載入的資料庫。

  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:
      - '+.example.com'

如何理解 fallback-filter 的判斷順序

• domain：符合指定網域條件時，直接優先採用 fallback 的解析結果。此處的 +.example.com 是用來說明語法的保留範例網域；實際設定時請改成確有需要的網域，或刪除此項。
• ipcidr：nameserver 回傳的位址若落在列出的網段內，便視為可改用 fallback 結果的候選情況。240.0.0.0/4 是常見範例，並非完整的異常位址清單。
• geoip：啟用後，會依據 geoip-code 判斷主要結果是否屬於預期地區。設為 CN 時，若主要結果不屬於 CN，就會觸發採用 fallback 結果的邏輯。

可以這樣理解：某個網域經 nameserver 解析後取得資料庫判定為 CN 的位址，且未符合其他篩選條件，通常會保留該結果；若取得非 CN 位址，則改用 fallback 結果。這裡說明的是判斷流程，並非實測紀錄。CDN 位址、資料庫歸屬和查詢結果都可能變動。

另外，將某個 DoH 設為 fallback，不代表它一定會經過代理。DNS 上游的出站方式會受到核心類型、版本及相關設定影響。若目前網路無法直連這組解析器，應先確認可行的連線路徑，不要以「換成海外 DNS」取代問題排查。若沒有明確的篩選需求，先只使用 nameserver，通常更容易找出問題。

fake-ip 與 redir-host：回傳虛擬位址還是實際位址

兩種模式的關鍵差異，在於回覆給應用程式的 DNS 位址。redir-host 通常回傳上游解析出的實際位址，並維護網域與位址的對應關係；fake-ip 則會為網域配置虛擬 IP。核心收到連往該位址的連線後，會透過對應表找回網域，再進行規則比對與出站處理。

fake-ip 基礎設定片段

  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

198.18.0.0/16 屬於專用的基準測試位址範圍，並非目標網站的實際公開 IP。查詢結果若出現 198.18.x.x，不應直接判定為 DNS 污染；在 fake-ip 模式下，這可能正是預期結果。應用程式的連線仍須經過能辨識該對應關係的核心，否則虛擬位址便無法正常用於連線。

fake-ip-filter 可讓符合條件的網域不再取得虛擬位址，但不會自動替網域建立直連規則。將區域網路網域排除後，仍須確保有可解析這些名稱的路徑。特別是 .local 常用於 mDNS，多點傳送探索能否正常運作也取決於系統和區域網路環境，不能只靠加入篩選清單解決。

使用 fake-ip 不代表一定要啟用 TUN；關鍵在於 DNS 結果對應的連線是否會進入核心。反過來說，TUN 也能搭配 redir-host 使用。切換兩種模式後，建議清除系統 DNS 快取並重新啟動受影響的應用程式，避免繼續使用舊的實際位址或虛擬位址。

TUN DNS 劫持：將 53 埠查詢交給核心

TUN 會建立虛擬網路介面，將符合路由條件的 IP 流量導入核心。dns-hijack 則會辨識其中的 DNS 查詢，並交由內建 DNS 模組處理。它不會修改所有 DNS 封包，也不會解密加密流量；查詢必須先進入 TUN，劫持規則才有機會處理。

mihomo 的 UDP 與 TCP 53 範例

以下是 mihomo 常見的欄位組合，須搭配已啟用的 dns 設定使用。請先確認目前核心支援這些選項；舊版 Clash for Windows 隨附的核心不適合直接套用。Windows 上通常還需要用戶端服務或足夠的權限，才能建立介面和路由。

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

• stack: mixed 用來選擇混合協定堆疊，是核心功能選項，並非所有舊版都支援的通用開關。
• auto-route: true 會自動設定相關路由，但不保證涵蓋所有應用程式、網卡，以及其他 VPN 建立的路徑。
• auto-detect-interface: true 會自動判斷出站介面；若有多張網卡或其他虛擬網卡，仍須確認選用的介面是否正確。
• any:53 用於比對 UDP 53 查詢，tcp://any:53 則補上 TCP 53。大型回應或重試情境可能會使用 TCP。

為什麼啟用劫持後，仍可能看到其他 DNS 連線

瀏覽器的「安全 DNS」可能直接連線至 DoH 服務；Android 的「私人 DNS」通常使用 DoT。這些都不是一般的 UDP/TCP 53 查詢，因此不能指望上述兩條規則將它們轉交給核心 DNS。應用程式自行發出的 DoH 查詢，也可能以一般 HTTPS 連線進入代理；但「流量經過代理」和「DNS 查詢交由核心處理」是兩回事。

排查時先暫時關閉瀏覽器的安全 DNS，改用系統解析路徑進行比對，再決定是否恢復。不要只憑單次線上 DNS 測試頁面判斷是否洩漏；頁面顯示的可能是遞迴解析器的出口位址，而非本機或代理節點位址。應綜合連線記錄、實際出口、系統設定和封包擷取結果判斷。

依序驗證：監聽、解析、接管、規則

遇到「啟用 TUN 後無法開啟網頁」時，不要同時更換節點、DNS 和協定堆疊。依照以下順序檢查，可以逐步鎖定問題環節，也能避免將解析失敗誤判為節點故障。

1. 檢查監聽：確認設定已重新載入，且記錄中沒有位址占用或權限錯誤。本文測試連接埠為 127.0.0.1:1053；若實際設定使用其他連接埠，測試命令也要一併修改。
2. 直接查詢核心 DNS：明確指定本機伺服器和連接埠，略過系統預設解析器。若查詢失敗，先檢查上游連線、引導解析及設定語法。
3. 檢查預設路徑：啟用 TUN 後，再使用未指定伺服器的查詢方式測試，並比對核心記錄，確認系統查詢是否已被接管。
4. 檢查實際連線：在用戶端的連線清單中查看目標網域、命中規則、策略組及出站節點。若解析成功但連線逾時，請繼續檢查規則、節點和網路路徑。

Windows 查詢與快取清除

在命令提示字元輸入 nslookup 進入互動模式，再依序執行以下三行。這裡以 example.com 進行基本查詢，範例不預設任何回應內容。

server 127.0.0.1
set port=1053
example.com

離開互動模式後，可執行以下命令清除 Windows DNS 快取。瀏覽器可能另有快取；必要時請完全關閉後重新開啟。

ipconfig /flushdns

macOS 或 Linux 查詢範例

在已安裝 dig 的系統上，可分別測試 UDP 和 TCP。以下兩條命令都會直接查詢本機 1053 埠，不適用於驗證系統預設 DNS 是否已變更。

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

常見問題與設定整理

最後可從四個面向檢查：DNS 監聽可連線、上游可達、應用程式的 DNS 查詢進入預期路徑，以及連線命中正確規則。先逐一確認這四點，再增加 fallback 篩選、fake-ip 例外或更複雜的分域解析。如此既能保留可重現的基準設定，也更容易在訂閱更新或更換用戶端後還原設定。