當應用程式先解析網域，接著只以 IP 建立連線時，FakeDNS 能暫存網域與虛擬 IP 的對應關係，讓進入代理核心的連線重新取得網域資訊。本文將依序說明查詢、映射、嗅探與路由，並介紹如何在 v2rayN 檢查 TUN、DNS 和嗅探設定；即使只使用一般系統代理，也能據此判斷是否需要啟用。
FakeDNS 解決的是哪個環節的網域資訊遺失
依網域分流的前提，是進行路由判斷時仍能取得目標網域。瀏覽器透過 HTTP 代理發出請求時，代理通常能直接取得網域；但在 TUN 模式下，應用程式可能先透過系統 DNS 將網域解析為實際 IP，再連線至該 IP。TUN 擷取到的是目標 IP，原始網域不一定會隨連線傳到核心。此時，即使路由規則設有網域條件，也可能只能繼續依 IP 規則判斷。
FakeDNS 並非替遠端網站找出實際位址，而是將一次 DNS 查詢轉為臨時編號：核心回傳虛擬 IP 給應用程式，並記錄「這個虛擬 IP 對應哪個網域」。應用程式照常連線至該位址；核心收到連線後，再透過映射找回網域。後續如何處理則由路由與出站設定決定，不應將 FakeDNS 誤認為代理協定或新的伺服器節點。
關鍵在於兩段流量都必須進入同一套處理流程：DNS 查詢要經過 FakeDNS，使用回傳位址發起的連線也要進入能讀取映射的核心。如果查詢使用系統外部的 DNS，或連線未經 TUN，單獨啟用 FakeDNS 並不能補回網域資訊。若應用程式一開始就連線至固定 IP，FakeDNS 也沒有網域可供記錄。
虛擬 IP 如何分配與還原網域
常見的 IPv4 虛擬位址池為 198.18.0.0/15。這個網段供網路設備效能測試使用，並非瀏覽網站時應直接連線的公網目的位址。FakeDNS 會從設定的位址池中取出位址，回傳給提出查詢的應用程式，並在核心內部保存對應關係。位址池範圍、可分配數量和快取狀態，會依設定與核心實作而異；不要將某個虛擬 IP 視為永久不變的網域識別碼。
此處所說的「嗅探」，不只指從 TLS 交握或 HTTP 請求中讀取網域。支援 FakeDNS 的核心也能依據先前建立的虛擬 IP 映射，還原連線目標的網域；HTTP Host、TLS SNI 等一般嗅探方式，則是其他可能的網域來源。應用程式使用的協定、是否加密及是否帶有網域資訊，都會影響一般嗅探；但「先收到 FakeDNS 回覆，再命中映射」仍是基本條件。
判斷重點：確認連線是否命中映射
記錄中只看到 DNS 回傳虛擬 IP，還不足以證明分流成功。請繼續確認後續連線是否由同一個核心接收，以及路由記錄中的目標能否還原為網域；若目標仍是虛擬 IP，先檢查 TUN 擷取範圍與嗅探設定。
核心重新啟動、映射遭清除，或應用程式長時間快取舊 DNS 回覆後，可能會繼續連線至已找不到對應網域的虛擬 IP。若遇到「剛切換設定時無法開啟，過一會兒又恢復」的情況，先讓應用程式重新查詢 DNS；必要時關閉再重新開啟應用程式，不要立刻修改伺服器位址。
在 v2rayN 的 TUN 情境中，該檢查哪些設定
先在 v2rayN 的「設定」→「參數設定」確認目前使用的核心與 TUN 相關選項，再檢查 DNS 和流量嗅探設定。不同版本的分類名稱和開關位置可能有所變動，請以目前介面顯示的欄位為準。FakeDNS、DNS 接管、TUN 擷取和嗅探需要互相配合；只勾選其中一項，不能據此認定整個流程已生效。
DNS 查詢路徑
- 檢查位置
- 「設定」→「參數設定」
- 確認項目
- 目前使用的核心、TUN 與 DNS 選項
- 預期狀況
- 應用程式查詢由設定中的 DNS 處理
- 異常線索
- 仍收到實際公網 IP
先確認查詢已進入核心，再檢查回傳位址是否屬於設定的虛擬位址池。
連線與路由路徑
- 檢查位置
- v2rayN 核心記錄與路由設定
- 確認項目
- 啟用嗅探、網域規則與出站設定
- 預期狀況
- 連線依還原後的網域比對規則
- 異常線索
- 記錄中只剩下虛擬 IP
路由結果也取決於規則順序；FakeDNS 負責找回網域，不負責決定使用哪個出站。
測試時，選一個已明確列入網域分流規則的網域，先記錄未啟用相關功能時的路由結果，再逐項檢查 DNS 回覆、連線擷取和規則命中狀況。不要只以「網頁能開啟」作為判斷標準：直連和代理出站都可能開啟同一個頁面。也不要用內網裝置名稱測試公網網域規則，兩者通常經由不同的解析路徑。
訂閱提供的是伺服器連線資訊，不代表本機 DNS 與 TUN 設定。更換 VMess 或 VLESS 節點後，仍須在本機確認 FakeDNS 的查詢路徑；節點可用也不能證明網域已依預期分流。需要找出問題時，請維持同一個節點，每次只調整一項本機設定，才容易比對記錄。
哪些流量適合啟用，哪些應保留實際解析
FakeDNS 特別適合「應用程式先解析，TUN 再接管連線」的情境：應用程式最後只連線至 IP，但路由規則仍需要原始網域。它也能降低應用程式先取得實際解析結果，導致網域資訊在進入核心前遺失的機率。不過，FakeDNS 不是所有 DNS 問題的通用解法；上游解析、路由規則和應用程式本身的 DNS 行為仍須分別檢查。
| 流量類型 | 優先檢查 | 使用建議 |
|---|---|---|
| TUN 中的公網網域連線 | DNS 查詢與連線是否都進入核心 | 需要網域分流時，可測試 FakeDNS 映射 |
| 區域網路裝置與內部網域 | 本機 DNS、區域網路直連規則 | 建議保留實際位址，避免影響內網連線 |
| 直接連線至數字 IP | IP 路由規則 | 沒有原始網域可供 FakeDNS 還原 |
| 應用程式自行使用加密 DNS | 確認應用程式的解析是否繞過本機 DNS 路徑 | 先確認查詢入口，不要只看系統 DNS 設定 |
區域網路印表機、路由器管理頁面和企業內部服務尤其需要留意。這些服務可能仰賴本機 DNS 回傳實際內網位址；若查詢被改為虛擬位址，而後續連線又未依預期進入核心，便會無法存取。建議先為這些網域或目標網段設定明確的本機解析與直連路徑，再測試公網網域的 FakeDNS，不要將所有查詢一律交給虛擬位址池。
結論：依連線入口決定是否啟用
若主要使用一般系統代理，且網域規則已正確命中，就不必為了「多一項 DNS 功能」而改變現有解析路徑。只有確認 TUN 情境確實發生網域資訊遺失後，才針對相關流量測試 FakeDNS，並為本機資源保留獨立的處理方式。
另一種情況是應用程式自行傳送加密 DNS 查詢，或將請求交由其他網路元件處理。此時 v2rayN 不一定看得到一般 DNS 查詢；即使後續連線經 TUN 擷取，也未必有虛擬位址映射可查。排查時應先確認「應用程式實際將查詢送往何處」，而不是先認定 FakeDNS 分配失敗。
啟用後無法連線：依現象逐項排查
先將問題分成三類：沒有取得虛擬 IP、取得虛擬 IP 卻無法連線，以及連線成功但未命中預期的網域規則。這三種情況分別涉及 DNS 入口、連線擷取與映射、路由比對。保留同一次測試的查詢結果和同一時段的核心記錄，有助避免混合不同請求的現象來判斷。
啟用 FakeDNS 後，查到的仍是網站實際 IP？
先到「設定」→「參數設定」確認目前使用的核心及 TUN、DNS 選項，再確認發出查詢的應用程式是否使用這條 DNS 路徑。若查詢沒有進入 FakeDNS，調整嗅探規則不會改變 DNS 回覆。
查到 198.18 網段的位址，網頁卻一直轉圈？
檢查後續 TCP 或 UDP 連線是否由 TUN 擷取，並在核心記錄中搜尋相應請求。若連線繞過核心，虛擬 IP 無法像網站的實際位址一樣直接存取；若核心剛重新啟動，請讓應用程式重新查詢一次。
公網網站正常，區域網路裝置卻無法連線？
檢查本機 DNS 與區域網路直連設定，讓內部網域和內網位址使用實際解析結果。修改後重新查詢裝置網域，確認回傳的是實際內網位址，而非虛擬位址池中的位址。
網域已還原，為什麼出站仍不正確？
前往路由設定檢查規則內容與優先順序，確認該網域是否先命中其他規則。FakeDNS 只會補回判斷所需的網域；最後使用哪個出站，仍由路由設定決定。
若問題只出現在特定應用程式，可將瀏覽器與該應用程式互相比對：兩者是否使用相同的 DNS 入口、是否都經過 TUN，以及連線的網域是否相同。不要因為瀏覽器運作正常，就認定所有應用程式都會發出相同的查詢。若問題只在切換設定後短暫發生，優先考慮應用程式快取了舊虛擬 IP；重新查詢後再觀察。
最後再檢查節點與協定層。v2rayN 中的 VMess、VLESS 伺服器是否連得上，與 FakeDNS 映射是否成立是兩回事：只有在記錄已顯示網域規則命中、出站也已選定，但請求仍逾時時，才繼續排查節點連線。依 DNS、嗅探、路由、出站的順序逐層縮小範圍，比同時修改訂閱、路由和 DNS 更容易找出真正的問題。