在 Clash Meta（mihomo）設定中，DNS 模式會直接影響網域解析、規則比對與連線建立。Fake-IP 是其中相當常見的運作方式：用戶端不會立即將目標網域解析成真實公網位址，而是從專用位址池分配一個虛擬 IP，並在內部保存網域與虛擬 IP 的對應關係。應用程式看到的是這個虛擬位址，代理核心則能在後續連線階段還原原始網域，再依規則決定直連、代理或拒絕。

這套流程經常與 TUN 模式搭配使用，但兩者並不是同一個概念。Fake-IP 處理的是 DNS 回應與網域保留問題，TUN 處理的則是如何接收系統及應用程式產生的網路流量。理解兩者的界線，才能判斷故障究竟發生在 DNS、規則、路由，還是應用程式本身。本文將依解析流程、設定選擇、使用情境與故障排除順序說明。

Fake-IP 究竟改變了什麼

傳統的 redir-host 作法通常是：應用程式向系統解析器查詢網域，解析器回傳真實 IP，應用程式再使用這個 IP 建立連線。如果代理核心只能看到目標 IP，就需要依靠網域嗅探、補充規則或已知位址範圍來推測存取對象。對於 HTTPS 流量，核心可能從 TLS 的 SNI 取得網域；但對部分加密或非標準協定，這種推測不一定成立。

Fake-IP 模式將順序調整為「先保留網域，再建立連線」。當應用程式查詢 example.com 時，DNS 模組會回傳位址池中的虛擬位址，例如 198.18.0.23。這個位址不是目標伺服器的真實位址，而是核心用來標記該網域的索引。應用程式接著連線至 198.18.0.23，流量由代理接管後，核心透過映射表還原出 example.com，再執行網域規則。

常見的 Fake-IP 位址池會使用專門保留的測試網段，例如 198.18.0.1/16。這類位址不應視為公網目標使用。位址池大小、排除清單與映射生命週期由核心及設定共同決定。虛擬 IP 與網域的對應關係通常會維護在快取中，因此同一網域在一段時間內可能持續取得相同位址，也可能在清除快取、重新載入設定或位址池變更後重新分配。

一次請求的處理流程

  1. 應用程式發起 DNS 查詢，查詢內容是網域，而不是最終 IP。
  2. Clash 接收查詢，依據 nameserver、fallback、fake-ip-filter 等設定處理請求。
  3. Fake-IP 模組為網域建立映射，並向應用程式回傳位址池中的虛擬 IP。
  4. 應用程式連線至虛擬 IP；系統代理、透明代理或 TUN 會將這條連線交給 Clash。
  5. Clash 依據映射還原網域，依序執行網域規則、程序規則、IP 規則與兜底規則。
  6. 選定策略群組後，核心透過直連或代理線路連線至真實目標。

這裡的關鍵在於「規則看到的目標」。在映射有效且流量經過 Clash 的情況下，網域規則通常能在連線初期發揮作用。若應用程式繞過系統 DNS、直接使用硬編碼 IP，或流量沒有進入 Clash，Fake-IP 無法憑空還原網域，也不能取代路由接管。

Fake-IP、真實解析與 TUN 模式的關係

Fake-IP 與 redir-host 是 DNS 回傳策略的兩種取向。Fake-IP 更著重保留網域脈絡，適合需要穩定進行網域規則比對的情境；redir-host 更接近一般 DNS 的直覺，應用程式取得真實 IP，部分依賴真實位址的程式相容性會更好。兩種模式都需要正確的 DNS 劫持、系統代理或流量接管，不能簡單認為某一種模式一定更快。

TUN 模式則位於另一個層次。啟用 TUN 後，系統會建立虛擬網路介面，符合路由條件的流量會送入 Clash。如此一來，可以接管不遵循 HTTP 或 SOCKS 系統代理的程式，也能涵蓋部分背景服務與 UDP 流量。啟用 TUN 不代表 DNS 自動正確：如果系統仍將查詢送往外部 DNS，或應用程式啟用了自己的加密 DNS，Fake-IP 映射可能無法參與完整的請求流程。

元件 主要職責 常見誤解
Fake-IP 為網域分配虛擬位址並保留映射 不是遠端 DNS 伺服器，也不是代理節點
DNS 模組 接收查詢、選擇解析器並回傳結果 只修改 nameserver 就能解決所有 DNS 洩漏問題
TUN 接管系統路由中的網路流量 啟用 TUN 後所有應用程式必然都會經過代理
規則系統 依據網域、IP、連接埠等條件選擇策略 規則無法處理完全沒有進入核心的連線

在桌面端，系統代理通常足以涵蓋瀏覽器及遵循系統設定的應用程式；需要涵蓋更多程式時，可以考慮使用 TUN。Android 上，VpnService 是常見的流量接管基礎，系統 VPN 權限、省電策略及其他 VPN 應用程式的狀態都會影響結果。iOS 的網路延伸權限與用戶端能力也有自身限制，不應直接套用桌面端的 TUN 設定。

設定 Fake-IP 前應先確認的項目

設定檔的欄位名稱與可用選項應以目前 mihomo 版本的文件及用戶端介面為準。不同用戶端可能為 DNS、TUN 與覆寫設定提供不同的編輯入口。以下提供檢查方向，而不是要求所有平台複製完全相同的設定。

1. 確認由誰接收 DNS 請求

首先確認用戶端是否啟用了核心 DNS，以及系統 DNS 查詢是否會轉送至 Clash。桌面用戶端可能透過本機監聽位址接收查詢，TUN 用戶端則可能透過 DNS 劫持處理 UDP 或 TCP 查詢。若瀏覽器啟用了「安全 DNS」並直接連線至指定服務商，系統 DNS 設定可能不會生效。測試時應暫時關閉應用程式內建的加密 DNS，或將其納入明確的網路策略。

2. 規劃 Fake-IP 位址池

位址池應使用適合虛擬映射的保留網段，並避開實際區域網路、公司內網、容器網路與常用 VPN 網段。例如區域網路使用 192.168.1.0/24 時，不要將 Fake-IP 位址池設為相同網段。位址衝突會導致系統誤將虛擬位址視為區域網路主機，表現為連線逾時、路由異常或某些內網服務無法存取。

Fake-IP 位址池不宜隨意設定為常見的家庭網段。設定前可檢查目前裝置的路由表、Docker 橋接介面、虛擬機網卡與公司 VPN 使用的網段。如果位址池與實際網路重疊，應優先更換位址池，再清除快取並重新測試，而不是反覆切換代理節點。

3. 設定 fake-ip-filter

並非所有網域都適合回傳 Fake-IP。區域網路主機名稱、路由器管理位址、需要依真實 IP 判斷的服務，以及某些依賴本機解析的網域，通常應加入排除清單。套用篩選後，這些網域會使用真實解析，或依用戶端實作回傳原始結果。篩選範圍不宜一開始就設定過大，否則大量網域會回到真實解析，規則比對與 DNS 行為將難以判斷。

篩選清單應根據實際故障逐步增加，並記錄每次修改的目的。例如印表機探索失敗，可以先檢查區域網路網域及多點傳送名稱解析；某個企業內網網域無法開啟，則可確認企業 DNS 是否必須在特定網路中使用。不要只因某次請求失敗，就排除整個頂級網域或所有中國大陸網域。

4. 檢查 nameserver 與 fallback 的分工

nameserver 是常規解析器，fallback 是備用解析器，或用於特定判斷的解析來源，實際行為取決於核心版本與設定。設定解析器時，應注意可達性、回應速度、是否支援所需的記錄類型，以及請求是否應透過代理傳送。解析器本身無法連線時，Fake-IP 仍可能回傳快取結果，但新網域會出現解析等待或連線失敗。

如果設定了 nameserver-policy，應確認規則寫法與網域範圍正確。這項策略的目標是讓不同網域使用合適的解析器，而不是取代代理規則。DNS 解析成功也不代表目標連線一定成功，最終還要檢查規則命中的策略群組、節點可用性與遠端服務回應。

哪些情境適合使用 Fake-IP

當設定依賴網域規則分流時，Fake-IP 通常更容易保留規則脈絡。例如需要依網域後綴區分直連與代理、需要讓一組服務使用獨立策略群組，或希望減少只依目標 IP 判斷所造成的錯誤分流。網域在連線初期仍可使用，規則維護也更貼近使用者實際看到的網站名稱。

在 TUN 模式下，Fake-IP 對不遵循系統代理的程式特別有幫助。程式只要透過系統網路堆疊發出 DNS 查詢並連線至回傳位址，核心就有機會依映射辨識目標。不過，程式若使用自訂 DNS、DoH、DoT，或將網域解析結果固定在自己的快取中，仍需另行處理。部分應用程式還會使用 QUIC、IPv6 或自有網路協定，測試時應將協定差異納入判斷。

對於區域網路裝置，使用 Fake-IP 應保持謹慎。印表機、NAS、智慧家居控制器、路由器後台與區域網路遊戲探索通常依賴真實區域網路位址、多點傳送或廣播，這些流量不一定適合經過代理。將相關網域加入 fake-ip-filter，並為區域網路網段設定直連規則，是較穩妥的起點。

常見異常與故障排除順序

瀏覽器顯示 DNS_PROBE_FINISHED_NXDOMAIN 或解析逾時

先確認問題是所有網域都發生，還是只有特定網域發生。檢查 Clash 記錄中是否出現 DNS 請求，確認用戶端 DNS 監聽是否啟動，再確認系統或瀏覽器是否繞過了該監聽。接著暫時切換至可存取的解析器，清除用戶端 DNS 快取並重新載入設定。如果只有一個網域失敗，請檢查 nameserver-policy、網域拼寫、篩選清單與該網域的記錄類型。

網頁可以開啟，但規則誤判為直連或代理

查看連線詳細資訊中的目標網域、目標 IP 與命中規則。若連線詳細資訊只顯示 Fake-IP 位址，表示映射沒有正確還原，可能是連線未由 Clash 接收，或應用程式使用了快取 IP。若顯示真實網域但規則不符合預期，請檢查規則順序：更具體的 DOMAIN、DOMAIN-SUFFIX 或 DOMAIN-KEYWORD 應放在較寬泛的規則之前，MATCH 兜底項應位於規則末尾。

修改規則後要儲存並執行設定重新載入。只編輯檔案但未重新載入時，執行中的核心仍可能使用舊規則。測試時應建立新的連線，舊連線與舊快取不一定會重新執行完整的解析與比對流程。

啟用 TUN 後區域網路裝置或公司內網失效

先關閉 TUN 進行對照測試。如果關閉後恢復，請檢查 TUN 的路由設定、自動路由、嚴格路由、DNS 劫持與繞過網段設定。確認家用路由器、公司內網及印表機所在網段沒有被錯誤送往代理策略。對區域網路流量，應確保規則與路由都允許直連；只寫一條 IP-CIDR 規則但沒有讓流量進入核心，仍無法解決問題。

多個 VPN、虛擬機、容器與安全軟體可能同時修改路由表。故障排除時，應暫時停用不必要的 VPN 或虛擬網卡，記錄啟用 TUN 前後的預設路由與 DNS 伺服器。Windows、Linux、Android 的權限模型不同，用戶端顯示「已啟用」不代表系統一定授予全部必要權限。

部分應用程式完全無法連線

檢查應用程式是否使用 IPv6、QUIC、硬編碼 IP、內建 DoH 或獨立代理。Fake-IP 主要圍繞網域解析建立映射，直接使用 IP 的連線可能只能依靠 IP 規則處理。若應用程式優先使用 IPv6，而目前 TUN、節點或規則未涵蓋 IPv6，可能出現瀏覽器正常、單一應用程式失敗的情況。測試階段可以分別驗證 IPv4、IPv6、TCP 與 UDP，再決定是否調整協定或路由範圍。

# 僅用於排查思路，實際欄位請依目前用戶端與 mihomo 版本確認
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

上方片段只展示欄位之間的關係，不代表所有系統都應照原樣使用。dns-hijack、TUN 路由與篩選項可能受到用戶端封裝及版本差異影響。尤其是區域網路網域、企業 DNS 與 IPv6 環境，應先了解現有網路，再逐項加入設定。

一套可重複執行的檢查清單

  1. 記錄目前的用戶端版本、核心版本、系統版本與網路環境，並保留原始設定。
  2. 關閉其他 VPN、代理軟體與瀏覽器獨立 DNS，建立單一變因的測試環境。
  3. 確認一般網域能取得解析結果，觀察 Clash 是否出現對應的 DNS 請求。
  4. 檢查回傳位址是否屬於 Fake-IP 位址池，並確認該位址池沒有與區域網路重疊。
  5. 查看連線詳細資訊，確認映射能還原網域，並核對實際命中的規則與策略群組。
  6. 分別測試一般網頁、區域網路裝置、需要登入的應用程式、UDP 服務與 IPv6 服務。
  7. 每次只修改一個項目，儲存、重新載入、清除快取後，再重複相同的一組測試。

如果切換至 redir-host 後某個應用程式恢復，表示該應用程式可能依賴真實 IP、區域網路解析或特殊協定；這不代表 Fake-IP 設定一定有誤。可以先將特定網域加入篩選清單，或為該應用程式的流量設定明確的直連策略。反過來，如果在 redir-host 下網域規則容易失效，而在 Fake-IP 下規則穩定，就應優先檢查 DNS 劫持與映射回收，而不是只更換節點。

結語：依請求流程定位問題

Fake-IP 的價值在於讓網域資訊貫穿 DNS、連線接管與規則比對。它不是獨立的加速開關，也不能取代可用的解析器、正確的路由與有效的代理策略。設定是否適合，取決於裝置類型、應用程式協定、區域網路結構，以及是否需要透過 TUN 接管流量。

遇到異常時，依照「應用程式查詢 DNS—Clash 回傳位址—流量進入核心—映射還原網域—規則選擇策略—節點建立連線」的順序檢查，通常比反覆切換 DNS 或節點更快找出原因。對區域網路、企業內網與特殊應用程式保留明確的例外處理，再透過記錄與連線詳細資訊驗證每次修改，能讓 Fake-IP 設定更容易維護。