Fake-IP 原理解析：DNS 增强模式与 Redir-Host 如何选择

一、Fake-IP 改變的是 DNS 回應，不是節點出口

在 Clash 或 Clash Meta（現名 mihomo）的設定中，dns.enhanced-mode 會決定內建 DNS 如何回應查詢。常見值為 fake-ip 和 redir-host。這項設定不會選擇訂閱、不會改變節點通訊協定，也不能取代規則模式或 TUN 模式。

Fake-IP 會為網域名稱指派一個合成位址，並儲存「網域名稱 ↔ 合成位址」的對應關係。應用程式連線到這個位址時，核心會先還原網域名稱，再比對規則並處理出站連線。這個位址不是網站伺服器的真實位址，也不是代理節點的 IP。

為什麼常見位址以 198.18 開頭？

常見設定會使用 198.18.0.1/16 作為 Fake-IP 位址池。這個範圍位於保留給網路設備效能測試的 198.18.0.0/15 位址空間內，不是可直接存取的公網網站位址。設定為 /16，表示位址池只取其中一部分，並不代表整個保留範圍只有這一段。

因此，DNS 查詢出現 198.18.x.x，本身不代表解析遭到竄改。關鍵在於後續連線能否回到持有對應資料的同一個核心。如果應用程式取得合成位址後，繞過 TUN 和其他透明接管路徑直接連線，通常就會連線失敗。

二、從網域查詢到建立連線：兩種模式有何不同

Fake-IP 的典型處理流程

應用程式查詢網域名稱，例如 example.com，查詢會送至核心 DNS。
核心會指派或重複使用一個合成 IPv4 位址，並將結果回傳給應用程式。
應用程式連線至該位址，流量透過 TUN 等接管方式送回核心。
核心根據對應資料找回網域名稱，依序比對規則，選擇直連或代理出口。
需要真實 IP 時才進行解析；若代理通訊協定與出站設定允許傳遞網域名稱，也可由遠端解析。

這個流程能減少應用程式開始連線前等待真實 DNS 結果的時間，也讓核心更容易取得原始網域名稱。但這不代表「整個連線過程都不需要查 DNS」。直連、IP 類規則、部分出站通訊協定或特定解析策略，仍可能觸發真實解析。

Redir-Host 的典型處理流程

Redir-Host 通常會先向上游解析器查詢真實位址，再將位址回傳給應用程式。核心可搭配 DNS 快取中的關聯資料，在連線進入時還原網域名稱。如果 DNS 查詢未經過核心、快取已遺失，或多個網域共用同一個位址，網域名稱可能無法完整還原。流量嗅探可補足部分通訊協定的資訊，但並非對所有連線都有效。

比較項目	Fake-IP	Redir-Host
應用程式收到的 IPv4 結果	通常是位址池中的合成位址	通常是上游回傳的真實位址
回應前是否需要等待真實解析	一般合成回應通常不必等待	快取未命中時通常需要等待
網域規則所需的資訊	主要來自合成位址對應資料	仰賴 DNS 關聯資料、明確代理資訊或流量嗅探等
常見的相容性注意事項	位址驗證、區域網路探索、繞過接管的連線	真實解析延遲、解析結果與出口的配合

對使用 HTTP CONNECT 或 SOCKS 網域名稱請求的明確代理連線，核心可能直接取得目標網域名稱，不一定會經過上述系統 DNS 流程。因此，只在瀏覽器設定代理後瀏覽網頁，無法單獨證明 Fake-IP 的 DNS 接管運作正常。

三、依使用情境選擇，別把 Fake-IP 當成網速開關

透過 TUN 接管日常應用程式：可以先測試 Fake-IP。前提是 DNS 查詢與後續連線都會進入核心，且位址池沒有和現有網路衝突。
企業內網、校園網路、NAS 與印表機：先確認能否存取內網 DNS，再為相關網域設定例外。只有少數網域不相容時，不必立刻全域切換模式。
應用程式要求 DNS 回傳真實位址：先新增精確的過濾項目；如果這類應用程式很多，或排除範圍難以維護，再比較 Redir-Host。
只使用瀏覽器的系統代理：先確認瀏覽器實際使用的代理通訊協定與 DNS 路徑。不要只因為看到某個模式名稱，就開啟 TUN 或重寫整份 DNS 設定。

Fake-IP 可能縮短首次連線前等待解析的時間，但不會增加訂閱頻寬、降低節點倍率，也無法修復壅塞的線路。下載速度慢時，應分別觀察 DNS 耗時、建立連線所需時間與持續傳輸速度，別把三種問題混為一談。

四、fake-ip-filter：只讓必要網域回傳真實位址

在預設的黑名單語意下，fake-ip-filter 表示清單中的網域不使用合成位址，而是採用一般解析。它不是代理繞過清單。網域加入過濾清單後，連線仍會繼續比對 rules；需要直連的服務，還得確認對應規則是否指向 DIRECT。

以下是適用於 mihomo 的局部範例。127.0.0.1:1053 是方便手動驗證的本機監聽位址，不會自動成為系統 DNS。合併到現有設定時，只保留一個頂層 dns:，並保留原設定所需的解析分流、上游位址及其他欄位。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - localhost
    - "+.lan"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

此處的上游位址僅用來示範設定結構，實際使用時應選擇目前網路可連線且符合內網需求的解析器。在 mihomo 的網域比對語法中，+.home.arpa 可匹配該網域本身及其子網域。若使用舊版 Clash 核心，請先確認它支援的欄位與比對語法；不要假設舊核心支援 fake-ip-filter-mode。

適合逐項驗證的排除對象

自建的區域網路網域：例如 nas.home.arpa。如果該網域只存在於路由器 DNS 中，也需要讓它使用內網解析器。
需要驗證真實位址的應用程式網域：應用程式可能會比對 DNS 結果與伺服器回傳的位址。先從記錄中確認實際查詢的網域名稱，再新增精確項目。
特定遊戲或裝置探索服務：只有在觀察到 DNS 合成位址造成異常後才排除。遊戲連線也可能涉及 UDP、NAT 與中繼服務；過濾網域無法修復這些獨立問題。

.local 通常使用 mDNS，與一般單播 DNS 不同。即使將相關名稱加入過濾清單，也不代表 TUN 會自動轉送多點傳播探索資料。找不到投放裝置或印表機時，也要檢查區域網路存取權限、多點傳播路徑與防火牆。

五、內網解析與規則分流必須分開設定

「回傳真實位址」、「向哪一台 DNS 查詢」和「連線走哪個出口」是三個不同問題。例如 NAS 使用 nas.home.arpa，路由器位址為 192.168.1.1，可以在上方範例中加入解析策略，並將直連規則放在可能先匹配的廣泛規則之前。

# 以下欄位請合併至現有的 dns，不要再建立第二個 dns。
dns:
  nameserver-policy:
    "+.home.arpa": "192.168.1.1"

# 以下項目請加入現有的 rules，並留意比對順序。
rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT

這只是合併位置示意，並非可直接取代訂閱內容的完整設定。範例中的 192.168.1.1 必須換成實際的內網 DNS；若目前網路無法連線到該位址，即使過濾清單設定正確也無法取得有效回應。

訂閱更新可能會覆蓋手動修改的內容。使用用戶端提供的覆寫、擴充設定或合併功能時，應先確認最後產生的執行設定：過濾項目是否保留、解析策略是否合併，以及直連規則是否排在兜底規則之前。介面顯示「儲存成功」不代表核心已載入新欄位。

六、透過 DNS 查詢與連線記錄驗證設定

步驟一：確認目前執行中的核心設定

記下用戶端顯示的核心名稱與版本，並檢查執行設定中的 enhanced-mode、listen、過濾清單及 TUN DNS 劫持設定。用戶端介面可能會重新產生欄位，應以載入後的設定與記錄為準。如果核心回報未知欄位，請先修正相容性問題，再繼續測試。

步驟二：直接查詢本機 DNS 監聽埠

若實際監聽設定與前面的範例相同，請在已安裝 dig 的系統上執行：

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

Windows 可透過 nslookup 的互動模式指定埠號：

nslookup
> server 127.0.0.1
> set port=1053
> set type=A
> example.com
> nas.home.arpa
> exit

如果第一個網域未被過濾，通常應回傳位址池中的 IPv4 位址；只有在內網 DNS 確實設有第二個網域的記錄時，才應回傳對應的內網位址。不要照抄某個固定的 198.18.x.x 當作正確答案，位址分配會隨對應狀態改變。

步驟三：檢查系統實際使用的 DNS 與連線路徑

關閉應用程式現有的連線，再重新連線，並查看用戶端「連線」頁面是否顯示目標網域、命中規則與出站策略。
如果手動 DNS 查詢正常，但應用程式無法連線，請檢查系統 DNS 是否進入核心，以及 TUN 是否接管合成位址連線。
如果應用程式使用自己的加密 DNS，先記下目前設定，再暫時關閉該功能進行比較。應用程式內的 DoH 查詢不一定會經過核心的一般 DNS 監聽。
如果只有 IPv6 路徑異常，請分別檢查 AAAA 查詢、IPv6 路由與接管設定。只測試一次 A 記錄，不能代表 IPv6 也正常。

切換模式後，可在 Windows 執行 ipconfig /flushdns 清除系統解析快取，再重新啟動測試中的應用程式。瀏覽器、應用程式和核心也可能各自保留快取或長連線，因此只重新整理網頁不一定會觸發全新的 DNS 查詢。

七、常見故障：先找出哪個環節失效

關閉用戶端後，網站仍嘗試連線至 198.18 位址

通常需要檢查殘留的 DNS 快取、舊連線，以及尚未還原的系統網路設定。還原一般 DNS 與代理設定、清除系統快取，再重新啟動應用程式。不要嘗試為合成位址新增公網閘道；沒有對應資料與接管機制時，它不是可直接連線的網站位址。

加入過濾項目後，內網網站還是無法開啟

先查詢過濾後的真實 DNS 回應。若回傳不存在或逾時，問題出在解析路徑；若已回傳正確的內網 IP，接著檢查連線規則、路由與防火牆。過濾清單只能解決「不再回傳合成位址」，不會自動找到內網 DNS，也不會自動允許區域網路連線。

網頁正常，但 ping 合成位址失敗

ping 使用 ICMP，與網頁使用的 TCP 或 QUIC 請求不同。不同核心與接管方式對 ICMP 的處理也不一樣；合成位址的 ping 結果不是節點延遲。請以實際應用程式連線、連線記錄及針對目標服務的測試為準。

改用 Redir-Host 後恢復正常，就該一直使用嗎？

可以先保留目前正常運作的設定，再找出差異所在。如果只有一項服務受影響，優先嘗試精確過濾與正確的內網解析；如果許多應用程式都依賴真實 DNS 位址，Redir-Host 也能作為長期方案。判斷依據應是連線能否穩定重現、規則命中是否符合預期，以及維護成本是否可控，而不是哪種模式聽起來比較先進。