Clashを開くと落ちるときの対処法｜起動クラッシュの原因と解決手順

まずは原因を切り分ける：アプリのクラッシュ、コアの停止、VPN接続の失敗

「Clashを開くと落ちる」といっても、アプリの画面が終了する、プロキシコアが停止する、システムのVPN接続が確立しない、という3つの異なる問題が考えられます。どの段階で止まるのかを確認してから、設定を変更しましょう。Webページが開かない、ノードがタイムアウトする、サブスクリプションを更新できないといった症状だけでは、アプリがクラッシュしたとは限りません。

確認できる症状	優先して確認する項目	最初に行うこと
アイコンをタップするとホーム画面に戻り、設定画面も開けない	アプリデータ、インストールパッケージのアーキテクチャ、OSとの互換性	強制停止してから再起動し、システムのメッセージを記録する
画面は開くが、サービスを起動するとすぐ停止する	設定の解析、コアの機能、リソースファイル	起動ログで最初に出たエラーを確認する
接続をタップすると失敗するが、画面は操作できる	VPNの許可、他のVPN、常時接続VPNの設定	まずVPNを使用する他のアプリを切断する
画面消灯後に切断されるが、再度開くと接続できる	バッテリー最適化、バックグラウンド制限、メモリ解放	バックグラウンド実行の権限を確認し、設定はまだ消去しない

まず、端末の機種とOSバージョン、クライアント名とバージョン、コア名とバージョン、問題が起きる操作の4点を記録してください。特に「サブスクリプション更新後」「クライアントのアップグレード後」「TUNの有効化後」のどのタイミングで発生したかが重要です。何度も再インストールするより、こうした情報のほうが原因究明に役立ちます。

手順1：設定を残したまま、リスクの低い方法から試す

アプリを開ける場合は、まずローカル設定とオーバーライドをエクスポートしてください。サブスクリプションURLには通常、アクセス用の認証情報が含まれるため、信頼できる非公開の場所に別途保存し、公開スクリーンショットには写さないでください。設定を再取得できることを確認してから、データの消去を検討しましょう。

他のVPNアプリを終了します。ローカルVPNで通信をフィルタリングするファイアウォール、広告ブロッカー、パケットキャプチャツールなども終了し、テスト時にシステムのVPN接続を取り合わないようにします。
クライアントを強制停止します。Androidでは「設定」→「アプリ」→「すべてのアプリを表示」→対象のクライアント→「強制停止」の順に操作します。メニュー名はメーカーによって多少異なる場合があります。
もう一度アプリを開きます。設定画面に入れる場合は、クライアントの「起動時に自動接続」オプションを一時的にオフにして、画面が安定しているか確認します。
必要に応じて端末を再起動します。再起動後は他のVPNを起動せず、対象のクライアントだけを起動して、複数のサービスによる干渉を減らします。

手順2：YAMLの構文とサブスクリプションの応答内容を確認する

サブスクリプションの更新やルールの変更直後に問題が起きた場合は、まず設定の解析状況を確認します。通常、クライアントは設定エラーを報告しますが、異常な設定を処理する際に終了してしまうものもあります。最後に表示された「サービス停止」だけで判断せず、ログをさかのぼって最初の解析エラーを探してください。

ログのキーワードから原因を絞り込む

yaml、unmarshal、line：インデントや型、エラーの近くにある行を優先して確認します。実際の原因が、エラー表示の1行前にある場合もあります。
proxy not foundまたはプロキシグループの参照エラー：ルールから参照されているプロキシグループが存在するか、名前の表記、大文字・小文字、空白が一致しているか確認します。
unsupported、unknown：ログが示しているのがプロトコル、ルールの種類、フィールドのどれかを確認し、コアとの互換性を調べます。
ダウンロードした内容が<htmlで始まる：設定ファイルではなく、ログインページ、エラーページ、アクセス認証ページを取得した可能性があります。

YAMLの階層インデントにはスペースを使い、タブを混在させないでください。コロンやシャープなどの特殊文字を含む名前や文字列は、必要に応じて引用符で囲みます。サブスクリプションURLをブラウザーで開けても、Clashの設定が返されるとは限りません。エンコードされたノード一覧しか含まれない形式もあるため、形式に対応したURLを提供元に確認してください。

最小構成で問題を切り分ける

クライアントがローカルYAMLのインポートに対応している場合は、一時的な設定を新規作成してテストします。元の設定を上書きしないでください。以下は基本的な解析とコアの起動を確認するためのもので、プロキシノードは含まれておらず、通信のプロキシ転送機能もありません。モバイルクライアントではVPN、DNS、TUNの設定が別途生成されることがあるため、クライアントごとのインポート要件に従ってください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

7890はこのサンプルで使用するローカルの混合プロキシ待ち受けポートであり、リモートノードのポートではありません。モバイルクライアントによっては、この値が上書きされます。最小構成で起動でき、元の設定では起動できない場合は、プロキシグループ、ルールセット、オーバーライドを一つずつ戻してください。項目を戻すたびにテストすれば、複数を同時に追加して原因を見失うのを防げます。

サブスクリプションから生成された設定の場合、修正はできるだけクライアントが対応するオーバーライド機能で行うか、設定の提供元にソースファイルの修正を依頼してください。ダウンロードした設定を直接編集すると、次回の更新で上書きされる可能性があります。

手順3：クライアントのコアと設定機能の互換性を確認する

Clashはプロジェクトや設定エコシステムで広く使われる名称であり、同じ名前のクライアントがすべて同じコアを使っているわけではありません。Clash Metaの系統はその後mihomoとして開発が続けられており、対応範囲は従来のClashと完全には一致しません。見た目が似たクライアントでも、対応するプロトコル、ルールのフィールド、TUNの実装が異なる場合があります。

設定更新後にクラッシュする場合は、追加した機能を確認する

たとえば、特定のプロトコル、rule-providersフィールドの拡張オプション、特定のDNS設定を追加すると、古いコアでは対応できないことがあります。未知のフィールドは無視される場合もあれば、検証エラーを引き起こす場合もあります。「エラーが出ないから反映されている」とは限りません。該当するコアのバージョンのドキュメントと実際のログを確認してください。

クライアントの「このアプリについて」またはコア情報画面で、アプリとコアそれぞれのバージョンを記録します。両者を混同しないでください。
エラーが示すフィールドやプロトコルを確認し、コアの説明と照らし合わせて対応状況を調べます。
アップグレードが必要な場合は、クライアントの正式な安定版を選び、事前に設定のコピーを保存してください。
アップグレード後は、まず最小構成で起動し、次に完全なサブスクリプションをインポートして、最後にローカルのオーバーライドを戻します。

Androidのインストールパッケージはアーキテクチャも確認する

一般的なarm64-v8aとarmeabi-v7aは異なるアーキテクチャです。エミュレーターではx86_64が使われることもあります。アーキテクチャに互換性がない場合は通常、インストール時にエラーが出ますが、対応するネイティブライブラリがないことで起動時に問題が表面化する場合もあります。プロセッサが64ビット対応だからといって、OSがすべての64ビットアプリに対応するとは限りません。クライアントのリリース情報と端末のOSに合わせてパッケージを選んでください。

アプリのアップグレード直後に問題が始まったことが明らかな場合は、ログを保存し、プロジェクトの既知の問題を確認してください。ダウングレードは万能な解決策ではありません。新しいバージョンが保存したデータ形式を旧バージョンで読み込めない場合や、旧パッケージを上書きインストールできない場合があります。入手元の異なるクライアントを何度も上書きインストールするのは避けてください。

手順4：キャッシュ、リソース、アプリデータの順に対処する

キャッシュの破損、ルールセットのダウンロード中断、ローカルデータベースの異常などにより、起動時の失敗が繰り返されることがあります。影響の小さい操作から試してください。Androidでは「設定」→「アプリ」→対象のクライアント→「ストレージとキャッシュ」→「キャッシュを消去」の順に進み、完了したら再起動します。

画面を開ける場合は、問題のあるリソースだけを再取得する

ログに特定のルールプロバイダーが記録されている場合は、該当するrule-providersだけを更新するか一時的に無効にします。サブスクリプションをすべて削除しないでください。
地理データベースの読み込み失敗がログに明記されている場合は、クライアントに用意されたリソース更新機能を使い、ダウンロードの完了を確認してから起動します。
空き容量不足やファイル書き込みエラーが発生した場合は、まず端末のストレージ空き容量を確認し、更新時に不完全なファイルが再び作成されないようにします。

システムのキャッシュを消去しても、クライアントが保存したデータベースや設定リソースが削除されるとは限りません。ファイルの保存場所はアプリによって異なります。キャッシュを消去しても症状がまったく変わらない場合は、同じ操作を繰り返すのではなく、ログを見直してください。

データの消去が必要な場合は、一度にすべて戻さず段階的に復元する

サブスクリプションURL、ローカルルール、必要な設定をバックアップ済みで、再取得できることを確認します。
「ストレージを消去」を実行するか、アプリをアンインストールして再インストールします。Androidでは通常、アンインストールするとローカルのアプリデータも削除されます。
初回起動後は、古いバックアップをすぐに復元せず、何も設定していない状態で画面が安定するか確認します。
設定を1つだけインポートして起動テストを行います。成功したら、オーバーライドや他のサブスクリプションを戻します。

古いバックアップをすべて復元した途端に同じ問題が再発する場合は、原因となる条件も一緒に戻った可能性が高いと考えられます。バックアップ内の設定、リソース参照、アプリの設定を確認し、インストール失敗だけを原因と決めつけないでください。

手順5：VPN権限、TUN、バックグラウンド制限を確認する

Android端末では通常、システムのVPNサービスを使って端末の通信を処理します。この方法を使うのに、一般的にはroot権限は不要です。ただし、クライアントのTUN設定はデスクトップ版と完全には同じではありません。デスクトップの仮想NIC名、ルーティングパラメーター、権限修正コマンドをそのまま流用しないでください。

接続直後に失敗する場合は、VPNセッションの競合を確認する

Androidでは一般に「設定」→「ネットワークとインターネット」→「VPN」の順に確認できます。他のアプリで「常時接続VPN」が有効になっていないか、「VPNを使用しない接続をブロック」が今回のテストに影響していないか確認してください。OSによっては、「接続と共有」などのメニュー内にあります。変更前に元の設定を記録し、確認後は必要なセキュリティ設定に戻してください。

再認証する場合は、対象のクライアントからシステムのVPN接続要求を出し、システムの確認画面に表示されるアプリ名を確認してください。仕事用プロファイル、デバイス管理ポリシー、組織で管理されている端末では、VPNの使用が制限されていることがあります。この場合は端末の管理者に相談してください。クライアントの再インストールだけでは解決しないことがほとんどです。

画面消灯後の切断は、起動時のクラッシュとは別の問題

アプリを前面で使用しているときは正常で、画面消灯後にだけ切断される場合は、「設定」→「アプリ」→対象のクライアント→「バッテリー」でバックグラウンド実行の設定を確認してください。メーカーによっては、自動起動やバックグラウンド保護の設定もあります。制限を緩めるとバッテリー消費が増える可能性があるため、バックグラウンドで終了されていることを確認してから必要に応じて調整してください。

ログにノードへの接続タイムアウトやDNSクエリの失敗だけが記録され、画面とサービスが動作し続けている場合は、ネットワークやDNSの問題として調べてください。DNSサーバーを変更してもYAMLの解析エラーは直りません。ノードを変更しても、アプリのネイティブライブラリのクラッシュは解決しません。

iOSで起動直後に終了する場合：アプリ本体とネットワーク拡張を分けて確認

iOSクライアントは通常、Network Extensionを使ってVPNトンネルを確立します。インストール方法はAndroidのAPKとは異なり、すべてのiOSクライアントがmihomoの設定を完全にサポートするとも限りません。画面は開くものの接続直後に停止する場合は、クライアントの接続ログを確認してください。アイコンをタップした直後に終了する場合は、アプリ本体、OSとの互換性、インストール元の状態を優先して確認します。

まず端末を再起動し、元の配布元で利用できるアップデートを確認します。TestFlightからインストールした場合は、テストビルドの有効期限も確認してください。
「設定」→「一般」→「VPNとデバイス管理」で登録済みのVPNを確認します。勤務先や学校が管理するプロファイルは、むやみに削除しないでください。
「設定」→「プライバシーとセキュリティ」→「解析と改善」→「解析データ」を開き、問題が発生した時刻に対応するアプリや拡張機能の記録を探します。記録があるかどうかは、OSや診断設定によって異なります。

解析データのJetsamEventは、メモリ不足時のプロセス終了に関係する可能性がありますが、コードのクラッシュが確認されたことを意味するわけではありません。大きなルールセットを読み込んだときだけ終了する場合は、ルールプロバイダーの数を減らして比較テストし、ログをクライアントの開発者に共有して判断を仰いでください。

iOSの「Appを取り除く」では通常、書類とデータが保持されますが、「Appを削除」するとローカルデータも削除されます。両者は用途が異なります。前者では問題の状態が残る可能性があり、後者では事前に設定をエクスポートする必要があります。復元手段がないままアプリを削除しないでください。

解決しない場合：再現手順を添えて報告し、サブスクリプションの認証情報は公開しない

問題を報告する際は、「起動直後は設定画面を開けるが、特定の設定を選んで接続をタップすると、毎回同じ手順で画面が終了する」のように、発生条件を一文で説明してください。OS、アプリ、コアの各バージョン、最後に正常動作した時刻、最小構成で起動できるかどうかも添えます。開発者が必要としているのは再現条件であり、デスクトップのスクリーンショットだけでは不十分です。

Androidの場合：ADBでクラッシュログを取得する

PCでのデバッグに慣れている場合は、信頼できる自分のPCにAndroid SDK Platform-Toolsをインストールし、USBデバッグを有効にして許可したうえで、以下のコマンドを実行できます。まず一度クラッシュを再現してからログを保存し、作業後はUSBデバッグを無効にしてください。ADBの操作に慣れていない場合は、アプリ内のログ出力機能を利用してください。

adb devices
adb logcat -b crash -d > clash-crash.txt

クラッシュバッファーには、独立したプロキシコアのエラーがすべて含まれるとは限りません。クライアントの起動ログも保存してください。共有する前に、サブスクリプションURL、トークン、ノードのパスワード、サーバーアドレス、個人用のパスを削除し、エラーの前後だけを残します。設定全体を公開の掲示板に貼り付けないでください。