進階技巧 · 預計閱讀 8 分鐘

Fake-IP 模式是什麼:DNS 劫持原理、優缺點與適用情境解析

從 DNS 解析流程講清 Fake-IP 模式的運作原理:為何回傳保留段假位址、如何降低解析延遲,以及區域網路服務、遊戲連線等情境下需要設定 fake-ip-filter 的原因。

為什麼代理軟體要插手 DNS 解析

正常上網時,裝置存取一個網域要先經過一次 DNS 解析:系統把網域交給 DNS 伺服器,取得一個真實 IP,再用這個 IP 建立連線。問題在於,Clash 這類基於規則做分流的代理工具,很多分流策略是按網域比對的——比如按 GeoSite 規則判斷某個網域該走代理還是直連。如果代理軟體對 DNS 解析完全不插手,只在收到連線請求時看到一個裸 IP,就沒法反查出這個 IP 對應的網域,規則裡寫的網域比對條件也就形同虛設。

為了解決這個問題,Clash/mihomo 核心提供了幾種 DNS 處理模式,Fake-IP 是其中預設且最常用的一種。它的思路簡單直接:客戶端查詢網域時,不把真實 IP 交給應用程式,而是回傳一個核心自行編造、外界從未真正分配過的假位址,同時在核心內部記住這個假位址對應哪個網域。等應用程式真正發起連線時,核心再用記住的網域做規則比對,該走代理就走代理,該直連就直連,整個過程對上層應用程式完全透明。

Fake-IP 模式的運作原理:保留位址段與映射表

Fake-IP 回傳的位址並不是隨機亂編的,而是從一段專門劃分出來、不會被任何真實網路路由到的私有位址段裡分配,常見設定中預設使用 198.18.0.0/16 這類保留段。這段位址在公網上不會被實際使用,核心把它當作「臨時門牌號」來用,具體流程大致如下:

  1. 應用程式發起 DNS 查詢,請求解析某個網域;
  2. Clash/mihomo 的 DNS 模組攔截這次查詢,不去問真實的上游 DNS 伺服器要位址,而是從保留位址池裡取一個尚未使用的假 IP;
  3. 核心在記憶體裡維護一張映射表,記下「假 IP ↔ 網域」的對應關係,並把這個假 IP 回傳給應用程式;
  4. 應用程式拿著假 IP 發起連線,核心在連線建立階段查表,還原出真實網域,再依規則集判斷走哪條策略、走哪個代理節點;
  5. 如果規則判定要走代理,核心直接把網域交給代理節點端去解析和連線,真實 IP 解析這一步被推遲到了連線的另一端。

這套機制帶來的直接好處是解析延遲明顯降低——因為大多數情況下核心根本不需要真的去問一次上游 DNS,只是從本機位址池裡發一個假位址,回應幾乎是瞬時的。同時因為網域資訊全程保留在核心裡,基於網域的分流規則可以精確生效,不會退化成「只能按 IP 段猜測」的粗略比對。

要點Fake-IP 回傳的位址只在本機代理程序內部有意義,一旦離開這台裝置(比如被其他程式記錄、轉發給別的機器),這個假位址就毫無用處,因為它從未被真正分配和路由。

Fake-IP、Redir-Host 與正常解析模式的取捨

除了 Fake-IP,核心通常還支援另外兩類 DNS 處理方式,理解它們的差異有助於判斷自己的情境該選哪個:

  • Fake-IP 模式:如上所述,回傳假位址,核心內部按網域做規則比對。優點是延遲低、網域比對精確;缺點是假位址不能直接用於需要真實 IP 的情境,比如某些應用程式會把解析到的 IP 快取起來做健康檢查或直接顯示。
  • Redir-Host 模式:同樣依賴回傳給應用程式的位址來觸發規則判斷,但更偏向按目標埠做重定向轉發,實作細節和適用範圍比 Fake-IP 更受限,目前主流客戶端已較少將其設為預設選項。
  • 正常解析(Fake-IP 之外的直接解析)模式:每次都向真實的上游 DNS 伺服器發起查詢,取得真實 IP。優點是應用程式拿到的始終是可用的真實位址,相容性最好;缺點是失去了基於網域的精確規則比對能力(只能按 IP 段判斷),而且每次查詢都有真實的網路往返延遲。

對絕大多數日常使用情境——網頁瀏覽、影片、社交應用程式——Fake-IP 都是延遲更低、比對更準的選擇,這也是為什麼它被大多數客戶端設為預設模式。

區域網路服務與遊戲連線為什麼必須設定 fake-ip-filter

Fake-IP 的假位址機制在跨裝置情境下會暴露出明顯短板。典型情況有兩類:

區域網路內的自建服務或路由器管理頁面。 假設家裡有一台 NAS 或路由器,網域解析走的是內網 DNS,正常情況下應該取得一個 192.168.x.x 之類的內網真實位址。但如果這類網域沒有被排除在 Fake-IP 處理之外,核心會照樣回傳一個 198.18.x.x 假位址,應用程式拿著假位址去連線,核心嘗試按規則比對轉發,結果往往是連不上,或是繞了一圈才連上,體驗上表現為「內網裝置存取變慢甚至逾時」。

遊戲連線與即時對戰類應用程式。 不少遊戲客戶端會把伺服器網域解析結果直接用於建立 UDP 連線、做延遲偵測,甚至在介面上把解析到的 IP 顯示給使用者做節點選擇依據。假位址在這類情境下會導致連線失敗、延遲數值異常,或是遊戲內的伺服器清單根本無法正確載入。

解決辦法是在 DNS 設定裡加入 fake-ip-filter 欄位,把這些特定網域或網域模式排除在 Fake-IP 處理範圍之外,讓它們走真實解析。常見設定範例:

dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "192.168.*.*.*"
    - "router.asus.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

其中 *.lan、*.local 一類通配寫法涵蓋了大多數家用區域網路裝置常用的網域後綴;帶 +. 前綴的寫法表示同時比對主網域及其所有子網域,常用於排除連通性檢測一類系統層級網域,避免它們被假位址干擾導致系統誤判「網路不可用」。遊戲相關網域建議逐條加入官方文件給出的伺服器網域清單,而不是籠統排除整個大類,否則會犧牲掉 Fake-IP 本該帶來的分流精準度。

排查思路:遇到「某個服務連不上」時怎麼定位

當懷疑問題出在 Fake-IP 身上時,可以按下面的順序排查:

  1. 先確認目前 DNS 模式確實是 Fake-IP,而不是其他模式導致的問題;
  2. 查看客戶端的連線日誌或網域解析記錄,確認目標網域解析出來的是不是 198.18.x.x 或類似保留段位址;
  3. 如果是,說明該網域被錯誤地納入了 Fake-IP 處理,需要把它加入 fake-ip-filter;
  4. 修改設定後重啟核心或重新載入設定(不同客戶端操作入口不同,一般在設定管理頁面有「重新載入」按鈕),避免舊的映射表繼續生效;
  5. 如果問題依舊,再檢查是否是規則集本身把該網域分流到了不可用的代理節點,而不是 DNS 模式的問題。
注意修改 fake-ip-filter 後,已經建立的映射關係可能還留在快取裡,建議重啟代理核心而不是只重新載入設定檔,確保舊的假位址映射被清空。

什麼情況下可以考慮關閉 Fake-IP

並不是所有情境都必須用 Fake-IP。如果所在網路環境裡大量應用程式依賴真實 IP 做校驗、或是區域網路服務特別多、逐條加入過濾規則維護成本過高,也可以整體切換回真實解析模式,犧牲一部分延遲優勢換取更少的相容性問題。不過對大多數只是想讓瀏覽器、社交應用程式、影片客戶端正常分流的使用者來說,保留 Fake-IP 預設設定、只針對區域網路網域和少數特殊應用程式做過濾清單,是維護成本和體驗之間更平衡的做法。

下載Clash