2026-07-30 · 進階設定 · 約 10 分鐘

FakeDNS 是什麼？虛擬 IP 對應原理、適用情境與 v2rayN 設定時機

了解 FakeDNS 如何透過保留網段的虛擬 IP 保留網域資訊，以及它在 TUN 模式與網域分流中的用途，並評估應用程式不相容時的取捨。

本文重點

設定判斷：FakeDNS 主要用來解決透明代理接管流量後「只有目標 IP、沒有原始網域」的問題，適合已使用 TUN 且需要依網域分流的使用者。本文從對應機制、核心限制、啟用檢查到故障回復逐步說明，協助辨別正常的虛擬 IP、DNS 接管遺漏與應用程式相容性問題。

FakeDNS 原理：保留網域資訊，再決定連線出口

虛擬 IP 對應：一般 DNS 會為網域回傳可連線的實際 IP；FakeDNS 則從指定的位址池分配一個 IP，並在本機記錄「網域與虛擬 IP」的對應關係。這個 IP 不是目標網站的公開入口，而是供後續連線辨識網域的索引。應用程式收到結果後仍會照常連線，代理處理流程再透過對應紀錄找回原始網域。

查詢網域 分配虛擬 IP 接管連線 還原原始網域 依規則選擇出口

連線流程：DNS 查詢與後續連線必須經過彼此配套的處理流程，虛擬 IP 才有作用。如果 DNS 已回傳虛擬 IP，但 TUN 沒有接管該位址池，應用程式可能會透過一般網路連線，最後逾時。反過來說，若應用程式透過獨立的加密 DNS 取得實際 IP，FakeDNS 也不會自動產生這次查詢的網域對應紀錄。

出口解析：還原網域不代表整個連線都不需要實際 DNS。後續是否解析、在哪裡解析，取決於出口類型、網域處理策略與伺服器行為。直連通常仍須取得可連線的 IP；支援傳遞網域的代理出口則可將網域交由遠端處理。FakeDNS 解決的是本機辨識與分流問題，並非取代整個網際網路的名稱解析。

位址池與連接埠：看到虛擬 IP 不代表 DNS 出錯

數值辨識：Xray 的 FakeDNS 常見設定會使用 198.18.0.0/15 位址池；這個範圍原本保留作網路基準測試用途，不是一般公開網站的 IP。以下列出的是位址與協定相關資訊，不是速度測試結果，也不代表所有環境都應照此設定。

/15
範例位址池的前綴長度
131072
此 IPv4 位址區塊的總位址數
53
傳統 DNS 使用的服務連接埠

位址範圍：198.18.0.0/15 涵蓋 198.18.0.0 至 198.19.255.255。位址區塊的總數不代表核心一定會儲存相同數量的對應紀錄，實際容量仍受位址池設定與實作限制影響。如果企業測試網路已使用這個範圍，必須先處理路由衝突；「保留位址」不代表「本機一定沒有使用」。

判斷重點：檢查完整連線流程，不要只看虛擬 IP 判定故障

驗證順序：先確認網域查詢有進入預期的 DNS 處理流程，再確認虛擬 IP 連線進入 TUN，最後核對網域還原結果與出口。查詢結果有變化，並不能證明分流已生效。

v2rayN 設定時機：先分清系統代理與 TUN

系統代理情境：遵循系統代理設定的應用程式，通常會將目標網域交給本機 HTTP 或 SOCKS 代理；不過是否由本機解析，仍取決於應用程式與協定的使用方式。如果記錄已顯示網域，路由也符合預期，通常就不必啟用 FakeDNS。FakeDNS 不是 VMess、VLESS 節點連線的必要條件，也無法修復訂閱失效或 TLS 參數錯誤。

系統代理檢查重點

流量入口
應用程式遵循本機代理設定
網域來源
代理請求或應用程式的解析行為
啟用條件
先確認確實存在網域辨識缺口
驗證位置
連線記錄與路由規則命中結果

選擇建議：已有網域資訊且分流正常時，維持目前的 DNS 流程較容易管理。

TUN 檢查重點

流量入口
虛擬網卡接收 IP 封包
網域來源
DNS 對應或協定嗅探
啟用條件
DNS 與虛擬 IP 連線都已接管
驗證位置
DNS、入站與出站記錄

選擇建議：需要保留網域規則，但入口只有 IP 時，再評估虛擬 IP 方案。

核心限制：v2rayN 是桌面用戶端，介面中選取的節點核心與 TUN 實際使用的處理元件不一定相同。不能因為節點使用 Xray 連線，就把 Xray 的 FakeDNS 欄位直接貼到所有 TUN 設定中。請先檢視目前設定與啟動記錄，確認 DNS、TUN 與路由分別由哪個元件處理，再使用該核心支援的設定。

Android 限制：v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；兩者的介面選項、設定產生方式與欄位支援情況，不能根據桌面版截圖推測。即使名稱相似，也應分別檢查目前版本提供的 DNS 與流量接管選項。跨平台移轉時，請保留分流目標，不要直接複製未經確認的底層設定。

設定順序：位址池、DNS 回應與網域還原缺一不可

最小設定片段：以下僅展示 Xray 頂層的 fakedns 位址池設定，方便理解欄位，並非可獨立執行的完整設定。poolSize 的 65535 是此範例採用的對應容量，不代表位址區塊的總數，也不是所有電腦都適用的建議值。v2rayN 自動產生的檔案可能在重新啟動後被改寫，修改前請先確認自訂設定的入口與儲存方式。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}
  1. 記錄基準：先儲存目前的 DNS、路由與 TUN 設定，並選定一個常用網站和一項區域網路服務，作為調整前後的比較對象。
  2. 確認 DNS 入口：檢查系統與應用程式的查詢是否進入預期的處理流程。只在設定中定義位址池，不會自動讓所有系統查詢使用 FakeDNS。
  3. 啟用 FakeDNS 回應：在適用的 Xray 設定中，還需要讓相應的 DNS 查詢使用內建的 fakedns 服務；查詢規則應配合直連或代理需求設定。
  4. 確認網域還原：使用相應的 Xray 入站時，請檢查嗅探設定中的 enabled 與 destOverride；其中的 fakedns 項目可從對應紀錄還原網域。其他流量接管元件則應使用各自相應的機制。
  5. 逐項驗證：檢查一般瀏覽、區域網路存取與目標應用程式。先確認還原後的網域與出口，再決定是否擴大到日常使用。

IPv6 配套：只有 IPv4 位址池，不代表 IPv6 也受到相同處理。應用程式可能優先查詢 AAAA 記錄，再透過 IPv6 連線；若這條路徑沒有相應的路由與 DNS 策略，不同應用程式的表現就可能不一致。請分別驗證 A、AAAA 查詢及其連線路徑，不要只憑一次 IPv4 連線成功就認定全部正常。

適用情境與相容性取捨：優先使用網域規則，另行處理實際 IP 需求

規則優勢：TUN 接收的通常是目標 IP，單靠 IP 很難穩定判斷網站所屬服務。一個網域可能對應多個 IP，一個 IP 也可能承載多個網域。FakeDNS 會保留查詢時的網域名稱，讓網域規則更容易取得比對依據；但涵蓋範圍受實際 DNS 查詢路徑限制，無法還原所有連線的網域。

使用情境主要影響處理建議
在 TUN 模式下依網域分流對應紀錄可為連線保留原始網域確認 DNS 與連線都已接管後再啟用
依實際目標 IP 比對虛擬 IP 本身無法代表目標網路的歸屬核對網域還原後的解析方式與規則順序
區域網路名稱與裝置探索可能仰賴本機 DNS、群播或專用探索協定保留相應的本機解析與直連路徑
應用程式驗證解析結果可能拒絕保留位址，或因結果快取而異常使用核心支援的排除機制，必要時恢復原設定
應用程式直接連線至固定 IP沒有先前的網域查詢可供建立對應檢查 IP 規則，不要期待 FakeDNS 自動補出網域

相容性原因：部分應用程式會檢查解析出的 IP 是否屬於預期網段，或將 DNS 結果交給其他程序或裝置使用。虛擬 IP 離開原本的對應環境後，通常就沒有實際用途。因此，不應將 FakeDNS 回應提供給沒有相應接管能力的其他裝置，也不要把回傳的 IP 當成伺服器實際 IP 寫入長期設定。

設定取捨：局部不相容時，先縮小影響範圍

操作建議：若只有單一應用程式或本機服務異常，優先檢查該應用程式的 DNS、路由與 IP 驗證需求；只有在目前核心支援排除設定時，才進行局部調整。若無法建立可靠的例外規則，恢復使用實際 DNS 流程會比疊加多組不明規則更容易驗證。

故障排除與回復：依查詢、對應、連線的順序檢查

排查起點：啟用後出現「網頁能開，某個應用程式不能用」時，先保留問題發生時的本機記錄，確認異常應用程式是否使用獨立 DNS、固定 IP 或不同的網路路徑。不要同時更換節點、路由規則與 DNS，否則即使恢復正常，也很難判斷是哪項調整奏效。

  1. 查不到虛擬 IP：確認測試網域確實符合 FakeDNS 查詢規則；回傳實際 IP 可能是排除策略的預期結果，也可能是應用程式使用內建 DNS 或舊快取造成。
  2. 取得虛擬 IP 卻連線逾時：檢查 TUN 是否正在運作、位址池路由是否進入正確介面，以及是否與其他虛擬網卡或企業路由衝突。
  3. 記錄只顯示虛擬 IP：檢查相應入站的網域還原設定，並確認是否因重新啟動而遺失對應紀錄，但應用程式仍保留舊的 DNS 快取。
  4. 網域正確但出口錯誤：檢查規則由前至後的比對順序，以及程序、連接埠或 IP 規則是否先行命中；此時問題已不只是 DNS。
  5. 瀏覽器與應用程式表現不同：分別檢查加密 DNS、應用程式代理設定與快取，不要因瀏覽器成功一次，就認定其他程序也正常。

Windows 快取：恢復實際 DNS 前，先還原 DNS 回應與流量接管設定，再清除系統快取並重新啟動目標應用程式。以下指令只會清除 Windows DNS 用戶端快取，不會清除瀏覽器內建快取，也不會修改節點。長時間執行的應用程式可能保留自己的連線池，請完全結束後再重新開啟。

ipconfig /flushdns

回復驗證：確認新查詢不再回傳原本的虛擬 IP、區域網路服務可以存取，且系統代理或 TUN 已恢復預定狀態。若關閉接管後仍有應用程式嘗試連線至舊虛擬 IP，應繼續清除應用程式快取，而不是將該 IP 加入直連規則；直連無法把虛擬索引變成實際伺服器。

常見問題：FakeDNS、嗅探與隱私的適用範圍

FakeDNS 和協定嗅探有什麼不同？
資訊來源：FakeDNS 會根據先前的 DNS 查詢維護對應紀錄；協定嗅探則會嘗試從連線資料中擷取可辨識的名稱，例如部分 HTTP 或 TLS 交握資訊。嗅探能力受協定與加密方式限制，對應紀錄則受 DNS 是否經過本機處理流程限制。兩者可以搭配使用，但都無法保證涵蓋所有流量。
啟用 FakeDNS 一定會更快嗎？
效能限制：本機分配虛擬 IP，或可省去等待實際解析完成後才進行本機分流的步驟；但最終連線仍受出口解析、網路線路、伺服器與應用程式行為影響。較合理的評估方式是確認規則是否正確、應用程式是否穩定，而不是先假設延遲一定會降低。
FakeDNS 能確保 DNS 查詢不外洩嗎？
隱私限制：不能只憑這項功能作出保證。應用程式可能繞過系統 DNS，代理伺服器的 IP 也可能需要預先解析，直連流量仍可能呼叫其他解析器。應分別檢查系統 DNS、應用程式 DNS、出口解析與路由，而非只看單次查詢是否回傳虛擬 IP。
重新啟動核心後，為什麼部分連線突然失敗？
快取一致性：不要假設重新啟動後對應紀錄仍會保留。如果應用程式儲存了舊虛擬 IP，而新啟動的核心沒有相應紀錄，連線就可能失敗。重新查詢網域、清除相關快取並重新啟動應用程式，通常比反覆更換節點更能對症處理。

最後判斷：若系統代理下的網域分流已正常，FakeDNS 不必列為例行設定；若在 TUN 模式下確實缺少網域資訊，而且能同時控制 DNS 與連線路徑，再考慮啟用。設定完成後，應一併確認網域還原、路由命中與應用程式相容性。

用戶端安裝檔