1. DNS 模式與流量接管是兩種不同設定

dns.enhanced-mode決定核心如何回覆 DNS 查詢；系統代理與 TUN 則決定應用程式的連線如何進入核心。兩者不能互相取代。啟用 Fake-IP，不代表系統的所有 DNS 查詢都已被接管；啟用 TUN，也不代表瀏覽器內建的加密 DNS 一定會交由核心解析。

本文討論使用 mihomo 核心的 Clash 用戶端。舊版 Clash、不同分支的核心，以及用戶端的覆寫功能都可能造成差異。操作前請先備份目前的設定、記下核心版本，並確認執行中的設定裡dns欄位內容，不要只檢查訂閱原始檔。

  • 系統代理：如果應用程式透過 HTTP 代理傳送網域名稱，核心就能直接取得目標名稱，不一定需要依賴本機 DNS 的 Fake-IP 對應。
  • TUN：接收應用程式傳送的 IP 封包。若要還原原始網域名稱，DNS 接管與對應表尤其重要。
  • DNS 監聽：例如127.0.0.1:1053，這只是核心接收查詢的位置。系統仍須透過適當的轉送或攔截路徑，將查詢送到這裡。

判斷設定是否生效時，請分別確認「DNS 查詢送往何處」和「後續連線送往何處」。只看用戶端的主開關，無法確認這兩條路徑是否一致。

2. Fake-IP 位址分配與網域回查流程

Fake-IP 的核心概念是建立「網域名稱與合成 IP」的對應。應用程式查詢某個網域的 IPv4 位址時，核心可從fake-ip-range指定的位址池分配一個位址並回覆，不必先等待該網域的真實 A 記錄。常見的位址池為198.18.0.1/16，屬於保留的效能測試位址範圍，並非網站的公網位址。

  1. 應用程式查詢example.com，查詢送入 mihomo DNS。
  2. 核心回覆位址池中的一個合成位址，並儲存該位址與example.com的對應。實際分配的位址視執行狀態而定，不應寫死。
  3. 應用程式連線至這個合成位址，連線經由 TUN 等接管路徑進入同一個核心執行個體。
  4. 核心查詢對應表以還原網域名稱，再依規則選擇直連或代理出站。
  5. 直連通常仍須解析真實的目標位址；代理出站若支援傳遞網域名稱，則可將網域交由遠端處理。實際行為也會受到規則、節點協定及相關 DNS 設定影響。

為什麼有時能縮短等待時間

若連線可直接依網域名稱分流，再將網域交由代理出站處理，本機就不必先查出目標網站的真實 IP。因此，較慢或受干擾的本機解析不一定會阻礙首次建立連線。不過，Fake-IP 無法縮短節點交握、遠端解析或伺服器回應時間，也不保證所有網站都會變快。

為什麼對應遺失會導致無法連線

合成位址只有在保有對應資料的核心中才有意義。若應用程式快取了舊位址，而核心重新啟動後未保留對應資料，後續連線就可能無法還原網域名稱。切換用戶端、切換 DNS 模式，或讓流量改由另一台閘道處理，也可能造成類似問題。修復時應重新發起 DNS 查詢，而不是替合成位址新增一般直連規則。

3. redir-host 的解析時機與規則比對差異

redir-host通常會先向上游 DNS 查詢，再將真實位址回覆給應用程式。核心會利用經過自身 DNS 的查詢結果，維護網域名稱與 IP 的關聯，以便在後續連線中還原網域名稱。它的相容性優點是應用程式看到的仍是真實位址，但真實位址與網域名稱不一定總是一對一。

比較項目Fake-IPredir-host
回覆給應用程式的 A 記錄通常是位址池中的合成位址通常是上游 DNS 回覆的真實位址
首次查詢所需時間分配合成位址通常不必等待目標的真實位址解析通常須等待上游解析完成
還原網域名稱的依據合成位址的對應資料DNS 查詢記錄與真實 IP 的關聯
共用 IP 的影響不同網域可分別建立對應多個網域共用 IP 時，關聯可能有歧義
應用程式自行使用加密 DNS可能略過合成位址分配可能略過核心的 DNS 關聯記錄
區域網路服務相容性通常須為內部網域設定過濾直接回覆真實的內網位址通常更簡單

規則本身也會影響解析時機。即使啟用 Fake-IP，執行需要目標真實 IP 的規則時，核心仍可能觸發解析。IP-CIDR等規則中的no-resolve可避免該條規則主動解析網域名稱，但它不是「禁止整個連線進行解析」的總開關。請一併檢查規則順序、真實 IP 是否已知，以及其他規則的行為。

如果程式直接連線至 IP，且未先向核心查詢網域名稱，兩種 DNS 模式都無法憑空取得可靠的原始名稱。流量嗅探或許能從部分協定交握中擷取網域名稱，但不能取代 DNS 對應，也無法涵蓋所有加密協定。

4. Fake-IP 與 DNS 外洩的關係

DNS 外洩通常是指查詢未依預期的解析路徑傳送，例如原本應交由指定解析器處理的查詢，卻送往網路業者提供的 DNS。Fake-IP 可減少部分代理網域在本機進行真實位址解析的情況，但不是防止 DNS 外洩的總開關；使用 redir-host 也不代表一定會外洩。是否外洩取決於查詢的接管範圍、上游協定與出站選擇。

  • 瀏覽器安全 DNS：瀏覽器可能直接透過 HTTPS 向外部解析器查詢，略過系統 DNS。排查時可暫時關閉此功能，再比較結果。
  • 一般 UDP/TCP DNS：通訊埠通常是 53。TUN 的 DNS 攔截可涵蓋符合條件的請求，但 HTTPS 443 或 TLS 853 上的加密查詢，不能單靠通訊埠 53 的規則處理。
  • IPv6：只驗證 A 記錄並不足夠，還須檢查 AAAA 查詢、IPv6 路由和應用程式連線。IPv4 Fake-IP 位址池無法證明 IPv6 路徑也已接管。
  • 引導與節點解析：加密 DNS 服務的網域名稱、代理節點伺服器的網域名稱，可能各自使用不同的解析路徑；請檢查default-nameserver、proxy-server-nameserver等欄位。

使用 DoH 可加密通往解析器的查詢，但不會自動確保連線經由代理，也不代表解析器看不到網域名稱。測試網站顯示某個 DNS 業者，只能說明該網站觀察到的解析出口；還應搭配核心記錄與網路封包擷取，確認目標解析器及實際出站。

5. fake-ip-filter 設定與區域網路例外

fake-ip-filter用來指定哪些網域不以一般 Fake-IP 方式回覆。以下範例明確使用 mihomo 的blacklist過濾模式：符合清單的網域會取得真實解析結果，其餘網域仍可分配合成位址。若舊版核心不支援fake-ip-filter-mode，請先查閱對應版本的文件，不要直接套用此欄位。

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:
    - "*.lan"
    - "*.home.arpa"
    - "router.home.arpa"
  nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan": 192.168.1.1
    "+.home.arpa": 192.168.1.1

這是欄位關係的範例，並非可直接取代整份設定的訂閱檔。192.168.1.1假設是實際負責解析內部網域的路由器；使用前務必替換成目前網路的內部 DNS 位址。範例中的公網解析器使用一般 DNS，方便觀察流程，不代表加密或代理解析方案。listen也不會自動變更系統 DNS。

過濾、解析策略與出站規則各自負責不同層面

  • fake-ip-filter：決定符合條件的網域是否略過合成位址，不負責指定直連。
  • nameserver-policy：為內部網域指定可解析該網域的 DNS。公網解析器通常不知道企業或家庭網路的私人記錄。
  • rules：決定連線的出站方式。內部服務即使取得真實 IP，仍須設定適當的直連規則，並確保路由可達。

例如，可在較廣泛的代理規則之前加入以下兩條規則。這些規則只決定出站方式，不能取代 DNS 策略；也不要為了套用範例而刪除現有規則：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

為什麼區域網路服務容易受影響

NAS、印表機、投放裝置和部分遊戲的探索機制，可能會檢查目標是否位於本機網段，或將解析結果傳給其他裝置。若收到198.18.0.0/16範圍內的位址，應用程式可能拒絕連線；其他沒有相同對應資料的裝置也無法使用該位址。建議只過濾實際使用的內部網域，不要一開始就排除所有網域。

.local常用於 mDNS，涉及多點傳送探索，不只是一般單播 DNS。將*.local加入過濾清單，並不會自動恢復 mDNS。若找不到投放裝置，請一併檢查區域網路存取權限、多點傳送轉送、TUN 路由與防火牆。透過路由器將 DNS 提供給其他裝置時，也必須確保這些裝置連往合成位址的流量會經過持有對應資料的閘道。

6. 驗證 DNS 回覆與連線接管

先使用明確指定的監聽位址驗證核心 DNS，再檢查系統預設的查詢路徑。以下命令適用於提供相應工具的系統；查詢通訊埠1053必須與執行中的設定一致：

# Windows：直接查詢核心 DNS
nslookup -port=1053 example.com 127.0.0.1

# macOS / Linux：直接查詢核心 DNS
dig @127.0.0.1 -p 1053 example.com A

# 檢查內部網域是否回覆真實內網位址
dig @127.0.0.1 -p 1053 router.home.arpa A
  1. 確認回覆：Fake-IP 模式下，未過濾的網域應依設定回覆位址池中的位址；經過濾的內部網域則應取得內部 DNS 提供的真實位址。若查詢逾時，請先檢查監聽設定與核心啟動狀態。
  2. 確認系統路徑：接著執行未指定伺服器的nslookup example.com，或以一般應用程式測試。直接查詢核心成功，不代表系統查詢已送入核心。
  3. 確認連線記錄：在用戶端的連線頁面或記錄中檢查網域名稱、比對到的規則與出站方式。若解析成功但無法連線，請確認流量是否進入同一個核心，以及規則是否選錯節點。
  4. 個別檢查 IPv6：查詢 AAAA 記錄，並觀察應用程式實際使用的位址類型。不要只因 A 記錄正常，就認定整條 DNS 路徑都正常。

排查期間可暫時將log-level設為debug，完成後請恢復常用等級，以免長時間記錄大量網域名稱。分享記錄前，請移除訂閱網址、權杖、節點憑證和內部主機名稱。

7. 切換模式與故障排除順序

如果主要需求是在 TUN 模式下依網域名稱分流，且 DNS 與連線都能進入同一個核心，可優先評估 Fake-IP。如果許多應用程式需要真實 IP、內部服務較複雜，或受限環境難以確保合成位址的接管路徑，可比較 redir-host 的相容性。選擇時應以資料路徑為依據，而不是模式名稱。

症狀優先檢查項目處理方向
回覆合成位址後連線逾時TUN 路由及核心對應資料是否一致修復接管路徑，重新查詢 DNS
公網服務正常，NAS 網域名稱無法連線過濾清單、內部 DNS、直連規則針對特定內部網域設定例外
重新啟動後部分應用程式中斷連線應用程式快取了舊的合成位址關閉舊連線、清除快取後再試
更新訂閱後模式又恢復原狀用戶端 DNS 覆寫與訂閱更新機制在實際生效的設定層修改
只有瀏覽器的測試結果不同瀏覽器加密 DNS 與自身快取統一測試路徑後再比較模式

每次只變更一個變數

  1. 備份設定，記錄目前的enhanced-mode、DNS 上游與 TUN 狀態。
  2. 只切換 DNS 模式，維持相同節點、規則和測試網域。
  3. 套用設定後關閉舊連線，清除系統及應用程式的 DNS 快取。Windows 可執行ipconfig /flushdns；瀏覽器和其他應用程式可能仍須個別重新啟動。
  4. 依序測試公網網域、內部網域與實際使用的應用程式，記錄問題發生在查詢、規則比對還是建立連線階段。

不要同時永久停用 IPv6、批次過濾所有網域並切換節點來排除問題。一次變更多個條件，會失去判斷故障位置的依據。欄位說明可參閱設定欄位參考，接管路徑則可搭配入門指南確認。

最終設定應符合三個條件：查詢交由預期的解析器處理、連線進入預期的核心、規則選擇預期的出站方式。Fake-IP 與 redir-host 都只是這條流程中的 DNS 運作模式；分別驗證這三點，才能判斷問題出在解析、路由還是代理節點。