Clashクライアントのクラッシュ・起動時強制終了対処法:ログから読み解く修正チェックリスト
クライアントが開いた瞬間に落ちる場合の切り分け手順を解説。起動ログでエラー種別を特定し、設定ファイルの構文エラー、ポート競合、キャッシュディレクトリの破損、ランタイム不足を順に確認。各OSのログファイルの場所も掲載。
Clashクライアントを開いた瞬間に落ちてしまう現象は、トラブル対処の中でも特に手がかりがつかみにくいタイプです。エラーダイアログも表示されず、画面が表示される時間もほぼゼロで、スクリーンショットを撮る余裕さえありません。しかし、この種の不具合はほとんどの場合ランダムに発生しているわけではなく、原因は主に4つに絞られます。設定ファイルの構文エラー、ポートが使用中でプロセスが即終了、キャッシュ・データディレクトリの破損、システムに必要なランタイムが不足している場合です。本記事では「まずログを確認し、原因に応じて対処する」という順序で、それぞれの特定方法と修正手順を丁寧に解説し、各OSのログファイルの具体的な場所も紹介します。
再インストールの前に、まず起動ログを確認する
強制終了が起きたときの最初の反応はアンインストール&再インストールになりがちですが、原因が設定ファイルやシステム環境にある場合、再インストールしても同じ現象が再発します。正しい最初のステップは、クラッシュ発生直前に書き込まれた最後のログを確認することです。Clash系クライアントの大半(Clash Premiumコアでも Clash Meta / mihomo コアでも)は、クラッシュ前にエラースタックやエラーメッセージをローカルのログファイルに書き込みますが、このログは自動的にポップアップ表示されるわけではありません。
ログファイルを開いたら、注目すべきポイントは2つです。1つはファイル末尾の数行で、ここに大抵プロセス終了の直接的な原因が記録されています。もう1つは同じエラーが繰り返し出現していないかどうかです。同じエラーが上書き・追記の形で繰り返されている場合、クライアントが「起動→クラッシュ→再試行」のループに陥っていることを意味し、問題の性質がほぼ特定できます。
ログファイルが空、またはそもそも生成されていない場合、クライアントがコアプロセスの起動すらできていない可能性が高く、まずランタイム不足かインストールパッケージ自体の破損を疑うべきで、設定ファイルの問題ではありません。
よくあるエラー4パターンと対処法
1. 設定ファイルの構文エラー
Clashの設定ファイルはYAML形式で、インデントとコロン後のスペースに非常に敏感です。ログに yaml: line X: mapping values are not allowed in this context、cannot unmarshal といった文字列が出ている場合、設定ファイルの解析失敗が確定的です。よくある原因は以下の通りです。
- スペースの代わりにTabキーでインデントしている(YAML仕様ではTabインデントは許可されていません)。
- 同じ階層のインデントのスペース数が揃っていない。例えば
proxies:の直下では2スペース、その次の行では4スペースになっているなど。 - ルールやプロキシグループに全角の引用符や全角コロンが混入している。目視では気づきにくいですが、パーサーは即座にエラーを返します。
- サブスクリプション変換後の設定を手動編集した際、リスト記号
-の追加漏れや余分な記述がある。
対処の考え方としては、まず設定ファイルを任意のオンラインYAML検証ツールか、テキストエディタのYAML構文ハイライト機能に貼り付けてエラー行を特定し、その行の構造をクライアント公式の設定サンプルと1文字ずつ照合します。設定がサブスクリプション変換サービス経由で生成されたものであれば、元のプロバイダー(機場)側の管理画面でサブスクリプションURLを再生成し、更新をやり直すほうが、エラーの出た設定ファイルを手動で修繕するより確実です。
2. ポートが使用中で、起動直後にプロセスが終了する
Clashコアの起動時には、HTTP/SOCKS混合ポート(デフォルトは多くの場合7890)とコントロールパネル用ポート(一般的に9090)をバインドする必要があります。これらのポートが既に他のプログラムに使われている場合、コアはバインド段階でエラーを出してそのまま終了します。ログには通常 bind: address already in use や listen tcp :7890: bind: permission denied といった記述が見られます。GUIクライアントの場合、「一瞬表示されてすぐ消える」という挙動になりがちで、これはコアプロセスの終了を検知したGUIプロセス側も連動して終了するためです。
確認方法としては、コマンドラインでポートを占有しているプロセスを調べます。Windowsでは netstat -ano | findstr 7890 でPIDを特定し、タスクマネージャーから終了させます。macOS/Linuxでは lsof -i :7890 でプロセス名を直接確認できます。競合するプロセスを特定したら、そのプロセスを終了させるか、クライアント設定で混合ポートを空いているポートに変更します(変更後はシステムのプロキシ設定に登録しているポート番号も忘れず同期させてください。そうしないと接続できなくなります)。
3. キャッシュ・データディレクトリの破損
クライアントが強制終了された場合(システムのスリープ中断や突然の電源断など)、データディレクトリ内のキャッシュファイル、GeoIPデータベース、ルールキャッシュが不完全な状態で書き込まれることがあります。次回起動時にこの破損したファイルを読み込もうとしてクラッシュするケースです。この種の問題はログ上で、設定解析の段階ではなくキャッシュやデータベースの読み込み段階でエラーが発生している点が特徴で、よく見られるキーワードは database is locked、unexpected EOF、invalid cache などです。
対処法は、まずクライアントを完全に終了させ(バックグラウンドに残っているトレイプロセスも含めて)、データディレクトリ内のキャッシュ用サブディレクトリ(通常 cache、*.db、Cache といった名前)を手動で削除し、次回起動時に再生成させることです。キャッシュを削除しても設定ファイルやサブスクリプションURLには影響しないため比較的安全な操作で、再起動後にGeoIPやGeoSiteなどのルールデータベースが再ダウンロードされます。
4. システムランタイムの不足
一部のプラットフォームのクライアントは、起動にシステムへ事前インストールされたランタイムを必要とします。代表例はWindowsのMicrosoft Visual C++ランタイムや、Linuxディストリビューションによっては不足しているGUI依存パッケージ(GTK、WebKitGTKなど)です。この種の問題は「ウィンドウが一切表示されない」ことが特徴で、プロセス一覧にも出てこない場合があり、動的リンクの最も早い段階で失敗するためログディレクトリ自体が作成されていないこともあります。
Windowsユーザーは「プログラムと機能」で対応バージョンのVC++ランタイムがインストールされているか確認し、不足していれば公式サイトから最新版を導入してください。Linuxユーザーは端末(ターミナル)からクライアントの実行ファイルを直接起動してみることで、不足している共有ライブラリ名(error while loading shared libraries: libwebkit2gtk... のような形式)が表示されるため、システムのパッケージマネージャーで該当パッケージをインストールしてください。
各OSのログファイルの場所
ログファイルが見つからず調査が滞るのはよくあるパターンです。以下の表は主要OSにおけるクライアントのログ・データディレクトリの典型的な場所をまとめたものです(クライアントによっては設定内に「ログフォルダを開く」というショートカットが用意されている場合もあるので、そちらを優先的に使うのが最も手間がかかりません)。
| OS | 典型的なログ/データディレクトリ | 確認方法 |
|---|---|---|
| Windows | %APPDATA%\<クライアント名>\logs | アドレスバーに %APPDATA% を貼り付けて移動し、更新日時でソートして最新のファイルを探す |
| macOS | ~/Library/Logs/<クライアント名> | Finderの「フォルダへ移動」でパスを貼り付ける、または「コンソール」Appでクライアントのプロセス名を検索する |
| Linux | ~/.config/<クライアント名>/logs | 端末から実行ファイルを直接実行すると、エラーがリアルタイムで端末に表示されるため、ファイルを探すより早い |
| Android | クライアント内の「ログ」または「実行ログ」メニュー | 多くのAndroidクライアントはアプリ内画面にログを表示するため、rootやファイルマネージャーは不要 |
| iOS | クライアント内の「診断」または「ログ」ページ | iOSはサンドボックスの制約でエクスポートできないため、クラッシュ時はまずクライアント内蔵の診断記録を確認する |
クライアントによって製品名やディレクトリ名の表記に多少の違いがあります。上表のパスで見つからない場合は、システムのファイル検索でクライアントの実行ファイル名に .log を付けて検索すると、多くの場合特定できます。
標準的な切り分け手順チェックリスト
上記の原因を実行可能な確認フローとしてまとめました。強制終了が発生したら順番に沿って確認していくことで、大抵は数分以内に原因を特定できます。
- クライアントを完全に終了させ(システムトレイ・メニューバーに残っているプロセスがないか確認)、再度開いてクラッシュが発生した時点を記録する。
- 上表の場所からログファイルを見つけ、最後に書き込まれたエラー内容を確認し、設定解析・ポートバインド・キャッシュ読み込み・ランタイム読み込みのいずれに該当するか判断する。
- 設定の問題であれば、一時的に正常に動作していた旧設定ファイルに切り替えて起動できるか確認する。起動できれば新しい設定に問題があることが分かる。
- ポート競合であれば、
netstat/lsofで占有プロセスを調べ、プロセスを終了するかポートを変更し、変更後はシステムのプロキシ設定も同期して更新する。 - キャッシュ破損であれば、クライアントを終了させてからキャッシュ用サブディレクトリを手動で削除し、再起動して再生成させる。
- ランタイム不足であれば、端末から実行ファイルを直接実行してエラー内容を確認し、指示に従って不足している依存ライブラリを導入する。
- 上記すべてを確認しても改善しない場合は、クライアントをアンインストールし、データディレクトリも合わせて削除(プログラム本体の削除だけでは不十分)してから、インストールパッケージを再ダウンロードして導入し、パッケージ自体や残存設定の破損の可能性を排除する。
強制終了の再発を防ぐための習慣
一度強制終了に対処したあとは、いくつかの習慣を身につけることで再発率を大きく下げられます。設定ファイルを編集する前には正常に動作していた旧バージョンを必ずバックアップしておきましょう。別名で保存するだけでも問題発生時に即座に戻せます。システム更新後や強制シャットダウン直後にすぐクライアントで重要な操作を行わず、まず正常に起動するか確認してください。ルールキャッシュとログファイルは定期的に整理し、データディレクトリの肥大化による起動の遅延を防ぎましょう。特定のサブスクリプション変換サービスを長期的に利用している場合は、できるだけ同じテンプレート・パラメータを使い続け、フィールド構造の頻繁な変更による互換性リスクを減らすことをおすすめします。
強制終了問題の核心は「まず現象を確認し、次に原因を特定し、最後に対処する」という順序にあります。むやみな再インストールやシステムプロキシのリセットは根本的な解決にならないばかりか、本来特定できたはずのログの手がかりを消してしまうことにもなります。まずログを確認する習慣を身につければ、起動時の不具合の多くは設定ファイル・ポート・キャッシュ・ランタイムという4つの方向のいずれかで答えが見つかります。
Clashクライアントをダウンロード
現在使用しているクライアントで原因不明の起動トラブルが繰り返し発生する場合は、ダウンロードページから公式配布元の最新インストールパッケージを取得するか、チュートリアルに沿って標準的な設定手順をもう一度やり直してみてください。