Mihomo v1.19.30 の invalid domain エラーを修正する

この記事で扱うのは、明確な一連の症状だけです。同じ設定が 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 と表示される場合、またはカーネルは起動していても Web ページを開けない場合、障害は別の段階で発生しています。該当するエラーに沿って先に調査し、すべての設定エラーをこの記事のワイルドカード形式へ置き換えないでください。

アスタリスクを検索する前に、現在の最終設定、クライアントの Profile、Merge またはオーバーライド、サブスクリプション変換テンプレートを個別に保存します。実行ディレクトリ内の config.yaml だけをバックアップしても不十分です。クライアントが次にサブスクリプションを更新すると、生成元の誤ったパターンによって修正が再び上書きされます。

古いカーネルが引き続き転送している場合は、先にサービスを再起動したり、サブスクリプションを何度も更新したりしないでください。まず現在の利用可能な状態を維持し、その後エラーログ、クライアントのバージョン、実際の Mihomo バージョンをコピーします。スクリーンショットと設定のコピーからは、サブスクリプションの token、ノードのパスワード、コントローラーの secret、個人用ドメインを削除してください。

まず、実際に使用する v1.19.30 で最終設定をテストします。公式 issue で使われたコマンドは mihomo -t -f です。テストモードの成功が示すのは、現在のカーネルで設定を解析して初期化できることだけです。プロキシは起動せず、ノードが利用可能であることも証明しません。

v1.19.30 の安定版は、詳細を示さず invalid domain だけを返す場合があります。その場合は、最終 YAML と参照しているローカルファイルからアスタリスクを検索し、issue で問題が確認された sniffer.skip-domain と dns.fake-ip-filter を優先して調べます。一項目を修正するたびに再テストし、カーネルが次のエラーを示せるようにしてください。

Mihomo のドキュメントでは、この書式を Clash 形式のドメインワイルドカードと呼び、ルーティングルールの DOMAIN-WILDCARD とは異なる構文であると明記しています。ルールのチュートリアルから似たアスタリスク表現をコピーし、fake-ip-filter または skip-domain へ直接記述しないでください。

重要なのはアスタリスクを先頭と末尾のどちらへ書くかではなく、ドットで区切られた一つの完全なラベルをアスタリスクだけで構成することです。time.*.com が正しいのは、中間の部分がアスタリスクだけだからです。rrn-sw-* は、アスタリスクと rrn-sw- が同じラベルに混在するため正しくありません。

固定したルートドメインの直下または複数階層のサブドメインへ一致させる場合は、アスタリスク、プラス記号、ドット接頭辞から選べます。元の目的が rrn-sw- で始まる一連の LAN ホストへ一致させることなら、Clash 形式のドメイン一覧には rrn-sw-* と同等の部分ラベルワイルドカードがありません。実際のホスト名を列挙する方法が最も確実です。

rrn-sw-* を機械的に *.rrn-sw、rrn-sw.*、+.rrn-sw へ変更しないでください。これらが表すラベル構造は異なるため、検証に通っても目的のホストへ一致しない場合があります。まず実際に問い合わせる名前を列挙し、各設定が対象範囲を説明できるようにしてください。

候補のコピーを保存してから、同じ v1.19.30 で設定テストを実行します。引き続き invalid domain と表示される場合は、次の項目へ対処してください。最初のエラーが消えただけで、唯一利用可能な設定を上書きしないようにします。すべてのエラーがなくなってから、クライアントに候補を読み込ませてカーネルを再起動してください。

カーネルの起動は、最初の受け入れ条件にすぎません。fake-ip-filter へ一致するはずのドメイン、sniffer でスキップするはずのドメイン、通常のインターネットドメインへそれぞれアクセスし、DNS の結果と接続記録を確認します。書式が検証を通っても一致範囲が誤っていれば、修正完了ではありません。

手動修正後は起動できても、サブスクリプションの更新、Profile の切り替え、クライアントの再起動で同じエラーが再発する場合、無効なパターンは変換テンプレート、リモート設定、Merge、オーバーライドのいずれかから生成されています。一時的な実行ファイルを繰り返し編集せず、修正前後の最終 YAML を比較し、どの層が古い値を書き戻したかを特定してください。

サブスクリプションまたは変換ツールを管理できる場合は、テンプレートを直接修正して再生成します。クライアントだけを管理できる場合は、制御可能な Merge またはオーバーライドで一覧全体を置き換え、更新後の最終設定も正しいことを確認してください。token を含むサブスクリプションを不明な変換サイトへアップロードせず、広すぎるサフィックス一つですべての未知の状況を覆わないようにします。

制御できない生成元が誤った設定を出力し続け、短期間では修正できない場合は、まず TUN またはシステムプロキシを無効にしてシステムの直接接続を復元し、バックアップ設定へ戻します。業務上の依存がある場合は、手元の端末で動作確認済みの v1.19.29 へ一時的に戻し、生成元の修正後に v1.19.30 を再テストできます。

ロールバックはサービスを復旧するためだけのもので、古い書式が正しいことを証明しません。v1.19.30 の厳格な検証を導入するコミットは現在の安定版に含まれ、より詳細なエラーパスを示すコミットはその後に追加されています。「旧版ではエラーにならない」と「新しい Alpha の方が特定しやすい」を混同し、長期的なバージョン方針にしないでください。