先確認適用範圍：過濾 Fake-IP，不是改寫代理規則

本文只處理一個問題：某個網域在 OpenClash 的 fake-ip 運作模式下不適合取得 Fake-IP，或你需要明確控制它是否回傳 Fake-IP 時，如何設定 fake-ip-filter。步驟以 OpenClash v0.47.156 穩定版、OpenWrt 與 Mihomo 核心為準；舊版 OpenClash、其他 Clash 用戶端及 redir-host 模式不能直接照搬。

Mihomo 的 DNS 文件把 fake-ip-filter 定義為 Fake-IP 映射的過濾條件。它決定 DNS 查詢取得 Fake-IP 或真實解析結果，並不決定連線最後走 DIRECT 或 PROXY。出口仍由路由規則與策略群組決定，所以加入過濾清單不等於新增直連規則，也不會自動修好失效節點。

畫面找不到此項時先停下：OpenClash v0.47.156 的介面原始碼只在目前運作模式為 fake-ip 時顯示 Fake-IP Range、持久化 Fake-IP 與 Fake-IP-Filter。不要為了找到開關，將本文硬套到 redir-host 設定。

完整入口通常是「服務 → OpenClash → 覆寫設定 → DNS 設定」；不同 LuCI 佈景與語言套件也可能顯示「Services → OpenClash → Overwrite Settings → DNS Settings」。請以欄位名稱 Fake-IP-Filter、Fake-IP-Filter-Mode 辨識，而不是依照截圖位置。

先選匹配方向：blacklist、whitelist 與 rule 不要混為一談

進入 OpenClash 的「覆寫設定 → DNS 設定」，啟用 Fake-IP-Filter 後即可選擇模式。v0.47.156 提供 blacklist、whitelist、rule，預設為 blacklist。這些名稱描述 Fake-IP 的回傳範圍，不是代理節點黑白名單。

模式DNS 行為適合的最小情境
blacklist命中時回傳真實解析；未命中仍可回傳 Fake-IP只排除少量異常網域，建議先使用
whitelist命中時回傳 Fake-IP；未命中回傳真實解析只讓明確列出的網域使用 Fake-IP
rule執行第一條匹配的 fake-ip 或 real-ip；全部未命中時預設使用 Fake-IP需要依序混合兩種結果

最常見的誤解，是選了 whitelist，仍把輸入區當成「不回傳 Fake-IP 的網域清單」。白名單模式的方向恰好相反：只有匹配成功才回傳 Fake-IP。若只是處理印表機、企業內網、登入偵測或某個應用程式的一個網域，先保留預設 blacklist，不要立即反轉所有 DNS 查詢。

修改前記錄原狀：記錄目前模式、原清單與異常現象。一次只改一種模式設定或一個網域；若同時更換 DNS 上游、繞過中國大陸、IPv6、規則集與瀏覽器安全 DNS，便無法判斷哪項改動真正生效。

先以 blacklist 完成單一網域測試

先選一個能穩定重現問題的完整網域。下文的 device.example.net 只是避免與隨附預設項目重疊的預留字串，操作時必須換成日誌中確認的實際異常主機名稱。在 Fake-IP-Filter 輸入區每行填一條規則，不加 YAML 清單的短橫線，也不要在網域後附註解。OpenClash v0.47.156 會把文字儲存到 /etc/openclash/custom/openclash_custom_fake_filter.list，覆寫程序再將它合併到最後設定的 dns.fake-ip-filter。

Fake-IP-Filter · blacklistdevice.example.net
  1. 確認目前模式是 fake-ip，記錄修改前的 DNS 回覆與原本失敗現象，並依文末方式備份現有清單。
  2. 開啟「覆寫設定 → DNS 設定」，啟用 Fake-IP-Filter，模式維持 blacklist。
  3. 先只加入一個完整網域。準備立即測試時直接按「Apply Settings（套用設定）」；它會儲存變更、啟用並重新啟動 OpenClash，不必先按一次「Commit Settings（儲存設定）」。
  4. 等待外掛恢復執行，先檢查啟動日誌是否有 YAML、Fake-IP-Filter 或 DNS 錯誤。
  5. 從仍使用路由器 DNS 的相同裝置再次查詢並重試原應用程式；此時不要換節點或代理模式。

完整網域驗證成功後，才考慮是否擴大。Mihomo 的 Clash 風格網域語法中，*.example.com 只匹配一層子網域，不包含根網域或更多層級；+.example.com 類似後綴匹配，可包含根網域與多層子網域。Mihomo YAML 的萬用字元項目需要引號，但 OpenClash 這個輸入區儲存的是逐行純文字，不要貼入 YAML 的引號或清單短橫線：

擴大前逐項驗證*.device.example.net
+.corp.example.net

不要因為名稱看似屬於同一服務，就加入整個公共後綴。先從日誌或實際查詢找出準確主機名稱；過寬的過濾會使大量網域改用真實解析，反而掩蓋分流或上游 DNS 問題。

需求明確時才改用 whitelist 或 rule

whitelist 適合「只讓一小組網域取得 Fake-IP，其餘網域回傳真實解析」的設計。切換前要知道未匹配網域的預設結果會被改變；它不是 blacklist 的另一種寫法。至少先在測試裝置驗證登入、區網服務、常用站點與代理規則，再考慮套用到整個網路。

切換前必須備份並檢查最終運作清單：whitelist 會把合併清單中現有普通項目的意義反轉成「命中才回傳 Fake-IP」；rule 則要求最後 dns.fake-ip-filter 的每一個非註解項目，包括訂閱原有過濾項目與 OpenClash 產生項目，都成為帶有 fake-ip 或 real-ip 動作的完整規則。末尾 MATCH 並非解析必要條件；全部未命中時 Mihomo 預設繼續使用 Fake-IP，但仍建議明確寫出兜底規則方便檢查。下方是獨立測試清單，不能直接附加在原本的 blacklist 形式項目後方；無法檢查最終清單時不要切換 rule。

Fake-IP-Filter · whitelist+.proxy-test.example.net
api.proxy-test.example.net

rule 模式採用類似 Mihomo 路由規則的由上到下匹配，但動作是 fake-ip 或 real-ip。未命中任何規則時 Mihomo 預設繼續使用 Fake-IP；為使結果明確且方便維護，仍建議加入末尾兜底規則。以下只讓兩個範例範圍取得真實位址，其餘繼續使用 Fake-IP：

Fake-IP-Filter · ruleDOMAIN,device.example.net,real-ip
DOMAIN-SUFFIX,corp.example.net,real-ip
MATCH,fake-ip

使用 rule 時不要再填普通 blacklist 清單，也不要把 DIRECT、PROXY 或策略群組名稱當成動作。Mihomo 支援 GEOSITE、RULE-SET，但外部集合必須存在且類型相容；若無法審查其內容，使用少量明確的 DOMAIN、DOMAIN-SUFFIX 更容易維護。

單一網域問題先用 blacklist：它對其他網域既有 Fake-IP 行為的影響最小，也最好還原。只有需求本來就是「少數 Fake-IP」或「依順序混合」時，才分別選 whitelist 或 rule。

套用後分別驗證 DNS、日誌與真實請求

v0.47.156 的「Commit Settings（儲存設定）」會儲存目前表單與自訂清單，但不會重新啟動 OpenClash；「Apply Settings（套用設定）」同樣會儲存設定，另外還會啟用並重新啟動 OpenClash，重新產生執行設定。因此準備測試時可直接套用一次，不必先另按儲存設定。重新啟動期間短暫斷線是預期狀態，持續無法連線則不是。等待狀態恢復後，先確認產生設定沒有錯誤，再進行 DNS 查詢。

替換成你的實際位址與網域nslookup device.example.net <路由器LAN位址>

先以目前執行設定的 fake-ip-range 為準；OpenClash v0.47.156 隨附的預設範本使用 198.18.0.1/16，覆寫項目預設不會強制取代訂閱中的值。blacklist 命中後，應取得上游回覆的真實位址、內網位址或明確的不存在回應。實際結果取決於上游與網域，不能只因位址不再位於 Fake-IP 位址池，就判定應用程式已修復。

  1. 確認測試裝置使用路由器 DNS，而非瀏覽器安全 DNS、應用程式內 DoH 或另一個手動 DNS。
  2. 查詢目標完整網域，記錄回覆伺服器、位址與狀態。
  3. 檢查 OpenClash 日誌是否出現過濾語法錯誤或設定被退回。
  4. 重新執行原來的登入、發現、存取或連線動作。
  5. 在連線日誌確認網域最後命中預期路由規則與策略群組。

這些步驟分別證明用戶端 DNS 路徑、Fake-IP 映射、設定有效性、應用行為與路由出口。不要只用 ping 判斷；部分服務不回應 ICMP，而 fake-ip 模式下看到保留位址也不代表代理請求必然失敗。

清單沒有作用時依固定順序排解

若儲存後完全沒有改變，先不要擴大清單。依照以下順序，通常可以分辨規則未進入運作設定，或查詢根本繞過 OpenClash：

現象先檢查處理方向
畫面沒有 Fake-IP-Filter運作模式是否為 fake-ip確認適用模式，不硬套在 redir-host
單一網域仍回傳 Fake-IP開關、模式、拼字、實際查詢主機名回到 blacklist 與完整網域測試
路由器查詢正確，瀏覽器仍異常安全 DNS、應用程式 DoH、快取讓測試經過路由器 DNS 並清除對應快取
真實 IP 正常但網站仍無法開啟路由規則、策略群組、節點與憑證分開處理 DNS 映射與代理出口
套用後 OpenClash 無法啟動rule 語法與首個日誌錯誤恢復原清單與模式，再逐條新增

還要確認訂閱或其他覆寫是否在重新啟動時替換 DNS 區段。OpenClash 的合併腳本只有在自訂 Fake-IP-Filter 已啟用且運作設定確實為 fake-ip 時，才會把自訂檔案項目插入原有 dns.fake-ip-filter 前方。腳本會先移除每行從 # 開始的註解並裁去首尾空白，再僅對正規化後完全相同的字串去除重複；語意上有包含關係的兩行仍會同時保留。外掛還可能加入其他產生項目，因此文字框不等於最終清單，檔案存在也不代表執行中的設定一定採用了它。

不要把單一症狀擴大成全域名規則：遊戲、印表機或公司網域異常時，先從日誌取得真正請求的主機名。沒有證據就加入 geosite:cn、整個廠商後綴或公共集合，可能改變大量查詢並產生更難追查的新問題。

若同時涉及 IPv6 節點網域、上游 AAAA 回應或 DNS 劫持，請改看本站的 OpenClash IPv6 節點網域解析分層排查，不要把不同故障都放進 fake-ip-filter。

保留原清單，建立可還原的維護方式

第一次修改前，可透過 SSH 將自訂清單複製到管理帳號可讀、且不會公開的位置。先確認來源檔案存在；若尚未產生，只要記錄 LuCI 中的停用狀態與空白清單。下方指令只備份清單、不修改訂閱，而且會覆蓋同名目的檔案；已有備份時先換一個新檔名：

OpenWrt Shellcp /etc/openclash/custom/openclash_custom_fake_filter.list   /root/openclash_custom_fake_filter.list.bak

需要還原時，在 LuCI 恢復原模式與原文字，或停用自訂 Fake-IP-Filter，再按「Apply Settings（套用設定）」讓 OpenClash 重新產生設定並啟動。若使用下方 SSH 指令複製備份，先重新載入 LuCI 頁面並確認文字已恢復，再按套用，避免舊頁面內容覆蓋檔案。確認 DNS 與原應用都恢復後，再嘗試更窄的規則。不要為了還原一條網域而刪除全部訂閱、規則集或用戶端。

確認備份正確後才執行cp /root/openclash_custom_fake_filter.list.bak   /etc/openclash/custom/openclash_custom_fake_filter.list

長期維護時，替每條規則記錄需要它的裝置或服務、原症狀與最後驗證日期。服務升級或網域改變後，可暫時移除一條再測試；不再需要的例外應刪除，避免清單累積成無法審查的第二份網域資料庫。

完成條件：只更改已確認的網域範圍；模式方向符合需求；DNS 查詢、OpenClash 日誌與真實應用請求都通過；原清單與還原方法仍可使用。

需要核對平台或取得 OpenClash、Mihomo 相關用戶端時，可前往本站 下載頁面。下載或更新不會取代本文的備份與單一變數驗證。

官方來源與版本邊界

版本號、檔案名稱與介面文字可能隨專案更新而變動，操作前請以連結中的專案文件為準。