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

先說結論：Android 端應先確認 DNS 查詢確實進入 Clash，再調整解析伺服器。nameserver 是一般解析使用的上游伺服器，fallback 是另一組會參與結果篩選的上游，並非單純「主要伺服器斷線後才啟用」。fake-ip 決定回傳給應用程式的位址形式；DNS 劫持則決定哪些查詢會導入核心。這些功能位於不同層級，不能互相取代。

1. Android DNS 查詢如何進入 Clash

應用程式開啟網域時，通常會先向系統解析器查詢位址，再建立連線。Android 用戶端取得系統 VPN 授權後，可透過虛擬網路介面接收流量；是否同時接管 DNS，還取決於用戶端的 VPN 實作、DNS 設定與應用程式存取控制。

應用程式呼叫系統解析介面，系統便向目前網路指定的 DNS 位址發出查詢。
VPN 介面收到符合接管條件的流量後，用戶端或核心會將 DNS 查詢交給內部解析器。
內部解析器會讀取快取、網域策略與 nameserver 等設定，並在需要時向上游發出查詢。
核心會將真實位址或 Fake IP 回傳給應用程式。應用程式再連線至該位址，由核心依據規則決定直連或透過代理節點連線。

因此，「VPN 已連線」只代表服務已啟動，不代表每個應用程式的 DNS 查詢都已進入核心。未納入 VPN 的應用程式，以及啟用獨立加密 DNS 的瀏覽器，都可能採用不同的連線路徑。排查時，先用一個未排除於 VPN 外的瀏覽器測試，暫時關閉其中的「安全 DNS」，再比對日誌。

DNS 劫持主要接管一般的 53 連接埠查詢

常見的 DNS 劫持會接管 UDP 或 TCP 的 53 連接埠。Android「私人 DNS」的嚴格模式通常使用 DNS over TLS，連接埠為 853；瀏覽器內建的 DNS over HTTPS 則通常使用 443。一般針對 53 連接埠的劫持規則，無法直接將這些查詢轉成核心 DNS 查詢。

「私人 DNS」的設定位置會因系統版本而異，常見路徑是「設定」→「網路和網際網路」→「私人 DNS」；部分裝置則將它放在「連線與分享」中。排查時可先記下原本設定，暫時關閉嚴格模式並重新連線 VPN，確認結果後再決定是否恢復。並非所有裝置都必須關閉這項設定。

2. dns 區段各欄位的用途

欄位	用途與設定重點
`enable`	啟用核心 DNS。用戶端可能會以執行時設定覆寫訂閱中的值。
`listen`	核心 DNS 的監聽位址，不是 HTTP 代理連接埠，也不代表系統 DNS 已被接管。
`default-nameserver`	主要用來解析 DNS 上游伺服器本身的網域，解決啟動時的引導解析問題。
`nameserver`	一般網域查詢使用的上游伺服器清單，也可能被更具體的網域策略覆寫。
`fallback`	備用解析結果來源；會搭配篩選條件選擇結果，不宜視為依序重試的伺服器清單。
`fallback-filter`	設定使用 fallback 結果的條件，例如主要解析結果落在指定網段。
`enhanced-mode`	選擇 fake-ip 或 redir-host，變更回傳位址與網域的關聯方式。
`ipv6`	控制核心如何處理 AAAA 查詢；不等於關閉裝置上的所有 IPv6 流量。

default-nameserver 並非「預設解析所有網站」

例如上游設定為 https://dns.alidns.com/dns-query 時，用戶端必須先取得 dns.alidns.com 的位址，才能連線至這項 HTTPS 服務。引導伺服器就是用來處理這一步。使用 IP 位址形式的引導伺服器，可避免「為了解析 DNS 伺服器，卻又得先連上同一台 DNS 伺服器」的循環。

傳統設定常以一般 IP 位址作為 default-nameserver。不同核心支援此欄位的協定範圍可能不同；移轉舊設定時，建議先保留簡單的寫法。不要把上游伺服器網域解析失敗，誤判為所有代理節點都同時故障。

listen 不要填 7890

7890 常用作 HTTP 或混合代理連接埠，與 DNS 監聽屬於不同服務。以下範例以 127.0.0.1:1053 監聽本機 DNS，避免直接綁定需要特殊權限的低連接埠。Android 用戶端可能自行配置內部連接埠，或不使用這個監聽入口，請以執行時設定為準。只填入 listen，不會自動讓 Android 將查詢送進來。

3. nameserver 與 fallback 的基本設定

以下設定片段用來說明欄位之間的關係，並非適用於所有訂閱的完整設定。範例使用一個一般 DoH 上游、一個 fallback DoH 上游，並關閉 GeoIP 篩選，僅以明確的保留位址範圍示範篩選邏輯。兩項 HTTPS 服務都必須能在目前的網路與路由條件下連線。

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
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 240.0.0.0/4

198.18.0.1/16 是 Fake IP 位址池設定，用來建立網域與虛擬位址的對應，不應填入代理節點位址。
240.0.0.0/4 在此作為異常回應值的篩選範例；它不是完整的異常位址清單，也無法辨識所有錯誤解析。
geoip: false 表示不依 GeoIP 條件挑選 fallback，避免將地理資料庫差異納入這次測試。
ipv6: false 可先縮小排查範圍。若需要 IPv6，請確認節點、網路與接管路徑都支援，再分別啟用並測試。

上游伺服器不是越多越好。伺服器數量增加可能帶來更多查詢，回傳結果也可能不同。先用一組可連線且行為容易判讀的上游建立基準，再加入網域策略或 fallback。加密 DNS 只保護裝置與解析服務之間的查詢傳輸，不代表後續網站連線會自動經過代理。

4. fallback-filter 如何決定採用哪組結果

在經典 Clash 的常見實作中，設定 fallback 後，兩組查詢可能會同時進行。核心會依據篩選條件判斷採用哪組回應，而不是等 nameserver 完全逾時後才開始查詢 fallback。實際的並行、快取與錯誤處理方式，仍應以使用中的核心為準。

三種常見篩選條件

GeoIP：傳統設定常搭配 geoip: true 與 geoip-code: CN，依主要解析結果的 IP 歸屬作為選擇依據。判斷依據是 GeoIP 資料庫中的 IP 地理歸屬，資料庫版本也會影響結果。
IP 網段：ipcidr 可比對主要解析結果中的指定位址範圍。例如命中上方設定的保留網段時，就改用 fallback 結果。
網域：domain 可指定符合條件的網域使用 fallback 結果。比對語法須以核心文件為準，不要直接將代理規則中的整行語法貼入清單。

啟用 GeoIP 篩選後，使用海外 CDN 位址的正常網站也可能觸發 fallback。這只是篩選規則的結果，不足以證明主要解析受到干擾。反過來說，異常回應也可能落在看似正常的位址範圍內。因此，不要將 fallback-filter 當成能自動辨別所有解析真偽的安全檢測工具。

mihomo 的網域策略與節點網域解析

mihomo 提供 nameserver-policy，可為指定網域單獨選擇解析器；另有專門處理代理節點伺服器網域解析的 proxy-server-nameserver。後者有助於將「節點本身的位址解析」與「使用者瀏覽網站的解析」分開排查。這些擴充欄位不應直接套用於舊版 Clash 核心。

# 僅作為 mihomo dns 區段內欄位範例
nameserver-policy:
  '+.example.com':
    - https://dns.alidns.com/dns-query
proxy-server-nameserver:
  - https://dns.alidns.com/dns-query

此處的 example.com 是語法示範網域，不會自動比對你的實際網站。若要依網域指定上游，請填入需要處理的網域，並確認用戶端會保留這些欄位。不要同時修改策略、fallback 與節點解析，否則難以判斷是哪個步驟改變了結果。

5. 如何選擇 fake-ip 與 redir-host

比較項目	fake-ip	redir-host
應用程式收到的位址	核心位址池中的虛擬 IP	上游查詢取得的真實 IP
網域關聯方式	透過虛擬 IP 對應保留網域關係	透過解析記錄等資訊，將網域與真實 IP 關聯
常見注意事項	依賴真實 DNS 位址的應用程式可能需要設定例外	較依賴實際解析結果與位址關聯，可能受到快取影響
排查時的觀察重點	出現 198.18.x.x 不一定是錯誤	收到真實 IP，也不代表連線已經走正確的出口

一般代理瀏覽可先沿用用戶端預設的 fake-ip。應用程式連線至虛擬位址後，核心可以找回對應網域，再依規則決定如何建立實際連線。這不表示每次回傳位址給應用程式前，都必須先解析出目標網站的真實位址；不過實際出口、IP 類規則與特定路由仍可能需要進行解析。

如果只有投放畫面、區域網路探索或特定應用程式發生異常，可考慮使用 fake-ip-filter，讓特定網域不回傳 Fake IP。先確認網域，再新增範圍最小的例外，不要一開始就排除所有網域。不同版本的篩選模式與比對能力可能不同，新增欄位後請查看設定載入日誌。

切換至 redir-host 後，應用程式往往仍保留舊的 DNS 或連線快取。請停止並重新啟動代理服務，徹底關閉測試應用程式後再開啟。對 Fake IP 位址執行 ping，不能用來判斷代理網站是否可用。

6. Android DNS 劫持與 TUN 設定的界線

原版 Clash for Android 的 VPN 流量接管由 Android 用戶端與核心協同實作，不等於將桌面版 TUN 設定原封不動搬到手機。請先在用戶端「設定」中檢查 DNS 覆寫、網路堆疊與應用程式存取控制等選項。不同分支的選單名稱並不一致，不應將某個分支的按鈕位置視為通用路徑。

對於明確支援 mihomo TUN 設定的用戶端，以下是常見欄位格式。這些欄位只用來說明劫持目標，並非可取代 Android 用戶端 VPN 設定的完整方案。

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 可接管常見的 UDP DNS，tcp://any:53 則補上 TCP DNS。是否生效，還取決於流量是否進入該 TUN、用戶端是否允許這些設定，以及是否存在額外的路由排除項。Android 用戶端建立 VPN 介面時，應優先使用其支援的設定方式，不要為了套用範例而重複建立另一套接管設定。

7. 修改後的驗證順序與常見問題

確認設定已載入。儲存後重新載入設定，檢查是否有 YAML 縮排、未知欄位或位址格式錯誤，並確認目前選用的設定檔就是剛才編輯的那一份。
檢查執行時覆寫。如果用戶端提供「覆寫」或「DNS 設定」功能，請核對其中的開關與伺服器清單。修改訂閱檔案，不代表最終執行參數也已變更。
固定測試條件。只使用一個瀏覽器、一種網路與一個節點，並記錄目前使用 Wi-Fi 或行動數據。先停用瀏覽器獨立的 DoH，再造訪一個先前未開啟過的網域。
查看日誌。暫時將日誌層級調高至用戶端支援的除錯等級，查看上游逾時、TLS 錯誤或節點網域解析失敗等記錄。測試完成後請恢復日常等級；分享日誌前，務必隱藏訂閱網址與認證資訊。
每次只修改一項。依序檢查「接管路徑 → 上游連線狀態 → 模式 → fallback 篩選」。網路恢復正常後，再逐項加入個人化設定。

啟用劫持後，所有網站都無法開啟

先檢查 DNS 上游是否逾時。如果上游只能透過代理連線，而代理節點的網域又必須靠該上游解析，就可能形成啟動依賴循環。優先修復可連線的引導解析路徑；若使用 mihomo，再考慮單獨設定節點網域解析。不要只靠反覆切換規則模式來掩蓋問題。

網頁可以開啟，但內網裝置或投放功能失效

檢查內網網域是否必須透過路由器或企業 DNS 才能解析。公共 DNS 通常不知道家用路由器管理的裝置名稱，也無法自動取得企業內網記錄。可依核心支援情況，為這些網域指定本機上游，必要時新增 Fake IP 例外；同時確認區域網路位址沒有被錯誤送進代理。

訂閱更新後，DNS 修改就消失

遠端訂閱通常會以新內容覆寫舊檔案。若用戶端提供持久化覆寫、合併或修補機制，請使用該機制保存 DNS 自訂設定；若沒有這類功能，請先保留本機副本，並確認更新時需要重新合併哪些欄位。不要誤以為暫時編輯的結果已永久生效。

最後，請分開驗證「解析出什麼位址」與「連線從哪裡出去」。前者由 DNS 設定、快取與接管路徑決定；後者還會受到代理規則、策略群組與節點狀態影響。若要核對完整設定結構，請繼續參閱完整文件，避免只修改 DNS，卻忽略規則或網路入口。