#Fake-IP 模式原理詳解:DNS 應答機制、優缺點與 fake-ip-filter 設定

為什麼 DNS 模式會成為一道選擇題

一般網路環境裡,應用程式發起請求前會先做一次網域解析:系統把網域交給 DNS 伺服器,拿到一個真實 IP,再拿著這個 IP 去連接目標伺服器。Clash 要做基於網域的分流(比如「某類網站走代理,某類網站直連」),就必須在這一步插一手——問題是,分流規則裡寫的往往是網域(DOMAIN-SUFFIX、DOMAIN-KEYWORD),而底層網路連接用的是 IP。如果不做特殊處理,規則引擎在連接發生時只能看到一個裸 IP,想反查出它對應哪個網域、該符合哪條規則,並不總是可靠。

這就是 Clash Meta(mihomo)在 DNS 層提供多種模式的原因,其中最常用的兩種是 Fake-IP 和 redir-host(舊稱 fake-ip 之外的重新導向模式)。兩者本質上都在解決同一個問題:如何讓「網域規則」在「IP 層連接」發生時依然能對上號。只是走的路線完全不同,帶來的行為差異也不小。

Fake-IP 的運作機制

Fake-IP 的思路是:當應用程式查詢某個網域的 DNS 時,Clash 不去真正解析這個網域,而是從一個保留的私有網段(預設常見於 198.18.0.0/16)裡挑一個尚未分配的位址,立即回傳給應用程式,同時在內部維護一張「虛假 IP ↔ 真實網域」的對照表。

1. 應用程式查詢 example.com 的 A 記錄;
2. Clash 的 DNS 模組攔截這次查詢,分配一個 fake-ip(例如 198.18.0.23),並記錄「198.18.0.23 對應 example.com」;
3. 應用程式拿到 198.18.0.23,發起 TCP/UDP 連接;
4. 連接經過 Clash(無論是系統代理埠還是 TUN 虛擬網卡),Clash 查表還原出原始網域 example.com;
5. 規則引擎用還原出的網域去比對 DOMAIN 系規則,決定走哪個代理節點;
6. 確認策略後,Clash 再對真實網域發起實際解析(如果目標是直連節點)或直接把網域交給支援 SNI 的代理協定處理,建立真正的出站連接。

整個過程裡,應用程式感知到的是一次「秒回」的 DNS 應答——因為 Fake-IP 根本沒有走網路去問權威 DNS 伺服器,分配一個本地保留位址幾乎零延遲。這也是它相對 redir-host 最直接的優勢:DNS 查詢延遲幾乎為零,同時因為規則比對階段拿到的是完整網域而不是 IP,DOMAIN 規則的命中精確度也更高。

Fake-IP 與 redir-host 的差異

redir-host 模式走另一條路:Clash 會真的把網域解析成一個可用 IP 回傳給應用程式,但在代理轉發階段,透過讀取 HTTP Host 標頭或 TLS SNI 欄位重新識別出網域,再去比對規則。它的好處是應用程式拿到的始終是真實 IP,某些強依賴真實 IP 的場景(比如程式自己做 IP 白名單判斷)不容易出問題;代價是每次查詢都要發起真實解析,DNS 延遲被完整保留,而且對不帶明文網域資訊的協定(部分 UDP 應用、非標準埠流量)識別能力有限。

多數 Clash Meta(mihomo)核心的預設發行版都把 Fake-IP 設為預設或建議模式,尤其是搭配 TUN 模式使用時——TUN 接管了系統全部網路層流量,Fake-IP 的網域還原機制能更完整地覆蓋各類應用程式的連接請求,而不只是走系統代理埠的那部分流量。

Fake-IP 容易踩的坑

Fake-IP 不是沒有代價,以下幾類場景是社群回饋頻率較高的問題:

• 區域網路內網服務解析異常:如果 NAS、路由器管理頁面、區域網路印表機等裝置的網域也被 Fake-IP 接管,應用程式拿到的是虛假位址,一旦這條連接沒有經過 Clash(比如直接區域網路通訊、跳過了代理),連接就會失敗。
• 需要真實 IP 做驗證的程式:部分客戶端軟體會在應用層記錄、比對解析到的 IP(常見於某些企業 VPN 客戶端、憑證綁定驗證較嚴的服務),Fake-IP 回傳的虛假位址會讓這類驗證直接不通過。
• 基於 IP 的地理位置判斷出錯:如果某個程式自己拿 DNS 回傳的 IP 去做地區判斷(而不是走標準的網域連接流程),Fake-IP 的保留網段顯然不具備地理資訊,判斷結果會失真。
• 與某些 mDNS/區域網路發現協定衝突:區域網路裝置發現依賴真實網段內的位址廣播,被 Fake-IP 接管後裝置發現可能失效。

這些場景的共同特點是:網域本該走「直連、不受 Clash 分流影響」的通道,但因為落入了 Fake-IP 的預設接管範圍而出了問題。解決辦法不是關掉 Fake-IP,而是精確地把這些網域從接管範圍裡排除出去——這正是 fake-ip-filter 存在的意義。

fake-ip-filter 排除名單怎麼寫

設定項位於 DNS 設定區塊下,作用是宣告一批「即使處於 Fake-IP 模式,也不要偽造應答,直接走真實解析」的網域規則。寫法支援萬用字元,基本結構如下:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 8.8.8.8
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.market.xiaomi.com"
    - "time.*.com"
    - "ntp.*.com"
    - "*.msftncsi.com"
    - "www.msftconnecttest.com"

幾個常用寫法要點:

1. *.lan、*.local 這類萬用後綴用於排除區域網路裝置常見的本地網域後綴;
2. 路由器、NAS 管理面板如果用的是固定網域(比如廠商分配的 DDNS 網域),建議單獨加一行精確排除;
3. 系統層級連網偵測網域(如 Windows 的 msftncsi.com、msftconnecttest.com)保持真實解析,避免系統誤判「無網路連接」;
4. 時間同步(NTP)相關網域建議排除,部分客戶端對時間同步的回應延遲敏感;
5. 如果某個特定 App 的登入/驗證網域在使用中反覆出現連接異常,可以先把它單獨加進 filter 試一次,再判斷問題是否消失。

什麼情況該切回 redir-host 或直接關閉 Fake-IP

Fake-IP 對絕大多數使用場景是合適的預設選擇,尤其是搭配規則分流、TUN 模式使用時體驗更連貫。但如果遇到以下情況,可以考慮切換或調整:

• 整個網路環境高度依賴區域網路內多裝置的網域互通(家用 NAS 叢集、自建區域網路服務較多),排除名單維護成本已經高於收益;
• 使用的客戶端軟體明確要求「拿到的 DNS 結果必須是真實公網 IP」,且該軟體無法容忍 Fake-IP 網段;
• 只需要非常基礎的分流能力,對 DNS 延遲不敏感,更看重「所見即所得」的真實 IP 排查體驗(方便用 ping、nslookup 之類工具直接核對)。

切換方式很簡單,把 enhanced-mode 從 fake-ip 改成 redir-host 即可,不需要改動規則集本身,因為 DOMAIN 系規則在兩種模式下都能正常運作,差別只在底層的應答機制。

排查思路小結

遇到「某個網域連不上,但直連正常、代理規則看起來也沒問題」的情況,可以按下面順序排查:

1. 確認目前 DNS 模式(查看設定檔 enhanced-mode 欄位,或客戶端介面裡的 DNS 設定);
2. 如果是 Fake-IP 模式,檢查該網域或其所在網段是否本應走區域網路直連,卻未加入 fake-ip-filter;
3. 查看客戶端日誌或連接面板,確認這條連接的目標 IP 是否落在 fake-ip-range 宣告的網段內(預設多為 198.18.0.0/16);
4. 暫時把可疑網域加入 fake-ip-filter 後重啟核心測試,問題是否消失;
5. 仍未解決時,嘗試將 enhanced-mode 暫時切到 redir-host 做對照測試,縮小問題範圍。

理解 Fake-IP 的應答機制之後,大多數「DNS 相關的連接異常」都能歸結為「該網域要不要走 Fake-IP 接管」這一個問題,排查路徑會比一開始想像的清晰很多。