エラーの意味：正しいYAMLでもMihomo設定として正しいとは限らない

yaml: unmarshal errors は、プログラムが YAML を内部設定構造へ変換するとき、あるキーや値を期待するフィールドへ入れられなかったことを示します。まったく YAML でない場合と重なることはありますが、同じではありません。一般 YAML として読めても、文字列型のフィールドに配列、真偽値型のフィールドにオブジェクト、現在の設定スキーマにないキーがあると変換段階で失敗します。

原因を2種類に分けます。1つ目は Tab、インデント、コロン後の空白、閉じていない引用符などの YAML 構文です。2つ目は未知フィールド、親の誤り、バージョンの違い、値の型など Mihomo の設定構造です。Mihomo YAML 構文ガイドは大文字・小文字、スペースによるインデント、同階層の左揃え、コロン後の空白、配列のハイフンを説明します。設定リファレンスで各フィールドを確認します。

2つの問い：「構文上正しい YAML か」と「使用中の Mihomo バージョンの設定スキーマに合うか」を別々に確認します。一般的な linter の合格は前者だけです。

この表示だけでサブスクリプションを削除したり、クライアントを再インストールしたりしません。元のファイルを複製し、エラーメッセージ全文、クライアントとコアバージョン、設定の出所、直前の変更を記録します。サブスクリプション更新後なら更新前のバージョン、手動編集後なら今回の差分を残します。大規模な作り直しより小さな差分比較が有効です。

最初の行番号から始め、親と直前の項目も見る

line 42: cannot unmarshal ... のような1行または複数行が出ます。最初の1件から直します。前の行にある階層ミスが後続キーを誤った親に入れ、多数の二次エラーを生むためです。表示行は矛盾を確定できた場所であり、誤字の場所とは限りません。閉じていない引用符や親のインデント不足が数行上にある場合があります。

  1. 直前まで使えていたファイルを読み取り専用で保存し、唯一のコピーを編集しない。
  2. 行番号、空白文字、UTF-8 を表示するテキストエディタで作業版を開く。
  3. 最初のエラー行、その親、直前の配列項目を見る。
  4. その小さなブロックだけを公式フィールド例と比較する。
  5. 確定した1項目だけ直し、新しいバージョンとして再検証する。

実際のノードを含む行は公開しません。フィールド名と型を残し、サーバー、UUID、パスワード、サブスクリプションのパラメータを置換します。ただし先頭空白とハイフンは階層の証拠なので保持します。左端を切った画像は診断に必要な情報を消します。

断片主な分類確認範囲
did not find expected keyキー、引用、前の行にある構文の中断現在行とその数行前
cannot unmarshal !!seq into string文字列型のフィールドに配列リファレンスとハイフン
cannot unmarshal !!map into bool真偽値型のフィールドにマップインデントと期待される型
field ... not found未知キー、つづり、バージョン現在のコアのリファレンス

画面上の折り返しは行番号を変えませんが、チャットへの貼り付けは Tab を変換することがあります。元の作業版で不可視文字を見て、必要なら機密情報を除いた最小ブロックだけ共有します。

インデント、Tab、コロン、引用符を先に直す

YAML はインデントで親子関係を表します。公式構文ガイドは Tab ではなくスペース、同階層の左揃え、キーのコロン後の空白、配列項目のハイフンを求めます。スペース2個か4個かはファイル内のスタイルに合わせられますが、同じ論理階層は揃える必要があります。

次の不正例は配列前が Tab で、type と name も同階層ではありません。

proxies:
	- name: Example
    type: ss

スペースへ変え、同じプロキシオブジェクトのキーを揃えます。

proxies:
  - name: Example
    type: ss

mixed-port: 7890 のフィールドコロン後には空白が必要です。URL、IPv6、# を含む文字列は、公式例に従い、曖昧になる場合は引用符で囲みます。引用符は対にし、ワープロの曲がった引用符を ASCII 引用符として使いません。

すべての空白を一括整形しない：複数行文字列、スクリプト、ルール内容まで変わる可能性があります。確認済み構造だけを直し、編集前のコピーを残します。

YAML 1.2.2 仕様は一般構文、Mihomo のリファレンスは実際のフィールドの確認に使います。構文上正しい YAML にした後、型へ進みます。

構文合格後、文字列、数値、真偽、マップ、配列を確認する

cannot unmarshal の変換元と変換先の型を読みます。!!seq は配列、!!map はキーと値のマップ、!!str は文字列で、整数と真偽値にも型があります。すべてのハイフンを消す指示ではなく、特定フィールドへ定義と違う構造が渡ったという意味です。

次はポートを引用符付きの文字列、真偽値のスイッチを配列にした例です。

mixed-port: "7890"
allow-lan:
  - true

リファレンスを確認すると、この形になります。

mixed-port: 7890
allow-lan: true

一方、proxies、proxy-groups、rules は通常配列です。!!seq を消すため全部を1行の文字列にしてはいけません。現在のコアバージョンのリファレンスで各フィールドを調べます。名前は大文字・小文字とハイフンを区別し、別クライアントや旧版由来のキーは未対応または親が違う場合があります。

  • unknown field：つづり、大文字・小文字、バージョン、親を確認。
  • sequence into scalar：単一の値か複数項目かを確認。
  • map into scalar：余分なインデントで後続キーを取り込んでいないか確認。
  • 重複キー：暗黙の上書き動作に依存せず意図して統合。
  • null・空：リファレンスに従い省略、有効値、空文字を選択。

リモートのサブスクリプションなら、更新で消えるキャッシュを恒久的に修正しません。提供形式が Mihomo 対応か確認し、ローカル変更はクライアントが正式に対応しているオーバーライド機能へ分離します。

同じバージョンのコアで最小修正を検証してから完全運用へ戻す

大きな設定にはノード、ルールプロバイダー、DNS、TUN、スクリプトが同居します。疑わしいすべてのセクションを一度に削除せず、元のファイルを残して最初のエラーへの最小修正を行います。場所が不明ならオフラインの作業用コピーで不要部分を半分ずつ除外しますが、YAML 階層を保ち、各操作を記録します。

クライアントと同じバージョン・同じ環境の Mihomo で設定を試せます。一般的なコマンド形式は次のとおりで、パスは機密を除いたローカル作業版へ置き換えます。

mihomo -t -f /path/to/config.yaml

検証のため信頼できないサイトから別コアを取得しません。オンライン YAML 検査は設定全体を送信して認証を漏らす可能性があり、構文しか確認しないこともあります。ローカルを優先し、相談時は再現する最小範囲だけを共有します。

  1. 元のファイルと直近の正常なバージョンを読み取り専用で保存する。
  2. 最初の構文・型エラーだけ直し、同じバージョンで再検証する。
  3. 残りを順番に扱い、ファイル全体を一度に書き直さない。
  4. 合格後、System Proxy と TUN を切った状態で読み込む。
  5. プロファイル、グループ、DNS ログ、実際の接続を確認する。
  6. 安定後に本番設定へ反映し、復元用コピーを保持する。

完了条件：設定検査にエラーがなく、コアが安定して稼働し、想定したグループがあり、ログが正しいファイルを読み、実際のリクエストが説明できるルールを通ることです。保存成功だけでは足りません。

未知フィールドが残るなら、コアバージョン、最初のエラーメッセージ全文、機密情報を除いた親ブロック、参照した公式文書を伝えます。サブスクリプショントークン、サーバーパスワード、本番設定全体は添付しません。

公式情報源とバージョン範囲

バージョン番号、ファイル名、画面表示は更新で変わる場合があります。作業前にリンク先の公式資料を確認してください。