Clash Fake-IP 模式原理詳解：與 Redir-Host 的差異及適用情境

Fake-IP 不是偽造公網目標，而是保留網域線索

應用程式存取網站時，通常會先查詢網域對應的 IP 位址，再向該位址建立 TCP 或 UDP 連線。傳統 DNS 流程會直接把真實位址交給應用程式，例如將 example.com 解析為某個公網 IPv4 位址。流量進入代理核心後，核心看到的目標往往只剩下這個 IP；如果規則以網域、GEOSITE 或網域後綴為條件，核心還必須依靠嗅探、DNS 對應紀錄或額外解析來還原網域。

Fake-IP 改變的是本機 DNS 回應這一段。mihomo 收到應用程式對網域的查詢後，會從保留位址池分配一個合成位址，預設常見範圍為 198.18.0.1/16，接著將「合成位址—原始網域」的對應關係儲存在核心對應表中。應用程式隨後連線至這個合成位址，流量經由 TUN、透明代理或受控網路堆疊回到核心，mihomo 查表即可得知原始目標網域。

應用程式查詢 www.example.com
        ↓
mihomo DNS 回傳 198.18.0.23
        ↓
應用程式連線 198.18.0.23:443
        ↓
mihomo 查詢對應表取得 www.example.com
        ↓
依網域規則選擇策略組與節點
        ↓
透過代理節點連線至真實目標

198.18.0.0/15 是供網路設備基準測試使用的保留位址段，不是網際網路網站實際使用的公網位址。mihomo 常使用其中的 198.18.0.1/16 作為 Fake-IP 位址池。合成位址只在本機代理鏈路中充當索引，不能直接傳送至一般閘道，更不能繞過核心後繼續路由。

Fake-IP 為何通常比 Redir-Host 更直接

Redir-Host 模式仍會將真實 DNS 結果回傳給應用程式。應用程式取得真實 IP 後發起連線，核心再根據現有 DNS 紀錄、流量中的主機名稱或嗅探結果對應網域。優點是網路行為接近一般系統 DNS，區域網路裝置、某些遊戲及只接受真實位址的程式較容易相容；代價是首次查詢必須等待上游 DNS 回應，網域與連線之間的對應關係也可能因快取、CDN 多個位址及並行請求而變得複雜。

Fake-IP 可以立即從本機位址池回應，不必先等待公網解析完成後再將結果交給應用程式。這裡所說的「省下一次解析」，準確來說是應用程式建立連線前不必等待真實位址解析，並不代表整條鏈路永遠不需要 DNS。若代理伺服器需要由本機解析節點網域，或最終對外連線需要取得目標 IP，mihomo 仍會依照 proxy-server-nameserver、nameserver 與策略設定完成解析。

一次請求中實際發生了什麼

1. 應用程式向系統 DNS 發出 A 或 AAAA 查詢，常見目標連接埠為 UDP 或 TCP 53。
2. 系統 DNS 流量會被送至 mihomo 的 DNS 模組，而不是未經控管地傳往路由器或電信業者 DNS。
3. mihomo 為網域分配 Fake-IP，並將對應關係寫入記憶體快取。
4. 應用程式連線至該位址，例如 198.18.0.23:443。
5. TUN 路由或透明代理規則會將連線交還給 mihomo。
6. 核心還原網域，依序比對 DOMAIN-SUFFIX、規則集、程序規則等。
7. 選定 DIRECT 或代理策略後，核心才會執行對應的真實對外連線。

mihomo Fake-IP 基礎設定與欄位說明

使用核心設定時，可以在 YAML 的 dns 區段啟用 Fake-IP。圖形化用戶端若提供覆寫入口，通常需要先進入「設定」→「設定檔」或「設定」→「參數設定」，再找到 DNS 或全域擴充設定。不同用戶端的選單名稱會隨版本變更，最終應以實際產生並交由 mihomo 使用的 YAML 為準。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

基礎欄位各自控制什麼

• enable：啟用 mihomo 內建的 DNS 模組。只寫入 enhanced-mode、但 DNS 模組未運作時，應用程式查詢仍可能繞往系統上游。
• listen：DNS 監聽位址與連接埠。範例使用 1053，可避免一般使用者權限直接佔用 53。部署於路由器時，還要讓 dnsmasq 將請求轉送至該連接埠。
• enhanced-mode: fake-ip：對符合條件的網域回傳合成位址。切換為 redir-host 後，則會回傳真實解析結果。
• fake-ip-range：合成位址池。修改後要同步檢查 TUN 路由、防火牆與旁路由策略，確保整個位址段都導入 mihomo。
• default-nameserver：通常填寫可直接存取的 IP 位址，用來解析 DoH 或其他 DNS 伺服器本身的網域，避免解析鏈形成迴圈。
• nameserver：一般網域解析上游。實際請求是否經由代理，也會受到 DNS 跟隨策略與對外連線設定影響。
• proxy-server-nameserver：專門處理代理節點伺服器網域。節點位址使用網域時，這個欄位可以將節點解析與一般目標解析分開。
• fake-ip-filter-mode: blacklist：清單中的網域不使用 Fake-IP，而是回傳真實結果。若改用白名單邏輯，清單含義會反轉，移轉設定時務必一併檢查。

fake-ip-filter 應過濾哪些網域

fake-ip-filter 的目的不是排除所有常用網站，而是讓必須取得真實位址的查詢回到真實解析流程。過濾範圍過大，會逐漸失去 Fake-IP 快速對應網域的價值；範圍過小，則可能讓區域網路探索、時間同步、登入偵測或即時通訊取得無法直接使用的合成位址。

區域網路主機與本地域名

NAS、印表機、路由器管理頁面與家庭自動化裝置常使用 .lan、.local 或自訂的內部後綴。若裝置回傳 192.168.1.20，應用程式通常需要直接連線至這個真實的區域網路位址。請將對應後綴加入過濾清單，並確保本地 DNS 伺服器能夠回應這些名稱。

.local 也經常搭配 mDNS 使用，而 mDNS 採用多點傳送位址與 UDP 5353，並不等同於一般單播 DNS。僅新增過濾規則未必能解決跨網段探索問題；VLAN、無線訪客網路與旁路由環境還要檢查多點傳送轉送及防火牆邊界。

STUN、遊戲與即時通訊

部分遊戲、語音通話與 WebRTC 程式會透過 STUN 判斷公網出口與 NAT 類型。這類程式可能直接將 DNS 回傳值用於 UDP 探測，或核對伺服器回傳的候選位址。若啟用 Fake-IP 後出現語音能連線卻沒有聲音、房間配對後斷線，或 NAT 類型從開放變為嚴格，可以先針對相關 STUN 網域進行過濾，而不是立即將全部 DNS 切回 Redir-Host。

遊戲加速也不能簡單歸類為「必須關閉 Fake-IP」。許多基於 HTTPS 登入、內容下載與網域分流的遊戲啟動器都能正常使用 Fake-IP；真正需要留意的是遊戲本體是否依賴 UDP、是否固定驗證伺服器位址，以及相關流量是否由 TUN 完整接管。排查時應分開測試啟動器登入、資源下載、配對服務與即時對戰。

網路探測、時間同步與裝置登入

• 系統連線能力檢測網域可能依據特定狀態碼或固定位址，判斷是否需要開啟認證頁面。
• NTP 通常使用 UDP 123，部分裝置會直接驗證回傳位址，或繞過系統代理。
• 智慧電視、遊戲主機與物聯網裝置可能只接受真實 A 記錄，而且不會將後續流量送入電腦上的 mihomo。
• 企業內部網域可能採用分區 DNS，同一網域在公司網路與公網回傳不同結果，應交由指定的內部 DNS 處理。

過濾應依照故障網域逐項新增，並記錄新增原因。可維護的清單通常包含本地域名、已確認存在相容性問題的服務網域及必要的探測網域，而不是複製數百條來源不明的規則。

TUN 模式下 Fake-IP 能否運作，取決於接管是否完整

Fake-IP 回傳的位址不具備公網路由意義，因此應用程式連線必須進入 mihomo。桌面用戶端啟用 TUN 後，核心通常會建立虛擬網卡並寫入路由；路由器透明代理則可能依賴策略路由、nftables 或 iptables。只開啟 DNS 增強模式，卻沒有接管 198.18.0.0/16，常見結果就是網域解析很快，但網頁始終逾時。

需要同時檢查的四條鏈路

1. DNS 查詢鏈路：應用程式查詢是否真的抵達 mihomo。瀏覽器內建的安全 DNS、Android 私人 DNS 與區域網路手動 DNS 都可能改變路徑。
2. Fake-IP 路由：198.18.0.0/16 是否指向 TUN 或透明代理處理鏈，而非預設閘道。
3. 規則比對：連線還原出的網域是否命中預期規則，最終策略組是否選到可用節點。
4. 實際對外連線：節點網域、目標網域及 IPv4、IPv6 路徑是否能正確解析與存取。

如果系統啟用了 IPv6，而設定只接管 IPv4，應用程式可能優先使用 AAAA 結果，改走另一條路徑。測試階段可以暫時設定 ipv6: false 以縮小範圍，確認 IPv4 Fake-IP 鏈路正常後，再補齊 IPv6 路由與 DNS 策略。長期使用時應根據本地網路是否具備穩定的 IPv6 對外連線來決定，而不是只靠關閉選項掩蓋路由問題。

用具體指令驗證 Fake-IP 與規則命中

不要只根據網頁能否開啟來判斷設定。先直接查詢 mihomo 的 DNS 監聽連接埠，再查看系統路由與核心記錄。以下範例假設 DNS 監聽於本機 1053，混合代理連接埠為常見的 7890。

nslookup www.example.com 127.0.0.1
dig @127.0.0.1 -p 1053 www.example.com A
curl -x http://127.0.0.1:7890 https://www.example.com/

若 dig 回傳 198.18.x.x，表示該網域已進入 Fake-IP 流程。若回傳真實公網位址，請檢查網域是否命中 fake-ip-filter、目前執行中的設定是否仍為 redir-host，以及查詢是否確實送往設定中的監聽連接埠。

本機查詢的回應時間通常應落在毫秒等級。在相同裝置與相同網路環境下，可以連續執行 10 次查詢並比較首次回應：例如 Fake-IP 本機回應約為 2 至 8 毫秒，而真實 DoH 首次查詢可能需要 30 至 150 毫秒。數值會受到裝置效能、上游距離與快取影響，重點是比較同一環境中的差異，不應將某個固定延遲視為通用標準。

常見故障與排查順序

哪些情境適合啟用，哪些情境先使用 Redir-Host

優先考慮 Fake-IP 的情境

• 桌面端使用 TUN 接管大多數應用程式，希望網域規則穩定命中。
• 訂閱中包含較多網域規則、規則集及依網域劃分的策略組。
• 本機上游 DNS 首次查詢延遲明顯，希望縮短應用程式等待真實解析的時間。
• 需要代理不遵循系統代理設定的應用程式，而且 TCP、UDP 都由 mihomo 管理。
• 願意依照區域網路、遊戲與即時通訊狀況維護精確的過濾清單。

先使用 Redir-Host 較穩妥的情境

• 裝置只將 DNS 交給 mihomo，但實際連線沒有經過 TUN 或透明代理。
• 企業內網大量依賴分區 DNS、固定真實位址與內部安全設備。
• 區域網路中有許多舊裝置，應用程式行為無法觀察，也無法逐項維護過濾網域。
• 正在排查 UDP、遊戲或裝置探索故障，需要先建立接近一般 DNS 的對照組。
• 現有路由規則無法保證 198.18.0.0/16 始終回到 mihomo。

兩種模式不是核心新舊之分，而是不同的 DNS 接管策略。mihomo 接替舊版 Clash Meta 核心後，持續擴充 DNS、規則集與 TUN 能力，但模式選擇仍應依循網路拓撲。桌面單機、旁路由、主路由與容器環境的 DNS 入口各不相同，同一份設定直接複製過去，不一定會得到相同結果。

移轉與調整時的實用順序

從 Redir-Host 切換至 Fake-IP 時，建議先保留原有代理規則與節點，只修改 DNS 增強模式，避免同時改變多個變數。載入設定後，先查詢三個目標：一般公網網域、區域網路網域，以及已知需要過濾的網域。公網網域應取得合成位址，後兩類則應依設計回傳真實位址。

1. 備份目前可用的設定，記錄 DNS 監聽連接埠、TUN 開關與系統代理連接埠。
2. 啟用 enhanced-mode: fake-ip，保留預設位址池或明確規劃自訂範圍。
3. 確認系統路由完整涵蓋 Fake-IP 位址段。
4. 先加入 *.lan、*.local 等明確的本地過濾項目。
5. 分別測試瀏覽器、即時通訊、遊戲、NAS 與電視盒，不要只測試一個網站。
6. 根據記錄新增最小範圍的過濾規則，並在每條規則註明對應故障。
7. 清理過期的過濾項目，避免清單不斷擴大後退化成近似 Redir-Host。

如果切換後出現許多問題，回到 Redir-Host 作為對照，是有效的工程排查方式。確認故障只在 Fake-IP 下出現後，再檢查 DNS 入口、位址池路由、過濾清單與 UDP 接管。沿著鏈路逐層定位，比反覆更換訂閱、節點或整份設定更容易找出真正原因。