FakeDNS 回傳的是供本機代理辨識網域的位址，不是目標伺服器的實際位址。本文適合正在設定 v2rayN TUN 模式，或遇到虛擬 IP、DNS 異常的讀者：先釐清查詢、對應與出口三個環節，再判斷是否適合啟用，最後依序檢查快取、分流與位址衝突。
FakeDNS 是什麼：用位址保留網域線索
一般 DNS 查詢會將網域解析為目標服務的實際 IP，應用程式接著連線至該位址。FakeDNS 則從預設的位址池分配一個虛擬 IP，在本機保存「網域與虛擬 IP」的對應關係，再將虛擬 IP 回傳給應用程式。這個位址就像取件憑證，只有掌握對應表的處理元件才能還原它代表的網域。
例如，應用程式查詢 example.com，FakeDNS 可以回傳池中的 198.18.0.10。應用程式連線至該位址的 443 連接埠後，接管元件查表還原 example.com，再交由路由與出口處理。此位址僅供流程示範，不代表該網域固定對應此位址，也不是可直接連線的公網服務。
關鍵不在於「產生了一個假位址」，而在於回傳位址的元件與接收後續連線的元件能共用或銜接對應狀態。如果 DNS 只回傳虛擬位址，卻將連線交給一般閘道，通常就會連線失敗。FakeDNS 也不負責流量加密；VMess、VLESS 等代理協定屬於不同環節。
虛擬 IP 池：位址數量不等於快取項目數
在 V2Ray/Xray 的 FakeDNS 設定中，常見的 IPv4 位址池為 198.18.0.0/15。此範圍用於網路設備基準測試，並非一般公網目標位址。下方三個數字分別代表位址範圍、對應容量範例與常見 DNS 服務連接埠，不是效能測試結果。
ipPool 決定可分配的位址範圍，poolSize 決定對應池容量，兩者並不相同。網域數量多、執行時間長或對應項目遭到淘汰，都可能使舊位址與目前的對應失去關聯；實際回收方式取決於實作。應用程式也可能保留舊的 DNS 結果，因此重新啟動核心後，先前快取的虛擬位址不一定還能正確辨識。
判斷方式：先檢查位址衝突，再考慮擴大對應池
如果企業 VPN 或測試網路已使用 198.18.0.0/15，請先檢查實際路由與位址池是否衝突。增加 poolSize 無法修復重疊路由，也無法還原重新啟動前遺失的對應。
為什麼 TUN 模式常搭配 FakeDNS
TUN 在網路層接收 IP 封包，通常只能看到目標位址，而非應用程式最初輸入的網域。多個網域可能共用同一個實際 IP，因此難以只靠 IP 穩定還原原始網域。FakeDNS 將網域保留在對應表中，讓後續連線更容易依網域分流。
不過，TUN 與 FakeDNS 並非綁定啟用。TUN 可以搭配實際 DNS 解析運作；FakeDNS 也能用於其他具備透明接管能力的連線路徑。TLS 或 HTTP 嗅探有時能提供網域線索，但無法涵蓋所有協定與加密情境，不能直接視為對應表的替代方案。
- 較適合：需要接管不讀取系統代理設定的應用程式，同時希望保留依網域比對規則的能力。
- 先確認：應用程式的 DNS 查詢確實進入已設定的 DNS 處理鏈，回傳虛擬位址後的連線也進入同一套接管路徑。
- 不必強行啟用：瀏覽器已透過明確代理傳遞網域，且系統代理已能滿足需求時，先維持現有設定即可。
- 無法補救：應用程式直接連線至寫死的實際 IP，沒有查詢網域的流程，FakeDNS 無法憑空還原網域。
設定怎麼看：DNS 分配與連線還原必須搭配
下方兩張卡片用於辨識 Xray 風格設定中的相關欄位，不是可直接執行的完整設定，也不應直接貼到用戶端的任意輸入欄位。用戶端自動產生的設定可能會覆蓋手動修改；若 TUN 使用另一套 DNS 實作，其欄位名稱與行為也可能不同。
DNS 分配端
- 頂層設定
fakedns陣列- 位址池
ipPool: 198.18.0.0/15- 對應容量
poolSize: 65535- DNS 服務項目
- 在
dns.servers中使用fakedns
分配端必須實際處理應用程式的查詢；只定義位址池但未接入 DNS 請求鏈，不會自動接管系統解析。
入站還原端
- 入站嗅探
sniffing.enabled: true- 還原類型
destOverride: ["fakedns"]- 目標處理
- 還原網域後交由路由與出口處理
- 驗證依據
- 入站目標、網域與出口記錄
還原端必須能存取相應的對應資料；不要將尚未還原的虛擬位址交給一般直連出口。
在 v2rayN 中，可以先從「設定」→「參數設定」確認目前的基本設定，再檢查目前版本提供的 DNS 與 TUN 設定入口；不同版本的選項位置與名稱可能不同。重點是確認由誰監聽 DNS、由誰產生虛擬位址、由誰接收連線，而不是照著名稱尋找同名核取方塊。
v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心，但桌面版設定與 Android 應用程式設定不能直接依欄位位置照抄。應以用戶端實際提供的選項、隨附的核心版本與執行記錄為準。訂閱通常只提供節點參數，不代表已替使用者設定好整台裝置的 DNS 接管。
少做一次解析，究竟省略了哪個步驟
FakeDNS 可以省去應用程式連線前、在本機等待取得目標實際 IP 的那次查詢。但這不代表整個連線過程從此不需要 DNS。若代理出口將網域傳給遠端，遠端仍可能進行解析；若符合直連規則，本機出口通常仍需要實際 IP 才能建立連線。
| 連線路徑 | 應用程式收到的結果 | 後續解析位置 | 注意事項 |
|---|---|---|---|
| 一般 DNS 後直連 | 實際 IP | 通常已在連線前完成 | 應用程式直接使用解析結果 |
| FakeDNS 後透過代理 | 虛擬 IP | 可能交由代理伺服器解析 | 取決於出口是否傳遞網域 |
| FakeDNS 後直連 | 虛擬 IP | 通常仍需要在本機進行實際解析 | 注意避免再次回傳虛擬位址而形成迴圈 |
| 應用程式內建加密 DNS | 由應用程式的解析流程決定 | 可能繞過本機 FakeDNS | 只接管 53 連接埠通常不夠 |
網域規則與 IP 規則也要分開看。還原網域後，網域規則可以直接比對；IP 地理分類仍可能需要實際位址，是否觸發解析則取決於路由策略。不能把 198.18.0.10 當成目標伺服器所在地的證據，也不能因為啟用 FakeDNS 就認定所有 DNS 查詢都經過代理。
判斷方式：用出口記錄確認分流，不要用虛擬 IP 判斷地區
選一個應直連的服務和一個應走代理的服務，分別建立新連線，確認實際使用的出口。若只看到位址池中的 IP，看不到預期網域或出口，請先修復還原流程，再調整網域規則。
相容性問題：從快取、繞行與特殊網路著手排查
最常見的故障不是「所有網站都變慢」，而是啟用後少數應用程式無法使用、重新啟動核心後舊連線異常，或企業內網突然無法連線。排查時一次只變更一個條件，保留可復原的基準設定，避免同時修改節點、DNS 與路由，導致無法判斷原因。
為什麼查詢結果變成 198.18 開頭，網頁卻仍然能開啟？
如果目前設定確實使用這個位址池，這就是預期結果。只要確認記錄能還原網域並選到正確出口即可；不要把該位址填入節點伺服器欄位，也不要傳給其他裝置當成實際目標使用。
重新啟動用戶端後，部分應用程式突然無法連線？
先完全關閉受影響的應用程式再重新開啟，讓它重新查詢 DNS。若仍沿用舊位址，再清除系統解析快取。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。這些命令不會清除每個應用程式自己的快取。
瀏覽器正常，遊戲或區域網路探索卻失敗？
先關閉 FakeDNS，保留其他設定後重新測試。部分應用程式依賴實際 IP 判斷網路範圍，區域網路探索也可能依賴廣播或多點傳播。請為本地域名與內部網路設定實際解析及直連例外，並確認這些例外沒有再次被 TUN 錯誤接管。
啟用後仍看到應用程式直接查詢外部 DNS？
檢查瀏覽器的「安全 DNS」或應用程式內的加密 DNS 設定，並確認 IPv6 查詢路徑。診斷時可暫時改用系統解析再測試；不要只因為 53 連接埠已被接管，就認定加密 DNS 也會進入 FakeDNS。
另一個常見誤區是用 ping 測試虛擬 IP，再依封包遺失率判斷節點品質。這個位址代表的是對應，不是真實伺服器；ICMP 的處理方式也可能與 TCP、UDP 不同。請測試目標應用程式的實際連線，並分別記錄 DNS 查詢時間、連線時間與下載速率。
啟用與復原：以相同請求進行對照
是否使用 FakeDNS，最終要看它能否讓目前的接管流程更完整，而不是設定項目愈多愈好。建議先記錄用戶端版本、目前節點、TUN 狀態、DNS 處理元件與位址池，再依照下列步驟進行可重複的對照測試。
- 建立基準：關閉 FakeDNS，維持相同節點與網路，分別連線至一個代理目標、一個直連目標與一項區域網路服務，記錄成功或失敗。
- 只啟用對應流程：確認 DNS 分配與入站還原一併啟用，不要同時更換節點或重寫整套路由。
- 重新建立連線：退出測試中的應用程式後重新開啟，必要時清除系統 DNS 快取，避免混用舊的實際位址與新的虛擬位址進行測試。
- 核對三類證據：確認查詢是否回傳池內位址、連線是否還原為原始網域，以及最終出口是否符合分流預期。若啟用 IPv6，也要另外檢查 AAAA 查詢與 IPv6 連線。
- 確認能否復原：關閉 FakeDNS、還原原本的 DNS 設定，並重新啟動受影響的應用程式。若復原後仍有異常，請繼續檢查 TUN 路由、系統代理或節點連線狀況，不要把所有問題都歸咎於 DNS。