Fake-IP 模式原理解析：DNS 假 IP 映射与區域網路裝置相容問題

1. Fake-IP 的用途：以映射位址保留目標網域

Fake-IP 是 Clash 系列核心的一種 DNS 運作模式。應用程式查詢網域的 IPv4 位址時，核心可以先從指定的位址池分配一個位址，再記錄「網域與假位址」的對應關係。這個位址用於本機或受管理網路中的連線接管，並非網站伺服器的公網位址。

常見設定會使用 198.18.0.1/16 作為位址池設定值，位於 198.18.0.0/15 基準測試保留位址範圍內。這與 192.168.0.0/16 等私有區域網路網段不同，也不應直接傳送到公網。看到這類 DNS 回應，本身不代表解析異常。

一次連線的處理流程

應用程式查詢 example.com，查詢會送至核心的 DNS 服務。
核心從位址池分配一個位址並建立映射。例如，某次分配結果可能是 198.18.0.2；實際位址並不固定。
應用程式向這個假位址發起連線，TUN 或其他透明接管路徑會將連線送回同一個核心。
核心從映射表還原目標網域，依規則選擇直連或代理出口。
直連通常仍須解析出真實位址；代理出口能否將網域交由遠端處理，則取決於出站協定與設定。

關鍵在於查詢與後續連線必須形成完整閉環。若只讓裝置從 Clash 取得假位址，卻沒有讓發往該位址的流量回到對應核心，就會出現「DNS 有回應，網頁卻打不開」的情況。單獨開啟 DNS 監聽埠，並不代表已建立這個閉環。

速度提升的範圍

Fake-IP 可以縮短應用程式等待真實 DNS 結果的時間，也讓核心更容易依原始網域比對規則。但它不會降低網路鏈路的實體延遲，也無法保證所有網站都變快。直連解析、代理交握、TLS 連線建立與伺服器回應仍可能是主要耗時，因此不能把分配假位址的速度等同於網頁載入速度。

2. Fake-IP 與 redir-host：回傳內容和接管條件

比較項目	Fake-IP	redir-host
DNS 回應	符合條件的查詢會取得位址池中的映射位址	回傳上游解析取得的真實位址
網域關聯方式	透過假位址映射還原網域	透過 DNS 紀錄關聯等機制辨識網域，但會受共用 IP 等因素限制
連線前的等待時間	可先分配假位址，不必先取得目標的真實位址	通常須先完成真實位址解析
網路需求	發往假位址的流量必須回到對應核心	真實位址可正常路由，但分流仍取決於接管方式與規則
相容性注意事項	位址檢查、跨裝置連線、舊映射快取	上游解析結果、網域關聯與 DNS 路徑

選擇模式應以實際的連線接管方式為準。桌上型裝置啟用 TUN，且 DNS 查詢由同一個核心處理時，Fake-IP 的運作路徑較清楚。印表機、電視和遊戲主機的網路行為較複雜；若只調整 DNS，卻未設定透明代理路由，就不能直接套用桌面裝置的設定。

系統代理則是另一種連線路徑。HTTP 代理要求可能直接帶有網域，不一定會使用本機 DNS 查詢結果。瀏覽器能連上網站，不代表系統 DNS 和 TUN 都正常運作；同樣地，某個診斷指令無法連線，也不代表 HTTP 代理失效。

3. 最精簡的 DNS 設定與 fake-ip-filter 寫法

以下是 DNS 設定片段，並非包含節點、代理群組與規則的完整設定。範例使用本機 1053 埠，避免直接占用系統常用的 53 埠。TUN 的 DNS 劫持或系統 DNS 轉送仍須另外設定；作業系統一般的 DNS 位址欄位通常無法填入自訂埠號。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '+.lan'
    - '+.local'
    - '+.home.arpa'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

欄位說明與適用範圍

enable：啟用核心 DNS 服務。用戶端介面可能另有獨立的 DNS 覆寫開關，請以最後實際生效的設定為準。
listen：此處只接受本機查詢，不會向區域網路開放 DNS 服務。
ipv6: false：控制此 DNS 模組如何處理 AAAA 查詢，不代表停用作業系統的 IPv6，也不保證其他解析器不會回傳 IPv6 位址。
enhanced-mode：指定 DNS 增強模式。範例選用 fake-ip。
fake-ip-filter：在常見的預設黑名單語意下，符合項目的網域不會分配假位址，而會改為取得真實解析結果。
nameserver：範例列出兩個上游位址。清單順序不代表「中國大陸優先、海外備用」的分流策略；實際行為也會受到核心實作與其他 DNS 欄位影響。

+.home.arpa 用來比對該網域及其子網域。home.arpa 是家庭網路的網域空間；.local 通常與 mDNS 有關，部分請求會透過 UDP 5353 多播傳送，不會經過這裡的一般 DNS 監聽器。將網域加入過濾清單，不能取代 mDNS 轉送或裝置探索機制。

mihomo 提供更細緻的過濾模式選項，例如 fake-ip-filter-mode。複製設定前，請先確認核心是否支援：白名單模式會改變過濾清單的意義，不能再把清單中的每個項目都解讀為「排除」。原版 Clash、不同分支與不同發行版本支援的欄位不盡相同。

4. 區域網路裝置相容性：先區分解析、路由與探索

NAS 網域回傳假位址

例如 NAS 的真實位址是 192.168.1.20，家庭網域為 nas.home.arpa。若查詢結果是以 198.18 開頭的位址，請先確認該網域是否符合過濾條件，再檢查它是否由家庭 DNS 解析。兩個步驟都處理妥當，才能穩定取得私有位址。

在 mihomo 中，可以使用 nameserver-policy 為家庭網域指定解析器。以下片段假設路由器 DNS 位址為 192.168.1.1，且執行核心的裝置可以連線至該位址。請將片段合併至同一個 dns 物件中，不要再建立第二個頂層 dns 鍵。

dns:
  nameserver-policy:
    '+.home.arpa': '192.168.1.1'

這段設定不包含前文的過濾清單，合併時請保留 fake-ip-filter。也要確認路由器沒有將同一筆查詢再次轉送回 Clash，否則可能形成 DNS 轉送迴圈。

印表機、電視與投放裝置無法探索

裝置探索可能使用 mDNS、SSDP 或廣播，不只依賴一般 DNS。mDNS 常用 224.0.0.251:5353，SSDP 常用 239.255.255.250:1900。用戶端若連上訪客 Wi-Fi、位於不同 VLAN，或啟用了無線用戶端隔離，即使網域解析正常，也可能無法探索到裝置。

先使用裝置的實際私有 IP 開啟管理頁面，確認基本連線正常。
接著查詢裝置網域，確認是否取得預期的私有位址。
只有自動探索失敗時，才檢查多播、廣播與網段隔離；不要一再擴大 DNS 過濾清單。

手機取得假位址，連線卻進入另一台閘道器

假位址映射屬於特定的核心執行個體。手機向閘道器 A 查詢 DNS，卻透過閘道器 B 傳送連線時，B 通常沒有 A 的映射。重新啟動 A 後，手機若仍使用舊快取，也可能出現類似問題。家庭網路應統一 DNS 與透明代理的路徑，不能把某台電腦的 Fake-IP DNS 當成獨立的公用 DNS，提供給所有裝置使用。

5. 排查步驟：從 DNS 回應追查實際出口

步驟一：直接查詢核心 DNS

Linux 或 macOS 已安裝 dig 時，可直接連線至範例中的本機埠。以下指令用於檢查，不預設固定輸出：

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

正常的 Fake-IP 分配流程中，前一筆查詢應回傳位址池內的位址。若過濾與家庭 DNS 政策設定正確，後一筆查詢應回傳實際的家庭網域紀錄。若逾時，優先檢查 DNS 監聽與程序狀態；若回傳 NXDOMAIN，則檢查紀錄是否存在，以及是否選錯解析器。

步驟二：檢查系統實際使用的解析器

Windows 可使用 ipconfig /all 查看網路介面卡的 DNS 位址，並以 nslookup example.com 檢查預設查詢路徑。瀏覽器的安全 DNS、應用程式內建的 DoH、VPN 和其他虛擬網卡都可能改變查詢路徑。命令列與瀏覽器使用不同解析器時，查詢結果不同並不罕見。

ipconfig /all
nslookup example.com
ipconfig /flushdns

ipconfig /flushdns 只會清除 Windows DNS 用戶端快取，不會一併清除瀏覽器、應用程式與核心的映射快取。變更模式或重新啟動核心後，請重新啟動仍保留舊連線的應用程式，再執行相同查詢。不要只重新整理頁面，就判定設定沒有生效。

步驟三：確認規則命中與私有網段

請在用戶端的連線清單或記錄中檢查目標網域、目標位址、命中的規則與出口。若要讓家庭網路直連，可參考以下規則片段，並將其放在範圍較廣的代理規則與最終 MATCH 之前：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

這不是完整的規則集，請合併至現有的 rules 清單。no-resolve 表示不會為了比對這條 IP 規則而額外觸發網域解析；已有目標 IP 時仍可用於比對。核心已還原網域的連線，可以先由前面的網域規則命中，不必依賴 IP 規則兜底。

不要把整個 Fake-IP 位址池加入直連規則，試圖讓作業系統直接連線到這些位址。假位址必須先交由維護映射的核心處理，不能當成真實網站位址進行路由。

6. 常見問題與切換模式的時機

ping 連到以 198.18 開頭的位址，代表網站故障嗎？

不是。這可能只是目前網域的假位址。ICMP 的處理路徑與 TCP、UDP 代理不同，不能只根據 ping 結果判斷網頁是否能連線。請一併檢查 DNS 回應、連線記錄與實際應用程式的請求。

fake-ip-filter 可以解決所有遊戲和智慧裝置的錯誤嗎？

不行。它只會調整符合條件網域的位址分配方式。UDP 轉送、NAT 類型、應用程式寫死 IP、憑證錯誤與多播隔離都需要分別排查。只有確認應用程式依賴真實 DNS 位址時，才優先為特定網域新增過濾項目。

啟用 Fake-IP 後一定要開啟 TUN 嗎？

不一定。TUN 是常見的連線接管方式，路由器透明代理也可能完成相同工作。必要條件是發往假位址的相關流量必須由維護該映射的核心處理，而不是介面上的某個開關一定要開啟。

什麼時候可以考慮切換至 redir-host？

如果特定裝置持續檢查 DNS 位址、需要將解析結果交給不經過該核心的其他裝置，或暫時無法統一 DNS 與連線路徑，可以測試 redir-host。切換後請清除相關快取並重新建立連線，同時再次檢查網域規則與真實 DNS 解析路徑。

穩定設定的判斷標準有三項：網域由預期的解析器處理、連線進入正確的核心，且出口符合規則。先針對一個應用程式和一個網域完成驗證，再擴大過濾範圍或調整模式，通常比同時修改 DNS、TUN 和整套訂閱更容易找出問題。基礎欄位可參閱協定參考，網路術語可查閱名詞速查。