Clashクライアントの起動直後にクラッシュする場合の対処法：設定・権限・残留プロセスを確認

まずクラッシュ、バックグラウンド実行、ウィンドウ非表示を区別する

Clash のGUIクライアントは通常、画面を表示するプログラム、プロキシコア、システムサービスで構成されています。アイコンをダブルクリックしてもメインウィンドウが表示されないからといって、3つすべてが終了したとは限りません。画面がシステムトレイに最小化されていたり、ウィンドウ位置が接続を解除したディスプレイ上に残っていたり、プロキシコアだけがバックグラウンドでポートを待ち受けている場合があります。トラブル対処の第一歩は起動を繰り返すことではなく、現在の状態を確認することです。

まず Windows のタスクバー通知領域、macOS のメニューバー、Linux デスクトップのトレイを確認します。クライアントのアイコンがあれば、メニューからメイン画面を開いてみてください。デュアルディスプレイ、リモートデスクトップ、表示倍率の変更を利用したことがある場合は、ウィンドウが画面の外側に移動していないかも確認します。これは画面の復旧に関する問題であり、プロキシコアのクラッシュではありません。

続いてシステムのプロセス管理ツールを開き、クライアントの画面プロセスと、Clash、mihomo、または利用中のクライアントに対応するコアプロセスを探します。次の状態を目安に切り分けてください。

画面とコアのプロセスがすぐに消える：起動ログ、設定の解析、ランタイム、ローカルデータを優先して確認します。
画面だけ消え、コアは残っている：画面のログ、ウィンドウ状態ファイル、グラフィック実行環境を重点的に確認します。
画面は残っているが、コアが何度も再起動する：YAML 設定、ポートの使用状況、TUN 権限、コアのバージョンを重点的に確認します。
プロセスは残っているのにウィンドウがない：まずトレイから復元し、次にウィンドウレイアウトのリセットを検討します。設定をすべて削除するのは避けてください。

ログからクライアントが停止した段階を確認する

クラッシュが起きた後は、ポップアップよりログのほうが信頼できます。クライアントによってログの保存場所は異なりますが、通常はユーザー設定フォルダー、アプリデータフォルダー、またはクライアントのインストール先付近にあります。ファイル名には app、main、service、core、runtime などが含まれることがあります。画面を一時的に開ける場合は、まず設定またはログ画面で実際の保存先を確認し、別のクライアントのパスを参考にしてファイルを直接削除するのは避けてください。

ログは最後に起動した時刻から読み始め、単独の error だけを検索しないでください。警告の一部は起動を妨げません。実際に終了の原因となった情報は、末尾の数行に現れることが多いです。起動段階ごとに確認すると、原因を特定しやすくなります。

画面プログラムが設定とウィンドウ状態を読み込む。
現在の設定ファイル、またはサブスクリプションから生成された設定を読み込む。
Clash または mihomo コアを起動する。
mixed-port、HTTP、SOCKS、コントロールポート、DNS ポートをバインドする。
ルールセット、GeoIP、GeoSite などのデータを読み込む。
システムプロキシを設定する、または TUN とシステムサービスを起動する。

ログが設定の読み込み段階で止まる場合は、まず YAML を確認します。address already in use、bind failed などが表示される場合はポートを確認し、permission denied、operation not permitted などが表示される場合はフォルダーや TUN の権限を確認します。動的ライブラリ、WebView、グラフィックコンポーネントが見つからない場合は、画面の実行環境に関する問題です。すべてのエラーをサブスクリプションのノードが原因だと考えないでください。ノードが利用できない場合は通常、接続に影響するだけで、画面を読み込む前にクライアントが終了することはありません。

ログの手がかり	よくある場所	次の対応
parse、yaml、unmarshal	設定の解析段階	インデント、フィールドの型、コアとの互換性を確認する
address already in use	ポートのバインド段階	占有プロセスを終了する、またはポートを変更する
permission denied	ファイル、サービス、TUN の初期化	フォルダーの権限とシステムサービスの状態を確認する
database、cache、state	ローカルデータの読み込み段階	バックアップ後、該当するデータファイルを再構築する
webview、runtime、library	グラフィカルインターフェースの初期化	クライアントが必要とするシステム実行コンポーネントを修復する

YAML 設定の構文とコアとの互換性を確認する

設定エラーは、コアの起動直後に終了する主な原因です。Clash の設定には YAML が使われており、インデント、リストの階層、データ型が解析結果を左右します。Tab 文字、全角コロン、空白不足、閉じていない引用符、リストを通常の文字列として記述することなどが、コアの読み込み拒否につながります。サブスクリプションを正常にダウンロードできても、生成された設定が現在のコアに適合するとは限りません。

現在の設定を先にバックアップし、クライアント付属の基本設定、または以前に動作を確認した設定へ切り替えます。クライアントが起動できれば、原因は現在のサブスクリプション、上書きスクリプト、手動で変更した内容に絞り込めます。最初からクライアントをアンインストールするのは避けてください。再インストール後に同じ誤った設定を取り込めば、問題は再発します。

次の例は、混同しやすい階層を示したものです。ルールは文字列のリストで、プロキシグループ内の proxies もリストです。インデントをそろえる必要があります。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

プロキシコアを直接実行できる場合は、コアに付属する設定テスト用のパラメーターでファイルを確認できます。mihomo でよく使われるテスト方法は次のとおりですが、実行ファイル名とパスは実際のインストール内容に合わせてください。

mihomo -t -f /path/to/config.yaml

テスト結果の行番号は通常、解析に失敗した付近を示しますが、原因が数行前にある場合もあります。たとえば引用符が閉じていないと、解析器が次のフィールドまで進んでから異常を報告することがあります。確認時はエラーが出た行だけでなく、同じ設定ブロックを上方向にも確認してください。

更新後に初めて現れたフィールドの非互換

Clash Meta は後継プロジェクトとして mihomo に引き継がれ、対応する設定フィールドは初期の Clash コアと完全には一致しません。サブスクリプション変換ルール、TUN 設定、DNS の拡張モード、ルールセット形式、プロキシプロトコルのパラメーターは、特定のコアバージョンに依存することがあります。mihomo 向けに生成された設定を古いコアで読み込むと、unknown field、unsupported proxy type、ルールプロバイダーの読み込み失敗などが発生する場合があります。

逆に、コアを更新したことで、以前は見過ごされていた古い設定の問題が表面化することもあります。その場合は、クライアントが現在使用しているコアの種類とバージョンを確認し、サブスクリプションの変換先も確認してください。見慣れないフィールドを無計画に削除して強引に起動するのは避けましょう。DNS、ルールセット、プロキシのパラメーターを削除すると、構文は通っても実際のルーティング結果が変わる可能性があります。

実行権限、設定フォルダー、TUN サービスを確認する

通常のシステムプロキシモードでは、クライアントを常に管理者権限で実行する必要はありません。ただし、保護されたフォルダーへの書き込み、システムサービスのインストール、TUN ネットワークインターフェースの作成には、適切な権限が必要です。権限不足は明確なメッセージとして表示されることもあれば、サービス初期化の段階でクライアントが突然終了する形で現れることもあります。

Windows では、クライアントが特別な書き込み権限を必要とするシステムフォルダーに置かれていないか確認し、セキュリティポリシーが設定フォルダーへの書き込みを妨げていないか確認します。独立したサービスモードがある場合は、「管理者として実行」で長期的に回避するのではなく、クライアントの設定からサービスを再インストールまたは修復してください。サービスと画面のバージョンが一致しない場合も、コアの起動失敗や再接続の繰り返しが起こることがあります。

macOS では、アプリが通常のアプリケーションフォルダーにあること、システムのプライバシーとセキュリティ設定がネットワーク拡張機能やバックグラウンド項目をブロックしていないことを確認します。出所が不明なプログラムへの対処として、システムのセキュリティ機能を無効にするのは避けてください。インストールパッケージの入手元を確認し、現在のシステムアーキテクチャに合うバージョンを使用します。Linux では、設定フォルダーの所有者、実行権限、TUN デバイスへのアクセス権を確認します。

TUN モードを個別に検証する

TUN モードは仮想ネットワークインターフェースを作成してルーティングを変更するため、通常の HTTP や SOCKS プロキシより高い権限が必要です。ログが tun、route、interface、service などの箇所で止まる場合は、まず TUN を無効にしてシステムプロキシだけでテストします。通常のプロキシモードで起動できるなら、YAML の主要部分と画面はおおむね正常で、問題は TUN サービス、ドライバー、権限、ルーティング環境に絞られます。

TUN を無効にするのは診断のための手順です。TUN を再び有効にする際は、クライアントのサービスインストール状態、古い仮想ネットワークアダプターの残存、他の VPN やネットワークフィルタリングソフトによるルーティングの同時制御を確認します。複数のネットワークツールを同時に使うと、ポートが異なっていてもルーティングテーブルや DNS の制御で競合することがあります。

ポート競合と残留プロセスに対処する

プロキシコアは起動時に、設定されたポートで待ち受ける必要があります。よく使われるポートには mixed-port、port、socks-port、external-controller、DNS listen があります。古いコアが終了していない場合や、別のプロキシプログラムが同じポートを使っている場合、新しいコアはバインドに失敗します。クライアント画面がコアの終了を致命的なエラーとして扱うと、画面も連動して閉じ、ダブルクリック後にクラッシュしたように見えることがあります。

Windows では、まずタスクマネージャーで該当プロセスを終了し、コマンドで指定ポートを確認します。

netstat -ano | findstr :7890

出力末尾の PID から、ポートを使用しているプロセスを特定できます。macOS と Linux では次を使用します。

lsof -nP -iTCP:7890 -sTCP:LISTEN

ポートが使用中だからといって、未知のシステムプロセスをすぐに終了しないでください。まず PID に対応するプログラム名を確認します。前回の起動で残った Clash または mihomo であれば正常に終了して構いません。引き続き必要な別サービスであれば、クライアントの設定でポートを変更し、システムプロキシが新しいポートを参照しているかも確認します。

残留プロセスが繰り返し現れる理由

クライアントによっては画面を閉じてもプロキシ接続を維持するためにコアを残します。また、クラッシュ後にクリーンアップ処理を実行できないこともあります。再起動時に古いコアがポート、コントロールインターフェース、設定ファイルのロックを保持している場合があります。まずトレイから完全終了を実行し、数秒待ってからプロセスを確認してください。終了していなければ、システムツールで停止します。

システムを再起動すれば通常の残留プロセスは消去できますが、自動起動する古いサービスまでは修復できません。起動するたびに競合する場合は、システムのスタートアップ項目とサービス一覧を確認し、異なるバージョンのクライアントが2つ同時に自動起動していないか確認します。現在使うクライアントの入口を1つに統一し、その設定からコアサービスを管理してください。

バックアップ後に破損したローカルデータを再構築する

設定構文、権限、ポートに問題がない場合は、クライアント自身が保存する状態データを確認します。異常終了、ディスク書き込みの中断、バージョンをまたぐ移行によって、ウィンドウレイアウト、設定インデックス、データベース、キャッシュ、設定ファイルが破損することがあります。データフォルダー全体を直接削除すれば復旧する可能性はありますが、サブスクリプション履歴、上書きルール、カスタム設定も失われます。段階的に切り分けてください。

画面、コア、関連サービスを完全に終了する。
クライアントが実際に使用しているデータフォルダーを見つけ、別のバックアップ先にコピーする。
まずウィンドウ状態、キャッシュ、ログのフォルダーをリネームしてから起動テストする。
それでもクラッシュする場合は、設定データベースまたは設定インデックスをリネームする。
クライアントに新しいデータフォルダーを生成させ、メイン画面を開けることを確認する。
必要なサブスクリプションURLと検証済みの設定だけを戻し、フォルダー全体を上書きして戻さない。

「削除」ではなく「リネーム」する方法なら、いつでも元に戻せます。項目を1つずつ復元して破損ファイルを特定することも可能です。クライアントによってデータ構造は大きく異なるため、ファイル名を別のクライアントにそのまま当てはめないでください。特に Electron、WebView、その他のデスクトップコンテナを基盤とする画面では、キャッシュとコア設定が別のサブフォルダーにあることが多いため、ログとクライアント設定から用途を確認してください。

新しいデータフォルダーでは起動できても、古いサブスクリプションを取り込むと再び終了する場合は、設定の互換性を確認します。画面設定だけを戻したときにクラッシュするなら、ウィンドウレイアウト、テーマ状態、ローカルデータベースを重点的にリセットします。これにより、何度も再インストールせず、問題を1種類のデータに絞り込めます。

更新後にクラッシュする場合：アーキテクチャ、コア、実行環境を確認する

クライアント更新後の初回起動でクラッシュする場合は、アプリのアーキテクチャ、内蔵コア、システムバージョン、設定の移行を同時に確認します。Windows のインストーラーには x64、ARM64 などの違いがあり、macOS では Intel と Apple Silicon を区別する必要があります。適合しないビルドを選ぶと、起動できなかったり、コアの読み込み時に終了したりします。システム情報でプロセッサのアーキテクチャを確認し、対応するバージョンを選択してください。

一部のGUIクライアントは、システムの WebView や特定の実行コンポーネントに依存します。ログに実行環境の不足が明記されている場合は、OS またはクライアントのドキュメントで指定された方法でコンポーネントを修復してください。別のPCから動的ライブラリをコピーする方法は、バージョンやアーキテクチャの不一致を招きやすく、安定した修復方法ではありません。

上書きインストールでは、古いコア、古いサービス、古い設定の移行情報が残ることもあります。その場合はデータをバックアップし、システムのアンインストール手順で旧プログラムを削除してから、現在のバージョンをインストールします。アンインストール前に、サブスクリプションURL、カスタムルール、ポート、DNS 設定を必ず記録してください。再インストール後はまず初期状態で起動し、画面とコアが正常であることを確認してから、設定を1つずつ戻します。

新しいOSが現在のクライアントに対応しなくなった場合は、そのOSに対応し、現在も保守されている Clash GUI クライアントを選択します。移行時に重視すべきなのは画面の名称ではなく、設定とコアの互換性です。mihomo の設定に含まれる一部のフィールドには対応コアが必要であり、古い Clash 設定を新しいコアへ移行するときも DNS、TUN、ルールプロバイダーの動作を再確認してください。

決められた順序で復旧手順を実行する

クラッシュの調査で最も陥りやすいのは、複数の箇所を同時に変更してしまうことです。次の順序はリスクの低い操作から始まり、各手順で明確な判断材料を得られます。起動直後の終了、ウィンドウ非表示、更新後のクラッシュ、コアの停止が繰り返される場合に利用できます。

トレイとプロセスを確認：ウィンドウが隠れているのか、画面がクラッシュしたのか、コアが終了したのかを判断します。
古いインスタンスを完全に終了：画面、コア、残留サービスを閉じ、複数のインスタンスによるポート競合を防ぎます。
最後のログを読む：停止した段階と最初の重要なエラーを記録し、末尾に連続して表示される二次エラーだけを見ないようにします。
基本設定へ切り替え：クライアントの初期設定を使い、YAML またはサブスクリプションが原因かを確認します。
通常のプロキシモードをテスト：一時的に TUN を無効にし、コアの起動問題とシステムのネットワーク権限問題を切り分けます。
待ち受けポートを確認：mixed-port、コントロールポート、DNS ポートが他のプログラムに使用されていないか確認します。
プログラムのアーキテクチャとコアのバージョンを確認：クライアント、コア、OS、設定の対象が互いに適合していることを確認します。
ローカル状態を再構築：バックアップ後、キャッシュ、ウィンドウ状態、データベースを順番にリネームします。
再インストールは最後に行う：まず初期状態で検証し、その後サブスクリプションとカスタム設定を戻します。

上記の手順を完了しても終了する場合は、クライアントのバージョン、OS のバージョン、プロセッサアーキテクチャ、コアの種類、重要なログ、再現手順を保存します。問題を報告する際は、サブスクリプションURL、ノードの認証情報、コントロールインターフェースのキーを隠し、エラーに関係するフィールドだけを残してください。完全な環境情報があれば、クライアント画面、mihomo コア、設定ジェネレーター、システムのネットワークコンポーネントのどこに問題があるか判断しやすくなります。