V2Ray FakeDNS 原理與設定：虛擬 IP、流量嗅探與適用情境

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

一般 DNS 會將網域解析為可連線的實際位址。FakeDNS 則會為經過處理的 A 或 AAAA 查詢分配虛擬位址，並在本機保存「網域與虛擬位址」的對應關係。應用程式會以為取得一般解析結果，接著向該位址建立連線；代理核心接手連線後，會查詢映射表，還原原始網域，再交由路由與出站處理。

這裡的「還原」是查詢本機映射，不是向公共 DNS 發出 PTR 反向查詢。舉例來說，應用程式查詢 example.com 後取得池中的某個位址；核心偵測到應用程式連往該位址時，就能透過同一份映射表找回 example.com。實際分配到哪個位址取決於執行狀態，不應將特定虛擬位址永久寫入規則。

虛擬 IP 只是本機接管流程中的標記，不是網站伺服器的實際位址。它不能直接拿到另一台裝置上使用，也不能透過一般閘道傳送到公網後期待目標回應。即使最後選擇直連出站，也必須先正確還原網域，再由相應的解析與連線機制處理實際目標。

位址池與連接埠：先分清三個數值

198.18.0.0/15 涵蓋 198.18.0.0 至 198.19.255.255，是保留給效能測試使用的位址範圍，並非一般私有區域網路位址範圍。將它用作虛擬位址池，是利用這段位址不應作為一般公網目標的特性；不過企業網路、測試環境或其他隧道也可能使用它，啟用前仍應確認是否有路由衝突。

poolSize 代表映射池容量，不是 DNS 快取時間，也不是並行連線上限。本文的 4096 僅為設定範例，並非所有裝置都適用的最佳值。容量不足，或映射遭淘汰但應用程式仍保留舊位址時，可能導致還原失敗；排查時不能只清除瀏覽器快取，也要留意核心映射與系統 DNS 快取的生命週期。

• 位址池：決定哪些目的位址會被辨識為虛擬目標，不可與現有業務位址重疊。
• 映射容量：決定可保留多少映射項目；排查時應觀察實際狀況，不要根據數字推斷速度。
• DNS 入口：傳統 DNS 通常使用 UDP/TCP 53，但核心內建 DNS 模組不代表會自動在本機 53 連接埠監聽。

FakeDNS、sniffing 與 TUN：三者各司其職

TUN 負責接收路由至虛擬網卡的 IP 流量，本身不會確保所有連線都帶有網域資訊。一般 sniffing 會嘗試從 HTTP Host、TLS 交握等支援的協定資訊中辨識網域；FakeDNS 則依靠先前建立的映射還原網域。兩者都能補足網域資訊，但來源不同，不能視為相同機制。

如果應用程式直接使用 IP、使用未受接管的加密 DNS，或重複使用啟用前快取的真實位址，FakeDNS 就無法建立相應映射。此時即使連線仍依 IP 規則處理，也不能直接判定功能失效。反過來說，若只有 DNS 查詢進入 FakeDNS，而目標連線繞過 TUN 或透明入站，應用程式也會因使用虛擬位址而連線失敗。

Xray 設定範例：位址分配與入站還原缺一不可

以下展示 Xray 風格的欄位關係，並非完整的執行設定。V2Ray 是常用稱呼，實際欄位與行為仍以目前使用的核心為準。v2rayN 是用戶端，v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；不要只因介面名稱相近，就跨核心複製同一份 JSON。

第一段是頂層設定片段：宣告 IPv4 位址池，並讓內建 DNS 使用 FakeDNS。這裡只呈現最基本的關係，未包含節點伺服器網域解析、區域網路網域例外、IPv6 與 DNS 流量入口，不應直接取代用戶端產生的完整設定。

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

第二段屬於接收虛擬目標連線的入站物件，用於查表還原網域。此處只保留 fakedns，方便看清必要設定；若要新增 HTTP、TLS 等嗅探類型，應先確認所用核心是否支援。不要將此物件當成獨立的頂層設定，也不要誤加到完全收不到目標連線的入站物件。

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

• 若節點伺服器使用網域名稱，必須有能取得實際位址的解析流程，不能將虛擬位址當作連線節點的最終位址。
• 路由還原網域後，geosite: 規則才有相應的比對依據；geoip: 是用來比對 IP，不能把虛擬位址當成目標網站的所在地。
• 只設定 IPv4 位址池，不代表已涵蓋 AAAA 查詢與 IPv6 連線；雙堆疊網路需另外驗證。

適用情境：透明接管較有幫助，一般系統代理維持簡單即可

HTTP 代理與支援遠端解析的 SOCKS 請求，可以直接將網域傳給代理；這種情況下再加入 FakeDNS，未必能解決其他問題。透明接管只收到 IP 封包，更容易遺失網域脈絡，才是 FakeDNS 常見的使用情境。決定是否啟用前，先判斷流量缺少的是網域資訊，還是節點連線、出站解析或路由順序。

FakeDNS 不等於 DNS 加密，也不保證所有 DNS 查詢都會經過代理。它只會改變應用程式收到的解析結果；後續實際解析在哪一端進行、使用哪種傳輸方式，仍由出站與 DNS 策略決定。VMess 或 VLESS 等節點協定不會單獨決定 FakeDNS 能否運作，也不需要為此重新匯入訂閱。

驗證步驟：從解析結果一路追查到最終出站

1. 保留基準狀態。先確認一般代理模式下，同一個節點可以連上目標，並備份目前設定。暫時不要同時調整訂閱、路由規則庫與 DNS。
2. 檢查接管入口。啟用選定的 TUN 或透明接管方案，確認應用程式的 DNS 查詢與後續連線都進入預期流程。在 Windows 可前往「設定」→「網路和網際網路」確認目前的網路介面，但不能只憑實體網卡顯示的 DNS 值，就認定接管已成功。
3. 清除舊快取。關閉測試中的應用程式；在 Windows 可於命令提示字元執行 ipconfig /flushdns 清除系統快取，再重新開啟應用程式。瀏覽器本身的快取與加密 DNS 設定仍需另外確認。
4. 觀察實際查詢。透過應用程式發出請求以觸發解析，並搭配 DNS 記錄確認回傳位址是否屬於設定的位址池。nslookup example.com 可供參考，但它的查詢路徑可能與瀏覽器不同，不能只憑一次結果判斷所有應用程式。
5. 確認還原與分流。查看可用記錄中的原始虛擬目標、還原後的網域、命中的規則及出站標籤。記錄詳細程度會因核心與用戶端而異；必要時可暫時提高記錄層級，測試結束後再還原。
6. 驗證例外情況。分別測試內部網站、IPv6 目標與直連規則。只確認一個代理網站能開啟，還不足以證明整套 DNS 策略正確。

測試資料應能回答具體問題：DNS 回傳了什麼、連線去了哪裡、命中了哪條規則。單獨執行 ping 不適合用來判斷網頁代理是否可用，因為虛擬位址不一定會回應 ICMP，而網頁使用的是另一條連線路徑。也不要把取得虛擬位址的速度當成網站連線延遲，兩者並非同一項指標。

常見問題：虛擬位址殘留、內網異常與分流失效

若問題只在核心重新啟動後出現，還需考慮映射狀態與應用程式快取不同步：應用程式保存了舊虛擬位址，但新啟動的程序沒有對應項目。此時重新啟動應用程式並再次解析，比反覆切換節點更能對症處理。如果擴大位址池後仍反覆發生，也應重新檢查是否有多個 DNS 處理元件；不能無止境擴充容量來取代故障排查。

復原順序：還原 DNS、清除快取，再測試一般代理

判斷這項功能不適合目前的網路時，依原設定復原即可。重點是同時撤銷虛擬位址分配與依賴它的接管設定，避免只留下半套流程。用戶端更新可能改變設定產生方式，復原時應以先前備份的設定為準，不要猜測曾經開啟過哪些選項。

• 還原原本的 DNS 伺服器、網域例外與用戶端接管設定。
• 確認實體網路介面與系統路由中，沒有殘留虛擬位址池的接管規則。
• 結束應用程式、清除 DNS 快取，再以一般系統代理方式測試相同目標。
• 記錄問題發生在查詢、映射還原或出站連線哪個階段，下次只調整相應環節。

記住這個重點就夠了：FakeDNS 的用途，是為需要網域資訊的分流流程補足資料。若網域已能穩定傳遞，就不必為了多開一個選項而增加複雜度；只有透明接管確實缺少網域資訊時，才逐一接通位址池、查詢入口、入站還原與出站解析。更多欄位關係可參考設定參考中的 DNS 設定；基本連線問題請先查看連線問題排查說明。