症状：設定はあるのにコアが立ち上がらない

Clash Meta（コア実体として広く使われる mihomo）は、起動時にプロファイルを YAML としてパースし、内部構造へ unmarshal（復元）します。ここで文法や構造が許容範囲を外れると、GUI によっては「読み込み中のまま」「エラーtoast だけ」といった見え方になり、根本ログには yaml: unmarshal errors や行番号に近いヒントが残ります。ルールの中身が正しくても、字下げが一段ズレただけで止まるのが YAML 利用のつらいところです。

本記事は「分流の考え方」より前に、そもそも設定が読める状態に戻すことに絞ります。分流や GeoIP の詳細は ルール分流の詳解、サブスク運用は サブスクリプション管理の記事 と併読すると、復旧後の調整がスムーズです。

最初に：必ずバックアップと差分を取る

直す前に、問題のファイルを別名でコピーしてください。クライアントが自動バックアップを持っていても、人間が編集して壊した版が上書きされる事故はよくあります。可能なら Git やタイムスタンプ付きコピーで履歴を残し、「いつから読めなくなったか」を後から辿れるようにします。

ログで手掛かりを拾う（unmarshal と行番号）

まずコア／GUI のログを開き、unmarshal、yaml:、mapping key、already set などの語を探します。行番号が出る場合は、その周辺の インデント と 同名キーが二度出ていないか を最優先で疑ってください。行番号はエディタの表示と完全一致しないこともありますが、だいたいの位置感は掴めます。

クライアントによっては「検証」ボタンや設定プレビューがあります。ログと併用し、同じエラーが再現するか を確認すると迷いが減ります。

インデント：スペース幅の統一とタブ禁止

YAML は字下げの深さが意味を持ちます。Clash 系の設定例は多くが 半角スペース 2 個を一段とするスタイルです。ここで タブ文字が混ざると、見た目は揃っていてもパーサが別階層と解釈し、配列の要素が親マッピングから外れたり、rules: のリストが途中で切れたりします。

エディタで「空白を可視化」し、タブをスペースに変換する設定を有効にしてください。また、コピペで 全角スペースが紛れ込むと地獄なので、疑わしい行は一度打ち直すのが早いです。 

# Bad: tab-indented list item (use spaces only)
rules:
	- MATCH,DIRECT

# Good: two spaces per level
rules:
  - MATCH,DIRECT

重複キー：トップレベルで proxy-groups が二重

YAML 1.1 系のパーサでは、同一マッピング内で 同じキーが二度出るとエラーか、後勝ちのような危険な挙動になります。Clash の設定で特に多いのは、サブスク由来の断片と手元の追記をくっつけた結果、proxy-groups: や rules:、proxies: がファイル内に二回現れるパターンです。片方は古いまま残り、もう片方だけ編集していた——というオペミスも典型です。 

# Example only — duplicate top-level keys (invalid / risky)
proxy-groups:
  - name: GroupA
    type: select
    proxies: [DIRECT]

proxy-groups:
  - name: GroupB
    type: select
    proxies: [DIRECT]

対処はシンプルで、論理的に一つにまとめるか、proxy-providers や rule-providers、script など別機構へ寄せることです。単純に二つのブロックを連結するだけでは、同名グループやプロキシ名の衝突で別のエラーに進むので、中身の name: も含めて整理してください。

rules はリストか、誤ってマップになっていないか

rules: の直下は通常 ハイフン付きの配列です。インデントを一段足りないと、行が前のキーの「値の続き」として解釈され、型が期待と合わず unmarshal 失敗に繋がります。proxy-groups 内の proxies: も同様で、リストとマップを取り違えると一気にエラーが増えます。

サブスク更新・追記ファイルとの「二重定義」

リモートのサブスクとローカルの prepend-rules などを組み合わせる構成では、最終的に一つの設定ツリーにマージされます。クライアントの実装次第では、マージ結果が一時ファイルとして書き出され、その段階で重複キーや順序の問題が表面化します。追記だけを疑うのではなく、サブスク本体が既に巨大な rules: を持っている前提で、ローカル追記の位置（先頭か末尾か）を見直してください。

定期更新の運用全般は サブスクリプション管理の記事 の流れと相性が良いです。ここでは「更新後だけ壊れた」なら、まず一つ前の世代のプロファイルに戻して起動確認し、差分を小さくしながら原因行を特定するのが安全です。

Clash Meta 固有：拡張フィールドとバージョン差

mihomo／Clash Meta では、コアのバージョンによって受け付けるキーや型が増減します。古いクライアントに新しいキーだけ載せた YAML を流し込むと、unmarshal で落ちることがあります。逆に、大きく古い文法だけのファイルを最新コアへ持ち込む場合も、移行ガイドに沿った方が早いです。内核の入れ替えや互換性の整理は Clash Meta のアップグレード解説 を参照してください。

検証のコツ（外部ツールとプライバシー）

ローカルで yamllint やエディタの YAML 拡張を使うと、インデントと重複キーを機械的に拾えます。ブラウザ上のパーサに本番のサブスク全文を貼らないよう、ノード名やトークンをマスクした抜粋で試す習慣をつけてください。構文が通っても、proxy-groups が参照する名前が存在しないといった意味論のエラーは別段階のチェックが必要ですが、まずは「パース可能」に戻すことが先決です。

復旧チェックリスト（短時間で回す）

（1）ログの unmarshal 付近を開き、行の目安をメモする。（2）エディタで タブ→スペース、全角スペース削除。（3）proxy-groups・rules・proxies がトップレベルで重複していないか全文検索。（4）サブスク直後だけ失敗するなら直前版にロールバックして差分を縮める。（5）拡張キーを足したならコアのバージョンとドキュメントを照合。（6）構文が通ったら、GUI か external-controller 経由で設定リロードを試す。

まとめ

Clash Meta の「設定が効かない」問題のうち、起動時点で止まるタイプは YAML の文法と構造に原因が集約されがちです。インデントの統一、重複キーの排除、サブスクと追記のマージ結果の想像、この三つを押さえれば、unmarshal 系のエラーはかなりの割合で解消できます。分流や DNS の話は、そのあとで十分です。

ルール表現の柔軟さとコミュニティの知見の豊富さから、用途に合わせ設定を磨き込める点は Clash 系クライアントの強みです。実行ファイルの入手は本サイトの ダウンロードページ からどうぞ。ソースやライセンスは公式リポジトリも参照できますが、配布物の入手経路はサイトの案内と揃えると説明と版の対応が取りやすくなります。

Clash を無料ダウンロードして、プロファイルを試す → 各 OS 向けのビルドが揃っており、画面の案内に沿えば短時間で初期設定まで進められます。