Clashが起動直後に落ちるときの対処法｜ログ確認・設定の復元・再インストール

1. まず、ウィンドウが閉じるのか、プロキシコアが停止するのかを確認

ウィンドウが消えても、必ずしもアプリがクラッシュしたとは限りません。Clash系クライアントは通常、ボタンや設定一覧を表示するGUIと、実際に接続を受け付けてルールを適用するプロキシコアで構成されています。mihomoは一部のクライアントで使われるプロキシコアで、Clash Metaとも呼ばれます。両者は別々に問題が起きるため、まずどちらに問題があるのか切り分けましょう。

1. システムトレイにクライアントのアイコンが残っているか確認します。Windowsでは、タスクバーの隠れているアイコン内にある場合があります。アイコンが残っていれば、トレイからメインウィンドウを開き直し、「起動時に最小化」が有効になっていないか確認してください。
2. Ctrl + Shift + Escを押してタスクマネージャーを開き、「詳細」タブでクライアントとコアのプロセスを確認します。アイコンだけで判断せず、プロセス名を記録してください。
3. ウィンドウは開くもののコアが実行されていない場合は、まずコアのログを確認します。GUIのプロセスもすぐに終了する場合は、クライアントのログとシステムのクラッシュ記録を確認してください。
4. ほかのプロキシクライアントを終了してから、問題のクライアントをもう一度起動します。複数のアプリを同時に起動すると、ローカルポートや仮想ネットワークアダプターが競合することがあります。

2. ログを確認する：起動前後の最初のエラーを記録

ログの保存場所はクライアントによって異なり、「Clash」という総称だけでは特定できません。インストール先、ユーザーデータの保存先、コアの作業ディレクトリがそれぞれ別の場合があります。ネット上で見つけたフォルダーのパスをそのまま使い、自分のログも必ずそこにあると思い込まないでください。

ウィンドウが数秒間表示される場合

まずクライアントの設定にある「ログフォルダーを開く」または「設定フォルダーを開く」を使います。項目名や場所はクライアントごとに異なります。フォルダーを開いたらログ一式をコピーし、たとえば09:42:10のように起動時刻を記録してください。その後、もう一度起動し、その時刻以降に追加されたログを確認します。以前のエラーを何度も読み返すのではなく、新しい記録を見てください。

ウィンドウがまったく開かない場合

• 旧版のClash for Windows：データの保存先として、%USERPROFILE%\.config\clashがよく使われます。フォルダー内にlogsがあるか確認してください。ポータブルモードを使っている場合や、フォルダーを移動した場合は、実際のファイル更新日時を手がかりにします。ほかのクライアントにこのパスを流用しないでください。
• そのほかのWindowsクライアント：エクスプローラーのアドレスバーに%APPDATA%と%LOCALAPPDATA%をそれぞれ入力し、クライアント名やプロジェクト識別子でフォルダーを探します。確認とバックアップにとどめ、今は削除しないでください。
• Windowsのシステム記録：Win + Rを押してeventvwr.mscと入力し、「Windowsログ」→「アプリケーション」を開いて、起動時刻のエラーを探します。perfmon /relを実行し、信頼性モニターでアプリの障害を確認する方法もあります。
• macOS：「コンソール」を開いてクラッシュレポートを確認します。ユーザー単位のレポートは、通常~/Library/Logs/DiagnosticReportsに保存されています。コアだけが終了する場合も、まずクライアント独自のコアログを探してください。
• Linux：実際のクライアント実行ファイルをターミナルから起動し、出力を保存します。systemdのユーザーサービスを使っている場合は、該当するサービスのログも確認してください。すべてのディストリビューションで同じサービス名が使われるとは限りません。

ログではまず起動を中断させた最初のエラーを確認し、その前後20行も読みます。末尾にある「接続が拒否されました」は、コアがすでに終了した結果かもしれません。障害モジュールにGUIランタイムが表示されても、それだけでグラフィックドライバーが原因とは断定できません。クライアントのログと照らし合わせてください。

3. ポート競合：7890と9090を使っているプロセスを調べる

ポートの競合は通常、コアの起動に影響しますが、GUI全体がクラッシュするとは限りません。7890はローカルプロキシ、9090はコントロールAPIのポートとしてよく使われますが、どちらも変更可能です。ログと現在の設定を確認してください。エラーに7897と表示されている場合は、7897を調べます。

Windows PowerShellで次のコマンドを実行し、例として指定したポートをTCPで待ち受けているプロセスを確認します。何も表示されない場合、確認した時点で該当ポートを待ち受けていないことを示すだけで、直前にプロセスが終了した可能性までは否定できません。

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

出力されたプロセスIDが4321だと仮定し、次にプロセスの情報を調べます。4321は説明用の値です。実行時には、実際に確認したIDに置き換えてください。

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path

1. 別のプロキシアプリがポートを使っている場合は、そのアプリのトレイメニューから通常の手順で終了してください。正体の分からないシステムプロセスを強制終了しないでください。
2. 同じクライアントのコアが残ってポートを使っている場合は、クライアントとバックグラウンドサービスを終了します。そのコアを使用中の接続がないことを確認してから、残ったプロセスに対処してください。
3. 2つのアプリを併用する必要がある場合は、片方のプロキシポートを未使用の7893に、コントロールポートを未使用の9093に変更できます。アプリに手動で登録したプロキシアドレスも更新してください。設定ファイルだけ変更して、古いポートをそのまま使わないようにします。

待ち受けプロセスが見つからないのにWindowsでポートへのアクセスが拒否される場合は、netsh interface ipv4 show excludedportrange protocol=tcpを実行して、TCPの除外ポート範囲を確認できます。システムの予約範囲を直接削除せず、その範囲外にある空きポートを選んでください。UDPのバインドエラーはUDPのエンドポイントを別途確認し、TCPの検索結果だけで判断しないでください。

4. 設定を復元する：まずYAMLをテストし、クライアント側の結合設定も確認

設定の復元では、項目を手当たり次第に削除せず、正常に動作する設定全体に戻します。YAMLはインデントで階層を表すテキスト形式です。タブの混入、数値の型の誤り、存在しないプロキシグループの参照などにより、設定を読み込めなくなることがあります。サブスクリプションを正常にダウンロードできても、その内容が現在のコアで使えるとは限りません。

直近の変更から原因を絞り込む

• 設定を手動で編集した直後：問題のファイルをコピーして保管し、編集前のバックアップに戻します。
• サブスクリプションを更新した直後：更新後のファイルを保存します。クライアントに過去のスナップショットがあれば、起動できていた時点のものに戻してください。サブスクリプションの内容がサーバー側で変わる場合もあります。
• コアを変更した直後：設定に、新しいコアでのみサポートされる項目やプロトコルがないか確認します。従来のClashとmihomoでは対応範囲が異なるため、どちらもYAMLだから互換性があるとは限りません。
• オーバーライドやスクリプトを有効にした直後：オーバーライドは、元の設定に項目を追加または置き換えるクライアントの処理です。追加した結合設定を一時的に無効にし、元の設定をテストしてください。

現在のコアで設定をテストする

mihomoの-tは設定をテストして終了するオプション、-fは設定ファイル、-dは作業ディレクトリを指定するオプションです。以下では現在のクライアントに付属するコアとテスト対象の設定をD:\ClashRecoveryに置き、ファイル名をそれぞれmihomo.exeとcandidate.yamlとします。実際のパスが異なる場合は適宜変更してください。

Set-Location 'D:\ClashRecovery'
.\mihomo.exe -t -d 'D:\ClashRecovery' -f 'D:\ClashRecovery\candidate.yaml'

作業ディレクトリには、地理データやルールなどのリソースも必要な場合があります。リソース不足のエラーが出たら、現在の設定に合ったリソースを先に用意してください。インデントの誤りと決めつけてはいけません。テストに合格しても、そのコアが設定を読み込めることを示すだけです。ノードへの接続やリモートルールのダウンロード、GUIの正常動作までは保証されません。

5. コア不足、アーキテクチャの不一致、実行環境のエラー

プログラムファイルを修復するのは、ログがファイルまたは読み込みの失敗を明確に示している場合に限ります。「コアが実行されていません」という表示は設定エラーが原因のこともあり、コアファイルが消えたとは限りません。まずエラーに記載された完全なパスを確認し、ファイルの有無や移動の有無、現在のユーザーに読み取り・実行権限があるかを調べてください。

インストーラーとデバイスのアーキテクチャを確認する

Windowsでは「設定」→「システム」→「バージョン情報」でシステムの種類を確認できます。Linuxではuname -mを実行します。デバイスとクライアントの対応状況に合わせて、x64またはARM64のインストーラーを選んでください。別のクライアントのコアを名前だけ変更して上書きしないでください。起動オプションやコントロールAPI、付属リソースが異なる場合があります。

セキュリティの記録と依存関係のエラーを確認する

• Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、該当ファイルが隔離されていないか確認します。ファイルの入手元と検出内容を確かめてください。起動させるために保護機能を一律に無効化しないでください。
• ログにWebView2などのランタイム不足が明記されている場合は、クライアントのシステム要件に従って該当する依存関係を修復します。すべてのClashクライアントがWebView2を使うわけではないため、ランタイムを片っ端からインストールする必要はありません。
• macOSでアプリを開けないと表示された場合は、まず現在のOSバージョンに対応したアプリか確認し、「システム設定」→「プライバシーとセキュリティ」に表示される説明を確認してください。システムのセキュリティ機能を無効にするコマンドを、そのまま実行しないでください。
• Linuxで実行権限のエラーが発生した場合は、まずls -lで対象ファイルの権限を確認します。ファイルの入手元とパスを確認してから、プロジェクトのインストール手順に沿って権限を変更してください。

通常モードでは起動でき、TUNを有効にしたときだけ失敗する場合は、仮想ネットワークアダプター、サービスのインストール状態、権限を確認してください。切り分けのため一時的にTUNを無効にし、「常に管理者として実行」をあらゆるクラッシュに効く対処法として使わないでください。

6. 安全に再インストールする：アプリ本体とユーザーデータを分けて確認

再インストール前にデータを保護し、再インストール後は一度にすべて戻さないでください。アプリのファイルだけを上書きしても、原因となったユーザー設定が残ることがあります。一方で、データフォルダー全体を削除すると、ローカルルールやサブスクリプションの記録を失うおそれがあります。バックアップを取り、旧データを隔離してから、項目ごとに戻すのが安全です。

1. 現在の状態を記録：クライアント名とバージョン、コアのバージョン、OSのバージョン、最後に正常起動した時刻、直前に行った更新や設定変更を記録します。
2. データをバックアップ：アプリと関連サービスを完全に終了してから、設定、サブスクリプションの記録、ローカルルール、オーバーライドスクリプト、ログをコピーします。認証情報を含むバックアップは、保護されたローカルフォルダーに保存してください。
3. 古いフォルダーを隔離：実際のユーザーデータフォルダーを確認し、元の名前の末尾に-backup-20261015のような日付付きの名前を付けて変更します。使用中で変更できない場合は、まずバックグラウンドプロセスを終了してください。無理に削除しないでください。
4. 再インストール：クライアントのドキュメントに従ってアプリをアンインストールします。サービスモードを使っている場合は、プロジェクトの手順に沿って該当サービスも削除してください。デバイスのアーキテクチャに合った安定版をインストールし、別プロジェクトのファイルを混在させないでください。
5. まず初期状態で起動：新しいデータフォルダーを使っていることを確認し、古いサブスクリプション、スクリプト、TUNの設定を戻さずにウィンドウを開きます。設定が選択されていないとコアを起動しないクライアントもあります。これはGUIのクラッシュとは別の状態です。
6. 項目ごとに復元：まず動作確認済みの設定を1つ読み込み、起動してログを確認します。その後、ローカルルール、オーバーライド、システムプロキシ、TUNを戻します。原因を特定しやすくするため、変更は一度に1項目ずつ行ってください。

初期状態でもクラッシュする場合は、OSとの互換性、ランタイム、インストールの完全性、クライアント自体の不具合を中心に調べます。初期状態では正常で、古いデータを戻すと再発する場合は、新しいフォルダーをそのまま使い、古いデータを分けて復元してください。バックアップ全体を一括で上書きしないでください。

7. 修復後の確認と問い合わせに必要な情報

ウィンドウが表示されても、まだ確認は終わりではありません。設定と接続が復旧したか確認しましょう。クライアントを2分間起動したままにし、コアが再起動を繰り返していないか確認します。選択中の設定、プロキシモード、プロキシグループも確認してください。ルールモードではルールに応じて接続方法が選ばれるため、特定のサイトが直接接続されてもプロキシの故障とは限りません。

• 実際に待ち受けているポートと、アプリに設定したプロキシポートが一致しているか確認します。特に、調査中に7890を変更した場合は注意してください。
• 接続一覧を開き、ルールが明確に一致するテスト用ドメインにアクセスして、適用されたルールとプロキシグループを確認します。遅延の数値だけで判断しないでください。
• TUNが必要な場合は最後に有効にし、DNSの名前解決、通常のWebページ、普段使うアプリを確認します。問題が起きたら、直前に確認済みの状態に戻してください。
• クライアントを終了してから通常の手順で再起動し、設定の選択とポート設定が保持されること、同じ起動エラーがログに再発しないことを確認します。

調査の流れはシンプルに保てます。まず終了した対象を確認してログを読み、ポートのエラーならポートを、設定のエラーなら設定を、ファイルのエラーならインストールを確認します。各手順で元に戻せるバックアップを残すことで、何度も再インストールするより原因を特定しやすくなります。