設定實務 · Clash 技術部落格

Mihomo v1.19.30 invalid domain 修復

Mihomo v1.19.30 報 invalid domain 時，定位 fake-ip-filter 或 skip-domain 中的錯誤星號，改用合法通配符或列舉主機名，驗證設定並保留還原。

閱讀正文回到部落格
  • Mihomo
  • YAML
  • 設定驗證
  • 設定相容
本文目錄
發布日期
預計閱讀
約 9 分鐘

先確認是網域模式驗證失敗

本文只處理一組明確症狀：同一份設定在 Mihomo v1.19.29 或更早版本可以啟動，升級到 v1.19.30 後卻出現 Parse config error: invalid domain，核心在載入設定階段直接退出。

官方 issue #3116 在 Linux Docker 環境記錄了該變化，最終定位到 sniffer.skip-domain 與 dns.fake-ip-filter 中的網域模式。v1.19.30 收錄了更嚴格的 Clash 風格網域通配符驗證；這不是節點失效，也不是把代理模式切成 Direct 就能繞開的連線問題。

如果日誌是 Invalid YAML、unsupported field、proxy not found，或核心已經啟動但網頁打不開，故障發生在其他階段，應先按對應錯誤檢查，不能把所有設定失敗都改成本文的通配符寫法。

先按第一條錯誤分流

日誌或現象更可能的階段本文是否適用
Parse config error: invalid domain網域模式驗證升級到 v1.19.30 後出現時適用
Invalid YAML 或縮進錯誤YAML 文字結構不適用，先修語法
proxy / group not found策略群組或規則引用不適用，先補齊引用
核心已啟動，只有某個網域失敗DNS、規則或網路不適用，先看連線記錄

先儲存可用設定和產生來源

動手搜尋星號前，先分別儲存目前最終設定、用戶端的 Profile、Merge 或覆寫，以及訂閱轉換模板。只備份執行目錄中的 config.yaml 不夠：用戶端下一次更新訂閱時，來源中的錯誤模式還會把修復覆蓋回去。

如果舊核心仍在轉發，不要先重啟服務或連續重新整理訂閱。先保留目前可用狀態，再複製錯誤日誌、用戶端版本和實際 Mihomo 版本；截圖與設定副本要移除訂閱 token、節點密碼、控制器 secret 和私人網域。

準備一條可還原路徑

  1. 記錄實際核心版本

    從用戶端關於頁、啟動日誌或 mihomo -v 確認執行的是 v1.19.30，不用「最新版」代替版本號。

  2. 匯出最終設定

    儲存核心實際載入的 YAML，並另存 Profile、Merge、覆寫或轉換模板。

  3. 保留上一版核心

    只保留來自官方 Release、且本機曾驗證可用的 v1.19.29 檔案作為臨時還原。

  4. 固定其他變數

    檢查期間不同時換訂閱、節點、DNS 模式或 TUN 設定，避免新增第二個故障。

定位第一條無效網域模式

先用實際要執行的 v1.19.30 測試最終設定。官方 issue 使用的命令是 mihomo -t -f；測試模式成功只代表設定可以被目前核心解析和初始化，不會啟動代理，也不能證明節點可用。

v1.19.30 穩定版可能只回傳籠統的 invalid domain。此時在最終 YAML 和它引用的本機檔案中搜尋星號，優先檢查 issue 已確認出現問題的 sniffer.skip-domain 與 dns.fake-ip-filter。每修正一項就重新測試，讓核心繼續指出下一條錯誤。

使用目前 v1.19.30 測試最終設定
mihomo -v
mihomo -t -f /path/to/config.yaml
Linux / macOS 只讀搜尋網域清單中的星號
grep -R -n '\*' /path/to/config.yaml /path/to/rules 2>/dev/null

rrn-sw-*、a*.example.com 或 *a.example.com

星號混在同一個標籤裡，屬於 v1.19.30 明確拒絕的模式。

*.example.com 或 time.*.com

星號獨佔完整標籤，形式本身合法；繼續找下一項。

example.com.、a..example.com 或首尾帶空格

尾點、空標籤和首尾空白也會被嚴格驗證拒絕。

完全找不到星號

檢查加號、尾點、空標籤和用戶端產生的最終設定，不要只搜尋訂閱原文。

先分清三種合法網域通配符

Mihomo 文件把這裡的寫法稱為 Clash 風格網域通配符，並特別說明它與路由規則中的 DOMAIN-WILDCARD 不是同一種語法。不能從規則教學複製一個看似相同的星號表達式，直接放進 fake-ip-filter 或 skip-domain。

關鍵不是星號寫在前面還是後面，而是星號必須獨佔由點分隔的完整標籤。time.*.com 合法，因為中間一段只有星號；rrn-sw-* 不合法，因為星號和 rrn-sw- 混在同一個標籤裡。

按實際匹配範圍選擇寫法

合法寫法匹配範圍不會匹配
*.example.com恰好一級子域，如 a.example.comexample.com、b.a.example.com
+.example.com根域和任意層級子域其他後綴
.example.com任意層級子域example.com 根域
time.*.com中間恰好一個完整標籤time.com、time.a.b.com
*不含點的單標籤主機名帶點的完整網域
語法反例示例：這些部分標籤通配符會被 v1.19.30 拒絕
rrn-sw-*
a*.example.com
*a.example.com
a*b.example.com

按實際意圖改寫，不做機械式替換

如果意圖是匹配某個固定根域下的一級或多級子域，可以在星號、加號和點前綴之間選擇。若原意是匹配 rrn-sw- 開頭的一批區域網路主機，Clash 風格網域清單沒有與 rrn-sw-* 等價的部分標籤通配符；最穩妥的方法是列舉實際主機名。

不要把 rrn-sw-* 機械改成 *.rrn-sw、rrn-sw.* 或 +.rrn-sw。它們表達的是不同的標籤結構，可能透過驗證，卻不會命中原來想要的主機。先列出實際查詢名稱，再讓每條設定都能解釋其覆蓋範圍。

示例：列舉區域網路主機，並保留合法的網域範圍
sniffer:
  skip-domain:
    - "rrn-sw-01"
    - "rrn-sw-02"

dns:
  fake-ip-filter:
    - "+.example.com"
    - "time.*.com"

錯誤寫法與可執行處理

原始意圖不要這樣改可執行處理
匹配 rrn-sw- 開頭的短主機名繼續使用 rrn-sw-*列舉 rrn-sw-01、rrn-sw-02 等實際主機名
匹配 example.com 的一級子域a*.example.com使用 *.example.com
匹配根域與全部子域*example.com使用 +.example.com
只匹配全部子域，不含根域*.example.com 並誤以為含多級使用 .example.com

用同一 v1.19.30 驗證修復

儲存候選副本後，再用同一份 v1.19.30 執行設定測試。若仍報 invalid domain，繼續處理下一條，不要因為第一條消失就直接覆蓋唯一可用設定。所有錯誤清零後，才讓用戶端載入候選並重啟核心。

核心啟動只是第一層驗收。分別存取一條應該命中 fake-ip-filter 的網域、一條應該被 sniffer 跳過的網域和一個普通公用網路網域，再查看 DNS 結果與連線記錄。寫法透過驗證但匹配範圍錯誤，仍然不是完成修復。

按可還原順序上線候選

  1. 測試候選副本

    執行 mihomo -t -f，直到 v1.19.30 明確回傳設定測試成功。

  2. 儲存原件再替換

    保留上一份可用 YAML，不在用戶端執行中覆蓋唯一原件。

  3. 重載或重啟核心

    確認日誌顯示 v1.19.30 已啟動，沒有繼續讀取舊處理程式或舊設定。

  4. 重新測試實際匹配

    用確定的網域請求檢查 DNS、嗅探、規則命中和最終頁面存取。

修復完成標準

  • v1.19.30 對最終設定的測試模式透過
  • 核心能啟動並保持執行，沒有新的設定解析錯誤
  • 列舉的區域網路主機按預期跳過嗅探或 Fake-IP
  • 一級、任意層級與根域的匹配範圍符合所選語法
  • 普通公用網路網域和節點連線沒有被擴大後的規則誤傷
  • 原設定、產生來源和舊核心還原檔案仍可找到

更新後復發要修產生來源

如果手動修改後可以啟動，但重新整理訂閱、切換 Profile 或重啟用戶端又報同樣錯誤，說明無效模式來自轉換模板、遠端設定、Merge 或覆寫。此時不要反覆編輯臨時執行檔案，先比較修復前後的最終 YAML，找到是哪一層重新寫回了舊值。

能控制訂閱或轉換器時，直接修模板並重新產生；只能控制用戶端時，在受控 Merge 或覆寫中替換完整清單，並確認更新後最終設定仍然合法。不要把含 token 的訂閱上傳到陌生轉換站，也不要用一條過寬後綴覆蓋所有未知情況。

每次更新訂閱後復發

修訂訂閱轉換模板或上游設定，再產生候選。

切換 Profile 後復發

分別檢查每個 Profile 的 Merge、Script 和本機覆寫。

磁碟檔案已改，核心仍報舊值

確認實際載入路徑、處理程式和用戶端產生的最終設定。

只能靠寬泛後綴才能啟動

先列舉必要主機並記錄缺口，不把擴大範圍當長期答案。

無法立即修正時先安全還原

若設定由不可控來源持續產生、短時間內無法完成修訂，可以先關閉 TUN 或系統代理，恢復系統直連，再還原備份設定。確有業務依賴時，可臨時回到本機已驗證的 v1.19.29，等待產生源修正後重新測試 v1.19.30。

還原只用於恢復服務，不能證明舊寫法正確。v1.19.30 的嚴格驗證提交已經進入目前穩定版，而更詳細的錯誤路徑提交在其後出現；不要把「舊版不發生錯誤」和「新 Alpha 更容易定位」混成長期版本策略。

恢復已知可用狀態

  1. 停止失敗的核心重試

    先關閉用戶端接管，避免系統流量持續指向沒有執行的本機連接埠。

  2. 恢復設定備份

    還原 Profile、最終 YAML 與必要覆寫，不匯入來源不明的完整目錄。

  3. 必要時臨時還原核心

    只使用官方 v1.19.29 和本機已驗證架構，記錄還原原因與日期。

  4. 安排同版本重新測試

    產生源修正後回到 v1.19.30，重複設定測試、啟動和實際網域驗證。

參考資料