· 問題排查 · 約 12 分鐘

DNS 洩漏測試與防護設定：遠端 DNS、FakeDNS 與路由規則教學

了解如何判斷 DNS 查詢是否繞過代理，並逐步設定 v2rayN、v2rayNG 的遠端 DNS、FakeDNS 與 DNS 分流規則。

本文重點

DNS 防洩漏必須同時檢查查詢入口、解析器與連線出口。本文適合已能連上節點，卻不確定網域解析是否經由代理傳送的使用者：先比較直連與代理，再設定 v2rayN、v2rayNG 的 DNS，最後處理 FakeDNS、瀏覽器安全 DNS 與路由例外。檢測結果必須對照實際規則判讀，不能只看解析伺服器所在區域。

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

連線至網域通常會經過兩個步驟：先取得 IP 位址，再建立服務連線。網頁連線經過代理，不代表前面的 DNS 查詢也經過代理。系統代理主要影響支援代理的應用程式如何連線，通常不會接管整台裝置的 UDP 53 查詢。

本文要排查的是「原本應由代理傳送的網域查詢，卻從本地網路送出」的情況。如果路由策略明確指定區域網路網域、本地域名或特定網站直連，這些查詢使用本地解析器就是策略設定的結果；若希望所有公網查詢都經代理傳送，就必須進一步限制本地回退與應用程式繞過代理。

檢測結果不能直接據此判斷接下來檢查
網頁出口 IP 已變更所有 DNS 查詢都經過代理瀏覽器、系統與核心各自使用哪個解析器
解析器顯示為公共 DNS查詢一定經過代理DoH 連線走直連還是代理出口
偵測到多個解析器一定有 DNS 洩漏是否使用分流、回退或解析器叢集
出現本地電信業者的解析器一定是節點設定錯誤是否有系統查詢、瀏覽器回退或直連網域

判斷方式：先寫下預期路徑，再解讀檢測結果

如果預期路徑是「公網網域透過代理解析，區域網路名稱在本地解析」，就分別測試這兩類查詢。解析器名稱與所在區域只能提供線索，不能取代出口日誌與封包擷取的證據。

2. 建立比較基準：同時檢查瀏覽器測試與本機封包

先暫停代理，記錄 DNS 檢測頁面顯示的解析器資訊；接著啟用代理，用同一個瀏覽器重新測試。檢測頁通常會以隨機子網域觸發查詢，降低舊快取造成的影響，但主要涵蓋目前瀏覽器的解析路徑，無法證明其他應用程式也已由代理接管。

  1. 記錄基準狀態

    記下目前的網路、代理模式、瀏覽器安全 DNS 狀態與系統私人 DNS 狀態。先完成直連測試，再啟用代理；兩次測試都不要變更其他設定。

  2. 清除快取

    Windows 可執行下方指令清除系統 DNS 快取。瀏覽器可能另有快取，請關閉相關頁面後再重新開啟。清除快取不會讓已建立的連線自動改走新的路徑。

  3. 使用隨機網域重新測試

    在 DNS 檢測頁重新發起測試，不要只重新整理上一輪結果。記錄解析器位址與服務供應商，再與直連結果比較；不要只根據頁面顯示的單一地區下結論。

  4. 確認出口流量

    在實際連網的網路介面上觀察 UDP/TCP 53 流量。檢查測試網域是否直接傳送至路由器或電信業者的解析器，並搭配核心日誌確認遠端 DNS 的連線出口。

ipconfig /flushdns
nslookup example.com

nslookup example.com 可用來觀察系統端的查詢行為，不是 HTTP 或 SOCKS 代理測試。僅啟用系統代理時，它仍可能向系統指定的 DNS 傳送封包。啟用 TUN 後是否會被接管，則取決於該模式的 DNS 劫持與路由設定。

3. v2rayN：分別設定系統代理、TUN 與遠端 DNS

v2rayN 是桌面用戶端，實際的解析與路由方式取決於所選核心及產生的設定。先在主畫面確認目前節點可用，再檢查「設定」→「DNS 設定」。不同版本的欄位配置可能有所不同；若目前介面沒有相應選項，請查看實際產生的設定，不要把其他版本的畫面當成固定選單。

  1. 確認接管範圍

    只測試瀏覽器時，可先使用系統代理。若要涵蓋不遵守系統代理設定的應用程式，再啟用主畫面的 TUN 模式，並確認系統授權成功。開啟 TUN 不代表 DNS 劫持已生效。

  2. 設定遠端 DNS

    前往「設定」→「DNS 設定」，在目前核心對應的遠端 DNS 欄位填入支援的解析位址。例如 https://1.1.1.1/dns-query 是 DoH 位址，不能填入只接受一般 IP 位址的欄位。

  3. 檢查解析路由

    查看「設定」→「路由設定」及目前啟用的規則集。確認遠端 DNS 連線沒有被前面的直連規則攔截；同時保留節點伺服器位址所需的引導解析路徑。

  4. 重新啟動並測試

    儲存後重新啟動目前服務、清除快取，再進行同一組比較測試。切換至 TUN 後，也要另外測試系統端查詢，避免只因瀏覽器測試成功，就認定整台裝置的 DNS 都已被接管。

使用系統代理模式時，也要留意本機監聽位址。應用程式使用的 HTTP 或 SOCKS 埠號必須與用戶端顯示的值一致；DNS 的 53 埠不是 SOCKS 入口。不要把遠端 DNS 位址填入應用程式的代理伺服器欄位，也不要為了解決 DNS 問題而任意開放區域網路監聽。

4. v2rayNG：確認本地 DNS、遠端 DNS 與應用程式範圍

v2rayNG 透過 Android VPN 介面承接應用程式流量，核心使用 Xray。此處的「本地 DNS」通常指解析策略中的本地端伺服器，不一定代表只監聽本機迴環位址。應搭配設定項說明與產生的設定檔判讀，不能只憑名稱判斷資料是否離開裝置。

  1. 確認應用程式範圍

    前往「設定」→「分應用程式代理」，檢查目前設定是僅代理選取的應用程式，還是略過選取的應用程式。用來檢測的瀏覽器必須納入代理範圍，否則測到的會是該應用程式的直連行為。

  2. 啟用核心解析

    前往「設定」，找到「啟用本地 DNS」與 DNS 設定項目。若目前版本提供此開關，啟用後請檢查「遠端 DNS」與「本地 DNS」的實際值；選單名稱可能因版本而略有不同。

  3. 設定遠端 DNS

    在「遠端 DNS」欄位填入目前核心支援的伺服器位址，例如 https://1.1.1.1/dns-query。先測試單一遠端伺服器，不要同時加入多個尚未驗證的回退伺服器。

  4. 檢查系統解析設定

    在 Android 系統設定中搜尋「私人 DNS」或「Private DNS」。記錄原本狀態後，暫時關閉以進行比較；測試完成後再恢復，並確認恢復後的加密解析連線仍符合預期路由。

  5. 重新連線並查看日誌

    中斷連線後重新啟動連線，檢查網域解析錯誤與請求逾時。如果只有被排除的應用程式仍使用本地解析器，應先修正應用程式範圍，而不是繼續更換 DNS 位址。

5. 遠端 DNS 路由：使用加密位址不代表流量經過代理

DoH 解決的是查詢內容在傳輸過程中的加密問題；是否經過代理，取決於連線的路由。Xray 內建 DNS 的一般 https:// 查詢可以交由核心路由處理，而 https+local:// 屬於本地查詢模式，不應用於要求透過核心代理路由的情境。

以下是用來說明路由關係的 Xray 設定片段，並非完整的用戶端設定。此設定會將內建 DNS 查詢標記為 dns-query，再把帶有此標記的流量交給既有的 proxy 出站。使用前務必確認目前核心支援相應欄位，且實際代理出站標籤確實為 proxy。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      }
    ]
  }
}

操作建議：先驗證單一路徑，再加入分流

先確保單一遠端 DNS 能穩定透過代理完成查詢，再逐項加入本地域名規則、備用解析器與 IPv6。每新增一項就重新測試，才能找出是哪個例外改變了出口路徑。

6. FakeDNS：回傳虛擬位址後，仍須接管後續連線

FakeDNS 不會將目標網站的真實 IP 位址直接回傳給應用程式，而是配置一個虛擬位址，並保存網域與虛擬位址的對應關係。應用程式連線至該位址時，核心會利用對應資料還原網域，再交由路由與出站處理。這可以減少某些情境下過早取得真實 IP 的情況，但不能取代加密的遠端 DNS。

常見的 IPv4 虛擬位址池為 198.18.0.0/15，也就是 198.18.0.0 至 198.19.255.255。這段位址不是目標網站的公網位址。若查詢由 FakeDNS 處理，但後續連線未被接管，應用程式就會嘗試連線至無法正常抵達目標的虛擬位址。

必須銜接的環節檢查項目未設定時的現象
查詢入口應用程式的 DNS 查詢確實進入 FakeDNS仍取得真實 IP，設定未涵蓋測試中的應用程式
連線接管虛擬位址流量回到同一套核心處理解析成功，但連線持續逾時
還原對應關係入站支援還原 FakeDNS 網域路由無法依原始網域匹配
快取生命週期重新啟動後不再使用舊的虛擬位址重新啟動核心後，部分應用程式暫時無法連線

在 v2rayNG 中，若「設定」提供「啟用虛擬 DNS」，應先依該版本要求啟用本地 DNS，再啟用虛擬 DNS，並確認「嗅探」相關設定支援 FakeDNS 還原。在 v2rayN 中，則應確認 TUN 與目前核心的 FakeDNS 搭配方式。不要以為只新增虛擬位址池，就已完成 DNS 接管與網域還原。

7. 日誌排錯：分辨解析失敗與連線失敗

先記錄錯誤發生的時間與目標位址，再比對同一時段的日誌。以下字串可能出現在日誌內容中，前綴與完整訊息會因核心版本而異。單一逾時訊息無法證明有 DNS 洩漏，也不能證明 DNS 伺服器本身無法使用。

錯誤：failed to lookup ip for domain

原因：核心無法取得目標網域的可用位址，可能是遠端解析器無法連線、引導解析失敗，或查詢策略排除了可用的記錄。

解決方式：確認日誌中的實際網域，先檢查節點網域能否完成引導解析，再檢查遠端 DNS 的路由，以及 IPv4、IPv6 查詢策略。

錯誤：context deadline exceeded

原因：作業未能在指定時間內完成；若錯誤與 DoH 請求相關，可能是連往解析器的 HTTPS 連線或上游回應逾時。

解決方式：透過相同的代理路徑測試該解析位址，一次只更換一個遠端 DNS，並檢查是否出現「解析依賴代理、代理又依賴解析」的循環。

錯誤：network is unreachable

原因：目前網路沒有通往目標位址的可用路由，例如嘗試連線至無法到達的 IPv6 位址。

解決方式：檢查錯誤目標使用的位址類型，暫時改用 IPv4 查詢策略進行比較；同時確認 TUN 路由、實體網路與代理出站是否支援 IPv6。

8. 常見問題與最後一次測試

檢測頁顯示本地解析器，就代表有 DNS 洩漏嗎？

先確認測試用的瀏覽器是否在代理範圍內，再檢查本地 DNS 分流規則。若測試網域依策略應經代理查詢，卻在實體網路介面上看到對應的直連查詢，才有較明確的繞過代理證據。

已填入 DoH 位址，為什麼結果沒有改變？

確認修改的是目前核心實際使用的 DNS 設定，並重新啟動服務。接著暫時關閉瀏覽器安全 DNS 再測試；若瀏覽器自行解析，可能根本沒有使用剛修改的核心 DNS。

啟用 FakeDNS 後解析成功，但網頁無法開啟，該怎麼辦？

先確認虛擬位址連線是否進入同一套接管路徑，以及入站是否啟用相應的網域還原功能。停用 FakeDNS、清除應用程式快取後再測試；若恢復正常，應優先檢查對應關係與連線接管，不要先更換節點。

直接封鎖所有 53 埠就能解決嗎？

不行。這可能會阻斷正常的引導解析，也無法攔截使用 443 埠的 DoH 或使用 853 埠的 DoT。應先建立可用且受控的解析路徑，再依需求限制繞過代理的流量，並保留必要的區域網路服務。

最後，將代理重新連線、重新啟動用戶端與切換網路都納入測試。Wi-Fi 與行動網路可能提供不同的解析器及 IPv6 路由；只在一種網路上完成的檢測，不能代表另一種網路的結果。請保留設定變更記錄，發生異常時逐項還原。

下載v2rayN查看四平台用戶端