先釐清：DNS 回應與實際連線
手機開啟網站時，App 通常會先查詢網域名稱對應的 IP 位址，再發起連線。在支援 Clash Meta（mihomo）DNS 功能的用戶端中，enhanced-mode: fake-ip 會改變 DNS 查詢的回應方式：核心會為網域名稱分配一個暫時的合成位址，將「網域名稱 ↔ 合成位址」的對應關係記錄在映射表中，再把合成位址回傳給 App。
接著，App 會連線至這個位址。流量由用戶端接管後，核心會透過映射表找回原本的網域名稱，再比對網域規則，並依規則選擇直連或代理。合成位址是用戶端內部使用的索引，並非網站伺服器的真實位址，也不能視為可從網際網路存取的目標。
一次請求會經過哪些步驟
- App 查詢
example.com的 A 記錄；查詢必須進入用戶端的 DNS 處理流程。 - 核心會從設定的 Fake-IP 位址範圍中回傳一個位址，並記錄它與
example.com的對應關係。 - App 連線至該位址；用戶端接管連線、找回網域名稱，並套用
DOMAIN、DOMAIN-SUFFIX等規則。 - 核心會依選定的出口方式處理目標連線。代理出口能否透過網域名稱連線，仍取決於通訊協定、節點及用戶端的具體實作。
因此，「取得 DNS 回應」和「成功連上目標」是兩回事。Fake-IP 讓 App 較早取得可供後續比對的位址，但實際連線仍須經過規則判斷、節點連線及目標服務回應。若 App 直接連線至數字 IP、DNS 查詢未經用戶端處理，或後續連線未由用戶端接管，網域映射流程就無法正常運作。
Fake-IP 與 redir-host：真實解析發生在哪個步驟
redir-host 通常會先透過上游 DNS 查詢目標的真實 IP，再將結果回傳給 App。fake-ip 則會先回傳合成位址，讓後續由用戶端接管的連線透過映射表還原網域名稱。兩者的關鍵差異不是「要不要用 DNS」，而是 App 等待 DNS 回應時，是否通常得先等目標網域完成真實位址解析。
| 觀察項目 | Fake-IP | redir-host |
|---|---|---|
| 回傳給 App 的位址 | 映射至網域名稱的合成位址 | 透過上游解析取得的真實位址 |
| 網域規則的比對依據 | 合成位址對應的映射記錄 | DNS 查詢記錄；其他情境可能還會用到協定嗅探 |
| 常見取捨 | App 可能較早收到 DNS 回應，但後續連線必須由用戶端正確接管 | App 可直接取得真實位址，但 DNS 回應可能得等待上游完成解析 |
「縮短首次連線等待時間」主要是減少 App 在 DNS 階段等待真實位址解析的機會，不代表每次開啟網頁都會更快。若瓶頸在節點交握、封包遺失、目標網站回應或 App 啟動本身，切換 DNS 模式未必能改善首次連線時間。即使是直連目標，最終仍可能需要解析真實位址；這段耗時只是移到後續流程，並不會憑空從總耗時中消失。
比較不同模式時，請使用相同網路、相同節點和相同目標。先確認 App 是否能穩定建立連線，再比較等待時間；別把 DNS 回應快誤認為整個網頁載入流程都變快。
保留位址範圍如何搭配映射表運作
mihomo 設定中常見的 fake-ip-range 範例是 198.18.0.1/16。198.18.0.0/15 屬於保留供網路設備效能測試使用的 IPv4 位址空間，並非一般公網網站位址。取其中一段作為本機合成位址，方便核心辨識這類連線；實際使用的位址範圍仍應以目前用戶端設定為準。
映射表由執行中的核心維護，並不是能永久保存網站 IP 的清單。同一個合成位址在不同執行期間，不應被假設永遠對應同一個網域名稱。將合成位址複製到其他裝置、寫入長期使用的 App 設定，或在用戶端重新啟動後單獨用它測試連線，都無法可靠反映原網域的狀態。
精簡版 DNS 設定範例
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
fake-ip-filter:
- '*.lan'
- printer.home.arpa這段 YAML 用來示範欄位位置，並非適用於所有網路的完整設定。nameserver 中的位址僅供閱讀示範：請依所在網路、訂閱設定及實際連線狀況選擇解析器。fake-ip-filter 用來列出不應收到合成位址的網域；實際比對語法，以及用戶端是否允許編輯這些欄位，請以使用中的核心和用戶端版本為準。修改時請維持兩個空格縮排，並先備份原始設定。
只將 enhanced-mode 改成 fake-ip，不代表設定一定會生效。App 的 DNS 查詢必須進入用戶端，後續連往合成位址的流量也必須由用戶端接管。手機通常還會涉及系統 VPN 設定、用戶端 DNS 設定及所選代理模式；部分用戶端會透過圖形介面管理這些參數，不會直接讀取使用者編輯的 YAML。
哪些目標適合加入過濾清單
判斷是否要過濾，關鍵在於目標 App 是否需要取得真實位址，或其連線能否始終經過同一個用戶端核心。不要把所有網域一律加入過濾清單；過濾範圍愈大，就愈多查詢會回到等待真實位址解析的流程，原本想減少的 DNS 等待時間也可能再次出現。
區域網路裝置：先確認由哪裡解析網域
印表機、NAS 和路由器常使用 printer.lan、nas.home.arpa 這類內網名稱。若裝置管理 App 需要真實的區域網路位址，卻收到合成位址，可先將該裝置的確切網域加入過濾清單，再確認目前的 DNS 上游能否解析內網名稱。過濾只會改變是否回傳 Fake-IP；如果公用 DNS 根本不知道印表機的位址，只加入過濾項目也無法讓名稱解析成功。
.local 名稱通常透過 mDNS 在區域網路中探索，不一定會經過一般 DNS 查詢。若遇到「裝置清單看得到，點開卻連不上」，請分別檢查區域網路權限、mDNS 探索、實際連線使用的網域名稱或 IP，以及代理規則。若 App 直接連線至 192.168.1.1，Fake-IP 過濾清單不會影響這條直接使用 IP 的連線。
遊戲與部分 App：依實際網域逐一排查
遊戲的登入、配對和語音功能可能使用不同網域及 UDP 連線。先確認問題發生在帳號登入、房間配對還是即時通訊；若只有特定網域在 Fake-IP 模式下異常，改用真實解析後就恢復，再只針對該網域加入過濾清單。部分 App 會快取解析結果，修改設定後還需要結束 App、重新開啟；必要時重新連線用戶端，避免舊連線和快取影響測試。
不要將「遊戲使用 UDP」直接等同於「必須停用 Fake-IP」。UDP 流量能否正常運作，也會受到用戶端接管方式、節點通訊協定、規則和伺服器影響。對使用數字 IP、區域網路廣播或裝置探索的功能來說，網域過濾可能完全無關；此時繼續新增網域只會增加設定複雜度。
iPhone 排查順序
切換 DNS 模式後若發生無法連線、部分 App 一直載入或內網裝置離線，請依「系統接管 → DNS 回應 → 連線規則 → 單一 App」逐層排查，比同時更換節點、訂閱和 DNS 上游更容易找出原因。
- 確認 VPN 已連線。在 iPhone「設定」→「一般」→「VPN 與裝置管理」→「VPN」查看目前連線狀態，再回到用戶端確認使用的是預期設定。選單名稱可能會因 iOS 版本而異。
- 確認設定已啟用。檢查目前 Profile 中的 DNS 模式、Fake-IP 位址範圍和規則模式。更新訂閱後若切換到另一份 Profile，請確認實際啟用的設定檔中的參數。
- 分辨是全面異常還是單一項目異常。所有網站都無法開啟時，優先檢查 DNS 上游是否可連線、VPN 是否接管流量及節點狀態；只有一台 NAS 或一個 App 異常時，先記錄它連線的網域名稱或區域網路位址。
- 一次只修改一項設定。針對確切的內網網域新增過濾項目並重新連線，再測試目標；如果沒有改善，請還原這項修改，並檢查區域網路解析、直連規則及 App 權限。
規則模式和 DNS 模式負責不同環節：前者決定請求使用哪個出口，後者影響名稱如何解析及回傳。將網域加入 DIRECT 規則，不會自動確保 App 取得真實 IP；同樣地，把網域加入 Fake-IP 過濾清單，也不會自動讓它直連。若要同時確保內網名稱解析為真實位址並採用直連，請分別檢查這兩處設定。
只有確認「合成位址影響目標功能」時，才加入過濾項目。保留原設定副本，記錄每次修改的網域及現象，確認測試成功後再保留規則。