FakeDNS 以虛擬位址保留網域資訊，適合在 TUN 接管流量後仍須依網域分流的情況。它不是加速功能，也不能取代真實 DNS 解析。本文依序說明「回傳位址、接管連線、還原網域、選擇出口」的運作方式，再整理啟用條件、設定檢查項目與還原步驟，適合已能正常連線，準備調整 DNS 和路由的使用者。
FakeDNS 如何保留網域資訊
一般 DNS 查詢會將網域解析為目標伺服器的位址。應用程式接著建立連線，系統網路層通常只會看到目標 IP；若多個網域共用同一個位址，光靠 IP 很難判斷應用程式原本要連線的網域。FakeDNS 會改變回覆方式：先配置一個虛擬 IP，並在本機記錄該位址對應的網域。
例如，應用程式查詢 example.com 時，FakeDNS 會從位址池配置一個位址。應用程式連線至該位址後，代理核心會依據對應表找回 example.com，再以網域比對路由規則。這個位址只是本機處理流程中的標記，不是網站伺服器的新位址，更不能直接當作遠端節點位址使用。
虛擬位址池與真實 DNS 的差異
在 Xray 的 FakeDNS 設定中，常見的 IPv4 位址池範例是 198.18.0.0/15。範圍涵蓋 198.18.0.0 至 198.19.255.255，屬於保留給網路效能測試的位址空間，並非可直接連線的公網目標。請勿將它與家用區域網路的私有位址範圍混為一談。
位址池範圍與對應容量是兩回事。網段內的位址數量，不代表目前的核心一定會保留同等數量的對應資料。容量、回收策略，以及重新啟動後是否保留對應，都取決於具體實作；請勿將特定範例中的容量值視為所有用戶端的預設值。
- 虛擬回覆：先讓應用程式取得可供本機辨識的目標標記，不必立即取得網站的真實 IP。
- 真實解析：連線最終仍須抵達實際服務。若以網域交由遠端代理處理，可由遠端解析；直連時通常仍須在本機進行真實解析。
- 加密 DNS：處理的是 DNS 查詢的傳輸方式；是否回傳虛擬 IP 則是另一個層面，兩者不能互相取代。
TUN 模式如何搭配網域分流
TUN 會將符合路由條件的 IP 流量送入虛擬網卡，但不會自動保留應用程式查詢過的網域。FakeDNS 的作用，是讓核心有機會將目標虛擬 IP 還原為網域，再比對網域規則。對於不使用系統 HTTP 代理、但能由 TUN 接管的應用程式，這項功能尤其實用。
TUN 搭配虛擬位址
- DNS 回覆
- 由支援對應功能的元件回傳虛擬 IP
- 流量入口
- 虛擬網卡及其相關路由
- 網域資訊來源
- 查詢與連線之間的位址對應
- 檢查重點
- 位址池的流量是否回到同一處理流程
TUN 負責接管流量，對應資料負責還原網域；兩者都正常才能完成整個流程。
系統代理會傳遞網域資訊
- DNS 回覆
- 不一定需要虛擬位址
- 流量入口
- 應用程式使用的 HTTP 或 SOCKS 代理
- 網域資訊來源
- 代理請求中包含的目標主機名稱
- 檢查重點
- 應用程式是否將網域交由代理處理
如果應用程式已將網域交給代理處理，通常不必使用 FakeDNS。
網域還原後，最終使用哪個出口仍由路由規則決定。FakeDNS 不會自動將所有流量改走代理，也不會建立直連白名單。網域規則、IP 規則及其順序仍可能影響比對結果；若依 IP 地理資訊分流，也要確認規則採用的位址是否為經過真實解析的目標位址。
哪些情況適合啟用 FakeDNS
先判斷目前的連線缺少哪些資訊，再決定是否啟用。一個實用的判斷標準是：應用程式的連線可由 TUN 接管，但核心記錄中只看得到目標 IP，導致預期的網域規則無法命中；同時，應用程式的 DNS 查詢也能納入同一個處理流程。符合這兩項條件，才值得測試。
| 使用情境 | 建議 | 優先檢查 |
|---|---|---|
| 由 TUN 接管，主要依賴網域規則 | 可測試啟用 | DNS 查詢與虛擬位址連線都由 TUN 接管 |
| 瀏覽器正常使用系統代理 | 通常維持目前設定即可 | 代理請求是否已包含網域資訊 |
| 辦公室 VPN 與內部網域並用 | 先規劃排除項目 | 企業 DNS、內部網段及路由優先順序 |
| 應用程式需要儲存或驗證真實 IP | 建議使用真實解析 | 虛擬位址是否會影響應用程式判斷 |
| 目標本身就是 IP 位址 | 無法透過對應資料補出網域 | 直接依 IP 規則處理連線 |
FakeDNS 可能減少「先等待真實解析，再決定如何轉送」的依賴，但不能因此保證下載速度或連線延遲有所改善。應用程式若自行使用加密 DNS，查詢也可能繞過本機對應服務；即使一般 DNS 請求已由 TUN 接管，應用程式仍可能取得真實 IP，而非虛擬 IP。
啟用前，檢查處理流程的四個項目
在 v2rayN 桌面版中，先從「設定」確認目前的 TUN、DNS 和路由選項；實際子選單名稱請以使用版本的介面為準。Android 版 v2rayNG 使用 Xray 核心，但 VPN 授權成功只代表應用程式能建立流量入口，並不表示 FakeDNS 對應已正常運作。兩個平台都應先記錄原有設定，避免同時變更多個項目。
- 備份目前設定。記下 DNS 伺服器、路由規則及使用的核心資訊。先確認停用 FakeDNS 時節點可正常使用，以免將原有連線故障誤認為對應問題。
- 確認 DNS 入口。確認目標應用程式的查詢經過哪個解析器。傳統 DNS 通常使用 UDP 或 TCP 的
53埠；僅檢查這個埠，無法判斷瀏覽器是否使用內建的加密 DNS。 - 確認位址池路由。若使用
198.18.0.0/15，請確認辦公室網路未使用此網段，且規則沒有提前將流量排除、送往實體網卡。特殊網路環境可能確實會用到這個範圍，若有衝突就不能直接照搬。 - 確認網域還原設定。查看目前核心的入站、嗅探或對應設定，確認能否從虛擬 IP 找回網域。Xray 的
fakedns、ipPool、poolSize等欄位用途各異，不能只新增位址池，卻忽略接收並使用對應資料的入站設定。
嗅探與 FakeDNS 也不是同一回事。嗅探可能從 HTTP 主機名稱或 TLS 交握資訊辨識網域；位址對應則依賴先前記錄的 DNS 查詢。不同流量能提供的資訊不一樣，不能假設所有加密連線都能靠嗅探找回網域。用戶端自動產生設定時，手動修改產生的檔案也可能在下次啟動時被覆寫。
如何確認虛擬 IP 與規則命中
測試時只選一個一般網域和一個需要直連的內部網路目標。先關閉現有連線，再重新查詢並連線；不要只憑已開啟的網頁判斷結果，因為連線重用和 DNS 快取可能仍沿用修改前的資料。
- 第一步，檢查查詢結果。在 Windows 執行
nslookup example.com。若該工具使用的解析路徑確實經過 FakeDNS，回覆位址應落在已設定的位址池內；結果不同不一定代表功能失效，請先確認工具使用的解析路徑是否與應用程式相同。 - 第二步，檢查核心記錄。重新連線至網域，確認記錄是否顯示原始網域、命中的規則及使用的出口。依記錄層級不同，可查看的欄位也會不同；必要時可暫時提高記錄層級，完成後再還原。
- 第三步，檢查直連目標。測試內部網域和區域網路服務，確認沒有被錯誤地送往代理。記下「網域、解析結果、命中的出口、是否連線成功」，每次只調整一個設定。
直連衝突與停用後的還原步驟
最常見的故障情況是：應用程式取得了虛擬 IP，連線卻走上不認得對應資料的路徑。例如，某個處理程序被排除在 TUN 之外，卻仍使用已被接管的系統 DNS；或企業 VPN 接管了位址池網段。這類問題與節點速度無關，反覆更換節點通常無法解決。
啟用後只有一個直連應用程式無法開啟，該怎麼處理？
先確認該處理程序是否被排除在 TUN 之外。若必須直連，請讓它取得真實 DNS 回覆，並確保相關連線也走直連路徑。DNS 與流量的排除設定必須配套；不能只排除處理程序，卻仍提供虛擬位址。
停用 FakeDNS 後仍然逾時，為什麼？
應用程式或系統可能仍快取舊的虛擬 IP。還原原本的 DNS 設定後，請重新啟動受影響的應用程式；在 Windows 命令提示字元執行 ipconfig /flushdns，即可清除系統 DNS 快取，再重新連線。瀏覽器自身的快取和既有長連線可能也需要另外重建。
重新啟動用戶端後，部分連線突然失敗怎麼辦？
請確認是否發生「應用程式仍保留舊的 DNS 結果，但核心的對應表已重新建立」的情況。先關閉舊連線、清除相關快取，再重新查詢。部分實作可能會持久保存對應資料，是否支援須視目前使用的後端而定，不能假設重新啟動前後的對應完全一致。
看到虛擬 IP，就代表 DNS 一定沒有外洩嗎？
不是。這只能表示這次查詢取得了虛擬回覆。其他應用程式、其他記錄類型，或瀏覽器自己的解析路徑仍可能不同。請分別檢查系統解析器、應用程式的加密 DNS，以及 IPv6 的 AAAA 查詢，再搭配實際路由判斷。
若目標是穩定連線，而非驗證對應機制，建議保留容易理解、能夠還原的設定：系統代理已能正確傳遞網域時，不必額外啟用 FakeDNS；確實需要 TUN 網域分流時，再逐項確認 DNS、對應、路由和出口。若遇到無法判斷原因的連線故障，可依照連線故障疑難排解步驟繼續檢查，不要同時調整所有網路選項。