DNS 設定 閱讀時間約 12 分鐘

Clash DNS 洩漏檢測與 fake-ip 防洩漏設定教學

透過檢測頁面確認 DNS 查詢是否外洩，逐步設定 dns 區段的 enhanced-mode、nameserver 與 fallback，並提供可直接套用的範例。

先釐清 DNS 洩漏的判斷標準

DNS 洩漏是指 DNS 查詢經由非預期的出口送出。例如，原本預期某個網站的連線與網域解析都經過代理，但檢測結果顯示，解析仍由本地網際網路服務供應商（ISP）處理。網頁能正常開啟，不代表 DNS 路徑正確；啟用 fake-ip，也不能直接證明解析不會外洩。

排查時，請分開檢查三個環節：應用程式向誰查詢、Clash 核心如何處理查詢，以及核心透過哪條連線存取上游 DNS。fake-ip 主要改變第二個環節：先向應用程式回傳一個對應位址，核心再依據連線找回網域名稱並執行分流。它不是加密協定，也不會自動接管所有應用程式。

  • 系統代理：主要影響遵循系統代理設定的應用程式，不等於接管系統的所有 DNS 查詢。
  • TUN 模式：可接管更多網路流量，但仍須檢查路由、DNS 劫持、IPv6，以及其他 VPN 的影響。
  • DoH：透過 HTTPS 傳輸 DNS 資料，減少傳輸過程中的明文暴露；直接連線至 DoH 與透過代理存取 DoH，仍是不同的連線路徑。

本文設定適用於 Clash Meta，也就是 mihomo 核心。舊版 Clash 或不同用戶端的覆寫機制，可能不支援相同欄位。修改前，請先在用戶端的「關於」或核心資訊頁面確認核心名稱。

檢測流程：先建立基準，再比較代理前後的結果

第一輪：記錄本地網路使用的解析器

  1. 請在可信任的個人網路中測試，並先關閉其他 VPN，避免多組接管規則彼此疊加。
  2. 關閉 Clash 的系統代理與 TUN。開啟 DNS 洩漏檢測網站，例如 DNSLeakTest，先執行 Standard test，記錄解析器的 IP 位址、營運機構與時間。
  3. 如果平時需要透過代理連線，關閉代理後檢測頁面無法載入，就略過這一輪；不必為了取得基準結果而修改路由器設定。

第二輪：啟用代理後重複檢測

啟用目前使用的設定，確認代理策略已選取可用節點。再次執行相同檢測，再執行 Extended test，觀察是否出現第一輪記錄的本地 ISP 解析器。另開一個網頁確認出口 IP，分別記錄「網頁出口」與「DNS 解析器」，不要把兩者混為同一項指標。

檢測現象可能原因下一步
網頁經代理連線，但解析器仍是本地 ISP系統 DNS 未被接管，或有直連解析規則檢查 TUN、53 埠劫持與實際生效的設定
出現公共 DNS 服務商可能是核心上游，也可能是瀏覽器的安全 DNS比對上游設定，並暫時關閉瀏覽器安全 DNS 後重新測試
解析器位置與節點位置不同公共 DNS 可能使用 Anycast，或採用不同出口綜合機構資訊與連線記錄判斷，不要只看國家標籤
檢測逾時，但快取中的網頁仍能開啟新網域解析失敗，既有連線仍可使用檢查 DoH 連線狀態與代理節點的網域解析

檢測頁面顯示的是為其測試網域執行遞迴查詢的解析器，無法單獨證明所有應用程式都遵循相同路徑。更換瀏覽器、切換網路或啟用其他 VPN，也可能讓結果不同。不要只因單次測試顯示綠色提示就停止排查。

fake-ip 設定：先確認策略群組，再合併 DNS 區段

以下是可合併至現有 mihomo 設定的 DNS 區段，並非完整的訂閱檔案。前提是現有設定包含名為 PROXY 的代理策略群組，而且該群組已選取可用的代理節點，而非 DIRECT。如果實際群組名稱是「節點選擇」，請將兩處 #PROXY 改為 #節點選擇。此處的後綴用來指定上游 DNS 連線所採用的出口策略。

請先備份原有設定，再取代原本頂層的 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
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#PROXY"
  fallback:
    - "https://9.9.9.9/dns-query#PROXY"
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/8
      - 127.0.0.0/8

此範例會明確指定一般業務網域的上游查詢經由 PROXY 傳送，但保留直連的引導解析與節點網域解析。因此，這並不代表「所有 DNS 都會經過代理」。若要避免本地網路看到任何明文 DNS，還需另外設計引導解析路徑，並確認節點在冷啟動時仍能建立連線。

enable、listen 與 enhanced-mode

enable: true會啟用核心 DNS。listen: 127.0.0.1:1053只在本機迴路位址的 1053 埠監聽，避免意外向區域網路開放 DNS 服務。只設定這個位址，不會自動將系統 DNS 指向此處；多數系統的 DNS 設定只能填寫伺服器位址，無法另外指定 1053 埠。

enhanced-mode: fake-ip會啟用映射模式。範例使用的位址池位於 198.18.0.0/16，這是保留供基準測試使用的位址範圍，並非網站實際的公網位址。一般網域查詢若回傳類似 198.18.0.2 的結果，可能是正常情況；此位址僅為格式示例，實際分配的位址不固定。

nameserver 與節點網域解析

nameserver是一般查詢的上游入口。範例使用 IP 格式的 DoH 位址，避免還要先解析上游位址的網域名稱，並以 #PROXY指定代理策略。請保留引號，避免 YAML 將含有特殊字元的內容錯誤解讀。

proxy-server-nameserver用來解析代理節點的伺服器網域名稱。節點連線尚未建立時，不能讓其網域解析依賴同一個節點，否則會形成循環依賴。範例為這個步驟提供直連 DoH；default-nameserver則為需要解析的 DNS 服務網域提供引導解析。這兩者的可見範圍與一般網站網域查詢不同，必須分開評估。

fallback 不只是逾時時的備用伺服器

fallback搭配 fallback-filter用來決定如何取捨查詢結果，不能將它理解為「主要 DNS 逾時後才開始查詢」。依核心的處理方式，兩組上游可能會同時查詢。範例將兩組上游都指定至 PROXY，避免備用上游意外成為直連出口。

此處關閉 GeoIP 篩選，只保留對指定異常位址範圍的結果篩選，避免預設的地理位置判斷改變預期結果。這份精簡清單並非完整的污染辨識方案。fake-ip 回傳映射位址，也不代表每次查詢都會立即觸發所有真實位址解析。如果只需要一個可信任的上游，可以刪除 fallback與 fallback-filter，先簡化連線路徑。

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

準備好 DNS 區段後，還要解決「查詢是否進入核心」的問題。若要在桌面環境接管系統的一般 DNS，請在支援的 mihomo 用戶端中啟用 TUN。以下片段應合併至現有的頂層 tun:；如果用戶端透過介面管理 TUN，請以介面產生的最終設定為準。

TUN 設定片段
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • auto-route會讓核心建立接管流量所需的路由，通常需要系統管理員權限，或由用戶端的系統服務執行。
  • dns-hijack會將已進入 TUN 的一般 UDP、TCP 53 埠查詢交由內部 DNS 處理；它不是能攔截所有 DNS 協定的通用工具。
  • strict-route可限制部分繞過路由的行為，但不同系統上的效果不一，也可能影響區域網路存取或與其他 VPN 的相容性。
  • 瀏覽器 DoH 使用 HTTPS，DoT 通常使用 853 埠，兩者都不同於一般的 53 埠查詢，也需要另外檢查各自的連線路由。

多網卡、虛擬機器、公司 VPN 與旁路由等情境，不建議直接套用自動路由片段。請先確認預設出口網卡，並在記錄中檢查是否出現路由迴圈。如果啟用後整個網路中斷，請先關閉 TUN 恢復網路，再逐項檢查；不要同時修改 DNS、路由與節點設定。

驗證設定：分別檢查埠、映射結果與實際出口

先直接查詢核心的 1053 埠

在已安裝 dig 的 macOS 或 Linux 終端機中執行以下命令。這會直接指定本機核心，不受系統 DNS 目前指向何處影響。Windows 也可以在互動式 nslookup 中設定埠進行測試。

macOS / Linux
dig @127.0.0.1 -p 1053 example.com A
Windows：依序輸入
nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

未符合篩選規則的一般網域，通常會回傳位址池中的 A 記錄。如果逾時，請先檢查核心是否已成功載入、1053 埠是否被占用，以及記錄中是否出現未知欄位的提示。如果直接查詢正常，但系統應用程式仍繞過核心，問題就在流量接管路徑，不必繼續更換上游 DNS。

接著清除快取並觀察連線

  1. 在 Windows 執行 ipconfig /flushdns可清除系統 DNS 快取；瀏覽器也可能保留自己的快取與連線，重新測試前請完全關閉瀏覽器，再重新開啟。
  2. 在 Chrome 的「設定」→「隱私權和安全性」→「安全性」中檢查「使用安全 DNS」。為了排除變數，可以暫時關閉，測試完成後再依自己的策略恢復設定。
  3. 查看用戶端的連線面板，確認連往 1.1.1.1:443、9.9.9.9:443的上游連線是否使用預期的代理。記錄的呈現方式可能不同，不必要求每次查詢都建立新的連線。
  4. 再次執行 DNS 洩漏檢測。先比對解析器所屬機構，再參考出口與記錄綜合判斷，不要只看地圖上的位置。

系統與瀏覽器設定可能受組織政策管理。如果是工作裝置，請先確認管理規範，不要為了完成測試而強行關閉安全政策。一般 DNS 檢測也不等於 WebRTC 檢測；網頁是否暴露本機或公網位址，需另外判斷。

常見問題：IPv6、區域網路與訂閱覆寫

設定 ipv6: false 後，為什麼仍有 IPv6 流量？

DNS 區段中的 ipv6: false主要影響核心如何處理 AAAA 查詢，並不是關閉作業系統 IPv6 的總開關。應用程式快取、寫死的 IPv6 位址、瀏覽器內建解析，或未被接管的網路介面，仍可能產生 IPv6 連線。若需要使用 IPv6，應完整設定並測試流量接管；暫時不使用時，也應一併檢查系統與用戶端設定，而非只修改一個 DNS 欄位。

印表機、NAS 或區域網路網域無法開啟，該怎麼辦？

先確認問題出在網域解析還是路由。fake-ip-filter只會讓符合條件的網域不回傳映射位址，不會自動將這些網域交由路由器 DNS 解析。如果區域網路的實際解析器是 192.168.1.1，可先確認實際網段，再為內部網域設定 nameserver-policy。以下只示範要合併的欄位，請勿再次建立頂層 DNS 區段。

合併至現有 dns 區段
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

此處的內網 DNS 查詢是刻意保留的本地解析，不應與公共網站的意外外洩混為一談。.local常用於 mDNS，不能假設路由器的一般 DNS 一定能解析。如果直接連線至 NAS 的區域網路 IP 也無法使用，請先檢查 TUN 路由與防火牆。

訂閱更新後，為什麼檢測結果又變了？

用戶端可能會重新產生設定，訂閱也可能加入 nameserver-policy、額外的 DNS 上游或其他分流欄位。修改編輯器中的檔案，不代表執行中的核心已套用這些設定。每次更新後，請檢查實際生效設定中的 DNS、TUN 與策略群組名稱，再簡短重測一次。如果使用 respect-rules讓 DNS 依循規則，請另外設計相應規則與節點引導解析；不要和本文明確指定出口的做法混用後，再憑感覺判斷結果。

完成判斷：保留可重複執行的檢查記錄

最後記錄四項資訊：使用的核心與設定、瀏覽器安全 DNS 狀態、代理出口，以及檢測到的解析器所屬機構。合格的結果應符合預先設定的標準：一般業務查詢使用指定的代理上游，必要的本地解析用途明確，節點引導連線路徑也能清楚說明。fake-ip 負責位址映射，TUN 負責接管流量，上游與出口策略則決定解析路徑；三者配合，才能組成可驗證的設定。

下載用戶端