進階設定 預計閱讀 13 分鐘

Clash DNS 設定詳解：nameserver、fallback 與 DNS 劫持的作用

整理常用 DNS 欄位的處理順序、適用情境與設定界線，協助釐清解析異常和規則比對之間的關係。

先釐清 DNS 解析、代理規則與連線出口

Clash 設定中的 DNS 模組負責將網域名稱解析為位址，並在特定增強模式下保留網域與連線之間的對應關係。代理規則負責判斷請求應進入 DIRECT、REJECT、某個代理節點或策略組，最後則由選定的出口建立連線。這三個部分彼此會互相影響，但並不是同一件事。

例如，瀏覽器存取某個網域名稱時，系統可能會先向本機 DNS 發出查詢。Clash 接管查詢後，會依設定選擇上游解析器，並向瀏覽器回傳真實位址或 Fake IP。接著瀏覽器發起連線，Clash 再結合網域名稱、目標位址、規則順序與目前模式決定出口。單純將某個 DNS 伺服器寫入設定，並不代表所有連線都會經過代理；同樣地，將某條網域規則指定為代理，也不代表應用程式一定會使用 Clash 的 DNS 模組。

排查解析問題時，首先要回答三個問題：DNS 請求是否確實抵達 Clash、Clash 選用了哪個上游解析器，以及解析結果如何參與後續規則比對。若只看到「網頁無法開啟」，很容易將解析失敗、規則誤判、節點無法使用與系統代理未生效混為一談。

一般解析與增強模式的差異

在常見實作中，enhanced-mode可選擇fake-ip或redir-host。Fake IP 模式會向應用程式回傳保留位址範圍內的合成位址，並在核心中保存該位址與原始網域名稱的對應。當應用程式連線至這個合成位址時，Clash 可以還原網域名稱，再執行網域規則與後續解析。這種方式通常有助於保留網域資訊，也能減少應用程式在 Clash 外自行解析，進而造成規則判斷偏差。

Redir-host 模式通常會向應用程式回傳真實解析結果，行為更接近傳統 DNS；但後續連線能否保留完整網域資訊，仍取決於流量入口、嗅探能力、應用程式協定與核心實作。兩種模式沒有脫離情境的固定優劣：區域網路裝置、遊戲、列印服務、需要真實位址的程式，以及某些連線檢查機制，可能需要加入 Fake IP 排除清單；若希望網域規則穩定參與比對，則通常會優先測試 Fake IP。

nameserver 與 default-nameserver 的用途

nameserver是 Clash DNS 模組處理一般網域查詢時使用的主要上游解析器。它可以包含傳統 UDP/TCP DNS，也可以在核心支援時使用 DoH 或 DoT 位址。設定多個上游後，實際的並行、快取與結果選擇行為由核心版本決定，因此不能將清單簡單理解為嚴格依序逐個重試。

default-nameserver主要用於解析 DNS 伺服器本身的網域名稱，也就是引導解析。假設nameserver中填寫了https://dns.example.net/dns-query，Clash 必須先取得dns.example.net的位址，才能建立 DoH 連線。如果引導解析仍依賴這台尚未連線的 DoH 伺服器，就會形成依賴迴圈。為避免這種情況，預設解析器通常會填寫可直接存取、採 IP 形式的 DNS 位址。

這兩個欄位並不是「首選 DNS」與「備用 DNS」的關係。一般查詢主要交由nameserver處理，而default-nameserver負責基礎引導工作。若主要上游使用純 IP 位址，例如223.5.5.5，引導環節不太明顯；一旦使用含主機名稱的 DoH 或 DoT 端點，預設解析器的重要性就會提高。

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
    - 119.29.29.29

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

範例停用了 AAAA 結果處理，但這不等於停用作業系統的 IPv6 功能，也不代表所有應用程式都停止發出 AAAA 查詢。它表示 Clash DNS 模組在此設定下不會向呼叫端提供 IPv6 解析結果。若網路具備穩定的 IPv6 出口，規則與代理節點也完整支援 IPv6，便可重新啟用，並分別驗證直連與代理路徑。

nameserver-policy 的適用範圍

Mihomo 等較新的核心還提供nameserver-policy，允許依網域名稱、規則集或 Geosite 分類指定解析器。它適合處理不同網域需要使用不同解析出口的情況，例如將本地域名交給區域網路 DNS，將特定業務網域交給指定 DoH。策略比對成功時，指定的解析器會覆蓋一般nameserver選擇。

此欄位取決於核心支援與規則資料，遷移設定時應核對用戶端實際使用的核心版本。規則集未載入、分類名稱不受支援，或語法來自其他分支時，可能導致策略未依預期生效。在基礎設定尚未驗證前，不建議一次堆疊過多依網域分流的 DNS 策略。

代理節點的網域名稱也需要解析

若代理伺服器位址填寫的是網域名稱，核心必須先解析節點網域，才能建立與節點的連線。Mihomo 設定中的proxy-server-nameserver可專門處理這類查詢，避免節點網域解析依賴一般業務查詢路徑。若解析節點網域時又嘗試透過該節點存取遠端 DNS，就可能在啟動階段形成循環依賴。

同樣地，支援direct-nameserver的核心可以為直連流量指定解析器。是否需要這些擴充欄位，取決於設定規模與網路環境。對多數入門設定而言，先確保default-nameserver和nameserver正常運作，再逐步拆分節點解析與直連解析，會更容易定位問題。

fallback 不只是故障備援

fallback經常被誤解為「nameserver 逾時後才啟用的備用伺服器」。在經典 Clash DNS 設計中，主要解析器與 fallback 解析器可以並行查詢，再由fallback-filter判斷是否採用 fallback 結果。因此，fallback 更接近另一組候選解析路徑，而不是傳統網路設備中依序切換的備用 DNS。

常見的篩選依據包括 GeoIP、指定網段與網域清單。啟用geoip: true並設定geoip-code: CN時，核心可根據主要解析結果所屬區域，決定是否使用 fallback 候選。domain可以指定一批一律交由 fallback 判斷的網域，ipcidr則可將特定位址範圍視為需要切換結果的條件。

dns:
  enable: true
  enhanced-mode: fake-ip

  default-nameserver:
    - 223.5.5.5

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

  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - +.google.com
      - +.github.com

這個範例呈現的是結果篩選的思路，不代表所有網路都需要照搬。遠端 DoH 或 DoT 端點能否連線，還取決於路由、代理出口、憑證驗證、系統時間與核心對協定的支援。若 fallback 伺服器本身無法存取，再多的篩選規則也不會產生可用結果。

GeoIP 篩選的限制

GeoIP 判斷取決於資料庫內容，而大型網站經常使用 CDN、Anycast 與區域化調度。同一個網域在不同地區可能回傳不同位址，單一位址的地理標籤也無法完整說明它是否適合目前網路。因此，GeoIP 適合作為篩選訊號，不應被視為絕對精準的可用性檢測。

如果業務目標明確，依網域名稱設定解析策略通常比依賴寬泛的 GeoIP 切換更容易說明。例如，區域網路網域應傳送至路由器 DNS，公司內部網域應傳送至企業 DNS，指定的公網服務則使用某個 DoH。此時可優先考慮nameserver-policy，而不是讓所有查詢同時進入兩組解析器，再依結果所在地判斷。

TUN 模式中的 DNS 劫持作用

這裡的「DNS 劫持」是指本機代理核心主動接管進入 TUN 介面的 DNS 請求，而不是修改公共 DNS 記錄。啟用 TUN 後，應用程式流量會進入虛擬網路介面；設定dns-hijack可將傳送至指定位址與連接埠的傳統 DNS 請求轉交給 Clash 內建 DNS 模組處理。如此一來，即使系統仍將 DNS 請求傳送至路由器或其他位址，核心也有機會統一執行 Fake IP、快取與上游選擇。

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

any:53通常表示接管目標為任意位址、連接埠為 53 的 DNS 流量。不同系統、核心版本與 TUN 網路堆疊對 UDP、TCP 以及具體寫法的支援有所差異，應以用戶端產生的有效設定與啟動日誌為準。若只開啟 TUN，卻沒有讓 DNS 請求進入內建解析器，系統可能繼續使用原有 DNS 路徑，Fake IP 與網域規則的效果也會偏離預期。

DNS 劫持無法接管所有加密 DNS

瀏覽器或應用程式可能內建 DoH，透過 HTTPS 的 443 連接埠直接連線至自己的解析服務。這類流量在網路層看起來像一般 HTTPS 連線，對 53 連接埠的劫持不會自動將它轉換為 Clash DNS 查詢。DoT 通常使用 853 連接埠，也不在一般 53 連接埠的接管範圍內。若發現某個瀏覽器與系統解析結果不同，應檢查應用程式是否啟用了獨立的安全 DNS 功能。

即使應用程式內建的 DoH 流量能夠透過代理規則轉送，網域解析仍由應用程式選擇的 DoH 服務完成，而不是直接由 Clash 設定中的nameserver完成。這可能出現兩種情況：應用程式取得真實 IP 後再建立連線，或規則只能依目標 IP 進行比對。若需要統一 DNS 路徑，應同時檢查應用程式設定、系統 DNS 與 TUN 接管範圍。

區域網路與特殊網域需要排除

在 Fake IP 模式下，部分本地域名、裝置探索網域、NTP 服務、遊戲平台連線，以及依賴真實位址的程式，可能需要加入fake-ip-filter。排除的網域通常會回傳真實解析結果，不再分配 Fake IP。應根據實際故障逐項加入，而不是整批排除大量頂級網域，否則會削弱 Fake IP 模式保留網域對應的價值。

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

.local通常與 mDNS 裝置探索有關，實際查詢可能不會經過一般單播 DNS。將它寫入排除清單只能避免分配 Fake IP，不能取代區域網路多播轉送、系統防火牆或裝置探索服務。若區域網路裝置無法存取，還應檢查 TUN 路由、繞過網段與本機介面選擇。

DNS 結果如何影響代理規則比對

Clash 通常會依規則由上到下進行比對。DOMAIN、DOMAIN-SUFFIX 與 RULE-SET 中的網域規則可以直接使用請求網域；IP-CIDR、GEOIP 等規則則需要目標位址。若連線入口只提供 IP，核心能否還原網域名稱，取決於 Fake IP 對應、協定嗅探與連線方式。DNS 設定的其中一個作用，就是盡量讓網域資訊在連線階段仍能供規則使用。

規則中的no-resolve參數表示比對這類 IP 規則時，不要為取得位址而額外觸發 DNS 解析。它可以減少不必要的查詢並避免某些迴圈，但若目前連線沒有目標 IP，該規則也可能無法完成預期判斷。使用時應確認規則前方是否已有網域比對，以及連線入口是否提供真實目標位址。

DNS 伺服器的出口規則同樣重要。DoH 伺服器是 HTTPS 目標，本身也會被 Clash 規則比對。若設定希望某個 DoH 透過代理存取，就要確保代理節點已可連線，並避免節點網域解析依賴這條尚未建立的 DoH 鏈路。若希望本機 DNS 直連，則應確認相關位址不會被寬泛的代理規則誤送至代理組。

快取可能讓修改看起來沒有生效

DNS 結果可能同時存在於瀏覽器、作業系統、Clash 核心與上游解析器的快取中。修改nameserver後立即重新存取，看到舊位址不一定表示設定未載入。應先確認用戶端已完成設定重新載入，再關閉受影響應用程式的現有連線；必要時清除系統 DNS 快取，並等待上游記錄的 TTL 影響消退。

HTTP/2、HTTP/3 與連線池也會重複使用已建立的連線。即使新的 DNS 查詢回傳不同位址，瀏覽器仍可能繼續使用舊連線。排查時可搭配無痕視窗、完全結束應用程式、查看 Clash 連線清單與日誌時間戳，判斷問題發生在新查詢還是舊工作階段。

依處理鏈路排查解析異常

DNS 故障適合從入口到出口逐層檢查。每次只變更一個變數，可以避免多個設定問題相互疊加。以下順序適用於「網域無法開啟但 IP 可連線」、「系統代理正常但 TUN 異常」、「啟用 Fake IP 後個別應用程式失效」等常見情況。

  1. 確認設定已被核心接受。

    先查看 Clash Verge 的設定檢查結果與啟動日誌。YAML 縮排錯誤、欄位拼寫錯誤，或目前核心不支援某個選項時，DNS 模組可能無法依預期啟動。請特別確認監聽位址、增強模式與上游伺服器均已載入。

  2. 確認查詢是否抵達 Clash。

    系統代理只會接管支援代理設定的應用程式流量，不會自動接管作業系統的所有 DNS 請求。若依賴 DNS 劫持，應確認 TUN 已啟用、自動路由有效，並檢查請求是否進入虛擬介面。若只修改 Clash 中的 nameserver，但應用程式仍直接查詢系統 DNS，兩邊的結果就會不同。

  3. 驗證是否能連線至上游。

    傳統 DNS 應檢查 53 連接埠的 UDP 或 TCP 可達性；DoH 應檢查 HTTPS 連線、憑證與系統時間；DoT 則應檢查 853 連接埠與 TLS 握手。採網域形式的上游還要驗證 default-nameserver 能否完成引導解析。

  4. 檢查結果類型。

    在 Fake IP 模式下看到 198.18.0.0/16 這類保留位址通常是預期現象，不應直接判定為解析錯誤。真正需要檢查的是後續連線是否進入 Clash，以及核心能否從 Fake IP 還原原始網域名稱。

  5. 核對規則與 DNS 出口。

    觀察解析器網域或 IP 最後命中的是 DIRECT 還是代理策略組。若遠端 DoH 被分配至無法使用的節點，查詢會逾時；若內部 DNS 被送往公網代理，區域網路網域也可能無法解析。

  6. 精簡設定後逐項恢復。

    暫時保留一組可用的 nameserver，關閉複雜的 fallback 篩選與依網域設定的策略，先驗證基礎解析。接著依序恢復 fallback、nameserver-policy、代理節點專用 DNS 與 Fake IP 排除，每次修改後都查看日誌與查詢結果。

選擇設定方式的簡化原則

  • 只需要統一一般解析時，先設定可靠的default-nameserver與nameserver。
  • 需要保留網域對應並搭配 TUN 時，測試fake-ip與 DNS 劫持，再為特殊網域加入排除項目。
  • 需要篩選兩組候選結果時，再使用fallback與fallback-filter。
  • 需要依業務網域指定解析器時，優先評估核心支援的nameserver-policy。
  • 代理節點位址為網域名稱且啟動解析較複雜時，單獨設定節點網域解析路徑。

穩定的 Clash DNS 設定通常不是欄位越多越好，而是每條解析路徑都能說明來源、出口與使用條件。先建立可運作的基礎鏈路，再依區域網路、IPv6、TUN 與特定應用程式需求擴充，發生異常時才能快速判斷問題位於系統 DNS、Clash 核心、上游解析器還是代理規則。

繼續安裝 Clash Verge

前往下載頁選擇作業系統與架構，或先閱讀完整安裝步驟。

前往下載頁 查看安裝教學
下載Clash