進階設定 閱讀時間約 12 分鐘

Fake-IP 模式原理與設定：mihomo DNS 增強模式、redir-host 與適用情境

說明 Fake-IP 如何透過保留位址提升解析效率與分流準確度，並比較 redir-host、介紹 fake-ip-filter 設定方式及不適用情境。

Fake-IP 的運作流程：網域、合成位址與實際連線

Fake-IP 是 mihomo DNS 的一種增強模式，可透過 dns.enhanced-mode: fake-ip 啟用。它會回傳合成的 IPv4 位址給應用程式，並在核心中保存「網域與合成位址」的對應關係。這個位址不是網站伺服器的實際位址，也不是代理節點位址；它相當於提供給應用程式的連線索引。

常見設定會使用 198.18.0.1/16 作為分配範圍。這段位址屬於保留供網路效能測試使用的 198.18.0.0/15 位址空間，並非一般可供網站在公網提供服務的位址。使用前仍須確認企業網路或測試網路是否已占用這段位址，不能只因它是保留位址就假設不會衝突。

  1. 應用程式查詢 example.com，查詢會送至 mihomo 的 DNS 服務。
  2. mihomo 會為該網域分配一個位址池中的位址，並保存對應關係。應用程式收到的位址可能是 198.18.0.2，實際分配值並不固定。
  3. 應用程式連線至這個合成位址；該連線必須再次進入同一個 mihomo 核心。
  4. 核心會依據對應關係還原網域、比對規則，再透過選定的直連或代理出口建立實際連線。

解析更快、分流更準，分別代表什麼？

減少等待上游 DNS 回應的情況

對於可由本機分配合成位址的查詢，mihomo 不必先等待上游回傳目標網站的實際 IPv4 位址，就能回覆應用程式。若後續使用支援傳遞網域資訊的代理出口，目標網域也可交由遠端解析。這只能減少部分連線流程中的 DNS 等待時間，不代表節點延遲、下載頻寬或伺服器回應速度也會改善。

若規則最後選擇 DIRECT，建立直連通常仍需要實際位址。遭過濾的網域、某些查詢類型，以及其他需要實際解析結果的情況，也仍會使用上游 DNS。因此，Fake-IP 並不代表「所有連線都不再查詢 DNS」，也不宜宣稱能在所有網路環境中固定提升某個百分比的速度。

保留網域資訊，方便比對網域規則

透明接管連線時，系統最初交給核心的通常只有目標 IP。Fake-IP 的對應關係可讓核心還原原始查詢網域，再比對 DOMAIN、DOMAIN-SUFFIX 等規則。例如 DOMAIN-SUFFIX,example.com,Proxy 可比對該網域及其子網域；其中的 Proxy 必須是設定中實際存在的代理或代理群組名稱。

  • 規則仍會由上而下執行，較早符合的規則可能先決定出口。
  • 應用程式直接連線至寫死的 IP 時，沒有對應的 DNS 查詢，Fake-IP 無法憑空還原網域。
  • 若應用程式繞過 mihomo，自行使用加密 DNS，核心不一定能取得對應資訊；嗅探功能可補充部分網域資訊，但並非所有通訊協定都能嗅探。

Fake-IP 與 redir-host 的差異

redir-host 會將上游解析出的實際 IP 回傳給應用程式，並嘗試透過 DNS 紀錄將網域與連線關聯起來。它並非「關閉 DNS」，也不是一種出口模式。兩種 DNS 增強模式都能搭配規則模式使用，主要差異在於應用程式收到的位址，以及核心保留網域資訊的方式。

比較項目 Fake-IP redir-host
應用程式收到的 IPv4 位址 符合條件時，回傳位址池中的合成位址 回傳實際解析出的位址
網域關聯方式 透過合成位址與網域的對應關係還原 依據 DNS 紀錄關聯；遇到共用 IP 等情況時，可能較難判斷
初次 DNS 查詢等待時間 部分查詢可直接由本機回覆 通常需要等待上游回覆，快取命中時除外
相容性注意事項 應用程式是否要求實際位址，以及連線是否回到同一個核心 實際解析品質、DNS 快取，以及網域關聯資訊是否完整
區域網路應用程式 內部網域可能需要加入過濾清單並設定專用 DNS 仍須設定能解析內部網域的 DNS

選擇前先確認需求。若需要透明接管，且主要依賴網域規則，可優先測試 Fake-IP；若應用程式需要取得實際位址，或現有軟體無法相容合成位址，可使用過濾規則，必要時再切換至 redir-host。切換 DNS 模式後，應清除舊快取並重新建立連線，否則測試結果可能受到舊位址影響。

精簡設定：先測試 DNS，再接管系統流量

以下是供本機測試用的 mihomo 設定片段，並非完整訂閱。它只會在迴路位址的 1053 連接埠提供 DNS 服務，不會自動變更系統 DNS，也不會自動啟用 TUN。請合併至現有設定的對應欄位，避免在同一份 YAML 文件中重複宣告 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-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9
  • listen 用來設定 DNS 的監聽位置。系統 DNS 設定通常無法填入自訂連接埠，因此不能直接將「127.0.0.1:1053」當成一般 DNS 伺服器位址填入系統設定介面。
  • ipv6: false 僅用來縮小本範例的 DNS 測試範圍，不代表關閉作業系統的 IPv6，也不是所有部署情境都適用的設定。
  • nameserver 是範例中的上游 DNS，請確認目前網路可以連線。企業內部網域通常也需要內部 DNS，不能期待公共 DNS 解析器回傳內部位址。
  • fake-ip-filter-mode 須使用支援此欄位的 mihomo 版本。舊版 Clash 分支對欄位的支援情況不同，請先確認用戶端使用的核心，並檢查設定載入錯誤。

桌面用戶端可能透過「覆寫」或「擴充設定」產生執行中的設定，更新訂閱也可能覆蓋手動編輯的內容。修改後，請使用用戶端提供的執行中設定檢視功能核對最終的 dns 區段，並在記錄頁確認設定已成功載入。編輯器顯示儲存成功，不代表核心已套用新設定。

fake-ip-filter 設定方式：回傳實際位址不代表直連

在上述 blacklist 模式中，符合 fake-ip-filter 的網域不會使用 Fake-IP，而會改為實際解析。"localhost" 用來指定名稱；"*.lan" 用來比對相應的子網域；"+.home.arpa" 可涵蓋 home.arpa 及其子網域。含星號的字串應加上引號，避免 YAML 將其解讀為其他語法。

先加入特定網域，再考慮整個網域後綴

假設 NAS 使用 nas.home.arpa，而應用程式需要取得實際的內網位址，可將該網域加入過濾清單。同時也要讓家庭路由器的 DNS 負責解析此網域。只新增過濾項目，不會自動找到正確的內部 DNS；如果上游仍是公共 DNS 解析器，結果可能還是找不到網域。

.local 常用於 mDNS，而 mDNS 與一般單播 DNS 的探索機制不同。將 "*.local" 加入過濾清單，只能解決「不要回傳合成位址」這個問題，無法保證跨網段探索印表機、投放裝置或其他區域網路服務。

分開管理過濾清單與出口規則

將網域加入過濾清單，不會自動新增 DIRECT 規則；該網域仍須依照 rules 判斷出口。反過來說，新增直連規則也不代表一定要停用該網域的 Fake-IP：核心可以先還原網域，再解析實際位址並建立直連。

TUN、系統代理與 DNS 劫持如何搭配

Fake-IP 是 DNS 層的機制，TUN 是讓流量進入核心的一種方式，而系統代理則是告知遵循此設定的應用程式使用本機代理連接埠。三者不能互相取代。尤其是瀏覽器透過 HTTP 代理傳遞目標網域時，目標解析可能由代理連線處理，不一定會經過瀏覽器本機的 Fake-IP 查詢。

  • 系統代理：適合會讀取系統代理設定的應用程式。未使用此設定的遊戲、命令列工具或背景服務，可能仍會依照原本的網路路徑連線。
  • TUN：透過虛擬網路介面接管符合路由條件的流量。也須確認路由、排除項目，以及 DNS 查詢是否有進入核心。
  • DNS 劫持：例如 TUN 設定中的 dns-hijack 可處理指定的 DNS 流量，但劫持連接埠 53 的流量，不代表能攔截所有 DoH、DoT 或應用程式內建的解析。

同時使用多張網卡、VPN 與企業安全軟體時，路由優先順序可能導致合成位址的連線走錯介面。另一個常見問題是本機與路由器各執行一個核心：DNS 對應存在路由器上，連線卻交由本機核心處理。兩套獨立的對應關係無法自然互通，應讓 DNS 回覆與連線處理位於同一套流量接管流程中。

基本設定可參考系統代理設定與規則模式說明。排查時一次只變更一個條件：先確認 DNS，再確認流量接管，最後檢查規則與代理群組的選擇。

驗證方式：查詢結果、連線記錄與快取

第一步：直接查詢 mihomo 的監聽連接埠

使用前述本機測試設定時，可執行以下指令。Windows 可使用 nslookup；已安裝 dig 的 Linux 或 macOS 環境則可使用第二條指令。測試網域不應列於過濾清單中。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A

若回覆位址落在設定的 198.18.0.0/16 範圍內，代表此次查詢經過 Fake-IP 分配。若回傳實際公網位址，請檢查過濾清單、最終執行中的設定與查詢目標。若逾時，請先檢查 DNS 是否已啟用、監聽連接埠是否遭占用，以及核心是否成功啟動。

第二步：檢查應用程式的實際連線

建立流量接管流程後，使用同一個網域，並在用戶端的「連線」或記錄頁查看目標網域、命中的規則與出口路徑。查詢指令取得合成位址，只能證明 DNS 分配正常；應用程式成功連線且命中預期規則，才能證明整個流程有效。請勿以對合成位址執行 ping 的結果判斷網頁是否可用。

第三步：清除快取後重新測試

Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。瀏覽器與應用程式也可能維護獨立快取及長連線，因此需要關閉相關連線或重新啟動應用程式。清除系統快取不保證能清除所有應用程式的快取。

mihomo 的 profile.store-fake-ip: true 可用來持續保存 Fake-IP 對應關係，但無法修正錯誤路由，也不會讓不同裝置共用對應資訊。若重新建立對應、更換位址池或切換模式，也應一併處理應用程式中殘留的舊位址，避免出現「應用程式仍持有舊位址，但核心已沒有相應紀錄」的情況。

不宜直接啟用的情境與切回方式

部分軟體會將 DNS 結果視為實際服務位址，例如將位址寫入訊號資料、交由另一台裝置連線，或據此判斷是否位於區域網路。這時合成位址可能會傳給無法存取該對應資訊的裝置。企業內網、測試網路及部分遊戲的連線流程也應個別測試，而不是在整台裝置啟用後只確認瀏覽器能否使用。

  1. 只有一個應用程式異常：確認它使用哪些網域、是否自備 DNS，以及是否直接連線至 IP；先將確實有相容性問題的網域加入過濾清單。
  2. 只有內網服務異常：檢查內部 DNS、網域過濾、私有網路路由與出口規則。若位址解析正確但仍無法存取，請繼續檢查路由與存取權限。
  3. 所有應用程式都異常：檢查合成位址是否進入同一個核心、TUN 路由是否生效，以及是否與其他 VPN 衝突。
  4. 應用程式必須取得實際位址：先備份執行中的設定，再切換為 enhanced-mode: redir-host，重新載入設定、清除快取、重建連線並驗證規則。

最後請釐清隱私範圍：Fake-IP 不等於加密 DNS，也不保證所有 DNS 查詢都會透過代理傳送。上游協定、DNS 出口策略、應用程式自備的解析功能與直連規則，都會影響實際連線路徑。請依據查詢、路由與記錄等資訊判斷是否符合預期，而不要只看用戶端是否開啟「Fake-IP」選項。

Clash 下載