Clashが起動直後に落ちるときの対処法｜クラッシュログの確認と修復手順

まず確認：ウィンドウが閉じるのか、コアが終了するのか、アプリ全体がクラッシュするのか

アイコンをダブルクリックしてもウィンドウが見えないからといって、Clashがクラッシュしたとは限りません。デスクトップクライアントは通常、GUI、プロキシコア、任意のバックグラウンドサービスで構成されています。ウィンドウがタスクトレイに最小化されていたり、画面は正常に起動していても、設定エラーでmihomoコアだけが終了していたりする場合があります。まず問題が起きている層を特定すれば、遠回りせずに対処できます。

1. タスクトレイまたはメニューバーを確認する。Windowsではタスクバー右側の隠れているアイコンを表示し、macOSでは画面上部のメニューバーを確認します。アイコンがあれば、まず「メイン画面を表示」を試してください。続けて複数のプロセスを起動しないようにしましょう。
2. プロセスを確認する。Windowsでは「タスク マネージャー」→「詳細」、macOSでは「アクティビティモニタ」、Linuxではシステムモニターを開きます。クライアントのプロセスと、mihomoなどのコアプロセスが残っているか確認してください。
3. 問題が起きるタイミングを記録する。アップグレード直後に起動しない、サブスクリプション更新後に終了する、TUNを有効にすると終了する場合は、それぞれプログラム環境、設定、権限の問題が疑われます。
4. 重複して起動したプロセスを終了してから再試行する。まずタスクトレイから終了し、プロセスが停止したことを確認します。バックグラウンドサービスが動作し続けていることもあるため、ウィンドウを閉じただけで完全に終了したとは判断できません。

起動ログの確認場所：OS別の見つけ方

画面を開ける場合は、「設定」から「ログフォルダーを開く」「設定フォルダーを開く」「アプリケーションフォルダー」などの項目を探してください。画面上のログにはコアの出力が記録されることがありますが、GUI自体のクラッシュが記録されるとは限りません。まったく起動できない場合は、OSのクラッシュ記録も確認します。

Windows： 「アプリケーション エラー」だけでなく障害モジュールも確認

Win + Rを押してeventvwr.mscと入力し、問題が起きた時刻のアプリケーションイベントを絞り込みます。イベントID 1000はアプリケーションのクラッシュ、1001はWindowsエラー報告に関連する情報として記録されることがあります。ただし、いずれも手がかりであり、原因そのものとは限りません。「障害が発生しているアプリケーション名」「障害モジュール名」「例外コード」を記録し、クライアントのログと照合してください。

Linux・Android：再現時の出力を保存する

Linuxではクライアントの実行ファイルをターミナルから起動できます。ユーザー単位のsystemdサービスを使っている場合は、直近10分のログを確認してください。以下のAndroidコマンドを使うにはADBのインストール、USBデバッグの有効化、PCの許可が必要です。問題を再現したらすぐに実行してください。

# Linux：ユーザーセッションのログを確認
journalctl --user --since "10 minutes ago" --no-pager

# Android：クラッシュバッファーをPCのカレントディレクトリに保存
adb logcat -b crash -d > clash-crash.txt

ログを共有する前に、サブスクリプションURL内のトークン、ノードのパスワード、UUID、コントロールインターフェースのキー、公開したくない接続先ドメインを伏せてください。エラー前後の約30行だけを共有するほうが、設定フォルダー全体をアップロードするより原因を特定しやすく、情報漏えいも抑えられます。

原因1：YAMLの構文エラー、または設定とコアの非互換

設定の編集、サブスクリプションの更新、コアの切り替え後に問題が始まった場合は、まずログにyaml:、unmarshal、proxy group、not foundなどがないか確認します。YAMLのインデントにはスペースを使い、Tabは使えません。コロンの後のスペース不足やリストのインデントずれでも、解析に失敗します。

• 構文エラー：ログにline 18とあれば、18行目とその前の数行を確認します。表示された行は、パーサーが処理を続けられなくなった位置にすぎない場合があります。
• 参照エラー：プロキシグループが存在しないノード名を参照している、またはルールが未定義のプロキシグループやルールセットを参照している場合は、設定の意味上の問題です。インデントを直すだけでは解決しません。
• コアの不一致：Clash、Clash Premium、Clash Meta（現mihomo）では、利用できる機能が異なります。プロトコルや設定項目が使えるかどうかは、画面のブランド名ではなく、実際に起動しているコアとそのバージョンで判断してください。
• ダウンロード内容の問題：期限切れのサブスクリプションURLは、ログイン画面やエラーテキストを返すことがあります。ファイルの先頭がHTMLになっていないか確認し、サーバーのエラーページをYAMLとして読み込まないでください。

同じコアで設定をテストする

サブスクリプションから生成されたファイルを直接編集しないよう、確認用の設定をコピーして使います。mihomoを使うクライアントでは、実際に使用しているコアでテストできます。設定が相対パスのファイルを参照している場合は、元の作業ディレクトリも指定してください。以下はWindows PowerShellの例です。実際のコアがあるフォルダーに移動し、必要なファイルを用意してから実行してください。

.\mihomo.exe -v
.\mihomo.exe -t -d "C:\Clash-Debug" -f "C:\Clash-Debug\config.yaml"

-vはバージョン確認、-tは設定チェックに使います。設定ファイルと必要なローカルルールファイルをテスト用フォルダーに置いてから実行してください。リソース不足やリモートからのダウンロード失敗でもテストに失敗することがあります。失敗をすべてYAMLのインデントが原因だと決めつけないでください。テストに通っても、その時点での設定チェックが成功しただけで、TUNの権限、ポートのバインド、ネットワーク接続まで正常とは限りません。

原因2：7890番ポートまたはコントロールポートが使用中

ログにbind: address already in useと出る場合や、Windowsで「通常、各ソケット アドレスに対して使用できるのは 1 回だけです」と表示される場合は、待ち受けポートを確認します。混合ポートは7890、コントロールポートは9090がよく使われますが、どちらも変更できます。現在の設定を確認してください。ポート競合では通常コアの起動に失敗しますが、GUI全体が終了するとは限りません。

# Windows PowerShell：指定したポートの待ち受けを確認
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

# macOS：7890番ポートのTCP待ち受けプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受けポートとプロセスを一覧表示
ss -ltnp

WindowsではGet-Process -Id プロセス番号を使い、前の手順で表示されたPIDを調べられます。よくある原因は、別のプロキシクライアント、終了しきれていない古いコアプロセス、または稼働中のサービスです。プロセスを特定してから、該当するプログラムから正常に終了してください。ポートが使用中だからといって、システムプロセスをすぐ強制終了しないでください。

1. ほかのプロキシクライアントと、不要なバックグラウンドサービスを終了してから、もう一度起動します。
2. 2つのプログラムを同時に使う必要がある場合は、片方の混合ポートを7897など未使用のポートに変更し、待ち受け状態を再確認してください。
3. プロキシを手動設定しているブラウザー、ターミナル、LAN内のデバイスも同じポートに変更します。コアのポートだけ変えてアプリ側のプロキシアドレスを更新しないと、「クライアントは起動するがアプリはネットにつながらない」状態になります。

permission deniedや「アクセス許可で禁止されている方法でソケットにアクセスしようとしました」というエラーは、ポート使用中と同じ意味ではありません。OSの予約ポート、セキュリティポリシー、バインド権限が関係する場合もあるため、エラー全体を確認してください。

原因3：コアファイルの不足、アーキテクチャの不一致、インストール不備

no such file or directory、failed to spawn、exec format errorが表示されたら、まずプログラムが正しくインストールされているか確認します。配布形式によってはGUIとコアが別の場所にあります。メインプログラムだけをコピーすると、同梱のリソースや補助プログラムが不足することがあります。

• アーキテクチャを確認：Windowsでは「設定」→「システム」→「バージョン情報」でシステムの種類を確認します。macOSでは「このMacについて」でチップを確認し、Linuxではuname -mを実行します。x86_64とaarch64ではビルドが異なるため、互換性を確認せずに入れ替えないでください。
• インストール方法を確認：アーカイブは最後まで展開して固定のフォルダーに置いてから起動します。macOSではアプリを「アプリケーション」フォルダーにコピーして起動し、ディスクイメージから直接起動し続けないでください。
• セキュリティソフトの履歴を確認：Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開きます。ファイルの入手元と検出内容を確認してください。起動のためにセキュリティ機能全体を無効にしないでください。
• プログラムファイルを再インストール：プロジェクトの公式リリースから、OSに合ったインストーラーを入手します。ユーザーデータは先に保持し、「プログラムの再インストール」と「設定の削除」を一度に行わないでください。

Linuxで「ファイルが存在しない」と表示されても、実際には動的ローダーや依存ライブラリが不足している場合があります。信頼できる配布元のバイナリなら、fileでアーキテクチャを確認し、ターミナルに表示される依存関係のエラーも調べてください。ファイルサイズが正常というだけで、完全に実行できるとは判断できません。

原因4・5：TUNの権限、サービスの異常、ランタイム不足

TUNを有効にしたときだけ終了する場合は、通常のプロキシでテストする

TUNは仮想ネットワークアダプターの作成やルート設定を行い、設定によってはDNSも引き継ぐため、高い権限が必要になることがあります。TUNを無効にすると正常に起動する場合は、サブスクリプションを何度も入れ替えるのではなく、クライアントの「サービスモード」や特権ヘルパーを確認してください。

1. ネットワークを制御しているほかのVPNやプロキシツールを終了し、クライアントを1つだけ起動してテストします。
2. 画面を開ける場合はTUNを無効にして再起動し、通常のプロキシが使えるか確認します。
3. 現在のクライアントに用意されているインストールまたは修復機能でサービスを修復し、サービスが現在のインストール先を参照しているか確認します。ポータブル版のフォルダーを移動すると、古いサービスが以前のパスを参照したままになることがあります。
4. macOSでは特権ヘルパーの許可状態を確認し、Linuxではサービスログの権限エラーを確認します。設定フォルダー全体を誰でも書き込める状態にしたり、問題を隠すためにGUIをrootで常用したりしないでください。

AndroidでVPNの許可を拒否した場合や、別のアプリがVPN接続を使用中の場合は、通常は接続に失敗するだけで、アプリのプロセスがクラッシュするわけではありません。システムのクラッシュ記録がアプリの異常終了を示している場合に限り、起動時のクラッシュとして調査してください。

画面が真っ白になる、または一瞬で消える場合はGUIの実行環境を確認する

GUIの技術によって必要な環境は異なります。Tauriを使うWindowsクライアントは通常Microsoft Edge WebView2に依存します。一方、Electronベースのクライアントは通常Chromium環境を同梱しているため、白画面の原因がすべてWebView2とは限りません。クライアントのリリースノートで動作要件を確認し、Microsoftが提供する該当コンポーネントをインストールまたは修復してください。

VCRUNTIME140.dllまたはMSVCP140.dllが見つからないと表示された場合は、ソフトウェアの要件に従ってMicrosoft Visual C++ Redistributableをインストールし、アプリのアーキテクチャに合わせてください。DLL配布サイトから個別にファイルを入手しないでください。Linuxで共有ライブラリが不足している場合は、ディストリビューションとプロジェクトの依存関係の説明に従って該当パッケージをインストールします。出所不明のライブラリをシステムフォルダーにコピーしないでください。

安全に設定をリセットする：削除せず、名前を変更して退避

設定チェックで原因が分からない場合や、クライアントのアップグレード後に古い画面状態を読み込むとクラッシュする場合は、新しいユーザーデータで動作を確認できます。ただし、サブスクリプション、ルールの上書き、プロキシグループの選択、ショートカット、サービス、TUNの設定に影響することがあります。ログを確認した後に行ってください。

1. 先にエクスポートまたはコピーする。サブスクリプションの入手元、ローカル設定、ルールの上書き、スクリプト、クライアント設定を保存します。認証情報を含むバックアップは、管理された安全な場所に保管してください。
2. 完全に終了する。タスクトレイのプロセスを終了し、関連するコアも停止したことを確認します。サービスを操作する必要がある場合は、クライアントに用意されたサービス管理機能を使ってください。
3. 実際に使われているユーザーデータフォルダーを退避する。対象が現在のクライアントのデータフォルダーだと確認してから、.backup-20261021のような名前に変更します。AppDataや.config全体の名前は変更しないでください。
4. 初期状態で起動する。起動できたら、まずTUNを有効にせず、動作確認済みの設定を1つだけ読み込んで、起動と終了を確認します。
5. 設定を1つずつ戻す。サブスクリプション、ルールの上書き、画面設定、TUNの順に戻し、項目を追加するたびに再起動します。古いフォルダーを丸ごと戻すと、問題まで復元してしまうおそれがあります。

新しいデータでもクラッシュする場合は、調査対象をプログラムのビルド、実行環境、OSとの互換性に切り替えます。この段階で設定を何度もリセットしても、通常は解決しません。バックアップを保持したうえで、プロジェクトのリリースノートを確認し、互換性のある別バージョンを試してください。旧バージョンで新バージョンのデータフォルダーを直接開かないようにしましょう。

問い合わせ前の確認リスト

問い合わせる際は、「起動しない」だけでなく、再現できる手順を伝えましょう。次の情報があれば、メンテナーはGUI、コア、システム環境のどこに問題があるか判断しやすくなり、確認のやり取りも減らせます。

• クライアント名と完全なバージョン、コア名とバージョン、OSのバージョン、CPUアーキテクチャ。
• インストーラーの種類、インストール先を移動したかどうか、旧バージョンからアップグレードしたかどうか。
• 「起動から2秒後に終了」「TUNを有効にするとすぐ終了」などの再現手順。確認できていない原因を、確定した事実のように書かないでください。
• 発生時刻、関連ログ、システムのクラッシュモジュール、設定テストで表示されたエラー全文。
• TUNを無効にした場合、ほかのクライアントを停止した場合、新しいデータフォルダーを使った場合、それぞれの結果。

修復後は一連の動作を確認します。メイン画面が繰り返し開くこと、プロキシコアが動作し続けること、ローカルポートが実際に待ち受けていること、プロキシを手動設定したアプリが正しいポートを使うこと、正常終了後にシステムプロキシ設定が残らないことを確認してください。TUNを使っていた場合は、起動と停止も個別に検証します。これにより、「ウィンドウが表示された」だけなのか、「プロキシ接続全体が復旧した」のかを区別できます。