網路安全

ClashX DNS 防洩漏檢查清單：從瀏覽器到系統層逐項驗證

📅 2026-02-10 ⏱️ 10 分鐘閱讀 ✍️ ClashX Team

DNS 防洩漏的核心不是「測一次就安心」，而是建立可重現、可追蹤、可回歸的檢查流程。只要代理路徑、系統 DNS、瀏覽器 DNS 任一層沒有對齊，都可能在你以為「已經走代理」時把查詢暴露給本地 ISP 或公司網關。

什麼情況算 DNS 洩漏

很多人把「網站能打開」等同於「沒有 DNS 洩漏」，這是最常見的誤解。 DNS 洩漏關注的是查詢流量是否仍走到不該出現的解析器，而不是 HTTP 是否成功連線。

💡
DNS 洩漏的精確定義

當你啟用 ClashX 代理後，DNS 查詢依然由本地網路（例如家庭寬頻 ISP、公司內網 DNS）直接處理， 而非依照你的代理策略與遠端解析鏈路執行，即可視為 DNS 洩漏。

判讀檢測結果的最小準則

檢測結果 含義
解析器 ASN 顯示為本地 ISP 高機率洩漏，查詢未走代理 DNS 鏈路
解析器國家與代理出口長期不一致 需進一步檢查 ClashX DNS 與瀏覽器 DoH 是否分流
不同檢測站結果差異極大 可能是快取或多介面干擾，先做基線重測
解析器屬於你配置的 DoH/DoT 供應商 通常正常，但仍需比對規則命中與節點出口

常見洩漏指標（任一成立就應進入排查）

  • 切換節點後，檢測站顯示的 DNS 提供商完全不變，且固定為本地 ISP。
  • 只有瀏覽器測試正常，終端應用與系統工具測試異常。
  • 開啟代理時與關閉代理時 DNS 檢測結果幾乎一致。
  • 公司或校園網路下，解析器持續顯示內網 DNS 網段。
  • ClashX 日誌出現 DNS 超時後，系統回退到預設本地解析器。

ClashX 端關鍵設定

若要把 DNS 風險壓到最低，最重要的是讓配置「可預期」。 一份可維護的設定應包含：啟用 DNS、明確 nameserver/fallback、合理 fallback-filter，以及符合場景的 enhanced-mode。

建議基線 YAML

dns:
  enable: true
  ipv6: false
  listen: 127.0.0.1:53
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.google.com'
      - '+.youtube.com'
  fake-ip-filter:
    - '*.lan'
    - 'localhost.ptlogin2.qq.com'
    - '+.stun.*.*'
    - '+.stun.*.*.*'
    - '+.stun.*.*.*.*'
⚠️
常見設定錯誤
  • dns.enable 被註解或誤設為 false，導致系統直接用本地 DNS。
  • 只填 nameserver 不填 fallback，污染或失效時沒有退路。
  • fallback-filter 條件過寬，導致大量查詢落入非預期路徑。
  • 同時在多份 profile 裡維護 DNS 區塊，切換配置時出現行為漂移。
🧭
fake-ip vs redir-host 怎麼選

fake-ip 適合大多數日常情境，命中快且便於規則控制； redir-host 在某些對真實 DNS 解析敏感的應用更相容。 如果你遇到串流 App、企業內網、遊戲反作弊等場景異常，可先保留其餘設定不動，只切換 enhanced-mode 做 A/B 驗證。

系統層檢查

ClashX 設得再完整，若 macOS 系統層仍殘留外部 DNS，最後仍可能繞過你的代理規劃。 這一步的目標是確認「系統正在使用誰解析」。

必跑終端指令

# 檢查目前系統 DNS 詳細狀態
scutil --dns
# 查看 Wi-Fi DNS 伺服器
networksetup -getdnsservers Wi-Fi
# 查看乙太網路 DNS 伺服器（如有）
networksetup -getdnsservers Ethernet
# 檢查當前代理狀態
scutil --proxy

建議檢查步驟

  1. 先確認 ClashX 已「設為系統代理」，並記下當前使用的 profile。
  2. 執行 scutil --dns，觀察 resolver 列表是否混入公司 DNS、路由器 DNS。
  3. 執行 networksetup -getdnsservers，對照每張網卡是否有殘留手動 DNS。
  4. 切換一次節點後重跑指令，確認結果具有一致性。
  5. 清快取後再次測試，排除快取幻象：sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder。
⚠️
多網路介面注意事項

同時開著 Wi-Fi、手機熱點、VPN 虛擬網卡、Docker bridge 時， macOS 可能按服務順序選擇 DNS，導致你在單一測試站看到的結果不穩定。 排查期間建議先保留一個主要介面，其他介面暫時停用，再做基線比對。

瀏覽器 DoH 影響

瀏覽器內建的「安全 DNS」會讓查詢不再遵循系統 DNS 路徑。這不是錯誤，但若你正在檢查 ClashX DNS 洩漏， 它會造成極大干擾，讓你誤判到底是 ClashX 問題還是瀏覽器自帶 DoH 行為。

🔍
DoH 是什麼

DoH（DNS over HTTPS）會把 DNS 查詢包在 HTTPS 內送出，通常能提升隱私與抗污染能力。 但在代理排查期間，DoH 可能繞過你想觀察的系統 DNS 鏈路，因此必須先建立一致的測試前提。

Chrome 設定建議

  1. 進入 chrome://settings/security。
  2. 找到「使用安全 DNS」。
  3. 排查階段先切「關閉」或「使用目前服務供應商」。
  4. 完成基線驗證後，再按需求指定供應商並重測。

Firefox 設定建議

  1. 開啟設定 → 一般 → 網路設定。
  2. 點選「設定...」後找到「啟用 DNS over HTTPS」。
  3. 排查階段先取消勾選，確認系統鏈路正常。
  4. 若需啟用，建議固定同一 DoH 供應商並記錄。

Edge 設定建議

  1. 開啟 edge://settings/privacy。
  2. 在安全性區段找到「使用安全 DNS 指定如何查找網站網路位址」。
  3. 先關閉或改為「使用目前服務提供者」。
  4. 恢復 DoH 後需重做至少兩組 DNS 測試站比對。
⚠️
干擾警告

若你在瀏覽器開了自訂 DoH，同時在 ClashX 也做 DNS 分流， 檢測結果可能顯示「看起來都正常」，但其實是兩條不同 DNS 路徑疊加。 排查時請先統一路徑，再討論最佳化，不要一開始就疊滿所有功能。

驗證記錄模板

防洩漏排查最怕「改了很多但不知道哪一項真的有效」。 建議每次只改一個變數，並用同一模板記錄，確保你可以重現、回退、交接。

可直接複製的驗證模板

=== ClashX DNS 防洩漏驗證記錄 ===
日期時間：
macOS 版本：
ClashX 版本：
配置檔名稱：
代理模式：Rule / Global / Direct
enhanced-mode：fake-ip / redir-host
[系統層]
scutil --dns 摘要：
networksetup -getdnsservers Wi-Fi：
目前系統代理（scutil --proxy）：
[瀏覽器層]
Chrome 安全 DNS：開 / 關 / 供應商
Firefox DoH：開 / 關 / 供應商
Edge 安全 DNS：開 / 關 / 供應商
[檢測結果]
測試站 A（時間/解析器 ASN/國家）：
測試站 B（時間/解析器 ASN/國家）：
出口節點國家：
是否符合預期：是 / 否
[本次只改動一項]
改動內容：
回退方式：
下一步：
===============================

推薦驗證工具（交叉比對）

BrowserLeaks
DNS
DNSLeakTest
標準測試
ipleak.net
IP+DNS
終端指令
scutil

建議驗證節奏（最穩定）

  1. 關閉瀏覽器 DoH，先取得系統層基線。
  2. 固定節點與模式，僅調整 ClashX DNS 一項設定。
  3. 每次改動後跑兩個網站 + 一次終端指令檢查。
  4. 結果不一致時，先清 DNS 快取再重測。
  5. 確認穩定後再恢復瀏覽器 DoH，做最終驗證。

常見誤判

很多「看似 DNS 洩漏」其實是網路架構或 CDN 行為造成。先排除這些誤判，可以省下大量時間。

誤判場景 A：CDN 邊緣節點造成地區偏差

⚠️
現象

出口在日本，但某檢測頁顯示新加坡或香港，誤以為 DNS 洩漏。

誤判場景 B：本地防毒/企業代理接管 DNS

⚠️
現象

ClashX 設定正確，但解析器固定顯示公司安全閘道或防毒供應商。

✅
正確診斷方法

不要依賴單一網站與單一時間點。請至少採用「兩個檢測站 + 一次終端命令 + 一次節點切換回歸」四點法。 如果四點結果一致，判讀可靠性會顯著提升。

常見問題 FAQ

Q1：檢測站顯示的是 Cloudflare DNS，就一定沒洩漏嗎？

不一定。你仍需確認這是 ClashX 配置的預期供應商，而不是瀏覽器 DoH 自行指定的路徑。

Q2：我只在 Chrome 正常，其他 App 不正常，代表什麼？

這通常代表 Chrome 自行處理了 DNS（如 DoH），但系統層或 ClashX DNS 鏈路仍有問題。

Q3：fake-ip 一定比 redir-host 更安全嗎？

不是絕對。兩者是策略取捨。fake-ip 常見於高效率路由，redir-host 在特定相容性場景更穩。

Q4：要不要把系統 DNS 手動改成 8.8.8.8？

在 ClashX DNS 規劃完善時，通常不需要額外手動硬改。排查時建議先保持簡單、可回退。

Q5：每次改設定都要清 DNS 快取嗎？

不是每次都必要，但當結果矛盾或出現舊值殘留時，清快取是最低成本且有效的排除手段。

Q6：公司網路環境下一直顯示內網 DNS，怎麼辦？

優先確認是否有 MDM、企業安全代理或防毒產品接管 DNS。若有，需與 IT 策略協調，不是單靠 ClashX 可完全覆蓋。

總結

DNS 防洩漏不是一次性設定，而是一套持續可驗證的流程：先建立基線、再單點改動、最後回歸驗證。 只要你把 ClashX 配置、系統 DNS、瀏覽器 DoH 三層對齊，並保留完整記錄，後續即使換節點、換網路、換版本， 也能快速定位問題，不再被「偶發失準」反覆困擾。

標籤： DNS防洩漏 網路安全 隱私保護 ClashX DNS設定

相關文章