先釐清 DNS 解析、規則分流與流量接管

Clash 已連上節點，部分網站卻無法開啟，原因未必是節點故障。一次連線至少涉及三個環節：將網域名稱解析為 IP 位址、依規則選擇出口，以及將應用程式的連線導入代理核心。DNS 設定主要處理第一個環節；TUN 和系統代理則決定第三個環節。只更改 DNS 位址，並不會自動接管所有應用程式的流量。

本文主要以 mihomo，也就是常說的 Clash Meta 核心為例。原版 Clash、不同分支及各客戶端介面支援的欄位不盡相同。請先在客戶端的核心資訊或啟動記錄中確認實際使用的核心，再套用相符設定；應用程式版本與核心版本並非同一組編號。

  1. 應用程式發出解析請求：可能使用作業系統 DNS，也可能使用瀏覽器內建的安全 DNS。
  2. 核心處理查詢：收到查詢後，依 DNS 設定回傳實際 IP 位址或 fake-ip。
  3. 連線比對規則：網域名稱、目標 IP、處理程序等資訊會用於比對，接著選擇直連或代理策略。

nameserver、default-nameserver 與 fallback 各自的用途

nameserver 是一般網域名稱解析所使用的上游伺服器清單；default-nameserver 主要用來解析 DNS 上游伺服器本身的網域名稱。例如，上游設定為 https://dns.alidns.com/dns-query 時，核心必須先取得 dns.alidns.com 的 IP 位址，才能建立加密連線。這個步驟通常稱為引導解析。

欄位用途常見誤解
enable啟用核心的 DNS 功能。啟用後，仍須讓系統的查詢進入核心。
listen指定 DNS 監聽位址與連接埠。不是 HTTP 或 SOCKS 代理連接埠。
default-nameserver為使用網域名稱的 DNS 上游提供引導解析。並非所有一般查詢的預設優先清單。
nameserver處理一般 DNS 查詢。不代表會嚴格依序切換主要與備用伺服器。
fallback提供另一組解析結果，並搭配篩選條件選擇答案。不是只有主要 DNS 逾時才會使用的備用清單。
fallback-filter決定哪些查詢或主要解析結果需要改用 fallback。不是廣告封鎖器，也不會決定網頁流量使用哪個節點。

常見上游格式包括一般 DNS 的 223.5.5.5、DoT 的 tls://1.1.1.1:853，以及 DoH 的 https://dns.google/dns-query。一般 DNS 通常使用 53 埠，DoT 通常使用 853 埠，DoH 通常使用 HTTPS 的 443 埠。連接埠可連通，不代表服務一定能完成查詢，仍須檢查解析結果與記錄。

加密 DNS 保護的是用戶端到解析服務之間的傳輸。它不會自動確保上游可信，也不會自動隱藏所有網域資訊，更不代表 DNS 請求已經經過代理節點。請先確認目前網路能否連上上游，再評估是否需要依規則代理上游連線。

fake-ip 與 redir-host：依相容性選擇

fake-ip 會回傳由核心管理的虛擬 IP 位址給應用程式，並保存網域名稱與該位址的對應關係。應用程式接著連線至這個位址時，核心便能還原目標網域名稱，再進行規則比對。常用的位址池為 198.18.0.1/16，屬於基準測試用途的位址範圍，並非網站的實際伺服器位址。

redir-host 則會將解析出的實際 IP 位址回傳給應用程式，並盡可能利用已記錄的解析關係判斷網域名稱。如果應用程式自行使用加密 DNS，或連線資訊中只有 IP，核心未必能取得可靠的原始網域名稱。網域嗅探可以補足部分資訊，但無法保證涵蓋所有協定。

  • 優先嘗試 fake-ip：適合希望穩定保留網域分流資訊，且已正確接管流量的桌面環境。
  • 為個別網域設定例外：區域網路裝置探索、依賴實際 IP 的程式或連線測試出現異常時，先調整 fake-ip-filter。
  • 再考慮 redir-host：如果業務程式一直無法相容虛擬位址，可切換模式進行對照測試，不必同時更改所有 DNS 上游。

排除問題時也要注意：對 fake-ip 執行 ping，不能據此判斷遠端網站是否正常。虛擬位址的用途是建立對應並接管連線；真正有參考價值的是應用程式能否建立連線，以及客戶端連線詳細資訊辨識出的網域名稱與最終策略是否正確。

易於理解的 DNS 設定範例

以下範例會啟用本機 DNS，並示範 fake-ip 如何搭配兩組解析上游。服務監聽於 127.0.0.1:1053，僅允許本機存取，避免裝置意外成為區域網路 DNS 服務。1053 不是系統預設 DNS 連接埠；單獨寫入設定後，作業系統不會自動向此連接埠送出查詢。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - localhost
    - "*.lan"
    - "*.local"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 0.0.0.0/32
      - 240.0.0.0/4

套用設定前，先確認三件事

  1. 合併至既有的 dns 區段：同一份 YAML 中不要重複宣告兩個頂層 dns:。同名鍵可能遭覆寫，也可能直接造成解析錯誤。縮排請使用空格，不要使用 Tab。
  2. 確認上游可連線：如果目前網路無法連上 Google 或 Cloudflare 的 DoH，這份 fallback 設定也無法修復網路。請先改用目前環境可連線且可信的上游，或進一步設定 DNS 上游的代理路徑。
  3. 了解 IPv6 設定的範圍：此處的 dns.ipv6: false 是停止 DNS 服務回傳 AAAA 記錄，不等於停用作業系統的 IPv6，也無法單獨阻止應用程式的 IPv6 流量繞過代理。

為 *.local 加入篩選，也不代表已接管裝置探索。常見的 mDNS 使用 UDP 5353 與多點傳播位址，和一般單播 DNS 不同。如果印表機、投影裝置或 NAS 無法被探索，還須檢查 TUN 的區域網路路由、系統防火牆及多點傳播處理。

fallback-filter 如何判斷解析結果

在上述設定中，geoip: true 與 geoip-code: CN 表示：一般解析結果不符合指定地區條件時，改用 fallback 結果。ipcidr 則可補充要排除的位址範圍，例如 0.0.0.0/32。這種判斷依賴 IP 地理資料庫，無法保證每個 CDN 位址都能正確分類。

請特別留意：非 CN 位址不等於遭到污染。合法網站本來就可能部署在其他地區。這是依網路環境設計的結果選擇策略，並非絕對證明解析答案真偽的方式。若網站回傳的是合法位址但連線速度緩慢，應繼續檢查出口規則與 CDN 調度，而不是一味擴大篩選網段。

指定網域使用另一組上游

mihomo 也支援 nameserver-policy。若要讓特定類型的網域固定使用指定 DNS，直接設定解析策略通常比不斷擴充 fallback 條件更清楚。例如，以下局部設定會讓 example.com 及其子網域使用指定的 DoH，其餘查詢仍依一般設定處理。

dns:
  nameserver-policy:
    "+.example.com":
      - https://dns.alidns.com/dns-query

這段範例僅示範策略語法，須合併至原有的 dns 區段。若使用公司內網網域，請填入公司提供的 DNS 位址，並確認透過 VPN 或專線可連線。更換成不同的公共 DNS，無法解析只存在於企業內網的私人記錄。

DNS 上游經代理時，避免形成循環依賴

mihomo 的 respect-rules 可讓 DNS 上游連線遵循路由規則，但啟用時也須妥善設定 proxy-server-nameserver，為代理節點伺服器的網域名稱提供可用的解析服務。否則可能形成「DNS 必須經過節點，節點網域名稱又需要 DNS 解析」的依賴循環。基礎設定尚未正常運作前，不建議同時啟用這些選項。

TUN DNS 劫持：讓系統查詢真正進入核心

只啟用系統代理時，通常是支援代理設定的應用程式將 HTTP 或 SOCKS 連線交給核心處理，作業系統的 DNS 查詢仍可能送往路由器或電信業者的伺服器。TUN 則透過虛擬網卡接管更多 IP 流量，也能將攔截到的 DNS 請求交給核心 DNS 服務處理。

確認客戶端服務模式或所需權限已就緒後，可參考以下 mihomo 局部設定。桌面客戶端經常會自行管理 TUN 欄位；若介面已產生相同設定，請檢查最終生效的設定，避免介面選項與手動覆寫互相覆蓋。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • any:53 用來比對相應的 UDP DNS 請求，tcp://any:53 則補上 TCP DNS。兩者處理的都是進入流量接管路徑的請求。
  • auto-route 負責自動設定相關路由；這可能影響其他 VPN、虛擬機器網路或企業安全軟體，請逐項測試。
  • auto-detect-interface 會嘗試識別出口網卡；在多網卡、熱點分享或複雜 VPN 環境中，仍可能需要明確指定出口。

若不使用 TUN，而是要讓作業系統直接使用本機 DNS，通常需要由服務監聽本機 53 埠，並將系統 DNS 指向該位址。這牽涉連接埠占用、管理員權限與系統解析服務衝突；不能將範例中的 1053 直接填入只接受 IP 位址的系統 DNS 欄位。

依序排查：解析失敗、fake-ip 未生效與 DNS 外洩

第一步：直接查詢核心的監聽連接埠

在安裝了 dig 的 Linux 或 macOS 環境中，先執行以下命令。Windows 也可在具備該工具的終端機環境中進行相同測試；不要將一般 nslookup 預設使用 53 埠的測試，誤認為已驗證 1053 埠。

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

使用 fake-ip 模式時，未命中篩選清單的網域通常會取得 198.18.0.0/16 範圍內的對應位址。如果請求逾時，請先檢查 DNS 功能是否啟用、連接埠是否遭占用，以及設定是否成功載入。請注意，取得 fake-ip 只能證明本機對應查詢正常，不能單獨證明遠端解析或網站連線也正常。

第二步：確認系統與應用程式是否使用同一條路徑

  1. 重新載入設定，確認記錄中沒有未知欄位、YAML 縮排錯誤或連接埠綁定錯誤。
  2. 啟用 TUN 後，使用瀏覽器開啟測試網域，並在客戶端連線詳細資訊中查看網域名稱、命中規則與出口策略。
  3. 暫時關閉瀏覽器安全 DNS，比較前後結果。若關閉後恢復正常，應檢查瀏覽器的 DoH 路徑，而非只修改 fallback。
  4. 逐一排除其他 VPN、手動設定的 DNS 與應用程式內建代理，避免同時存在多條接管路徑。

第三步：清除快取後重新測試

Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 sudo resolvectl flush-caches。macOS 常用命令如下。系統快取、瀏覽器快取與核心的 fake-ip 對應並非同一層；必要時也須重新啟動測試應用程式，或使用客戶端提供的 DNS 快取清除功能。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

從 fake-ip 切換至 redir-host 後，尤其要避免應用程式繼續使用舊的虛擬位址。如果清除了核心對應，但瀏覽器仍快取原本的 fake-ip，連線可能暫時失敗；重新啟動瀏覽器再試，比繼續修改規則更有針對性。

第四步：將「外洩測試」視為線索，而非定論

DNS 測試網站顯示的通常是遞迴解析服務的出口，不一定是本機或代理節點的 IP 位址。解析服務所在區域與節點所在區域不同，也不能直接證明請求繞過了代理。請先確認目標是避免電信業者取得明文查詢、統一應用程式的解析路徑，還是讓特定上游經過代理，再搭配記錄、連線資訊及必要的封包擷取進行判斷。

整理設定：先確認基本功能，再逐項增加策略

穩定的起點是可連線的 DNS 上游、明確的解析模式，以及確實生效的流量接管。先透過本機連接埠查詢確認 DNS 服務，再用應用程式連線測試規則與出口。只有觀察到具體異常時，才新增 fake-ip-filter、nameserver-policy 或 DNS 上游代理策略。

  • 區域網路網域解析失敗：先檢查內網 DNS、mDNS 與路由，不必急著更換公共上游。
  • 只有特定應用程式失敗：先檢查應用程式內建的 DoH、代理設定與 fake-ip 相容性。
  • 所有網域都逾時：先檢查服務監聽狀態、上游連線情形，以及是否形成解析循環。
  • 解析正常但網站無法開啟：改查節點連線、規則比對與目標連接埠，別把所有問題都歸咎於 DNS。

每次只修改一項，並保存修改前後的設定與錯誤記錄。如此才能找出真正有效的調整，也能在訂閱更新、核心升級或網路切換後快速還原。