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 位址的連線,但路由規則仍需要原始網域的情況。
| 比較項目 | 一般 DNS | FakeDNS |
|---|---|---|
| 回傳結果 | 由上游 DNS 解析取得的真實位址 | 從本機位址池分配的虛擬位址 |
| 保留網域資訊的方式 | 依賴代理協定、嗅探或額外記錄 | 依賴網域與虛擬位址對應表 |
| 後續連線 | 可依真實 IP 位址發起連線 | 必須先接管連線並還原目的地 |
| 真實位址的解析時機 | 通常在應用程式連線前 | 依出口方式於後續階段完成 |
| 停用後的快取 | 快取位址通常在有效期限內仍可連線 | 殘留的虛擬位址可能導致連線失敗 |
FakeDNS 也不等於加密 DNS。DoH、DoT 處理的是 DNS 查詢的傳輸方式;FakeDNS 處理的是如何讓網域資訊跟著後續連線走。查詢交給 FakeDNS 後,直連目標仍可能需要真實解析,代理伺服器的網域也必須能正常解析。不能因此認定所有 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。
- 位址池範圍應避開現有 VPN、企業網路及測試網路正在使用的網段。
- 變更位址池後,應一併檢查 TUN 路由或透明轉送規則是否涵蓋新的範圍。
- 對應池容量較大不代表網頁會更快;應先確保查詢與連線能走完同一條鏈路。
啟用前先確認:誰接管 DNS,誰處理連線
v2rayN 是用戶端介面,Xray 則是可能使用的代理核心。介面中的 TUN 功能也可能由獨立元件負責;不能只看節點使用 VLESS 或 VMess,就判定 TUN 的 DNS 一定由 Xray 處理。協定描述的是節點連線方式,並不決定本機 DNS 的接管架構。
系統代理情境
- 接管對象
- 遵循系統代理設定的應用程式
- 網域來源
- 代理請求可能直接帶有網域
- DNS 接管範圍
- 不保證接管系統的所有查詢
- 建議的起始設定
- 先使用一般 DNS 與網域路由
若只透過代理瀏覽網頁,不必一開始就加入虛擬位址池。
TUN 或透明代理情境
- 接管對象
- 進入虛擬網卡或轉送入口的封包
- 網域來源
- FakeDNS 對應資訊或其他嗅探結果
- DNS 接管範圍
- 必須明確設定 DNS 查詢的接管路徑
- 必要條件
- 虛擬位址連線能回到對應的對應表
先確認使用的元件如何實作,再選擇其支援的 FakeDNS 設定格式。
- 在 v2rayN 的「設定」→「參數設定」中確認目前核心的相關設定,並查看啟動記錄中實際啟動的程序。不同版本的分組名稱可能有所調整,請以目前介面和記錄為準。
- 若介面提供「設定」→「DNS 設定」,請先確認它修改的是哪個核心的設定;不要把名稱相同的 DNS 選項當成全域總開關。
- 先記下目前的系統代理狀態、TUN 狀態和 DNS 設定,再一次只修改一項。保留原設定的備份,以便直接還原。
- 若使用 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 查詢的入口設定,卻漏掉接收網頁或應用程式連線的入口。
- 先確保節點伺服器位址能正常解析,避免形成「連上代理前必須先透過代理解析」的循環依賴。
- 不要只讓虛擬位址連線比對網域規則,卻仍以虛擬目的位址直連;連線送出前必須先正確還原目的地。
- 若需要處理 IPv6 查詢,應另外規劃 AAAA 記錄與 IPv6 流量策略;只設定 IPv4 位址池,不能證明 IPv6 也已接管。
如何確認 FakeDNS 生效,而不只是取得虛擬位址
完整驗證必須同時檢查 DNS 回應、連線接管和最後的存取結果。只看到 198.18.x.x,最多只能證明某次查詢取得了虛擬位址,無法證明瀏覽器連線成功,也無法證明網域分流採用了預期規則。
- 清除舊狀態。關閉測試用瀏覽器,套用設定並重新啟動相關核心。在 Windows 終端機執行下方指令,即可清除系統 DNS 快取;應用程式本身的快取可能仍需另外清除。
- 查詢測試網域。執行
nslookup example.com,記錄回傳的位址和顯示的 DNS 伺服器。若使用 IPv4 FakeDNS,請確認 A 記錄位於所設定的位址池範圍內。 - 確認應用程式連線路徑。重新開啟瀏覽器並造訪同一網域。瀏覽器的安全 DNS 可能會繞過系統查詢路徑,可先暫時停用此功能進行比對;不要假設命令列的結果適用於所有應用程式。
- 檢查路由結果。在核心存取記錄中確認目標網域和出口標記。記錄格式會因版本而異,請確認是否還原為預期網域,而不只看見「連線成功」字樣。
- 確認直連與代理路由。各選一個已有規則涵蓋的目標進行測試,確認網域比對成功後會進入對應出口。不要根據虛擬 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 才是合適的工具。它不是訂閱節點附帶的功能,也不要求伺服器端節點採用特定協定;主要設定在本機的接管與路由階段。
- 適用:在 TUN 情境中需要依網域分流,卻無法只靠應用程式代理請求保留網域;或透明代理已有明確的 DNS 接管與目的地還原流程。
- 優先維持一般解析:只使用瀏覽器系統代理、依賴區域網路名稱探索、需要診斷真實位址,或 DNS 已由企業網路政策管理。
- 應先測試相容性:遊戲、即時通訊、虛擬機器及多層 VPN 疊加環境。除了檢查虛擬網段衝突,也要確認 UDP 和 IPv6 是否遵循相同的接管策略。
需要還原時,先復原原本的 DNS 設定與接管規則,確保新的查詢能取得正常結果;接著退出相關 TUN 或透明代理鏈路,並清除系統及應用程式快取。最後分別驗證網域解析與一般連線。不要只刪除位址池設定,卻繼續向應用程式回傳舊的虛擬回應;也不要只關閉代理程序,卻留下虛擬網段路由。