2026-09-28 · 進階設定 · 約 10 分鐘

FakeDNS 原理與適用情境：何時該在 v2rayNG 啟用

FakeDNS 會先以保留位址回覆網域查詢，再於流量送出時還原原始網域。本文說明它如何降低 DNS 洩漏與解析延遲，以及搭配 TUN、分流規則時的注意事項。

本文重點

FakeDNS 適合連線正常，但需要改善網域辨識與 DNS 路徑的 v2rayNG 使用者。先了解虛擬位址如何還原，再檢查 Android VPN 接管、網域路由與應用程式內建 DNS；最後逐項變更並驗證。它無法修復失效節點，也不保證所有應用程式的 DNS 查詢都會經過代理。

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

一般 DNS 查詢會將網域轉換成伺服器的真實 IP，接著由應用程式連線至該 IP。流量進入透明代理接管路徑後，代理核心有時只能看到目標 IP，不再知道應用程式最初查詢的網域。依賴網域的路由規則便可能無法匹配，只能再嘗試嗅探、匹配 IP，或交由預設出站處理。

FakeDNS 會維護一份「網域與虛擬 IP」對照表。應用程式查詢網域時，FakeDNS 先從位址池分配一個位址；應用程式連線至該位址時，核心再查回網域，並依路由選擇直連或代理。這個位址不是網站伺服器，也不應直接送往公網。

網域查詢 分配虛擬位址 應用程式建立連線 還原目標網域 匹配出站規則

Xray 的 FakeDNS 常用 IPv4 位址池為 198.18.0.0/15，範圍從 198.18.0.0 到 198.19.255.255。這個網段原本保留作為網路設備基準測試用途，不是可連線網站的公網位址，也不是一般所說的家庭區域網路私有網段。DNS 回覆出現這個範圍，本身不代表解析遭到污染。

DNS 洩漏與解析延遲：能改善什麼、無法保證什麼

對於已接管的查詢，FakeDNS 可在本機產生回覆，不必在這個階段向外部 DNS 查詢真實 IP。這能減少本地 DNS 直接得知目標網域的機會，也省下應用程式等待外部查詢的時間。不過，網站連線最後仍須找到真實伺服器；解析可能在代理伺服器端進行，也可能在直連出站時才進行。

流量路徑FakeDNS 的作用仍須檢查
進入核心的一般 DNS 查詢在本機回覆虛擬位址，保留網域對照UDP/TCP 53 查詢是否確實進入處理流程
以網域名稱送往代理出站可將還原後的網域交給後續連線流程伺服器端的解析策略與 DNS 出口
依規則選擇直連先還原網域，方便匹配規則直連端如何解析真實位址
應用程式內建的加密 DNS不一定能處理其中的網域查詢應用程式內的 DoH 與安全 DNS 設定
應用程式直接連線至固定 IP沒有對應的查詢，就無法憑空還原網域IP 規則與預設出站

判斷「DNS 洩漏」時，須一併考量預期路由：若規則原本就允許部分網域直連，這些網域在直連端解析，不一定代表設定故障。真正要確認的是，原本預期經代理處理的網域，是否仍被送往本地網路的解析器。只看檢測網頁顯示哪家 DNS 服務，無法證明整台裝置上的所有應用程式都走相同路徑。

結論：先確認 DNS 路徑，再比較開啟速度

維持相同節點與路由規則，分別測試功能開啟前後的目標應用程式。只有查詢進入 FakeDNS、後續連線也能正確還原，才值得比較首次連線的等待時間；取得虛擬位址較快，不代表網站整體載入也更快。

在 v2rayNG 啟用前：檢查 VPN、DNS 與網域還原

v2rayNG 在 Android 上通常透過系統 VPN 服務取得虛擬網路介面，再將流量交由核心處理。這與桌面環境常說的 TUN 接管概念相近，但介面上不一定有獨立名為「TUN 模式」的開關。請先確認 VPN 已啟動、目標應用程式未設為排除，再調整 FakeDNS；不要直接套用 v2rayN 的桌面選單設定。

檢查用戶端入口

功能入口
側邊欄「設定」→「啟用 FakeDNS」
相關選項
「啟用本機 DNS」與 DNS 設定項目
接管範圍
檢查「應用程式分流」中的選取項目
套用方式
停止連線後重新啟動 VPN

不同版本的選項名稱與分類可能有所調整，請以已安裝的版本為準；名稱相近的開關不一定是同一項功能。

檢查核心處理流程

DNS 回覆
查詢已送交 FakeDNS 處理
位址池
常見 IPv4 範圍為 198.18.0.0/15
網域還原
檢查對應 fakedns 的嗅探設定
路由依據
還原網域後匹配網域規則

自動產生的設定通常由用戶端搭配處理；自訂設定不能只加入一個位址池就算完成。

先記下「設定」中的 DNS、流量嗅探與路由選項，再啟用「啟用 FakeDNS」。若目前版本提示需要相關相依設定，請依提示一併設定；不要為了以防萬一而同時啟用所有 DNS 選項。自訂設定可能不會採用介面自動產生的欄位，務必確認實際執行的設定，而不只是查看介面開關。

網域分流與 IP 分流：須一併檢查規則順序

FakeDNS 的一項直接效益，是還原網域，讓網域規則有可供匹配的對象。例如，核心還原目標網域後，可先嘗試匹配指定的網域規則，再處理其他規則。不過，它不會替使用者決定哪些網站應直連，也不會自動補齊缺少的規則資源。

路由通常依照設定順序匹配。如果自訂規則先將整個虛擬位址池判定為直連，而且此時目標尚未正確還原，流量可能會被送往無法連線的位址。另一個常見誤解，是把「IP 位於哪個地區」當成「網域屬於哪個類別」：虛擬 IP 只是本機對照標記，不能用來判斷真實伺服器的地理位置。

  1. 先確認網域已還原。透過可用的記錄或執行設定，檢查入站是否能還原 FakeDNS 位址；不要先為 198.18.0.0/15 新增直連規則。
  2. 再檢查網域規則。確認指定網域、網域集合與預設出站的順序符合預期，尤其留意過早匹配的寬泛規則。
  3. 最後檢查 IP 判斷。若啟用 IPIfNonMatch 或 IPOnDemand 等網域解析策略，路由階段仍可能觸發真實解析；這不代表 FakeDNS 自動失效。
  4. 單獨測試區域網路。印表機、路由器管理頁面與內部網域可能依賴本地 DNS。請保留明確的區域網路存取規則，並檢查 VPN 路由是否涵蓋相關位址。

啟用與還原：使用同一個應用程式逐項驗證

適合嘗試 FakeDNS 的情況，是節點連線正常，但透明接管後網域規則經常無法匹配，或已接管的一般 DNS 查詢等待時間明顯。若目前的解析與分流都很穩定，啟用後不一定看得出差異。遇到伺服器拒絕連線、TLS 交握失敗或訂閱更新失敗時，應先處理對應問題；FakeDNS 並非這些故障的通用修復方式。

  1. 建立基準。關閉 FakeDNS，維持節點、路由與網路不變，確認瀏覽器、目標應用程式與一項區域網路服務的狀況。記錄能否開啟、流量是否走預期的出站，而不是只記「快」或「慢」。
  2. 只調整 FakeDNS 相關設定。在「設定」中啟用功能及用戶端提示的必要相依項目，停止後重新啟動 VPN。此時不要同時更換節點、DNS 服務或路由模式。
  3. 排除舊連線的影響。完全退出測試應用程式後重新開啟。若應用程式沿用 DNS 快取，可先強制停止再測試；瀏覽器也要檢查本身的「安全 DNS」設定。
  4. 檢查查詢與連線結果。一般 DNS 測試可能會看到位址池中的位址，之後實際連線仍必須成功。若只有前者成功、連線卻失敗，請優先檢查對照還原、VPN 接管與舊快取。
  5. 發生異常時完整還原。恢復原本的開關設定，重新啟動 VPN，再重新開啟應用程式。若仍留有舊虛擬位址，請等待應用程式快取失效或重新啟動裝置，不要用長期固定虛擬 IP 的方式迴避問題。

結論：能還原、能分流、能回復，才值得保持啟用

若啟用後只有部分應用程式失效，先找出該應用程式的加密 DNS、應用程式分流與快取問題，不要繼續疊加全域規則。若無法確認實際設定流程，恢復原設定會比同時修改多項 DNS 與嗅探選項更容易排查。

FakeDNS 常見問題：位址異常、應用程式失效與網路切換

解析結果以 198.18 開頭，代表節點有問題嗎？

先查看「設定」→「啟用 FakeDNS」是否已開啟。若位址落在設定的位址池範圍內，這是預期的虛擬回覆；接著實際開啟目標網站。只有連線無法還原時，才進一步檢查 VPN 接管、嗅探設定與應用程式舊快取；不要只憑位址外觀判定節點失效。

瀏覽器正常，另一個應用程式卻一直轉圈，該怎麼辦？

前往「應用程式分流」確認該應用程式是否由 VPN 接管，再檢查應用程式內是否設有獨立的安全 DNS。維持節點不變，關閉 FakeDNS、重新啟動 VPN，並強制停止該應用程式後再試。若只有啟用 FakeDNS 時失敗，請優先檢查該應用程式是否繞過虛擬位址的回程路徑。

啟用後 DNS 檢測仍顯示本地解析服務，算是洩漏嗎？

先確認受測網域的出站方式：它可能依規則直連，也可能由應用程式自己的加密 DNS 解析。請改用預期會走代理的網域重新測試，並檢查瀏覽器的「安全 DNS」與系統的「私人 DNS」。判讀檢測結果時應一併考量路由目標，不能只憑解析服務名稱下結論。

從 Wi-Fi 切換到行動網路後無法開啟網站，需要重新匯入訂閱嗎？

先停止並重新啟動 VPN，再關閉並重新開啟應用程式，以排除舊連線與對照快取不一致的問題。訂閱提供節點參數，不會清除應用程式的 DNS 快取；只有節點本身也無法連線時，才進一步檢查網路連通性與節點參數。

v2flyNG 可以直接照搬 v2rayNG 的設定嗎？

不能只因功能名稱相同就直接照搬。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；即使兩者都提供相關功能，支援欄位、預設值與介面產生設定的方式仍可能不同。請以目前用戶端與核心支援的功能為準，遷移時分別核對 DNS、入站與路由設定。

下載用戶端