画面の終了・コアの停止・ウィンドウの非表示を見分ける

Clashクライアントは通常、GUI、プロキシコア、必要に応じてバックグラウンドサービスで構成されています。画面が消えても、コアまでクラッシュしたとは限りません。ノードがすべてタイムアウトしても、クライアントが強制終了したとは限りません。まずどの部分が終了したのかを見極めてから設定を確認すれば、原因を残したまま再インストールを繰り返す事態を防げます。

確認できる症状まず確認する項目判断のポイント
ウィンドウは消えたが、通知領域にアイコンが残っているウィンドウを閉じたときに通知領域へ最小化する設定通知領域のメニューからウィンドウを再表示し、非表示になっているだけか確認する
画面は正常だが、コアに接続できないと表示される設定の読み込み、コアのプロセス、コントロールポート画面のデータを消す前に、コアのログを確認する
ウィンドウとプロセスが同時に終了するシステムのクラッシュ記録、実行環境、アプリのデータ終了時刻と障害が発生したモジュールを記録する
TUNを有効にしたときだけ終了するサービスの権限、仮想ネットワークアダプター、他のVPNTUNを無効にすると安定して起動するか確認する

Windowsでは Ctrl + Shift + Esc でタスク マネージャーを開き、「詳細」タブでクライアントとコアのプロセスを確認します。macOSでは「アクティビティモニタ」を開き、クライアント名と mihomo を検索します。Androidでは「設定」→「アプリ」→該当するクライアントを開き、アプリの終了とVPN接続の切断を区別します。メニュー名はメーカーやOSのバージョンによって異なる場合があります。

設定をバックアップし、最初のエラーを記録する

サブスクリプションとローカルの変更を残す

クライアントとバックグラウンドサービスを完全に終了してから、設定フォルダーをバックアップします。サブスクリプションURL、ローカルのYAML、オーバーライド、ルールセット、プロキシグループの選択内容を重点的に保存してください。設定フォルダーの場所はクライアントによって異なるため、特定の製品のパスをすべてのClashクライアントに当てはめないでください。画面を開ける場合は、クライアントにある「設定フォルダーを開く」または「ログフォルダーを開く」を使うのが確実です。

画面を開けない場合は、インストールガイドやOSのアプリデータフォルダーを確認します。Windowsでは %APPDATA% または %LOCALAPPDATA% 内のアプリ別フォルダーが一般的です。macOSでは通常 ~/Library/Application Support/ にあります。これらの親フォルダーを直接削除しないでください。Androidのアプリ専用データは通常、一般的なファイル管理アプリから読み取れません。ストレージを消去する前に、サブスクリプションとローカル設定を外部にバックアップしたことを確認してください。

ログは時刻を手がかりに調べ、最後の1行だけで判断しない

  • Windows：Win + R を押し、eventvwr.msc と入力して、「Windowsログ」→「アプリケーション」を開きます。終了時刻の前後にある Application Error、.NET Runtime、Windows Error Reporting の記録を探し、障害が発生したアプリ、モジュール、例外コードを保存します。
  • macOS：「コンソール」を開いてクラッシュレポートを確認します。~/Library/Logs/DiagnosticReports/ も確認してください。例外の種類、終了理由、クラッシュしたスレッドの情報を保存します。
  • Android：ADBの操作に慣れている場合は、USBデバッグを有効にして次のコマンドで起動時のログを収集します。バッファーを消去すると古いログが削除されるため、過去の記録を残す必要がない場合にのみ実行してください。
adb logcat -c
adb logcat -v time > clash-startup.txt
# この状態でスマートフォンのクライアントを起動し、終了を再現したら Ctrl+C で記録を停止

Androidのログでは FATAL EXCEPTION、AndroidRuntime、Fatal signal、アプリのパッケージ名を重点的に検索します。デスクトップでは permission denied、address already in use、panic、設定の解析エラーを確認してください。最後に表示される「接続に失敗しました」は、コアの終了に伴うメッセージにすぎない場合があります。根本原因はその前に記録されていることが多いため、ログをさかのぼって確認しましょう。

最小構成でYAMLとコアの互換性を確認する

サブスクリプションの更新、オーバーライドの変更、コアのアップグレード後に問題が発生した場合は、まず直近の変更を元に戻します。サブスクリプションの元ファイル、クライアントのオーバーライド、実際に読み込まれる最終設定は別物です。サブスクリプション編集画面の内容だけでなく、コアが実際に読み込んだ設定を確認してください。

まず構文と読み込みを確認する

以下のコマンドはmihomo向けです。コアと設定ファイルが同じテストフォルダーにある前提の例です。実際に存在するコアのファイルを使ってください。他のClash系では、まず -h のヘルプを確認し、すべての引数が同じだと決めつけないでください。

# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

# macOS / Linux
./mihomo -v
./mihomo -t -f ./config.yaml

-t は設定を読み込めるかをテストするためのもので、ノードへの接続確認や実際の起動の代わりにはなりません。YAMLの行番号エラーが出た場合は、インデントにタブが混入していないか、コロンの後にスペースがあるか、プロキシグループが参照する名前が存在するかを確認します。パーサーはエラー箇所の次の行で停止することもあるため、エラー行の前後も確認してください。

サブスクリプション、ルールセット、TUNを切り分ける

バックアップを取ったうえで、専用のテストフォルダーに次の最小構成を作成します。コアが起動するかを確かめるための設定で、すべての通信を直接接続し、プロキシノードは含みません。テスト中は元のクライアントを終了し、コアを2つ同時に起動しないでください。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false
dns:
  enable: false
rules:
  - MATCH,DIRECT

.\mihomo.exe -f .\minimal.yaml または ./mihomo -f ./minimal.yaml でフォアグラウンド起動し、動作が続くか確認してから Ctrl + C で終了します。ここでは一般的な 7890 と区別するため 17890 を使っていますが、このポートが必ず空いているとは限りません。テスト中はシステムプロキシやTUNを有効にしないでください。

  1. 最小構成でも終了する場合：コアのアーキテクチャ、ファイルの権限、実行フォルダー、システムのクラッシュ記録を優先して確認します。
  2. 最小構成で正常に動作する場合：ノード、プロキシグループ、ルールセット、DNSを順番に戻し、最後にTUNを有効にします。
  3. 特定の設定を戻したときだけ問題が起きる場合：その設定と正確なエラー情報を保存し、必要なコア機能と設定形式を確認します。

Clash、Clash Meta、mihomoで利用できる設定機能は完全には同じではありません。フィールドが無視されたり、読み込みを拒否されたりすると、動作が変わることがあります。YAMLの構文が正しいだけでは、現在のコアで使える設定とは限りません。proxy-providers と rule-providers については、ファイルのパス、リモートからの応答内容、読み書き権限も確認してください。

プロキシポート、コントロールポート、残存プロセスを確認する

address already in use は、待ち受けアドレスがすでに使われていることを示します。プロキシ用の待ち受けポートとコントロールインターフェースのポートは用途が異なります。たとえば mixed-port: 7890 はHTTP/SOCKSプロキシ用、external-controller: 127.0.0.1:9090 は管理インターフェース用です。これらは一般的な設定例なので、実際に動作している設定を確認してください。

Windowsでポートの使用プロセスを調べる

netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"
# 例：PID 1234 のプロセス名を確認
tasklist /FI "PID eq 1234"

ローカルアドレスと LISTENING の状態を確認し、PIDからプロセスを特定します。リモートアドレスに同じポート番号があるだけで、ローカルの競合と誤認しないようにしてください。前回の実行で残ったコアなら、クライアントまたは該当サービスから正常に終了します。別のアプリが使っている場合は、どのサービスを待ち受けさせるか判断し、正体の分からないシステムプロセスを安易に終了しないでください。

macOSで待ち受けポートを調べる

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

プロキシポートを 7890 から 17890 に変更する場合、ブラウザー拡張、コマンドラインの環境変数、システムプロキシも合わせて変更する必要があります。クライアントの管理インターフェースを変更する際は、画面側が自動で追従するか確認してください。コントロールポートが一致しないと、コア自体は動作していても「コアに接続できません」と表示されることがあります。

Windows・macOS・Android別に実行環境を修復する

Windows：障害が発生したモジュールを確認してからランタイムを対処する

ログが画面側のランタイムを示している場合は、そのクライアントのリリースノートに従って必要な依存コンポーネントをインストールします。たとえばWebView2を使うクライアントには、利用可能なWebView2 Runtimeが必要ですが、すべてのClashクライアントが依存するわけではありません。DLLの不足が確認できた場合、またはリリースノートに明記されている場合に限り、該当するVisual C++ランタイムを導入してください。出所不明のサイトからDLLを単体でダウンロードし、システムフォルダーに置くのは避けましょう。

Windows セキュリティの「ウイルスと脅威の防止」→「保護の履歴」を開き、コアが隔離されていないか確認します。インストーラーの入手元と警告内容を確認し、セキュリティ保護を長期間無効にして解決しようとしないでください。画面の初期化や設定の解析に通常、管理者権限は必要ありません。サービスのインストールやTUNの有効化など、明確に権限が必要な操作だけ管理者として実行します。

macOS：Intel・Appleシリコン・権限の警告を切り分ける

「このMacについて」でプロセッサを確認します。Appleシリコン搭載Macではarm64版、Intelプロセッサ搭載Macではx64版を選びます。macOSの「開けません」というセキュリティ警告と、起動後のクラッシュは別の問題です。信頼できる配布元のアプリであれば、「システム設定」→「プライバシーとセキュリティ」に表示される案内に従ってください。すべてのアプリから一括してセキュリティ属性を削除するのは避けましょう。

レポートに dyld、動的ライブラリの欠落、アーキテクチャの不一致が記録されている場合は、別のMacからコアをコピーするのではなく、OSに合った完全なアプリケーションを再インストールします。TUN関連の問題では、まず他のVPNを終了し、クライアントのドキュメントに従って補助サービスの許可状態を確認してください。

Android：起動時のクラッシュとバックグラウンド切断を分けて調べる

adb shell getprop ro.product.cpu.abilist で、端末が対応するABIを確認できます。arm64、armv7、汎用インストーラーのどれを使うかは、端末とクライアントの対応状況に合わせて選んでください。APKのABI、アプリが必要とする最低Androidバージョン、端末の実際のOSバージョンが一致している必要があります。

まず「設定」→「アプリ」→クライアント→「ストレージとキャッシュ」でキャッシュを消去します。ストレージを消去するとローカル設定が削除されるため、バックアップ後に行ってください。画面ロックから数分後にVPNが切断される場合は、バッテリー最適化とバックグラウンド実行の権限を確認します。アイコンをタップしてすぐにクラッシュ表示が出る問題とは原因が異なります。通常、Androidでは同じユーザーで有効にできるVPNサービスは1つだけです。テスト時は他のVPNアプリを切断してください。

コアの再インストールとバージョンのロールバック手順

最小構成でも起動しない、コアファイルが見つからない、またはアップグレード後に同じ終了が安定して再現する場合に限り、再インストールやバージョンのロールバックを行います。コアを適当に差し替えると、クライアントとコントロールインターフェースの互換性が損なわれることがあります。任意のmihomo実行ファイルをリネームしてインストールフォルダーに入れる方法は避けてください。

  1. 現状を保存：ログと設定のバックアップを取り、現在のクライアントとコアのバージョンを記録します。唯一の正常なインストーラーを上書きしないでください。
  2. 関連プロセスを停止：通知領域のアプリを終了し、クライアントの手順に従って補助サービスを停止して、待ち受けポートが解放されたことを確認します。
  3. 対応するコンポーネントを復元：まずクライアント内蔵のコア復元機能を使います。画面を起動できない場合は、同じバージョンの完全なインストーラーを再実行します。
  4. 古いデータを分離：バックアップ後、アプリ専用のデータフォルダーの名前を変更して残し、クライアントに新しいフォルダーを作成させます。システム全体のアプリデータフォルダーは削除しないでください。
  5. 空の環境で先に確認：古いオーバーライドを読み込まず、自動起動とTUNを無効にした状態で、画面とコアが安定して動作するか確認します。
  6. 設定を1つずつ戻す：まず動作確認済みの設定を1つ読み込み、DNS、ルールセット、TUNの順に戻します。変更は一度に1項目にとどめ、その都度結果を記録してください。

新しいデータフォルダーでも新バージョンで同じ問題が再現し、同じ端末で前のバージョンが正常に動作する場合は、バージョンの回帰を疑う根拠になります。ロールバックには、信頼できる配布元から入手したシステムのアーキテクチャに合うインストーラーを使ってください。新しいバージョンのデータ形式を旧版で読み込めるかにも注意し、必要に応じて別々のデータフォルダーでテストします。

修復後の確認と不具合報告のチェックリスト

修復後は、ウィンドウが開くかどうかだけで判断しないでください。画面が開いたまま維持されること、コアの初期化が完了すること、プロキシポートが待ち受けを開始すること、設定を読み込めること、ルールモードが使えることを順に確認し、最後にTUNを有効にします。各段階でログに起動や終了が繰り返し記録されていないことを確かめてから次へ進みます。

  • 正常に終了してからもう一度起動し、正しい設定が読み込まれるか確認します。
  • システムを再起動した後にサービスの権限とプロキシ設定を確認し、手動起動のときだけ正常な状態を除外します。
  • クライアントのバージョン、コアのバージョン、OSのバージョンとアーキテクチャを記載し、直近のアップデートや設定変更を明記します。
  • 個人情報を伏せたログ、クラッシュ時刻、最短の再現手順を添え、最小構成でも終了するかを記載します。

対処の順序を一貫させましょう。まず終了した箇所を特定してログを確認し、設定を元に戻してからポートを調べ、実行環境を確認して最後に対応コンポーネントを再インストールします。この手順なら既存のルールを保ちながら、「Clashを開くとすぐクラッシュする」問題を再現・特定できる状態に絞り込めます。