Clash Fake-IP 模式設定與原理：DNS 對應、fake-ip-filter 與適用情境

先確認 DNS 與流量都經過核心

設定 Fake-IP 前，請先確認兩件事：應用程式的 DNS 查詢能送達 Clash 核心，接著發出的連線也由同一個核心接管。若只啟用 DNS 設定，卻讓連線直接經由實體網卡送出，應用程式可能取得無法從公網連線的合成位址，導致網頁一直載入。

在用戶端的設定檔詳細資料或執行中的設定中，確認 dns.enable 為 true，且 dns.enhanced-mode 為 fake-ip。
確認目前使用的是系統代理，還是由 TUN 接管流量。系統代理只涵蓋遵循代理設定的應用程式；TUN 能接管更多 IP 流量，但路由與 DNS 設定仍須正確。
開啟用戶端的連線面板，前往一個未曾存取的網域，查看是否顯示網域、命中的規則與出口。選單名稱會因用戶端而異，別只看首頁的「已連線」狀態。
如果使用的是 Clash Meta（現名 mihomo），請以目前核心實際生效的設定為準。用戶端編輯器中的訂閱原始內容，不一定等同合併覆寫後的執行設定。

DNS 對應如何連結規則分流

從真實解析改為本機對應

傳統流程是應用程式先透過 DNS 取得目標的真實 IP，再連線至該 IP。Fake-IP 則會先從位址池分配合成的 IPv4 位址，例如 198.18.0.2，並由核心記錄「網域 ↔ 合成位址」的對應關係。這裡的位址僅供說明流程，不代表每次查詢都會取得相同結果。

應用程式查詢 www.example.com 的 A 記錄。
核心記錄網域與 Fake-IP 的對應關係，並將合成位址回傳給應用程式。
應用程式連線至這個位址，連線再經由系統代理或 TUN 等接管路徑送交核心。
核心依目標位址找回網域，按照網域規則選擇策略群組，再透過選定的出口完成連線。

常見設定中的 198.18.0.1/16 位於 198.18.0.0/15 基準測試保留位址區塊內，並非目標網站的公網位址。這個範圍也不是「免費節點位址」。如果企業網路、測試環境或另一套 VPN 使用了重疊網段，請先處理路由衝突。

為什麼可能縮短等待時間

對於能依網域比對規則，且代理協定支援傳遞網域的連線，不必先等目標網域完成真實 DNS 解析，就能開始代理連線流程。實際解析可以交由遠端處理，減少本機 DNS 查詢成為連線必要等待步驟的機會。

這不代表所有連線都會變快。使用直連出口時，通常仍需要真實 IP；比對 IP 類型規則時也可能觸發解析。節點往返延遲、遠端 DNS、交握流程與目標網站回應，都可能是主要耗時來源。Fake-IP 無法讓不可用的節點恢復正常，也不會自動降低節點延遲測試結果。

Fake-IP 與 redir-host 的差異

比較項目	fake-ip	redir-host
A 記錄回應	未排除的網域通常會回傳合成位址。	回傳上游解析取得的真實位址。
網域關聯方式	透過 Fake-IP 對應關係還原目標網域。	可利用 DNS 快取等資訊關聯網域，但一個真實 IP 可能對應多個網域。
本機解析等待	部分代理連線可以延後或省略本機真實解析。	通常必須先取得真實解析結果，才能回應 DNS 查詢。
常見相容性問題	應用程式檢查真實 IP、對應資料遺失，或連線未受接管。	本機解析品質、共用 IP 的網域關聯，以及分流判斷。
適合的使用情境	以網域規則分流為主，且 DNS 與連線路徑可控。	應用程式確實需要真實 DNS 結果，或優先考量相容性。

redir-host 不代表停用網域規則，Fake-IP 也不代表完全不查詢上游 DNS。核心的連線中繼資料、DNS 快取、嗅探設定與規則順序，都會影響實際行為。排查時請查看連線面板中的實際網域與命中規則，不要只根據模式名稱推斷。

如果只有某款遊戲或一台 NAS 存取異常，建議先排除相關網域，不要立刻將所有流量切換至 redir-host。如果許多應用程式都需要真實位址，而且無法妥善維護例外清單，再考慮整體切換，並在相同網路與出口下比較結果。

fake-ip-filter 設定與限制

在傳統 Clash 與 mihomo 的黑名單過濾語意中，fake-ip-filter 列出的網域不會被分配 Fake-IP，而是進行真實解析。這份清單常被稱為「白名單」，更精確的說法是「Fake-IP 排除清單」。它不是代理放行清單，也不會決定連線是否直連。

以下是方便驗證的 DNS 設定片段，並非完整訂閱。範例使用本機的 1053 連接埠，避免直接占用系統常用的 53 連接埠；兩個公共上游僅用來示範語法，實際使用時應換成目前網路可連線且符合需求的解析器。

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:
    - 'localhost'
    - '*.lan'
    - '+.home.arpa'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

listen 只會設定監聽位址。系統 DNS 不會因為這行設定就自動改用 1053 連接埠，仍須由用戶端或系統完成轉送與接管。
ipv6: false 是為了簡化本例中的 AAAA 回應流程，不代表所有網路都應停用 IPv6，也不表示作業系統的 IPv6 已停用。
'*.lan' 可比對符合此模式的區域網路子網域；在支援的網域比對語法中，'+.' 形式可涵蓋網域本身及其子網域。加上單引號也能避免 YAML 誤讀萬用字元。
mihomo 也提供 fake-ip-filter-mode 等擴充設定。如果執行設定採用 whitelist，清單的意義會反轉；使用前請先確認核心支援情況與目前模式，不要混用不同模式的設定片段。

訂閱更新可能會取代原始檔案。若要長期保留修改，請放入用戶端支援的覆寫或合併設定中，再檢查最後生效的執行設定。也要留意清單的合併方式：有些用戶端會直接取代整份過濾清單，而非新增項目。

哪些網域適合加入排除清單

區域網路服務與內部網域

NAS、印表機管理頁面與企業內部系統都是優先排查的對象。例如，內部 DNS 將 nas.home.arpa 解析至 192.168.1.20，而應用程式需要辨識這個私有位址時，可以排除該網域，並交由內部 DNS 解析。如果內網規則與流量接管路徑已設定正確，也可能不必排除；請先依實際故障狀況判斷。

.local 常用於 mDNS。mDNS 採用的多點傳播探索路徑不同於一般單播 DNS；加入過濾清單不會自動解決跨網段探索、多點傳播路由或防火牆問題。若能透過 IP 開啟裝置頁面，但裝置探索清單為空，也應一併檢查多點傳播與介面選擇。

會明確檢查位址結果的應用程式

部分遊戲、裝置綁定工具或網路診斷程式會使用 DNS 結果進行位址驗證、區域判斷或後續協定交涉。只有在日誌或對照測試確認 Fake-IP 導致異常後，才排除該應用程式實際查詢的網域。每次新增一個網域，重新啟動應用程式後再測試，比複製數百筆來源不明的清單更容易找出原因。

不要只因網域屬於中國大陸網站就一律排除。直連或代理由規則決定，與 Fake-IP 位址無關。
不要把整個頂層網域加入排除清單當作預設修復方式。範圍過大會改變大量查詢的解析路徑。
不要把節點伺服器的網域解析問題一概歸咎於 Fake-IP。在 mihomo 中，節點網域解析也可能涉及 proxy-server-nameserver 等獨立設定。
過濾通常是依網域設定，不是填入 192.168.1.20 這類目標 IP，就能解決所有內網存取問題。

驗證 DNS 回應與連線結果

先備份設定，再套用修改。以下指令會直接查詢範例中的監聽連接埠，可分別確認「核心是否正確回應」與「系統是否真的使用它」。在 macOS 或 Linux 上，若已安裝 dig，可以執行：

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

在本例設定下，第一個查詢通常應回傳 198.18.0.0/16 範圍內的位址；實際位址不固定。若已正確接入內部 DNS，第二個查詢應回傳內部服務的真實位址。公共解析器查無結果或回報網域不存在，並不能證明過濾功能失效。

檢查回應。若逾時，先確認核心是否正在監聽 127.0.0.1:1053，以及設定是否成功載入。若回傳真實公網位址，請檢查過濾規則與實際使用的增強模式。
檢查應用程式的連線路徑。用瀏覽器開啟相同網域，並查看連線面板。直接查詢成功，只能證明測試指令已連上核心，不代表瀏覽器使用相同的 DNS 路徑。
檢查規則與出口。確認命中的是預期的網域規則與策略群組。若看得到網域但連線失敗，請接著檢查節點、目標連接埠與遠端解析。
記錄比較結果。記下修改前後的 DNS 回應、連線日誌與應用程式結果，每次只修改過濾清單、模式或 DNS 上游其中一項。

不要根據 ping 合成位址的結果判斷節點是否可用。ICMP 與瀏覽器使用的 TCP、QUIC 並非同一種連線，TUN 對 ICMP 的處理方式也可能不同。請優先確認實際服務請求能否完成。

常見問題排查順序

切換模式後，部分網站仍無法開啟

先清除快取。在 Windows 上執行 ipconfig /flushdns 清除系統 DNS 快取，再將相關應用程式完全關閉後重新啟動。瀏覽器、執行環境與應用程式可能各自維護快取；清除系統快取不代表所有舊位址都已清除。重新啟動核心後，對應關係可能改變；若應用程式繼續使用舊的 Fake-IP，也可能造成連線失敗。

啟用 TUN 後，DNS 仍繞過核心

在 mihomo 支援的設定中，TUN 的 dns-hijack 常見目標寫法是 any:53。是否生效仍取決於平台、路由與權限。這類設定主要處理傳統 DNS 路徑，無法直接解密瀏覽器透過 HTTPS 傳送的 DoH 查詢。排查時可暫時關閉瀏覽器自訂的安全 DNS，比較回應與連線日誌，再決定統一的解析方案。

規則設為 DIRECT，仍無法連線至內網裝置

DIRECT 只會決定出口，不會自動提供內部 DNS 記錄，也不會排除另一套 VPN 的網段衝突。請依序檢查：內部網域是否解析至正確位址、系統前往該位址的路由是否正確、TUN 是否接管了不應接管的網段，以及裝置連接埠是否可以存取。

如何選擇適合的模式

一般瀏覽與網域規則分流可從 Fake-IP 開始；遇到局部相容性問題，先用精確的網域過濾處理；若有許多應用程式確實需要真實 DNS 結果，再透過 redir-host 進行對照測試。判斷標準應是服務連線、規則命中與解析路徑都符合預期，而非 DNS 回傳的位址看起來像不像公網 IP。更多流量接管與規則基礎，請參閱規則分流使用指南和連接埠設定說明。