Clash クライアントが起動直後にクラッシュする原因と対処法

設定を削除したり、何度も再インストールしたりするのはまだ早いです。Clashを起動するとすぐ終了する場合、まず画面のプロセスがクラッシュしたのか、プロキシコアの起動に失敗したのかを切り分けましょう。前者は実行環境や画面キャッシュ、インストーラーに関係することが多く、後者はYAML、待ち受けポート、コアファイル、権限を優先して確認します。Webページが開けないのはあくまで結果であり、それだけでクライアントがクラッシュしたとは限りません。

1. 終了したのはウィンドウ、画面プロセス、それともコアか確認する

クライアントによっては、閉じるボタンを押しても終了せず、タスクトレイに最小化されます。ウィンドウが消えただけでは、プロセスが終了したとは限りません。Windowsではタスクバー右側の隠れているインジケーターを開き、Ctrl + Shift + Escでタスクマネージャーを起動します。macOSではメニューバーのアイコンと「アクティビティモニタ」、Androidでは通知欄にVPNの常駐通知が残っているかを確認してください。

WindowsではWin + Rを押し、eventvwr.mscを入力して、「Windowsログ」→「Application」を開き、障害発生時刻のアプリケーションエラーを確認します。perfmon /relを実行して信頼性モニターを開く方法もあります。障害が発生したアプリ、障害モジュール、例外コードを記録してください。これらは原因を絞り込む手掛かりです。システムDLLの名前が表示されても、削除や置き換えが必要とは限りません。

2. ログを保存してから、最小構成でYAMLの問題を切り分ける

ログと設定ファイルの場所を確認する

画面を開ける場合は、まず「ログ」ページを確認し、「設定」から「設定フォルダーを開く」「ログフォルダーを開く」などの項目を探してください。クライアントによって名称や保存先は異なるため、特定製品のフォルダーをすべてのClashクライアントに当てはめることはできません。画面を開けない場合は、インストール方法とクライアントのドキュメントを参考にユーザーデータの保存先を探します。ポータブル版ではプログラムのフォルダー、インストール版では通常ユーザーデータの保存先にデータが置かれます。

yaml、unmarshal、parse、permission denied、address already in useなどのエラーを検索します。起動時に最初に出た有効なエラーを確認してください。後から表示される「コアに接続できない」は、別のエラーに伴って発生しているだけの場合がよくあります。

設定のチェックと接続テストは別

mihomoコアを使用している場合は、コアがあるフォルダーで次のPowerShellコマンドを実行できます。対象のフォルダーにmihomo.exeと確認したいconfig.yamlが実際に存在することが前提です。クライアントに同梱されたコアはファイル名が異なることがあるため、実際のファイル名を使ってください。

.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-vは実際のコアのバージョン確認、-tは設定ファイルのチェックに使います。チェックに成功しても、ノードに接続できるとは限らず、通常起動時にポートを利用できるとも限りません。外部ルールセット、サブスクリプションプロバイダー、Geoデータを含む設定では、データフォルダーやリソースファイルが必要になる場合もあります。クライアントを介さずに単独でチェックする際は、パスの違いに注意してください。

よくある構文エラーには、インデントにTabを使う、コロンの後にスペースがない、リストの階層がずれている、サブスクリプションの応答として返されたログインページやエラーページをYAMLとして読み込ませている、などがあります。エラーに表示された行番号は手掛かりです。実際の原因が直前の行にあることもあります。パスワードやURLパラメーターに#などの特殊文字が含まれる場合は、コメントや別のYAML構文として解釈されないよう、引用符で囲むことをおすすめします。

サブスクリプションを上書きせず、診断用ファイルで確認する

次の内容を別ファイルdiagnostic.yamlとして保存し、設定チェックを実行してください。プロキシノードを含まないため、基本的な構文解析と起動環境の確認に使えます。普段使うサブスクリプションの代わりにはなりません。

mixed-port: 17890
allow-lan: false
mode: direct
log-level: debug
ipv6: false
tun:
  enable: false
dns:
  enable: false
rules:
  - MATCH,DIRECT

.\mihomo.exe -t -f .\diagnostic.yaml
.\mihomo.exe -f .\diagnostic.yaml

2つ目のコマンドを実行する前に、クライアントとバックグラウンドのコアを終了してください。複数のプロセスが動作していると、テストに影響します。コマンドはフォアグラウンドで実行されるため、停止するにはCtrl + Cを押します。最小構成では起動でき、元の設定では失敗する場合は、DNS、プロキシプロバイダー、ルールセット、TUNを一つずつ戻し、項目を追加するたびに確認してください。サブスクリプション、コア、DNSを同時に変更しないでください。どの変更が有効だったのか分からなくなります。

3. コアファイルの欠落、アーキテクチャの不一致、セキュリティソフトによるブロック

Clashクライアントはグラフィカルな操作画面です。ClashとClash Meta（mihomo）は、コアの異なる実装または派生系です。画面が表示されても、対応するコアが存在するとは限りません。また、新しいサブスクリプションを古いコアで読み込むと、未対応の項目やプロトコルが原因で失敗することがあります。実行ファイルを適当に置き換えて、すべてのクライアントを「アップグレード」しようとしないでください。

1. インストーラーが正しく展開されているか確認します。圧縮ファイルのプレビュー画面から直接プログラムを実行したり、リソースフォルダーを残して本体だけをコピーしたりしないでください。再インストールする前にユーザーデータをバックアップし、クライアントのリリース手順に従ってください。
2. OSのアーキテクチャを確認します。Windowsでは「設定」→「システム」→「バージョン情報」にあるシステムの種類、macOSでは「このMacについて」にあるチップ、Linuxではuname -mの結果を確認します。x64、ARM64、x86向けのインストーラーは相互に置き換えられません。
3. ブロック履歴を確認します。Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、コアファイルが隔離されていないか確認してください。配布元と対象ファイルを確認してから対応し、すべての保護機能を安易に無効化しないでください。
4. クライアントがサポートする方法でコアを更新します。クライアントとコアのバージョンを記録しておきます。入れ替えた後に問題が発生した場合は、ファイルをさらに混在させるのではなく、まず直前の変更を元に戻してください。

macOSの「開けません」「開発元を検証できません」という表示は、プロセスのクラッシュとは限りません。配布元が信頼でき、システム上許可されていることを確認したうえで、「システム設定」→「プライバシーとセキュリティ」に表示された内容を確認してください。組織管理下のデバイスでは、管理ポリシーに従ってください。LinuxでPermission deniedが表示される場合は、実行権限の不足、フォルダーへのアクセス不可、マウント先のnoexec制限を切り分けます。インストーラーを何度も実行するだけでは解決しません。

4. 権限不足とTUNサービスの問題

通常のHTTP/SOCKSプロキシは高番ポートで待ち受けるため、画面全体を常に管理者権限で実行する必要は通常ありません。一方、TUNは仮想ネットワークアダプターやルーティング、DNSの制御を伴うため、デスクトップクライアントによってはサービスモードや昇格用プログラムが必要です。TUNを有効にした場合だけエラーが出るなら、まずTUNを無効にし、通常のプロキシでテストして、サービスまたはネットワーク制御の問題に絞り込みます。

• Windows：クライアントの設定で「サービスモード」や「TUN」に関する状態を確認します。サービスがインストールされていない、または利用できないと表示された場合は、クライアントの手順に従ってサービスを修復してください。管理者として一度起動する方法は診断には使えますが、正規のサービスインストールの代わりにはなりません。
• macOS：クライアントが必要とする補助プログラムに許可が与えられているか確認します。アプリの更新後に権限を求められた場合は、許可の状態を改めて確認し、システムのネットワークコンポーネントを手動で削除しないでください。
• Linux：TUNを使うには通常、/dev/net/tunへのアクセスと適切なネットワーク管理権限が必要です。コンテナ環境ではデバイスの割り当てやケイパビリティの設定も関係するため、一般的なデスクトップ向けの手順が使えるとは限りません。
• Android：システムのVPN権限が拒否されると接続できませんが、アプリがクラッシュしたとは限りません。他のVPNアプリを切断してから再接続し、権限を許可してください。仕事用プロファイルやデバイス管理ポリシーによってVPNが制限される場合もあります。

5. ポート7890の競合は設定ファイルの構文エラーとは別

ログにbindやaddress already in useが表示される場合、設定の解析は成功していて、ポートの待ち受け時に失敗している可能性があります。Windowsでは次のコマンドで、7890を使用しているTCPの待ち受けプロセスを調べられます。待ち受けがなければ、1つ目のコマンドで対象が見つからないというメッセージが表示される場合があります。

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

netstat -ano | findstr :7890

2つ目のコマンドの出力にはリモートポートや別の状態が含まれることがあるため、ローカルアドレスの列と待ち受け状態の両方を確認してください。結果に表示されたPIDを使って、タスクマネージャーの「詳細」タブでプロセス名を確認します。macOSではlsof -nP -iTCP:7890 -sTCP:LISTEN、Linuxではss -ltnp 'sport = :7890'を実行できます。プロセスの情報を確認するために追加の権限が必要な場合があります。

以前使っていたクライアントのプロセスが残っている場合は、まず通常の終了操作で停止してください。必要な別のプログラムがポートを使用している場合は、空いていることを確認したうえでmixed-portを7891に変更し、システムプロキシとブラウザーの手動プロキシのポートも合わせます。単独のport、socks-port、external-controllerも競合することがあるため、7890だけを確認して終わりにしないでください。

クライアントによっては、起動時に実行用の設定を再生成します。ディスク上のファイルを変更しても再起動後に元の値へ戻る場合は、生成された一時ファイルを繰り返し編集するのではなく、クライアントのポート設定や上書き機能を使って変更してください。

6. 設定に問題がない場合は、ランタイムと画面キャッシュを確認する

エラーに応じて依存ランタイムを修復し、DLLを個別にダウンロードしない

WindowsでVCRUNTIME140.dllやMSVCP140.dllなどの不足が表示された場合は、クライアントの案内に従ってMicrosoft Visual C++ 2015–2022 Redistributableを修復し、アプリに合ったアーキテクチャを選んでください。64ビット版Windowsでも32ビットアプリを使うことがあり、必要なランタイムはOSのビット数ではなくアプリによって決まります。

WebView2ベースのクライアントの一部はMicrosoft Edge WebView2 Runtimeに依存しますが、ElectronやFlutter製のクライアントすべてに必要というわけではありません。ログやプロジェクトの要件で依存関係が明示されている場合に限り、インストールまたは修復してください。「ランタイムを全部入れる」ことを万能の解決策にしないでください。LinuxでGLIBCのバージョンエラーが出る場合は、通常、現在のディストリビューションに対応するビルドを選ぶ必要があります。他のOSのlibcファイルをコピーしても解決しません。

元に戻せる方法でユーザーデータの破損を確認する

コア単体では正常に動作するのに、画面が起動時にクラッシュする場合は、すべてのプロセスを終了してから、クライアントのユーザーデータフォルダーをバックアップし、名前を変更して再起動します。アプリが新しいデータを生成するか確認してください。フォルダー全体を削除しないでください。サブスクリプション、ルールの上書き、画面の状態、認証情報が別々のファイルに保存されている場合があります。

新しいフォルダーで起動できた場合は、まずサブスクリプション、次に上書きルールを戻し、画面の状態やキャッシュは最後に戻してください。古いファイルを一度にすべて戻すと、問題まで再発するおそれがあります。ログにGPUプロセスが示されている場合は、クライアントのドキュメントを参考にハードウェアアクセラレーションを無効にしてテストしてください。特定の画面の起動オプションを、すべてのClashクライアントに流用しないでください。

7. 復旧後の確認項目と、問い合わせ時に伝える情報

ウィンドウが開くのは最初の一歩です。次の項目を順番に確認し、一つずつ正常に動作することを確かめてから次の機能を戻しましょう。

1. 画面が起動した状態を保ち、ログでコアの再起動や設定解析エラーが繰り返されないことを確認する。
2. 実際に使う設定が正しく、サブスクリプション更新後も読み込めることを確認する。上書き設定によって未対応の項目が再び加わっていないかも確認する。
3. ルールモードでブラウザーから通信し、接続ログで適用されたルールと通信先を確認する。
4. TUNが必要な場合は有効にしてから、DNSの名前解決、スリープからの復帰、ネットワークの切り替えをテストする。
5. クライアント終了後にシステムプロキシが元に戻ることを確認する。クライアントが異常終了した後もWebページが開けない場合は、システムの手動プロキシが古いローカルポートを指したままになっていないか確認する。

解決しない場合は、クライアント名と完全なバージョン番号、コアのバージョン、OSのバージョン、CPUアーキテクチャ、問題が最初に発生した操作、起動時刻付近のエラーログを伝えてください。「最小構成では動くか」「TUNを無効にすると正常か」「新しいユーザーデータフォルダーでは正常か」の結果も添えると、「接続できない」というスクリーンショットだけより原因を特定しやすくなります。

設定項目を確認するにはYAMLガイド、よくあるネットワークの問題についてはトラブルシューティングをご覧ください。切り分けのポイントは、まず問題が発生している層を特定し、該当する設定を変更することです。原因が分からないまま再インストールして済ませないようにしましょう。