2026-10-17 · 進階原理 · 約 10 分鐘

FakeDNS 原理與設定指南：適用情境及注意事項

了解 FakeDNS 如何以虛擬 IP 保留網域資訊，掌握它在 TUN 模式與網域分流中的用途，以及可能與特定應用程式或 DNS 快取發生的衝突。

本文重點

FakeDNS 適合用來解決透明接管流量後只剩目標 IP、無法取得原始網域的問題。本文適合已使用 v2rayN 或 v2rayNG，並準備調整 TUN 或 VPN 分流的使用者，說明虛擬位址對應的運作方式、哪些查詢仍須進行真實解析，以及如何透過記錄與清除快取驗證效果。若目前網域分流正常，不必只為了多一個選項而啟用 FakeDNS。

FakeDNS 原理：以虛擬 IP 保留網域資訊

FakeDNS 不是代理協定，也不是加密 DNS。一般 DNS 會將網域解析為實際服務位址；FakeDNS 則從專用位址池配置一個虛擬 IP，並記錄網域與虛擬 IP 的對應關係。應用程式接著連線至這個位址時，接管流量的核心會透過對應紀錄找回原始網域，再執行路由與輸出處理。

查詢網域 配置虛擬位址 應用程式發起連線 透過對應還原網域 依規則選擇出口

Xray 在這個流程中必須同時處理 DNS 查詢與後續連線。例如，應用程式查詢 example.com 後，取得位址池中的 198.18.0.1；接著，送往這個位址的連線必須重新進入保存對應紀錄的核心。這個位址僅為配置結果示意，並非該網域的實際位址，也不是應填入節點設定的伺服器位址。

TUN 與網域分流：FakeDNS 解決哪個環節的問題

v2rayN 的系統代理通常由應用程式主動使用 HTTP 或 SOCKS 代理，並有機會直接將網域傳給代理端。TUN 接管的則是網路層封包，核心看到的目標可能已是解析後的 IP。FakeDNS 的用途，是在這種情況下保留可供網域規則比對的資訊。

v2rayNG 透過 Android VPN 介面接收裝置流量，但 VPN 接管不代表會自動啟用 FakeDNS。DNS 是否進入核心、核心是否配置虛擬位址，以及連線是否還原網域，是三個各自獨立的條件。TLS 或 HTTP 嗅探也能提供部分網域資訊，但受協定與應用程式行為限制，不能視為適用於所有連線的可靠替代方案。

明確使用代理的路徑

流量入口
HTTP 或 SOCKS 入站
網域資訊來源
應用程式提交的目標網域
檢查重點
應用程式是否使用代理，以及是否由遠端解析
啟用判斷
網域已完整傳遞時，通常不必再啟用 FakeDNS

SOCKS 應用程式也可能先在本機解析，只提交 IP；不能只根據代理類型判斷。

TUN 與 VPN 路徑

流量入口
虛擬網路介面
網域資訊來源
FakeDNS 對應資訊或其他可用中繼資料
檢查重點
DNS 接管與虛擬位址路由
啟用判斷
需要穩定依網域分流時，可評估啟用

只有 DNS 查詢與後續連線都受到接管，虛擬位址對應才能發揮作用。

VLESS 與 VMess 負責代理連線，FakeDNS 則負責本機 DNS 與目標資訊處理；切換代理協定不會自動修復對應流程。v2flyNG 使用 V2Fly 核心，設定能力與欄位支援應以實際核心為準，不能將 Xray 範例直接當成三款用戶端通用的設定。

位址池與設定欄位：先弄懂三個數字

53
傳統 DNS 的 UDP／TCP 服務埠
131072
IPv4 /15 網段包含的位址總數
65535
下方設定範例中的 poolSize 值

Xray 的 FakeDNS 設定可使用 198.18.0.0/15 作為 IPv4 位址池。這個網段屬於供基準測試使用的特殊用途位址空間，並非可直接連線至公網服務的一般位址。網段包含的位址總數與 poolSize 是不同概念：前者由前綴長度決定，後者則控制實作中的對應池容量。

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

這段 Xray 範例只展示頂層位址池定義，並非可獨立執行的完整設定。實際套用還需要設定內建 DNS 的 fakedns 伺服器項目，以及接收連線的入站中相應的網域還原設定，例如支援 fakedns 的 sniffing.destOverride。只貼上位址池，不會自動將系統 DNS 導向 FakeDNS。

適用情境：哪些流量值得啟用

FakeDNS 較適合依賴網域規則，且難以直接從應用程式取得網域資訊的透明接管情境。它可降低預先進行真實解析對網域辨識的影響，但不保證網頁一定會變快。最終出口、伺服器可連線性與實際目標解析，仍會影響連線結果。

使用情境建議驗證重點
TUN 接管後依網域選擇出口適合評估啟用記錄可還原網域，且連線符合預期規則
瀏覽器使用明確代理，且已傳遞網域維持現狀也可以確認應用程式是否已將網域交給代理
公司內部網域與私有位址存取先設定真實解析例外內部 DNS、回傳位址與直連路由彼此相符
應用程式直接連線至固定 IPFakeDNS 無法補回原始網域改用 IP 規則或其他適合該應用程式的規則
應用程式內建加密 DNS先確認查詢是否繞過內建 DNS只接管 53 埠，無法涵蓋應用程式內的查詢

處理內部網域時尤其要謹慎使用 FakeDNS。公司服務可能必須透過指定 DNS 才能取得私有位址；讓這些查詢採用真實解析，再為相關連線設定直連，通常更容易維持原有的存取方式。例外設定必須依目前的 DNS 與路由實作配置，不能只新增一條直連規則，就認定解析路徑也會跟著改變。

啟用前檢查：一併確認 DNS、出口與快取

  1. 記錄目前設定。記下用戶端版本、執行核心版本、DNS 設定，以及 TUN 或 VPN 狀態。使用同一個網域完成一次連線並保存記錄，之後才能比較差異。
  2. 確認解析入口。檢查系統 DNS 是否受到接管；瀏覽器的安全 DNS、應用程式內的 DoH 可能繞過這個入口。測試時可暫時讓測試應用程式使用系統 DNS，測試結束後再還原設定。
  3. 確認連線是否回到核心。檢查目前的 TUN 或 VPN 路由是否會接收虛擬位址池的流量。若 Android 按應用程式設定代理時排除了測試應用程式，它可能取得虛擬位址，卻無法將連線送回核心。
  4. 確認真實解析的出口。若代理伺服器位址使用網域，必須有可用的初始解析路徑，不能依賴尚未建立的代理連線來完成解析。直連目標也可能仍需要真實 IP。
  5. 一次只調整一項設定。先維持節點與路由預設不變，只調整 FakeDNS 相關設定。不要同時切換核心、協定、DNS 與分流規則，否則難以找出失敗環節。

v2rayN 與 v2rayNG 的介面選項會隨版本變動，應以執行設定與記錄為準，而不是依據舊截圖中的選項位置。如果目前版本沒有提供所需設定，請優先維持已驗證的模式；自訂設定必須同時理解 DNS、入站與路由，不能只新增一個欄位。

驗證與還原：分開確認解析與連線

FakeDNS 測試分為兩步：先查看系統查詢結果，再確認同一網域的實際連線。Windows 可在命令提示字元中執行下方指令。nslookup 驗證的是目前使用的 DNS 查詢路徑，不代表瀏覽器內建的 DNS 也走相同路徑。

ipconfig /flushdns
nslookup example.com

FakeDNS 的對應資訊通常是執行期間的狀態。核心重新啟動、對應項目遭到淘汰或設定變更後，應用程式可能仍快取舊的虛擬位址，但新的核心已無法查出它對應的網域。此時不斷更換節點通常無濟於事，應先清除快取並重新建立連線。Windows 的 ipconfig /flushdns 只會清除系統 DNS 快取，無法取代所有應用程式各自的快取清理。

常見問題：虛擬位址、應用程式衝突與耗電

查到以 198.18 開頭的位址，代表 DNS 設定出錯嗎？

啟用 FakeDNS 且位址池設為 198.18.0.0/15 時，查到這類位址可能是正常結果。先確認查詢的網域是否應交由 FakeDNS 處理，再檢查連線記錄能否還原該網域。單看位址形式無法判斷故障，也不要將它存成網站的固定 IP。

關閉 FakeDNS 後，為什麼部分應用程式仍會逾時？

應用程式可能還快取著舊的虛擬位址。還原原本的 DNS 設定、重新建立用戶端連線，在 Windows 執行 ipconfig /flushdns，接著完全關閉並重新開啟應用程式。Android 則先強制停止受影響的應用程式再測試；一開始不要清除應用程式資料。

只有某款遊戲或辦公應用程式無法開啟，該如何排查？

先為該應用程式所需的網域測試真實解析例外，並維持其他設定不變。有些應用程式會檢查位址類型、固定使用 IP 或自行解析，因此不能只因為「其他網頁正常」就排除相容性問題。若改用真實解析後恢復正常，再檢查該應用程式的 DNS 與路由需求。

v2rayNG 啟用後會更耗電，或一定會變快嗎？

兩者都無法直接保證。FakeDNS 需要維護對應資訊並參與目標還原，實際耗電量也會受網路喚醒、應用程式重試及 VPN 持續執行影響。請在相同網路、節點與應用程式負載下比較；若記錄顯示頻繁重試，應先修復失敗流程，而不是擴大位址池。

啟用 FakeDNS 的標準，應是能驗證網域還原與正確分流。v2rayN、v2rayNG 或 v2flyNG 的設定若已穩定運作，不必只為了增加功能而調整。確實需要導入時，先確認查詢入口、虛擬位址路由、真實解析例外與快取還原機制都清楚可驗證，再擴大到日常使用。

v2rayN 用戶端下載