先釐清：DNS 增強模式不等於代理模式

dns.enhanced-mode 決定核心如何處理 DNS 查詢，以及如何將後續連線對應至網域；mode: rule 則決定連線如何分流。兩者是不同的設定。選用 Fake-IP，不代表所有流量都會經過代理；選用 redir-host，也不代表連線一定會直連。

本文以 Clash Meta（現稱 mihomo）的常見設定欄位為例。舊版 Clash 與不同用戶端支援的功能可能有所差異，修改前請先在用戶端的核心資訊中確認目前使用的核心。圖形介面中的選項也可能覆寫設定檔，因此應以核心實際載入的設定為準，而不只是查看訂閱原始內容。

  • DNS 層：處理網域查詢，並回傳位址給應用程式。
  • 流量入口：透過系統代理、TUN 或路由器透明代理接管連線，並將流量送至核心。
  • 規則層：依照 rules 的順序，選擇直連、代理群組或拒絕連線。

Fake-IP 必須搭配流量接管。應用程式取得合成位址後，如果連線沒有回到持有對應映射的核心，就無法依預期連線至目標。

Fake-IP 原理：先回傳合成位址，再依網域建立連線

假設應用程式查詢 www.example.com。在 Fake-IP 模式下，核心可從設定的位址池分配一個合成 IPv4 位址，並儲存「合成位址 → 網域」的對應關係。應用程式接著連線至該位址，核心接手連線後找回原始網域，再套用分流規則。

  1. 應用程式將 DNS 查詢交給 Clash 或 mihomo 的 DNS 服務。
  2. 核心回傳位址池中的位址，例如 198.18.0.2；實際分配結果不固定。
  3. 應用程式向該位址發起連線，再由 TUN 等入口將連線送回同一個核心。
  4. 核心還原網域、比對規則，再透過選定的出口建立實際連線。

為什麼常見位址以 198.18 開頭

198.18.0.0/15 是供網路設備效能測試使用的特殊用途位址範圍，並非目標網站的公網位址。設定中常見的 198.18.0.1/16 就位於此範圍內，也不是一般家用區域網路常用的 RFC 1918 私有位址範圍。若企業網路或測試環境也使用相同範圍，請先檢查是否有路由衝突。

解析更快，不代表所有查詢都免除解析

對於可使用 Fake-IP 的查詢，核心通常不必等到取得目標的真實位址，就能先回傳合成位址給應用程式。這能縮短應用程式在 DNS 階段的等待時間，也能保留明確的網域資訊。不過，直連出口最後仍須取得真實位址；代理出口是否在遠端解析，則取決於節點協定與連線方式。首次載入網頁也會受到交握、線路及伺服器回應影響，無法保證固定的提速幅度。

redir-host 的差異：回傳真實位址，適用於依賴 IP 的應用程式

redir-host 會透過上游 DNS 查詢真實位址並回傳給應用程式，同時利用 DNS 查詢紀錄維護網域與位址的關聯。後續連線進入核心時，可運用這些關聯輔助比對網域規則。不過，若多個網域共用同一個位址、應用程式使用獨立 DNS，或 DNS 快取來源不同，網域與位址的關聯就可能不夠明確。

比較項目 Fake-IP redir-host
應用程式收到的位址 位址池中的合成位址，排除項目除外 上游 DNS 解析出的真實位址
DNS 回應等待時間 通常可先回傳合成位址 需要取得真實解析結果或使用既有快取
網域關聯方式 透過合成位址映射還原網域 依賴 DNS 紀錄等資訊輔助關聯
常見相容性問題 應用程式檢查真實 IP，或合成位址未經流量接管 解析結果不合適，或網域關聯不完整
適合優先嘗試的情境 流量接管完整的日常瀏覽與規則分流 依賴真實解析結果的工具，或相容性疑難排解

redir-host 不是「隱私模式」，Fake-IP 也不會自動確保所有 DNS 查詢都經過代理。是否使用 DoH、DoT、上游查詢從哪個出口送出，以及應用程式是否繞過系統 DNS，都是不同的問題。啟用瀏覽器安全 DNS 後，查詢可能不會進入核心的 DNS 服務；不要只憑 enhanced-mode 的值，就判定是否發生 DNS 洩漏。

Fake-IP 設定：先確認 DNS 入口，再設定過濾清單

以下是用來說明欄位關係的 mihomo DNS 設定片段，請合併至既有且可正常使用的設定中；這不是包含節點與規則的完整設定檔。如果原檔已有 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
    - 119.29.29.29
  • listen：本例只在本機迴圈位址的 1053 埠接收查詢，不會自動變更系統 DNS，也不會對區域網路裝置開放監聽。
  • enhanced-mode：設為 fake-ip 才會啟用此增強模式。
  • fake-ip-range：指定合成位址池。這不是代理節點位址，也不是 DNS 上游位址。
  • fake-ip-filter：本例採用預設的黑名單語意，符合項目會改為回傳真實解析結果。
  • nameserver：此處以兩個明確的傳統 DNS 上游為例，請依所在網路的連線狀況與隱私需求調整。

部分新版 mihomo 支援透過 fake-ip-filter-mode 變更過濾邏輯。若現有設定明確使用 whitelist，清單的意義就會相反，不能直接套用本文的排除清單。移轉至其他核心前，請先確認欄位支援狀況。

fake-ip-filter 只會決定 DNS 是否回傳合成位址，不等於新增 DIRECT 規則。需要直連的目標，仍須在 rules 中設定適當的分流規則。

請分開理解 TUN 的 DNS 劫持與監聽埠

支援相關欄位的 mihomo 設定，可透過 tun.dns-hijack 將一般 DNS 流量交由核心處理。例如，下方片段表示接管 UDP 與 TCP 的 53 埠查詢；這不代表能直接解密應用程式自行使用的 DoH。TUN 的啟用權限、路由與用戶端覆寫設定仍須另外確認。

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

不要將這段設定與系統代理視為相同的流量入口。瀏覽器使用 HTTP 代理時，可能會直接將網域交給代理，不一定透過本機 DNS；TUN 則通常需要接管應用程式先解析、再連線至 IP 的完整流程。

遊戲、區域網路裝置與 fake-ip-filter 的適用範圍

區域網路 NAS、印表機：先確保本機網域能正確解析

如果路由器透過一般 DNS 提供 nas.home.arpa，可將此名稱加入排除清單，讓查詢交由實際持有該筆紀錄的路由器 DNS 處理。假設路由器位址確實是 192.168.1.1，可在原有的 DNS 區段中合併以下項目：

  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '*.local'
    - 'nas.home.arpa'
  nameserver-policy:
    'nas.home.arpa':
      - 192.168.1.1

此處的路由器位址必須符合目前網路的設定。過濾清單不會自動建立本機 DNS 紀錄。若直接透過 192.168.1.20 存取 NAS，就不會進行網域查詢；修改 Fake-IP 過濾設定通常沒有幫助，應改查私有網路路由、TUN 排除設定與防火牆。

.local 也常用於 mDNS 裝置探索。將 *.local 加入過濾清單，不會自動轉送 mDNS 多點傳播，也無法修復跨網段的印表機探索問題。請分開排查「找不到裝置」與「已知位址卻無法連線」這兩種情況。

遊戲與語音：只排除異常網域，不要整類流量都改為直連

部分遊戲、語音或連線測試工具會檢查 DNS 回傳的位址，或將解析結果交給另一台裝置使用。這類流程可能不適合合成位址。請先從記錄中找出登入、配對、語音或 STUN 相關的實際查詢網域，再將確切名稱加入過濾清單；不要只憑服務名稱猜測一長串網域。

  • 登入正常，語音無法使用：同時檢查節點的 UDP 支援、UDP 分流與 NAT 條件；DNS 過濾無法補足 UDP 支援。
  • 只有某項測試失敗：先只排除該測試使用的網域，保留其他流量的 Fake-IP 行為。
  • 手機透過電腦共享代理：確認手機連線至合成位址時，流量仍會經過建立映射的電腦核心；只將 DNS 指向電腦並不足夠。

不建議直接加入 '*' 來「解決所有相容性問題」。採用黑名單語意時，這會讓所有符合條件的查詢都避開 Fake-IP，失去原有的位址映射機制，也會讓後續難以判斷究竟是哪個項目造成問題。

切換模式後的檢查步驟與常見誤判

  1. 先備份，每次只調整一個變數。先儲存目前的設定，只變更 DNS 模式或一個過濾項目；不要同時修改節點、規則與 TUN 路由。
  2. 重新載入設定。檢查記錄中是否出現 YAML 縮排錯誤、未知欄位或埠被占用等問題；若載入失敗，核心可能仍在使用舊設定。
  3. 檢查 DNS 回應。可使用下方指令查詢本文的監聽位址，確認請求確實送到核心。
  4. 清除舊的解析狀態。關閉後重新開啟目標應用程式，必要時清除系統 DNS 快取；修改檔案不會立即清除既有連線或應用程式自己的快取。
  5. 檢查實際連線狀況。在用戶端的連線紀錄中查看目標網域、符合的規則與出口，再判斷問題發生在解析、分流還是連線階段。
dig @127.0.0.1 -p 1053 www.example.com A

# Windows PowerShell：清除系統 DNS 快取
Clear-DnsClientCache

# Windows 命令提示字元：相同操作
ipconfig /flushdns

dig 必須先在系統中安裝相應工具。此指令會明確指定 1053 埠；直接執行一般的 nslookup，通常測試的是系統設定的 DNS，不一定是本文的監聽服務。Fake-IP 模式下，未列入過濾的網域若回傳位址池中的 A 記錄，屬於正常現象，不應視為公網解析遭到竄改的證據。

切換成 redir-host 後，為什麼仍連線至 198.18 位址？

常見原因是應用程式仍保留舊位址，或用戶端尚未將新設定套用至核心。請先確認實際運作模式，再關閉舊連線、清除快取後重試。如果重新啟動核心導致 Fake-IP 映射遺失，而應用程式仍持有舊的合成位址，也可能造成連線失敗；支援此功能的核心可透過 profile.store-fake-ip 保存映射，但這無法取代正確的流量接管。

IP 類型規則是否仍然有效？

Fake-IP 不代表停用 IP 規則。核心在需要時可以解析目標的真實位址，以完成相關比對；實際結果也會受到規則順序、快取及 no-resolve 等參數影響。不要用合成位址直接判斷目標所在區域，也不要替整個 Fake-IP 位址池新增直連規則來修復網站連線。

選擇建議：日常使用以穩定為先，局部處理相容性問題

日常瀏覽網頁、流量入口明確且 DNS 查詢能進入核心時，可先嘗試 Fake-IP。若只有 NAS、遊戲登入或特定測試出現異常，優先加入少量且有依據的過濾項目，並搭配正確的本機 DNS 與規則。只有在應用程式確實依賴真實位址，或目前環境難以完整接管合成位址流量時，再改用 redir-host 進行對照測試。

判斷依據不該只有 DNS 查詢耗時，而是目標應用程式能否穩定完成整個流程：網域解析、規則比對、建立連線與傳輸資料。保留一份可正常使用的設定，並記錄修改欄位與重現步驟，比反覆同時切換多個選項更容易找出問題。初次設定可先閱讀訂閱匯入與設定教學；遇到連線異常，再查閱疑難排解手冊。