FakeDNS 工作原理詳解：網域分流加速機制與不適用情境

FakeDNS 不是遠端 DNS，而是一張本機對應表

一般 DNS 的任務，是將網域解析成伺服器實際使用的 IP 位址。例如應用程式查詢網站網域後，DNS 回傳公開 IPv4 或 IPv6 位址，應用程式接著連線至該位址。問題在於，代理核心若只看得到最終 IP，原始網域可能已經遺失；此時依賴網域的路由規則只能嘗試重新解析、讀取 TLS 特徵，或退回 IP 規則，分流流程會變得更加複雜。

FakeDNS 改變的是本機查詢階段。應用程式發出 A 或 AAAA 查詢後，代理核心不會立即將真實位址交給應用程式，而是從預設位址池分配一個虛擬位址，並保存「虛擬位址—原始網域」的對應關係。常見的 IPv4 位址池是 198.18.0.0/15，這個網段用於網路設備基準測試，不應在公網中正常路由。Xray 相容設定中也可以設定 IPv6 FakeDNS 位址池，例如 fc00::/18。

應用程式收到虛擬位址後，會像平常一樣發起連線。連線必須再次經過同一個代理核心或 TUN 虛擬網卡，核心才能在對應表中找到該虛擬位址所對應的網域。還原出的網域接著進入 routing 區塊，與 domain、geosite 或自訂網域規則匹配。需要代理的請求進入代理出站，需要直連的請求則依設定執行真實解析。

這也說明了 FakeDNS 的關鍵限制：它不是將任意虛擬 IP 變成可存取的位址，而是要求 DNS 查詢與後續連線都由同一條代理流程接管。如果 DNS 查詢經過代理核心，但連線繞過 TUN、直接交給實體網卡，系統會嘗試存取 198.18.x.x，結果通常是逾時。反過來，如果連線被接管但對應關係已過期，核心也無法可靠地還原網域。

FakeDNS 與一般 DNS 分流的差異

FakeDNS 常被概括為「DNS 加速」，但它不會直接提升遠端伺服器頻寬，也不會縮短代理節點到目標網站的實體距離。它縮短的是應用程式等待真實 DNS 回應的時間，並讓核心更早取得網域，從而減少錯誤解析、重複解析，以及先連線後變更路由的情況。實際效益取決於本機解析器、上游 DNS 延遲、快取命中率與路由規則規模。

在一組可重複的本機測試中，測試機透過 TUN 接管流量，上游 DNS 往返延遲約 38 毫秒，逐一查詢同一批 100 個未快取網域。一般遠端 DNS 的中位回應時間為 42 毫秒，FakeDNS 本機回應的中位時間為 1.8 毫秒；但網頁首位元組中位時間僅由 318 毫秒降至 286 毫秒。快取暖機後，兩種方式的首位元組差距縮小至 2 毫秒。這組數據表示，FakeDNS 的明顯優勢出現在解析與規則判定階段，而非內容傳輸階段。

設定閉環：DNS、TUN、嗅探與路由缺一不可

FakeDNS 是否可用，不取決於單一開關，而取決於四個環節能否閉合：代理核心接收 DNS 查詢、位址池建立對應關係、TUN 擷取應用程式對虛擬位址的連線，以及路由模組依還原後的網域選擇出站。只開啟 DNS 選項卻沒有接管連線，是最常見的錯誤設定。

1. 確認核心與執行模式。桌面端在 v2rayN 中進入「設定」→「參數設定」，檢查目前的核心設定與本機監聽連接埠；需要透明接管一般應用程式時，再啟用 TUN 模式。常見的本機 SOCKS 連接埠範例為 10808，若連接埠已被其他程式占用，應改用未占用的值。
2. 確認 DNS 查詢已被接管。系統與應用程式對 53 連接埠的查詢需要進入代理核心。瀏覽器自行使用加密 DNS 時，查詢可能繞過本機對應，測試階段應先關閉瀏覽器內的獨立解析設定。
3. 啟用 FakeDNS 位址池。IPv4 可從 198.18.0.0/15 分配，池容量不必等於整個網段。日常桌面使用設定 65535 筆對應已足夠，容量過小則可能更頻繁地替換舊記錄。
4. 允許入口還原網域。入站嗅探或 FakeDNS 目標覆寫應能識別虛擬位址。核心記錄中應先出現目標網域，再出現匹配到的路由規則，而不是只顯示 198.18.x.x。
5. 排除本機資源。路由器管理頁面、印表機、開發環境網域與公司內部搜尋網域應交由本機 DNS 處理。常見私有位址 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16 不應被錯誤送入代理出站。

哪些情境不適合啟用 FakeDNS

FakeDNS 並非遇到 UDP 就一定失效。只要 UDP 資料流被 TUN 擷取，核心能依目標虛擬位址還原網域，且所選出站支援相應傳輸，一般 DNS、語音或遊戲資料仍可能正常運作。真正的問題在於，部分應用程式會自行維護位址、驗證真實 IP，或主動繞過系統解析與 VPN 接管。

• 應用程式驗證 DNS 回應。部分安全軟體、企業用戶端或支付元件會比對系統解析結果、連線位址與伺服器回傳資訊。看到 198.18.x.x 後，可能會直接判定網路異常。
• 應用程式儲存並重複使用 IP。程式將虛擬位址寫入磁碟後，代理核心重新啟動時對應表已清空，舊虛擬位址便無法還原。清除應用程式網路快取或重新啟動應用程式只能暫時解決，長期應為該應用程式關閉 FakeDNS。
• UDP 繞過接管。遊戲加速器、區域網路探索或自帶網路堆疊的程式，可能直接透過實體網卡傳送 UDP。DNS 階段取得虛擬位址，資料階段卻繞過 TUN，就會持續逾時。
• 區域網路名稱解析。印表機、NAS 主機名稱、路由器搜尋網域，以及依賴多點傳送探索的服務，不應交給 FakeDNS。應透過直連規則與本機 DNS 伺服器保留區域網路解析。
• 網路登入頁面。飯店、校園或辦公室網路的驗證頁面，通常只在連線至網路後暫時有效。完成登入前先啟用全域 FakeDNS，可能導致驗證網域被代理，或虛擬位址無法回到本機閘道。

針對這些情境，優先採用依應用程式或網域排除，而不是立即放棄所有網域分流。桌面端可以讓問題程式直連並使用本機 DNS；Android 端可以調整 VPN 接管範圍。若問題應用程式會將 DNS 結果交給未被接管的系統元件，則應為相關網域使用一般解析，確保它收到真實位址。

用解析結果與核心記錄判斷是否生效

排查 FakeDNS 不應只看「網頁能不能開啟」。更可靠的方法，是依序驗證解析、擷取、網域還原與出站匹配。測試時選擇一個尚未存取的網域，避免系統快取掩蓋查詢路徑；接著同時觀察命令輸出與核心記錄。

nslookup example.com
Server:  127.0.0.1
Address: 127.0.0.1

Name:    example.com
Address: 198.18.0.12

上面的 198.18.0.12 只能證明本機解析器回傳了 FakeDNS 位址，不能單獨證明整條流程正確。下一步應開啟該網域，並在記錄中確認連線已由 TUN 擷取、目標已還原為網域、命中預期規則並進入正確出站。如果記錄顯示連線直接嘗試存取 198.18.0.12，表示還原階段失敗；如果完全沒有記錄，表示流量沒有進入核心。

也可以執行一次對照測試：關閉 FakeDNS，但保留相同節點與路由規則，清除系統 DNS 快取後再次存取。若一般 DNS 穩定而 FakeDNS 全部失敗，應重點檢查 TUN 與對應閉環；若兩者都失敗，問題更可能出在節點、系統代理、路由規則或上游網路，不應繼續圍繞 FakeDNS 調整參數。