Clash Fake-IP 模式是什麼：DNS 回傳假位址的原理與適用情境

Fake-IP 不是錯誤位址，而是一張臨時號碼牌

應用程式造訪網站時，通常會先向 DNS 查詢網域對應的 IP 位址，再向該 IP 建立 TCP、UDP 或 QUIC 連線。傳統流程中，DNS 必須先提供真實位址，連線才能繼續。Fake-IP 改變的正是這一步：Clash 或 mihomo 內建的 DNS 先從保留位址池分配一個位址，並將「網域—假位址」的對應關係寫入記憶體。

常見的位址池是 198.18.0.0/16。這段 IPv4 位址由 RFC 2544 保留作為網路設備基準測試用途，不應在公網路由。mihomo 設定通常寫成 198.18.0.1/16，可分配約 65534 個位址。瀏覽器看到的可能是 198.18.0.23，但它不會真的前往公網尋找這台主機。

當應用程式隨後連線至 198.18.0.23:443 時，Clash 核心會從對應表取回原始網域，例如 www.example.com。規則引擎此時可以直接依網域比對 DOMAIN、DOMAIN-SUFFIX、GEOSITE 等規則，再決定使用代理、直連或拒絕。若流量經由代理，網域也可交由代理鏈路處理；若規則要求直連，核心才透過設定的 DNS 伺服器取得真實位址。

一次存取中發生了什麼

瀏覽器查詢 api.example.com 的 A 記錄。
Clash DNS 從 Fake-IP 位址池回傳 198.18.0.23，同時儲存對應關係。
瀏覽器向 198.18.0.23:443 建立連線。
系統代理、透明代理或 TUN 模式會將這條連線交給核心。
核心還原網域，依規則群組選擇 DIRECT、PROXY 或其他策略。
需要真實 IP 時，由核心或代理伺服器完成解析，再連線至目標網站。

「省下一次 DNS 往返」指的是應用程式不必等待公網權威解析完成，就能先取得本機回應並發起連線。真實解析並沒有憑空消失，而是延後、合併，或移至代理端完成。最終延遲仍會受到 DNS 伺服器、代理節點與目標網路影響。

Fake-IP 與 Redir-Host 的核心差異

Redir-Host 是另一種常見的增強 DNS 模式。它會先完成真實 DNS 查詢，再將真實 IP 回傳給應用程式。應用程式連線至真實 IP 後，核心會嘗試結合 DNS 對應、連線資訊或網域嗅探來還原網域。其結果更接近一般網路行為，因此對區域網路裝置，以及少數嚴格檢查 DNS 結果的應用程式更友善。

Fake-IP 則優先保留網域資訊。進行規則判斷時，核心已經知道這條連線最初造訪的網域，不必只依賴目標 IP，也較不容易受到同一個 IP 承載多個網站的影響。CDN 情境尤其明顯：數百個網域可能共用同一個邊緣位址，只看 IP 很難準確區分服務。

比較項目	Fake-IP	Redir-Host
回傳給應用程式的位址	通常是 198.18.0.0/16 內的保留位址	DNS 查詢取得的真實位址
網域規則識別	透過對應直接還原，通常更穩定	依賴 DNS 對應或嗅探補充
首次 DNS 回應	本機快速分配位址	等待上游 DNS 回傳結果
區域網路相容性	部分網域需要加入過濾清單	通常更接近系統原有行為
適用情境	TUN、透明代理、精細網域分流	簡易系統代理、特殊裝置相容性

兩種模式沒有絕對優劣。桌面裝置使用 TUN 接管流量，且規則以網域為主時，Fake-IP 通常更省事。路由器旁路由、區域網路探索、印表機控制或舊版應用程式較多時，可以先測試過濾規則；若仍有異常，再切換至 Redir-Host 進行比較。

mihomo 中的 Fake-IP 設定方式

以下範例適用於 mihomo 1.19 系列常見的設定結構。不同圖形化用戶端可能會將選項拆分到介面中，但最終都必須產生對應的 YAML。修改前先複製目前設定；訂閱設定會在更新時覆蓋本機內容，建議優先使用用戶端提供的覆寫、Mixin 或擴充腳本功能。

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-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost.ptlogin2.qq.com"
    - "+.pool.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

逐項理解設定

enable: true：啟用內建 DNS。只寫 enhanced-mode 卻未啟用 DNS，不會產生預期效果。
listen: 127.0.0.1:1053：只在本機 1053 埠監聽。一般使用者程序直接監聽 53 埠可能受到權限限制，也可能與系統 DNS 服務衝突。
ipv6: false：不向應用程式回傳 AAAA 結果。網路具備穩定 IPv6，且規則也涵蓋 IPv6 時可以啟用，但應同時檢查直連與代理鏈路。
enhanced-mode: fake-ip：選擇 Fake-IP 增強模式。若寫成 redir-host，DNS 會回傳真實位址。
fake-ip-range：指定 IPv4 位址池。一般保留預設值，不要改成家庭區域網路使用的 192.168.0.0/16 或 10.0.0.0/8。
fake-ip-filter-mode: blacklist：清單內的網域略過 Fake-IP，回傳真實解析結果。這是最常用的行為。
nameserver：處理一般網域解析。範例使用 DoH，連線埠通常為 443。
proxy-server-nameserver：專門解析代理節點伺服器的網域，避免解析節點位址時出現循環依賴。

驗證 Fake-IP 是否生效

macOS 或 Linux 可使用 dig 指定本機 DNS 埠。Windows 可使用支援自訂埠的 DNS 工具，或暫時將監聽埠調整為系統可查詢的 53 埠後再測試。以下指令不會修改系統設定：

dig @127.0.0.1 -p 1053 www.example.com A

# 預期結果類似：
# www.example.com.  1  IN  A  198.18.0.2

如果回傳公網真實 IP，先檢查實際載入的設定是否仍為 redir-host，再確認該網域是否命中 fake-ip-filter。如果查詢逾時，可使用 lsof -nP -iUDP:1053 或 ss -lunp 查看埠是否正在監聽。圖形化用戶端還應確認目前執行中的設定，而不只是查看訂閱原始檔案。

mihomo 啟用 external-controller: 127.0.0.1:9090 後，也可以透過控制介面查詢 DNS。未設定控制介面密鑰時，範例請求如下：

curl "http://127.0.0.1:9090/dns/query?name=www.example.com&type=A"

若控制介面設定了 secret，請求必須附帶對應的 Bearer 憑證。9090 控制埠不應直接暴露於公網，家庭區域網路共用時也應設定存取限制。

fake-ip-filter 應該怎麼寫

fake-ip-filter 的作用是讓特定網域略過假位址分配，直接取得真實 DNS 結果。通常需要過濾的不是「無法開啟的網站」，而是依賴真實位址、區域網路位址或特殊 DNS 記錄才能運作的服務。清單過大反而會削弱 Fake-IP 的網域對應優勢。

適合加入過濾清單的類型

區域網路名稱：*.lan、+.local、路由器管理網域及 NAS 自訂網域。
時間同步：部分 NTP 用戶端只接受直接解析出的 UDP 目標，可過濾 +.pool.ntp.org。
網路連線檢測：某些系統會透過固定網域與回傳內容，判斷是否需要跳出飯店、機場或校園網路的認證頁面。
裝置探索與投放：印表機、電視、喇叭與投放裝置可能依賴 mDNS、單播 DNS 及區域網路位址協同運作。
明確驗證 DNS 位址的應用程式：少數程式會比較 DNS 結果與實際連線位址，保留位址可能造成異常。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "router.asus.com"
    - "miwifi.com"
    - "+.pool.ntp.org"
    - "time.windows.com"
    - "time.apple.com"

*.lan 通常用於比對子網域，+.local 在 mihomo 網域比對語法中可涵蓋根網域及其子網域。不同核心版本對萬用字元表達式的支援可能不同，移植舊版 Clash 設定時應查看執行記錄。最穩妥的排查方式是先填寫完整網域，確認恢復後再擴大比對範圍。

白名單模式不是通用最佳化選項

mihomo 支援將 fake-ip-filter-mode 設為 whitelist。此時邏輯會反轉：只有清單內的網域使用 Fake-IP，其他網域回傳真實位址。這適合希望逐步啟用 Fake-IP 的特殊環境，但容易造成規則行為不一致，不建議只為了「減少假位址」就隨意啟用。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: whitelist
  fake-ip-filter:
    - "+.example.com"
    - "+.example.net"

調整過濾清單時，一次只增加一到兩個項目。儲存設定、重新載入核心、清除系統 DNS 快取，然後重現問題。macOS 可執行 sudo dscacheutil -flushcache，Windows 可執行 ipconfig /flushdns。瀏覽器也可能保留獨立 DNS 快取，完全退出瀏覽器後再測試會更可靠。

哪些情境更適合 Fake-IP

TUN 模式接管整台裝置的流量

TUN 會建立虛擬網卡，在網路層接收比系統代理更廣泛的流量。命令列工具、部分遊戲啟動器，以及不讀取系統代理的應用程式，也能進入核心。Fake-IP 回傳的保留位址必須由核心接收，因此它與 TUN、透明代理或路由器重新導向搭配最自然。

如果只啟用 Fake-IP，卻沒有啟用系統代理、TUN 或透明轉送，應用程式可能直接向 198.18.0.0/16 發送封包，最後表現為連線逾時。此時 DNS 看似正常，真正缺少的是流量接管鏈路。排查時應同時查看 DNS 查詢記錄與連線記錄。

規則主要依網域組織

設定中大量使用 DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOSITE 或規則集時，Fake-IP 可以在建立連線階段保留網域脈絡。相較於只取得 CDN IP 後再猜測網域，這種方式更容易說明規則為何命中。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP,CN,DIRECT,no-resolve 中的 no-resolve 表示不要只為了比對這條 IP 規則而額外觸發 DNS 解析。在 Fake-IP 環境下，這能減少不必要的查詢，但是否使用仍要配合前面的網域規則順序。規則會由上而下比對，第一條命中後即停止。

希望降低本機 DNS 污染影響

應用程式會先收到本機 Fake-IP，不直接依賴電信業者 DNS 回傳的目標位址。實際解析可交由加密 DNS 或代理鏈路處理，因此錯誤回應與解析路徑洩漏更容易控制。不過，Fake-IP 不是獨立的安全開關：若 nameserver 仍指向不穩定的明文 DNS，或代理節點的網域解析設定錯誤，問題仍可能存在。

Fake-IP 不適用或需要謹慎使用的情境

區域網路裝置與企業內網網域較多

企業內部 DNS 可能將 git.company.test 解析至 10.20.0.15，家庭 NAS 也可能依賴路由器下發的搜尋網域。若所有查詢都送往公用 DoH，內網網域會直接解析失敗；即使 Fake-IP 成功分配位址，後續也找不到真實服務。

這種情況應透過 nameserver-policy 為內網後綴指定內部 DNS，而不是把所有網域不加區分地加入過濾清單。例如內部 DNS 位於 10.20.0.53：

dns:
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
  nameserver-policy:
    "+.company.test":
      - 10.20.0.53
  fake-ip-filter:
    - "+.company.test"

旁路由沒有完整接管保留網段

路由器將 Fake-IP 回傳給用戶端後，必須確保送往 198.18.0.0/16 的流量回到執行 mihomo 的裝置。策略路由、iptables 或 nftables 規則遺漏 UDP 時，常見情況是網頁能開啟，但 QUIC、語音或遊戲連線失敗。此時應檢查 TCP 與 UDP 是否都進入 TUN 或透明代理鏈路。

應用程式依賴真實 DNS 回應

網路診斷工具、DNS 管理工具，以及少數反作弊或裝置探索程式，可能需要看見真實的 A、AAAA、PTR 或 SRV 記錄。對這類程式，全域切換 Redir-Host 往往過於激進；建議優先將明確網域加入過濾清單，或讓該程式的 DNS 查詢繞過 Clash。

常見故障與排查順序

DNS 回傳 198.18 位址，但網頁無法開啟

確認系統代理或 TUN 已啟用，而不只是啟用了內建 DNS。
檢查連線記錄中是否出現目標網域；完全沒有記錄通常表示流量未進入核心。
檢查 198.18.0.0/16 是否被其他 VPN、虛擬機器軟體或公司路由佔用。
暫時停用 QUIC，改用 TCP 443 進行對照測試，判斷是否只有 UDP 未被接管。
將目標網域加入 fake-ip-filter；若立即恢復，再繼續檢查應用程式相容性。

只有區域網路網域無法開啟

先使用內部 DNS 直接查詢，例如 dig @192.168.1.1 nas.lan。若能取得 192.168.1.20，表示內部解析正常。接著為該後綴設定 nameserver-policy，並加入過濾清單。還要確認規則中私有網段位於代理兜底規則之前：

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

訂閱更新後設定被還原

訂閱提供的是遠端設定快照。用戶端更新訂閱時，本機直接編輯的 YAML 可能會被覆蓋。應在用戶端的覆寫功能中維護 DNS 區段，例如進入「設定」→「配置」→「全域擴充」或對應的 Mixin 頁面。具體名稱會隨用戶端版本變化，但原則相同：訂閱負責儲存節點與規則，本機擴充負責儲存裝置相關的 DNS、TUN 與監聽埠設定。

切換模式後仍看到舊結果

DNS 快取可能同時存在於作業系統、瀏覽器與 Clash 核心三層。先重新載入設定或重新啟動核心，再清除系統 DNS 快取，最後完全退出瀏覽器。Fake-IP 記錄的 TTL 通常設定得較短，但已建立的連線不會因切換 DNS 模式而立即重建。

設定結論：先確保流量接管，再最佳化 DNS

Fake-IP 的價值不在於回傳特殊位址，而在於將網域資訊穩定保留至規則比對階段。它讓 TUN 與透明代理更容易依網域分流，也能將真實解析放到更合適的網路路徑上。看到 198.18.x.x 不代表 DNS 故障，前提是連線隨後確實進入 Clash 核心。

實用設定可以從預設位址池、黑名單過濾模式及兩個可靠的 DNS 上游開始。區域網路網域交給 nameserver-policy，必須取得真實位址的網域則放入 fake-ip-filter。發生問題時，依照「DNS 是否監聽—查詢是否回傳—連線是否被接管—規則是否命中—真實解析是否成功」的順序檢查，比反覆切換節點更快。