Clash クライアント起動クラッシュ対処:設定ファイルの構文・ポート競合・残留プロセスのクリーンアップ

「起動しない」と「クラッシュする」は分けて考える

ユーザーから不具合報告が来ると、この2つの現象が混同されがちですが、実際には切り分け方が異なります。「起動しない」は通常、アイコンをクリックしても全く反応がなく、プロセス一覧にも対応する実行ファイルが見当たらない状態を指し、この場合はシステム権限・ランタイム不足・インストールパッケージ自体の破損が原因であることが多いです。一方「起動直後に落ちる」はプロセス自体は立ち上がっており、ウィンドウが一瞬表示された後、あるいは表示すらされずに自動的に消えるケースで、多くは設定ファイルの解析失敗・コアのポート競合・ローカルのコア残留プロセスによるリソース占有が原因です。この2つの現象を区別することが原因特定の第一歩です——闇雲な再インストールでは根本原因を解決できないことが多く、特にポート競合や残留プロセスが原因の場合、何度再インストールしても同じ問題が再発します。

また、Clash 系クライアント(Clash Meta(mihomo) コアをベースにした実装も含む)はアーキテクチャ上、上層のグラフィカルインターフェース(GUI)と、実際に通信を処理する下層のコアプロセスの2層に分かれています。GUI がクラッシュしてもコアが異常とは限らず、逆にコアがクラッシュしても GUI がフリーズして無反応になるだけの場合もあります。原因を切り分ける際は、まずどちらの層で問題が起きているかを確認した上で対処するのが効率的です。

ステップ1:ログを確認する。当てずっぽうは禁物

Clash 系クライアントの多くはローカルに実行ログを残しており、ログ内のエラー情報は何度再起動するより問題解明の助けになります。よくあるログの保存先は以下の通りです。

• Windows:クライアントのインストールディレクトリ内の logs フォルダ、またはユーザーディレクトリ %APPDATA% 内の対応するクライアントのサブディレクトリ。
• macOS:~/Library/Logs/ 内の対応するクライアント名のフォルダ、またはアプリ内の「ログディレクトリを開く」機能。
• Linux:systemd サービスとして動作している場合は journalctl で確認可能。単体実行ファイルとして動かしている場合は通常、ログが端末の標準出力に出力されます。

クライアントに「ターミナルから起動」のようなデバッグオプションがある場合は、まずこの方法で一度起動してみることをお勧めします——GUI がクラッシュするとエラー内容を確認する前に消えてしまいますが、ターミナルの出力はそのまま残るため、内容を一行ずつ確認できます。

原因1:設定ファイルの構文エラー

Clash の設定ファイルは YAML 形式で、インデントや特殊文字に非常に敏感です。設定ファイルを手動編集した場合や、サブスクリプション変換スクリプトが生成した内容が規格に沿っていない場合、コアが解析段階でそのまま終了してしまうことがあります。よくある構文問題は以下の通りです。

1. スペースとタブが混在している、または同階層の項目でインデント量が揃っていない。
2. 文字列内にエスケープされていないコロンやシャープが含まれ、パーサーが新しいキーバリューやコメントの開始と誤判定する。
3. ルールセット(rule-providers)やプロキシグループ(proxy-groups)で存在しない名前が参照されており、コアが検証段階でエラーを出して終了する。
4. 新しいバージョンのコアで廃止されたフィールド名が設定に残っており、フィールドの型が一致しない。

切り分け方法:まず任意のオンラインまたはローカルの YAML 検証ツールでインデントと基本構文が正しいか確認し、次にクライアントのドキュメントと照らし合わせて、フィールド名が現行コアバージョンで対応している書き方かを確認します。どの行でエラーが出ているか判断できない場合は、段落単位でコメントアウトしてみるのも有効です——まず最低限のポート・モード・DNS 項目だけを残して正常起動を確認し、その後プロキシノード・ルールセットを段階的に戻していき、エラーが再現した段落を特定します。

原因2:ポート競合

Clash コアの起動時には、HTTP/SOCKS プロキシポート・外部コントロールポート(通常 9090 付近)、TUN モード有効時に関わる仮想ネットワークアダプタなど、ローカルポートのバインドが必要です。これらのポートが他のプログラムに使用されていると、コアのバインドが失敗して終了し、GUI 側ではクラッシュ、またはコアへの接続失敗として表示されます。

よくある競合の原因:完全に終了していない別のプロキシツールが同時に動作している、前回のコア残留プロセスが古いポートを監視し続けている、あるいはローカルの開発ツール(ローカルデバッグサーバーなど)が偶然同じポート帯を使用している、などです。切り分け手順:

• Windows:コマンドラインで netstat -ano | findstr 7890 を実行し(ポート番号は設定ファイルで実際に設定した値に置き換えてください)、返ってきた PID を記録します。次にタスクマネージャーや tasklist /FI "PID eq 対応するPID" でどのプログラムかを確認します。
• macOS / Linux:lsof -i :7890 または sudo lsof -i :9090 を実行してポート占有元を確認します。プロセス名から、コアの残留か他のプロキシソフトかがすぐに分かることが多いです。

占有元を確認したら、そのプロセスを終了させるか、クライアントの設定でミックスポートや外部コントロールポートを空いている値に変更してください。同じマシンで複数のプロキシツールを切り替えて使う場合は、それぞれに異なるポート帯を割り当てておくと、切り替えるたびに手動で競合を調べる手間を省けます。

原因3:コア残留プロセス

クライアントの異常終了(強制終了、システムのスリープによる中断、更新処理中の中断など)により、コアの子プロセスが GUI の管理から外れ、孤立プロセスとしてバックグラウンドで動き続けることがあります。この残留プロセスは以前使用していたポートを占有し続けるため、次回クライアントを正常に起動しようとしても、新しく立ち上がったコアが同じポートへのバインドに失敗し、起動直後にすぐ終了するという現象になります。ログには「アドレスは既に使用されています」といった趣旨のメッセージが明記されているはずです。

クリーンアップ方法(プラットフォーム別):

• Windows:タスクマネージャーを開き、コアに対応するプロセス名(クライアントによって異なりますが、mihomo、clash などの文字列を含む実行ファイルが一般的)を探して手動終了し、その後クライアントを再起動します。
• macOS:アクティビティモニタで同様のプロセス名キーワードを検索する、またはコマンド pkill -f mihomo で一括終了します(実行前に、同名の他のプログラムを誤って終了させないか確認してください)。
• Linux:ps aux | grep mihomo で PID を特定し、kill -9 PID で終了します。クライアントが systemd で管理されているサービスの場合は、systemctl stop の後に systemctl start を使うほうが、サービスの状態と実際のプロセス状態の不一致を避けられます。

この種の残留プロセス問題が繰り返し発生する場合は、クライアントやシステムの更新中に関連プロセスが頻繁に強制終了されていないか確認してください。また、クライアントの設定に「終了時にコアプロセスをクリーンアップする」といった項目があれば、有効になっているか確認しておくとよいでしょう。

原因4:ランタイム不足

一部のクライアントの GUI は OS 標準またはサードパーティのランタイムフレームワーク上に構築されており、システムに対応するランタイムのバージョンがインストールされていない場合、アプリは起動段階でそのままクラッシュします。多くの場合、ログを書き込む処理に到達する前にプロセスが終了してしまうため、ログファイル自体が生成されないこともあります。

よくあるケース:

• Windows:Visual C++ ランタイムや WebView2 コンポーネントが不足している場合。特に古いシステムバージョンや、OS を再インストールした直後で常用ランタイムが入っていない環境で多発します。システムのコンポーネント管理から WebView2 がインストールされているか確認し、不足している場合は公式のランタイム配布パッケージをインストールしてください。
• Linux:ディストリビューション標準の動的ライブラリのバージョンが古い、または GTK、WebKitGTK などの GUI 関連依存パッケージが不足している場合。パッケージマネージャーで該当の依存関係をインストールすれば通常は解消します。
• macOS:OS のバージョンがクライアントの要求する最低バージョンに達しておらず、新しいアプリが古いシステムで未対応の API を使用している場合。この場合は OS をアップグレードするか、現在のシステムバージョンに対応したクライアントバージョンに切り替えるしかありません。

このケースに該当するかどうかを簡単に判断する方法:アイコンをダブルクリックする代わりに、ターミナルから直接クライアントの実行ファイルを実行してみてください。ターミナルには通常、不足している具体的な動的ライブラリやコンポーネント名が出力され、GUI の「クラッシュした」という表示よりはるかに多くの情報が得られます。

4分類のクイックチェック表

対処後の確認順序

問題が解決した後は、以前の複雑な設定をそのまま復元するのではなく、以下の順序で確認することをお勧めします。

1. まず最も単純なデフォルト設定でクライアントを起動し、コアが正常に立ち上がり、外部コントロールポートに正常にアクセスできることを確認する。
2. 段階的に元のサブスクリプション設定に戻し、ノードリストが正常に解析・更新されるか確認する。
3. システムプロキシや TUN モードを有効化する前に、まずプロキシモード単体でネットワーク接続が正常であることを確認し、その後段階的に高度な機能を有効化していく。これにより、再度問題が発生した際にどの層が原因かを特定しやすくなる。
4. 以前ポート競合が原因だった場合は、システムプロキシ設定に入力されているポート番号が、現在クライアントが使用しているポートと一致しているか併せて確認してください。ポート変更後にシステムプロキシ設定が更新されていないケースはよくあります。