FakeDNS 虛擬 DNS 映射原理詳解：哪些情境適合啟用、哪些情境應避免

FakeDNS 解決的不是「解析更精準」，而是網域身分遺失

應用程式存取網域時，通常會先向 DNS 查詢真實位址，再連線至回傳的 IP。進入代理核心的連線若只剩目標 IP，網域資訊可能早已遺失。此時，依 geosite、完整網域或網域後綴撰寫的路由規則便無法直接比對，只能依賴目標 IP、協定嗅探結果或其他補充資訊。

FakeDNS 的作用，是在 DNS 階段先回傳暫時性的虛擬位址，並在核心內部保存「網域—虛擬位址」的對應關係。應用程式接著連線至該虛擬位址時，核心可以反向找回原始網域，再依網域規則決定直連、代理或阻擋。它本質上是一張短期映射表，不是公共 DNS 服務，也不會將虛擬位址發布到網際網路。

Xray 常見的 FakeDNS 位址池會使用專用保留的 IPv4 網段，例如 198.18.0.0/15。該位址段不會成為目標網站的真實位址，只在本機或受控網路堆疊內充當索引。實際的位址池、容量與處理方式取決於核心設定及用戶端版本，不應將某個預設值視為所有環境都固定不變的參數。

一次請求如何經過虛擬位址映射

以 v2rayN 的 TUN 模式為例，瀏覽器準備存取 docs.example.net。啟用 FakeDNS 且 DNS 流量已由 TUN 接管後，完整流程大致分為六個步驟：

1. 應用程式向系統發起 docs.example.net 的 DNS 查詢。
2. TUN 網路堆疊攔截查詢，並將其交給核心設定中的 DNS 處理鏈。
3. FakeDNS 從位址池分配一個虛擬 IP，同時記錄該 IP 對應的原始網域。
4. 應用程式收到虛擬 IP，接著像連線至一般位址一樣發起 TCP 或 UDP 流量。
5. TUN 再次攔截該連線。核心查詢映射表，還原出 docs.example.net。
6. 路由模組依網域規則選擇出站；實際需要的目標解析則由相應的出站鏈路繼續完成。

應用程式查詢網域
    ↓
TUN 攔截 DNS
    ↓
FakeDNS 回傳虛擬 IP，並儲存映射
    ↓
應用程式連線至虛擬 IP
    ↓
核心還原原始網域
    ↓
網域路由比對 → 選擇直連或代理出站

這裡所說的「減少一次 DNS 往返」，是指應用程式在建立連線前不必等待公共上游回傳真實 IP。FakeDNS 可以在本機立即提供映射結果。但這不代表整個存取過程完全不再解析網域。代理出站可能將網域交由遠端解析，直連出站也可能依設定呼叫指定 DNS。省略的是前置階段的一次真實位址查詢，不是所有鏈路上的網域解析。

映射具有生命週期。快取過期、核心重新啟動、設定重新載入或位址池項目被回收後，舊的虛擬位址可能失去對應關係。因此，不應將 FakeDNS 回傳值儲存為長期業務資料，也不適合複製到其他裝置使用。

FakeDNS、嗅探與真實 DNS 的分工

網域嗅探與 FakeDNS 經常同時出現，但兩者取得網域的時機不同。嗅探是在連線已進入核心後，嘗試從協定資料中擷取目標名稱，例如 HTTP 請求中的 Host，或 TLS 交握中的伺服器名稱。FakeDNS 則更早介入，在應用程式查詢 DNS 時建立明確的映射。

嗅探依賴流量中存在可識別的欄位。協定行為改變、加密交握形式變化、應用程式直接連線 IP，或首個封包不含可用網域時，嗅探結果可能為空。FakeDNS 不需要從業務負載猜測網域，只要 DNS 查詢與後續連線都經過同一套受控網路堆疊，就能沿著映射表還原名稱。

真實 DNS 仍負責找出最終可連線的目標位址。FakeDNS 只是將「應用程式先解析、再連線真實 IP」的順序改為「應用程式取得虛擬 IP、核心還原網域、出站階段再解析」。這項變化讓解析位置可以跟隨路由結果：代理網域可由代理鏈路處理，直連網域可交由本地選定的 DNS，從而減少解析結果與實際出站位置不一致的問題。

TUN 模式下適合啟用的情境

依網域進行精細路由

當規則主要依賴 geosite、網域後綴或完整網域時，FakeDNS 最能發揮價值。即使應用程式原本只會將真實 IP 交給網路堆疊，核心仍可透過虛擬位址映射找回網域。對於「指定網站走代理、常用的台灣本地域名直連，其餘依預設規則處理」這類設定，網域身分越穩定，比對結果就越容易理解。

希望解析位置跟隨出站

同一個網域在不同網路位置可能回傳不同位址。先由本地 DNS 解析，再將真實 IP 交給代理鏈路，可能造成解析位置與連線位置分離。FakeDNS 讓應用程式先取得虛擬位址，等核心確定出站後再處理真實解析。對於需要由代理端完成網域解析的連線，這種順序通常更合理。

接管不支援單獨設定代理的程式

TUN 模式可以承接沒有 HTTP 或 SOCKS 代理選項的程式。此時，FakeDNS 與 TUN 配合，可讓這些程式的一般系統 DNS 查詢及後續連線進入同一處理路徑。只要程式遵循系統網路堆疊，且流量確實受到接管，網域規則就能取得較完整的比對條件。

降低對協定嗅探的單點依賴

嗅探仍可作為輔助資訊，但不必獨自承擔網域還原任務。對於連線建立快速、首個封包特徵不穩定或使用 UDP 傳輸的應用程式，預先建立的 FakeDNS 映射通常更直接。需要注意的是，FakeDNS 不會讓所有 UDP 協定自動相容；它只負責目標映射，協定本身能否經由目前的出站傳輸，仍取決於節點、核心與路由設定。

以下情境應關閉或繞過 FakeDNS

區域網路名稱與分流 DNS 依賴真實結果

企業內網、家庭裝置名稱、路由器管理網域與分區 DNS，經常依賴區域網路解析器回傳私有位址。若這些查詢被 FakeDNS 提前替換，應用程式可能無法取得服務探索所需的真實記錄。通常應讓內網網域、私有位址段及指定 DNS 伺服器直連，並從 FakeDNS 規則中排除。若排除關係難以確認，關閉 FakeDNS 後先驗證內網存取會更穩妥。

應用程式會讀取或驗證 DNS 回傳內容

部分診斷工具、網路管理程式、網域解析測試程式與業務用戶端，不只是取得位址後建立連線，還會顯示、儲存、比較或驗證 DNS 回應。它們需要看到 A、AAAA 或其他記錄的真實內容。虛擬位址會改變這類程式觀察到的資料，因此不適合參與相關查詢。

連線沒有經過同一套 TUN 映射鏈

FakeDNS 的前提是「查詢時寫入映射，連線時讀取映射」。如果 DNS 查詢被攔截，但後續連線繞過 TUN，應用程式會嘗試將虛擬位址直接送往一般網路；反過來，如果連線進入 TUN，而 DNS 查詢由其他裝置或獨立加密解析通道完成，核心也可能無法取得映射。兩段路徑不一致時，應先統一接管範圍；無法統一則關閉 FakeDNS。

需要將解析結果交給其他裝置

虛擬位址只在產生它的映射實例中有效。將該位址寫入設定檔、傳送給區域網路中的其他主機、用於連接埠探測，或在核心重新啟動後繼續重複使用，都可能導致失敗。旁路由部署尤其要確認 DNS 回應與後續連線是否始終回到同一實例。若用戶端可能改走其他閘道，回傳真實位址更容易維持行為一致。

排除問題時需要觀察原始解析鏈

當問題集中在上游 DNS、分流 DNS、網域污染、快取，或 IPv4 與 IPv6 的選擇時，FakeDNS 會增加一層轉換。此時可以暫時關閉它，直接觀察查詢送往哪台伺服器、回傳哪些記錄，以及連線選擇哪個位址。確認真實解析鏈正常後，再重新啟用映射並比較差異。

在 v2rayN 中啟用前的檢查順序

v2rayN 不同版本對 TUN、DNS 與核心設定的入口編排可能調整，選項名稱也可能隨核心能力變化。與其照抄某張舊版介面截圖，不如依資料路徑進行檢查。以下順序適用於大多數設定：

1. 確認 TUN 確實正在執行。 先觀察一般應用程式流量是否進入核心，避免在接管尚未成功時再增加 DNS 變數。
2. 確認 DNS 查詢進入 TUN。 系統中殘留的獨立 DNS 工具、瀏覽器內建解析設定或其他網路服務，可能讓查詢繞過映射鏈。
3. 檢查私有網路排除項目。 區域網路網域、閘道位址、印表機與內部服務，應依實際環境決定直連或排除。
4. 簡化路由規則。 初次測試只保留明確的直連、代理與預設規則，避免多個規則集同時影響判斷。
5. 再啟用 FakeDNS。 重新載入設定後重新發起查詢，不要用應用程式快取中的舊位址判斷結果。
6. 查看記錄中的網域與出站。 重點確認核心是否還原原始網域，以及該網域最終符合哪一條路由。

如果 v2rayN 使用訂閱節點，FakeDNS 與節點協定並不屬於同一層級。VMess、VLESS 等節點參數決定代理出站如何連線至伺服器；FakeDNS 位於本地 DNS 與路由處理環節。節點能夠連線，不代表 FakeDNS 設定一定正確；FakeDNS 映射正常，也無法修復伺服器位址、連接埠、安全層或傳輸參數錯誤。

同樣地，Android 上的 v2rayNG 使用 Xray 核心時，也要區分本地 VPN 接管、DNS 設定與節點協定。v2flyNG 使用 v2fly 核心，實際可用功能應以核心與用戶端目前的實作為準。不要將某個桌面設定欄位原樣搬到另一個核心，再假設行為完全一致。

如何定位常見故障

啟用後所有網域都無法開啟

先檢查 DNS 查詢是否進入 FakeDNS，再檢查虛擬位址對應的連線是否受到 TUN 攔截。若系統路由將保留位址段送往一般網卡，映射就無法在核心內部形成閉環。也應查看位址池是否與本地既有網路、虛擬機網路或其他通道設定衝突。

網頁可以存取，但區域網路裝置失去連線

這通常不是節點故障，而是內網名稱或私有位址被納入錯誤的處理範圍。檢查區域網路網域是否應交由本地 DNS 處理、私有網段是否直連，以及本地服務探索流量是否需要留在實體網路中。先為明確的內網範圍建立排除，再測試裝置名稱與直接 IP 存取的差異。

記錄中只有虛擬 IP，沒有原始網域

這表示連線階段未能成功讀取映射。可能原因包括查詢與連線使用不同的核心實例、映射已過期、應用程式重用了舊快取，或某段流量繞過 TUN。關閉應用程式後清除系統 DNS 快取，重新載入核心，再進行一次全新的查詢與連線，通常比反覆重新整理同一頁面更容易取得有效記錄。

規則命中結果與預期相反

確認規則順序。路由通常依設定順序進行比對，較寬泛的 IP、連接埠或網域規則若排在前面，可能提前接管連線。還要區分 FakeDNS 還原的網域、嗅探取得的網域，以及最終解析出的 IP。排除問題時一次只保留一種主要判斷條件，定位後再恢復組合規則。

執行一段時間後偶爾失敗

觀察失敗是否發生在休眠恢復、網路切換、核心重新載入或長時間維持連線之後。這些事件可能讓應用程式快取的虛擬位址與目前映射表不同步。關閉並重新開啟應用程式、重新整理 DNS 快取、重建 TUN，有助於確認問題是否來自過期映射。如果頻繁發生，也應檢查位址池容量，以及是否存在大量短期網域查詢。

最終選擇：依流量路徑決定，而不是依開關名稱決定

FakeDNS 適用的條件很明確：DNS 查詢與後續連線由同一條 TUN 鏈路接管，路由需要穩定取得網域，而且最終解析可以延後至出站階段完成。在這種結構中，它能減少應用程式連線前的一次真實 DNS 等待，並讓 geosite、網域後綴及完整網域規則取得更可靠的輸入。

應關閉或繞過的條件同樣明確：程式必須讀取真實 DNS 記錄、區域網路依賴分流解析、虛擬位址會被傳送給其他裝置，或無法確保查詢與連線進入同一映射實例。FakeDNS 不是預設越多越好的加速功能，而是一種改變解析順序的路由工具。

實際設定時，先讓 TUN、真實 DNS 與基礎路由獨立運作，再加入 FakeDNS。每次只變更一個環節，並透過記錄確認「查詢、映射、連線、路由、出站」五個階段。如此即使發生問題，也能判斷故障是在 DNS 接管、映射還原還是規則比對，而不是把所有異常都歸咎於節點品質。