V2Ray DNS 洩漏如何檢測？遠端 DNS、FakeDNS 與 TUN 防洩漏設定教學

1. 什麼是 DNS 洩漏：解析出口與連線出口不一致

DNS 負責將網域名稱轉換為 IP 位址。代理連線已建立，不代表先前的網域查詢也經過代理。例如，應用程式先向家用路由器查詢目標 IP，再將連線交給本機代理連接埠；網頁看起來是透過代理瀏覽，但本機解析器仍可能得知造訪過哪些網域。判斷是否洩漏，應確認查詢是否違反預先設定的分流規則，而不是看到本機解析器就立刻判定有問題。

若中國大陸網站依規則直連，使用直連 DNS 通常合乎預期；若某個網域應透過代理連線，查詢卻送往本機網路的解析器，才是本文要排除的繞行。VMess、VLESS 負責代理傳輸，不會自動接管系統中的所有 DNS 查詢。訂閱提供節點設定，也不代表已涵蓋完整的本機 DNS 規則。

2. 如何檢測 DNS 洩漏：建立基準，再檢查實體網卡

瀏覽器檢測頁面顯示的是它觀察到的遞迴解析器出口，不一定是用戶端直接連線的伺服器。公用 DNS 可能使用不同地區的出口；頁面顯示的城市也可能來自過時的 IP 位址資料庫。因此，不要只憑「解析器所在城市與節點所在城市不同」就判定有問題。還需要確認查詢經過哪張網卡，以及是否符合目前的規則。

1. 記錄基準狀態。關閉 TUN 和系統代理，記下系統 DNS 位址、瀏覽器安全 DNS 狀態，以及檢測頁面列出的解析器。測試期間請勿造訪敏感網站。
2. 固定測試條件。使用同一個節點和同一套路由，再測試同一個頁面。不要同時切換節點和更改瀏覽器 DNS，否則無法判斷是哪項設定影響結果。
3. 清除快取。在 Windows 終端機執行 ipconfig /flushdns，關閉後重新開啟瀏覽器。核心內建的 DNS 快取通常也需要重新啟動核心才能清除。
4. 檢查系統查詢。執行下方指令，記錄預設解析器與查詢結果。此結果用來觀察系統的解析路徑，不代表瀏覽器一定使用相同路徑。
5. 檢查實體網卡。在封包擷取工具中選取目前使用的乙太網路或無線網卡，查看目標查詢是否直接送往本機解析器；虛擬網卡出現 DNS 封包，本身不代表封包已離開裝置。

ipconfig /all
ipconfig /flushdns
nslookup example.com

# 封包擷取顯示篩選器：檢查傳統 DNS 與常見 DoT 連線
udp.port == 53 || tcp.port == 53 || tcp.port == 853

example.com 是用來示範查詢方法的範例網域，不是 DNS 洩漏檢測服務。正式複測時，請選擇一個依照你的規則明確走代理的網域。瀏覽器內建的 DoH 使用 HTTPS，無法只靠連接埠 53 的篩選器識別；請一併檢查安全 DNS 設定、連線目的位址與用戶端路由日誌。

3. v2rayN 遠端 DNS 與直連 DNS：設定解析器，也要設定出口

在 v2rayN 中先開啟「設定」→「參數設定」，確認目前使用的核心與監聽設定；再開啟「設定」→「DNS 設定」，檢查對應核心的 DNS 設定。不同版本的選單位置和欄位名稱可能不同，請以目前介面及產生的設定為準。尤其要分清一般代理使用的核心與 TUN 使用的核心，勿將一份 DNS JSON 貼到另一個核心的設定區。

遠端 DNS 用於需要透過代理連線的網域，直連 DNS 則用於明確設定為直連的網域。設定遠端解析器只是第一步：若連線至解析器的請求仍走直連，即使使用加密查詢，也無法達成「解析流量走代理出口」的目標。DoH 保護的是裝置與解析器之間的連線，不會自動替你選擇代理出站。

• 先處理引導解析。若節點伺服器使用網域名稱，必須在代理連線建立前取得可用的 IP。請為節點網域個別安排可連線的引導解析路徑，避免陷入「必須連上代理才能解析節點，解析出節點才能連上代理」的循環。
• 限制直連解析範圍。只將明確設定為直連的網域交給直連解析器，不要將它設為所有查詢失敗時都無限制使用的備援解析器。
• 檢查規則順序。解析器的出口規則應放在可能提前符合的廣泛直連規則之前；路由通常依序比對，由第一條符合的規則決定流量去向。

Xray DNS 設定片段：直連網域個別比對，其餘使用遠端查詢

以下使用 Xray 設定格式示範。需要有 geosite.dat 才能使用 geosite:cn 分類；若缺少規則資料，請先修復資料檔，或改用明確列出的自訂網域清單。範例位址僅用來說明設定分工，是否可連線仍須在目前的網路環境中確認。disableFallbackIfMatch 可避免已符合的網域群組在查詢失敗後改用其他解析器，但無法限制瀏覽器或應用程式自行發出的查詢。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

還要將下列規則合併至現有的 routing.rules，不要取代整套路由。此處假設設定中確實有名為 proxy 和 direct 的出站；若用戶端產生的標籤不同，請改用實際標籤。範例依解析器 IP 選擇出口，可能影響傳送至這些 IP 的其他連線；正式設定前應配合現有規則一併評估。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1/32"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. TUN 模式防 DNS 洩漏：接管流量後，也要處理 DNS 與 IPv6

TUN 會將系統流量導入虛擬網卡，適合處理不使用系統代理的應用程式。但它不是「所有請求一律走代理」的開關：流量最後走直連或代理，仍由路由規則決定。DNS 是否會被攔截並送入受控解析流程，也取決於 TUN 設定。請先儲存目前參數，再於 v2rayN 主畫面啟用「啟用 TUN」，依照系統提示授予權限，並檢查啟動日誌。

1. 確認虛擬網卡已建立。若核心啟動失敗，請先排除權限、驅動程式或設定錯誤，不要繼續調整 DNS 來掩蓋啟動問題。
2. 確認 DNS 已接管。檢查 TUN 設定是否包含適用的 DNS 劫持或重新導向規則，再透過系統查詢與封包擷取驗證。只修改網卡 DNS 位址，無法控制應用程式中寫死的解析器。
3. 檢查路由排除項目。可依需求讓區域網路流量直連，但請確認排除範圍沒有一併放行應走代理的 DNS 查詢。遠端解析器位址也不應被廣泛的直連規則提前比對。
4. 同時檢查 IPv6。IPv4 已進入 TUN，不代表 IPv6 也已接管。請檢查 IPv6 預設路由及 DNS 伺服器；若不需要 IPv6，可先確認影響範圍，再暫時關閉進行比較，別將關閉 IPv6 當作通用修復方式。
5. 驗證重新連線與休眠喚醒。切換無線網路、從休眠狀態恢復後，請再次執行查詢。網卡 DNS、系統路由和虛擬網卡狀態都可能已經改變。

v2rayN 的 TUN 功能可能使用 sing-box 核心，其 DNS 與 FakeIP 設定結構不同於 Xray 的 FakeDNS，應透過對應設定或核心格式進行設定。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly，但 Android VPN 接管、應用程式排除項目及 DNS 行為仍受用戶端設定影響。桌面版 JSON 不能直接照抄到 Android 介面。

5. 如何設定 FakeDNS：假位址必須在同一條流程中還原為網域

FakeDNS 不會直接傳回網站的真實 IP，而是從位址池傳回一個對應位址。應用程式連線至該位址時，核心會透過映射還原原始網域，再執行網域路由與代理連線。這能減少事先取得真實 IP 的需求，但它不是加密 DNS，也無法單獨保證不發生洩漏。節點網域的引導解析、直連目標，以及不受控應用程式發出的 DNS 查詢，仍須另外處理。

以下是支援此功能的 Xray 核心示意片段。198.18.0.0/15 是此類映射常用的基準測試位址範圍，不是網站的真實位址；使用前請確認它不會與區域網路、其他 VPN 或現有路由衝突。poolSize 表示映射池容量，不代表網速或可同時處理的連線數。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

接收後續連線的相關入站也必須能還原 FakeDNS 網域，例如為該入站設定下方的嗅探欄位。請將其合併至現有入站物件，不可單獨作為入站使用。這只示範「產生映射與還原映射」，尚未包含 DNS 流量接入、節點引導解析及直連網域的例外規則。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

• 位址池流量必須由代理接管。應用程式取得映射位址後，連線不能直接從實體網卡送出，否則它會嘗試連線到不存在的公網目標。
• 映射與連線必須相互對應。不可由一個獨立執行個體產生映射，再將連線交給不含該映射資訊的另一個執行個體。
• 直連流量仍需解析真實位址。還原出網域後，直連出站可能仍須查詢真實 IP；這個步驟也必須依照直連 DNS 規則執行。
• 重新啟動後清除快取。核心重新啟動時可能會遺失舊映射，但應用程式仍快取舊位址。請清除系統與應用程式快取，再重新查詢，以免將過期映射誤判為節點故障。

6. 常見 DNS 錯誤：先找出問題發生在哪一層

以下列出日誌中可能出現的錯誤片段。完整前綴與文字會隨核心版本而異，單一錯誤只能提供排查方向。複測時一次只變更一項設定，並記錄錯誤發生於節點連線、遠端解析器連線，還是目標網站連線。

7. 複測問答：瀏覽器正常，不代表整台裝置都正常

最終驗收應形成完整流程：代理網域使用受控解析路徑，遠端解析器連線走預期的出站，直連網域依規則解析，節點位址可獨立完成引導，TUN 與 IPv6 的接管範圍也清楚明確。若要檢查基本設定，請參閱訂閱匯入指南、DNS 設定文件和TUN 模式說明。