V2Ray FakeDNS 原理與虛擬 IP 對應機制解析｜適用情境

FakeDNS 與一般 DNS 解析的差異

一般 DNS 的 A、AAAA 查詢分別用來取得 IPv4、IPv6 位址。應用程式取得結果後，通常會直接連線至該位址。進入透明代理時，原始連線可能只剩下「目標 IP＋連接埠」，但網域規則需要的是應用程式最初查詢的名稱。FakeDNS 改變了流程前半段：它不會立即回傳伺服器的真實位址，而是分配一個只在受控連線路徑中有意義的虛擬 IP。

例如，應用程式查詢 www.example.com，FakeDNS 分配 198.18.0.2 並記錄兩者的對應關係。接著應用程式連線至 198.18.0.2:443，接管連線的核心查到對應資料後，就能將目標還原為 www.example.com:443。這裡的位址僅供說明機制，並非可直接連線的測試節點，也不是任何用戶端固定分配的第一個位址。

虛擬 IP 對應的完整流程

這條流程的關鍵不在於「DNS 回傳了什麼」，而在於回傳結果能否與後續連線重新連結。負責回應 DNS 的對應表，必須與處理目標連線的核心共用對應狀態，或透過支援此機制的整合元件銜接。若某個執行個體產生虛擬位址，卻把連線交給另一個沒有對應資料的執行個體，後者看到的只會是無法直接連線的特殊用途位址。

1. 查詢進入受控 DNS：應用程式的 A 或 AAAA 請求必須進入已設定的解析路徑。只接管傳統 DNS 的 UDP 53 連接埠，不代表也涵蓋應用程式內建的加密 DNS。
2. 寫入對應表：FakeDNS 為網域分配虛擬位址。位址池容量有限，部分實作可能在容量吃緊時回收舊的對應資料；位址分配順序不應視為固定介面。
3. 接管虛擬位址連線：TUN 或透明代理規則會將連線送至支援還原的入口。FakeDNS 本身不會建立 TUN 網卡，也不會自動設定完整的系統路由。
4. 查表並還原目標：核心透過虛擬 IP 找回網域，供網域規則及後續出站使用。是否會改寫連線目標，也會受入口的嗅探等設定影響。
5. 完成實際連線：選擇代理出站時，支援網域目標的協定可以將網域交由遠端處理；選擇直連時，通常仍須透過真實 DNS 取得可連線的位址。

因此，FakeDNS 並非「不再需要 DNS」，而是延後真實解析並保留網域關聯。它也不能取代 VMess、VLESS 等代理協定，不會修改節點驗證資料，更無法修復伺服器無法連線、傳輸路徑錯誤或 TLS 設定不符等問題。

設定欄位：位址池、DNS 與入口還原

「V2Ray FakeDNS」常被用來泛指這類機制，但 V2Ray 與 Xray 的設定功能、欄位及用戶端整合方式各有不同，請分別確認。以下以支援這些欄位的 Xray-core JSON 設定為例，展示明確填入的範例值，不表示這些是所有版本的預設值。v2rayN、v2rayNG 與 v2flyNG 的介面和產生設定檔的方式不同，不可跨核心直接套用。

以下是根物件中的 DNS 與位址池片段，並非可獨立執行的完整設定。內容未定義監聽入口、出站與系統路由，且只展示 IPv4 位址池；不能據此認定 AAAA 查詢也會以相同方式處理。實際部署時，請參照目前核心的文件設定 IPv6 行為與真實 DNS 備援路徑。

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

接收虛擬位址連線的對應入站，也需要設定還原機制。以下僅展示該入站中的 sniffing 欄位，不會自動補齊其他入站參數。routeOnly 通常表示嗅探結果只用於路由、不改寫目標；本例明確設為 false，避免將尚未還原的虛擬目標繼續交給出站。

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

適用與不適用的情境

FakeDNS 最適合已採用 TUN 或透明代理，且需要依網域分流的環境。透明入口從網路層接收連線，不一定能從連線本身取得網域；透過對應表，網域規則便不必完全依賴 HTTP Host 或 TLS 握手資訊。若希望將真實解析延後至代理出口處理，也可考慮使用；但能否達成仍取決於出站、路由與真實 DNS 的組合。

明確代理與透明代理應分開判斷：支援網域目標的 SOCKS 請求或 HTTP CONNECT 請求可以直接傳送網域，不一定需要 FakeDNS；但如果應用程式先在本機解析，再向代理提交 IP，網域仍可能遺失。是否需要啟用，應以實際請求形式為準，不要只看到「系統代理」四個字就直接判斷。

常見副作用：快取、內網與解析繞道

FakeDNS 會建立一份具有存續期限的本機對應表，但應用程式與系統可能仍會快取舊的 DNS 回應。核心重新啟動後，若原有對應已消失，應用程式仍以舊的虛擬 IP 發起連線，就可能出現「剛啟動時正常，切換模式後卻無法連線」的狀況。此時反覆更換節點通常無效，因為問題發生在選擇出站之前。

• 切換模式後無法連線：停用 FakeDNS 或結束 TUN 後，快取中的虛擬位址仍可能被使用。請先恢復一致的接管模式，再清除快取並重新啟動相關應用程式。
• 區域網路服務異常：內部網域可能需要由辦公室 DNS 回傳內部位址。請讓這些網域使用明確的真實解析與直連路徑，而非將所有查詢一律送入虛擬位址池。
• 應用程式自行解析：若應用程式內建 DoH、DoT 或解析結果，傳統 DNS 接管可能完全看不到查詢。此時沒有虛擬對應資料是預期情況，不代表位址池失效。
• IPv4 與 IPv6 行為不一致：A 查詢走虛擬位址池、AAAA 查詢卻走另一條路徑時，同一個應用程式可能會有不穩定的表現。請分別檢查兩種記錄、IPv6 路由與對應的位址池設定。
• 診斷工具結果不同：解析工具顯示 198.18 網段，不代表網域的真實位址就在該網段。測試虛擬 IP 的連線狀態，也無法直接反映遠端網站是否正常。

FakeDNS 並不等同於「不會發生 DNS 洩漏」。本機直連出站仍可能觸發真實解析，應用程式也可能繞過受控 DNS。若要確認解析路徑，應分別觀察查詢送往何處、連線使用哪個出站，不要只因某次解析回傳虛擬位址就下結論。

依序排查虛擬 IP 連線失敗

建議先固定一個網域、一個應用程式和一個節點，記錄切換前後的狀況。以下以 www.example.com 為查詢範例；命令用來查看本機目前的解析路徑，但不保證查詢一定會進入 FakeDNS。Windows、macOS 與 Linux 的解析工具，也可能採用與瀏覽器不同的解析路徑。

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

1. 先確認解析是否進入虛擬位址池：若 A 記錄結果是設定的位址池中的位址，表示該次查詢取得了虛擬結果；若仍是實際 IP，請確認查詢是否繞過受控 DNS，以及目標網域是否符合真實解析例外規則。
2. 再確認連線是否進入核心：應用程式建立連線時，請查看存取記錄。若解析結果是虛擬位址，但核心沒有相應的連線記錄，應優先檢查 TUN 路由與入口接管，不要先修改節點的 VMess 或 VLESS 參數。
3. 確認對應資料能否還原：若記錄中始終只有虛擬 IP，請確認接收連線的入站是否啟用了相符的還原設定，以及是否曾重新啟動核心、更換位址池或切換多個執行個體。記錄的顯示格式會因版本而異，不要只憑單行內容就判定失敗。
4. 最後檢查路由與出站：若網域已成功還原但仍無法連線，再確認網域規則選中了哪個出站。直連需要可用的真實解析路徑；代理出站則需繼續檢查節點連線、伺服器端解析與傳輸設定。

Windows 可使用下列命令清除系統 DNS 快取，但不會清除所有應用程式的快取。清除前請先確認目前的接管模式正確，否則應用程式只會再次取得無法使用的結果。若瀏覽器或常駐背景程式仍有異常，請先關閉相關程序再試。

ipconfig /flushdns