進階設定 預計閱讀 14 分鐘

Clash DNS 設定詳解：nameserver、fallback 與 DNS 劫持處理

整理 Clash DNS 請求路徑、主要與備援解析器的分工、fallback 篩選條件，以及常見異常的排查順序。

先確認 DNS 請求實際經過哪裡

Clash 的代理規則負責決定連線走直連、代理或拒絕，但在規則判斷前，通常還有網域解析流程。瀏覽器存取網域時，應用程式可能先呼叫作業系統解析器，也可能透過內建的加密 DNS 直接發起查詢。作業系統解析器接著會將請求交給網卡指定的 DNS、路由器或 Clash 的本機監聽連接埠。只有請求真正進入 Clash DNS 模組，設定中的 nameserver、fallback 與 fake-ip 才會生效。

常見的請求路徑可概括為：應用程式提交網域，系統或 TUN 接管 DNS 查詢，Clash 依策略選擇上游解析器，取得位址後比對代理規則，最後建立直連或代理連線。若應用程式繞過系統解析器，或區域網路裝置仍將 DNS 傳給路由器，修改 Clash 設定就不會改變這些請求的結果。

僅啟用系統代理時，HTTP 與 HTTPS 流量可以進入 Clash，但 DNS 不一定會同步進入。部分瀏覽器會在本機完成解析，部分 SOCKS 用戶端則能將網域交給代理端解析。TUN 模式的涵蓋範圍更大，可透過路由與 DNS 劫持接管不遵循系統代理設定的程式，但仍需處理瀏覽器安全 DNS、虛擬機獨立網路及區域網路其他裝置等例外。

一次查詢涉及的四個層次

  1. 應用層：瀏覽器、命令列工具或其他軟體決定使用系統 DNS、內建 DoH，或將網域交給 SOCKS 代理。
  2. 系統層：作業系統快取、網卡 DNS、VPN 介面優先順序與本機 hosts，都可能在 Clash 之前產生結果。
  3. Clash DNS 層：監聽連接埠、增強模式、主備解析器與網域策略決定查詢方式及回傳內容。
  4. 連線層：Clash 會依網域、目標位址與規則集選擇出站，節點網域本身也可能需要額外解析。

排查時依層次逐步向下，比反覆更換公共 DNS 更有效。尤其要注意快取：瀏覽器、作業系統與 Clash 都可能保存解析結果。修改設定後若立即測試同一網域，舊結果可能掩蓋設定變化。應先重新載入設定，再清理相關快取或等待記錄過期。

dns、default-nameserver 與 nameserver 的職責

以下是一份便於理解的基礎設定。欄位支援情況會隨原版 Clash、Clash Meta（現通常稱為 mihomo）及用戶端整合版本而異，實際使用時應以目前核心文件與設定驗證結果為準。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

enable 與 listen

enable: true 會啟用核心 DNS 模組。listen 指定本機監聽位址與連接埠；監聽 0.0.0.0 表示允許從所有網路介面接收請求，因此在桌面裝置上還應搭配防火牆限制外部存取。若只供本機明確使用，可考慮監聽回環位址。TUN DNS 劫持由核心轉送時，具體監聽方式取決於用戶端與核心實作。

連接埠衝突是設定無法啟動的常見原因。53 連接埠可能已被系統服務、容器工具或其他 DNS 程式佔用，因此桌面用戶端經常使用 1053 等非特權連接埠，再由 TUN 或系統設定將請求導入。未確認佔用情況前，不要同時啟動兩個本機 DNS 服務。

default-nameserver：為上游網域提供引導解析

當 nameserver 使用 DoH 或 DoT 網域時，核心必須先知道這些上游主機的 IP，才能建立加密連線。default-nameserver 主要負責這項引導解析，也常參與代理節點網域的初始解析。為避免「解析 DNS 伺服器還需要先存取同一台 DNS 伺服器」的循環，優先考慮相容性的設定通常會在此填入可直接存取的 IP 位址。

default-nameserver 不是一般網域查詢的主要答案來源。將大量解析器堆進這份清單不會自動提升速度，反而會增加結果差異與排查難度。選擇少量、網路可達且回應穩定的解析器即可。

nameserver：預設主要解析器

nameserver 是一般查詢的主要上游，可使用一般 UDP DNS，也可在核心支援時使用 DoH、DoT 等形式。不同解析器在 CDN 位址、IPv6 記錄及 DNS 污染環境下的表現可能不同。將多個上游放在同一份清單時，核心通常會並行或依內部策略請求，但這不等於按照固定順序逐一備援。

解析器數量不宜過多。上游越多，越容易出現同一網域回傳不同 CDN 位址、故障難以重現，或部分請求繞過預期路徑。設定初期可只保留一個主要解析器和一個獨立備援解析器，確認鏈路穩定後再增加冗餘。

fallback 與 fallback-filter 如何搭配

fallback 並不是單純的「主要伺服器逾時後再詢問備用伺服器」。在經典 Clash 設定語意中，主要解析器與備用解析器可能同時參與查詢，之後由 fallback-filter 判斷目前網域或主要解析結果是否應採用備用答案。因此，理解篩選條件比單純加入備用位址更重要。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.githubusercontent.com"

geoip 與 geoip-code

啟用 geoip 後，核心會根據主要解析結果的位址歸屬，判斷是否採用 fallback 結果。以 geoip-code: CN 為例，主要解析結果不符合指定區域時，可能切換至備用答案。這種方式適合處理部分跨區域解析差異，但依賴 GeoIP 資料庫的準確性。雲端服務、Anycast、CDN 與新分配的位址可能被歸類到預期之外的區域，不能將地理判斷視為絕對結論。

geosite 與 domain

geosite 可依網域集合指定 fallback 傾向，具體集合是否可用取決於核心與規則資料。domain 則適合加入少量需要明確使用備用解析器的網域。帶有 +. 的寫法通常表示比對根網域及其子網域，但不同版本對網域比對格式的相容範圍，仍需透過設定驗證確認。

不建議將大量網站逐一複製進 domain。清單越長，維護成本越高，也容易與 nameserver-policy、規則集或訂閱設定產生衝突。若使用 mihomo，可優先評估依網域指定解析器的策略欄位，讓用途更直觀。

ipcidr

ipcidr 用於將特定位址範圍視為異常或需要 fallback 的結果。例如保留位址區段不應作為一般公網網域的有效回應時，可以加入篩選條件。此欄位應針對明確觀察到的問題使用，而不是從不明來源複製大量網段。篩選範圍過寬，可能讓正常 CDN 位址持續落入備用路徑，增加延遲並造成結果波動。

使用 fallback 時的取捨

mihomo 中更細緻的解析器分工

mihomo 在 Clash 設定體系上擴充了 DNS 控制欄位，常見的包括 nameserver-policy、proxy-server-nameserver 與 direct-nameserver。這些欄位適合解決「業務網域、代理節點網域與直連網域不應共用同一解析路徑」的問題，但並非所有舊版用戶端都能辨識。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.example.net":
      - https://cloudflare-dns.com/dns-query

proxy-server-nameserver 主要用於解析代理節點伺服器本身的網域。節點尚未建立連線時，不能依賴必須經過該節點才能存取的 DNS，否則會形成啟動循環。節點網域解析應選擇目前網路可直接連線的上游。

direct-nameserver 用於直連出站相關的網域解析，可讓直連網站採用更貼近本地網路的答案。是否啟用、何時呼叫及其與規則比對的關係，會受到核心版本與 DNS 設定影響。移轉設定時應檢查執行記錄，而不是只看 YAML 是否能載入。

nameserver-policy 依網域或規則集合指定上游，表達能力比統一的主備架構更直接。例如將本地區域網域交給本地解析器，特定業務網域交給另一組加密解析器。策略之間可能存在覆蓋關係，設定時應先寫出預期矩陣：哪類網域、經由哪個上游、對應什麼出站，再逐項驗證。

fake-ip 與 redir-host 的選擇

enhanced-mode 決定 Clash 如何將 DNS 查詢與後續連線關聯起來。常見模式是 fake-ip 與 redir-host。兩者都用於協助核心保留網域資訊，但運作方式不同。

fake-ip：回傳保留位址並建立網域對應

在 fake-ip 模式下，Clash 會為查詢分配一個保留位址，例如來自 198.18.0.0/16 的位址區段，並記錄該位址與原始網域的對應。應用程式隨後連線至此位址時，流量會被 Clash 接管，核心依對應關係還原網域並執行規則。這通常具備較佳的網域規則命中能力，也能減少先取得真實位址再判斷所產生的歧義。

fake-ip 位址只有在 Clash 接管的鏈路中才有意義。若流量未進入 Clash，系統或其他裝置直接嘗試存取這個保留位址，連線就會失敗。區域網路探索、印表機、遊戲主機、企業驗證、時間同步，以及部分依賴真實 DNS 回應的程式，也可能與 fake-ip 不相容。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
    - "time.*.gov"

fake-ip-filter 中的網域會跳過 fake-ip 回傳方式，改為取得真實位址。篩選項目應從實際故障出發逐步加入。直接使用過大的萬用字元範圍，會削弱 fake-ip 的網域對應優勢，也可能使部分請求在連線前發生本機解析。

redir-host：回傳真實位址

redir-host 模式通常會向用戶端回傳真實 IP，並在連線階段盡量關聯網域。它對依賴真實位址的裝置與程式更友善，但在複雜轉送、連線重用或只剩目標 IP 的情境中，網域規則辨識能力可能不如 fake-ip 穩定。具體行為還會受到 sniffing、TUN 堆疊與核心版本影響。

桌面日常使用可先測試 fake-ip；遇到區域網路服務、企業網路或特定應用程式不相容時，優先加入精確的篩選項目。若問題範圍廣且無法穩定篩選，再評估 redir-host。切換模式後應清理 DNS 快取並重新啟動相關應用程式，因為舊的 fake-ip 記錄不會立即從所有快取層消失。

TUN 模式中的 DNS 劫持處理

這裡的「DNS 劫持」是 TUN 設定中的流量接管功能：將發往指定連接埠的 DNS 請求重新導向至 Clash DNS 模組，而不是指電信業者竄改解析結果。它要解決的是應用程式仍將 DNS 查詢傳送至網卡 DNS 或路由器的問題。

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

any:53 表示接管目標為任意位址、連接埠為 53 的傳統 DNS 請求。不同核心版本也可能支援其他格式。若用戶端圖形介面已自動產生 TUN 設定，不應同時在多個位置重複定義，否則可能出現設定覆蓋或啟動失敗。

傳統 DNS 劫持通常只能涵蓋 UDP 或 TCP 53 連接埠，無法自動攔截瀏覽器直接存取外部 HTTPS 位址的 DoH，也不能將所有 DoT 請求透明改寫。瀏覽器啟用獨立安全 DNS 後，查詢表現可能與系統工具不同。排查時可暫時讓瀏覽器使用系統解析器，確認 Clash 路徑穩定後，再決定是否保留瀏覽器內建設定。

常見的接管失敗情境

旁路由環境還要確認 DHCP 下發的閘道與 DNS。僅將 DNS 位址指向旁路由，不代表所有連線都會經過旁路由；僅將閘道指向旁路由，也不保證終端不會使用自訂的加密 DNS。閘道、DNS、轉送規則與防火牆應視為同一條路徑進行檢查。

解析異常的分步排查順序

DNS 故障的表現相似，但原因可能位於不同層次。以下順序會從設定載入、監聽狀態、上游存取一路檢查到規則與快取，適合處理「網頁無法開啟」、「部分網域逾時」、「啟用 TUN 後無法解析」以及「同一網站的結果反覆變化」等問題。

第一步：確認設定已被目前核心接受

先查看用戶端記錄與設定狀態，確認 YAML 縮排、欄位類型及協定位址沒有錯誤。尤其要注意清單縮排、冒號後的空格、網域規則中的特殊字元，以及舊版核心不支援的新欄位。圖形用戶端可能同時存在訂閱原始設定、覆寫設定與執行時合併設定，應以最終生效的設定為準。

第二步：確認本機 DNS 連接埠正在監聽

檢查設定指定的位址與連接埠是否有程序正在監聽。如果連接埠被其他程式佔用，Clash DNS 模組可能啟動失敗，而代理核心的其他功能仍能運作。此時系統代理看似正常，但依賴網域解析的連線卻會失敗。更換連接埠後，還要同步修改系統 DNS 轉送或 TUN 接管設定。

第三步：分別測試主要解析器與備用解析器

暫時只保留一個 nameserver，關閉複雜的篩選策略，確認一般網域是否能穩定解析。接著單獨測試 fallback 上游。若 DoH 無法連線，請檢查其主機名稱是否能透過 default-nameserver 完成引導解析，以及目前網路是否允許存取相應位址與連接埠。

第四步：檢查節點網域的啟動循環

如果代理節點使用網域，而 DNS 上游又必須透過該節點存取，核心啟動時可能無法解析節點，進而無法建立代理，最後導致 DNS 上游無法連線。處理方式是為節點網域使用目前網路可直接連線的引導解析器，mihomo 使用者也可以核對 proxy-server-nameserver。

第五步：檢查 fallback-filter 是否過於寬鬆

暫時移除 geosite、domain 與大範圍 ipcidr，只保留最小設定。若問題消失，再逐組恢復條件。某個網域頻繁在不同解析結果間變化時，應記錄主要與備用上游各自回傳的位址及篩選判斷，而不是繼續增加備用伺服器。

第六步：確認 fake-ip 流量確實進入 Clash

如果查詢回傳 198.18.0.0/16 類型的位址，表示 fake-ip 正在運作。之後連線失敗通常代表對應流量未被 TUN、透明代理或系統代理正確接管。此時應優先檢查路由與應用程式的代理方式，而不是更換 DNS。若只有個別區域網路或驗證網域異常，可將它們精確加入 fake-ip-filter。

第七步：處理 IPv6 不一致

ipv6: false 通常會限制 Clash DNS 回傳 AAAA 結果，但系統、瀏覽器或其他解析器仍可能取得 IPv6 位址。如果網路存在不完整的 IPv6 連線能力，應用程式可能優先嘗試 IPv6 後逾時。應確認系統 IPv6、Clash DNS 設定、TUN 路由與代理節點能力是否一致，而不是只修改一個開關。

第八步：清理快取並以相同測試條件複查

重新載入設定後，清理瀏覽器與作業系統的 DNS 快取，關閉並重新啟動目標應用程式。測試時固定網路、網域、執行模式與策略群組，避免同時切換多個變數。先驗證 DNS 回應，再驗證 Clash 記錄中的規則命中與出站選擇，最後檢查是否建立連線。

長期穩定的設定不依賴解析器數量，而取決於清楚的職責邊界。建議先建立最小可用架構：一組可直連的引導解析器、一組預設主要解析器，必要時再加入一組 fallback，之後依明確需求加入策略解析與 fake-ip 篩選。

  1. 先確認目前用戶端使用的核心名稱與版本，避免直接套用不支援的欄位。
  2. 讓 default-nameserver 保持精簡，用於解決加密 DNS 與節點網域的引導問題。
  3. 為 nameserver 選擇穩定且可連線的主要上游，不要混入用途不明的位址。
  4. 只有在確實存在解析差異時才啟用 fallback，並為篩選條件記錄原因。
  5. 使用 fake-ip 時維護精簡且精確的篩選清單，定期刪除已不需要的例外項目。
  6. TUN 環境需同步檢查 DNS 接管、路由、IPv6 與瀏覽器內建的安全 DNS。
  7. 每次只修改一組欄位，保留可回復的原始設定，並透過記錄驗證實際路徑。

訂閱提供的設定可能已包含 DNS 區段。用戶端覆寫功能若再次加入同名欄位，最終結果可能是替換、合併或完全忽略，具體取決於用戶端實作。更新訂閱前應確認自訂 DNS 位於獨立覆寫中，還是直接寫入訂閱副本；更新後則檢查最終設定，避免自訂內容被覆蓋。

對多數桌面情境而言，應先解決「請求是否進入 Clash」與「上游是否可達」這兩個問題，再優化 fallback 與策略分流。對於旁路由與多裝置網路，則要額外確認 DHCP、預設閘道、終端自訂 DNS 與 IPv6 出口。將解析路徑畫成從應用程式到上游的流程圖，通常比不斷增加設定欄位更容易定位故障。

下載Clash