先對齊症狀：您遇到的是不是「Fake-IP 誤傷」？
典型現象包括：在瀏覽器輸入 192.168.x.1 仍可開路由器，但輸入 router.lan 或供應商預設的區網主機名稱卻失敗；NAS 的網頁管理、Time Machine 或 SMB 名稱解析變得不穩；AirPrint 或內網服務依賴 .local（mDNS）時斷斷續續。另一種常見情況是：您明明在 rules 裡寫了 DOMAIN-SUFFIX,example.com,DIRECT，但應用程式仍像「走錯管線」一樣連不上，其實問題可能出在DNS 先被 Fake-IP 了，導致後續連線目標與預期不符。
若您完全沒開 enhanced-mode: fake-ip，或核心根本沒接管該程式的 DNS，則不適用本文主軸，應回到「系統代理／TUN／上游 DNS」路徑排查。若您不確定 TUN 與 DNS 攔截是否已對齊，可先閱讀 Clash Verge Rev TUN 模式完整教學，再回來調整 dns 區段，會比較不會兩頭空轉。
Fake-IP 為什麼會讓區網與「應直連」的網域變難用？
在 Fake-IP 模式下，核心對「符合 Fake-IP 條件」的 DNS 查詢會回傳一段虛擬位址（常見於 198.18.0.0/15 等區段，實際以您的 fake-ip-range 為準）。這樣設計的目的，是讓規則可以先依域名決策，再把真實解析延後到連線階段處理，降低「解析路徑與規則預期不一致」的機率。然而，區域網路主機、內網 IP 反向對應、以及部分必須立即拿到真實 A/AAAA 記錄的應用程式，若也拿到 Fake-IP，就會出現「解析看似成功、連線卻對不到正確機器」的體感。
fake-ip-filter 的角色，就是告訴核心：這些查詢不要走 Fake-IP，改以一般方式取得真實結果（仍由核心的 nameserver／fallback／nameserver-policy 處理）。把它想成「在 Fake-IP 大開關底下，再開一扇精準小門」：門內是內網與您信賴的直連名單，門外仍維持 Fake-IP 的整體策略。
小結：fake-ip-filter 處理的是「哪些查詢不要被 Fake-IP」；rules 處理的是「連線走哪個策略組」。兩者都要對，內網才會順。
1fake-ip-filter 放哪裡？與哪些鍵名一起出現？
在 Clash Meta／Mihomo 的設定中，fake-ip-filter 通常位於 dns: 區塊、且與 enhanced-mode: fake-ip 並存。清單元素可為網域後綴、完整域名、關鍵字，或 IP 類別（視您所用版本支援的語法為準）。實務上最常見的寫法是先覆蓋內網位址空間，再補上 *.local、路由器常見後綴、以及您家 NAS 的區網名稱。
若您使用圖形客戶端，請在編輯設定檔時確認沒有被 UI 另一層選項覆寫；有些客戶端會把 DNS 相關片段合併成「進階 YAML」，匯入前建議備份。鍵名若與上游文件不一致，請以您當前核心版本說明為準，但「排除清單」的概念在各分支中是一致的。
2可複製的 YAML 骨架（請依環境增刪）
下列片段示範如何把內網 IP、常見區網服務與 local 後綴放進 fake-ip-filter。請將範例中的私有域名改成您家中實際使用的名稱；註解一律使用英文，方便版本控管與跨語言團隊協作。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
# Queries matching these patterns skip fake-ip and get real records
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.localhost"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
- "time.*.com"
- "time.*.gov"
- "time.*.apple.com"
- "router.asus.com"
- "+._tcp.local"
- "10.0.0.0/8"
- "172.16.0.0/12"
- "192.168.0.0/16"
- "127.0.0.0/8"
- "169.254.0.0/16"
- "fc00::/7"
- "fe80::/10"
上列僅為高頻參考：例如 +.msftncsi.com 類條目與 Windows 連線偵測有關，是否保留請依您是否遇到「已連上網但系統顯示未連線」之類副作用而定。router.asus.com 僅為常見路由器範例，若您使用他牌設備，請改為實際出現在連線日誌中的主機名稱。若您有 Synology、QNAP 等裝置的自訂直連域名（僅在內網 DNS 或路由器上可解析），也應一併加入清單，否則它們仍可能被 Fake-IP。
提醒：過寬的 DOMAIN-KEYWORD 或過大的後綴可能讓過多查詢繞過 Fake-IP，反而讓規則分流變難預測；請維持「能解釋為什麼要放行」的最小集合。
3與 DNS 分流、nameserver-policy 如何一起看？
fake-ip-filter 只決定「這筆查詢要不要 Fake-IP」，並沒有指定「由哪一組上游 DNS 回答」。因此，若您的內網名稱只在家用路由器或公司內部 DNS 上才有記錄，仍須確保查詢真的會送到能回答的那台解析器。這時候 nameserver-policy、nameserver 與 fallback 的組合就很重要：常見做法是讓 +.lan 或內部網域走路由器或內網 DNS，其餘走加密公共解析器。完整管線與防洩漏思路請對照 Meta 核心 DNS 防洩漏指南，本文不重複敘述每一個上游參數，只強調放行 Fake-IP 與選對解析路徑是兩件事。
若您發現加入 fake-ip-filter 後仍解析不到內網主機，下一步通常不是再加更多 filter，而是檢查誰在回答這筆查詢：例如 TUN 模式下 dns-hijack 是否把查詢導回核心、以及核心是否真的能連到您內網 DNS（僅限內網可路由的情境）。這類問題若只用「再加一條 DOMAIN 規則」硬補，往往會在升級核心或更換路由器後再次復發。
4與 rules 直連的關係：順序與「先解析」陷阱
即使 rules 已寫 IP-CIDR,192.168.0.0/16,DIRECT，若應用程式先透過域名連線，而該域名在 Fake-IP 階段被映射到不適用的虛擬位址，仍可能出現異常。換句話說：規則直連與 DNS 行為必須同一套故事。實務上建議把「內網與必須真實解析的網域」同時放在 fake-ip-filter 與規則前段的 DOMAIN／IP-CIDR 保障裡，並用日誌確認命中順序。
對於少數只以 IP 連線、TLS 才帶出 SNI 的程式，若您已排除 Fake-IP 仍覺得規則怪，可再參考 HTTPS Sniffer 與域名路由 一文，理解「域名資訊從哪裡來」；但內網與 .local多數仍應優先用本文方式處理，不必動不該動的嗅探設定。
5驗收與除錯：怎麼確認真的繞過 Fake-IP？
建議採單一變因：先備份設定檔，只新增 fake-ip-filter 區塊或增量加入幾行，重載後立刻測試。驗收時可看核心日誌中 DNS 相關訊息（實際欄位依版本而異），並在終端機以 dig 或系統工具觀察：針對內網主機名稱，回傳是否為真實內網位址，而非 198.18.x.x 這類 Fake 區段。若回傳仍在 Fake 區段，代表清單模式未命中，請檢查是否需要 +. 前綴、萬用字元層級、或該名稱實際查的是另一個後綴（例如裝置自動補上的搜尋網域）。
另一個實用技巧是：先從「一定該成功」的條目驗證管線，例如 127.0.0.1 或已知存在的 192.168.x.x 反查，再擴大到 NAS 的自訂名稱。每次只加一組變更並記錄結果，日後要交付給家人或同事維護時，也比較能說清楚「當初為什麼要放行」。
常見誤區與取捨
誤區一：遇到問題就先關閉整套 Fake-IP
關閉 Fake-IP 確實能「快速證明問題跟 DNS 模式有關」，但長期會讓依域名分流的規則集較難維持一致。更穩定的做法是：保留 Fake-IP，並用 fake-ip-filter 精準放行區域網路與直連域名清單，讓「需要隱私與一致規則」與「需要真實內網解析」並存。
誤區二：只在 rules 加直連，卻忽略 DNS
規則處理的是連線策略，若 DNS 階段已經把名稱變成不適用的位址，後續直連規則可能救不回來。請把 rules 與 dns 當成同一張圖上的兩個圖層，而不是兩份互不相干的文字檔。
誤區三：整包複製社群設定卻不理解每一行
網路上常見的「巨型 filter 清單」可能包含您環境不需要、甚至與新版核心語法不完全相容的條目。建議以最小可用清單起步，遇到實際問題再依日誌擴充；這比一次貼上上百行更利於半年後的自己除錯。
開源資訊與安裝包取得方式
Mihomo 與 Clash Meta 生態以開源方式演進，行為細節會隨版本更新；若您要核對某個鍵名是否仍有效，建議查閱對應版本說明或原始碼變更紀錄。若您要取得圖形客戶端安裝包，仍建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「安裝升級」與「追蹤上游 Issue」分開，可避免把 Release 頁誤當成唯一入口。
結語
fake-ip-filter 是 Fake-IP 模式下少數能「一刀劃清邊界」的設定：一邊保留 Fake-IP 對公網域名分流的優勢，一邊把路由器、NAS、印表機與 *.local 這類必須真實解析的對象放回正確跑道。把它與 DNS 分流、直連域名規則一起驗收，您會發現多數「開了 Fake-IP 區網就壞」的案例，並不需要犧牲整套模式，只需要一份可維護的清單與清楚的日誌證據。
相較於在各處手動改系統 DNS 或反覆切換模式，用 Clash Meta 同一套設定檔集中管理，長期更容易與家人或團隊對齊；當您下次換路由器或改內網網段時，也只要同步更新 filter 與 IP-CIDR 規則即可。