Clash Meta：fake-ip 與 redir-host 怎麼選？DNS 與分流對齊實戰（2026）

1. 為什麼故障長得像「規則壞掉」：DNS 與規則各自看到什麼

Clash Meta 的規則（DOMAIN、DOMAIN-SUFFIX、GEOIP 等）本質上是在連線建立前後，盡力替你決定「這一筆流量要進哪個策略組」。但應用程式與作業系統往往先做一次 名稱解析：解析走誰（ISP、公共 DNS、瀏覽器 DoH、或 Clash 內建 DNS）會直接影響「你看到的主機名／IP」與「核心實際用來比對規則的線索」是否一致。

在 fake-ip 模式下，客戶端常先拿到一個本機池的臨時位址，真正的解析與出口決策延後到連線階段再做；好處是依網域名稱拆流通常比較直覺。相對地，若你同時開著瀏覽器安全 DNS、系統加密 DNS或訂閱裡另一套 dns: 片段，資訊就容易分裂成「表面上解析成功，規則卻對不到你想像的那條」。這也是為什麼我們會建議在調 mihomo 前先讀 Windows 上關閉瀏覽器安全 DNS 並校準系統代理：先把場外選手請出擂台，比較不會誤判成「規則集寫錯」。

redir-host（或你慣稱的 redir-host 類行為）則較偏向讓解析結果更貼近傳統「先解析、再連線」的模型：應用程式看到的 IP 往往就是（或更接近）上游解析器回來的答案，規則若高度依賴 GEOIP 或 實際位址所屬區域，行為會與 fake-ip 時期截然不同。兩者沒有絕對優劣，只有與你的規則風格、客戶端是否繞過本機 DNS、以及是否啟用 Sniffer 的組合是否合拍。

2. fake-ip 與 redir-host：行為差異與適用情境

下面用「使用者在乎的結果」來談取捨，而非逐行搬原始碼術語。寫設定時請以你實際使用的 Clash Meta 核心版本與 GUI 顯示名稱為準，本節描述的是社群設定裡最常遇到的兩種故事線。

• fake-ip：有利於把「同一個網域家族」集中丟進指定策略組，對大量使用 DOMAIN-SUFFIX、訂閱規則集的使用者較友善；但若 fake-ip-filter 漏寫、或應用程式硬要自解釋名稱，就可能出現「規則上看到 A、連線實際走 B」的錯覺。
• redir-host：對「必須先知道真實目的地位址」的舊客戶端或某些憑 IP 判區的服務，有時比較不易踩雷；代價是你對 nameserver 品質與DNS 洩漏要更有意識——上游回錯答案，後面整條分流都會跟著歪。

若你正在處理「訂閱更新 SSL 錯誤、特定 API 主機 TLS 握手怪異」這類議題，可以先對照 Windows 訂閱更新與 TLS／DNS 日誌：那條路徑和「網頁瀏覽」不完全相同，但同樣需要 dns: 區塊與 nameserver-policy 各司其職，而不是只靠換節點。

3. 分流失效對照：症狀、常見成因、先查哪一段設定

以下整理實務上最常收到的回報，刻意用「可觀測現象」寫，方便你對照自己的 mihomo 日誌與客戶端畫面。

若你關心的是「特定雲服務／AI 站台」如何把網域與 DNS 寫進同一份專題，亦可交叉閱讀 Claude 與 Fake-IP DNS：該文以單一平台示範「名稱解析與規則必須同一批次檢查」的方法論，與本篇一般化框架互補。

4. YAML 骨架：dns 區塊與 enhanced-mode 實務注意點

實際鍵名請以你的設定為準；下面是教學用骨架，註解一律使用英文以利版本控管。重點在於：enable、enhanced-mode、nameserver、fallback、nameserver-policy 必須成套思考，而不是只改一行就期待奇蹟。

dns:
  enable: true
  listen: 0.0.0.0:1053  # example; align with your OS resolver / forwarding
  enhanced-mode: fake-ip  # or redir-host — pick one story per debugging session
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - tls://1.1.1.1
  fallback:
    - https://dns.cloudflare.com/dns-query
  # Route sensitive domains away from polluted paths:
  nameserver-policy:
    'geosite:cn':
      - https://doh.pub/dns-query

5. mihomo 日誌怎麼讀：把「主機名／IP／策略」對回同一筆連線

分步排查時，請強迫自己回答三個問題：① 客戶端以為自己在連哪個 主機名？② 核心在規則匹配時手上有什麼線索（網域名稱、位址、行程）？③ 最後被送進哪個策略組與節點？三者對不起來，就不要先換節點。

實務上可以從「重現問題的單一網域」開始：先在 GUI 或外部 API 面板把日誌級別調到能看見規則命中，再對照瀏覽器 Network 裡的 Host。若你發現日誌裡出現的主機名與規則表達式永遠差一個子域，通常要先改規則表達式或規則順序，而不是改 DNS 模式；反之，若命中策略正確、但連線仍行為怪異，再回頭改 dns: 或考慮 Sniffer。

想從頭建立「規則優先序」直覺，可讀 高級規則分流指南，把「遠端規則 provider 合併後實際順序」畫在紙上；當列表一排開，你會更容易看出是誰提早把流量喂進 MATCH。

6. 修復步驟：可重現的操作順序（含切模式與清快取）

請把下列步驟當成實驗清單，而不是「每一步都做了就一定能好」的咒語；目的是在最少變因下定位問題層級。

1. 凍結變因：同一組規則、同一顆節點、同一個瀏覽器分頁，只改 DNS 故事，避免「同時改規則又改節點」。
2. 關掉場外解析：暫時關閉瀏覽器 DoH、作業系統加密 DNS，與其他本機 AdGuard／安全軟體內建解析攔截；必要時參考前述 Windows 瀏覽器篇。
3. 單一路徑驗證：在 fake-ip 與 redir-host 之間做一次有計畫的切換，每次都重新載入核心、清快取，觀察日誌差異而不是只看網頁表象。
4. 校對 fake-ip 例外：若堅持 fake-ip，檢查 fake-ip-filter 是否涵蓋了必須看真實位址的網段或網域（例如部分內網或特定套餐要求）。
5. 校對 nameserver-policy：確認「國內／國外」或「汙染敏感」網域沒有被錯配到會回傳意外答案的上游。
6. 引入 Sniffer 之前先寫假說：若懷疑 HTTPS／QUIC 客戶端帶的主機資訊與網域規則脫鉤，再開啟 Sniffer 相關段落，並用專文對照參數語意，避免一次開太多外掛式功能讓變因爆炸。

完成後請把「最後一份可行組合」記錄下來：包含 enhanced-mode、是否啟用 Sniffer、關鍵網域走哪個 nameserver-policy。日後訂閱範本更新時，你才能迅速 diff 出是誰又塞了一行覆寫。

7. 與 Sniffer／SNI 的銜接（上下篇分工）

當你發現「規則寫的是網域 A、TLS 交握裡卻是別的主機別稱或 CDN 邊緣」時，單靠改 fake-ip／redir-host 可能仍不足；此時需要的是把連線層觀測到的名稱與規則對齊。這正是 Clash Meta Sniffer 與 HTTPS／SNI 日誌那篇的戰場：本篇刻意停在「DNS 模式與解析路徑」層級，把 Sniffer 當成下一層工具鏈，避免兩篇互相複製同一長段截圖。

若你的主要痛點是「服務商看 IP 判區」或「固定節點需求」，請回到平台專題文；本篇只負責讓你在開啟那些進階選項之前，先確認 DNS 模式沒有讓規則形同虛設。