ClashのGUIクライアントは通常、画面を表示するプログラム、Clashまたはmihomoコア、設定ファイル、データベース、システムプロキシを制御するモジュールで構成されています。ダブルクリックしてもウィンドウが開かない、表示直後に消える、トレイアイコンだけ一瞬現れる、設定を読み込むと毎回強制終了する、といった症状は似ていますが、実際に問題が起きている起動段階は異なる場合があります。調査では上書きインストールや連打を繰り返すのではなく、まず発生範囲を確認し、設定、権限、コア、実行環境を順番に切り分けます。
まずクライアントがどの段階で終了するか確認する
起動処理は大きく、画面プロセスの読み込み、クライアント設定の読み込み、プロキシコアの起動、システムプロキシまたはTUNネットワーク設定の適用という4段階に分けられます。どの段階で終了するかを特定できれば、確認すべき範囲を大幅に絞れます。
クリックしてもウィンドウがまったく表示されない
まず、プログラムがバックグラウンドですでに動作していないか、ファイルが完全か、実行権限があるか、画面表示に必要な依存コンポーネントを読み込めるかを確認します。タスクマネージャーやシステムモニターでプロセスが表示された直後に終了する場合も、通常はこの段階の問題です。
ウィンドウが表示された直後に閉じる
よくある原因は、クライアント設定ファイルの破損、ウィンドウ状態の記録異常、画面表示用ランタイムの不足、または旧バージョンのデータと新バージョンの非互換です。この時点では、コアがまだ起動していない可能性があります。
設定を読み込んでから強制終了する
YAMLの構文、設定項目の互換性、ルールセットファイル、GeoIPやGeoSiteのデータ、サブスクリプションから生成された設定が現在のコアの対応範囲を超えていないかを重点的に確認します。
TUNを有効にすると終了する
管理者権限、サービスコンポーネント、仮想ネットワークインターフェース、ポートの使用状況、セキュリティポリシーを重点的に確認します。システムプロキシモードでは動作し、TUNを有効にした時だけ失敗するなら、まずノードやプロキシルールを変更する必要はありません。
「画面が終了する」場合と「コアが終了する」場合も区別してください。クライアントによってはウィンドウを閉じてもトレイプロセスが残り、別のクライアントではコアの起動失敗時に通知を表示しながら画面自体は開けることがあります。タスク管理ツールでGUIプロセスとmihomo、clashなどのコアプロセスを個別に監視し、どのプロセスが先に終了したかを記録します。エラーダイアログのタイトルよりも、この順序のほうが診断に役立ちます。
破損した設定と非対応項目を切り分ける
クライアントが以前は正常に動作しており、サブスクリプションの更新、ルールの編集、コアの切り替え後に強制終了するようになったなら、まず設定を確認します。YAMLはインデント、コロン、リスト形式の影響を受けやすい形式です。余分なタブ、インデントが正しくないルール項目、特殊文字を含むのに引用符で囲んでいない値などが、解析失敗の原因になることがあります。
空のデータディレクトリで動作を確認する
- クライアントを完全に終了し、画面プロセスとコアプロセスがすべて終了していることを確認します。
- クライアントのデータディレクトリを探し、日付を付けたバックアップ用ディレクトリ名に変更します。
- クライアントを再起動し、プログラムに初期設定を自動生成させます。
- サブスクリプション、上書きスクリプト、ルールセット、旧データベースは一時的に復元せず、まず基本画面が安定して動作するかだけを確認します。
空の環境で起動できるなら、プログラム本体と主要なシステム依存関係には通常問題がなく、原因は旧データディレクトリにあります。次はすべてを一度にコピーせず、種類ごとに移行してください。推奨順序は、クライアントの基本設定、単一の設定ファイル、サブスクリプション履歴、ルールセット、その他のキャッシュです。各項目を移行するたびに再起動すれば、問題の範囲を特定できます。
YAML設定を単独でテストする
mihomoでは、ターミナルから設定をテストできます。ディストリビューションによって実行ファイル名や対応パラメータが異なる場合があるため、まずヘルプコマンドで確認してください。一般的なテスト形式は次のとおりです。
mihomo -t -f config.yaml旧版のClashコアでも、同じテストパラメータが使われることがあります。
clash -t -f config.yamlテストに合格しても、現在のコアで設定を解析できることが確認できるだけで、すべてのプロキシノードに接続できるとは限りません。未知の項目、重複した名前、ルールセットが見つからない、ポート形式が正しくないといった報告が出たら、最初のエラーから修正して再テストします。後続のエラーは、最初の構造上の問題による連鎖結果に過ぎない場合があります。
別のクライアントから設定を移行する場合は、コアの系統も確認します。mihomo独自のプロキシプロトコル、ルールプロバイダー、DNS項目、トラフィック嗅覚オプションは、古い公式Clashコアでは認識できないことがあります。逆に、一部のGUIクライアントは設定を独自に加工するため、実行時設定を別のクライアントへそのままコピーすると専用項目が混入する可能性があります。対象クライアントが実際に呼び出すコアのバージョンを基準にしてください。
ディレクトリ権限、システムプロキシ、TUNの競合を確認する
権限の問題は、単純な「アクセス拒否」だけではありません。画面は開けても、設定の保存、コアの置き換え、ログの作成、バックグラウンドサービスの起動ができず、未処理の例外によって終了することがあります。ポータブル版を読み取り専用の場所に置く、別アカウントからデータディレクトリをコピーする、企業端末の実行制限、安全ソフトによる子プロセスの起動ブロックなどでも、似た症状が起こります。
Windowsでの確認手順
- クライアントを、現在のアカウントで読み書きできる一般的なディレクトリに置きます。圧縮ファイルの内部から直接実行しないでください。
- タスクマネージャーで、同名の画面プロセス、コアプロセス、旧サービスが残っていないか確認します。残ったプロセスを終了してから再起動し、データベースや待ち受けポートの競合を避けます。
- 通常のシステムプロキシモードでは、常に管理者として実行する必要はありません。TUN、サービスのインストール、ネットワークインターフェースの変更には、権限昇格が必要な場合があります。これらの操作を行う時だけ、クライアントの案内に従って許可してください。
- 別のプロキシツールがシステムプロキシを継続的に書き換えていないか確認します。複数のクライアントが同じプロキシポートやシステムプロキシ設定を同時に制御すると、起動ループが発生することがあります。
macOSとLinuxでの確認手順
- アプリまたは実行ファイルが実行を許可された場所にあり、現在のアカウントに必要な読み取り、書き込み、実行権限があることを確認します。
- ダウンロードしたファイルに表示されるシステムのセキュリティ警告を確認し、アプリの入手元を確認したうえでシステム設定から許可します。問題を回避するためにディレクトリ全体の権限を無条件に緩めないでください。
- TUNを使用する場合は、クライアントが必要とする補助サービスが正しくインストールされ、旧サービスが削除済みのプログラムパスを参照していないことを確認します。
- Linuxのデスクトップ環境では、一度ターミナルから起動し、動的リンクライブラリ、表示サービス、権限、設定パスに関する出力を確認します。
TUNモードでは仮想ネットワークインターフェースを作成または制御し、ルーティングとDNSの経路を変更します。TUNを無効にすると安定して動作するなら、まず通常のシステムプロキシモードを使い、TUNは別途対応します。他のVPN、仮想マシンのネットワーク、コンテナネットワーク、古いプロキシサービスが同じインターフェースやルートを使用していないか確認してください。同じテスト中にDNS、ルート、コア、設定を同時に変更すると、どの変更が有効だったのか判断できなくなります。
コアファイル、アーキテクチャ、起動パラメータを確認する
GUIクライアントのプロキシコアが、メインプログラムに常に組み込まれているとは限りません。初回起動や更新時にコアファイルを展開するクライアント、複数のコアを選べるクライアント、バックグラウンドサービス経由でコアを呼び出すクライアントもあります。画面は正常でも、コアプロセスを起動した直後に終了する場合は、次の項目を確認します。
ファイルが存在するか
クライアント設定に記録されているコアのパスが、現在も有効か確認します。インストール先の移動、キャッシュの削除、更新失敗の後に、存在しないファイルを指すことがあります。
プロセッサアーキテクチャが一致しているか
x86-64、ARM64、その他のアーキテクチャ用コアは、自由に置き換えられません。システム上でGUIが起動できても、別途ダウンロードしたコアが現在のデバイスに適しているとは限りません。
コアを単独で実行できるか
ターミナルでコアのバージョンまたはヘルプコマンドを実行すると、「コア自体を読み込めない」のか「クライアントからパラメータを渡した後に失敗する」のかを切り分けられます。
待ち受けポートが使用されていないか
HTTP、SOCKS、Mixed、コントロールポート、DNSポートを別のプロセスが使用していると、コアの起動に失敗し、ログにバインドエラーが記録されることがあります。
クライアントに「コアを更新」や「コアを切り替え」機能がある場合、更新後の強制終了はバージョンの組み合わせが合っていないことが原因かもしれません。たとえば、画面側が新しいコアへ変更済みの起動パラメータを渡している、または古いクライアントが新しいコアの生成した状態データを理解できない、といったケースです。この場合は、そのクライアントが明確に対応しているコアのバージョンを使用し、バージョン番号の大小だけで互換性を判断しないでください。
コア単独ではバージョン情報を表示できるのに、設定を読み込むとすぐ終了する場合は、設定とデータファイルに戻って確認します。メイン設定だけでなく、MMDB、GeoSite、ルールプロバイダーのキャッシュ、外部UIのパスにも注意してください。設定が存在しない、または読み取れないファイルを参照している場合、ログに具体的なパスが示されることが多いです。
画面用ランタイムとシステムコンポーネントを修復する
空のデータディレクトリでも起動できず、コアが動く前にGUIプロセスが終了するなら、画面表示技術の依存関係を確認します。Clashクライアントごとに採用しているデスクトップフレームワークが異なり、必要なコンポーネントも同じではありません。特定のランタイムだけをすべてのクライアントに共通する解決策と考えないでください。
Windowsでよくあるコンポーネント
画面表示にシステムのWebViewコンポーネントを必要とするクライアントや、Microsoft Visual C++ランタイムを必要とするネイティブモジュールがあります。システムコンポーネントが破損していたり古かったりすると、白画面、ウィンドウの瞬時終了、動的リンクライブラリの読み込み失敗などが発生します。イベントビューアーやターミナルのエラーに表示されたモジュール名を確認し、クライアントのアーキテクチャに合うシステムコンポーネントをインストールしてから、システムを再起動してください。
古いディレクトリに新しいバージョンを直接上書きすると、新旧のモジュールが同時に残ることもあります。データをバックアップしたうえで旧プログラムファイルを削除し、新しいバージョンを独立したディレクトリへ完全に展開またはインストールする方法が安全です。異なるアーキテクチャや配布系列のファイルを同じディレクトリに混在させないでください。
macOSとLinuxでよくあるコンポーネント
macOSでは、アプリ本体の読み込み失敗、補助サービスの認証失敗、コアのアーキテクチャエラーを区別する必要があります。「コンソール」アプリでクラッシュレポートを確認し、例外の種類、終了理由、最後に読み込まれたモジュールに注目します。Appleシリコン搭載デバイスでは、ネイティブARM64版をダウンロードしたか、クライアントが互換変換環境を必要としているかも確認してください。
Linuxでは、ターミナルから起動するのが最も直接的です。共有ライブラリが不足していると表示されたら、使用中のディストリビューションのパッケージ管理方法で依存関係を補い、別のディストリビューションから単一のライブラリファイルをコピーするのは避けます。Wayland、X11、デスクトップトレイの実装、サンドボックス権限が画面に影響する場合もありますが、通常それだけでmihomoコア自体が実行不能になることはありません。GUIとコアは分けてテストしてください。
ログとシステム記録から最初の有効なエラーを見つける
強制終了の調査で重要なのは、ログを大量に集めることではなく、終了前に現れた原因を説明できる最初のエラーを見つけることです。ログ末尾には「プロセス終了」や「接続切断」しかない場合があり、真の原因は前の数行に出ていることがよくあります。
- 障害が発生した正確な時刻を、分単位で記録します。
- 古いログを消去または名前変更してから、クライアントを一度だけ起動し、過去の情報による混乱を減らします。
- クライアントログ、コアログ、システムのクラッシュ記録を同時に確認します。
- 最初に現れたerror、fatal、panic、permission denied、address already in use、parse failedの付近から読み始めます。
- ログに記録されたファイルパス、ポート番号、項目名、モジュール名を使って、一項目ずつ検証します。
Windowsでは、イベントビューアーの「アプリケーション」記録で障害モジュールを確認できます。macOSではコンソールのクラッシュレポートを確認し、Linuxではターミナルの標準出力、ユーザーログ、システムログから手がかりを探します。クライアントでログレベルを設定できる場合は、再現前だけdebugに一時的に上げても構いません。ただし調査後は通常のレベルに戻し、大量のログを長期間生成しないようにします。
よくあるログメッセージと対処の方向性は、次のように整理できます。
- 設定の解析に失敗：YAMLの行番号とその上にある構造を確認し、現在のコアで再テストします。
- 対応していない項目：設定の入手元、コアの種類、バージョンを確認し、エラー項目を削除するだけで未知の設定を使い続けないでください。
- ポートのバインドに失敗：そのポートを使用しているプロセスを探し、用途を確認したうえで待ち受けポートを変更します。
- アクセスが拒否された：ディスク全体の権限を広げるのではなく、具体的なパス、ファイル所有者、ディレクトリ権限、サービスの認証を確認します。
- データベースまたはキャッシュの破損：バックアップ後に該当キャッシュを移動し、クライアントに再生成させます。サブスクリプション元と手動設定を同時に削除しないでください。
- コアが予期せず終了：同じ設定を使ってターミナルからコアを単独起動し、設定、データファイル、クライアントのパラメータのどれが原因か確認します。
変更を最小限にして復旧する
再利用しやすい復旧手順は、残ったプロセスを終了し、データディレクトリをバックアップし、空の環境で起動し、現在のコアで設定をテストし、最後にポート、権限、TUNサービスを確認する流れです。空の環境でも強制終了する場合は、プログラムファイル、システムコンポーネント、アーキテクチャの互換性を確認します。この順序なら、ユーザーデータの問題と実行環境の問題を分離でき、無意味な再インストールを減らせます。
旧データを復元するときは、一度に1つの設定だけを取り込み、まずルールモードまたは直接接続ポリシーで画面の安定性を確認します。コアが継続して動作することを確認してから、ノード接続、DNS解決、ルールプロバイダー、サブスクリプションの自動更新をテストします。古いサブスクリプションが原因のクラッシュなら、破損したキャッシュファイルをコピーし続けるのではなく、サブスクリプションを再取得してください。
クライアントプロジェクトへ問題を報告する場合は、クライアントのバージョン、コアのバージョン、OSのバージョン、プロセッサアーキテクチャ、再現手順、個人情報を伏せたエラーログを提示するとよいでしょう。設定に含まれるサブスクリプションURL、プロキシサーバーのアドレス、認証情報、個人用パスは事前に加工してください。「画面を開くと終了する」「特定の設定を読み込むと終了する」「TUNを有効にすると終了する」と具体的に書くほうが、「Clashが強制終了する」とだけ書くより有効な判断につながります。