Clash Fake-IP 模式原理與設定：虛擬 IP 池如何減少 DNS 等待及適用情境

Fake-IP 的運作方式：先回傳映射 IP，再處理連線

啟用 Clash 的 Fake-IP 模式後，DNS 查詢可能會取得 198.18.0.2 這類 IP。它不是目標網站的公網 IP，也不是代理節點 IP，而是核心為網域配置的暫時映射位址。應用程式接著連線至這個位址，流量由同一個核心接管，再透過映射找回網域，進行規則比對並建立對外連線。

這套機制將「提供應用程式可連線的位址」和「確認伺服器的實際位址」分開處理。若代理出站支援將網域交由遠端解析，用戶端就不必先在本機完成目標網域的實際解析，應用程式即可開始連線。它主要減少連線前的 DNS 等待時間，不會直接增加線路頻寬，也無法保證所有網頁都載入得更快。

為什麼 198.18.0.0/16 不是公網 IP？

198.18.0.0/15 是保留給網路設備效能測試使用的 IPv4 網段，不是一般公網服務位址。Clash 設定常從中使用 198.18.0.0/16，常見寫法為 fake-ip-range: 198.18.0.1/16。這個前綴涵蓋 65,536 個 IPv4 位址，但不能直接將此數字視為核心保證可同時維護的映射數量。

核心會分配、記錄並回收 IP 池中的位址。同一個網域今天可能對應 198.18.0.2，但下次重新啟動或映射變更後，位址未必相同，因此不應將虛擬 IP 寫入長期靜態路由、伺服器允許清單或應用程式固定設定。如果企業網路、測試環境或其他 VPN 已使用這個網段，請先檢查是否有路由衝突，再決定要不要調整 IP 池。

Fake-IP 與 redir-host：DNS 等待發生在哪個階段？

兩種模式的主要差異在於「回傳給應用程式的位址」，而非「是否使用代理」。規則模式和全域模式決定連線使用哪個出站；enhanced-mode 則決定 DNS 增強處理方式，兩者屬於不同層級。

代理連線流程比較

1. redir-host：應用程式查詢網域，Clash 向上游 DNS 查詢實際 IP，收到結果後回覆應用程式；應用程式再連線至該位址，並由規則選擇出站。
2. Fake-IP：應用程式查詢網域，Clash 儲存「網域－虛擬 IP」映射並回覆；連線進入核心後，核心還原網域，再依規則選擇出站。
3. 代理支援以網域作為目標時：實際解析可在遠端進行；若最後選擇直連，或規則需要判斷目標 IP，仍可能觸發本機實際解析。

例如，假設某次未命中快取的上游 DNS 查詢耗時 120 毫秒，Fake-IP 可能讓應用程式在開始連線前不必等待這段時間。這裡的 120 毫秒僅為流程示意，不代表實測加速效果。實際耗時還會受到規則、節點交握、遠端解析和伺服器回應影響，不能直接推論整個網頁載入時間會縮短相同幅度。

同樣地，Fake-IP 不代表「完全不需要 DNS」。節點伺服器本身可能需要解析，直連網域需要實際 IP，某些 IP 規則也需要解析結果。若應用程式已透過 HTTP 或 SOCKS 代理直接提交網域，連線路徑也未必會經過上述虛擬 IP 配置流程。

基本設定：啟用映射並保留區域網路解析

以下範例用來說明 Clash Meta（現稱 mihomo）常見欄位之間的關係，並非可直接取代訂閱的完整設定。操作前請先備份目前設定，保留原有節點、策略群組與規則，再將 DNS 欄位合併至用戶端支援的覆寫設定。請勿在同一個 YAML 檔案中重複建立兩個頂層 dns 鍵。

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

• enable：啟用核心 DNS；只修改模式而未啟用 DNS，無法建立預期的查詢流程。
• listen：範例監聽本機 UDP/TCP 1053 連接埠，方便單獨測試；系統預設 DNS 使用 53 連接埠，不會自動改為連線至 1053。
• enhanced-mode：選擇 fake-ip；進行對照測試時可改用 redir-host，其餘條件維持一致。
• nameserver：設定需要實際解析時使用的上游 DNS。範例使用一般 DNS，沒有加密傳輸；請依網路可連線性及隱私需求選擇。
• fake-ip-filter：依一般的排除模式設定，符合條件的網域會回傳實際解析結果，而非由 IP 池配置位址。

部分 mihomo 版本提供 fake-ip-filter-mode，可變更過濾清單的用途。本文依排除模式說明；若目前設定明確使用 whitelist 模式，就不能將清單解讀為「這些網域不使用 Fake-IP」。不同用戶端所附的核心版本和預設過濾項目也可能不同，請以實際生效的設定為準。

fake-ip-filter 例外清單：依故障網域新增例外

一般所說的「Fake-IP 白名單」，通常是指「不配置虛擬 IP 的例外清單」。加入清單不代表自動直連，也不代表自動使用路由器 DNS。網域是否直連由規則決定，實際 IP 要向哪個 DNS 查詢則由 DNS 策略決定，這三項設定需要分別確認。

區域網路裝置與私人網域

印表機、NAS、路由器管理頁面和企業內部服務，經常仰賴區域網路 DNS。對於 home.arpa 或組織內部網域，可新增精確的後綴例外，並將該網域交由正確的本機 DNS 解析。公共 DNS 通常不知道內部主機的 IP，只新增過濾項目仍可能收到找不到網域的回應。

.local 通常透過 mDNS 解析，其裝置探索機制與一般單播 DNS 不同。將它加入過濾清單只能避免配置 Fake-IP；若仍無法探索裝置，請進一步檢查區域網路存取權限、多播和 TUN 路由，而不是一再新增公共上游 DNS。

會驗證解析結果或將 IP 傳給其他裝置的應用程式

部分遊戲、語音、時間同步和裝置探索程式會檢查 DNS 解析結果，或將解析出的 IP 傳給另一台裝置。另一台裝置沒有本機核心維護的映射，就無法透過這個虛擬 IP 連線至目標。此時請從連線記錄找出實際網域，先新增單一例外，再重新測試完整功能。

• 優先使用精確比對：只有單一服務異常時，先加入它實際查詢的網域，不要直接排除整個大型網域後綴。
• 依故障情況驗證：網頁能開啟不代表語音、連線遊戲或裝置探索也正常；測試時應重現先前失敗的操作。
• 不要按應用程式類別一律排除：遊戲、NTP 或 STUN 並非天生就與 Fake-IP 衝突，是否需要例外取決於程式實作及流量接管方式。

mihomo 常見的網域比對語法中，+.home.arpa 可比對該網域及其子網域。若使用較舊的 Clash 核心，請先確認是否支援相應語法。變更過濾項目後，也要清除應用程式和系統快取，否則應用程式可能繼續使用先前取得的虛擬 IP。

TUN 與系統代理：讓虛擬 IP 連線回到核心

Fake-IP 是 DNS 處理方式，TUN 則是流量接管機制，兩者可以搭配使用，但不是同一個開關。TUN 通常較適合接管不遵循系統代理設定的應用程式；系統代理主要影響主動採用系統 HTTP、HTTPS 或 SOCKS 設定的程式，無法保證接管任意應用程式對虛擬 IP 發起的連線。

先測試 DNS，再確認連線路徑

1. 確認設定已載入，且 DNS 監聽連接埠確實為 127.0.0.1:1053。若出現連接埠已被使用的訊息，請先排查其他 DNS 服務或重複執行的核心。
2. 直接查詢該連接埠，確認不在過濾清單中的網域是否取得 IP 池內的 A 記錄。
3. 檢查系統或應用程式實際使用的 DNS。直接查詢測試成功，不代表系統預設查詢已送進 Clash。
4. 連線至目標並查看連線記錄，確認核心能還原目標網域，且命中的規則與出站符合預期。

# macOS / Linux：使用系統已提供或已安裝的 dig
dig @127.0.0.1 -p 1053 example.com A

# 對照預設解析流程
dig example.com A

第一個指令可能會回傳 198.18.0.2 等 IP 池內位址，實際配置值不固定。若第一個指令取得虛擬 IP、第二個仍取得公網 IP，應優先檢查 DNS 入口，而非認定 Fake-IP 設定未載入。瀏覽器使用的加密 DNS、應用程式內建解析器和快取，也可能使實際連線改走其他路徑。

TUN 設定中的 dns-hijack 可用來接管符合條件的 DNS 流量，常見目標寫法包括 any:53，但實際支援方式和涵蓋範圍會依核心、平台與通訊協定而異。它不是所有 DNS 的總開關：透過 HTTPS 443 連接埠傳送的 DoH，不會因為接管傳統 DNS 53 連接埠就自動進入核心 DNS。

常見故障排查：逐項檢查 IP 池、快取與規則

取得 198.18 IP 後網頁無法開啟

先確認該連線是否出現在核心記錄中。如果完全看不到，通常要排查應用程式是否繞過代理、TUN 路由是否生效，或是否有其他 VPN 搶用路由。如果看得到網域和策略，再檢查節點狀態、直連 DNS 與規則，不要一開始就切換整套 DNS 模式。

重新啟動核心後，少數應用程式暫時無法使用

應用程式可能快取了舊的虛擬 IP，但核心已重新建立映射。請先結束並重新開啟故障應用程式，再依系統要求清除 DNS 快取。Windows 可在終端機執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。這些指令不保證會清除瀏覽器或應用程式本身的快取。

部分核心提供 profile.store-fake-ip 來保存映射，減少重新啟動前後不一致的情況，但無法修復 DNS 被繞過、多個核心分別維護 IP 池或路由衝突等問題。未確認支援情況前，請勿直接將此欄位加入舊版核心設定。

加入過濾清單後仍無法開啟

先重新查詢，確認結果是否已從虛擬 IP 變成實際 IP。如果仍是 IP 池內的位址，請檢查過濾語法、模式和快取；如果已是實際 IP，則要確認該內部網域是否由正確的 DNS 解析，以及連線是否走對出站。過濾項目只會改變位址的產生方式，不會取代分流規則。

何時保留 Fake-IP，何時改用 redir-host 比較

• 優先保留 Fake-IP：DNS 與連線都由同一個核心處理，主要依網域分流，且希望減少代理連線前的本機解析等待。
• 先新增精確例外：只有少數內部服務、裝置探索或特定應用程式異常，其他連線都正常。
• 對照測試 redir-host：許多程式仰賴實際 IP，或目前環境無法穩定接管虛擬 IP 連線時，可比較兩種模式的實際相容性。

每次只調整一個變數，並記錄網域、DNS 回應、命中規則和錯誤訊息。先確認查詢進入正確的 DNS，再確認連線回到正確的核心，最後檢查上游解析與出站品質。比起同時修改 IP 池、節點和所有規則，這樣更容易找出問題，也能保留可還原的設定。