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

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

一般 DNS 查詢會將網域轉換成實際伺服器 IP。FakeDNS 則會為查詢的網域指派一個虛擬 IP，並在本機維護「網域—虛擬 IP」對應關係。例如，應用程式查詢 example.com 後，可能取得位址池中的一個 IP；接著應用程式連線至該 IP，代理核心再依據對應關係找回原始網域。這個 IP 並非網站的實際伺服器位址，不能直接用來連線至公網。

這個流程有兩個必要條件：DNS 查詢必須由負責維護對應關係的元件處理，後續連線也必須回到能識別該對應關係的處理鏈。只符合第一個條件，應用程式取得虛擬 IP 後仍無法連線；只符合第二個條件，查詢回傳的若是實際 IP，FakeDNS 就沒有可用的對應資料。

還原網域後，代理便能依網域規則選擇直連或代理。直連通常仍需要取得可連線的實際 IP；代理出站能否將網域交由遠端解析，則取決於出站協定與設定。FakeDNS 改變的是本機解析與識別流程，不會取代最終連線目標的解析，也不會變更 VMess、VLESS 的協定參數。

FakeDNS、TUN 與流量嗅探各自負責什麼？

TUN 是流量入口，FakeDNS 是 IP 對應機制，嗅探則負責識別目標；三者並非同一個開關。TUN 接收到的通常是 IP 封包；如果應用程式已在其他地方完成解析，封包裡未必還有網域資訊，因此需要額外的網域識別途徑。

FakeDNS 還原網域主要依靠自身的對應資料，不要求應用程式一定傳送可讀的 HTTP 主機標頭或 TLS 主機名稱。不過，應用程式內建的加密 DNS、固定 IP 連線或獨立的解析快取，仍可能繞過這條對應路徑。不能因為「已啟用嗅探」，就認定所有連線都會套用網域規則。

啟用前：確認核心與 DNS 接管範圍

v2rayN 是桌面用戶端，實際支援哪些設定取決於目前使用的核心與執行模式；v2rayNG 適用於 Android，使用 Xray 核心；v2flyNG 適用於 Android，使用 V2Fly 核心。不能只看用戶端名稱，就認定各版本的設定欄位相同。特別要注意的是，TUN 流量入口與節點代理核心可能由不同元件負責，Xray 的 FakeDNS 欄位不能直接套用到其他元件的設定中。

IPv4 與 IPv6 必須分別確認。若只設定 IPv4 虛擬 IP 池，但應用程式仍能取得實際 IPv6 位址，連線就可能改走另一條路徑；這不一定代表故障，卻可能讓分流結果與預期不同。不要只為了讓測試結果一致就貿然關閉系統 IPv6，應先確認用戶端是否支援相應的 IPv6 接管功能。

Xray 設定範例：位址池、DNS 與入口還原

以下是用來說明欄位關係的 Xray JSON 片段，並非完整的 TUN 設定。內容示範頂層的 fakedns 位址池、DNS 的 fakedns 伺服器，以及 SOCKS 入口的網域還原設定。合併前請確認目前的 Xray 版本支援這些欄位，並逐項與現有的 dns、inbounds 設定合併，切勿覆蓋原有入口與出站設定。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "fakedns"
        ]
      }
    }
  ]
}

• poolSize: 65535 是對應池的容量設定，不是節點數量，也不代表速度。長時間執行時，對應資料的生命週期是否與應用程式快取協調一致更為重要。
• 127.0.0.1:10808 是本例使用的 SOCKS 入口，不是 DNS 監聽埠。將系統 DNS 設為這個位址與埠號，並不會自動建立 DNS 服務。
• 此處的 dns.servers 僅示範 FakeDNS。實際部署時，還須依核心支援的規則安排實際解析，不能讓所有需要實際 IP 的查詢都落入虛擬 IP 池。
• destOverride 中的 fakedns 用於從對應資料還原目標網域；它本身不會建立 TUN 網卡，也不會將系統 DNS 導入核心。

用戶端自動產生設定時，直接編輯暫存設定檔，可能會在重新啟動或切換節點後失效。請使用目前版本提供的自訂設定入口，或在支援範圍內調整 DNS 與入口設定。若要了解規則欄位，可先參閱設定大全；不要將不同核心的範例拼在同一份設定中。

驗證步驟：從 DNS 回應追蹤至路由結果

建議每次只變更一類設定，先備妥可還原的設定，再依下列順序測試。驗證重點是確認整條處理鏈完整運作，而不只是看到一個虛擬 IP。單獨測一次延遲，也無法證明網域分流正確。

1. 記錄基準狀態。選定一個測試網域，記下目前的 DNS 回應、連線是否成功，以及路由命中的出站。測試期間不要同時更換節點、訂閱與規則集。
2. 清除舊快取。在 Windows 的 PowerShell 執行 Clear-DnsClientCache，然後重新啟動測試中的應用程式。系統命令不會清除所有瀏覽器內部快取，也不會清除代理核心自己的對應資料。
3. 檢查回應位址。如果查詢確實經過設定的 IPv4 虛擬 IP 池，回應位址應落在 198.18.0.0/15 範圍內。如果仍回傳實際位址，請先檢查 DNS 的導向，不要立刻修改路由。
4. 實際發起連線。查看用戶端記錄中的目標是否已還原成預期網域，並確認命中的規則或出站。記錄欄位會因核心而異，且不保證每種記錄層級都會顯示對應細節。
5. 分別測試直連與代理。兩種目標都應能成功連線。如果只有直連失敗，請優先檢查實際 DNS 解析與直連出站；如果所有虛擬 IP 都逾時，請先檢查連線回收路徑。
6. 驗證停用後的狀況。關閉此模式後，再清除系統與應用程式快取，確認新的查詢不再沿用舊虛擬 IP；否則停用後的連線失敗，容易被誤判為網路故障。

適用情境與建議暫緩啟用的狀況

FakeDNS 適合需要透明接管、依賴網域規則，且能統一管理 DNS 的環境。它可以減少對協定嗅探結果的依賴，但也增加了維護對應狀態與快取一致性的需求。是否啟用，應視目前遇到的問題而定。

• 適合評估：啟用 TUN 接管後，記錄經常只顯示 IP，網域規則難以命中，而且能控制系統與應用程式的解析路徑。
• 可以維持現狀：瀏覽器透過明確設定的代理傳送網域，現有網域分流運作穩定，也沒有透明接管需求。
• 應先排查：企業內網使用分離式 DNS、內部網域，或有路由與虛擬 IP 池衝突的情況；應先區分內部查詢與公網查詢。
• 應謹慎測試：應用程式會將 DNS 結果長期儲存在磁碟、在不同處理程序間傳遞 IP，或在代理關閉後繼續使用舊連線。
• 不應期待藉此改善：節點無法連線、伺服器驗證參數錯誤或傳輸路徑壅塞。這些問題無法靠網域對應機制解決。

區域網路印表機、網路儲存裝置與內部業務網域，通常應保留符合本機網路需求的解析方式。將所有查詢一律改用虛擬 IP，可能破壞依賴實際位址的裝置探索、存取控制或診斷流程。先小範圍驗證，再逐步擴大，比一次啟用所有相關選項更容易找出問題。

FakeDNS 常見問題與排查順序

實際設定可依照以下順序進行：先確保一般代理與實際 DNS 正常運作，再驗證 TUN 接管，最後加入 FakeDNS。每個階段都保留記錄與可還原的設定，才能分辨問題出在解析、路由或出站連線。