FakeDNS 是什麼？虛擬 DNS 原理、TUN 模式搭配與適用情境

FakeDNS 原理：以暫存位址保留網域資訊

FakeDNS 回傳的是本機映射位址，而非網站伺服器的真實位址。一般 DNS 查詢會將網域轉換為真實 IP；FakeDNS 則從預先設定的位址池分配一個位址，並記錄「網域與暫存位址」的對應關係。應用程式仍依照一般流程連線至該位址，代理接管後再根據映射還原網域，交由後續路由與出口處理。

Xray 常見的 IPv4 位址池範例為 198.18.0.0/15，範圍從 198.18.0.0 到 198.19.255.255。這是保留供基準測試使用的位址範圍，不是公網伺服器位址，也不是常見的家用區域網路私有位址範圍。在設定正確的 FakeDNS 流程中，應用程式取得這類結果是正常現象。

這套機制的關鍵在於「位址可以還原成網域」。如果應用程式連線至虛擬位址時繞過代理，或接管連線的核心沒有對應的映射表，虛擬位址就無法正常用來存取網站。只在 DNS 設定中填入位址池，卻未設定連線接管與還原流程，通常只會讓原本能存取的網站連線逾時。

FakeDNS 與 TUN：接管流量不代表接管 DNS

TUN 負責將網路封包送進代理處理，FakeDNS 則負責讓網域資訊在此過程中得以還原。兩者經常搭配使用，但並非同一項功能。啟用 TUN 後，應用程式的連線可能已被接管，但 DNS 查詢仍可能送往路由器、企業 DNS，或瀏覽器自己的加密 DNS 服務；此時取得的仍是真實位址，也不會建立 FakeDNS 映射。

網域還原與流量嗅探也應分開看待。HTTP Host、TLS 中的伺服器名稱等資訊可協助辨識部分連線，但並非每種連線都能讀取到網域。FakeDNS 依靠先前的查詢映射還原網域，不必完全仰賴應用層內容；不過，若應用程式直接使用 IP，或未經過該 DNS 入口，FakeDNS 也無法憑空找出原始網域。

Xray 設定：分別檢查位址池與入口還原

Xray 的 FakeDNS 必須搭配位址池設定與實際 DNS 使用方式。以下是用於說明的頂層設定片段，並非可直接執行的完整用戶端設定。內容僅展示 IPv4 虛擬位址池與內建 DNS 的伺服器選擇；完整設定還需要入口、路由與出口，並確保應用程式的查詢確實進入此 DNS 模組。

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

poolSize 表示映射池容量，不是 DNS 監聽連接埠，也不是網路速度參數。範例中的 65535 不代表網站能取得 65535 條並行連線。FakeDNS 的 DNS 設定也不能單獨處理所有真實解析需求：需要真實 IP 的直連目標、代理伺服器網域，以及特殊內網網域，都應有明確的真實解析路徑，避免連線準備階段也取得無法直接使用的虛擬位址。

對支援此機制的 Xray 入口而言，sniffing.destOverride 中的 fakedns 用於查詢映射並還原目標。請勿將這些欄位直接貼到其他核心的設定中，也不要只修改未接收 TUN 流量的入口。如果用戶端會自動產生設定，手動修改暫存檔也可能在下次啟動時被覆寫，建議優先使用用戶端提供的設定介面。

適用情境：以網域分流為優先，內網解析另行保留

FakeDNS 較適合「流量經透明方式接管，但仍需依網域選擇出口」的情境。例如，部分應用程式不使用系統 HTTP 代理，啟用 TUN 後只能看到連線目標 IP；透過 FakeDNS 保留映射，可讓路由重新取得網域條件。它改善的是辨識流程，不會改變訂閱節點的品質，也不會自動將 VMess 轉換成 VLESS。

區域網路印表機、企業內部服務及依賴本機探索的應用程式，不宜一律交由 FakeDNS 處理。多點傳播探索與一般單點傳播 DNS 也不是同一套機制。應先保留這些服務原有的解析路徑，再逐步擴大接管範圍；若將內部網域交給公用 DNS 解析，即使關閉 FakeDNS，仍可能無法存取。

驗證與排查：先檢查解析，再確認目標與出口

驗證 FakeDNS 不應只看網頁能否開啟。網頁可能因既有連線、快取或瀏覽器獨立 DNS 而正常載入，無法證明新設定已生效。建議一次只變更一項設定，記錄變更前後的 DNS 結果、連線目標與出口標籤；以下步驟不依賴特定用戶端版本，也不假設某個選單名稱適用所有版本。

1. 確認實際使用的核心。在 v2rayN 的核心選擇介面或執行記錄中確認啟動的核心，並記下目前用戶端與核心版本。若設定出現「未知欄位」錯誤，應先確認欄位所屬的核心，而非反覆切換訂閱節點。
2. 檢查 DNS 入口。一般 DNS 常使用 UDP 或 TCP 的 53 連接埠，但內建 DNS 模組不代表系統已在該連接埠監聽。請確認用戶端的 DNS 接管設定與系統 DNS 位址，不要直接假設 127.0.0.1:53 可以使用。
3. 清除舊快取。關閉測試中的應用程式並清除系統快取，再重新啟動應用程式；瀏覽器可能另有 DNS 快取與安全 DNS 設定，請分別確認。
4. 確認位址與還原結果。查詢結果應符合所設定的位址池，連線記錄則應顯示還原後的網域或相應處理資訊。只看到 198.18.x.x 並不能證明出口連線成功。
5. 確認真實解析與路由。檢查直連目標與代理伺服器網域能否取得真實位址，再確認網域規則命中的出口。排查完成後，請恢復一般記錄層級，避免長期保留大量連線資訊。

在 Windows 上可使用以下命令清除系統 DNS 快取，並查看各網路介面設定的 DNS 伺服器。第二個命令需在 PowerShell 中執行。這些命令可協助定位 DNS 入口，不會自動修改用戶端規則，也無法清除應用程式內的所有快取。

ipconfig /flushdns

Get-DnsClientServerAddress -AddressFamily IPv4

如果測試工具回傳真實位址，請先確認它查詢的是哪一台 DNS 伺服器，再判斷 FakeDNS 是否失效；若回傳虛擬位址但連線逾時，應優先檢查位址池流量是否進入正確入口，以及映射是否仍有效。重新啟動核心後，應用程式可能仍使用舊的虛擬位址，而新核心已沒有對應映射；此時重新啟動應用程式並清除快取，比反覆更換節點更有效。

• 出現 AAAA 結果，但 IPv4 映射正常：請檢查 IPv6 接管與 DNS 策略，不能只憑 IPv4 成功就認定所有連線都已進入代理。
• 企業網路出現異常：請確認是否已有網路設備使用 198.18.0.0/15，避免位址池與現有路由衝突。
• 懷疑 DNS 外洩：請分別檢查傳統 DNS、加密 DNS 與 IPv6 路徑；出現虛擬位址本身，不能證明所有查詢都未傳出。

常見問題：啟用、延遲與關閉後如何恢復

最終判斷應以完整連線流程為準：應用程式取得什麼位址、哪個入口接管連線、能否還原網域，以及規則選擇了哪個出口。若要進一步調整路由與代理模式，請參閱完整設定手冊；初次設定用戶端，則先依照使用指南建立可正常運作的基礎，再加入 FakeDNS。