V2Ray FakeDNS 是什麼？虛擬 IP 對應原理與啟用時機

FakeDNS 是什麼：回傳對應位址，而非網站的真實 IP

一般 DNS 查詢會將網域名稱解析為伺服器的真實位址；FakeDNS 則會先分配一個僅供目前代理連線識別的位址。例如，應用程式查詢 example.com 時，FakeDNS 可以回傳位址池中的 198.18.0.1，並在記憶體中記錄兩者的對應關係。這個位址不是網站伺服器的位址，也不應直接交由公網路由存取。

接著，應用程式會連線至合成位址。代理收到連線後，會從對應表找回原始網域名稱，再依網域規則決定直連或走代理。最後如何取得真實 IP，取決於出口類型與 DNS 解析策略：可能由本機直連出口解析，也可能將網域名稱交由遠端代理處理。FakeDNS 並不會免除最後連線至真實伺服器的需求。

常見範例使用 198.18.0.0/15，也就是從 198.18.0.0 到 198.19.255.255 的特殊用途位址範圍。這段位址原本用於網路設備基準測試，不是可任意存取的公網網站位址，也不是一般區域網路常用的私有位址範圍。將它用作合成位址池前，仍須確認企業網路或測試網路並未實際使用這段位址。

FakeDNS、嗅探與 TUN：三者各自負責什麼

這三者常出現在同一個設定介面，但負責的工作並不相同。FakeDNS 管理位址與網域名稱的對應關係；TUN 透過虛擬網路介面，將符合條件的 IP 流量送進客戶端；嗅探或入站目標還原機制，則會從連線資訊還原出可供路由與出口使用的目標。只啟用其中一項，無法確保整條連線路徑正常運作。

HTTP Host、TLS SNI 嗅探與 FakeDNS 對應還原並非完全相同的機制。前兩者會嘗試從協定資料中識別網域名稱，結果會受到協定、加密方式與應用程式行為影響；FakeDNS 還原則主要依賴先前儲存的對應關係。若應用程式直接連線至真實 IP、略過客戶端自行解析，或繼續使用上次執行時留下的合成 IP，就可能找不到可用的對應資料。

啟用時機：確有網域規則需求，再確認接管條件

當透明代理收到的主要是 IP 連線，而路由規則又需要原始網域名稱時，才值得考慮使用 FakeDNS。它可降低「先解析出真實 IP，再猜測這個 IP 對應哪個網域」的不確定性，也能讓部分請求不必等待本機取得真實解析結果，就進入後續處理。但 FakeDNS 不保證下載速度變快，也不會改變節點頻寬或線路壅塞情況。

• 可以嘗試：已穩定使用 TUN，且希望依網域分流；客戶端也能同時處理 DNS 查詢、合成位址路由與目標還原。
• 通常不必額外啟用：只使用系統代理，且應用程式已透過 HTTP CONNECT 或支援網域目標的 SOCKS 請求，將網域名稱交給代理；現有規則也能正確比對。
• 優先保留真實 DNS 解析：企業內網、區域網路裝置探索、依賴真實 IP 進行存取控管的軟體，以及需要直接檢視解析結果的網路診斷情境。
• 暫緩啟用：裝置上同時執行另一套 VPN 或透明代理，且尚未確認由哪一套服務管理 DNS、預設路由與合成位址範圍。

瀏覽器內建的安全 DNS、應用程式自帶的 DoH 等功能也必須一併檢查。接管傳統 UDP 53 查詢，不代表 HTTPS 內的 DNS 請求也會交由 FakeDNS 處理。只封鎖 443 連接埠會影響一般網頁瀏覽，不能當作通用解法；應檢查應用程式的 DNS 選項，確認由應用程式自行解析，還是交由客戶端統一處理。

設定欄位：位址池、DNS 與入站還原必須搭配使用

v2rayN 是桌面客戶端；v2rayNG 是使用 Xray 核心的 Android 客戶端；v2flyNG 使用 v2fly 核心。介面會產生或載入核心設定，但三款客戶端的選單、可用開關與產生的設定內容並不相同。不要將某個客戶端的介面截圖視為所有版本都適用的操作路徑，應以目前執行中的核心所支援的設定及記錄為準。

以下 JSON 範例用來說明欄位之間的關係，展示常見 V2Ray 風格的 IPv4 FakeDNS 設定。範例省略了入站、出口、路由與真實 DNS，並非可直接覆寫客戶端設定的完整內容。Xray 與 v2fly 的不同版本可能在行為或欄位上有所差異，儲存前應先確認目前使用的核心是否支援。

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

負責還原合成位址連線的入站，常見嗅探設定如下。這裡的 fakedns 是目標還原類型，不代表同時啟用了所有 HTTP、TLS 嗅探功能。不要為了讓「選項看起來完整」，就把其他版本使用的類型名稱也一併複製過來。

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

啟用後如何驗證：分別檢查 DNS、對應關係與路由

驗證重點不是「開關顯示已啟用」，而是同一次存取從網域查詢到最終出口都能得到合理結果。建議先記錄目前的代理模式、DNS 設定與核心類型，每次只調整一組設定。訂閱中的伺服器位址、連接埠與使用者識別資料並非 FakeDNS 位址池參數，測試時不必更動。

1. 建立基準。停用 FakeDNS 時，確認在相同網路下能正常存取目標網站，記錄使用的是系統代理還是 TUN，並留存一份原始設定。
2. 確認查詢路徑。啟用後，使用一個重新執行 DNS 查詢的網域進行存取，檢查 DNS 記錄是否進入預期的處理流程；若設定要求該查詢使用 FakeDNS，回覆位址應來自設定的位址池。
3. 確認連線回送。查看連線或核心記錄，確認連往合成位址的連線已進入代理，並在可檢視的記錄階段還原出網域名稱。不同記錄層級顯示的資訊可能不同，不能只憑一筆 IP 記錄就判定失敗。
4. 確認分流結果。分別測試一個預期直連及一個預期走代理的網域，核對實際使用的出口。只測試網頁能否開啟，無法證明路由規則有正確比對。
5. 補測相容性。檢查區域網路服務、應用程式內登入與背景網路連線；若已啟用 IPv6，也要檢查 AAAA 查詢，避免只驗證 A 記錄就認為所有流量都已接管。

在 Windows 上可執行 ipconfig /flushdns 清除系統 DNS 快取；瀏覽器或其他應用程式可能仍保留自己的快取與連線，須先結束再重新開啟。在 Android 上可先停止客戶端連線，再關閉並重新開啟測試用的應用程式。不要為了取得新結果，同時反覆切換網路、節點、協定與 DNS，否則測試結果就無法比較。

常見問題：延遲、解析結果與重新啟動後失效

停用與復原：同時撤銷 DNS 位址分配與流量接管

停用時要避免進入這種中間狀態：DNS 仍回傳合成位址給應用程式，但負責還原的入站或 TUN 已停止運作。較穩妥的做法是先暫停測試用的應用程式，還原原先搭配的 DNS 與代理設定，再重新啟動連線並清除舊快取。若客戶端提供整合式 FakeDNS 模式，應優先透過同一個入口復原，而非只手動刪除一行核心設定。

• 還原 DNS：確認新的查詢會回傳預期的真實解析結果，且系統沒有殘留無法連線的本機 DNS 位址。
• 還原路由：確認客戶端已正常撤銷不再需要的合成位址池路由、虛擬介面與接管規則。
• 還原應用程式連線：關閉舊連線，重新查詢網域名稱，再檢查網頁、內網服務與背景網路連線。
• 保留排查線索：記錄問題發生在哪個步驟，以及是否只影響特定應用程式；分享記錄前，請刪除訂閱網址、使用者識別資料等敏感資訊。

FakeDNS 的用途，是讓透明代理在進行路由判斷時仍能取得網域資訊。對於已穩定運作的系統代理，維持簡單通常更容易管理；若 TUN 確實需要依網域分流，則應確認 DNS 查詢、位址對應、入站與出口彼此搭配。更多基礎設定請參閱完整手冊的 DNS 設定，先確認一般 DNS 解析流程，再加入合成位址這一層。