Fake-IP 模式原理解析：198.18 保留位址、fake-ip-filter 與適用情境

Fake-IP 原理：先回傳映射位址，再處理實際連線

啟用 Fake-IP 後，查詢網域卻取得 198.18.x.x，通常不是 DNS 發生錯誤，而是核心回傳了用於本機映射的位址。理解這點前，先釐清兩個動作：DNS 回答「應用程式接下來要連到哪個位址」，代理規則則決定「這條連線要走哪個出口」。兩者彼此配合，但不是同一個開關。

本文的設定範例適用於 Clash Meta 後續發展的 mihomo 核心。不同用戶端的介面名稱與設定合併方式各異，舊版 Clash 核心也不一定支援所有 DNS 擴充欄位。修改前，請在用戶端的核心資訊與執行中的設定中確認實際生效內容，而不只是查看編輯器儲存的檔案。

網域連線會經過哪些步驟

應用程式查詢 example.com 的 IPv4 位址，請求送至 mihomo 的 DNS 服務。
核心從 Fake-IP 位址池分配一個位址，建立「網域 ↔ 假位址」映射，再將假位址回傳給應用程式。
應用程式連線至這個位址；連線必須再次由同一個核心接管，例如透過正確設定的 TUN 路由。
核心依據映射還原網域，執行規則比對，再透過直連或代理建立實際的目標連線。

主要優點是：對於可直接分配 Fake-IP 的查詢，DNS 不必先等待上游回傳真實位址，就能作出回應。網域資訊也能保留到分流階段。不過，後續直連、IP 類規則比對或某些代理協定仍可能需要進行真實解析；實際情況取決於規則、出口與核心行為。「DNS 回應更快」不代表「所有網頁都會更快」。

198.18.0.1/16 是什麼：位址池與保留網段

198.18.0.0/15 是供網路設備效能測試使用的特殊用途 IPv4 網段，範圍涵蓋 198.18.0.0 至 198.19.255.255，並非一般網站使用、可在全球路由的公網位址。常見設定中的 198.18.0.1/16，則是讓 Fake-IP 使用其中一個 /16 位址池；請勿將 /16 與整個 /15 混為一談。

設定為 198.18.0.1/16，不代表所有網域都會回傳 198.18.0.1。核心會管理位址池與映射，不同網域可能取得不同位址。這個位址也不是節點伺服器的位址，不必用它測速，更不應填入訂閱網址欄位。

看到保留位址：先確認是否為 Fake-IP 回應，不要立刻更換 DNS。
企業網路或實驗網路已使用該網段：可能造成路由衝突，請檢查路由表與位址池規劃。
變更位址池：還要一併檢查 TUN 路由、旁路由轉送與應用程式快取，不能只修改一行 YAML。

不要只為了「看起來像真實 IP」，就隨手把位址池改成 192.168.1.0/24。這個網段很可能與家中路由器、印表機或 NAS 所在網路重疊。保留位址的用途正是隔離這層映射，而不是讓介面上的數字看起來更熟悉。

Fake-IP 與 redir-host：如何選擇 DNS 模式

redir-host 通常會將上游解析出的真實位址回傳給應用程式，再搭配 DNS 映射等資訊處理連線；fake-ip 則主要回傳本機映射位址。這裡的模式名稱指的是 DNS 增強模式，不等同於用戶端首頁的「規則、全域、直連」模式。

比較項目	fake-ip	redir-host
應用程式收到的 A 記錄	通常是位址池中的映射位址	通常是上游回傳的真實 IPv4 位址
首次 DNS 回應	可先分配映射位址，減少等待上游的步驟	未命中快取時，通常需要等待真實解析
連線接管需求	假位址連線必須回到保有映射的核心	仍須正確接管，但一般網路也能辨識真實位址
常見相容性問題	位址探測、區域網路裝置探索、未經接管的程式	共用 IP、DNS 快取及網域關聯不完整等情況
適合優先嘗試的情境	接管完整、以網域規則分流的日常上網	依賴真實解析結果、Fake-IP 例外較多的環境

不必拘泥於單一模式。日常瀏覽且 TUN 接管完整時，可先使用 Fake-IP，再為確實受影響的服務設定例外；企業 VPN、複雜區域網路或依賴位址探測的服務，則可先確認真實解析模式是否更容易維護。判斷依據應是服務存取、記錄與路由是否一致，而不是只看一次 DNS 查詢耗時。

mihomo DNS 設定：最精簡範例與驗證方式

以下僅示範 dns 設定片段，並非完整訂閱設定。請合併至現有設定，避免出現兩個頂層 dns:。範例在本機 127.0.0.1:1053 監聽，供隔離測試使用；它不會自動將系統 DNS 改為這個連接埠，也不會自動啟用 TUN。

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

nameserver 是範例上游，不代表兩個位址在目前網路中都能連線，也不代表這裡已設定加密 DNS。請依網路環境與解析需求選擇上游；若改用 DoH 或 DoT，還須考量伺服器網域的引導解析、連線可用性及既有 DNS 分流策略，避免請求繞圈。

先測試核心，再檢查系統解析路徑

儲存設定並確認核心已成功載入後，請在已安裝 dig 的環境中執行以下指令。這裡以 -p 1053 明確指定測試連接埠，避免誤測系統目前使用的其他 DNS 服務。

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

若沒有其他過濾條件或策略覆寫，第一個指令的回答區應會出現 198.18.x.x，第二個指令則只會輸出位址。實際分配結果取決於核心的執行狀態，不必與特定截圖完全相同。若連線遭拒，請先檢查 DNS 開關、監聽連接埠與核心記錄，不要先更換節點。

確認直接查詢核心時，能取得符合預期的 A 記錄。
檢查用戶端的 TUN DNS 劫持或系統 DNS 轉送是否確實指向核心。
透過應用程式建立新連線，並在連線面板確認網域、命中規則與出口。
若看到舊結果，請清除應用程式與系統 DNS 快取，再以新連線重新測試。

fake-ip-filter 設定方式：回傳真實位址不等於直連

在範例明確設定的 blacklist 模式下，符合 fake-ip-filter 的網域不會分配 Fake-IP，而是進行真實解析。支援此欄位的 mihomo 也提供其他過濾模式，意義可能相反，因此移轉設定時，請一併檢查過濾模式與清單。若舊版核心提示不支援該欄位，請依相應核心文件調整，不要只消除錯誤而未確認設定意義。

範例中的 '+.lan' 可涵蓋 lan 及其子網域，'+.local' 也是相同用法。這是 mihomo 的網域比對語法，並非可任意組合的正規表示式。保留引號有助於維護，也能降低 YAML 特殊字元造成的解析問題。

三種設定應分開處理

回傳哪個位址：由 Fake-IP 模式與過濾策略決定。
向哪裡解析：由上游 DNS、nameserver-policy 等設定決定。
連線走哪裡：由 rules 與代理群組選擇決定。

因此，將某個 NAS 網域加入過濾清單，不會自動讓核心改向家中路由器查詢，也不會自動新增 DIRECT 規則。若網域只存在於路由器 DNS 中，仍須將該網域的解析導向正確的區域網路 DNS，並確保連線可直達對應網段。

維護清單時，建議每次只新增一個服務所需的網域範圍，並記錄修改前後的解析與存取結果。若直接加入範圍過廣的公用網域後綴，大量原本適合使用 Fake-IP 的請求便會改為真實解析，後續也更難釐清問題。

區域網路與遊戲情境：依實際問題新增例外

NAS、印表機與 .local 裝置探索

區域網路服務常見兩種路徑：一種是透過路由器提供的單播 DNS 解析裝置名稱，另一種是透過 mDNS 在區域網路內探索裝置。.local 常用於 mDNS，後者通常使用 UDP 5353，而非一般 DNS 的 53 連接埠。將 +.local 加入過濾清單，無法解決所有多點傳送探索問題。

若可直接透過 NAS 的區域網路 IP 存取，但主機名稱無法使用，請先檢查網域解析路徑；若裝置清單中完全看不到裝置，也要檢查防火牆、網路隔離、多點傳送與 TUN 路由。問題所在的網路層不同，排查工具也要跟著換。

遊戲登入、對戰 UDP 與延遲顯示

遊戲可能會利用網域解析結果判斷區域、列出伺服器、測試連線或顯示延遲。有些偵測機制無法接受保留位址，此時只針對受影響的網域嘗試真實解析，比停用所有 Fake-IP 更容易找出問題。

無法登入：檢查登入網域解析、HTTPS 連線與規則命中，不要直接歸因於 UDP。
可以登入但無法進入對戰：檢查遊戲 UDP 是否由核心接管，以及節點與出口是否支援所需的 UDP 流量。
延遲顯示異常但實際可玩：確認遊戲是否使用 ICMP 或獨立的探測網域；顯示數值不一定代表對戰連線的狀況。
只有切換模式後才出錯：完全關閉遊戲與啟動器，清除快取後重新建立連線。

不要預設所有遊戲網域都要加入過濾清單，更不要把「允許 UDP」當成降低延遲的保證。Fake-IP 處理的是位址映射；連線距離、出口壅塞、NAT 類型與遊戲伺服器狀態仍各自影響結果。

Fake-IP 無法存取時的排查順序

排查時每次只變更一個條件，並保留執行記錄。以下依設定到連線的順序逐項檢查，通常比反覆切換全域模式更有效。

確認執行中的設定：確認目前設定的 enhanced-mode 為 fake-ip，訂閱更新沒有覆蓋本機修改，且核心沒有載入設定錯誤。
確認查詢入口：直接查詢 127.0.0.1:1053，再與系統或瀏覽器的結果比較。瀏覽器的安全 DNS、應用程式內建的 DoH 可能會繞過預期的系統解析路徑。
確認接管範圍：一般 TUN DNS 劫持多半針對傳統 DNS 流量設定，無法自動將所有 HTTPS 加密 DNS 識別為一般 53 連接埠查詢。應用程式取得假位址後，連線也必須進入核心。
確認映射與快取：核心重新啟動、切換設定或變更位址池後，應用程式可能仍保留舊的假位址。先清除快取並重新啟動相關應用程式，再判斷是否需要調整核心的 Fake-IP 映射持久化設定。
確認規則：連線已帶有網域資訊卻走錯出口時，請檢查規則順序與代理群組，不要只修改 DNS。依賴目標 IP 的規則也可能觸發真實解析。
確認雙堆疊：分別測試 A 與 AAAA 記錄，並檢查 IPv6 接管情況。IPv4 查詢正常，不代表 IPv6 路徑也已正確設定。

最後應保留一份脈絡清楚、方便說明的設定：DNS 從何處進入、過濾項目為何存在、真實解析交由誰處理，以及連線由哪條規則接手。Fake-IP 的價值在於減少解析等待並保留網域關聯，而非取代路由、規則或網路品質檢查。