Clash Fake-IP 是什麼？DNS 映射流程、fake-ip-filter 與適用情境

先看結論：Fake-IP 是網域映射，不是代理出口

Fake-IP 模式會讓 Clash 核心先回傳一個合成 IP 位址給應用程式，接管連線時再將這個位址還原為網域。應用程式看到的位址可能是 198.18.0.2，但實際網站和代理出口並不在這個位址上。光是看到這個位址，不代表 DNS 遭到污染，也無法據此判斷請求是否經過代理。

這套機制必須同時具備兩個環節：DNS 查詢交由核心處理，接著，連往合成位址的連線也必須回到同一個核心。桌面端通常透過 TUN 接管流量；路由器則可能使用透明代理規則接管。只在設定中加入 enhanced-mode: fake-ip，不會自動替作業系統建立所有路由和 DNS 轉送。

從 DNS 映射到還原連線的五個步驟

以應用程式存取 example.com:443 為例，假設 DNS 查詢和連線都由同一個 mihomo 執行個體接管，處理順序如下。

應用程式發起查詢。應用程式查詢 example.com 的 IPv4 位址，查詢會進入核心的 DNS 服務。如果應用程式改用未受接管的加密 DNS，這個步驟可能會繞過核心。
核心分配合成位址。網域未命中过濾清單時，核心會從 Fake-IP 位址池分配位址，例如 198.18.0.2，並保存網域與位址之間的映射。若已有有效映射，則可重複使用。
應用程式連線至合成位址。應用程式依照一般網路流程，連線至 198.18.0.2:443。TUN 或透明代理規則會將連線送回核心，而不是讓它直接連上公網。
核心找回原始網域。核心查詢映射表，還原出 example.com，再據此套用網域規則、選擇策略組並處理後續連線。
依出口建立實際連線。使用代理時，如果協定和實作支援傳遞網域，便可由代理端解析；使用直連時，通常仍須由本機核心進行實際解析。具體行為也會受規則和 DNS 設定影響。

198.18.0.0/15 是供網路設備基準測試使用的特殊用途位址區段，並非網站實際使用的公網位址。常見設定會使用其中的 198.18.0.1/16 作為位址池。若企業網路已使用這個網段，請先處理路由衝突，不要直接套用預設值。

保留網域資訊為何有助於規則分流

如果只看到共用的 CDN 位址，核心很難單靠位址區分不同網站。Fake-IP 映射能讓連線保留網域資訊，方便比對 DOMAIN、DOMAIN-SUFFIX 等規則。不過規則仍會依序執行：排在前面的程序規則、網段規則或其他比對項目，仍可能先決定出口。

首包延遲：省下了哪一段等待時間

Fake-IP 能讓應用程式較早取得位址，提早進入連線階段；不必等到真實 A 記錄傳回後，才提供可用的合成位址。相較於必須等待真實解析結果的流程，這可能縮短開始連線前的等待時間，但不代表所有網站都能固定加速。

處理階段	回傳真實位址的流程	Fake-IP 流程
應用程式收到 DNS 回應	通常須取得真實解析結果，快取命中時除外	可從位址池分配並回傳合成位址
網域規則比對	須有可用的網域關聯資訊	可透過合成位址映射還原網域
直連網站	使用真實位址建立連線	核心可能仍須解析真實位址
透過代理存取	解析位置視協定與設定而定	支援傳遞網域時，可交由代理端解析

例如，假設一次未命中快取的真實 DNS 查詢耗時 80 毫秒，Fake-IP 就能讓應用程式不必先等這 80 毫秒，便開始建立連線。這只是用來說明機制的假設數值，並非實測結果；後續直連解析、代理交握、TLS 交握及伺服器回應仍需要時間。

如何進行有意義的比較

固定使用相同網路、節點和規則模式，分別測試冷快取與熱快取，不要將兩者混在一起。
使用瀏覽器開發人員工具的「網路」面板查看 DNS、連線和 TLS 階段，同時檢查核心記錄。瀏覽器顯示的 DNS 耗時，未必包含核心後續解析所花的時間。
至少記錄多次頁面請求的中位數，並區分 DNS 回應速度與頁面第一個位元組的時間。不要用單次測速下載結果代替 DNS 比較。

最簡 DNS 設定與驗證指令

以下是設定片段，不是可直接連網的完整設定。它只會啟用核心 DNS，並監聽本機的 1053 埠；代理節點、規則、TUN 和系統 DNS 接管仍須由現有設定提供。此處關閉 IPv6，是為了將驗證範圍限於 IPv4 A 記錄；日常使用時，請依據網路的 IPv6 接管能力決定是否啟用。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

這兩個上游 DNS 位址必須能從目前的網路連線。如果公司、校園或家庭網路使用分離解析，應改用相應的內部解析器；將所有查詢都送往公共 DNS，可能會導致內部網域解析失敗。監聽 127.0.0.1 只接受本機查詢，不適合作為其他區域網路裝置可直接存取的 DNS 服務。

先測試核心，再測試系統解析流程

在核心已啟動的裝置上，使用以下指令明確指定伺服器和埠號。Windows 可使用第一個指令；已安裝 dig 的 macOS 或 Linux 可使用第二個。兩者擇一即可，不必連續執行。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A +short

確認回傳位址位於設定的 Fake-IP 位址池內。若請求逾時，請先檢查核心是否已啟動、埠號是否被占用，以及最終設定中的 DNS 是否已啟用。
接著使用系統預設的解析方式查詢相同網域。如果指定埠號的查詢成功，但系統查詢結果不同，表示應用程式或系統尚未使用這條 DNS 流程。
在用戶端的「連線」頁面尋找剛才發起的瀏覽器請求，確認目標網域、命中的規則和出口策略組。DNS 回傳合成位址只能證明解析環節正常，不能證明連線已成功交由核心接管。

fake-ip-filter：哪些網域應回傳真實位址

fake-ip-filter 用來指定哪些 DNS 查詢不分配合成位址。在常見的預設黑名單語意下，符合清單的網域會改為回傳真實解析結果。較新版的 mihomo 也提供過濾模式等延伸設定；如果現有設定包含 fake-ip-filter-mode，請先確認其語意，不要直接假設清單中的項目一定是排除項目。

過濾清單不會決定直連或代理，也不會選擇內部 DNS。網域加入清單後，仍可依規則使用代理；網域即使被規則指定為 DIRECT，也不會因此自動略過 Fake-IP。

使用情境	需觀察的現象	處理方式
NAS、印表機與內部服務	應用程式需要真實區域網路位址，或內網網域解析失敗	依實際網域後綴設定過濾，並將查詢交給內部 DNS
遊戲登入與連線	程式會比對解析位址、將位址傳給其他裝置，或連線未經接管	從記錄中找出確切網域，逐一驗證過濾效果
網路連線狀態檢查	系統誤判網路已中斷，或入口網站驗證頁無法開啟	檢查連線狀態檢測網域的解析、出口規則與 HTTP 回應
位址一致性驗證	程式要求 DNS 結果與伺服器記錄或實際位址相符	只過濾已確認需要真實位址的網域

區域網路網域也需要正確的上游 DNS

+.home.arpa 表示該網域及其子網域，適用於已採用此命名方式的家庭網路。.lan 是常見的本機命名慣例，但不是每台路由器都使用。.local 通常涉及 mDNS；將它加入過濾清單，不會讓一般 DNS 上游自動具備 mDNS 探索能力。若印表機探索異常，也應檢查多點傳播和本機網路存取權限。

依據實際狀況新增遊戲與驗證網域

不要直接過濾整個遊戲平台或所有 CDN 網域。請先記錄錯誤發生時間，再從連線和 DNS 記錄中找出相關請求，只新增有問題的完整網域。例如以下的 login.example.com 只是語法示範用網域；實際使用時應替換為記錄中確認的目標，不要照抄來修復遊戲問題。

dns:
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
    - "login.example.com"

請將這些項目合併到現有的 dns 物件中，不要在同一個 YAML 檔案裡重複建立兩個頂層 dns 鍵。如果訂閱會由伺服器定期更新，請使用用戶端支援的覆寫或合併功能保存修改，並在更新後檢查最終生效的設定。

常見故障：解析正常，為何仍無法連線？

回傳 198.18 位址，但網頁一直逾時

請優先確認連線是否回到核心。系統代理通常只會套用到遵循代理設定的應用程式，無法自然接管所有連往合成位址的連線。使用 TUN 時，請檢查 TUN 是否已啟動、路由是否安裝成功，以及是否有其他 VPN 搶占路由。測試期間只保留一個負責接管流量的網路工具，避免 DNS 和流量分別由不同執行個體處理。

關閉用戶端後，少數網站仍無法連線

應用程式或作業系統可能仍快取著合成位址，但負責還原映射的核心已經結束。請先還原系統 DNS 和路由，再關閉相關應用程式並清除 DNS 快取。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。瀏覽器本身也可能有快取，因此清除系統快取後，仍須重新啟動瀏覽器。

加入過濾清單後沒有變化

確認修改的是目前使用的設定，且沒有被其他設定或全域覆寫取代。
檢查過濾模式與網域寫法，確認新增的是實際查詢的網域，而不只是網址列中看到的主網域。
套用設定後，清除應用程式和系統中的舊 DNS 快取，再重新查詢並測試。
如果已回傳真實位址但仍無法連線，請改查規則、UDP 支援、伺服器狀態或內部 DNS，不要繼續擴大過濾範圍。

瀏覽器正常，遊戲或命令列程式異常

兩者可能使用不同的 DNS 流程，也可能一個遵循系統代理，另一個直接送出封包。應用程式內建的 DoH、硬編碼 IP 和區域網路多點傳播，不一定會經過相同的處理流程。網域嗅探可補充部分連線資訊，但無法還原所有協定中的網域，也不能取代完整的 DNS 和路由接管。

尤其是直接使用 IP 的連線，本來就沒有「查詢網域後分配假位址」這個步驟。此時應檢查 IP 規則、程序規則和連線記錄，而不是期待新增 fake-ip-filter 項目就能解決問題。

適用情境與修改前檢查清單

日常瀏覽、需要依網域細緻分流，且已穩定使用 TUN 的裝置，通常適合先測試 Fake-IP。依賴內部 DNS、特殊探索協定或位址一致性檢查的環境，則應將真實解析、內部上游和路由規劃一併納入排查清單。

先確認核心。記錄用戶端和核心版本，確認目前使用的核心支援相關設定欄位。
再確認兩條流程。DNS 查詢進入核心，合成位址的連線也回到同一個執行個體。
過濾範圍盡量精簡。只新增已確認需要真實位址的網域，並註明新增原因。
確認訂閱覆寫。更新訂閱後檢查最終設定，避免手動修復內容遭到覆蓋。
一次只調整一類設定。先調整過濾項目並觀察結果；不要同時更換 DNS、節點、規則和 TUN 參數。