FakeDNS 原理詳解：虛擬 IP 如何加速網域分流

FakeDNS 解決什麼問題

一般 DNS 模式下，應用程式會先將網域解析為真實 IP，再向該 IP 建立連線。代理核心接管連線時，看到的目標可能只剩一個位址，例如 203.0.113.20:443。如果同一個位址承載多個網域，或伺服器位址經常變動，只依 IP 撰寫路由規則就容易判斷錯誤。

FakeDNS 不負責提供真實公網位址。收到應用程式的 DNS 查詢後，它會從預設位址池分配一個虛擬 IP，並暫存「網域與虛擬 IP」的映射關係。應用程式接著連線至這個虛擬位址，TUN 入站攔截連線後，代理核心再從映射表取回原始網域。因此，路由模組可以直接比對 domain、domainSuffix 或規則集中記錄的網域。

常見的 IPv4 位址池是 198.18.0.0/15。此網段用於網路設備基準測試，不應出現在公網路由中，適合用作本機虛擬目標。一個 /15 網段包含 131072 個位址，但 Xray 設定通常會使用較小的映射池，例如 poolSize: 65535，避免建立沒有實際用途的超大型映射表。

上面的 1–3 毫秒，是同一台 Android 裝置連續查詢未快取網域時的本機回應範圍，只代表 FakeDNS 回傳虛擬位址所需的時間，不代表網頁完整載入速度。實際連線仍須經過節點握手、遠端解析、TLS 建立連線與內容傳輸。

一次網域請求如何經過虛擬 IP 映射

完整鏈路可以拆成六個步驟。第一步，應用程式向系統 DNS 發出 A 或 AAAA 查詢。第二步，TUN 模式將 DNS 流量交給代理核心。第三步，FakeDNS 從位址池取出尚未使用的位址並寫入映射表。第四步，應用程式收到虛擬位址後發起 TCP 或 UDP 連線。第五步，入站依目標位址反查網域。第六步，路由模組依網域決定直連、代理或阻擋。

1. 查詢進入代理核心：DNS 請求必須由 TUN 或受控的本機 DNS 攔截。如果應用程式自行連線至外部 DNS，FakeDNS 就無法取得這次查詢。
2. 建立暫時映射：例如 news.example 被分配為 198.18.0.12，映射只在本機記憶體中生效。
3. 應用程式連線至虛擬位址：應用程式會將 198.18.0.12 視為一般目標位址，不需要理解 FakeDNS。
4. 入站還原網域：核心透過映射表取得 news.example，並將網域交給嗅探與路由模組。
5. 路由規則命中：網域規則可在實際 DNS 查詢發生前決定出站，減少「先解析、後判斷」造成的資訊遺失。
6. 出站完成解析：直連出站通常會在本機解析真實位址；支援網域目標的代理出站則可以將網域交給遠端處理，實際行為取決於出站協議與 DNS 設定。

Xray 設定中的關鍵欄位

Xray 設定通常包含三個相互配合的部分：頂層 fakedns 定義位址池，dns.servers 將查詢交給 FakeDNS，入站的 sniffing.destOverride 允許核心從虛擬位址映射中還原目標網域。只加入其中一個欄位，無法組成完整鏈路。

以下是用來說明欄位關係的最小範例。用戶端產生設定時可能會加入本機 DNS、規則集與多個入站。編輯前應先匯出目前設定，並確認所使用的用戶端允許自訂底層 JSON；訂閱更新可能會覆蓋手動修改的節點參數。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  },
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "settings": {
        "stack": "system"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "metadataOnly": false
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

destOverride 中的 fakedns 用於讀取映射；http、tls 與 quic 則用於從相應的協議中繼資料補充網域。兩種來源並不衝突。映射可以直接提供已查詢過的網域，協議嗅探則能處理部分未經 FakeDNS、但握手時仍攜帶主機名稱的連線。

v2rayNG 使用 Xray 核心時，建議優先透過用戶端介面管理 TUN 與本機 DNS。常見的檢查路徑是「設定」→「VPN 設定」，查看流量接管相關選項，再到「設定」→「路由設定」確認規則順序。不同版本的開關名稱可能有所調整，因此應以匯出的執行設定與核心日誌判斷是否生效，而不要只看介面上的開關狀態。

哪些情境適合啟用 FakeDNS

FakeDNS 最適合用於 TUN 已接管整台裝置流量，且路由規則主要依網域撰寫的環境。Android 應用程式經常先自行解析網域，再將真實 IP 交給網路堆疊。當 TUN 只能看到目標 IP 時，網域規則的命中率取決於嗅探結果；加入 FakeDNS 後，DNS 查詢與後續連線會透過映射建立關聯，路由判斷也更直接。

• 大量網域分流：規則包含數千個網域後綴或規則集，需要在建立連線前明確取得目標網域。
• 共用位址服務：多個網站共用同一組服務位址，只依 IP 無法穩定區分不同業務網域。
• 位址頻繁變動：伺服器透過動態調度回傳不同位址，靜態 IP 規則很快就會失效。
• 遠端解析需求：代理出站需要保留網域，讓節點所在的網路完成最終解析。
• UDP 與 QUIC 流量：應用程式使用 UDP 443 時，可以透過 FakeDNS 映射與 QUIC 嗅探補充目標資訊。

如果只使用 v2rayN 的系統代理模式，瀏覽器通常會直接將目標網域提交給本機 SOCKS 或 HTTP 入站。此時核心已經取得網域，啟用 FakeDNS 未必能帶來明顯效益。是否需要開啟，應根據入站類型與日誌中顯示的目標形式判斷。

區域網路包含特殊路由時也要謹慎。部分實驗室、虛擬化平台或企業設備可能使用 198.18.0.0/15 進行效能測試或內部模擬。如果系統路由表已將此網段指向實體介面，FakeDNS 位址就會與現有網路重疊，表現為連線被送往區域網路而未進入 TUN。

FakeDNS、嗅探與 TUN 如何協同運作

TUN 的職責是攔截 IP 封包，FakeDNS 的職責是保存網域與虛擬位址的關係，嗅探的職責則是從 HTTP Host、TLS Server Name 或 QUIC 握手中擷取網域。三者解決的問題不同。只有依序將它們串接起來，網域規則才能涵蓋更多應用程式流量。

建議先建立最小可用鏈路，再逐項加入進階設定。一次修改位址池、DNS 伺服器、路由規則與 MTU，會讓故障來源難以區分。以下順序適用於 v2rayNG 的 Xray 核心設定，也適合檢查由訂閱產生的執行設定。

1. 在「設定」→「VPN 設定」確認 TUN 或 VPN 接管已啟用，並檢查目標應用程式是否被分應用程式規則排除。
2. 啟動連線後查看核心日誌，確認存在 TUN 入站，且沒有位址衝突、權限失敗或介面建立失敗。
3. 檢查執行設定中的 fakedns 位址池，並確認 DNS 伺服器清單包含 FakeDNS 處理項目。
4. 確認入站嗅探已啟用，destOverride 至少包含 fakedns；需要識別網頁流量時，再保留 http、tls 與 quic。
5. 在「設定」→「路由設定」檢查規則順序。阻擋規則、私有位址規則與直連規則若排在前面，可能會先於目標網域規則命中。
6. 使用一個尚未造訪過的測試網域發起連線，查看日誌是否依序出現虛擬位址、還原後的網域與最終出站標籤。

MTU 問題與 FakeDNS 屬於不同層級。若網域已正確還原，但頁面只載入少量內容或大型檔案停住，應檢查 TUN MTU。Android 裝置可將 1500 調整為 1400 或 1380 進行對照測試，每次只修改一個數值。若所有網域都無法建立連線，再回頭檢查 DNS 攔截與位址池路由。

Mux 也不會取代 FakeDNS。Mux 負責在單一底層連線中承載多個邏輯連線，主要影響連線重用；FakeDNS 則負責保留目標網域。啟用或停用 Mux 不應改變虛擬位址映射是否建立，但可能改變連線數量與日誌呈現方式。

常見故障與逐項排查

FakeDNS 故障通常有三種表現：應用程式收到虛擬 IP 後無法連線、網域規則未命中，以及關閉用戶端後短時間內仍無法存取。第一類優先檢查 TUN 是否攔截虛擬網段，第二類檢查映射與規則順序，第三類通常與系統 DNS 快取中殘留虛擬位址有關。

排查時不要只觀察瀏覽器結果。核心日誌至少要核對四件事：DNS 查詢是否進入用戶端、是否分配虛擬位址、入站是否還原網域，以及路由最終選擇哪個出站。四個步驟中缺少哪一步，就回到對應模組修改，而不是同時更換節點與協議。

還要區分「解析快」與「連線快」。FakeDNS 的本機回應可以在數毫秒內完成，但代理節點延遲、TCP 丟包、TLS 握手與伺服器回應仍會決定頁面速度。若虛擬映射與路由都正確，速度問題就應繼續檢查節點延遲、丟包率與傳輸參數。