Fake-IP 與 redir-host 比較

先分清 DNS 模式與流量接管

dns.enhanced-mode 決定 Clash 內建 DNS 如何回應網域查詢。fake-ip 會回傳用於映射的虛擬位址；redir-host 則回傳上游解析出的真實位址。兩者都不能取代規則模式或全域模式，也不會決定連線最後使用哪個代理節點。

另一個層面是流量接管。系統代理通常只會影響遵循代理設定的程式；TUN 則透過虛擬網卡與路由接管更多 IP 流量。DNS 查詢是否進入核心、應用程式連線是否回到核心，都需要分開確認。只把設定中的模式改成 Fake-IP，不代表所有程式都會自動經過代理。

• 若想保留網域資訊以進行規則分流，且 DNS 與連線都由核心接管：優先測試 Fake-IP。
• 若應用程式必須取得真實 IP，或涉及區域網路裝置探索：先針對特定網域設定過濾，再評估 redir-host。
• 遇到逾時：先確認問題出在 DNS、路由還是連線出站，別同時修改模式、節點和規則。

Fake-IP 虛擬位址的運作方式

Fake-IP 的關鍵在於「網域與虛擬位址的映射」，並非永久改寫網站位址。常見的位址池為 198.18.0.1/16，屬於保留的基準測試位址範圍，並非網站實際部署的公網位址。這個位址必須由代理核心解析，不能當成一般目的地直接送往網際網路。

1. 應用程式要求解析某個網域，查詢送入 Clash 內建 DNS。
2. 核心會從位址池分配或重複使用一個虛擬位址，並儲存網域映射。符合條件的 A 查詢通常不必等候目標網域的真實 A 記錄回覆。
3. 應用程式連線至該虛擬位址；TUN 等接管鏈路會將連線交回核心。
4. 核心根據映射還原網域、比對規則，再交由對應的出站處理。直連通常仍須解析真實目的地；代理出站是否在遠端解析，則取決於通訊協定與出站實作。

為什麼首次連線有時會更快

傳統流程通常會在建立連線前等候真實 DNS 結果。Fake-IP 可縮短這段等待時間，也有助於依網域比對規則。不過，這不代表所有要求都會變快：代理交握、TLS、遠端解析及目標伺服器回應仍需時間；比對 IP 規則時也可能觸發真實解析。

解析結果出現 198.18.x.x，不代表網站故障，也不是實際出口 IP。直接對這個位址執行 ping，無法用來判斷節點延遲。請以實際服務連線進行測試，並搭配核心連線面板檢查規則、策略與錯誤訊息。

redir-host 的解析流程與限制

使用 redir-host 時，內建 DNS 會向設定的上游解析器查詢，並將真實位址回傳給應用程式。核心可以記錄解析所得的網域與 IP 對應關係，協助還原後續流量的網域資訊。但多個網域可能共用同一個位址，應用程式也可能繞過內建 DNS，因此這種關聯不一定能完整且唯一地還原原始網域。

真實位址對某些應用程式較合適，例如需要比對解析位址、直接將 IP 傳給其他程序，或裝置必須存取特定區域網路位址的情況。不過，回傳真實 IP 不代表一定會直連；若流量已由 TUN 接管，仍會依規則選擇出站。

兩種模式都不是防止 DNS 洩漏的開關。應用程式內建的 DoH、未受接管的 IPv6 流量，以及直接連線至外部 DNS 的程式，都需要分別排查。單次網頁 DNS 測試顯示某個解析器，也不足以證明所有程式都使用相同的查詢路徑。

Fake-IP 基本設定與接入條件

以下僅示範需要合併至現有設定的 dns 區段，不包含節點與代理群組。請保留現有訂閱的其他內容；若用戶端支援覆寫或合併設定，請在其持久化設定入口修改，避免下次更新訂閱時設定遭到覆蓋。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"

• listen 的 1053 是本文範例中的監聽埠，不是 HTTP 或 SOCKS 代理埠。此處僅監聽迴路位址，不會對區域網路提供 DNS 服務。
• default-nameserver 用於解析 DNS 伺服器本身的網域等引導情境。這裡的一般 DNS 引導查詢不具備 DoH 的加密特性。
• nameserver 是一般上游解析入口。使用 HTTPS 位址不代表所有 DNS 流量都會自動透過代理，仍須確認實際傳輸路徑。
• 作業系統的一般 DNS 設定通常無法直接指定 1053 埠。正式接入時需要用戶端的 DNS 接管、TUN DNS 劫持，或搭配本機轉發器；不能只填入 127.0.0.1 就認為設定完成。

若要對照測試 redir-host，可暫時將 enhanced-mode 改為 redir-host，其餘變數維持不變。Fake-IP 位址池與過濾清單不再負責分配虛擬位址。請先備份再重新載入設定；若 DNS 由用戶端管理，請確認產生的運行設定確實已變更。

fake-ip-filter 的指定例外

在常見的預設黑名單語意下，fake-ip-filter 代表「這些網域不分配 Fake-IP，而是回傳真實解析結果」，並非「這些網域不走代理」。是否直連仍由 rules 決定。支援切換過濾模式的 mihomo 版本也可能採用其他語意，複製清單前請先確認沒有另外啟用白名單模式。

先列出特定網域，再擴大範圍

假設家用 NAS 的網域是 nas.home.arpa，而應用程式收到虛擬位址後拒絕連線，可以先加入精確項目。若同一網域區域中的裝置都有相同問題，再使用核心支援的網域萬用字元語法擴大範圍。依 mihomo 常見的比對語意，+.home.arpa 可涵蓋根網域及其子網域；但這不是所有舊版核心都通用的寫法。

dns:
  fake-ip-filter:
    - "localhost"
    - "nas.home.arpa"
    - "+.home.arpa"
    - "*.lan"
    - "*.local"

這是局部修改範例，應合併至前一段既有的 dns 設定中，不可在 YAML 頂層再建立第二個同名的 dns 鍵。精確項目與涵蓋該項目的萬用字元項目可視需求擇一；長期使用的設定應移除冗餘項目。

過濾功能不會提供內網解析結果

將 NAS 網域加入過濾清單後，上游仍須知道它的真實位址。公共 DNS 通常不認識家庭內部網域；此時應將該網域的查詢交給路由器或內部 DNS，必要時使用 nameserver-policy 指定解析方式。只設定過濾而沒有正確的上游，問題就會從虛擬位址不相容變成網域解析失敗。

.local 常用於 mDNS，依賴區域網路多點傳播。加入 *.local 只能避免相關查詢被分配虛擬位址，不代表核心會代替系統完成 mDNS 探索。印表機、投影裝置仍可能需要多點傳播探索鏈路與可連通的區域網路路由。

檢查解析結果與連線路徑

排查分成三步：確認運行設定、直接查詢內建 DNS，再檢查應用程式連線。不要只看設定編輯器中的文字，也不要只憑瀏覽器能否開啟網頁就下結論。

1. 直接查詢 1053 埠

在已安裝 dig 的環境中，執行以下兩條指令。指令會明確查詢迴路位址的 1053 埠，不會因作業系統 DNS 設定不同而誤查其他解析器。

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

使用 Fake-IP 時，未經過濾的網域通常應回傳所設定位址池中的位址；實際分配值不固定。只有在過濾規則命中且內網上游可用時，NAS 網域才應取得對應的真實位址。查詢逾時時，先檢查監聽狀態與設定載入錯誤；若回傳真實公網位址，則繼續檢查模式、過濾規則與用戶端覆寫設定。

2. 查看規則與出站

開啟用戶端的連線面板，連線至待測網站，查看目標網域、命中的規則與使用的策略。若取得虛擬位址卻沒有對應的連線紀錄，請優先檢查流量是否繞過核心、是否有路由衝突，以及應用程式是否在另一台未受接管的裝置上使用該位址。

3. 清除舊狀態後重新測試

切換模式後，應用程式可能仍使用舊快取或既有連線。請先結束目標應用程式，再清除系統 DNS 快取並重新開啟。Windows 可執行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。應用程式內建的 DNS 快取不一定會隨系統快取一併清除。

若已啟用 profile.store-fake-ip，部分核心會持久化映射。此選項有助於還原既有映射，但無法解決所有逾時問題。調整位址池前，請依用戶端支援的方式清除舊映射並重新建立連線；不要直接刪除用途不明的設定檔。

依故障狀況選擇模式

• 一般網頁與常用應用程式運作正常：維持目前模式。沒必要為了抽象的「速度更快」而反覆切換。
• 只有 NAS、印表機或內網網域異常：優先處理過濾設定、內網 DNS 與區域網路路由，不必急著切換整個環境。
• 應用程式明確拒絕虛擬 IP：先將它實際查詢的網域加入例外；若依賴的網域很多且難以維護，再測試 redir-host。
• 所有 Fake-IP 連線都逾時：優先檢查虛擬位址區段的路由與流量接管。DNS 查詢成功不代表連線已進入 TUN。
• 使用 redir-host 時部分網站取得的位址不合適：檢查解析出口與代理出口是否相符，並依網域設定解析策略，不要盲目增加上游伺服器。

判斷時應以可重現的實際結果為準：在相同裝置、相同節點及相同網域下，分別檢查解析結果、規則命中情形與連線是否成功。Fake-IP 著重透過映射保留網域資訊並調整解析時機；redir-host 則著重提供真實位址給應用程式。模式選擇應符合實際的流量接管方式與應用程式需求，不應將任何一種模式視為適用所有情境的固定答案。