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

在 Clash、Clash Meta 與後續維護分支 mihomo 的 DNS 設定中，Fake-IP 是一個容易被誤解的選項。它回傳的位址看似真實 IP，但主要用途不是直接代表遠端伺服器，而是讓核心接管連線時重新找回原始網域。理解這一點，才能判斷連線失敗究竟來自 DNS、規則、代理節點，還是應用程式本身的網路行為。

Fake-IP 特別適合以網域規則為主的設定，也經常搭配 TUN 模式使用。它能減少應用程式提前解析網域造成的規則資訊遺失，但並非所有裝置、通訊協定與區域網路名稱都適合接收對映位址。正確做法不是盲目擴大排除清單，而是先釐清查詢與連線經過哪些環節，再針對確實依賴真實位址的目標設定過濾項。

Fake-IP 解決的核心問題

一般 DNS 查詢會將網域解析為真實 IP。應用程式接著連線到這個 IP 時，若代理核心只看得到目標位址，原始網域可能已不在連線資訊中。此時，像是 DOMAIN-SUFFIX、DOMAIN-KEYWORD 與特定網域規則便難以直接參與比對，只能退回 IP、GeoIP 或預設規則。對於同一個 IP 承載多個網站的內容傳遞網路而言，這種退化尤其明顯。

Fake-IP 的做法是由 Clash 內建 DNS 接收查詢，為網域分配暫時的對映位址，並保存「網域—對映位址」的對應關係。應用程式取得該位址後發起連線，流量再次進入核心；核心依據對映表識別原始網域，再按照網域規則選擇策略。實際連線到遠端時，核心仍會依設定查詢可用的真實位址，並透過直連或選定的代理建立連線。

許多設定會使用 198.18.0.1/16 作為預設位址池。此網段保留給基準測試情境使用，通常不會在公網路由。核心利用這類不應供公開網際網路使用的位址範圍建立對映，可降低與正常公網目標衝突的機率。若本地實驗網路已使用相同網段，便需要調整位址池，以免路由判斷互相覆蓋。

Fake-IP 與 Redir-Host 的差異

redir-host 模式通常會將真實解析結果回傳給應用程式，連線目標更接近傳統網路行為。對部分依賴真實 IP 的程式而言較直觀，但網域規則能否準確命中，會受到流量入口、嗅探能力與應用程式解析路徑影響。Fake-IP 則透過對映關係主動保留網域上下文，更適合需要細緻網域分流的設定。

從 DNS 查詢到規則比對的完整流程

排查 Fake-IP 問題時，不能只看一次 DNS 查詢。完整路徑至少包含應用程式發起查詢、內建 DNS 回應、應用程式連線至對映位址、核心還原網域、規則比對以及上游解析六個環節。任何一個環節繞過 Clash，都可能讓結果與預期不同。

1. 應用程式查詢網域。瀏覽器、遊戲用戶端或系統服務會向設定的 DNS 位址查詢 A 或 AAAA 記錄。若查詢沒有進入 Clash 內建 DNS，Fake-IP 設定便不會生效。
2. 核心檢查排除規則。若網域命中 fake-ip-filter，核心會回傳真實解析結果；未命中時則繼續分配對映位址。
3. 產生或讀取對映。核心從 Fake-IP 位址池取出位址，並將該位址與原始網域建立關聯。重複查詢可能會重用既有對映，實際生命週期由核心快取管理。
4. 應用程式發起連線。應用程式會將對映位址視為目標，建立 TCP 或 UDP 工作階段。系統代理模式與 TUN 模式的接管路徑不同，但關鍵在於連線必須再次進入 Clash。
5. 還原目標網域。核心讀取對映表，將目標還原為查詢時的網域，並使用該網域執行規則比對。
6. 選擇策略與解析路徑。規則決定採用直連、代理或某個策略群組。需要實際建立連線時，再依 DNS 設定取得遠端真實位址。

這套機制也解釋了一個常見現象：在命令列執行 nslookup 時看到對映位址，不代表存取已經透過代理。DNS 回應只完成對映階段，最終使用哪個策略仍由後續連線與規則決定。反過來，若應用程式使用內建 DoH、固定 IP 或自己的 DNS 通道，系統查詢可能完全沒有出現，Fake-IP 也無法憑空取得網域。

系統代理與 TUN 模式的差異

在系統代理模式下，遵循代理設定的 HTTP 或 SOCKS 應用程式可以直接將網域交給代理端處理，部分情境並不依賴 Fake-IP。無法讀取系統代理設定的應用程式則可能直接連線，除非另有透明接管方案。TUN 模式從虛擬網卡層接收更多系統流量，因此常與 DNS 劫持、Fake-IP 及路由設定搭配使用。

TUN 並不代表所有 DNS 都會自動進入核心。作業系統可能使用加密 DNS，瀏覽器也可能啟用獨立的安全 DNS。設定時應確認 DNS 劫持範圍、監聽連接埠、區域網路共用方式與系統防火牆狀態。若查詢經由外部 DNS，而連線卻由 TUN 接管，核心通常只看得到真實 IP，網域規則可能必須依賴嗅探才能還原。

mihomo 的基本設定方式

以下是一段用於理解欄位關係的簡化範例。實際用戶端可能透過圖形介面產生部分欄位，也可能將使用者覆寫內容與訂閱內容合併。修改前應保留原始設定，並在用戶端日誌中確認目前載入的是哪一份檔案。

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"
    - "localhost"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

enable 控制內建 DNS，enhanced-mode 選擇增強模式，fake-ip-range 定義對映位址池，fake-ip-filter 決定哪些網域回傳真實結果。nameserver 是主要上游解析器；default-nameserver 常用於解析 DoH、DoT 等上游伺服器本身的網域，因此通常需要填寫可直接連線的 IP 位址型解析器。

設定格式會隨核心版本與用戶端封裝方式而變化。mihomo 支援較豐富的 DNS 欄位與規則表達能力，但舊版 Clash 用戶端未必能識別所有新欄位。若訂閱要在多個用戶端之間使用，應先確認各用戶端綁定的核心及版本，不要因為某個介面能儲存欄位，就預設執行中的核心已經採用該欄位。

DNS 上游與分流的關係

上游 DNS 的選擇會影響真實位址取得、污染規避與連線延遲，但它與代理規則並非同一層。某個網域由境外 DoH 解析，不代表連線一定會走代理；同樣地，使用本地 DNS 解析也不等於該連線一定直連。最終策略仍取決於規則順序與比對結果。

部分 mihomo 設定也會使用 nameserver-policy，依網域規則指定不同上游。例如讓區域網路或特定地區網域使用本地解析器，其他網域則使用加密解析器。此功能適合明確掌握解析需求的設定，但規則過多時會增加排查難度。遇到問題時，應先縮減為單一可用上游，確認 Fake-IP 流程正常後再恢復分流。

適用情境與不宜直接套用的環境

適合以網域規則為主的訂閱

許多訂閱規則以網域後綴、關鍵字與規則集為主。Fake-IP 能讓連線進入規則引擎時保留網域，減少同一個 CDN 位址承載多項服務時的誤判。對瀏覽器、桌面應用程式與行動應用程式混合使用的裝置而言，這種行為通常比單純依賴目標 IP 更容易預測。

適合由 TUN 接管的桌面環境

有些應用程式不讀取系統代理，另有些程式會同時使用 TCP 與 UDP。TUN 模式能接管更廣泛的流量，Fake-IP 則協助核心將 DNS 查詢與後續連線關聯起來。兩者搭配時，應將「查詢是否進入內建 DNS」與「連線是否經過 TUN」視為兩個獨立項目檢查，不能只看到 TUN 已啟動就認定 DNS 路徑正確。

區域網路閘道需要更加謹慎

當 Clash 或 mihomo 部署在路由器、旁路閘道或家用伺服器上時，用戶端裝置可能將閘道當作 DNS，也可能繼續使用電信業者 DNS、路由器下發的 IPv6 DNS 或應用程式內建 DoH。若閘道向整個區域網路回傳 Fake-IP，就必須確保這些對映連線都能回到同一個核心；否則用戶端會嘗試將對映位址直接送往其他路由，最後表現為連線逾時。

區域網路裝置探索、印表機、NAS、智慧家庭與媒體投放常依賴 .local、單標籤主機名稱、mDNS、LLMNR 或廠商自訂網域。這些名稱不一定應由公網 DNS 處理。閘道方案通常需要保留本地解析器，並為內部網域設定真實解析或專用上游。

遊戲與即時通訊應依實際現象判斷

部分遊戲啟動器會使用網域下載資源，但實際對戰階段可能透過 UDP、固定 IP 或區域調度服務通訊。Fake-IP 對啟動器網頁介面可能運作正常，卻可能影響延遲偵測、伺服器清單或反作弊元件的位址判斷。出現問題時，不應直接關閉所有 DNS 功能；可先從日誌確認失敗網域，再將確實要求真實位址的網域加入過濾清單。

Fake-IP 排除項的設計方式

fake-ip-filter 的用途是讓特定網域略過對映，直接將真實 IP 回傳給應用程式。排除範圍越大，可用於網域規則比對的連線就越少，因此排除清單應圍繞具體相容需求建立，而不是複製一份無法說明來源的超長清單。

區域網路與本地域名

*.lan、*.local 與家庭內部自訂後綴通常值得優先檢查。如果 NAS 使用 storage.home.arpa，就應結合本地 DNS 與實際後綴設定對應規則。單純排除網域，卻沒有能回應查詢的本地解析器，仍然無法取得正確位址。

時間同步與網路連線檢測

某些系統服務會透過特定網域尋找 NTP 伺服器、檢測網路是否可用，或判斷目前是否需要登入驗證入口網站。這類程式可能希望取得真實位址，甚至會比對 DNS 與 HTTP 回應。若裝置頻繁顯示「網路無法使用」，但瀏覽器存取正常，可以從系統連線檢測網域與時間同步網域開始查看日誌。

裝置探索、語音與遊戲服務

依賴區域網路廣播的裝置通常不應將本地名稱對映到 Fake-IP。遊戲與語音程式則要區分登入、更新、配對與即時通訊網域，避免用過寬的萬用字元排除整個廠商網域。過寬的排除可能讓下載網域失去原有代理規則，只能依真實 IP 或預設規則處理。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "localhost"
    - "time.windows.com"
    - "time.apple.com"

不同核心版本對萬用字元、規則集與附加比對語法的支援可能不同。最穩妥的做法是先用明確的完整網域驗證，再依日誌擴展到必要的子網域範圍。設定載入後還應清除系統 DNS 快取、關閉應用程式中既有的長連線並重新查詢，避免舊快取掩蓋修改結果。

常見故障與定位順序

查詢結果仍是真實 IP

先確認用戶端顯示的執行模式，以及實際核心設定中是否為 enhanced-mode: fake-ip，再檢查網域是否命中过濾項。接著確認測試工具使用的是哪一台 DNS 伺服器。瀏覽器安全 DNS、系統 DoH、VPN 軟體或區域網路 DHCP 下發的其他 DNS，都可能讓查詢繞過 Clash。

可以解析，但連線一直逾時

看到對映位址表示 DNS 階段可能已經進入核心，但後續連線未必受到接管。在系統代理模式下，不遵循代理設定的應用程式可能直接存取 198.18.x.x；TUN 模式下則需檢查虛擬網卡、路由表、防火牆權限與 DNS 劫持設定。部署在閘道時，還要確認 Fake-IP 位址池的流量會被正確送回閘道核心。

規則沒有依網域命中

查看日誌中的目標類型。如果日誌只顯示真實 IP，可能是查詢繞過內建 DNS、應用程式直接連線到固定 IP，或該網域已加入 Fake-IP 過濾項。若日誌能顯示網域，但策略仍不正確，應檢查規則順序：Clash 通常按由上而下的順序比對，較寬泛的規則放在前面會提前攔截連線。

區域網路裝置名稱無法存取

確認名稱究竟由哪種機制解析。.local 通常與 mDNS 有關，不一定會經過一般單播 DNS；自訂 NAS 網域則可能由路由器 DNS 回應。應將對應網域交給能回傳內網位址的解析器，並視需要加入 Fake-IP 排除。只設定 DIRECT 規則無法修正錯誤的 DNS 回應，因為規則比對發生在解析鏈路之後。

切換設定後結果沒有變化

DNS 結果可能快取在作業系統、瀏覽器、應用程式與核心中。測試時可依序重新載入設定、清除系統 DNS 快取、完全退出應用程式後再重新開啟。不要只重新整理網頁，因為瀏覽器可能繼續重用現有連線。若用戶端支援檢視目前設定，應確認訂閱更新或覆寫流程沒有蓋掉手動修改。

建議的最小檢查清單

1. 確認目前執行的核心及其版本支援所使用的 DNS 欄位。
2. 確認內建 DNS 已啟用，且測試查詢確實送往對應的監聽位址。
3. 暫時保留一個可用上游，排除複雜 DNS 分流的影響。
4. 檢查目標網域是否命中 fake-ip-filter。
5. 確認對映位址對應的連線會進入系統代理或 TUN。
6. 從日誌核對網域、規則名稱、最終策略與連線錯誤。
7. 最後再檢查節點連線能力、UDP 支援與遠端服務狀態。

設定結論：先確保閉環，再增加排除項

Fake-IP 的關鍵不是「回傳一個特殊 IP」，而是建立 DNS 查詢與後續連線之間的對映閉環。查詢進入 Clash、連線再次進入 Clash、對映表還原網域、規則選擇策略，這四個步驟完整時，網域分流才具備穩定基礎。任何一步繞過核心，都可能出現解析正常卻無法連線，或連線成功卻命中錯誤規則的情況。

桌面裝置使用 mihomo 與 TUN 時，可以從基本 Fake-IP 設定開始，再依日誌加入區域網路、時間同步、遊戲與裝置探索網域。路由器與旁路閘道則要額外確認 DHCP、IPv6 DNS、位址池路由與用戶端加密 DNS。排除項應小而明確，每一項都對應可重現的相容需求，讓設定在訂閱更新、核心升級與裝置遷移後仍易於維護。