V2Ray FakeDNS 是什麼?原理、設定方式與適用情境

了解 FakeDNS 如何透過虛擬 IP 位址池保留網域資訊,並比較一般 DNS。掌握它在 TUN 模式與透明代理中的用途、限制及設定方式。

本文重點

FakeDNS 會保存網域與虛擬 IP 位址的對應關係,讓只能看到目的 IP 的透明代理重新取得網域資訊。它適用於 DNS 查詢與後續連線都由同一代理鏈路處理的情境,並非換個 DNS 位址就能加速。下文將說明資料流、Xray 設定範例、v2rayN 檢查方式,以及斷線後的復原步驟。

FakeDNS 是什麼:先回傳虛擬 IP,再還原網域

一般 DNS 查詢會回答「這個網域對應哪些真實 IP 位址」。FakeDNS 則會回答「用這個虛擬 IP 位址代表剛才查詢的網域」。例如,應用程式查詢 example.com 時,FakeDNS 會從自己的位址池分配一個位址,並記錄兩者的對應關係。應用程式接著連線至該位址,代理入口再查回網域,依網域規則選擇直連或代理出口。

應用程式查詢網域 分配虛擬位址 連線進入代理 依對應關係還原網域 依規則選擇出口

關鍵不在「虛擬」兩字,而在整個流程能否串接:負責回覆 DNS 的對應表,必須能讓處理後續連線的元件存取。如果 DNS 查詢交給一個程序處理,連線卻交給另一個無法共用對應表的程序,後者只會看到無法用於公網連線的目的位址。即使兩個程式都叫代理,也不能假設它們會自動共用對應資料。

一般 DNS 與 FakeDNS 的差異

一般 DNS 也能搭配網域分流。應用程式使用 HTTP 代理,或將網域交給 SOCKS 代理時,代理本來就可能知道網域;此時加入 FakeDNS 未必有幫助。FakeDNS 更適合 TUN 或透明代理攔截到目的地為 IP 位址的連線,但路由規則仍需要原始網域的情況。

比較項目一般 DNSFakeDNS
回傳結果由上游 DNS 解析取得的真實位址從本機位址池分配的虛擬位址
保留網域資訊的方式依賴代理協定、嗅探或額外記錄依賴網域與虛擬位址對應表
後續連線可依真實 IP 位址發起連線必須先接管連線並還原目的地
真實位址的解析時機通常在應用程式連線前依出口方式於後續階段完成
停用後的快取快取位址通常在有效期限內仍可連線殘留的虛擬位址可能導致連線失敗

FakeDNS 也不等於加密 DNS。DoH、DoT 處理的是 DNS 查詢的傳輸方式;FakeDNS 處理的是如何讓網域資訊跟著後續連線走。查詢交給 FakeDNS 後,直連目標仍可能需要真實解析,代理伺服器的網域也必須能正常解析。不能因此認定所有 DNS 查詢都不再發生,或所有流量都會經過代理。

位址池與連接埠:三個容易混淆的數字

131072
/15 網段包含的 IPv4 位址數量
65535
本文範例的 poolSize 設定值
53
一般 DNS 服務使用的連接埠號碼

198.18.0.0/15涵蓋 198.18.0.0 至 198.19.255.255,共包含 131072 個位址;這不代表對應表一定會同時保存這麼多筆記錄。範例中的 poolSize 是對應池容量設定,不能把位址範圍、對應容量和 DNS 快取有效期限視為同一件事。

連接埠也要分清楚。系統向 DNS 服務發出查詢時,常見的目標是 UDP 或 TCP 的 53 連接埠;代理軟體內部的 DNS 接收連接埠則可另外設定。HTTP、SOCKS 的本機監聽連接埠不是 DNS 連接埠;將系統 DNS 指向 HTTP 代理的監聽位址,不會自動啟用 FakeDNS。

啟用前先確認:誰接管 DNS,誰處理連線

v2rayN 是用戶端介面,Xray 則是可能使用的代理核心。介面中的 TUN 功能也可能由獨立元件負責;不能只看節點使用 VLESS 或 VMess,就判定 TUN 的 DNS 一定由 Xray 處理。協定描述的是節點連線方式,並不決定本機 DNS 的接管架構。

系統代理情境

接管對象
遵循系統代理設定的應用程式
網域來源
代理請求可能直接帶有網域
DNS 接管範圍
不保證接管系統的所有查詢
建議的起始設定
先使用一般 DNS 與網域路由

若只透過代理瀏覽網頁,不必一開始就加入虛擬位址池。

TUN 或透明代理情境

接管對象
進入虛擬網卡或轉送入口的封包
網域來源
FakeDNS 對應資訊或其他嗅探結果
DNS 接管範圍
必須明確設定 DNS 查詢的接管路徑
必要條件
虛擬位址連線能回到對應的對應表

先確認使用的元件如何實作,再選擇其支援的 FakeDNS 設定格式。

  1. 在 v2rayN 的「設定」→「參數設定」中確認目前核心的相關設定,並查看啟動記錄中實際啟動的程序。不同版本的分組名稱可能有所調整,請以目前介面和記錄為準。
  2. 若介面提供「設定」→「DNS 設定」,請先確認它修改的是哪個核心的設定;不要把名稱相同的 DNS 選項當成全域總開關。
  3. 先記下目前的系統代理狀態、TUN 狀態和 DNS 設定,再一次只修改一項。保留原設定的備份,以便直接還原。
  4. 若使用 v2rayNG 或 v2flyNG,也應先確認實際使用的核心及設定支援情況;不要直接照搬桌面用戶端的選單路徑到 Android 版。

Xray 設定範例:建立對應與還原目的地,缺一不可

以下是適用於支援這些欄位的 Xray 核心之設定片段,不是可獨立執行的完整節點設定。使用前請確認本機核心版本的設定說明。用戶端自動產生的檔案可能在儲存設定或切換節點時遭到覆寫,因此應透過用戶端支援的自訂設定入口修改,不要反覆編輯暫存檔。

第一部分:設定位址池並選用 FakeDNS

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

頂層的 fakedns 用來定義對應池,dns.servers 中的 "fakedns" 則用來選擇內建的 FakeDNS 服務。這個最精簡的片段只說明欄位之間的關係,沒有提供節點伺服器網域、區域網路網域及直連目標所需的真實解析方式。正式環境的設定應依用途安排一般解析器,避免將所有解析需求都交給虛擬位址池。

第二部分:讓接收連線的入口還原網域

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

第二段應合併至實際接收目標連線的 inbound 物件中,而非新增為頂層欄位。destOverride 中的 "fakedns" 用於從 FakeDNS 對應資料還原目標網域。不要只在接收 DNS 查詢的入口設定,卻漏掉接收網頁或應用程式連線的入口。

如何確認 FakeDNS 生效,而不只是取得虛擬位址

完整驗證必須同時檢查 DNS 回應、連線接管和最後的存取結果。只看到 198.18.x.x,最多只能證明某次查詢取得了虛擬位址,無法證明瀏覽器連線成功,也無法證明網域分流採用了預期規則。

  1. 清除舊狀態。關閉測試用瀏覽器,套用設定並重新啟動相關核心。在 Windows 終端機執行下方指令,即可清除系統 DNS 快取;應用程式本身的快取可能仍需另外清除。
  2. 查詢測試網域。執行 nslookup example.com,記錄回傳的位址和顯示的 DNS 伺服器。若使用 IPv4 FakeDNS,請確認 A 記錄位於所設定的位址池範圍內。
  3. 確認應用程式連線路徑。重新開啟瀏覽器並造訪同一網域。瀏覽器的安全 DNS 可能會繞過系統查詢路徑,可先暫時停用此功能進行比對;不要假設命令列的結果適用於所有應用程式。
  4. 檢查路由結果。在核心存取記錄中確認目標網域和出口標記。記錄格式會因版本而異,請確認是否還原為預期網域,而不只看見「連線成功」字樣。
  5. 確認直連與代理路由。各選一個已有規則涵蓋的目標進行測試,確認網域比對成功後會進入對應出口。不要根據虛擬 IP 的地理位置判斷目標應直連或使用代理。
ipconfig /flushdns
nslookup example.com

如果 nslookup 回傳真實 IP,可能是查詢沒有進入 FakeDNS,也可能是該網域依設計使用一般解析器。若回傳虛擬 IP 但網頁無法開啟,應優先檢查虛擬網段路由和對應還原,不要先更換訂閱或大量修改節點參數。

常見問題:虛擬位址、瀏覽器繞過與停用後斷線

查到以 198.18 開頭的位址,為什麼還是無法連線?

先確認該位址屬於目前設定的位址池,再檢查 TUN 路由是否有接管該位址。接著確認接收連線的入口能否讀取同一份對應資料。DNS 回應已生效,但連線繞過代理,是最常見的設定不完整狀況。

命令列查詢正常,為什麼瀏覽器還是走另一條路?

檢查瀏覽器設定中的「安全 DNS」或「使用安全 DNS」選項,暫時關閉後重新啟動瀏覽器進行比對。瀏覽器可能自行發出加密查詢,也可能沿用舊連線;清除系統快取不代表瀏覽器內部狀態也已清除。

關閉 TUN 後,為什麼有些網站突然無法開啟?

應用程式可能仍快取著虛擬 IP,但負責還原位址的鏈路已停止。還原原本的系統 DNS 與路由,執行 ipconfig /flushdns,再重新啟動受影響的應用程式。若仍未恢復,請檢查虛擬網卡路由是否殘留。

啟用 FakeDNS 能降低遊戲延遲嗎?

FakeDNS 主要改變網域與連線的關聯方式,不會改變節點距離或網路壅塞情況。需要探測真實 IP、使用內建網路診斷,或自行驗證位址的應用程式,反而可能無法相容虛擬回應。建議先使用一般 DNS 測試,再針對個別應用程式決定是否排除。

重新啟動核心後,為什麼先前開啟的網站會暫時無法使用?

不要假設對應表會在重新啟動後保留。應用程式快取的虛擬位址可能已找不到相應網域,也可能與新的對應資料不一致。關閉舊連線、清除 DNS 快取並重新查詢,比不斷切換節點更能對症處理。

適用情境與還原順序

只有在透明代理需要穩定取得網域、DNS 與連線由可互相配合的元件處理,且願意維護例外規則時,FakeDNS 才是合適的工具。它不是訂閱節點附帶的功能,也不要求伺服器端節點採用特定協定;主要設定在本機的接管與路由階段。

需要還原時,先復原原本的 DNS 設定與接管規則,確保新的查詢能取得正常結果;接著退出相關 TUN 或透明代理鏈路,並清除系統及應用程式快取。最後分別驗證網域解析與一般連線。不要只刪除位址池設定,卻繼續向應用程式回傳舊的虛擬回應;也不要只關閉代理程序,卻留下虛擬網段路由。

下載v2rayN依平台選擇安裝檔