FakeDNS 透過本機配置的虛擬位址保留網域資訊，不是公共 DNS，也不是新的代理協定。本文適合已能正常連線、準備調整 TUN 與網域分流的使用者：先了解查詢與連線如何串接，再確認設定限制，最後逐項排查快取、DNS 接管與區域網路存取。若沒有明確需求，維持目前可用的真實位址解析方式即可。
FakeDNS 原理：虛擬位址是映射索引
一般 DNS 查詢會將網域解析為目標服務的真實位址。FakeDNS 則從本機位址池挑選一個位址，記錄「網域與虛擬 IP」的對應關係，再將虛擬位址回傳給應用程式。例如，應用程式查詢 example.org 的 A 記錄時，可能會取得 198.18.0.1。這只是示範位址，實際分配順序取決於實作方式與執行狀態。
接著，應用程式會連線至這個虛擬 IP。接管流量的元件讀取目標位址後，查出對應網域，再交由路由與出站規則處理。因此，FakeDNS 的重點不只是「回覆特殊 IP」，而是 DNS 查詢與後續連線都必須經過能共用或使用這份映射資料的處理鏈。
198.18.0.0/15 是保留供基準測試使用的位址範圍，涵蓋 198.18.0.0 至 198.19.255.255，不是一般的公網服務位址。FakeDNS 常使用這個範圍，但不同實作也可能採用其他位址池。若虛擬位址未經接管便直接送往實體網路，通常無法連到原本的網站。
TUN 與網域分流：接管、還原、比對缺一不可
TUN 會在網路層接收 IP 封包。剛接管連線時，通常只取得目標 IP、連接埠與傳輸協定等資訊。若應用程式已完成網域解析，封包中可能不再直接帶有網域名稱。FakeDNS 會預先保存「這個位址原本對應哪個網域」，為網域規則提供線索。
- 接管 DNS：應用程式的查詢必須進入預期的 DNS 處理鏈。傳統 DNS 常使用 UDP 53，也可能使用 TCP 53；只處理其中一種，不代表所有查詢都已接管。
- 接管連線：前往虛擬位址池的 TCP 或 UDP 流量，必須進入相應的 TUN、路由與核心處理鏈，不能被排除規則提前放行。
- 還原網域：接收連線的元件必須能使用映射資料。Xray 的相關設定涉及 FakeDNS 與入站嗅探；只在 DNS 清單中新增一個名稱，並不足以完成整個流程。
- 套用規則：還原網域後，再依網域規則、IP 規則與預設規則決定出站路徑。VMess、VLESS 等協定負責後續代理傳輸，不負責建立這份映射。
瀏覽器透過系統 HTTP 代理存取 HTTPS 網站時，可以在 CONNECT 請求中帶上目標主機名稱；SOCKS5 也支援網域位址類型。這類連線可能已將網域資訊交給代理，不一定需要使用 FakeDNS。相對地，若應用程式先在本機解析網域、只傳送 IP，就需要另外確認如何取得網域資訊。
判斷方式：先確認網域是否已傳到路由層
若目前的系統代理連線已能依網域命中規則，先維持現狀。只有在 TUN 接管後網域資訊不足，而且 DNS 與連線都能進入同一套處理鏈時，再評估是否使用 FakeDNS。
設定檢查：位址池與還原入口必須配套
v2rayN 是桌面用戶端，v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。用戶端介面、所選核心與 TUN 接入元件分屬不同層級，不能只看用戶端名稱就判斷設定欄位是否適用。以下鍵值用來說明 Xray 的設定關係，不代表三款用戶端都提供相同名稱的開關，也不能直接當成完整設定匯入。
虛擬位址分配端
- 設定物件
fakedns- 位址池範例
198.18.0.0/15- 容量範例
poolSize: 65535- DNS 服務項目
fakedns
容量只是範例參數，不代表節點數或可支援的同時連線數；定義位址池後，也必須讓相關查詢實際使用它。
連線還原端
- 入站設定
sniffing- 啟用欄位
enabled: true- 還原類型
destOverride: ["fakedns"]- 接管範圍
- 套用至虛擬位址池的連線
應檢查實際承接流量的入站，而不是替沒有流量經過的入站新增欄位。
以下是 Xray 原生 JSON 的分配端片段，只展示位址池與內建 DNS 的關聯。內容缺少入站、出站、路由與接管設定，不能取代用戶端產生的完整檔案。若用戶端使用其他元件處理 TUN 與 DNS，請依該元件的設定格式操作，不要混用欄位。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}- 先備份目前設定，再檢查實際產生的執行設定。介面顯示「啟用 TUN」，不代表 FakeDNS 也已啟用。
- 確認用戶端啟動時沒有未知欄位、設定解析失敗或位址池衝突。無法通過檢查的設定應立即還原，並避免同時修改節點協定參數。
- 檢查 A 與 AAAA 查詢的處理方式。上述 IPv4 位址池範例，不代表 IPv6 查詢也會取得相應的虛擬映射。
- 分別檢查直連與代理出站如何處理還原後的網域。若最終連線需要真實位址，仍須有可用的解析路徑，避免查詢反覆回到虛擬位址分配端。
適用情境與副作用：虛擬 IP 不適用所有應用程式
FakeDNS 可減少部分連線在本機取得真實位址的需求，也能協助網域規則辨識已轉為 IP 連線的請求。但它不會自動縮短遠端解析時間，也無法修復節點無法使用、TLS 參數錯誤或路由規則順序不當等問題。是否值得使用，應看網域辨識與應用程式相容性，而非只看 DNS 回覆是否變快。
| 情境 | 主要影響 | 處理建議 |
|---|---|---|
| 在 TUN 下依網域分流 | 映射可為 IP 連線補回網域資訊 | 確認 DNS、虛擬網段與還原入口的整個流程正常 |
| 區域網路服務與內部網域 | 名稱探索或內網解析可能遭到錯誤接管 | 為內部網域與網段保留真實解析及直連路徑 |
| 企業網路使用相同網段 | 虛擬位址池可能與現有路由衝突 | 檢查路由表，視實作支援情況更換位址池或關閉功能 |
| 應用程式會檢查解析結果 | 程式可能拒絕保留位址，或將虛擬位址存入快取 | 讓該應用程式改用真實位址解析，再測試登入與連線 |
| 應用程式使用加密 DNS | 查詢可能繞過一般 53 連接埠的接管 | 檢查應用程式的 DNS 設定，勿將加密連線誤當成一般 DNS 強制重新導向 |
直接連線至 IP 位址的程式不會先查詢網域，FakeDNS 無法憑空補出網域資訊。區域網路的多點傳送名稱探索也不同於一般單點傳送 DNS；只調整 53 連接埠規則，不一定能解決列印、檔案共用或內部服務探索問題。
取捨建議：內部服務優先使用真實解析
若工作網路依賴內部 DNS，請先確認內部網域、DNS 伺服器及相關網段的解析與連線路徑。若登入或服務探索異常，先停用 FakeDNS 還原設定，不要藉由擴大代理範圍掩蓋問題。
驗證流程：分別檢查 DNS、映射與出站
驗證時請使用同一個測試網域，固定節點與路由規則，每次只變更一項設定。看到虛擬位址，只能證明某次查詢取得了虛擬回覆；網站能開啟，也不代表所有應用程式都經過相同的處理鏈。請一併檢查解析結果、接管記錄與規則命中狀況。
- 建立基準：關閉 FakeDNS，記錄測試網域是否可連線、目前的 DNS 結果與出站規則。保留可還原的設定，不要修改訂閱中的伺服器位址。
- 驗證查詢：啟用後查詢同一個網域，確認 A 記錄是否落在實際設定的虛擬位址池。若結果仍是真實 IP，先檢查快取、應用程式內建 DNS 與 DNS 路由，不要急著修改位址池。
- 驗證還原：建立新連線，檢查記錄是否能對應到原始網域及預期的出站路徑。若只看到虛擬 IP 被直接連線，應優先檢查還原入口與網段路由。
- 驗證相容性：分別測試網頁、內部服務與一款非瀏覽器應用程式。UDP 應用程式也要另外測試；網頁的 TCP 連線成功，不能取代 UDP 驗證。
在 Windows 上，可先查看系統目前取得的解析結果，切換方案後再清除系統 DNS 快取。以下兩個指令分別用於查詢與清除快取；它們不是效能測試，也沒有固定的預期位址。
nslookup example.org
ipconfig /flushdns清除系統快取，不代表瀏覽器或應用程式的內部快取也已清除。關閉 FakeDNS 或重新啟動映射元件後，應用程式可能仍保留舊的虛擬位址；若映射已失效，舊連線就會失敗。還原設定時，應先停止相關應用程式、清除系統快取，再重新開啟應用程式測試。
常見問題：啟用後異常的排查方式
解析結果以 198.18 開頭，代表 DNS 出錯了嗎？
先確認實際使用的位址池。啟用 FakeDNS 且設定使用 198.18.0.0/15 時，這可能是正常回覆。接著建立連線，查看網域還原與出站記錄；若已關閉功能卻仍回傳這類位址，請清除系統與應用程式快取，並檢查是否仍有其他 DNS 接管元件在執行。
為什麼啟用後瀏覽器能用，其他應用程式卻無法連線？
分別確認應用程式是否使用獨立 DNS、是否未納入 TUN 接管，以及是否拒絕保留位址。先讓異常的應用程式改用真實位址解析，再重新啟動測試。不要只因瀏覽器連線成功，就擴大所有應用程式的接管範圍。
啟用 FakeDNS 後，就不需要設定遠端 DNS 了嗎？
不是。虛擬位址分配端只負責本機映射；直連出站或遠端代理建立實際連線時，仍可能需要解析網域。請檢查負責最終解析的元件與 DNS 出站，避免代理伺服器網域的解析依賴尚未建立的代理連線。
關閉後還是無法開啟網頁，需要重新安裝用戶端嗎？
先還原原本的 DNS 與接管設定，執行 ipconfig /flushdns，再關閉並重新開啟瀏覽器。接著確認系統代理是否仍指向已停止的本機服務。Android 端請先停止並重新啟動用戶端的 VPN 連線及相關應用程式，再次測試；通常應先排除舊快取與殘留的接管狀態。
最終判斷標準是連線流程清楚可查、網域規則能正常命中，且日常使用的應用程式穩定。FakeDNS 只是 DNS 與流量接管之間的一種搭配方式；訂閱匯入、節點選擇、系統代理與 TUN 仍須分別確認。