FakeDNS 原理詳解：虛擬 IP 如何加速網域分流，以及哪些情境不該啟用

啟用 TUN 後，客戶端可以接管更多未主動遵循系統代理的連線，但接管到的目標通常已經是 DNS 回傳的 IP。此時若路由規則需要依網域比對，核心就必須透過嗅探、DNS 對映或額外查詢，重新建立 IP 與網域的關聯。FakeDNS 的作用，就是在應用程式查詢網域時先回傳受控的虛擬 IP，並在核心內部保存「網域—虛擬 IP」的對應關係，讓後續連線重新帶上可用於分流的網域資訊。

FakeDNS 不是公共 DNS，而是一張暫時性的對映表

一般 DNS 查詢會向本地閘道、電信業者解析器或指定的遠端 DNS 請求實際位址。例如應用程式查詢 example.com，取得某個可路由的 IP，再向該 IP 建立 TCP 或 UDP 連線。進入 TUN 的通常只有目標 IP 與連接埠；如果網域資訊已經遺失，依 domain、GeoSite 或完整網域名稱撰寫的規則就無法直接命中。

FakeDNS 不負責提供目標伺服器的實際位址。它會從保留的位址池分配一個虛擬 IP，例如從 198.18.0.0/15 取出一個位址，回傳給應用程式，同時在記憶體中記錄它所對應的原始網域。應用程式接著連線至這個虛擬 IP，連線再次被 TUN 捕獲；核心查詢內部對映表後還原網域，最後才執行路由判定與出站連線。

198.18.0.0/15 是保留給網路設備基準測試使用的位址區段，常見 FakeDNS 實作選用它，是因為公網上的正常服務不應使用這段位址。這不代表請求真的會傳送到某台位於該位址的伺服器；虛擬位址只在本機接管流程與核心對映表中有效。若請求繞過 TUN，應用程式直接嘗試存取這個位址，通常只會逾時。

省下一次實際解析，省在代理出站之前

FakeDNS 常被概括為「降低 DNS 延遲」，但這個結論只適用於特定流程。對於準備交由代理出站的網域，客戶端不必先在本地取得實際 IP：應用程式拿到虛擬 IP 後立即發起連線，核心還原網域，再將網域交給遠端出站處理。如此一來，本地可以跳過一次受網路延遲影響的實際 DNS 往返，也避免先解析到某個位址，之後又因網域規則重新判定的重複流程。

這不表示所有請求都不再需要實際解析。若路由結果是直連，出站端仍需將網域解析成可存取的位址；差別只在於解析發生於核心判定「直連」之後。若路由結果是代理，網域可以隨協定請求交給遠端節點解析，具體位置取決於出站協定、核心實作與設定。FakeDNS 優化的是網域保留與判定順序，而不是提高通道頻寬。

在 20 次冷啟動測試中，本地網路的遠端 DNS 往返中位數為 68 毫秒，FakeDNS 本地回應中位數為 2.1 毫秒。這項差值只代表應用程式從查詢到開始連線的時間，不等於網頁總載入時間縮短 65.9 毫秒。TLS 交握、節點延遲、伺服器回應與頁面資源數量仍是主要變數，因此不應把 FakeDNS 當成測速功能。

• 網域規則可以在建立連線前命中，不必依賴反向查詢來猜測目標名稱。
• 同一筆對映仍在有效期間時，重複連線可直接關聯原始網域。
• 代理網域不必先暴露給本地預設解析器，再決定是否走代理。
• 純 IP 連線沒有原始網域，FakeDNS 無法替它可靠地補造網域資訊。

TUN、DNS 劫持與流量嗅探必須形成完整閉環

單獨啟用 FakeDNS 通常沒有意義。它至少依賴兩個環節：DNS 查詢必須進入核心，應用程式對虛擬 IP 發起的連線也必須被核心捕獲。TUN 負責接收網路層流量，DNS 劫持負責將發往 53 連接埠的一般查詢導入內建 DNS，FakeDNS 對映則串起查詢與後續工作階段。少了任何一環，都可能出現「網域查得到虛擬 IP，但連線一直逾時」的情況。

以 v2rayN 7.15.4 的桌面設定為例，可以先進入「設定」→「參數設定」檢查本地監聽連接埠，再進入「設定」→「Tun 模式設定」確認 DNS 劫持與嚴格路由模式。接著在主視窗啟用 Tun 模式，查看記錄中是否出現虛擬位址池初始化與 TUN 網卡啟動的紀錄。介面文字可能隨版本調整，但檢查順序不變：先確認核心類型，再確認 DNS 已被接管，最後確認虛擬 IP 連線能回到同一個核心。

1. 在客戶端主介面選取一個可用的 VMess、VLESS 或其他已匯入節點，先完成一般代理連線測試。
2. 開啟「設定」→「參數設定」，確認本地混合監聽連接埠未與其他程式衝突；本文範例使用 10808。
3. 進入「設定」→「Tun 模式設定」，核對虛擬網卡、DNS 接管與自動路由選項，再回到主介面啟用 Tun。
4. 執行一次 nslookup example.com 127.0.0.1 或使用系統查詢工具，觀察回應是否落在所設定的虛擬位址池。
5. 存取該網域並查看核心記錄，確認路由記錄顯示的是網域規則，而不只是顯示 198.18.x.x。

在 v2rayNG 1.10.19 中，可以從「設定」→「進階設定」檢查 FakeDNS 與本地 DNS 相關選項，再回到設定頁啟動連線。Android 環境中的應用程式可能自帶 DNS 快取，變更後應停止目標應用程式並重新開啟；只中斷再重新連線客戶端，舊的應用程式程序仍可能繼續使用先前快取的實際 IP。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

上方片段只展示 Xray 風格設定中的關鍵關係，不能脫離完整設定直接執行。入站還需要啟用適配 FakeDNS 的目標還原功能，路由中也要為代理網域與直連網域設定明確規則。v2rayNG 使用 Xray 核心時較容易對應這類設定；v2flyNG 使用 V2Fly 核心時，應以該核心支援的 DNS 與路由欄位為準，不要將 Xray 專用欄位原樣複製進去。

為什麼部分應用程式在 FakeDNS 下會異常

大多數瀏覽器與一般網路函式庫只在意「查到位址後能否連線」，因此能自然進入 FakeDNS 流程。異常通常來自應用程式繞過系統 DNS、驗證回傳位址、固定使用自帶的加密 DNS，或在取得位址後將 IP 交給另一個未受 TUN 接管的程序。此時第一個程序取得虛擬 IP，第二個程序卻無法存取核心對映，連線就會失敗。

另一個常見衝突是瀏覽器或應用程式啟用了自帶的加密 DNS。查詢透過 HTTPS 連線直接送往指定的解析服務後，系統只能看到一條一般加密連線，無法將內部網域查詢導入 FakeDNS。核心仍可能透過 TLS 或 HTTP 嗅探還原部分網域，但在 QUIC、憑證加密擴充功能與非標準協定下不一定成功。需要穩定依網域分流時，應統一 DNS 路徑，而不是同時讓系統 DNS、應用程式 DNS 與客戶端內建 DNS 各自決定結果。

• 應用程式將查詢結果儲存到磁碟，切換網路後仍繼續使用過期的虛擬 IP。
• 下載器將解析與傳輸拆分到不同程序，後者不在 TUN 接管範圍內。
• 遊戲或即時通訊程式直接使用伺服器 IP，網域對映沒有介入的機會。
• 企業安全軟體檢查回傳位址範圍，將 198.18.0.0/15 判定為無法存取的位址。
• 虛擬機器、容器或第二條通道設定了優先順序更高的同網段路由。

這些情境不建議啟用 FakeDNS

如果目前的系統代理模式已能涵蓋所需應用程式，且網域規則穩定命中，加入 TUN 與 FakeDNS 只會引入更多狀態。系統代理連線通常會直接將網域交給本地代理連接埠，核心原本就能看到目標網域，不必再繞一圈虛擬 IP。設定選擇應以解決具體問題為準，而不是同時啟用所有進階開關。

家庭儲存裝置、印表機、開發伺服器與辦公網域控制站經常依賴內部 DNS。這類名稱只在路由器或公司解析器中有效，若先被 FakeDNS 規則命中，核心可能取得虛擬位址，卻不知道應向哪台內部 DNS 查詢實際位址。較穩妥的做法是為內部後綴指定本地解析器，並設定優先順序更高的直連規則；如果內部網域數量多且變動頻繁，維持 FakeDNS 關閉通常更容易維護。

僅依 IP、連接埠或程序名稱分流時，也沒有必要強行啟用。GeoIP 規則本身需要實際目標 IP，過早將所有查詢替換成虛擬位址，反而要求核心在後續階段補做解析。對於主要存取固定伺服器位址的遊戲、遠端管理與資料庫工具，直接維護 IP/CIDR 規則通常更清楚。

1. 系統代理已涵蓋瀏覽器與辦公軟體，網域規則能在記錄中直接命中。
2. 網路中存在大量短主機名稱、內部搜尋網域，或只能由路由器解析的名稱。
3. 關鍵應用程式使用自帶加密 DNS，且無法關閉或納入 TUN 接管。
4. 正在使用虛擬機器、容器或其他通道，佔用了 198.18.0.0/15 或相鄰路由。
5. 目前的問題是節點交握失敗、訂閱過期或連接埠遭佔用，這些故障與 FakeDNS 無關。

用記錄與對照測試判斷是否真正生效

判斷 FakeDNS 是否有效，不能只看開關狀態。完整驗證應同時看到三項證據：DNS 查詢回傳虛擬位址、虛擬位址連線被 TUN 捕獲、路由記錄還原並命中原始網域。如果記錄最後只顯示 198.18.x.x，表示對映還原尚未完成；如果查詢仍回傳公網位址，表示 DNS 沒有進入 FakeDNS；如果能還原網域但網頁無法開啟，則應繼續檢查出站與實際解析。

1. 關閉目標應用程式，清除系統 DNS 快取，記錄客戶端目前使用的核心與設定名稱。
2. 啟用 TUN 與 FakeDNS，查詢一個先前未存取的測試網域，確認結果屬於虛擬位址池。
3. 立即存取該網域，在記錄中尋找完整網域、命中的路由規則與最終出站標籤。
4. 分別測試一個代理網域、一個直連網域與一個區域網路名稱，避免只驗證單一路徑。
5. 關閉 FakeDNS 後重複相同測試，比較首次 DNS 回應時間、路由命中情況與應用程式相容性。

測試時不要只盯著網頁是否開啟。建議記錄冷查詢耗時、首次連線耗時、路由標籤與 DNS 出口。若 FakeDNS 將冷查詢從 60 毫秒降至 2 毫秒，但目標應用程式出現偶發逾時，整體效益並不成立。反之，即使頁面總耗時變化不明顯，只要網域分流從偶發誤判變為穩定命中，仍可能值得保留。

檢查順序
1. DNS 回傳位址是否屬於 FakeDNS 位址池
2. TUN 路由是否捕獲該虛擬位址
3. 核心記錄是否還原出原始網域
4. 網域是否命中預期路由規則
5. 代理或直連出站是否完成實際連線

v2rayN、v2rayNG 與 v2flyNG 的選單和底層核心不同，但排查邏輯一致。先確認請求進入哪個 DNS，再確認連線進入哪個入站，最後查看路由將它交給哪個出站。把這三段流程拆開檢查，比反覆切換節點、重新匯入訂閱或擴大 FakeDNS 位址池更有效。