FakeDNS 原理解析：假位址映射如何降低 DNS 解析延遲

FakeDNS 流程：先回傳假 IP，再還原原始網域

一般 DNS 流程會先將網域名稱傳送給解析伺服器，取得真實的 A 或 AAAA 記錄後，應用程式才連線至回傳的位址。這個過程至少包含一次 DNS 往返；若系統 DNS 回應緩慢、解析請求走錯出口，或本機快取未命中，建立連線就會卡在解析階段。

FakeDNS 改變的是本機解析路徑。應用程式查詢網域名稱時，核心不必立即向公共 DNS 取得真實位址，而是從預設位址池分配一個假 IP，同時記錄「網域名稱—假 IP」的對應關係。應用程式接著向假 IP 發起連線，TUN 入站擷取這條連線，核心依據映射表找回原始網域，再按照網域規則選擇代理、直連或封鎖出口。

常見的 IPv4 位址池是 198.18.0.0/15。這段位址用於網路設備基準測試，不屬於可在公網路由的位址，因此適合在本機內部作為映射標記。假 IP 不是目標伺服器位址，也不會作為最終目的地直接傳送至代理節點；它的作用類似本機索引，真正的代理請求仍以還原後的網域名稱為目標。

以上延遲數據來自同一台裝置連續執行 100 次冷查詢的範例：本機 FakeDNS 回應中位數約為 1.2 毫秒，遠端 DNS 往返中位數約為 43 毫秒。這只能說明首次解析回應可能更快，不代表網頁總載入時間一定減少 41.8 毫秒；TLS 交握、節點往返、封包遺失與伺服器回應仍會決定後續速度。

映射表、流量嗅探與出站如何協同運作

FakeDNS 能否正常運作，取決於三個環節是否同時成立：核心收到 DNS 查詢、假位址連線由對應入站擷取，以及在出站前能透過映射記錄還原網域。只啟用位址池，卻未讓 TUN 流量進入核心，就會出現應用程式取得 198.18.x.x 後無法連線的情況。

核心收到指向假 IP 的連線後，會檢查目標是否屬於 FakeDNS 位址池。若映射表中存在對應記錄，例如 198.18.0.27 對應 example.net，就能將目標還原為網域名稱。接著，路由器按照設定順序檢查網域規則、IP 規則、連接埠規則與入站標籤，最後選擇代理或直連出站。

這裡容易混淆「協定嗅探」與「FakeDNS 還原」。HTTP、TLS 或 QUIC 嗅探會嘗試從流量內容辨識網域名稱；FakeDNS 還原則是直接讀取先前建立的映射。兩者可以並存，但映射還原不依賴每條連線都暴露可辨識的主機名稱，因此對不易從負載中擷取網域名稱的連線更穩定。

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

這段設定只展示位址池與 DNS 伺服器之間的概念關係，無法脫離入站、路由與出站單獨使用。由用戶端產生實際設定時，還要確認 TUN 入站已啟用目標還原，且本地網路沒有將同一網段用於實驗裝置或企業測試環境。

FakeDNS 對延遲與分流的實際影響

FakeDNS 最直接的效益，是將「應用程式等待真實 DNS 回應」改為「應用程式立即取得本機假位址」。當遠端 DNS 往返時間較長、首個封包容易逾時，或多個應用程式同時發起冷查詢時，差異會較明顯。已命中系統快取的網域不需再次承擔完整解析延遲，效益則會縮小。

第二項效益是保留網域資訊。一般解析後，應用程式只連線至真實 IP，進入 TUN 的資訊可能只剩目標位址；若同一個 IP 承載多個網域，單靠 IP 規則很難精確區分。FakeDNS 在連線階段還原原始網域後，像 domain、domainSuffix、geosite 這類規則就能在選擇出站前參與比對。

觀察項目	一般遠端 DNS	FakeDNS	判斷方式
首次回傳位址	真實 A/AAAA 記錄	保留網段假 IP	查看應用程式端的解析結果
網域資訊	解析後可能只剩 IP	由映射表還原	查看路由命中記錄
冷查詢延遲	受 DNS 往返時間影響	通常為本機回應	連續測試並比較中位數
最終連線目標	真實 IP 或遠端解析結果	還原後的網域名稱	查看代理出站記錄

第三項影響是讓解析出口更加一致。若某個網域應該走代理，系統卻先透過本地網路查詢 DNS，解析路徑與流量路徑就可能分離。FakeDNS 讓本機先完成假位址分配，真實解析可延後至代理出站端處理，降低本地 DNS 對代理網域解析結果的干擾。

FakeDNS 也會改變故障排查方式。看到 198.18.x.x 不應立即判定為解析錯誤，應先檢查該位址是否屬於設定中的池、是否存在映射記錄，以及連線是否已進入 TUN。只有當應用程式收到假位址，而核心無法還原網域名稱時，才表示鏈路中途發生中斷。

搭配 TUN 模式與路由規則

TUN 模式透過虛擬網卡接管未主動使用系統代理之程序的流量，因此是 FakeDNS 最常見的搭配入口。在 v2rayN 中，可先進入「設定」→「參數設定」確認本機監聽連接埠，再啟用 TUN 模式；不同版本的 TUN 選項位置可能有所調整，最後應以狀態列顯示與核心啟動記錄為準。

Android 端的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。啟用裝置層級的流量接管後，應檢查用戶端設定中的本地 DNS、網域策略與路由模式是否來自同一套設定方案。不要同時讓其他本地網路工具佔用 VPN 介面，否則 DNS 查詢可能繞過目前的核心。

1. 先驗證 TUN 接管。關閉應用程式本身的 HTTP 或 SOCKS 代理設定，啟動用戶端後存取測試網域，確認連線仍出現在核心記錄中。
2. 再觀察假位址。對未快取的網域執行查詢，檢查是否回傳設定池中的 198.18.x.x 位址。
3. 確認網域還原。在路由記錄中尋找原始網域名稱，而不只是查看假 IP；若只記錄假 IP，應檢查目標還原設定。
4. 驗證規則命中。分別測試一個代理網域與一個直連網域，確認兩者都連至預期的出站標籤。
5. 最後測試回退。關閉 FakeDNS 後恢復一般 DNS，確保設定失敗時仍有明確可用的回退路徑。

規則順序尤其重要。假位址只是暫時目標，如果寬泛的 IP 規則先匹配 198.18.0.0/15 並直接放行，連線可能在網域還原前被送往錯誤出口。較穩妥的做法是讓 TUN 入站完成 FakeDNS 還原，再依網域規則分流，同時明確排除區域網路與內部服務。

適合與不適合啟用的情境

適合啟用的典型環境包括：TUN 已穩定接管、遠端 DNS 往返時間較長、網域分流規則較多，且應用程式流量經常只以 IP 形式進入核心。此時 FakeDNS 不僅能縮短冷查詢等待，也能讓路由器重新取得原始網域，效益不只是單純減少幾十毫秒。

如果只使用瀏覽器明確連線至本機 HTTP 或 SOCKS 連接埠，瀏覽器通常會直接將網域名稱交給代理。核心已取得網域名稱時，FakeDNS 對分流準確度的提升很小。這類設定應優先確保 10808、10809 等監聽連接埠沒有衝突，並檢查系統代理是否指向正確連接埠。

• 建議啟用：TUN 接管全域流量，且核心記錄中經常只能看到目標 IP。
• 建議啟用：遠端 DNS 冷查詢長期超過 50 毫秒，首次開啟應用程式時有明顯等待。
• 謹慎啟用：單位內部網域必須由區域網路 DNS 解析，且存在分區網域解析結果。
• 謹慎啟用：實際網路已使用 198.18.0.0/15 或自訂假位址池。
• 效益有限：應用程式已透過明確代理提交網域名稱，本地 DNS 並非目前的瓶頸。

依據記錄完成驗證與故障定位

驗證 FakeDNS 不應只看網頁能否開啟。完整檢查需涵蓋 DNS 回應、TUN 擷取、網域還原、規則命中與代理出站五個階段。任何一個階段缺失，都可能造成「偶爾可用」或「部分應用程式失效」。

建議選取兩個先前未存取過的網域：一個應走代理，另一個應直連。清除用戶端內部 DNS 快取後分別發起查詢，記錄回傳位址與時間；接著立即建立連線，在記錄中確認原始網域、入站標籤與出站標籤。測試期間不要頻繁切換節點，以免將節點差異誤判為 DNS 差異。

1. 記錄用戶端目前的設定，確認本機 SOCKS 連接埠為 10808、HTTP 連接埠為 10809，或記下實際的自訂值。
2. 啟動 TUN 後檢查核心記錄，確認虛擬網卡建立成功，且沒有新增路由失敗或介面遭佔用的提示。
3. 查詢測試網域，確認回應位址位於設定的 FakeDNS 池內，回應時間通常應低於遠端 DNS 往返時間。
4. 發起連線並在記錄中搜尋原始網域名稱，確認最終目標不是始終以 198.18.x.x 呈現。
5. 確認代理網域命中 proxy，直連網域命中 direct，避免被更前面的寬泛規則覆蓋。
6. 連續測試 20 次，分別記錄中位數與失敗次數，不要以單次最快結果下結論。

若測試失敗，可依反向順序回退：先暫時停用網域分流規則，確認基礎代理出站可達；再關閉 FakeDNS，改用一般 DNS 檢查解析；最後停用 TUN，使用明確的系統代理驗證本機監聽連接埠。每次只變更一個變數，才能判定故障屬於位址池、DNS、TUN、路由或節點鏈路。

FakeDNS 的核心價值不是製造看似特殊的解析結果，而是在接管全域流量時，仍能穩定保留網域層級資訊。設定正確時，假位址只會短暫存在於本機，路由判斷使用還原後的網域名稱，代理出站則依照 VMess、VLESS 與訂閱節點的實際設定建立連線。是否啟用，應由 DNS 延遲、TUN 接管方式、內部網路結構與分流需求共同決定。