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

DNS 增強模式決定回傳哪種位址

Mihomo 的 dns.enhanced-mode 主要會影響內建 DNS 如何回覆查詢，以及後續連線如何對應網域。這不等同於代理模式，也不會決定所有流量是否經過代理。Rule、Global 與 Direct 是另一層設定；TUN 則負責接入系統流量。

先掌握核心差異：fake-ip 通常會回傳由核心配置的合成 IPv4 位址給應用程式；redir-host 則回傳上游 DNS 解析出的實際位址。兩種模式都需要正確的 DNS 接入路徑。只在設定中啟用 DNS，不代表系統或瀏覽器就會自動將查詢交給核心處理。

比較項目	Fake-IP	redir-host
應用程式取得的 IPv4 位址	通常是合成位址	上游解析出的實際位址
網域與連線的對應方式	透過合成位址映射還原	依賴 DNS 映射等資訊，必要時搭配嗅探
回覆查詢前的準備工作	可先配置位址，不必等待目標實際位址	通常必須先取得解析結果
常見相容性問題	應用程式驗證 IP，或位址未經核心處理	共用 IP 導致網域對應不唯一

Fake-IP 的連線流程與效能限制

合成位址並非目標伺服器的位址

常見設定會使用 198.18.0.1/16 作為 Fake-IP 位址範圍。此範圍位於保留供網路基準測試使用的 198.18.0.0/15 之內，並非可在公網正常路由的目標位址，也不是 RFC 1918 定義的私有位址範圍。核心會將配置的位址與查詢網域建立映射。

應用程式查詢某個網域的 A 記錄，查詢送到 Mihomo DNS。
核心為網域配置合成位址，並將位址回傳給應用程式。
應用程式嘗試連線至合成位址，連線必須再次經過保有映射的核心。
核心還原網域、比對規則，再透過選定的直連或代理出口建立連線。

合成位址無法脫離對應映射單獨使用。如果應用程式將位址交給未經核心處理的程序，或 TUN 沒有接管這段位址的流量，連線就可能失敗。關閉用戶端後，仍有程式存取 198.18.x.x，通常表示應用程式或系統仍快取著舊結果。

減少 DNS 等待時間，不代表所有連線都會變快

Fake-IP 可以將實際解析延後到有需要時才進行。若符合網域規則，且使用的代理協定支援傳遞網域，目標位址可能由遠端解析；若選擇 DIRECT，核心仍須取得實際位址。IP 類規則也可能觸發解析，因此規則結構會影響實際效益。

它主要減少連線前的部分 DNS 等待時間，不會直接縮短實際網路距離，也不會提高代理伺服器頻寬。遊戲延遲、影片傳輸速度與封包遺失率，仍取決於出口、路由與協定。本文未提供實測加速幅度，避免將解析階段的變化誤當成整體連線效能的結論。

適合使用 redir-host 的情況

使用 redir-host 時，應用程式會取得實際解析位址，核心則會維護 DNS 相關映射，協助識別連線所屬網域。這種方式較接近依賴實際 IP 的應用程式所熟悉的傳統網路行為，但網域對應不一定唯一：多個網域可能共用同一個 CDN 位址，同一網域也可能回傳多個位址。

適合優先嘗試的情況：應用程式需要檢查目標 IP、將位址傳給其他裝置，或在多個網路堆疊之間共用解析結果。
無法自動解決的情況：上游 DNS 回傳錯誤位址、無法連線至內網 DNS、UDP 出口無法使用，或連線根本沒有進入核心。
仍須留意的情況：應用程式內建加密 DNS，導致核心未能觀察到一般 DNS 查詢；此時網域規則可能缺乏比對依據。

嗅探可從部分 TLS、HTTP 或 QUIC 流量中補充網域資訊，但並非所有協定都能提供可用網域。加密方式、用戶端實作與嗅探設定都會影響結果。不要把啟用嗅探當成解決所有網域分流問題的萬用開關。

fake-ip-filter：只排除必要網域

fake-ip-filter 用來設定哪些網域不使用合成位址。在 blacklist 模式下，符合條件的網域會採用實際解析；未符合的網域仍可配置 Fake-IP。Mihomo 也支援其他過濾模式，因此檢視設定時應一併查看 fake-ip-filter-mode，不能只看清單名稱。

以下是 DNS 設定片段。監聽位址使用 127.0.0.1:1053，僅供本機存取；這不是完整的 TUN 設定，也不會自動變更系統 DNS。若現有設定已有 dns:，應合併欄位，避免重複的頂層鍵。

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

排除合成位址不等於直連

+.home.arpa 表示比對此網域及其子網域。這裡以此說明家庭網路網域的處理方式；.lan 則是部分區域網路採用的後綴。過濾清單只會改變 DNS 回覆方式，不會自動新增 DIRECT 規則，也不會自動將查詢送往路由器。

因此，存取內網通常必須同時滿足三個條件：回傳實際位址、向正確的內網 DNS 查詢，並將連線路由至可連通的內網出口。只做到第一項，公共 DNS 仍可能回覆找不到網域。

區域網路與企業內網的 DNS 設定

假設某個家庭網路使用 192.168.50.53 提供內網 DNS，裝置名稱為 nas.home.arpa。可在前述 dns: 區段中加入以下欄位。這個位址僅用來說明網路架構；實際套用前，必須換成目前網路可連通的 DNS 位址。

  nameserver-policy:
    '+.home.arpa':
      - 192.168.50.53

也應在既有的 rules: 中，將區域網路規則放在最終兜底規則之前。例如以下兩條分別涵蓋網域與範例網段；請勿因此覆蓋原有訂閱規則或刪除既有策略群組。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

最後一行假設設定中已存在名為 PROXY 的策略群組；實際名稱必須與現有設定一致。no-resolve 的作用是避免僅為這條 IP 規則主動解析網域，不會讓原本無法解析的內網網域變得可用。

企業 VPN 與 .local 名稱須分開處理

企業 VPN：確認通往內網 DNS 的路由經過企業 VPN。若 TUN 與企業 VPN 同時接管路由，請檢查網段衝突、路由優先順序，以及用戶端提供的略過設定。
短主機名稱：輸入 nas 可能需要依賴系統搜尋網域。請優先使用完整名稱進行測試，避免將缺少搜尋網域誤判為 Fake-IP 故障。
.local：通常用於 mDNS，常涉及 UDP 5353 與多點傳送。新增一般 DNS 過濾項目不代表 mDNS 已可正常運作；請檢查區域網路探索機制與多點傳送路徑。
跨網路切換：離開公司或家中網路後，原本的內網 DNS 可能無法連線。請保留依網域分流的範圍，避免將所有 DNS 查詢都交給內網伺服器。

選擇遊戲與 TUN 模式的步驟

一般網頁可以存取但遊戲無法登入，並不能直接證明 Fake-IP 不相容。遊戲可能同時使用 HTTPS 登入、UDP 對戰、語音與區域網路探索。系統代理通常無法涵蓋所有這些流量；TUN 可接入更多 IP 流量，但也需要適當權限、路由與 UDP 出口支援。

先確認連線是否進入核心。開啟用戶端的連線清單或記錄，再啟動遊戲。若完全找不到對應連線，應優先檢查接入方式，而非修改過濾清單。
區分登入與對戰。登入失敗時記錄驗證網域；進入房間後斷線，則檢查 UDP、出口策略與 NAT 行為。這兩類問題可能來自不同的網路路徑。
確認是否依賴實際位址。若記錄顯示特定網域取得合成位址後連線失敗，可只將該網域加入過濾清單，並維持出口與其他條件不變再測試。
最後比較不同模式。暫時切換至 redir-host，重新載入設定並清除快取。只有在相同網路、相同出口下進行比較，才有助於判斷模式相容性。

使用 TUN 時，請確認 DNS 劫持設定確實接管了實際查詢。一般 DNS 常使用 53 埠，但瀏覽器的 DoH 通常透過 HTTPS 的 443 埠傳送；只接管 53 埠無法攔截所有加密 DNS。需要測試時，可暫時關閉瀏覽器的安全 DNS，並記下原本設定，測試完成後再依需求恢復。

驗證結果與還原步驟

先驗證核心 DNS，再確認系統接入

若採用前述本機 1053 埠範例，可在已安裝 dig 的 macOS 或 Linux 環境執行以下指令。第一個指令用來確認一般網域是否取得合成位址；第二個則檢查內網網域是否由正確的 DNS 回傳實際位址。內網名稱應使用目前網路中確實存在的記錄。

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

這些指令會直接查詢指定埠，能確認核心 DNS 的回覆，卻無法證明系統與瀏覽器也正在使用它。接著還要在實際應用程式中發起連線，並核對用戶端記錄中的網域、目標位址、符合的規則與出口。若直接查詢正常、瀏覽器行為卻不同，請優先檢查瀏覽器 DNS、系統快取與應用程式快取。

切換模式後清除舊狀態

先備份目前設定，每次只修改 DNS 模式或一個過濾項目。
重新載入設定；若用戶端提供清除 DNS 快取或 Fake-IP 映射的功能，請依介面操作。
Windows 可使用 ipconfig /flushdns 清除系統 DNS 快取。
macOS 可執行 sudo dscacheutil -flushcache，再執行 sudo killall -HUP mDNSResponder；這些操作不保證能清除瀏覽器本身的快取。
完全結束並重新啟動受影響的應用程式，避免舊連線與舊位址影響比較結果。

日常依網域規則分流，且連線能完整經過核心時，可先使用 Fake-IP。遇到少數內網或應用程式相容性問題，優先依網域新增例外，並設定正確的解析器。只有在應用程式持續依賴實際 IP、例外難以維護，或比較測試明確顯示模式差異時，再考慮全面改用 redir-host。

若要繼續檢查接入路徑，請參閱連線檢查步驟；若要區分 DNS、規則與維護設定，請閱讀DNS 設定說明。判斷依據始終是查詢送往何處、回傳了什麼，以及最後由哪個出口處理連線。