跳至正文
進階原理 約需閱讀 12 分鐘

Clash Fake-IP 模式原理：與 redir-host 的差異及適用情境

了解 Clash Fake-IP 如何透過保留位址映射網域、減少 DNS 往返，以及 fake-ip-filter 的用途與區域網路衝突的處理方式。

Fake-IP：先回傳映射位址，再處理實際連線

在 Clash 或 mihomo 設定中看到 enhanced-mode: fake-ip，表示核心的 DNS 模組可以為網域配置一個合成位址。這個位址不是網站伺服器的公用 IP，而是核心查找網域映射的索引。應用程式接著連線至此位址時，流量必須再次進入同一個核心，才能還原網域並繼續處理。

常見設定會使用 198.18.0.1/16 作為 fake-ip-range。此位址範圍位於供網路基準測試使用的保留區塊 198.18.0.0/15 內，不是一般公用網站位址，也不是 192.168.0.0/16 這類私人區域網路位址。若 DNS 結果中出現此位址，不能直接判定為解析錯誤。

一次連線會經過哪些步驟

  1. 應用程式查詢 example.com，查詢要求進入核心 DNS。
  2. 核心建立網域與合成位址的映射，並將該位址回傳給應用程式，例如 198.18.0.10。此處數字僅供示意，實際配置結果不固定。
  3. 應用程式連線至該位址，TUN 等流量接管路徑會將連線送回核心。
  4. 核心還原 example.com，依規則選擇直連或代理；需要實際位址時，再依相應的出站與 DNS 設定進行解析。

Fake-IP 與 redir-host 的主要差異

redir-host 通常會先查詢上游 DNS，再將實際 IP 回傳給應用程式。核心會嘗試利用 DNS 紀錄關聯網域，但同一個 IP 可能對應多個網域，關聯資訊也可能遺失。Fake-IP 則透過專用映射保留網域，通常更有利於依網域分流，但前提是完整接管連線路徑。

比較項目 Fake-IP redir-host
應用程式取得的 DNS 位址 通常是由位址池配置的合成位址；符合過濾條件的網域例外。 通常是上游 DNS 解析出的實際位址。
回傳 DNS 答案前 未符合過濾規則時，通常不必先等待實際 A 記錄。 通常需要等待實際解析結果，或使用快取。
網域識別 可透過合成位址映射還原網域。 依賴 DNS 關聯、要求中包含的網域，或嗅探等資訊。
相容性注意事項 應用程式是否接受合成位址，以及連線是否會回到核心。 上游 DNS 解析品質、實際位址可連線性，以及網域關聯資訊是否完整。

「減少 DNS 往返」不代表完全不做 DNS 解析

Fake-IP 減少的是部分情境下，應用程式等待實際解析的前置步驟。如果規則直接依網域選擇代理，且出站協定能將網域交由遠端處理，本機便可省去一次用來取得目標實際 IP 的查詢。但直連出口通常仍需要實際位址；IP 類規則、過濾網域及其他解析需求，也可能觸發上游查詢。

因此，無法保證固定節省多少毫秒。快取命中率、上游 DNS 延遲、節點位置和連線重複使用都會影響結果。比較兩種模式時，應使用相同網路、相同節點和相同網域，分別記錄 DNS 耗時與網頁第一個位元組的回應時間，不要把單次測速結果當成普遍結論。

mihomo 設定：分清 DNS 監聽與代理連接埠

以下 YAML 片段用於說明各欄位，適用於支援這些欄位的 mihomo 設定。內容未包含節點、代理群組與規則，不能直接當作完整訂閱使用。將欄位合併至現有設定時，請保留原有出站設定；圖形化用戶端可能透過覆寫功能產生最終設定，請以目前實際生效的設定為準。

mixed-port: 7890
mode: rule

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
    - 119.29.29.29
  • mixed-port: 7890：提供 HTTP 與 SOCKS 混合代理入口，不是 DNS 連接埠。實際連接埠請以用戶端顯示為準。
  • listen: 127.0.0.1:1053：僅在本機監聽 DNS，方便指定目標進行測試。Windows 網卡的 DNS 通常使用連接埠 53，不能只填入 127.0.0.1 就自動連到 1053。
  • ipv6: false：控制此 DNS 模組如何處理 AAAA 查詢，不代表關閉 Windows 的 IPv6 通訊協定堆疊。
  • nameserver：列出上游解析器。範例使用一般 DNS，不代表已啟用加密 DNS，也不保證每個網路都能連線。

訂閱更新可能會覆蓋手動編輯的設定。如果用戶端提供「覆寫」或設定合併入口，建議優先透過該入口修改 DNS 欄位。儲存後重新載入設定，並檢查記錄中是否出現 YAML 解析錯誤、監聽失敗或上游要求逾時；介面上的開關狀態不能取代對實際生效設定的檢查。

fake-ip-filter：只將需要實際位址的網域設為例外

一般過濾語意下，符合 fake-ip-filter 的網域不會配置 Fake-IP，而是進行實際解析。mihomo 也支援透過 fake-ip-filter-mode 調整比對語意；若設定中使用此欄位，請先核對目前版本的文件與實際值，不要直接套用預設黑名單語意判斷。

先找出特定網域，再新增過濾規則

  • 區域網路管理介面：先確認裝置實際使用的主機名稱，例如 nas.home.arpa，再為該名稱或必要的網域後綴新增例外。
  • 企業內部服務：確認公司 DNS 能解析內部網域；必要時可透過 nameserver-policy 指定公司解析器。
  • 依賴實際解析結果的應用程式：從記錄中找出解析失敗的網域，逐一新增例外，其餘網域仍維持 Fake-IP 行為。

+.lan 代表比對相關網域後綴，並不是辨識所有本機裝置的通用機制。.local 常用於 mDNS，涉及多點傳送探索；將 +.local 加入過濾，不會自動讓一般上游 DNS 變成 mDNS 轉送器。若找不到印表機，還要檢查應用程式的探索機制、防火牆和所在網段。

過濾規則不等於直連規則。它只決定 DNS 是否回傳合成位址，不會指定連線使用 DIRECT。如果 NAS 網域需要直連，還要另外設定相應的網域規則；如果只有公司 DNS 知道實際位址，也需要正確選擇解析器。把整份過濾清單擴大到所有網域，會削弱 Fake-IP 的作用，卻不一定能解決真正的路由問題。

TUN、系統代理與加密 DNS 的搭配

Fake-IP 是 DNS 工作模式，TUN 則是流量接管方式，兩者不是同一個開關。TUN 模式通常更適合接管應用程式連線至合成位址的流量；系統代理主要影響遵循 Windows 代理設定的應用程式。只啟用系統代理，不代表所有程式的 DNS 查詢與連線都會進入核心。

依照要求路徑檢查四個位置

  1. Windows DNS：在 Windows 11 開啟「設定」→「網路和網際網路」→目前連線的「內容」→「DNS 伺服器指派」，確認使用中的解析器。不同系統版本的頁面名稱可能略有差異。
  2. 用戶端 TUN：確認虛擬網卡已建立、服務運作正常，且路由涵蓋所使用的 Fake-IP 位址池。需要服務權限的用戶端，應先完成相應的服務安裝。
  3. DNS 劫持：檢查實際生效設定中的 tun.dns-hijack。常見的 53 連接埠劫持無法自動接管所有應用程式內建的 DoH 要求。
  4. 瀏覽器安全 DNS：在 Microsoft Edge 開啟「設定」→「隱私權、搜尋與服務」→「安全性」，檢查「使用安全 DNS」相關選項。受組織管理的裝置可能由原則控制。

如果瀏覽器直接向外部 DoH 服務查詢，可能會取得實際 IP，繞過核心的 Fake-IP 配置。網站仍可能正常開啟，但該連線不一定有預期的 DNS 映射。網域嗅探有時能補上資訊，卻無法保證從所有協定中還原網域。診斷時可暫時關閉應用程式自己的安全 DNS 進行比較，確認原因後再決定統一解析路徑，或保留獨立解析。

Windows 驗證：分別檢查查詢、連線與記錄

先測試核心 DNS 是否如預期回應，再測試應用程式連線。若使用上方的 1053 監聽範例，請在 PowerShell 或命令提示字元中啟動 nslookup，依序輸入以下命令。互動模式中設定的連接埠只用於本次測試，不會修改 Windows 網卡的 DNS。

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

在未符合過濾規則且設定已正確載入的情況下，答案應位於設定的 Fake-IP 位址池內。不必要求一定回傳特定的末位數字。如果顯示逾時，請先確認 DNS 是否已啟用、監聽位址是否一致，以及核心記錄；如果回傳實際 IP，先檢查過濾規則與生效中的 enhanced-mode。

切換模式後清除舊狀態

ipconfig /flushdns

此命令會清除 Windows DNS 用戶端快取，但不會清除所有瀏覽器快取、應用程式連線集區或核心映射。切換 Fake-IP 與 redir-host 後，也應關閉受影響應用程式的舊連線，必要時重新啟動應用程式。重新載入設定若導致映射失效，而應用程式仍保留舊的合成位址，可能會短暫連線失敗。

接著在用戶端的「連線」頁面查看目標網域、符合的規則、策略群組和出站節點。DNS 已回傳合成位址，但連線清單中沒有相應紀錄時，請優先檢查流量是否進入核心；若已有連線紀錄但連線失敗，則繼續檢查實際解析、節點連線狀態和出站錯誤。不要只根據 ping 結果判斷網站代理是否正常，ICMP 與瀏覽器的 TCP、UDP 要求並非同一條驗證路徑。

區域網路衝突與模式選擇

如果某個 VPN、測試環境或公司網路已使用 198.18.0.0/15 範圍內的位址，Fake-IP 路由可能會與實際目標衝突。請先執行 route print，檢查目的網段、介面和躍點數，再依 VPN 設定確認位址用途。不要只因為看到保留位址就直接刪除系統路由。

狀況 優先處理方式
公用網站正常，但 NAS 網域無法連線 檢查 NAS 網域的實際解析器、過濾例外與直連規則。
取得合成位址，但所有連線都失敗 檢查 TUN 路由、應用程式是否繞過代理，以及核心映射是否仍有效。
啟用公司 VPN 後，部分位址無法連線 檢查位址池是否與 VPN 路由重疊，並依網路管理要求調整。
只有特定應用程式拒絕合成位址 先新增範圍最小的過濾例外，再評估 redir-host。

調整 fake-ip-range 時，必須同時確認新位址範圍不會與實際網路衝突，並同步更新接管路由與排除規則。不要任意改成目前正在使用的家用區域網路網段。如果無法協調公司 VPN 與虛擬網卡策略，可切換至 redir-host 作為相容性比較，但仍須驗證網域規則、解析品質和內部服務連線。

對於主要依賴網域分流，且能完整接管 DNS 與連線的 Windows 環境，可優先測試 Fake-IP。若環境需要保留實際 DNS 回應、使用特殊的區域網路探索機制，或受企業網路政策限制，請先為特定網域設定例外；仍無法滿足需求時，再評估 redir-host。選擇依據應是實際要求路徑與應用程式相容性，而不是認定某一種模式適用於所有網路。

下載 Clash