Fake-IP 與 Redir-Host 比較：Clash DNS 增強模式、TUN 設定與適用情境

兩種 DNS 增強模式的核心差異

Fake-IP 與 Redir-Host 決定的是：Clash 接管 DNS 查詢後，要回傳什麼位址給應用程式，以及後續連線如何對應回網域名稱。它們不是「規則模式」或「全域模式」的替代選項，也不會決定節點通訊協定。排查問題時，應分別檢視 DNS 回應、流量接管、規則比對與對外連線。

以下設定範例主要以 Clash Meta（mihomo）為參考。傳統 Clash、ClashX 的不同核心及各類圖形化用戶端，支援的欄位與設定覆寫方式可能有所不同。請先在用戶端的「關於」或核心資訊中確認名稱，再檢視執行中的設定；不能只憑應用程式名稱判斷設定是否相容。

比較項目	Fake-IP	Redir-Host
應用程式取得的位址	通常是從位址池分配的虛擬 IPv4 位址	上游 DNS 解析出的實際位址
網域名稱對應方式	透過虛擬位址與網域名稱的對應關係	透過 DNS 快取中的網域名稱、位址對應等資訊
主要適用情境	由 TUN 接管，且需要穩定保留網域資訊的連線	應用程式必須取得實際 DNS 位址的相容性情境
主要檢查項目	DNS 與連線是否交由同一個核心處理、對應關係是否有效	上游解析是否正常、網域對應資訊是否完整

Fake-IP：先分配虛擬位址，再對應網域名稱

單次連線的處理順序

應用程式查詢某個網域的 A 記錄，查詢送達核心的 DNS 服務。
核心從設定的虛擬位址池分配位址，並儲存「網域名稱 ↔ 虛擬位址」的對應關係。
應用程式連線至這個虛擬位址，再由 TUN 或其他接管機制將連線交回核心。
核心依據對應關係找回網域名稱，並根據規則選擇對外連線方式；是否接著在本機解析實際位址，取決於規則、對外連線類型與通訊協定能力。

常見設定 fake-ip-range: 198.18.0.1/16 使用保留作為網路基準測試的位址範圍。這些位址不是目標網站的公網位址，也不是節點位址。在這條處理流程下，瀏覽器能開啟網頁，但系統查詢結果顯示 198.18.x.x，屬於預期情況。

Fake-IP 的優點是能明確將「應用程式準備連線的位址」對應至網域名稱，不必只靠實際 IP 反推存取目標。多個網域可能共用 CDN 位址，因此實際位址與網域名稱並非一對一；虛擬位址對應能降低判斷上的模糊空間。但這不代表所有請求都會變快，也無法解決訂閱失效、節點無法連線或規則錯誤等問題。

Redir-Host：回傳實際位址並保留解析對應

Redir-Host 會先完成實際 DNS 解析，再將結果回傳給應用程式。應用程式看到的是實際解析位址，核心則利用已觀察到的 DNS 記錄等資訊對應網域名稱。它不是針對每條連線都向公網執行一次 PTR 反向查詢；這裡所說的「網域回查」，主要是從既有對應資料中還原網域脈絡。

對於會檢查解析結果、比對介面位址或自行處理網路連線的應用程式，這種方式較直觀。不過，如果應用程式使用自己的加密 DNS、直接連線至寫死的 IP，或 DNS 查詢未經過核心，網域對應資訊就可能不完整。多個網域共用同一個位址時，也不能將單一 IP 視為唯一的網域識別資訊。

切換至 Redir-Host 前，先確認問題原因

只有某台印表機或某個內部網域異常：優先為該目標設定 Fake-IP 例外及正確的內部 DNS，不必立刻切換全域模式。
應用程式明確要求實際 DNS 結果：可以使用 Redir-Host 進行對照測試，同時記錄規則命中情況與解析結果。
節點連線逾時：先檢查對外連線位址及網路是否可連通。切換 DNS 增強模式不一定會改變節點握手結果。

為何 TUN 模式常搭配 Fake-IP

TUN 會在系統網路層接收路由至虛擬網卡的 IP 封包，適合接管不遵循系統 HTTP 代理設定的應用程式。不過，IP 封包本身通常不會直接帶有原始網域名稱。透過 Fake-IP 對應，核心收到虛擬目標位址時便能找回網域名稱，因此常用於 TUN 模式下依網域規則分流。

兩者仍是獨立設定：啟用 TUN 不代表 DNS 一定會送進核心，選用 Fake-IP 也不代表所有應用程式連線都已接管。瀏覽器的安全 DNS、另一個 VPN 的路由，以及企業下發的 DNS 政策，都可能讓查詢與連線走不同路徑。

mihomo 設定範例

以下僅示範 DNS 與 TUN 部分，不包含節點、策略群組及完整規則，不能直接當作可連線的訂閱使用。合併至現有設定時，應修改已有的同名區塊，避免出現兩個頂層 dns 或 tun 鍵。

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

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

這裡的 1053 是本機 DNS 測試監聽埠，不是 HTTP、SOCKS 或混合代理埠。範例中的上游 DoH 位址必須能透過目前網路及核心的 DNS 對外連線策略連線；若無法連線，應改用目前環境可用的解析服務，而不是反覆重新啟動用戶端。

dns-hijack 用於處理 TUN 接收到、目的埠符合指定值的 DNS 流量。它不會自動解密瀏覽器透過 HTTPS 傳送的 DoH 請求，也不保證能攔截所有系統的本機 DNS 通訊。TUN 也需要相應的系統權限或服務支援；若權限不足，應先處理啟動記錄中的錯誤。

fake-ip-filter 設定方式與區域網路例外

在常見的預設黑名單語意下，fake-ip-filter 列出的網域不會分配 Fake-IP，而是依實際解析流程回傳結果。較新版的 mihomo 也提供過濾模式等擴充欄位；如果設定明確指定了 fake-ip-filter-mode，應先確認其作用，不要直接套用預設語意。

只將例外套用至確實需要的網域

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.home.arpa"

printer.home.arpa 是教學用的區域網路名稱，請替換成實際裝置的網域。單一裝置適合使用精確名稱；*.lan 這類項目則用於符合該後綴的子網域。不同核心對萬用字元的比對範圍可能不同，不應將這些字串視為正規表示式，也不要未經確認就混用規則清單語法。

過濾不等於直連：過濾只是不回傳虛擬位址，改變 DNS 回應方式。連線是否直連，仍由規則與對外連線策略決定。
過濾不等於指定 DNS：內部網域通常需要由路由器或公司 DNS 解析。必要時，再使用核心支援的 nameserver-policy 設定對應的解析器。
過濾無法取代服務探索：.local 通常與 mDNS 有關。印表機探索也可能仰賴多點傳播、網卡選擇與防火牆；新增網域例外不保證能恢復探索功能。

切換模式後的驗證步驟

一次只變更一項設定。先儲存目前可正常運作的設定，並記錄原本的增強模式、DNS 上游、TUN 狀態及異常網域。圖形化用戶端可能會以介面設定或覆寫檔案蓋過訂閱；編輯訂閱原始檔後，應在執行中的設定確認最終值確實已變更。

重新載入設定並檢查記錄：確認 DNS 成功監聽、TUN 建立成功，且沒有埠被占用或欄位解析錯誤。
直接查詢核心 DNS：在已安裝 dig 的 macOS 或 Linux 環境中，使用下方指令查詢範例網域。
比較系統解析路徑：接著執行未指定伺服器的查詢。若兩次結果不同，請先確認系統查詢是否確實經過核心。
重新建立應用程式連線：結束相關應用程式後重新開啟，必要時清除系統 DNS 快取，避免舊的實際位址或虛擬位址影響判斷。
查看連線記錄：確認目標網域、命中規則及實際對外連線方式，不要只看網頁是否開啟。

# 直接查詢上文設定的核心 DNS
dig @127.0.0.1 -p 1053 example.com A +short

# 查詢系統預設解析路徑
dig example.com A +short

在 Fake-IP 模式下，未被過濾的 A 查詢通常會回傳設定位址池中的位址；在 Redir-Host 模式下，則會回傳上游提供的實際記錄。example.com 僅用來示範測試方式，實際排查時還需要查詢發生問題的網域。請勿以 AAAA 查詢是否出現虛擬 IPv4 位址，判斷 Fake-IP 是否生效。

依作業系統清除 DNS 快取

Windows 可在命令提示字元中執行 ipconfig /flushdns。macOS 常用以下指令，第二行會向系統 DNS 服務傳送訊號；執行時請依提示輸入本機管理員密碼。使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches；其他發行版請依實際使用的 DNS 服務處理。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清除系統快取不會自動清除瀏覽器內部快取，也不保證仍有效的 Fake-IP 對應會保留下來。切換模式後，請關閉舊連線並重新測試；若核心重新啟動後經常遇到舊的虛擬位址，可檢查用戶端是否支援並已啟用 Fake-IP 對應持久化。

常見問題與優先檢查項目

現象	優先檢查項目	處理方向
解析出 198.18.x.x，但連線逾時	連線是否回到同一個核心、TUN 路由是否存在	檢查路由排除項目、並行運作的 VPN 及過期對應
瀏覽器正常，但某個應用程式無法使用	應用程式自訂 DNS、位址檢查或獨立網路堆疊	精確過濾該應用程式使用的網域後重新測試
切換後仍回傳實際位址	實際執行的設定、過濾項目、查詢伺服器	先直接查詢核心監聽埠，再檢查系統解析路徑
印表機或內部網站無法使用	內部 DNS、mDNS、私有網路路由及防火牆	分別處理實際解析與直連規則
出現憑證名稱不符	目標網域、解析結果、入口網站驗證或中間代理	檢查憑證與連線目標，不要停用憑證驗證

另外，ping 失敗不能單獨證明網站無法存取。ICMP 與瀏覽器使用的 TCP、QUIC 請求並非同一種連線；Fake-IP 的 ICMP 處理方式也會受到核心與接管方式影響。建議優先使用實際應用程式發出請求，並搭配連線記錄進行確認。

模式選擇與最後確認

若環境主要使用 TUN 接管，且希望依網域穩定分流，可先使用 Fake-IP，再針對確實有相容性需求的網域新增少量例外。若應用程式依賴實際 DNS 回應，可使用 Redir-Host 進行對照驗證；切換後仍應保留正確的 DNS 上游與網域規則。

最後只要確認四件事：DNS 查詢交由誰處理、應用程式取得什麼位址、連線由誰接管，以及規則選擇哪種對外連線方式。四個環節都有依據後，再決定要變更增強模式、過濾清單或路由。若要查閱代理埠與規則概念，請參考使用文件與術語表。