V2Ray DNS 洩漏檢測方法與 dns 模組防洩漏設定實作

DNS 洩漏發生在哪個環節

存取網域時，應用程式通常會先將網域交給系統解析器，再連線至解析出的 IP。系統代理只會接管支援代理設定的 HTTP 或 SOCKS 連線，不會自動改寫作業系統發往 UDP 53、TCP 53 的 DNS 查詢。因此，即使網頁流量已由 VMess 或 VLESS 節點轉送，網域查詢仍可能直接傳給網卡設定的網路業者解析器。

洩漏不等於節點失效。更精確地說，是業務連線經過代理，但解析請求走了另一條不符合預期的路徑。當檢測頁面顯示本地網路業者、路由器位址或企業內網解析器時，才需要配合系統設定進一步判斷。結果中出現公共 DNS 名稱，也不能單獨證明查詢是否經由代理，因為同一個公共解析器既可能直連，也可能透過遠端節點存取。

Xray 設定中的頂層 dns 模組主要負責核心本身的網域解析與比對需求，例如解析節點伺服器網域、為路由規則取得目標 IP。它不會只因存在於設定檔中，就接管作業系統的所有查詢。若要處理應用程式提交給系統的 DNS，還需要讓監聽入口、系統 DNS 指向與對應出站三者同時成立。

瀏覽器內建的加密 DNS 是另一條路徑。它通常透過 HTTPS 連線解析服務，不再存取本機 53 埠。若瀏覽器流量由系統代理接管，這條連線可能經過代理；若應用程式繞過系統代理，也可能直接出站。因此排查時應先暫時關閉瀏覽器的安全 DNS，再檢測系統解析路徑，最後單獨恢復並驗證瀏覽器設定。

建立可重複的 DNS 洩漏檢測基準

單次檢測結果容易受到快取、瀏覽器預先擷取與解析器任播節點影響。更可靠的方式是在相同網路、相同節點與相同瀏覽器設定下完成兩輪測試：第一輪記錄未接管 DNS 時的結果，第二輪套用設定後清除快取並重新測試。每輪至少執行三次隨機網域查詢，避免舊快取讓系統略過實際解析。

1. 記錄網卡 DNS

   開啟 PowerShell，執行 Get-DnsClientServerAddress -AddressFamily IPv4。記錄正在使用的網卡名稱與 ServerAddresses；家用網路常見結果是路由器位址，公共網路也可能直接下發兩個解析器位址。

2. 排除測試干擾

   暫時關閉瀏覽器安全 DNS，退出其他會修改網路堆疊的程式。接著執行 ipconfig /flushdns 清除 Windows DNS 快取，並關閉已開啟的檢測頁面。

3. 記錄直連結果

   中斷 v2rayN 系統代理，重新進入 DNS 檢測頁面並連續測試兩次。記錄解析器數量、網路歸屬與地區；這組資料是本地路徑基準，不要只保存頁面上的國家或地區名稱。

4. 連線後重新測試

   連線至目標節點，確認 v2rayN 本機 SOCKS 埠 10808 與 HTTP 埠 10809 正在監聽，再次清除快取並測試。若結果與直連基準完全一致，系統 DNS 很可能尚未被接管。

5. 驗證指定入口

   設定本機 DNS 入口後執行 nslookup example.com 127.0.0.1。只有在返回位址且 Xray 記錄出現 dns-in、dns-out 時，才能表示查詢已進入預定鏈路。

範例環境使用 Windows 11 24H2、v2rayN 7.12.5 與 Xray-core 25.6.8。首次直連測試顯示 3 個本地網路解析端點，平均查詢時間約 18 毫秒；改由遠端節點存取指定解析器後，頁面只顯示所選的公共解析服務，連續查詢平均約 136 毫秒。延遲增加是跨節點轉送的正常代價，實際數值會隨線路距離變化，不能將 136 毫秒視為固定標準。

透過 dns 入口與出站納入代理鏈路

以下設定片段使用本機 127.0.0.1:53 作為 DNS 入口，將 TCP 與 UDP 查詢交給標籤為 dns-out 的出站，再透過現有的 proxy 出站轉送。套用前應先在目前有效的設定中確認所選節點的出站標籤；若實際標籤不是 proxy，就需要將 proxySettings.tag 改為現有標籤。

53 埠可能已被系統服務、虛擬網卡程式或本機解析軟體占用，而且監聽低號埠通常需要系統管理員權限。可以先將入口埠改為 1053，驗證 Xray 設定是否能啟動，但 Windows 網卡 DNS 設定不能直接填寫非標準埠。正式接管系統查詢時，仍需釋放 53 埠，並將作用中網卡的 IPv4 DNS 指向 127.0.0.1。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4",
    "disableCache": false
  },
  "inbounds": [
    {
      "tag": "dns-in",
      "listen": "127.0.0.1",
      "port": 53,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp,udp"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp",
        "nonIPQuery": "drop"
      },
      "proxySettings": {
        "tag": "proxy"
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "dns-in"
        ],
        "outboundTag": "dns-out"
      }
    ]
  }
}

queryStrategy: UseIPv4 會讓內建 DNS 優先回傳 IPv4 結果，適合目前節點或本地網路沒有穩定 IPv6 出站的情況。若線路完整支援 IPv6，可依實際目標改為 UseIP，但應同步檢查代理節點、系統路由與遠端解析器，避免只取得 AAAA 記錄卻沒有可用的 IPv6 出站。

nonIPQuery: drop 會捨棄 DNS 出站中非 A、AAAA 類型的查詢。這適合只需要一般網頁解析的精簡情境，但可能影響依賴 TXT、SRV 等記錄的企業服務。若出現郵件驗證、服務探索或內部應用程式解析異常，應移除此項後重新測試，而不是將問題歸咎於 VMess 或 VLESS 協定。

domainStrategy 不是 DNS 防洩漏開關

routing.domainStrategy 決定路由模組在比對規則時是否將目標網域解析為 IP。它處理的是「路由規則是否要額外解析」，不是「作業系統 DNS 應從哪裡發出」。將它從 AsIs 改為 IPIfNonMatch，可能讓 IP 規則取得比對機會，但不會自動攔截網卡發出的 UDP 53 請求。

常見設定選擇是 IPIfNonMatch：先套用網域規則，未命中時再為 geoip 或明確的 IP 規則解析。這樣可避免所有請求都提前觸發解析，同時保留 IP 分流能力。若路由清單將 IP 規則放在很前面，IPOnDemand 可能大幅增加核心 DNS 查詢數量，應配合記錄觀察，而不是只依名稱選擇。

頂層 dns.servers 的網域分流與 routing.rules 是兩套邏輯。前者決定某類網域交給哪個解析器，後者決定連線走 direct、proxy 或 block。若讓 geosite:cn 使用鄰近解析器，同時又要求所有 DNS 查詢必須經遠端節點轉送，就需要釐清兩個目標是否衝突；解析器位址與傳輸路徑應分開設計。

• 只想讓網域規則優先運作，可使用 AsIs，並另外處理系統 DNS。
• 網域未命中後仍要使用 geoip 分流，可使用 IPIfNonMatch。
• 不要將修改 domainStrategy 視為檢測完成的證據，仍須檢查 53 埠與記錄。
• 節點伺服器位址本身是網域時，應確保啟動階段存在可用的引導解析路徑，否則代理尚未建立就無法解析節點。

在 v2rayN 中套用設定並避免被覆寫

v2rayN 的一般訂閱節點由客戶端產生執行設定，直接修改暫存 JSON 檔案，可能在切換伺服器、更新訂閱或重新啟動核心後被覆寫。若需要完整控制 DNS 入站與出站，可使用自訂設定伺服器，並將現有節點參數、路由規則與上述 DNS 結構合併至一份有效設定。

1. 確認核心類型

   進入「設定」→「參數設定」→「Core 類型」，確認目前伺服器使用 Xray 核心。儲存後重新啟動核心，避免設定語法由另一個核心解讀。

2. 檢查出站標籤

   開啟目前執行中的設定，找到所選節點對應的 outbounds.tag。本文範例使用 proxy；若實際檔案使用其他名稱，DNS 出站的代理標籤必須保持一致。

3. 新增自訂設定

   在「伺服器」→「新增自訂設定伺服器」中選擇準備好的 JSON 檔案。先保留本機 DNS 入口埠 1053 進行啟動測試，確認語法與路由記錄正常。

4. 釋放 53 埠

   執行 Get-NetUDPEndpoint -LocalPort 53 與 Get-NetTCPConnection -LocalPort 53 檢查占用情況。處理衝突後，將設定埠改回 53，並以系統管理員權限重新啟動 v2rayN。

5. 修改作用中網卡

   將目前作用中網卡的 IPv4 DNS 伺服器設為 127.0.0.1。不要同時保留本地網路業者 DNS 作為備用項目，否則本機服務暫時無回應時，系統可能自動切換至備用解析器。

6. 清除快取後驗證

   執行 ipconfig /flushdns，使用 nslookup example.com 127.0.0.1 驗證入口，再執行三輪檢測。完成後檢查記錄是否由 dns-in 命中 dns-out。

若只使用系統代理而沒有 TUN，未遵循系統代理設定的應用程式連線仍可能直連。DNS 接管只能解決解析路徑，不能取代全流量接管。使用 TUN 時也要核對 DNS 劫持與路由規則：傳統 UDP、TCP 53 可被捕獲，但應用程式自行建立的 HTTPS 解析連線會呈現為一般 443 流量，需要由相應的應用程式流量規則決定去向。

常見錯誤與排查順序

排錯時先確認核心是否啟動，再確認埠是否監聽，最後才看檢測頁面。檢測頁面位於鏈路末端，前兩項失敗時反覆重新整理不會提供更多資訊。記錄層級可暫時設為 info，完成定位後再恢復日常設定，避免長期產生大量存取記錄。

若記錄顯示請求命中 dns-in，但沒有進入 dns-out，應檢查路由規則順序。Xray 路由會由上至下比對，較早的通用入站規則可能先將請求送往 direct。將針對 dns-in 的規則放在通用規則之前，並確認沒有重複的 tag。

若 Xray 記錄完整、系統查詢也正常，但瀏覽器檢測結果仍不同，通常表示瀏覽器使用了獨立解析鏈路。恢復安全 DNS 後，應將它視為一般 HTTPS 流量進行測試：檢查瀏覽器程序是否經由系統代理或 TUN，而不是繼續修改 53 埠設定。

建議監聽位址保持 127.0.0.1，不要為了省事改成 0.0.0.0。後者會讓服務監聽所有網卡，區域網路裝置可能存取該埠，也會擴大防火牆設定範圍。只有在明確要為其他裝置提供解析服務時，才應繫結區域網路位址並設定存取控制。