Fake-IP 模式原理詳解:DNS 解析怎麼被接管,哪些場景該開哪些該關
從 DNS 查詢流程講起,解釋 Fake-IP 如何用保留網段假地址加速規則匹配、減少 DNS 洩漏,對比 Redir-Host 的差異,並列出區網服務、遊戲連線等需要關閉或加例外的典型場景。
一般 DNS 解析流程,以及代理場景下它帶來的問題
存取一個網域之前,系統要先把網域翻譯成 IP 位址,這一步叫 DNS 解析。預設情況下,作業系統把查詢發給電信業者或系統設定的 DNS 伺服器,拿到真實 IP 後再建立連線。這個流程在沒有代理的環境下沒什麼問題,但套上代理軟體之後,至少會暴露兩個麻煩。
第一個麻煩是洩漏。如果代理軟體只接管了 TCP/UDP 流量,卻沒管住 DNS 查詢,那麼網域解析請求會繞過代理直接走本機網路出去,電信業者或本機網路的監聽方能看到使用者在查詢哪些網域,這就是常說的 DNS 洩漏——流量走了代理,查詢紀錄卻沒走。
第二個麻煩是匹配時機。Clash 的分流規則裡有大量基於網域的規則(DOMAIN-SUFFIX、DOMAIN-KEYWORD 等),這些規則天然更適合拿著網域字串去匹配。但傳統流程是先解析出 IP,應用層拿到的是一串數字,如果這時才做規則匹配,網域資訊已經丟了,只能退化成基於 IP 段的匹配,規則庫的維護成本和覆蓋率都會打折扣。
Fake-IP 是什麼:用保留網段的假地址頂替真實解析
Fake-IP 是 Clash / Clash Meta(mihomo)核心提供的一種 DNS 處理模式。核心思路很簡單:客戶端內建一個 DNS 伺服器,攔截系統發出的所有網域查詢,不去問真實 DNS,而是從一個預留的私有網段(常見預設是 198.18.0.0/16)裡,給每個網域分配一個從未被公網使用的假 IP,並在核心裡維護一張「網域 ↔ 假 IP」的對照表。
應用程式拿到這個假 IP 之後,會照常發起連線,連線請求進入 Clash 的流量接管層(TUN 模式或系統代理)。這時核心先查一下對照表,發現目標位址是個假 IP,立刻反查回對應的網域,規則匹配環節因此重新拿到了網域字串,而不是一個失去上下文的 IP 數字。真正的網域解析動作,被推遲到規則判斷「這條流量要走哪個代理節點」之後才執行,而且解析請求本身也是經代理節點轉發出去的,不會在本機網路裸奔。
這樣一來,前面提到的兩個麻煩同時被解決:DNS 查詢全程在代理鏈路內完成,不再裸露給本機網路;規則匹配拿到的始終是網域而不是提前固化的 IP,匹配準確率和回應速度都更有保障。
關鍵點:假 IP 只在本機核心裡「臨時存在」,不會真正發到公網,也不會被其他裝置識別,它的唯一作用是充當網域到規則引擎之間的一個中間令牌。
Fake-IP 與 Redir-Host:兩種網域保留方式的差異
Clash 的 DNS 增強模式裡,除了 Fake-IP,還有一種更早期的方案叫 Redir-Host。兩者目標一致——把網域資訊帶到規則匹配環節——但實現路徑不同,行為差異也直接影響到底該選哪一種。
| 對比項 | Fake-IP | Redir-Host |
|---|---|---|
| DNS 查詢處理 | 攔截查詢,回傳本機生成的假 IP | 正常放行查詢,拿到真實 IP |
| 規則匹配依據 | 反查對照表得到網域 | 依賴 SNI/Host 標頭等應用層欄位還原網域 |
| 相容性風險 | 非 HTTP/TLS 協定可能拿不到網域欄位而誤判 | 依賴真實 IP 的場景(如證書校驗 IP)更少出問題 |
| 對無網域協定支援 | 部分協定缺 Host 資訊時會分流不準 | 基本不受影響,因為用的是真實 IP |
| 目前主流建議 | mihomo 預設推薦,效能與準確率更平衡 | 逐步邊緣化,多用於排查相容性問題時對照 |
簡單說,Fake-IP 是「先假裝解析,靠核心對照表還原網域」,覆蓋面廣、速度快,是目前 mihomo 核心的預設推薦;Redir-Host 是「老老實實拿到真 IP,再從協定標頭裡摳網域欄位」,勝在穩,遇到某些不走標準 TLS/HTTP 的私有協定時更少翻車,但整體已經不是主流選擇。日常使用直接用 Fake-IP 即可,遇到某個應用連不上再針對性排查,不需要一上來就整體切換回 Redir-Host。
哪些場景需要關閉 Fake-IP 或加例外
Fake-IP 不是萬能開關,它假設「所有網域查詢都可以先給假地址」,但有些場景恰恰依賴「拿到的必須是真實 IP」,這時就得關閉 Fake-IP 或者把對應網域加入例外名單(通常設定項是 fake-ip-filter)。
- 區網內部服務發現:NAS、印表機、智慧家庭裝置、區網共享硬碟等,網域往往解析到
192.168.x.x或*.local這類內網地址,如果這些網域被塞進假 IP 邏輯,連線會被錯誤地送進代理鏈路而失敗,建議把*.local、內網裝置的自訂網域都寫進fake-ip-filter。 - 遊戲連線與區網發現協定:很多遊戲的連線大廳、語音服務需要拿到真實公網 IP 用於建立直連或 P2P 通道,假 IP 會破壞這類需要「看到真實地址」的握手邏輯,常見做法是把遊戲相關網域整體排除在 Fake-IP 之外,或者乾脆把遊戲程序加入直連規則。
- 某些客戶端直接做 IP 白名單校驗:少數企業內網工具、部分支付/金融類客戶端會在應用層校驗請求方 IP 是否落在預期範圍,假 IP 會導致校驗失敗,這類場景通常需要為對應網域單獨設定直連或加入例外列表。
- 依賴 mDNS / 多播發現的裝置:蘋果生態的 AirPlay、AirDrop 等基於多播廣播完成裝置發現,與 DNS 解析路徑不同,理論上不受 Fake-IP 影響,但如果發現異常,先排查 TUN 模式的路由劫持範圍,而不是急著關掉 Fake-IP。
注意:開啟 TUN 模式後,Fake-IP 的網段會被系統當作真實路由處理,如果這個網段與本機已有的內網地址段(比如公司 VPN 分配的私有網段)衝突,會出現莫名其妙連不上內網的問題。遇到這種情況,優先檢查 fake-ip-range 是否與現有網路環境衝突,而不是直接歸咎於代理軟體故障。
設定與排查建議
動手調整 Fake-IP 相關設定前,先明確自己用的是哪個層面在起作用:DNS 層的對照表,還是 TUN 層的路由劫持,兩者分開排查效率更高。
- 確認客戶端 DNS 設定裡
enhanced-mode是否為fake-ip,如果顯示redir-host說明走的是另一套邏輯,前面章節的行為對照要反過來看。 - 檢查
fake-ip-range使用的網段是否與本機現有網路(包括 VPN、虛擬機網卡)有重疊,重疊是導致內網存取異常的常見原因。 - 把明確需要真實 IP 的網域(內網服務、遊戲大廳、多播裝置)逐條加入
fake-ip-filter,不要圖省事整體關閉 Fake-IP,那樣會連帶丟失前面提到的匹配加速與防洩漏效果。 - 懷疑某個連線異常與 Fake-IP 有關時,先打開客戶端日誌頁觀察該連線實際命中的規則與目標地址,確認是解析環節出的問題,還是規則本身寫錯了。
- 調整設定後重啟一次代理核心而不只是重連節點,DNS 對照表和路由表通常是在核心啟動階段建立的,單純切換節點不會重新生成。
總的來說,Fake-IP 是把網域解析這一步「往後挪」並「藏起來」的工程手段,目的是讓規則匹配更準、DNS 查詢更私密,絕大多數使用場景保持預設開啟即可。真正需要關注的是那一小部分依賴真實 IP 語義的服務,針對它們加例外,而不是因為個別應用連不上就把整套機制關掉。