FakeDNS 是什麼？Xray 虛擬 IP 解析原理、適用情境與設定注意事項

FakeDNS 原理：回傳虛擬位址，不先查詢真實 IP

一般 DNS 解析會向上游查詢網域名稱的 A 或 AAAA 記錄，取得真實位址後才建立連線。FakeDNS 則在本機維護一份「網域名稱與虛擬 IP」對照表：應用程式查詢網域名稱時，會先從指定的位址池分配一個位址並回傳。這個位址不是網站伺服器，無法脫離對照表單獨使用。

假設應用程式查詢 example.com，本機會回傳位址池中的某個 198.18.x.x 位址。應用程式接著連線至這個位址，而流量必須回到能讀取同一份對照表的處理鏈路。Xray 才能還原原本的網域名稱、比對網域規則，並將請求交由相應的出站處理。若連線繞過接管鏈路，系統只會嘗試連線至一個並未承載該網站的虛擬位址。

這也說明了 FakeDNS 為何常與 TUN 搭配使用：虛擬網卡可以接收應用程式送往這些位址的 IP 流量。但 TUN 只負責接管入口，不會自動確保 DNS 查詢也進入 FakeDNS，更不保證不同核心共用同一份映射。DNS 查詢與後續連線必須形成完整流程。

位址池與映射容量：如何理解這三個數字

Xray 的 FakeDNS 設定可指定 ipPool 和 poolSize。以下以 IPv4 教學範例說明，數值代表設定意義，不表示所有用戶端都採用相同的預設值。位址池與映射容量是兩回事，不能因為網段夠大，就認定映射永遠不會被回收。

198.18.0.0/15 屬於保留的網路基準測試位址範圍，不是公用網站位址，也不是一般家用區域網路的私有網段。如果企業測試網路或其他通道已使用這個範圍，仍可能發生路由衝突。啟用前應檢查本機路由，不要把「保留位址」理解成絕對不會衝突。

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

這是 Xray 設定的一部分，並非完整的用戶端設定。內容未提供入站、出站、DNS 接管與路由規則，也沒有為直連目標安排真實解析，因此不能當成可直接連線使用的檔案。映射屬於執行期間的狀態，核心重新啟動後，不應假設舊位址仍對應原本的網域名稱。

FakeDNS、真實 DNS 與網域嗅探有何不同

FakeDNS 不等於加密 DNS，也不等於 HTTP 或 TLS 嗅探。FakeDNS 建立映射，嗅探則從連線內容擷取可能的網域名稱。Xray 的 FakeDNS 透過映射表還原網域名稱，不要求每條連線都能從應用層讀取主機名稱。即便如此，如果應用程式直接連線至真實 IP，且沒有先進行對應的網域查詢，FakeDNS 也無法憑空得知網域名稱。

對於需要代理的網域，FakeDNS 可以省去用戶端等待真實 IP 的步驟；如果代理出站將網域名稱交由遠端處理，解析可在後續鏈路完成。但存取直連網站時，仍需要真實位址。解析成本可能只是轉移到別處，並未從整條連線中消失。網頁載入速度還會受到節點延遲、封包遺失、伺服器回應與資源數量影響，因此不能保證固定的提速幅度。

• 適合：應用程式主要發起 IP 連線、TUN 已穩定接管，且需要更完整的網域資訊來比對規則。
• 不必優先啟用：瀏覽器已透過代理協定傳遞網域名稱，現有系統代理運作正常，暫時也沒有網域資訊遺失的問題。
• 請謹慎使用：企業內網、區域網路裝置探索、依賴真實解析結果的軟體，以及同時使用其他虛擬網卡的環境。
• 無法取代：正確的訂閱參數、可用節點、準確的系統時間與伺服器端支援。

在 v2rayN 啟用前：先確認核心與 DNS 入口

v2rayN 是用戶端介面，Xray 則是可供呼叫的核心。不能只因介面上有「TUN」選項，就推定該模式一定會讀取 Xray 的 fakedns 欄位。部分執行模式由不同的設定產生流程負責，實際欄位與接管方式可能不同。請先查看啟動記錄中的核心名稱、版本與設定載入結果，再決定是否使用本文介紹的 Xray 欄位。

1. 保留原始基準：備份目前設定；先關閉 TUN，使用原有系統代理確認同一個節點能否連上目標網頁。記下目前的 DNS、路由模式與本機連接埠。
2. 檢查設定：在 v2rayN 的「設定」→「參數設定」中確認核心與入站相關設定，再查看「設定」→「DNS 設定」的現有內容。不同版本的選單名稱可能不同，請以實際介面為準。
3. 確認產生的設定：檢查執行中的設定是否包含預期的 fakedns、DNS 伺服器清單，以及入站的 sniffing 欄位。不要只憑單一開關是否勾選來判斷功能是否生效。
4. 檢查接管範圍：DNS 查詢必須進入預期的本機處理鏈路，虛擬網段的連線也必須受到接管。請留意瀏覽器安全 DNS、應用程式內建的 DoH，以及 IPv6 查詢是否繞過這條鏈路。
5. 逐項驗證：儲存後依用戶端要求重新啟動核心，先測試一個代理目標與一個直連目標，再測試區域網路服務。每次只變更一類設定。

尤其要留意 routeOnly：將還原出的網域名稱僅用於規則比對，與將它作為連線目標，是兩種不同的處理方式。如果後續出站仍使用虛擬 IP 發起連線，就可能逾時。請依目前核心的設定說明及完整出站設計進行確認，不要單獨複製某個布林值。

如何驗證：同時檢查解析結果與連線記錄

只看到一個 198.18.x.x 位址，最多只能證明這次查詢取得了虛擬結果，不能證明代理出站成功。反過來說，網頁能開啟，也可能只是瀏覽器繞過了系統 DNS。驗證時要同時確認「查詢經由哪條路徑」以及「連線最後送往何處」。

1. 關閉瀏覽器中已開啟的測試分頁；在 Windows 終端機執行 ipconfig /flushdns，接著完全關閉並重新開啟瀏覽器，避免舊快取影響檢查結果。
2. 執行下方的查詢，確認系統目前使用的解析鏈路是否回傳位址池中的位址。不要在查詢中指定外部 DNS，否則測到的就不是原本的系統路徑。
3. 連線至同一個網域名稱，查看核心記錄中的目標網域名稱與出站標籤。必要時可暫時提高記錄層級，驗證後再恢復，避免長期記錄過多瀏覽資訊。
4. 再檢查一個應該直連的目標，確認沒有把虛擬 IP 當成最終伺服器位址；同時確認本機路由器與內網服務仍可存取。

ipconfig /flushdns
nslookup example.com
route print

nslookup 適合檢查一般 DNS 查詢，不代表瀏覽器內建 DoH 的實際行為。route print 可用來檢查虛擬網段的路由歸屬；若清單中沒有單獨列出該網段，也不能立刻判定接管失敗，因為某些 TUN 設定會使用範圍更大的路由。請搭配介面、躍點與用戶端記錄一起判斷。

常見問題：快取、IPv6 與關閉後的復原

FakeDNS 的作用是在特定接管鏈路中保留網域資訊。它不會改變 VMess、VLESS 的驗證參數，也無法修復失效的訂閱或無法連線的節點。請先確認基本連線穩定、確實需要網域分流，且能驗證並還原設定，再考慮啟用。若只是瀏覽器偶爾卡頓，應先依常見問題中的系統代理、DNS 與路由步驟逐步排查。