Clash 起動クラッシュの対処法:よくある原因と手順別チェックリスト

クラッシュはどの段階で起きているか:まず3つの典型パターンを見分ける

クライアントのクラッシュは単一の現象ではなく、調査を始める前にどの段階で発生しているかを確認しておく必要がある——これが以降の調査方向を決める。実際のケースはおおむね3つのタイミングに分類でき、それぞれ原因の傾向が大きく異なる。

• 起動直後にクラッシュする:メイン画面が表示される前にプロセスが終了する。多くは設定ファイルの解析失敗、コアバイナリの破損、実行権限の不足が原因。
• サブスクリプション読込みや設定切替後にクラッシュする:画面自体は開くが、特定の設定を読み込んだ瞬間に終了する。その設定ファイル自体に問題があると絞り込める。
• 一定時間動作したあとにクラッシュする:起動時は正常だが、使用中に落ちる。TUN モード有効化後にシステムのネットワークスタックと競合したり、特定の通信がルールに一致した際にコア側で異常が発生することが多い。

クラッシュを上記いずれかに分類できれば、調査時間を大幅に短縮できる。以下では実際の報告で頻度が高い順に原因を掘り下げる。

設定ファイルの構文エラー:最も発生頻度が高い原因

Clash および Clash Meta(mihomo コア)の設定ファイルは YAML 形式を採用しており、インデント・コロン後のスペース・参照関係に非常に敏感で、わずかな記述ミスがパーサーの例外を引き起こし、プロセス全体を落とすことがある。よく見られるエラーは次の通り。

• タブとスペースのインデントが混在している、または同階層のフィールドのインデントレベルが揃っていない;
• proxy-groups の中で proxies に存在しないノード名を参照している;
• rules の中で未定義のプロキシグループを指しているルールがある;
• 文字列中の特殊文字(#、: など)が引用符で囲まれておらず、コメントやキー・バリューの区切りと誤認識される。

よくあるミスの例:

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノードA
      - ノードB
    url: http://www.gstatic.com/generate_204
  interval: 300

この例では interval のインデントが1段足りず、同じプロキシグループに属さなくなっているため、解析時にフィールドの位置がずれてしまう。修正方法は interval を name、type と同じ階層に揃えることである。

構文が正しいかどうかは、まずクライアント内蔵の「設定検証」や「テスト設定」機能を使って確認し、直接切り替えて試すのは避ける。検証機能がないクライアントの場合は、任意の YAML オンラインチェックツールを使い、インデントとフィールドの所属関係を重点的に確認する。

ポート競合とネットワーク権限の衝突

Clash は起動時に混合ポート、SOCKS ポート、そして(内蔵 DNS が有効な場合)DNS リスニングポートのバインドを試みる。これらのポートが他のプログラムに既に使われている場合、コアはバインド段階で失敗し、一部のクライアントでは明確な通知を出さずにクラッシュ終了する。

• 別のプロキシツールを同時に起動していて、同じデフォルトポート(7890/7891 など)を使っている;
• システムのセキュリティソフトやファイアウォールがローカルのリスニング動作を遮断している;
• モバイル端末(特にシステムレベルの VPN インターフェースを使うクライアント)で、既に別の VPN 設定が有効な状態から再度起動すると、システムのネットワーク拡張と競合が発生する。

デスクトップ環境でポート競合を調査する場合は、ターミナルでポート照会コマンドを実行し、対象ポートが他のプロセスに使われていないか確認する。競合が確認できたら、設定ファイル内の mixed-port や socks-port を未使用のポート番号に変更すれば回避できる。モバイル端末でこの状況に遭遇した場合は、まずシステム設定側で他に接続中の VPN やプロキシ構成プロファイルを無効化してから Clash クライアントを起動することを推奨する。

コアバージョンと設定フィールドの不一致

Clash Meta(mihomo)は更新が速く、フィールドの追加・廃止のペースも速い。設定ファイルがネット上のチュートリアルや旧バージョンのクライアントから流用されたものである場合、現在のコアが既に対応していない書式が含まれている可能性があり、解析段階でエラーやクラッシュが発生する。よくあるケースは次の通り。

• 設定内に新しいコアバージョンでのみ対応するフィールド(一部の smart 型プロキシグループのパラメータなど)が使われているが、クライアントに内蔵されているコアが古く、そのフィールドを認識できない;
• 逆に、旧設定内のフィールドが新しいコアで既に廃止・削除されており、解析時に対応する処理が見つからない;
• コアバイナリ自体が更新過程で破損またはダウンロード不完全となっており、設定内容とは無関係に起動時点でクラッシュする。

調査方法:まずクライアントが現在使用しているコアのバージョン番号を確認し、設定ファイルの想定バージョンと一致しているか照合する。コアファイルの破損が疑われる場合は、クライアントを再度完全にインストールすることで解決することが多い。フィールドの非互換が疑われる場合は、コアの変更履歴に沿って設定の書式を調整するか、エラー発生前後で追加したフィールドを一時的に削除し、段階的に特定していく。

原因カテゴリ	典型的な症状	発生頻度
設定ファイルの構文エラー	読込み/切替後に即クラッシュ	高
ポート競合	起動直後に無通知で終了	中〜高
コアバージョンの不一致	特定フィールドの解析失敗	中
システム権限の制限	VPN/ネットワーク拡張の接続が確立できない	中
ルールやグループ設定の競合	一定時間動作後にクラッシュ	低

システム権限の制限:iOS では特に見落としやすい

iOS 上で Clash クライアントはシステムのネットワーク拡張(Network Extension)フレームワークに依存してローカルプロキシトンネルを確立する。この権限は通常のアプリ権限より扱いがセンシティブで、欠落や制限があると機能が使えなくなるだけでなく、クラッシュを直接引き起こすこともある。重点的に確認すべき項目は次の通り。

• VPN 構成プロファイルの信頼:VPN 設定を初めて追加する際、システムは信頼確認のダイアログを表示する。誤って「許可しない」を選んだ場合、以後プロキシ関連機能の起動が異常になる;
• TestFlight 版の有効期限:TestFlight で配布されるテスト版には90日間の使用期限があり、期限が切れるとシステムにより実行が制限され、「開かない」または起動直後に終了するような挙動になる;
• ネットワーク拡張のスイッチ:「設定 - 一般 - VPN とデバイス管理」で対応するネットワーク拡張が手動で無効化されていないか確認する;
• 低電力モードとバックグラウンド制限:一部のシステム省電力ポリシーはネットワーク拡張プロセスへのリソース割り当てを制限し、長時間サスペンド後の再開時に異常が発生する場合がある。

TestFlight 版の期限切れが原因の場合は、招待リンクから最新のテスト版を再インストールすれば復旧する。権限が誤って無効化されている場合は、システム設定に入って対応するネットワーク拡張の項目を再度有効にし、クライアントを再起動する。

最小構成で問題を特定する:段階的追加調査法

上記のすべてを確認しても明確な原因が見つからない場合、最も有効な方法は、正常に動作すると確定できる最小構成に戻し、そこから内容を段階的に元に戻していき、どの段階でクラッシュが再現するかを観察することである。出発点として使える最小構成の一例は次の通り。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
  - name: 直接接続テスト
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,直接接続テスト

この最小構成が正常に起動することを確認したら、次の順序で段階的に戻していく。

1. まず実際のノードを1つ proxies に追加し、ノード情報自体の書式が正しいか確認する;
2. 次に自動速度測定や手動選択を含む完全な proxy-groups 構造を追加する;
3. 続いて rules のルールを分けて追加していく。一度に数百行を貼り付けるのではなく、十数行ずつ追加して毎回再起動して確認することを推奨する;
4. 最後に TUN モードやカスタム DNS 設定(元の設定で使っていた場合)を有効化する。この2つはシステム層への依存が深いため、個別に検証した方が問題を絞り込みやすい。

どの段階で追加した後にクラッシュが再現するかが分かれば、問題はほぼその部分に絞られるため、対象を絞って構文やフィールドの値を確認すればよく、設定全体を最初から見直す必要はない。