進階設定 預計閱讀 12 分鐘

Clash Fake-IP 模式解析：DNS 對應原理與適用情境

了解 fake-ip 如何以保留位址範圍對應網域、與 redir-host 的差異，以及 fake-ip-filter 的設定重點與不適用情境。

Fake-IP 原理：先回傳對應位址，再依網域處理連線

啟用 Fake-IP 後，查詢網站網域時看到 198.18.x.x，通常是預期結果，不代表網站真的搬到這個位址。Clash 的 DNS 模組會從指定的位址池分配一個合成 IPv4 位址，並在內部保存「網域與合成位址」的對應關係。應用程式使用這個位址發起連線，核心接管連線後，再透過對應關係找回原始網域。

典型流程可分為四個步驟。了解這條連線路徑，比只記住 enhanced-mode: fake-ip 更有助於排查問題。

  1. 應用程式查詢 www.example.com 的 A 記錄，請求送至核心的 DNS 服務。
  2. DNS 模組從位址池分配一個位址，例如 198.18.0.2，並記錄其對應網域。實際分配結果不固定。
  3. 應用程式向這個合成位址的 TCP 443 連接埠發起連線，流量透過 TUN 或其他透明接管機制進入核心。
  4. 核心還原網域，依規則選擇出站方式；直連或代理出站接著會依自身需求完成真實位址解析與連線。

Fake-IP 可讓網域規則在建立連線時直接取得網域資訊，降低部分情境對本機真實解析結果的依賴。但這不代表所有連線都完全不需要真實 DNS：直連目的地、需要 IP 資訊的規則，以及代理節點本身的網域解析，仍可能觸發查詢。Fake-IP 也不是加密協定，不會自動將明文 DNS 轉為加密 DNS。

Fake-IP 與 redir-host：差異在 DNS 回覆與網域還原方式

redir-host 會回傳上游解析出的真實位址；fake-ip 則會在適用的查詢中回傳合成位址。兩者都能搭配規則分流，但應用程式看到的位址不同，核心取得網域資訊的方式也不同。

比較項目fake-ipredir-host
應用程式收到的 A 記錄通常是位址池中的合成 IPv4 位址上游回傳的真實 IPv4 位址
網域關聯方式透過合成位址對應關係找回網域依賴 DNS 快取關聯等資訊，必要時可搭配嗅探
對本機真實解析的依賴部分代理連線可延後解析，或交由遠端解析回覆應用程式查詢前，通常須先取得真實解析結果
常見相容性限制程式會檢查位址、區域網路探索、流量未被接管多個網域共用同一 IP 時，網域關聯可能有歧義
適合優先測試的情況TUN 接管穩定，主要使用瀏覽器與一般網路應用程式應用程式必須取得真實位址，或現有網路不便接管合成位址

不要把這兩種模式視為固定的速度排名。首次解析延遲、代理節點的 DNS 環境，以及規則是否觸發 IP 查詢，都會影響連線時間。若要比較，應在相同網路、相同節點與相同目標網站下重複測試，而不是根據一次網頁載入結果判斷模式優劣。

mihomo DNS 設定：最小設定範例與生效條件

以下是適用於 mihomo 的 DNS 設定片段，不是包含節點與規則的完整設定。範例將 DNS 監聽在本機 127.0.0.1:1053，方便單獨驗證；一般系統 DNS 設定通常只接受伺服器位址，且預設使用 53 連接埠，不能直接將 1053 連接埠填入系統 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:
    - "localhost"
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • enable 用來啟用內建 DNS。若只設定模式但未啟用 DNS，就無法取得預期的對應回覆。
  • listen 用來設定監聽位址與連接埠。迴路位址僅供本機存取，不會主動向整個區域網路提供服務。
  • ipv6: false 是為了簡化此範例中的 AAAA 查詢處理，不代表停用作業系統的 IPv6 網卡或路由。
  • fake-ip-range 用來定義合成 IPv4 位址池。請確認位址範圍與現有 VPN、測試網路及路由規劃不重疊。
  • nameserver 用於需要真實解析時的上游查詢。範例中的 IP 格式是傳統 DNS，上游伺服器必須能從目前網路連線；加密 DNS 需另外設定。

設定生效前，先確認三件事

  1. 確認目前執行的核心。查看用戶端的核心資訊與啟動記錄。Clash、Clash Meta、mihomo 支援的欄位範圍不盡相同，不能將新版核心的額外欄位直接套用至舊版。
  2. 確認修改的是實際生效的設定。訂閱檔案可能在更新時遭到覆寫。建議使用用戶端提供的覆寫或合併功能，重新載入後再檢查最終設定。
  3. 確認 DNS 與連線都能進入核心。測試查詢送至 1053，只能證明 DNS 服務可用；應用程式發往合成位址的連線，還需要由 TUN 或其他透明轉送機制接管。

fake-ip-filter：只排除需要真實位址的網域

在 mihomo 預設的黑名單過濾語意下，符合 fake-ip-filter 的網域不會收到 Fake-IP，而是使用真實解析結果。它不是代理規則清單，不會決定流量走 DIRECT 或特定代理群組；流量最終走向仍由出站規則及其他路由設定決定。

前面的範例使用 *.lan 與 *.local 表示常見的區域網路網域後綴。網域比對寫法與特殊規則的支援情況，請以實際使用的核心文件為準；若設定中另有指定 fake-ip-filter-mode，請先確認其語意，再判斷過濾清單的效果。

依實際問題新增項目，別整批複製長清單

  • 企業內部網域：例如某台內部服務需要回傳 10.20.0.15，可先排除該服務的完整網域。也要確保查詢會送至企業 DNS，否則排除後仍可能得到不存在或錯誤的結果。
  • 會驗證目標位址的程式：有些遠端連線、裝置探索或遊戲元件會檢查 DNS 回覆。先針對確實有問題的網域進行測試，再決定是否擴大比對範圍。
  • 區域網路裝置名稱：印表機、NAS 與投影裝置可能使用本機網域，但探索流程也可能涉及 mDNS 多點傳播、廣播或其他協定。過濾網域只能解決其中的 DNS 回覆問題。

如果只有 nas.home.arpa 無法使用，先加入這個完整名稱，比直接排除整個後綴更容易驗證。排除範圍越大，越多連線會改走真實位址解析，也越需要妥善維護內部 DNS 與分流策略。NTP 也不必一律排除：只有裝置或應用程式出現可重現的相容性問題時，才針對實際查詢的時間伺服器網域進行處理。

驗證方式：分別檢查 DNS 回覆、連線與規則

驗證時不要只看瀏覽器能不能開啟網頁。瀏覽器可能使用自己的安全 DNS，也可能已快取位址；網頁能開啟，不代表流量確實經過 Fake-IP。建議先在本機明確指定測試 DNS，再檢查應用程式的連線。

第一步：明確向核心查詢 A 記錄

# macOS / Linux：需要先安裝 dig
dig @127.0.0.1 -p 1053 www.example.com A

# 同時檢查 AAAA 回覆，確認範例中的 IPv6 設定
dig @127.0.0.1 -p 1053 www.example.com AAAA

若 A 記錄位於設定的 198.18.0.0/16 位址池內，表示這次查詢取得了對應位址。不必要求結果固定為 198.18.0.2，也不要將回傳值手動寫入 hosts 檔案。符合過濾清單的網域應另外測試，預期結果是上游提供的真實位址或相應的 DNS 狀態，而不是位址池中的回覆。

第二步：清除舊快取，再測試相同目標

# Windows：在終端機中執行
ipconfig /flushdns

# 使用 systemd-resolved 的 Linux
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

這些命令清除的是系統端快取，不保證會一併清除瀏覽器、應用程式與核心自身的快取。請關閉並重新開啟測試中的應用程式；必要時透過用戶端清除 DNS 快取，再建立新連線測試。核心重新啟動後，舊的合成位址與對應關係不一定仍相同，因此恢復舊的瀏覽器連線時可能短暫失敗。

第三步：核對連線記錄中的網域與出站方式

查看用戶端的連線清單或記錄，確認目標網域、命中規則與出站策略是否符合預期。若需要更詳細資訊，可暫時將 log-level 調整為 debug；測試完成後請還原為常用層級。分享記錄前，請移除訂閱網址、存取權杖、節點憑證與敏感網域。

常見問題：依連線流程逐步排查

現象優先檢查項目處理方向
回傳 198.18 位址，但所有網站都逾時合成位址的流量是否進入核心檢查 TUN 路由、執行權限，以及其他 VPN 是否覆蓋路由
明確查詢 1053 時逾時DNS 模組是否已啟動、連接埠是否正確檢查設定載入錯誤、監聽位址與連接埠占用
只有內部網路服務無法開啟過濾規則、企業 DNS、內部網路路由精確排除該網域，並為其設定正確的內部解析路徑
瀏覽器正常，但某個程式無法使用程式自行使用的 DNS、位址快取與代理方式檢查安全 DNS、快取，以及流量是否繞過接管
切換模式後偶爾發生連線問題應用程式仍保留舊位址或連線清除相關快取、中斷舊連線後重新測試

若真實解析也失敗，請先檢查上游 DNS 是否可連線，不要只是不斷擴大 fake-ip-filter。若 DNS 正常，連線記錄也顯示正確網域，但代理連線逾時，接著應排查節點連線狀態與出站規則。Fake-IP 位於連線流程的前段，無法修復失效節點或錯誤的代理憑證。

使用瀏覽器安全 DNS、Android 私人 DNS 或應用程式內建 DoH 時，查詢可能會繞過核心的一般 DNS 入口。攔截 53 連接埠無法直接處理所有 HTTPS 內的 DNS 請求。測試時請先統一解析路徑，再決定要長期採用哪種 DNS 方案，避免同時變更多個因素。

適用情境與回復順序

對已穩定使用 TUN、需要依網域分流的桌面環境，Fake-IP 值得優先測試。若是企業 VPN、複雜的區域網路，或工具要求顯示真實目標 IP，應先確認路由與解析需求，必要時維持使用 redir-host。Android 的 VPN 介面通常也會與其他 VPN 應用程式競用，單純切換 DNS 模式無法解決介面衝突。

  1. 先局部修正：單一網域異常時，記錄重現步驟，嘗試精確過濾，並確認真實解析結果。
  2. 接著檢查接管範圍：大量合成位址連線逾時時，應優先修復路由、DNS 接管與權限，而不是繼續增加過濾項目。
  3. 最後再評估切換模式：確認應用程式必須取得真實位址，或目前網路無法可靠接管合成位址時，再測試 enhanced-mode: redir-host。

切換前請先儲存可還原的設定；切換後重新載入並清除快取。最後應依三項結果判斷：DNS 回覆符合模式預期、連線命中正確規則，以及日常應用程式與內部網路服務都能穩定使用。保留一份精簡且容易理解的設定，比持續堆疊來源不明的過濾清單更易維護。

下載用戶端