Clash Fake-IP 模式原理：DNS 映射流程、適用情境與排除規則

Fake-IP 是 Clash 與 mihomo 常用的進階 DNS 處理方式。它不會直接將網域查詢結果替換成目標伺服器的公網位址，而是先從專用位址範圍分配虛擬位址，並在核心中保存「網域—虛擬位址」的對應關係。應用程式接著連線到這個虛擬位址時，Clash 會根據映射還原網域，再執行網域規則、策略組選擇與遠端解析。

這種方式的重點不是改變目標網站，而是讓流量入口保留準確的網域資訊。對於經由 TUN 虛擬網卡接管、只向作業系統提交 IP 連線的程式，Fake-IP 可以將先前 DNS 查詢取得的網域重新關聯到連線。如此一來，規則引擎更容易命中 DOMAIN、DOMAIN-SUFFIX、規則集合等網域規則，也能減少本地 DNS 結果與代理出口實際存取結果不一致的問題。

Fake-IP 的 DNS 映射流程

一次典型的存取可分為 DNS 查詢與建立連線兩個階段。理解這兩個階段，才能判斷異常發生在網域解析、流量接管、規則比對，還是代理出口。

1. 應用程式向系統 DNS 發起網域查詢，例如請求某項服務的 A 記錄或 AAAA 記錄。
2. 系統查詢會送到 Clash 的 DNS 模組。使用 TUN 時，常見做法是透過 dns-hijack 接收指定連接埠上的 DNS 請求；採用其他接管方式時，也可能由作業系統 DNS 設定直接指向本機監聽位址。
3. Fake-IP 模組會為網域分配虛擬位址，並記錄映射關係。常見位址池位於基準測試用途的保留網段中，實際範圍由 fake-ip-range 決定。
4. 應用程式取得虛擬位址後會發起 TCP 或 UDP 連線。這條連線必須繼續進入 Clash；若流量繞過 Clash，虛擬位址本身無法直接在公網建立連線。
5. Clash 會根據目標虛擬位址查回原始網域，將網域交給規則引擎，再選擇直連、代理、拒絕或指定策略組。
6. 需要建立實際連線時，Clash 會依設定使用上游 DNS、代理端解析，或目標協定所需的解析方式取得真實位址。

因此，Fake-IP 並不是獨立的代理模式，而是依賴 DNS 請求與後續連線都由同一個 Clash 執行個體接收。DNS 查詢進入 Clash、連線卻繞過 TUN，或連線進入 Clash、DNS 查詢卻被其他程式攔截，都會破壞映射鏈路。排查時，應分開檢查「DNS 是否經過 Clash」與「目標連線是否經過 Clash」。

網域規則通常會在還原映射後進行比對。例如規則中存在某個網域後綴時，Clash 可以直接使用還原後的主機名稱判斷，不必先將它當成一般公網 IP 交給 IP 規則。對於直接輸入 IP 位址的連線，由於沒有前置網域查詢，也就不會產生 Fake-IP 映射；規則仍會依 IP、連接埠及其他可用資訊處理。

mihomo 的基本設定與欄位關係

不同用戶端可能透過圖形介面開關產生設定，也可能經由訂閱覆寫寫入 DNS 區段。最終應以用戶端實際載入的設定為準。以下是用來理解欄位關係的簡化範例，監聽位址、上游 DNS 與位址池應依裝置環境調整。

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:
    - "*.lan"
    - "*.local"
    - "time.*.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53

enhanced-mode: fake-ip 用於選擇 Fake-IP 增強模式；fake-ip-range 定義虛擬位址池；fake-ip-filter 列出不應回傳虛擬位址的網域。命中过濾項目後，DNS 模組會為這些網域回傳真實解析結果，而不是建立 Fake-IP 映射。

dns-hijack 與 Fake-IP 的職責不同。前者負責讓裝置上的 DNS 請求進入 Clash，後者負責決定進入後的回應方式。只啟用 Fake-IP 卻沒有讓查詢抵達 Clash，設定不會套用到那些繞行的 DNS 請求；只設定 DNS 劫持但仍使用一般解析模式，也不會產生虛擬位址映射。

在 mihomo 中，Fake-IP 映射預設主要用於執行期間的連線關聯。部分設定可在 profile 中啟用 Fake-IP 資料持久化，讓核心重新啟動後繼續使用已儲存的映射。是否需要持久化，取決於用戶端的設定管理方式。遇到位址池調整、歷史映射異常或切換設定後行為不一致時，可以先關閉核心，再清除用戶端提供的 DNS/Fake-IP 快取，然後重新載入設定。

適合使用 Fake-IP 的情境

桌面裝置上的 TUN 全流量接管

TUN 會建立虛擬網路介面，接收未遵循系統 HTTP 代理設定的 TCP、UDP 及部分系統服務流量。許多程式建立連線時只向網路堆疊提交解析後的 IP，規則引擎未必能從連線本身取得網域。Fake-IP 透過前一次 DNS 查詢補回網域資訊，因此與 TUN 搭配相當直接。

瀏覽器、命令列工具、遊戲平台與背景更新服務可能使用不同的網路介面及代理機制。統一讓 DNS 查詢與連線經過 TUN，可減少某個程式遵循系統代理、另一個程式繞過系統代理所造成的分流差異。啟用後仍應檢查路由表、DNS 劫持與用戶端記錄，確認不是只有瀏覽器流量生效。

依賴網域規則的大型規則集

訂閱設定通常包含大量網域後綴、網域關鍵字與規則集合。使用 Fake-IP 後，核心可在連線抵達時還原查詢網域，並優先執行這些規則。網域規則比單純依伺服器 IP 判斷更穩定，因為同一項服務可能使用 CDN、動態調度或共用位址，而同一個公網 IP 也可能承載多個完全不同的網域。

如果某條規則希望直連區域網路服務、代理公開網站或拒絕特定網域，Fake-IP 能讓規則目標更明確。不過，規則順序仍然有效。較寬泛的規則放在前面，仍可能覆蓋後方的精確網域規則；Fake-IP 只提供比對資訊，不會自動修正規則優先順序。

希望減少本地解析差異的代理連線

一般 DNS 模式通常會先在本地取得真實 IP，再由規則引擎根據網域或 IP 做出決定。若代理出口與本地網路取得的 CDN 位址不同，可能造成路徑繞行或連線結果不一致。Fake-IP 可以延後決定真實目標位址，讓核心依策略與上游設定選擇解析路徑，適合需要網域分流並由代理端完成後續連線的環境。

區域網路、遊戲與特殊網域的常見問題

區域網路主機名稱與裝置探索

印表機、NAS、電視投放與路由器管理頁面經常使用 .local、.lan 或廠商自訂的主機名稱。部分名稱由 mDNS、LLMNR、路由器本地網域服務或搜尋網域完成解析，不適合交由公共上游 DNS 處理。若這些名稱取得 Fake-IP，應用程式可能無法完成同網段探索，或將原本應直連的管理請求交給代理規則。

處理順序應先確認名稱由哪種協定解析，再新增精確的排除項目。對於固定裝置，可以優先保留 DHCP 主機名稱解析，或使用明確的區域網路網域後綴。僅將需要本地解析的後綴加入 fake-ip-filter，同時確保區域網路 IP 區段有直連規則。單獨排除網域但沒有直連路由，連線階段仍可能選錯策略。

遊戲登入、語音與 UDP 工作階段

部分遊戲會同時使用帳號登入網域、內容下載網域、對戰伺服器 IP、語音 UDP 及 NAT 探測服務。登入網頁正常，不代表整條遊戲鏈路都正常。若啟動器查詢網域後將結果交給獨立程序，而後續程序未由同一個 TUN 接管，虛擬位址可能失去對應的轉送入口。

出現登入循環、伺服器區域清單空白或語音連線失敗時，應先查看核心記錄中是否能看到對應的 UDP/TCP 連線，再確認程序是否進入 TUN。只有在記錄證明某個網域不適合 Fake-IP 時，才將該網域加入過濾清單。遊戲通常會使用多個服務網域，直接排除整個頂級網域或關閉所有 Fake-IP，容易讓原有的網域分流失效。

時間同步、網路檢測與強制入口網站

系統時間同步、網路連線檢測，以及校園或飯店的登入入口網站，可能需要真實 DNS 結果，或必須在代理核心啟動前完成存取。這類請求若取得虛擬位址，但連線尚未進入 Clash，系統可能誤判為離線。時間同步網域、作業系統網路探測網域，以及入口網站驗證所使用的網域，都是常見的排除規則候選。

排除項目應來自實際記錄與擷取結果，而不是照抄冗長的通用清單。作業系統版本、地區及網路環境不同，檢測網域也會改變。先重現問題、記錄查詢網域，再新增最小範圍規則，能避免將一般業務流量一併改回真實 IP。

將 IP 位址寫入設定或由其他裝置重複使用

某些程式會長時間快取 DNS 結果，甚至將取得的位址寫入設定檔。Fake-IP 只在掌握映射的 Clash 執行個體中有效，將此位址複製到另一台裝置後並無意義。旁路由環境也要特別注意：若 DNS 由旁路由 A 回傳虛擬位址，但實際連線經過閘道 B，閘道 B 不知道該虛擬位址對應哪個網域。

同一個區域網路為多台裝置提供 Fake-IP DNS 時，應讓這些裝置的後續流量穩定經過同一個核心執行個體，並確保虛擬位址池的路由指向該執行個體。否則更適合使用回傳真實位址的 DNS 模式，或只讓本機用戶端使用 Fake-IP。

如何撰寫 Fake-IP 排除規則

排除規則的目標，是讓少數不相容網域回傳真實位址，而不是建立一份涵蓋所有服務的例外清單。可依「精確網域、有限萬用字元、後綴範圍」的順序逐步擴大。

mihomo 的實際比對能力會隨版本與設定格式變化，用戶端也可能在合併訂閱與覆寫時修改欄位。修改後應開啟用戶端的最終設定檢視，確認 fake-ip-filter 沒有被訂閱更新覆蓋，並查看核心啟動記錄是否回報欄位錯誤。

部分新版 mihomo 設定支援為 Fake-IP 過濾設定黑名單或白名單邏輯。黑名單方式表示清單內的網域使用真實解析，其他網域使用 Fake-IP；白名單方式則相反，只讓清單命中的網域使用 Fake-IP。日常桌面環境通常更適合從少量排除項目開始。若啟用白名單，應確認未命中的大量網域回傳真實位址是刻意設計，而不是誤解欄位含義。

Fake-IP 異常排查順序

1. 確認設定已載入。在用戶端的執行設定中核對 DNS 已啟用、增強模式為 Fake-IP，並檢查核心啟動記錄。訂閱檔案、覆寫檔案與用戶端開關可能同時修改 DNS 區段。
2. 確認 DNS 查詢已進入核心。觀察連線記錄或 DNS 記錄，檢查目標網域是否出現。若系統啟用了加密 DNS、瀏覽器獨立 DNS 或其他 DNS 工具，請確認它們是否繞過本地監聽。
3. 確認虛擬位址屬於設定的位址池。查詢結果應落在 fake-ip-range 中。若仍回傳一般公網 IP，可能命中过濾項目，也可能查詢未經過 Clash。
4. 確認後續連線也已被接管。應用程式取得虛擬位址後，記錄中應出現對應連線。完全沒有連線記錄時，優先檢查 TUN 權限、系統路由與應用程式繞行設定。
5. 檢查映射能否還原網域。連線記錄應顯示原始網域或命中的網域規則。若只顯示虛擬 IP，請嘗試清除 DNS 與 Fake-IP 快取，並確認查詢與連線由同一個核心處理。
6. 檢查規則順序與策略組。網域已還原但出口錯誤時，問題通常在規則優先順序、規則集合更新或策略組選擇，而非 Fake-IP 本身。
7. 最後再新增排除項目。只有確認目標服務確實要求真實 DNS 結果後，才將精確網域加入過濾清單。

修改 DNS 設定後，瀏覽器、作業系統與應用程式可能仍會使用舊快取。應先重新載入 Clash 設定，再清除系統 DNS 快取並完全退出相關應用程式。若用戶端提供「清除 DNS 快取」或「重新整理 Fake-IP 快取」入口，可在停止相關連線後執行。頻繁切換多個核心執行個體時，也要確認系統 DNS 與預設路由已指向目前的執行個體。

Fake-IP 與 Redir-Host 的選擇

Fake-IP 著重透過虛擬位址保留網域映射，適合 TUN 接管、網域規則較多，且 DNS 與連線路徑可統一控制的裝置。Redir-Host 這類回傳真實位址的模式較接近一般 DNS 行為，對需要真實位址的區域網路服務、跨裝置 DNS 及部分特殊應用程式更容易相容，但網域關聯與解析路徑會受到用戶端實作及連線類型影響。

選擇時不要只比較某個網頁能否開啟，還應同時檢查瀏覽器、系統更新、區域網路裝置、遊戲 UDP、休眠恢復與網路切換。單機桌面裝置通常可以先使用 Fake-IP，再針對明確異常建立小範圍過濾；由路由器為多台裝置統一提供服務時，應先規劃 DNS 請求與回程流量路徑，確保虛擬位址始終回到同一個執行個體。

最終判斷標準是鏈路是否完整：DNS 查詢進入 Clash、虛擬位址由目前核心分配、後續連線再次進入同一個核心、網域規則正確命中，且策略組能建立真實連線。只要依這個順序觀察記錄，Fake-IP 問題通常可以定位到具體環節，不必反覆切換所有 DNS 設定。