Clash クライアント起動クラッシュ トラブルシューティングガイド:ログの特定、ポート競合、設定のロールバック

Clash クライアント(Clash Verge Rev、Clash Plus、Clash for Windows などのフロントエンド、および内部で動作する mihomo コア)が起動時にクラッシュしたり「開いた瞬間に消える」現象は、ほとんどの場合ソフトウェア自体の欠陥ではなく、設定・ポート・権限・ファイルの整合性のいずれかに問題があります。本記事では実際のトラブルシューティングで遭遇する頻度が高い順に原因を並べ、そのまま実行できる検証手順を示します。OS の再インストールや繰り返しのアンインストール・再インストールをせずに問題を特定・解決できるようになることを目的としています。

起動クラッシュの原因が一目でわかりにくい理由

起動時のクラッシュは実行中のクラッシュとは異なり、多くの場合グラフィカルインターフェースの描画が終わる前にプロセスが終了してしまうため、ユーザーが目にできる情報はごくわずかです。ウィンドウが一瞬表示されるだけだったり、タスクバーのアイコンが出た直後に消えたりします。この種の問題の要点は、クライアント自体は多くの場合グラフィカルインターフェース(GUI)の層に過ぎず、実際にプロキシルールの処理や接続の確立を行っているのはコアプロセス(mihomo または旧版 Clash コア)であるという点です。クラッシュは GUI プロセス側で発生することもあれば、GUI に起動されたコアプロセスがすぐに終了してしまうこともあり、両者では確認すべき方向が全く異なります。そのため最初のステップは常に「ログを確認する」ことであり、推測ではありません。

最初のステップ:再インストールする前にログを確認する

ほぼすべてのプラットフォームの Clash クライアントはローカルに実行ログを残しています。再インストールしてしまうとこれらの手がかりが消え、原因の特定がより難しくなります。まず下表の場所からログファイルを見つけ、その内容を見た上で次の対応を決めることをお勧めします。

プラットフォーム	ログ/設定ディレクトリ	説明
Windows	%APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs	日付ごとにファイルが分かれ、コアの起動パラメータとエラー出力が記録されます
macOS	~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/logs	「フォルダに移動」から直接開けます
Linux(deb インストール)	~/.config/clash-verge-rev/logs	journalctl でサービスログを確認することも可能です
mihomo をコマンドラインで実行	ターミナルの標準出力 / -d ディレクトリ内の core.log	コマンドラインでフォアグラウンド実行するとエラーがターミナルに直接出力されます

直近のログファイルを開き、panic、FATAL、error、bind: address already in use といったキーワードを重点的に確認してください。これらは通常、問題の種類を直接示しています。

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

これは起動クラッシュの中で最も割合が高い原因で、特に設定ファイルを手動で編集した場合や、サブスクリプション提供元の設定フォーマットが規格に沿っていない場合に発生します。Clash の設定ファイルは YAML 形式で、インデントやコロンの後のスペースに非常に敏感です。よくある誤りには以下のようなものがあります:

スペースではなく Tab でインデントしている(YAML 仕様では Tab は許可されていません)
ルールやプロキシグループのリスト項目で、統一されたインデントレベルが保たれていない
コロンを含む文字列に引用符が付いていないため、キーと値のペアとして誤って解釈される
ルールプロバイダー(rule-providers)が、設定ファイル内で定義されていないプロキシグループ名を参照している

確認方法は明快です。コアが設定の解析に失敗すると、ログに具体的な行番号とフィールド名が表示されます。例えば yaml: line 42: mapping values are not allowed in this context のようになります。行番号を特定したら、その周辺のインデントを1行ずつ確認していけば十分です。もしログすら生成されない場合は、設定ファイル自体が読み込めていない可能性が高く(例えば文字エンコーディングが UTF-8 でないなど)、テキストエディタで UTF-8(BOM なし)として保存し直してから再度試してください。

よくある原因2:ポートが使用中

Clash はデフォルトで HTTP プロキシポート(一般的には 7890)、SOCKS5 ポート、コントロールパネルポート(一般的には 9090)を監視します。これらのポートが他のプログラム(完全に終了していない前回の Clash プロセス自体を含む)によって既に使用されている場合、コアはポートのバインド時にエラーを出してすぐに終了し、GUI は「開くとすぐ消える」ように見えます。

確認手順は次のとおりです:

ログ内で bind: address already in use や listen tcp :7890 関連のエラーを探す
Windows では netstat -ano | findstr 7890 でそのポートを使用しているプロセスの PID を確認し、タスクマネージャーで該当プロセスを終了する
macOS/Linux では lsof -i :7890 で使用状況を確認する
占有しているプロセスが前回終了しきれなかった Clash のコアである場合、タスクマネージャー/アクティビティモニタで残留している mihomo または clash プロセスを手動で終了し、クライアントを再起動する
ポート競合を確認したら、設定ファイル内の mixed-port、socks-port、external-controller を未使用のポート番号に変更し、保存後にクライアントを再起動して確認する

netstat -ano | findstr 7890
lsof -i :9090

よくある原因3:コアファイルの破損またはバージョン不一致

Clash Verge Rev や Clash Plus などのクライアントは、GUI とコア(mihomo)を分離してパッケージ化しており、コアは独立した実行ファイルとしてクライアントと一緒にインストールされます。ダウンロードの途中でファイルが切断されたり、システムのセキュリティソフトがコアの実行ファイルを誤って削除したり、互換性のないコアバージョンに手動で置き換えたりすると、GUI 起動後にコアプロセスが見つからない、または実行できないためすぐに終了してしまいます。

次の方法で確認できます:

クライアントのインストールディレクトリ内にコアの実行ファイル(通常は verge-mihomo または clash-meta という名前)が存在するかを確認する。ファイルサイズが明らかに小さい(数十 KB 程度)場合はダウンロードが不完全であることを示す
セキュリティソフト(特に中国製の総合セキュリティツール)の隔離/信頼リストの履歴を確認する。コアファイルは誤検知されて隔離されることがよくある
コアのアーキテクチャがシステムと一致しているか確認する。例えば Apple シリコン搭載の Mac では arm64 版のコアが必要で、Intel 版のコアファイルはそのまま使用できない

解決方法は、完全なインストールパッケージを再ダウンロードして上書きインストールすること、またはダウンロードセンターから対応プラットフォームのコアファイルを個別に取得してインストールディレクトリに置き換えることです。同時にクライアントのインストールディレクトリをセキュリティソフトの信頼リストに追加し、再度誤って削除されるのを防ぎましょう。

よくある原因4:システム権限の不足

この種の問題は TUN モード(仮想ネットワークアダプタでグローバル通信を処理する機能)を有効にしたときに最も多く発生します。TUN モードでは仮想ネットワークインターフェースを作成する必要があり、この操作はどのプラットフォームでも権限の昇格が必要です:

Windows ではクライアントを管理者権限で実行する必要があります。そうしないと TUN デバイスの作成時にエラーが発生して終了します
macOS では「システム設定」の「プライバシーとセキュリティ」でクライアントによるネットワーク拡張の読み込みを許可する必要があります。初回有効化時にシステムレベルの許可プロンプトが表示されるので、誤って「拒否」を選んだ場合はシステム設定から手動で再許可してください
Linux で一般ユーザーとして mihomo を実行し TUN を有効にするには CAP_NET_ADMIN 権限が必要です。一般的には sudo で実行するか、コアの実行ファイルに capability を設定します

TUN モードを有効にした直後からクラッシュが始まった場合は、ほぼ権限の問題と判断できます。まず TUN モードを無効にしてクライアントが正常に起動するか確認し、その後上記の方法で権限を昇格してください。

検証手順の推奨順序

クラッシュが発生した場合は、複数の要素を同時に変更するのではなく、次の順序で確認することをお勧めします。これにより、どの部分に問題があるのかを正確に特定できます:

まずログを確認し、設定の解析エラー、ポートのバインド失敗、コアプロセスの直接クラッシュのいずれであるかを確認する。

一時的に既知の動作する最小構成の設定ファイル(基本的なポートと直接接続ルール1つのみ)に切り替え、クライアント自体が正常に起動するか確認する。

起動できた場合は元の設定ファイルに問題があるため、前述の方法で構文やポート競合を順に確認する。起動できない場合は、クライアントのインストールまたはシステム権限の側に問題がある。

TUN モードやシステムプロキシの引き受けなどの拡張機能を一つずつ無効にし、問題を安定して再現できる最小条件まで絞り込む。

コアファイルの問題であると確認できたら、公式のインストールパッケージを再ダウンロードして上書きインストールし、出所不明のコア代替ファイルの使用は避ける。

安全な設定のロールバック方法

問題のある設定ファイル上で何度も試行錯誤するより、履歴バージョンを保存していつでもロールバックできるようにする方が確実です:

多くのクライアントは「サブスクリプション管理」や「設定ファイル」の画面で更新前のバックアップを自動保存しており、画面上で「前のバージョンに戻す」を選択できます
設定を手動で編集する前に、コピーを1つ作成して日付を付けたファイル名(例:config-2026-05-15.yaml)で保存し、新しいバージョンが問題なく動作することを確認してから古いバックアップを削除してください
設定がサブスクリプションリンクから取得されている場合、更新前に手動でエクスポートしたローカルコピーを残しておくと、サブスクリプション提供元のサーバーが異常な内容を返して上書きされた際にも復元できます
ロールバック後にクライアントを再起動してログを確認し、クラッシュ現象が解消されたことを確かめてから、変更を一つずつ元に戻し、どの変更が問題を引き起こしたのかを特定してください

注意

根本原因を確認する前に問題の設定ファイルを削除しないでください。まずアーカイブとして保管しておけば、後で比較検証したり、サブスクリプション提供元に問題を報告する際のサンプルとして使用できます。

それでも解決しない場合の対処

上記の順序で確認してもクライアントが起動しない場合は、次のような最終手段を検討してください:

クライアントを完全にアンインストールし(設定ディレクトリを空にした上で)再インストールし、インストール過程での残存ファイルの破損の可能性を排除する
別のクライアントに切り替える(例えば GUI クライアントから純粋にコマンドラインで mihomo コアを実行する方式に変更する)ことで、問題が特定の GUI フロントエンドに関連しているかを確認する
権限の低いアカウントや新規のシステムユーザーでテストし、システムレベルの環境変数やローカルポリシーによる干渉を排除する
完全なログファイルを保存しておき、コミュニティやフィードバック窓口で問題を説明する際に正確な情報を提供できるようにする

起動時のクラッシュは一見厄介に思えますが、「まずログを確認し、次に範囲を絞り、最後にロールバックして検証する」という順序で対処すれば、ほとんどの場合十数分で具体的な原因を特定できます。設定のバックアップを保存し、残留プロセスやポートの使用状況を定期的に確認する習慣をつけることで、こうした問題の発生頻度を根本的に減らすことができます。