一、先對齊現象：哪些情況像 fake-ip 問題
fake-ip 的核心行為是：在本機 DNS 查詢階段，對符合規則的網域名稱回傳一段虛擬 IPv4 位址（常見為設定中的 fake-ip-range，例如 198.18.0.1/16 這類保留區段），真正的網域到遠端 IP 的解析往往延後到連線建立時由核心或代理完成。絕大多數網站因此更順暢，但當某類應用程式或站點在「拿到假 IP 之後」仍堅持用自己的方式做二次解析、校驗憑證與 SNI，或依賴真實地理／電信業者解析結果時，就會表現為只有幾個站異常，而不是全網癱瘓。
讀者自查時可對照下列現象：瀏覽器網址列長時間空白或只顯示載入動畫；部分網路銀行、政府機關服務、企業入口在開啟代理後反而連不上；遊戲啟動器、語音或會議軟體提示網路錯誤；HTTPS 頁面跳出憑證與網域名稱不符；僅命令列或僅某一應用程式異常，而同一台機器上瀏覽器存取其他站正常。若你關閉 fake-ip（改為 redir-host 等）後問題立刻消失，則高度懷疑與假位址鏈路或過濾清單有關，而不是單純「節點掛了」。
這與我們在 Perplexity 分流一文 裡提到的「規則分流之外還要核對 DNS、DoH 與 fake-ip」是同一類思路：先把網域名稱解析異常從「規則寫錯」裡剝離出來，再決定是改清單還是改 DNS。
二、對照實驗：確認異常與 fake-ip 強相關
在動大設定之前，建議用最小對照鎖定因果關係。第一步：僅針對出問題的主機名稱，在用戶端日誌或連線預覽裡觀察解析結果是否落在 fake-ip-range 內。第二步：暫時將 dns.enhanced-mode（或你所使用核心中的等價項目）從 fake-ip 改為 redir-host，重新載入設定後複測同一網址；若異常消失，即可認定問題鏈條與 fake-ip 行為相關，後續專注 fake-ip-filter 與 DNS。
第三步（選用）：保持 fake-ip，但讓系統或瀏覽器繞過 Clash 的 DNS 做對照（例如僅在測試裝置上暫時指定公共 DNS）。若繞過後站點恢復，說明瓶頸在 Clash DNS 上游、劫持順序或 fallback；若仍失敗，則要回到規則、節點或嗅探層繼續查。
三、fake-ip-filter：該讓哪些網域走真實 IP
fake-ip-filter（在部分設定範本裡也寫作 fake-ip-filter 下的網域清單或與 nameserver-policy 組合使用）的作用是：對清單內的網域名稱不使用 fake-ip，而回傳真實解析結果。漏加一條，往往就代表「這個網域在用戶端眼裡始終是假位址」，進而觸發上文所述的各種相容性問題。
建議優先納入 filter 的類型
- 區域網路與純內網主機名稱，例如
*.local、路由器管理位址、NAS、印表機、公司內網入口；假 IP 無法對應你真正的二層／三層路徑。 - 對憑證校驗極度敏感的服務：部分網路銀行、支付、電子化政府服務、零信任接入會在握手階段綁定特定解析路徑或憑證釘選（pinning），假 IP 容易造成握手失敗或中間頁無限重新導向。
- 依賴真實 CDN 邊緣調度的站點：少數站點在 DNS 層就需要得到「離你最近的」位址，若長期拿到固定假位址，可能表現為極高延遲或握手逾時（視用戶端實作而定）。
- 已知的直連或中國大陸最佳化網域：若你的規則將這些網域標為直連，但仍走 fake-ip，可能在「直連出站」與「假位址目標」之間出現語意不一致；將此類網域放入
fake-ip-filter可減少邊界情況。
設定範例（依你所使用的核心欄位為準）
下列片段僅示意結構，欄位名稱請以 Mihomo／Meta 目前文件為準；合併訂閱時注意不要重複整段 dns: 鍵。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.msftconnecttest.com"
- "stun.*.*"
- "+.srv.nintendo.net"
# add hostnames that break with fake-ip below實際操作時，請把出問題站點的根網域、登入跳轉網域、靜態資源網域與 WebSocket 網域一併收集（開發者工具網路面板裡可見），逐條加入 filter 後重新載入 DNS 或重啟核心再測。若清單過長，可考慮用 geosite 或規則集批次覆蓋，再對個別網域微調。
fake-ip-filter 不是「廣告過濾清單」。它的目標是相容性，濫用會讓 fake-ip 失去意義；應堅持「只加確認有問題的網域」。
四、DNS：nameserver、fallback 與解析順序
即便 fake-ip-filter 已正確，若 DNS 區段本身不穩定，仍會出現「偶發連不上」「僅行動網路不行」等現象。建議依鏈路由上而下檢查。
nameserver 是否可連線
確認 Clash 設定的 DoH／DoT／UDP DNS 在你目前網路下未被攔截。企業網路、校園網或電信業者有時會干擾非標準連接埠或特定 DoH 主機名稱，表現為間歇性解析失敗。可暫時換成另一組上游做 A／B，觀察問題是否隨上游切換而消失。
fallback 與 fallback-filter
當主上游回傳被污染或異常結果時，fallback 是否會被觸發、fallback-filter 的 geoip 與網域清單是否合理，決定了你是否會在 fake-ip 情境下拿到錯誤地域或錯誤線路的解析前置資訊。若你曾從範本複製過一份很激進的 fallback-filter，建議對照官方範例逐項理解後再裁剪。
nameserver-policy 與分域上游
對中國大陸站點與境外站點併用時，用 nameserver-policy 把特定後綴交給指定 DNS，往往比全域單一上游更穩。這與 WSL2 與 DNS 排查 一文裡強調的「解析路徑分層」一致：先保證查詢能到達正確上游，再談 fake-ip 是否啟用。
| 現象 | 優先檢查項 |
|---|---|
| 僅特定網域異常 | 是否應加入 fake-ip-filter；該網域的 CNAME 鏈是否在規則集裡被遺漏 |
| 換網路環境後恢復 | DNS 上游是否被目前網路劫持或限速；DoH 主機名稱是否被阻擋 |
| 憑證錯誤或 SNI 相關日誌 | 嗅探是否誤傷；是否在 TUN 下與系統憑證政策衝突（見下一節） |
五、嗅探與憑證：何時縮小範圍或暫時關閉
嗅探（sniffer） 用於在流量已經加密時，根據 TLS Client Hello 等資訊嘗試還原網域名稱，以便規則模組在「看不到明文 Host」時仍能分流。它與 fake-ip 常常同時開啟，二者疊加後，若嗅探範圍過大或某一嗅探實作與目標站點握手特性不相容，可能出現憑證警告、連線被中途重設、HTTP／2 或 QUIC 降級異常等現象。
排查順序建議：先在日誌中確認異常連線是否經過嗅探路徑；再將嗅探限定在需要的通訊協定或連接埠（例如僅對特定入站或僅 TCP 443），排除誤嗅探；若仍無法解釋，可短暫關閉嗅探做對照——若關閉後站點恢復，則優先縮小嗅探規則，而不是盲目關閉 fake-ip。
部分桌面用戶端會把「自動嗅探」與「系統代理／TUN」綁定，修改後記得重啟系統代理服務或虛擬網路卡，避免舊行程仍依上一版行為運作。
六、與 TUN、系統代理及其他用戶端疊加
當 TUN 模式 與 fake-ip 同時啟用時，系統路由表、預設 DNS 與 Clash 內部 DNS 可能形成雙環依賴：系統認為 DNS 在本機某一位址，而 Clash 又在等應用程式發起連線後才完成遠端解析。此類問題在表現上與「單純 fake-ip」相似，但修法往往在路由排除、繞過中國大陸、DNS 劫持開關等層面。建議結合 TUN 與路由防火牆排查 一文，先確認 TUN 未造成全域斷流或迴圈，再回到本文的 filter 與 DNS 清單。
若機器上還執行其他 VPN、企業安全代理或「加速器」，多張虛擬網路卡爭奪優先順序時，也可能出現僅少數網域走錯堆疊。此時可在出問題的應用程式內關閉「獨立代理」或調整順序，確保只有一條明確的出口路徑。
長期維護上，建議把「已加入 fake-ip-filter 的網域及原因」記在本地筆記裡：是憑證問題、內網解析還是 CDN 調度。下次升級訂閱或更換用戶端時，可避免重複踩坑。
七、小結
Clash fake-ip 能顯著改善多數情境下的連線建立速度，但少數網站打不開往往不是節點單點故障，而是 fake-ip-filter 未涵蓋、DNS 上游與 fallback 不穩，或 嗅探 與 TLS 行為疊加後的相容性問題。依「對照實驗 → 補 filter → 查 DNS → 縮小嗅探 → 核對 TUN」的順序排查，通常能在不犧牲整體體驗的前提下定點修復。
相比反覆搜尋零散片段，把每一次異常網域記錄下來並歸入上述某一類，你的設定會越維護越穩。若你希望從可信管道取得用戶端與基礎範本，可先閱讀 本站設定文件，再匯入訂閱並依本文檢查 DNS 與 fake-ip 區段。
相比其他同類工具，Clash 系列在規則、DNS 與多模式協同方面文件與社群實作都較豐富；理順 fake-ip 與真實解析的邊界後，日常瀏覽與開發工具的穩定性都會明顯提升。