DNS 洩漏測試與防護：v2rayN、v2rayNG 設定教學

一、DNS 洩漏看的是查詢路徑，不只是國家標籤

DNS 會將網域名稱轉換為 IP 位址。應用程式可能先交由系統解析，再把 IP 位址交給代理；也可能直接將網域交給本機代理，由核心或遠端處理。兩種路徑都能開啟網頁，但前者的查詢可能先送到本地網路提供的解析器。是否算洩漏，應依你的規則判斷：原本要求經過代理的網域，卻透過本地出口解析，才是本文要處理的問題。

中國大陸境內網域若依照規劃使用本地 DNS，不應直接視為洩漏。VLESS、VMess 是代理協定，REALITY 是與連線安全相關的機制；它們不會自動決定作業系統如何送出 DNS 請求。訂閱包含節點參數，也不代表同時提供完整的 DNS 接管與路由策略。

二、線上 DNS 測試：先做三組對照再下結論

線上測試通常會讓瀏覽器查詢一批隨機子網域，再觀察哪些遞迴解析器前來查詢。結果顯示的是解析器的出口，不一定是裝置連線的上游位址，也不一定與代理節點位於同一座城市。公共 DNS 會使用任播與轉送叢集，不能只憑地圖或國家名稱判斷是否洩漏。

1. 記錄直連結果

   先停止代理，在瀏覽器開啟 dnsleaktest.com，執行標準測試，再執行擴充測試。記錄網路類型、時間、解析器 IP 與所屬機構，作為本地網路的對照。

2. 測試代理連線

   啟動用戶端，確認同一個瀏覽器已納入代理，再重新執行測試。維持相同節點與網路，不要同時變更 DNS、路由和瀏覽器設定等變數。

3. 排除瀏覽器因素

   在瀏覽器設定中搜尋「安全 DNS」，暫時關閉後再測一次。測試後是否重新啟用，取決於你是否打算另外管理瀏覽器的加密 DNS 路徑。

4. 測試斷線情況

   在允許短暫中斷網路的環境中斷開代理節點，再發起新的測試。如果目標是連線失敗時停止存取，斷線後仍能解析並存取新網域，就應檢查系統直連、VPN 旁路與應用程式回退。

三、v2rayN 桌面端：分開排查系統代理與 TUN

以下以 v2rayN 7.x 的設定架構為參考。不同小版本的分類名稱可能有所調整，請先確認目前使用的核心，再查看產生的設定。特別留意：TUN 模式實際使用的元件及 DNS 設定，可能與一般系統代理模式不同；修改 Xray 的 DNS 欄位，不一定會影響目前的 TUN 路徑。

1. 確認執行模式

   開啟「設定」→「參數設定」，確認核心相關選項；返回主畫面查看「系統代理」與「啟用 TUN」的實際狀態。不要因為系統匣顯示系統代理已啟用，就認定所有程式都已進入隧道。

2. 檢查解析上游

   進入「設定」→「DNS 設定」，分別檢查目前核心所使用的設定。可使用 https://1.1.1.1/dns-query 作為遠端上游的測試目標，接著確認連往該位址的流量會透過代理路由，而不只是填入 DoH URL。

3. 確認本機連接埠

   在「設定」→「參數設定」查看本機監聽連接埠，並與瀏覽器或應用程式的代理位址比對。例如實際監聽位址為 127.0.0.1:10808，應用程式也應使用該連接埠及相應的代理類型；範例連接埠不能取代實際設定。

4. 清除舊快取

   在 Windows 開啟終端機並執行 ipconfig /flushdns，接著關閉並重新開啟瀏覽器，再測試新的網域。既有連線與瀏覽器自己的快取不會因為這個指令全部清除。

Windows 多網卡環境還要檢查 Wi-Fi、有線網卡與虛擬網卡。支援群組原則的系統，可在「電腦設定」→「系統管理範本」→「網路」→「DNS 用戶端」中，將「關閉智慧多重主機名稱解析」設為「已啟用」。這是減少並行查詢的輔助措施，不能取代 TUN 接管，也不是所有系統 DNS 回退的總開關。變更後仍應以實際測試結果為準。

四、v2rayNG Android 端：先納入 VPN，再檢查私人 DNS

以下以 v2rayNG 1.9.x 常見的設定架構為參考。v2rayNG 使用 Xray 核心，但系統 VPN 接管、Android 私人 DNS 與瀏覽器安全 DNS 屬於不同層級。v2flyNG 使用 V2Fly 核心，不能直接套用本文所有選項與設定欄位。

1. 確認應用程式範圍

   開啟側邊欄「設定」→「分應用程式代理」，確認測試用的瀏覽器未遭排除。排查時可暫時關閉分應用程式代理，讓測試範圍更明確；若使用允許清單，瀏覽器必須列在清單中。

2. 檢查本機 DNS

   進入側邊欄的「設定」，找到「啟用本機 DNS」並開啟，確認「遠端 DNS」與「中國大陸 DNS」欄位。部分版本會將這些選項歸在 DNS 設定分類中；遠端上游與中國大陸上游的位址應分開確認，不能只憑欄位名稱推斷最後的出站路徑。

3. 測試私人 DNS

   Android 原生設定路徑通常是「設定」→「網路和網際網路」→「私人 DNS」。先記下原本的值，再暫時設為「關閉」，建立核心 DNS 的基準。部分廠牌系統可能稱為「私有 DNS」，可在系統設定中搜尋該名稱。

4. 重新建立 VPN 連線

   儲存設定後先中止連線，再重新啟動，並確認系統顯示 VPN 連線狀態。切換 Wi-Fi 與行動網路後各測一次；若只有其中一種網路異常，請優先檢查該網路的 IPv6、DNS 可連線性與 VPN 重新連線情況。

5. 測試斷線保護

   若要在連線失敗時停止存取，請在 Android「設定」→「網路和網際網路」→「VPN」→「v2rayNG」中檢查「一律啟用 VPN」及「封鎖未使用 VPN 的連線」。裝置與應用程式狀態不同，系統提供的選項也可能不同；啟用後須確認分應用程式規則仍符合預期。

五、FakeDNS：減少預先解析，但不能取代遠端上游

FakeDNS 會回傳合成位址，並在後續連線中將位址對應回網域。如此一來，核心便能保留網域資訊，用於路由比對與代理轉送。FakeDNS 本身不是加密 DNS 服務，也不會自動讓所有實際解析都經過代理；需要真實 IP 的直連流量，仍須使用合適的解析上游。

在 v2rayNG 的「設定」中尋找「啟用 Fake DNS」。啟用前先確認「啟用本機 DNS」已生效，儲存後重新啟動 VPN。桌面端則應依照目前 TUN 元件支援 FakeIP／FakeDNS 的方式設定，不要直接把 Xray 的 FakeDNS 物件複製到其他格式的設定中。

• 啟用後若網頁異常，請先重新啟動應用程式並清除舊 DNS 快取，再考慮還原設定。
• 若應用程式取得合成位址後繞過 VPN，通常無法正常使用該位址，必須調整接管範圍。
• 部分應用程式會自行驗證實際位址或使用獨立解析，可能不適合搭配 FakeDNS；應逐一測試。

六、關閉回退與設定路由備援：分別處理兩層設定

「關閉系統 DNS 回退」並不是跨平台通用的按鈕。用戶端核心的備用上游、Windows 多網卡查詢、Android 網路切換，以及瀏覽器本身的安全 DNS，都必須分別排查。Xray 的 disableFallback 只控制內建 DNS 的備用查詢行為，無法代替作業系統阻止直連。

以下是 Xray DNS 與路由的局部範例，並非完整設定。範例只展示遠端上游及其出口限制：現有設定必須已定義標籤為 proxy 的代理出站，並讓應用程式查詢進入核心 DNS。用戶端自動產生的設定，應透過對應的編輯介面調整並檢查最終結果，不可直接覆寫原設定後執行。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallback": true
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      }
    ]
  }
}

此處使用 IP 格式的 DoH 位址，是為了減少解析上游網域時對引導解析的依賴。UseIPv4 只會限制這段內建 DNS 查詢所使用的位址類型，不會關閉系統 IPv6。範例未設定網域分流，也未包含應用程式 DNS 接管規則，因此不能據此宣稱已完成全域防洩漏。

• 遠端上游優先比對：將遠端 DNS 的連線規則放在可能符合的直連規則之前。Xray 會依序比對路由規則，前面的規則符合後便不會繼續尋找後續規則。
• 檢查預設出站：Xray 找不到符合的規則時會使用第一個出站。若要以代理作為備援，請確認第一個出站不是未察覺的直連。
• 避免混用本機模式：選擇上游時，請留意 https+local:// 這類具有本機存取語意的位址格式；不要將它視為一般遠端 DoH 設定，認為它會受到相同的路由控制。
• 接管一般 DNS：在適當的入站與路由設計中，可將 UDP/TCP 53 交由 DNS 出站處理。只封鎖 53 埠會使部分應用程式無法解析，也無法涵蓋透過 853 或 HTTPS 傳輸的查詢。
• 確保節點網域能完成啟動：若代理伺服器使用網域名稱，建立代理連線前可能需要先進行引導解析。應明確規劃這項例外，避免 DNS 依賴代理、代理又依賴 DNS，形成循環。

七、驗收：同時檢查瀏覽器結果、日誌與斷線行為

完成變更後，不要只保留一張檢測頁截圖。請記錄用戶端版本、執行模式、網路類型、遠端上游與測試應用程式。先驗證單一上游與全代理，再逐項恢復中國大陸網域分流、瀏覽器安全 DNS 及分應用程式規則；每恢復一項就重新測試，才能找出是哪一層改變了解析路徑。

實體網卡沒有 53 埠流量，只能表示未觀察到這類明文 DNS；瀏覽器 DoH 仍可能透過 443 直連。加密查詢須搭配上游目標、連線路由與日誌判斷。暫時提高日誌層級後，也應恢復日常設定；分享日誌前，請先移除訂閱網址、使用者識別資訊與存取網域。