Clash DNS 設定教學：nameserver、fallback 與 DNS 劫持參數解析

先確認核心與 DNS 查詢入口

結論是：先讓 DNS 查詢進入 Clash DNS，再決定使用哪個上游解析。只修改 nameserver，不會自動接管系統、瀏覽器和區域網路裝置的所有 DNS 查詢。網頁能開啟，也不代表查詢已經經過這段設定；系統快取、瀏覽器安全 DNS 或應用程式內建的解析功能，都可能繞過設定。

「Clash 用戶端」是操作介面，真正負責解析 YAML 的是核心。原版 Clash、舊版 Premium 核心與 Clash Meta（現名 mihomo）支援的欄位並不完全相同。本文可直接複製的範例以 mihomo 核心為目標；舊版核心請勿直接套用 proxy-server-nameserver 或 TUN 參數。請先在用戶端的「關於」頁面或啟動記錄中確認核心名稱與版本，再依相應核心檢查設定。

1. 先備份目前的設定，並記下原本的 dns、tun 和用戶端 DNS 覆寫設定。
2. 在「設定檔」中確認目前實際啟用的設定檔；若支援訂閱覆寫，請修改可保留的覆寫設定，不要直接改會在下次更新訂閱時被取代的暫存檔。
3. 查看執行中的設定或匯出的合併設定，確認介面上的 DNS 設定沒有覆蓋 YAML。
4. 每次只修改一組參數，重新載入後查看啟動錯誤和解析記錄，再進行下一步。

dns 欄位：如何選擇監聽位址與解析模式

fake-ip 回傳虛擬位址，不代表解析失敗

fake-ip 會為網域指派虛擬位址，並保存網域與位址的對應關係。應用程式連線到這個位址時，核心可以還原網域並比對規則。查詢結果是 198.18.x.x 通常屬於預期情況，請勿直接拿來和公共 DNS 回傳的真實位址比較，也不要因為 ping 不通就認定設定失敗。

redir-host 則以真實解析結果為主，部分依賴真實 IP 的程式會更容易相容，但需要特別留意 DNS 污染與網域資訊的保留。這兩種模式都不會決定流量一定經過代理；解析模式負責網域與位址，連線去向則由規則決定。

listen 不等於系統 DNS 設定

127.0.0.1:1053 只會在本機提供使用非標準連接埠的 DNS 服務。多數系統的 DNS 設定只能填寫 IP，且預設使用 53 埠，無法直接填入這個含連接埠的位址。因此本文會先用查詢指令測試 1053 埠，再設定 TUN 劫持。請勿為了讓其他裝置連線就隨意改成 0.0.0.0:53：這會擴大監聽範圍，也需要檢查連接埠衝突、防火牆與區域網路存取範圍。

nameserver：先用最精簡的設定測試上游

以下是 mihomo 的 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

此處的 default-nameserver 用來解析 dns.alidns.com、doh.pub 這類上游主機名稱；日常查詢則由 nameserver 處理。DoH 使用 HTTPS，常見連線埠為 443，但加密不代表服務永遠連得上，也不保證其回傳結果適用於所有代理出口。

• 不要把清單理解成「第一個故障才改用第二個」：核心可能會同時查詢多個上游，或採用內部選擇策略；清單順序不是可靠的主備優先順序。
• 不要一次填入十多個上游：先使用一至兩個連線正常的服務，發生故障時才更容易確認是哪一端逾時。
• 留意 IPv6 設定的作用範圍：此處的 dns.ipv6: false 會讓 DNS 對 AAAA 查詢回傳空結果，但不代表系統已關閉 IPv6，也不會阻止應用程式連線到已知的 IPv6 位址。

如果代理伺服器本身使用網域名稱，mihomo 也支援 dns.proxy-server-nameserver，用來解析節點伺服器的網域名稱。它不是專門用來解析代理網站的上游。遇到「節點網域解析失敗」時，請先確認這個環節能獨立運作，避免形成「必須連上代理才能解析代理伺服器」的循環相依。

fallback 與 fallback-filter：不是逾時後才啟用的備援

fallback 這個名稱容易讓人誤解。它會與 fallback-filter 配合篩選解析結果，不只是等到 nameserver 逾時後才啟用。設定兩組上游時，兩邊都可能發出查詢；哪些結果會被採用，還取決於過濾條件與核心的實作方式。

以下片段應加入現有的 dns 區段，與 nameserver 同一層。範例關閉 GeoIP 判斷，避免依賴未經確認的地區資料庫，僅示範明確的網域條件與可疑位址過濾。

  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.github.com'

三種過濾條件各自解決什麼問題

• domain：指定網域使用 fallback 的解析結果。範例中的 +.github.com 會比對該網域及其子網域，不會讓網站自動改走代理。
• ipcidr：一般上游回傳的位址符合這些網段時，改採用 fallback 結果。範例將全零位址與回送位址列為可疑結果；若某個內部網域確實需要解析到回送位址，就不應直接照用這項過濾設定。
• geoip 與 geoip-code：啟用 GeoIP 判斷後，可依預期地區判斷是否要取代一般上游的解析結果。常見設定為 geoip: true、geoip-code: CN，但這依賴 GeoIP 資料庫，而且海外 CDN 位址不代表一定遭到污染。

如果主要需求是「特定網域固定使用某個 DNS」，通常應先考慮 nameserver-policy，而不是堆疊複雜的 fallback 條件。它用來指定解析上游；代理出口仍由連線規則決定。

  nameserver-policy:
    '+.cn':
      - https://dns.alidns.com/dns-query
    '+.github.com':
      - https://cloudflare-dns.com/dns-query

這段設定同樣要放在 dns 區段內。符合策略的查詢會使用指定上游，不要再以 fallback 的預設篩選邏輯推斷結果。設定初期可先選擇「策略解析」或「fallback 篩選」其中一種進行測試，確認記錄與結果相符後再組合使用。

dns-hijack：在 TUN 中攔截 53 埠查詢

在 mihomo 中，dns-hijack 位於頂層的 tun 區段，不屬於 dns。它會將進入 TUN 且符合條件的 DNS 流量交給核心的 DNS 模組處理。以下範例需搭配現有的 TUN 設定使用；若用戶端透過介面管理 TUN，請檢查最終執行設定，避免 YAML 被介面設定覆蓋。

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 埠。啟用 TUN 通常需要系統管理員權限或用戶端的服務模式。若現有設定已包含 tun:，請修改其中的欄位，不要再次宣告同名區段。

僅設定 any:53，並不會自動接管以下查詢

• 瀏覽器 DoH：通常使用 HTTPS 443 埠，不符合 53 埠條件。排查時可暫時關閉瀏覽器的「安全 DNS」；Firefox 常見路徑為「設定」→「隱私權與安全性」→「透過 HTTPS 的 DNS」。測試完成後，再依需求恢復設定。
• Android 私人 DNS：嚴格模式通常使用 DoT 853 埠。部分裝置的設定路徑為「設定」→「網路和網際網路」→「私人 DNS」，各廠牌的名稱可能不同，不能將它當作一般 UDP 53 埠流量處理。
• 未進入 TUN 的流量：區域網路直連路由、其他 VPN、特殊網路介面或系統處理路徑，都可能讓流量繞過 TUN。即使系統 DNS 指向路由器，也必須確認這些流量確實有被攔截。

監聽成功、TUN 已啟用、DNS 劫持生效，是三件不同的事。手機還要留意 VpnService 授權及其他 VPN 的衝突；桌上型系統則應檢查服務權限、路由與防火牆。請勿靠反覆更換解析器來解決查詢入口問題。

驗證順序：檢查設定、指定查詢、確認系統入口

第一步：檢查 YAML 與啟動記錄

如果本機可以直接執行 mihomo，請在設定檔所在的目錄執行以下指令。用戶端使用者也可以透過介面提供的設定檢查功能；指令檢查通過只代表設定可以解析，不代表上游一定連得上。

mihomo -t -f config.yaml

出現未知欄位時，先確認核心版本；遇到縮排或重複欄位問題時，先修正檔案。若記錄出現 address already in use，請找出占用 1053 埠的程序，或改用其他測試連接埠；修改上游 URL 無法解決監聽衝突。

第二步：直接查詢本機 1053 埠

在已安裝 dig 的 macOS 或 Linux 環境中，可執行以下三條指令。第一條測試 UDP 查詢，第二條測試 TCP，第三條檢查 AAAA 查詢的結果。

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

Windows 可先使用 nslookup 進入互動模式，再設定測試連接埠。測試完成後輸入 exit 離開。

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

在 fake-ip 模式下，A 記錄回傳虛擬位址是正常現象。若要檢查真實上游的結果，請先備份設定，再暫時切換為 redir-host，重新載入並清除相關快取後比較查詢結果；測試完成後恢復原設定。不要把 fake-ip 的回應時間當成真實上游的網路延遲。

第三步：確認系統預設的解析路徑

確認本機查詢成功後，再啟用 TUN，透過系統預設解析器查詢，同時觀察用戶端記錄。Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。瀏覽器也可能保留自己的快取與連線，請重新啟動瀏覽器或另外清除快取。

日常設定建議：讓解析路徑清楚可查

日常使用可從「一個 DNS 入口、少數可連線的上游、明確的規則模式」開始。需要指定固定解析上游時，再加入 nameserver-policy；確實需要篩選錯誤結果時，再設定 fallback-filter。每增加一層策略，都應清楚知道它會影響哪些網域、上游透過什麼路徑連線，以及發生問題時要在哪裡查看記錄。

DNS 加密可以保護查詢傳送至解析器途中的資料，但並不能隱藏所有連線資訊；DNS 洩漏測試頁面顯示某個解析服務，也不代表所有應用程式的流量都經過相同路徑。若要確認流量是否繞過預期入口，應一併檢查封包、解析記錄與連線記錄，而非只看一次網頁測試結果。

最後記住三者的分工：nameserver 決定向哪個上游查詢，fallback-filter 參與篩選要採用的解析結果，tun.dns-hijack 則決定哪些傳統 DNS 查詢會交由核心處理。分開驗證這三個層面，通常比反覆替換整份「通用 DNS 設定」更快找出問題。其他基本欄位可參閱YAML 手冊；連線與啟動異常則可查看疑難排解。