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

1. 判斷 DNS 洩漏：先確認哪些查詢應透過代理

網頁的出口 IP 已顯示為代理位址，DNS 查詢仍可能交由本地網路處理。原因很簡單：網頁連線與網域名稱解析是兩條不同的路徑。系統代理通常只會影響遵循代理設定的應用程式，不會自動接管系統送往 UDP 53 埠的查詢；瀏覽器也可能使用自己的加密 DNS。

本文所說的「洩漏」是指：原本應透過代理處理的網域查詢，意外經由本地直連路徑送往解析服務。如果設定本來就要求中國大陸網域使用本地解析，這種直連便是預期行為。測試頁出現兩個解析服務，不代表設定一定失效。

觀察到的情況	代表的意義	下一步
網頁出口 IP 屬於代理節點	該網頁連線經由代理	繼續檢查 DNS 路徑
測試顯示本地電信業者的解析器	可能使用了本地遞迴解析	確認分流策略與封包擷取結果
測試顯示公共 DNS 服務商	該服務商參與了遞迴查詢	不能只憑名稱判斷查詢是否經過代理
查詢結果為 `198.18.x.x`	可能已使用 fake-ip 對應	仍須檢查上游查詢與連線路由

2. DNS 洩漏檢測步驟：基準測試、前後比對與封包擷取

先固定測試條件

記下客戶端名稱、客戶端版本與核心版本。以下設定適用於 mihomo；原版 Clash 與較舊核心不一定支援所有欄位。
記錄目前的代理模式、節點、TUN 開關，以及瀏覽器的安全 DNS 設定。測試期間不要同時更換節點與解析服務。
在相同網路環境下先關閉代理，執行 DNS 檢測並記錄解析器名稱、IP 與網頁出口 IP，作為直連基準。
啟用代理後，在檢測頁重新測試一次。建議使用會產生隨機子網域的檢測功能，以降低快取的影響。
接著啟用 TUN，再以相同方式測試。如果只有開啟 TUN 後結果才改變，請優先確認系統 DNS 是否原本繞過了核心。

清除快取，再檢查本機監聽

Windows 使用者可在終端機執行以下命令。第一個命令會清除系統快取，第二個則直接查詢本文設定的本機 DNS 監聽埠。瀏覽器有自己的快取與連線池，測試時也應完全關閉後重新啟動；只重新整理頁面不一定會觸發新的解析。

ipconfig /flushdns
nslookup example.com 127.0.0.1

後續範例監聽 127.0.0.1:1053，而上方的 nslookup 預設查詢 53 埠，因此只有在本機另有 53 埠轉送時才適用。若要檢查 1053 埠，請使用支援指定埠的工具，例如已安裝的 dig：

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

如果回傳假 IP，表示這次查詢已進入核心 DNS；但這不代表所有應用程式都使用這個入口。還要查看客戶端連線記錄中，目標網域所套用的規則與出站策略。

透過封包擷取確認本地網路路徑

在實際連線的實體網卡上擷取封包，套用篩選條件 udp.port == 53 || tcp.port == 53，再重新執行檢測。如果看到測試用的隨機網域直接送往路由器或電信業者 DNS，且不符合預期的直連策略，就有明確的旁路證據。封包內容可能包含網域等隱私資訊，分享前請先遮蔽。

DoH 通常使用 TCP 443 或 QUIC 443，DoT 通常使用 TCP 853；53 埠沒有流量，不代表沒有 DNS 旁路。加密查詢還須搭配目標解析服務 IP、程序與客戶端連線記錄來判斷。

3. fake-ip、解析策略與 TUN 劫持各自解決什麼問題

機制	實際作用	限制
`fake-ip`	為網域配置假 IP，方便核心還原網域並比對規則	不會自動接管應用程式內建的 DoH
`nameserver-policy`	依網域選擇解析服務	選擇解析器不等於指定代理出站路徑
`respect-rules`	讓 DNS 上游連線依照路由規則處理	若規則符合直連條件，上游連線仍會直連
TUN 的 `dns-hijack`	將經過 TUN 且符合條件的 DNS 流量交由核心處理	無法解密並改寫任意 HTTPS 連線中的 DNS

198.18.0.0/16 是常見的 fake-ip 設定範圍，屬於保留作基準測試用途的位址空間，並非代理節點的實際公網位址。應用程式連線至這些假 IP 時，核心會利用對應資料還原網域，再比對規則並處理連線。

因此，fake-ip 是網域對應機制，不是「所有 DNS 都經過代理」的總開關。要讓設定可靠，必須同時確認三個環節：應用程式將查詢交給誰、核心選擇哪個解析器，以及連線至該解析器時採用哪條路徑。

4. mihomo DNS 設定：先建立可驗證的基本設定

請先備份目前的設定。以下片段可合併至支援這些欄位的 mihomo 設定中，並保留原有節點、策略組與規則；請勿將它當成完整的訂閱檔案匯入。同名的 dns: 區塊只能保留一份，YAML 縮排請使用空格。

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"
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query

逐項確認，不要只看設定是否成功載入

listen 僅綁定本機迴路位址，避免將解析服務開放給區域網路。系統網路設定通常無法填入 DNS 埠 1053；需要透過 TUN 劫持或本機轉送才能接入。
ipv6: false 控制核心 DNS 如何處理 AAAA 查詢，不會關閉作業系統的 IPv6，也無法阻止應用程式透過其他方式取得 IPv6 位址。
default-nameserver 用來解析 DNS 服務本身的網域。此範例保留明文的引導解析入口，因此不能宣稱所有查詢都已加密；使用 IP 格式的 DoH 位址可減少相關的引導解析需求。
proxy-server-nameserver 用來解析代理伺服器的網域，避免出現「必須先連上代理，才能解析代理位址」的循環依賴。範例選用獨立的 DoH 服務，仍須在目前的網路環境確認其連線能力。
respect-rules: true 必須搭配可用的代理伺服器解析設定。還要確認連往 1.1.1.1:443 的連線是否符合預期的代理策略；如果現有規則將它設為直連，查詢仍不會經過代理。

套用設定後，先查看設定檢查結果，再檢查執行記錄。如果出現未知欄位，請先確認實際載入的核心，不要持續對舊核心加入新欄位。客戶端可能會以介面設定覆蓋訂閱中的 DNS 區塊，更新訂閱也可能覆蓋手動修改；請使用客戶端提供的持久覆寫功能，並確認最終生效的設定。

5. nameserver-policy：為區域網路網域指定專用解析器

公司內網、家用 NAS 與路由器管理網域，通常只有本地 DNS 才能解析。若一律交由公共解析服務處理，通常只會導致無法解析，未必更安全。以下範例示範明確指定不同網域的解析方式；只有在路由器實際位址為 192.168.1.1，且能解析這些網域時才適用。

  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.home.arpa":
      - 192.168.1.1

將這段設定加在現有的 dns: 區塊內，與 nameserver 同一層級。此處的兩格縮排有實際作用。+.lan 會比對該網域及其子網域，home.arpa 則是家用網路專用網域。不要只為了讓單一內網服務恢復，就將整個公共網域後綴交給本地解析器。

如果應用程式需要取得內網的實際位址，也應將對應網域加入現有的 fake-ip-filter，例如 "*.home.arpa"。過濾項目只會改變是否回傳假 IP，不會選擇解析器，也不會自動指定直連路由；區域網路網段仍須設定正確的直連規則。

測試時先查詢內網服務，再查詢公共網域。內網查詢直連至路由器是此策略的預期結果，不應與公共網域意外旁路混為一談。

6. TUN DNS 劫持：接管系統查詢與不遵循系統代理的應用程式

只開啟系統代理時，部分應用程式仍會自行發送 DNS 查詢。桌面版 mihomo 客戶端可透過 TUN 擴大接管範圍，通常需要服務模式或系統管理員權限。以下是可搭配前述 DNS 區塊使用的基本設定：

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用來比對經過 TUN 的 UDP DNS，另一條則處理 TCP DNS。關鍵前提是流量確實進入 TUN：其他 VPN、虛擬機橋接、容器網路、IPv6 路由與應用程式排除清單都可能形成另一條路徑。部分系統接管本地網路 DNS 也有平台限制，請以實際封包擷取結果為準。

分別測試瀏覽器的安全 DNS

在 Chrome 中，可前往「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」查看目前選項；不同版本的名稱可能略有不同。排查時先關閉此選項，讓瀏覽器使用系統解析，再驗證 TUN。接著重新開啟，確認瀏覽器連線至解析服務時是否仍符合預期的代理規則。

這並不是要你長期關閉加密 DNS，而是為了排除變因：應用程式內建的 DoH 是一般的加密網路連線，不會因為設定了 53 埠劫持就自動被替換。Android 的「私人 DNS」也須另外確認；通常可在「設定」→「網路和網際網路」→「私人 DNS」找到，實際位置可能因廠牌系統而異。

7. 常見問題與最終檢查清單

啟用 fake-ip 後，印表機或 NAS 無法連線

先確認內網網域由哪個服務解析，再補上精確的 nameserver-policy 與必要的 fake-ip 過濾項目。mDNS 使用 UDP 5353，與一般單播 DNS 是不同機制；只新增 53 埠劫持，無法解決所有 .local 探索問題。

啟用 respect-rules 後，節點網域解析逾時

先檢查 proxy-server-nameserver 是否可連線，以及連線至該解析服務是否又依賴尚未解析成功的代理。必要時可還原備份，先恢復獨立可用的節點網域解析路徑，再逐步收緊 DNS 出站規則。不要直接將問題歸因於節點失效。

檢測結果沒有變化

依序檢查「實際生效設定 → DNS 快取 → 瀏覽器 DoH → TUN 路由 → 規則比對」。如果記錄中完全沒有這次測試網域，請優先檢查查詢入口；如果已有查詢但出站為直連，請檢查規則；如果出站符合預期，只是地理位置標示不同，請確認解析服務的任播與轉送情況。

公共測試網域：新查詢已進入核心，連往解析服務的連線也符合預期出站路徑。
本機實體網卡：未發現違反策略的明文測試網域查詢。
瀏覽器與系統：分別測試安全 DNS 開關，不要只憑單一網頁結果下結論。
區域網路服務：路由器、NAS 與印表機維持可用，預期直連的網域也有明確例外設定。
持久性：重新啟動客戶端並更新訂閱後再次測試，確認覆寫仍然生效。

驗收標準不是「檢測頁只剩一行」，而是每一類查詢都有明確可解釋的入口、解析器與出站路徑。先確認路徑清楚可見，再減少不必要的例外；設定越容易複核，下次網路環境變動時就越容易找出問題。