進階原理 閱讀時間約 12 分鐘

Fake-IP 與 redir-host 差異：mihomo DNS 增強模式原理與適用情境

了解 mihomo DNS 解析流程、Fake-IP 虛擬位址與降低解析延遲的原理，以及 fake-ip-filter 的用途和不適用的應用程式。

DNS 增強模式會改變哪些行為

在 mihomo 設定中，dns.enhanced-mode 會決定內建 DNS 如何處理位址查詢，以及後續連線如何對應網域名稱。常見值為 fake-ip 和 redir-host。它不是代理協定，也不等同於規則模式、全域模式或 TUN 開關。

要了解這兩種模式，得先區分三個動作：應用程式查詢網域名稱、作業系統發起連線，以及核心依規則選擇出站方式。DNS 回傳的位址只會影響其中一部分流程。連線最終採用直連或代理，仍取決於規則、策略群組及可用的出站方式。

Fake-IP：以虛擬位址保留網域關聯

從查詢到建立連線

  1. 應用程式向已接管的 DNS 查詢某個網域的 A 記錄。
  2. mihomo 從設定的位址池中分配虛擬 IPv4 位址，並保存「網域名稱與虛擬位址」的對應關係。
  3. 應用程式收到位址後發起連線。連線必須再次進入同一個能識別此對應關係的核心。
  4. 核心依虛擬位址找回網域名稱、比對規則，再透過選定的出站方式連線至目標。

例如，位址池設定為 198.18.0.1/16 時，應用程式可能會收到這個網段中的位址。此網段來自供效能測試使用的保留位址空間，並非目標網站的公網 IP，也不是代理伺服器位址。請勿手動將它設為網站的固定 IP。

Fake-IP 的重點不是偽造網站內容，而是在連線抵達核心前保留網域名稱。即使多個網站共用同一個 CDN 真實位址，也能透過各自的虛擬位址對應到不同網域，方便套用網域規則。

為何可能縮短 DNS 解析等待時間

回傳虛擬位址通常不必先等待目標網域的真實 A 記錄。若代理出站支援傳遞網域名稱，核心可將網域交由遠端處理，減少用戶端等待真實解析的環節。這只會省去部分前置等待，不代表所有連線都能略過 DNS。

  • 符合直連規則：本機通常仍須取得目標的真實位址，才能建立直連。
  • 符合 IP 類型規則：規則判斷可能需要先解析位址，實際情況取決於規則類型、順序，以及是否使用 no-resolve。
  • 代理節點使用網域名稱：節點本身也需要解析，無法透過目標網站的 Fake-IP 對應來解決。
  • 首次握手與遠端網路：TCP、TLS、節點負載及遠端 DNS 仍可能是主要耗時來源。

因此，DNS 查詢較快不代表網頁一定載入較快。請勿將節點延遲測試結果當成 DNS 耗時，也不要只憑瀏覽器首次開啟的體感判斷模式優劣。

redir-host：先回傳真實位址

使用 redir-host 時，內建 DNS 會查詢上游 DNS，並將真實解析結果回傳給應用程式。核心可利用 DNS 快取中的網域與位址對應關係，協助處理後續連線；但共用 IP、多個網域解析至同一位址等情況，會增加對應的不確定性。嗅探可提供額外的網域線索，但並非所有協定都能辨識。

此處的「真實位址」是指上游 DNS 回傳的位址，不保證一定可連線、效能最佳，或未受網路環境影響。上游選擇、分流 DNS、快取及出站路徑仍須分別檢查。

比較項目Fake-IPredir-host
應用程式收到的位址位址池中的虛擬位址；過濾項目除外上游回傳的真實解析位址
網域關聯方式主要透過虛擬位址對應可利用 DNS 快取及其他網域線索
回傳位址前的等待時間通常不必等待目標的真實解析結果通常需要真實解析結果或既有快取
應用程式相容性應用程式須能接受虛擬位址較接近一般 DNS 位址的行為
連線接管需求連線至虛擬位址後，必須回到核心處理真實位址本身不依賴虛擬位址對應

最精簡設定與 DNS 接管範圍

以下 DNS 片段用來說明欄位，並非完整的訂閱設定。它會在本機 127.0.0.1:1053 監聽、指定一個未加密的上游，並讓少數本地域名回傳真實解析結果。請依實際網路環境與隱私需求調整上游位址。

dns:
  enable: true
  listen: 127.0.0.1:1053
  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:
    - 223.5.5.5

listen 只會設定監聽位址，不會自動將系統 DNS 改為使用此服務。一般系統 DNS 設定通常只接受伺服器 IP，無法輸入連接埠；若欄位只接受 IP，就不能直接填入 127.0.0.1:1053。必須透過用戶端的 DNS 接管、TUN DNS 劫持或本機轉發，才能讓查詢抵達此監聽服務。

TUN 與系統代理的差異

TUN 用來接收系統路由送出的 IP 流量，DNS 增強模式則負責處理 DNS，兩者用途不同。TUN 設定中的 dns-hijack 可接管符合條件的 DNS 流量，例如常見的 any:53 設定適用於一般 DNS 請求；TCP DNS 則須依相應語法另行設定。即使劫持了 53 連接埠，443 連接埠上的 DoH 也不會自動成為內建 DNS 查詢。

若只啟用系統 HTTP 代理，部分應用程式會直接將目標網域交給代理，其他應用程式仍會在本機解析。此時看到真實 IP 不一定代表設定失敗。反之，若應用程式取得 Fake-IP，卻透過未接管的路徑直接連線至虛擬位址，就可能發生逾時。

fake-ip-filter：僅對必要網域設定例外

fake-ip-filter 用來控制哪些網域採用不同的位址回應方式，並非廣告過濾清單，也不是出站規則。在上述 blacklist 模式中，符合清單的網域不會取得 Fake-IP，而是回傳真實解析結果。若改用 whitelist，清單的涵義會反轉，不能直接沿用黑名單內容。

  • localhost 是精確網域名稱的範例。
  • +.lan 表示該網域及其子網域範圍，不是一般的字串包含比對。
  • +.home.arpa 可用於家庭網路內部網域，但仍須有能解析該網域的 DNS。
  • +.local 只會影響實際進入內建 DNS 的查詢；mDNS 通常使用 UDP 5353，多點傳播探索並不會由此清單完整處理。

將網域加入過濾清單，不會自動讓它直連。若要連線至區域網路服務，還須確認相應規則選擇 DIRECT、路由可抵達私有位址，並透過適當的 DNS 上游或 nameserver-policy 取得內部記錄。過濾清單只處理「回傳虛擬位址或真實位址」這個層面。

不建議只為了排除單一問題，就加入範圍過大的網域後綴，或直接讓所有網域回傳真實位址。請先從連線記錄找出實際失敗的網域，再新增範圍最小的例外。若訂閱中已有過濾項目，也要確認用戶端採用合併還是取代的覆寫方式。

不適合直接啟用 Fake-IP 的應用程式與網路

依賴真實 IP 的工具

網路診斷、IP 地理位置判斷，以及會將解析位址寫入存取控制清單的程式，可能會把 Fake-IP 當成伺服器的真實位址，導致結果失去原有意義。若要診斷真實位址，可針對目標網域使用真實解析，或在受控測試中切換至 redir-host。

區域網路探索與企業內部服務

NAS、印表機、投放裝置及企業內部網域，通常仰賴本機 DNS、多點傳播、廣播或專用路由。回傳真實位址只是必要條件之一。若企業 VPN 的分流 DNS、TUN 路由與私有位址範圍互相衝突，還須調整接管範圍，無法只靠過濾清單解決。

會將解析結果傳給其他裝置的程式

若程式在本機完成解析後，將位址傳給另一台裝置建立連線，另一台裝置通常沒有相應的 Fake-IP 對應。部分點對點、多媒體或控制類應用程式可能有此行為，但不能因此認定所有遊戲、影音或 UDP 應用程式都不相容。應根據實際網域、連線路徑及錯誤記錄判斷。

此外，使用硬編碼真實 IP 的應用程式不會查詢網域名稱，因此 Fake-IP 過濾自然不會生效。此時應檢查 IP 規則、UDP 支援、路由與防火牆，而非繼續新增網域例外。

驗證與排除問題：依序檢查查詢、對應與出站

  1. 確認執行中的設定：檢查目前載入的 Profile，以及最終生效的 dns.enhanced-mode。遠端訂閱更新可能會覆蓋直接修改的檔案，建議優先使用用戶端提供的持久覆寫機制。
  2. 直接測試監聽服務：若系統已安裝 dig，可執行以下指令，略過系統預設 DNS，直接查詢範例監聽連接埠。
  3. 檢查連線記錄：連線至同一網域，查看核心是否記錄到連線、是否正確對應網域、符合哪條規則，以及最終使用哪個出站方式。
  4. 檢查繞過用戶端的解析：若直接查詢正常，但應用程式行為不同，請檢查瀏覽器安全 DNS、應用程式內建 DoH、系統快取及其他 VPN。
  5. 逐項比對：先只為故障網域新增過濾項目；若仍無法解決，再與 redir-host 比較。每次只變更一個條件，並保留可還原的備份。
dig @127.0.0.1 -p 1053 example.com A

在上述 Fake-IP 設定中，未符合過濾條件的 A 記錄查詢應回傳位址池中的位址；切換至 redir-host 後，則應取得上游的實際解析結果。此指令只能驗證 DNS 監聽服務與回傳值，無法單獨證明 TUN 接管或代理出站正常。

切換模式後，應用程式可能仍保留先前的虛擬位址。Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取，但瀏覽器和應用程式的快取可能也需要重新啟動應用程式才能清除。若只清除對應資料，卻讓應用程式繼續使用舊的 Fake-IP，新連線仍可能失敗。

比較速度時，應維持相同的網路、節點、目標網域及出站規則，並分別記錄冷快取與暖快取的結果。例如每種模式各查詢 10 次，將首次結果獨立列出，再比較其餘結果的中位數。這是測試方法，並非本站的效能測量結論；DNS、建立連線及載入頁面應分開記錄。

模式選擇與設定保留

  • 優先考慮 Fake-IP：DNS 與業務流量能穩定進入同一個 mihomo 核心、需要明確的網域對應，且應用程式不依賴真實解析位址。
  • 優先考慮 redir-host：工作流程需要真實 IP、相容性優先，或目前的網路無法確保虛擬位址連線回到核心。
  • 採用局部過濾：大多數應用程式運作正常，只有少數內部網域或特定程式發生問題，且已確認需要真實位址。

若希望重新啟動後盡量保留對應關係，可檢查設定中的 profile.store-fake-ip。持久化可減少對應遺失造成的問題，但無法修正錯誤路由，也不保證切換設定、變更位址池或清除資料後，舊位址仍然有效。最終應確認執行中的設定、DNS 回傳值與連線記錄彼此一致。

下載Clash