1. ウィンドウの終了・コアの停止・接続失敗を切り分ける

Clashを起動したあとにウィンドウが消えても、原因は一つとは限りません。デスクトップクライアントは通常、GUI、プロキシコア、必要に応じてサービスやTUNコンポーネントで構成されています。GUIが終了してもコアがバックグラウンドで動作している場合があり、コアの起動に失敗しても設定画面が表示されたままのことがあります。まず、どの部分が終了したのかを確認してから、設定を変更するかインストールファイルを修復するか判断しましょう。

見えている症状まず確認する項目次に行うこと
ウィンドウは閉じたが、タスクトレイのアイコンは残っているウィンドウを閉じたときにタスクトレイへ最小化する設定かタスクトレイから再度開き、プロセスが動作中か確認する
ウィンドウとメインプロセスが同時に消えるGUIのログ、システムのクラッシュレポートエラー発生時刻と障害モジュールを記録する
GUIは正常だが、コアが何度も再起動する設定の解析、待ち受けポート、コアファイルコア終了前に記録された最初のエラーを確認する
プロセスは動作中だが、Webサイトを開けないシステムプロキシ、DNS、プロキシグループの選択接続障害として対処し、すぐに再インストールしない

Windowsでは Ctrl + Shift + Esc を押してタスクマネージャーを開き、「詳細」タブでクライアントとコアのプロセスを確認します。macOSでは「アクティビティモニタ」で該当するプロセスを確認できます。プロセス名はクライアントのパッケージ方法によって異なるため、clash.exe があるかどうかだけで判断しないでください。

2. ログの保存先を確認し、終了直前のエラー前後を残す

GUIを開ける場合

まずクライアントの「ログ」画面と、設定内にある「設定ディレクトリ」「データディレクトリ」「ログディレクトリ」などの項目を確認します。メニュー構成はクライアントごとに異なり、インストール先がデータ保存先とは限りません。ディレクトリを開いたら更新日時で並べ替え、今回の起動時刻に対応するファイルを確認します。GUIのログとコアのログの両方を保存してください。

ログレベルは一時的に info から debug に変更し、問題を一度再現したらすぐ元に戻します。デバッグログにはアクセス先のドメイン名、ノード名、ローカルパスが含まれることがあります。問い合わせに添付する前に、個人情報をマスキングしてください。コアがまだ起動していない場合、コアのログレベルを上げてもGUIのクラッシュレポートは作成されません。

ウィンドウをまったく開けない場合

最後の「起動に失敗しました」という一文だけでなく、最初のエラーの前後約20行をコピーしてください。たとえば yaml: line 18 は設定の解析、address already in use は待ち受けポートの競合、permission denied は権限または実行制限を示します。最後に表示される再試行のメッセージは、それ以前のエラーによって発生している場合がほとんどです。

3. YAML構文エラー：実際に読み込まれる設定を検証する

サブスクリプションの更新、ルールの貼り付け、Profileの切り替え後にクラッシュが起きた場合は、まずコアに渡される設定を確認します。クライアントはサブスクリプション、ローカルオーバーライド、実行時パラメーターを統合し、別のファイルを生成する場合があります。ダウンロードしたサブスクリプションの原文だけを調べても、統合時に生じた問題を見落とすことがあります。

よくある4種類のエラーを確認する

  1. インデント：YAMLのインデントにはスペースを使い、Tabは使いません。同じ階層の項目は位置をそろえ、リスト項目のハイフンの後にはスペースを入れます。
  2. 記号：キー名の後には半角コロンを使います。ノード名やパスワードに特殊文字が含まれる場合は、YAMLのルールに従って引用符で囲んでください。
  3. 参照先：ルールが参照するプロキシグループや、プロキシグループが参照するノード・他のグループの名前は、定義と完全に一致させます。全角の括弧や末尾の空白でも、別の名前として扱われることがあります。
  4. コアとの互換性：ClashとClash Meta（現名称：mihomo）では、対応するフィールドやプロトコルの範囲が異なります。設定の構文が正しくても、現在のコアがすべての設定項目に対応しているとは限りません。

クライアントがmihomoを使用している場合は、同じコアプログラムで設定をテストできます。以下はWindows PowerShellでの例です。まずコアがあるディレクトリに移動し、確認するファイルをカレントディレクトリに config-check.yaml という名前でコピーします。コマンド内のプログラム名は、実際のファイル名に合わせてください。

New-Item -ItemType Directory -Force .\check-data | Out-Null
.\mihomo.exe -t -d ".\check-data" -f ".\config-check.yaml"
$LASTEXITCODE

-t は設定のテスト、-f は設定ファイルの指定、-d はテスト用データディレクトリの指定に使います。テスト時にGeoIP、GeoSite、ルールプロバイダーなどのリソースが必要になることもあります。リソース不足を示すエラーが出た場合は、YAMLのインデントエラーと混同せず、別途対処してください。終了コードが 0 なら今回のテストは成功ですが、ポートが使用可能であること、ノードに接続できること、TUNを起動できることまで保証するものではありません。

4. ポート競合：待ち受け中のプロセスを確認してからポートを変更する

一般的な設定では、HTTPまたは混合プロキシに 7890、SOCKSに 7891、コントローラーに 9090 が使われますが、これらは固定の標準値ではありません。現在の設定にある port、socks-port、mixed-port、external-controller を確認してください。DNSの待ち受けポートが競合することもあります。

Windows：待ち受けポートとPIDを確認する

Get-NetTCPConnection -State Listen -LocalPort 7890,7891,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

2つ目のコマンドにある 1234 はPIDの例です。実行前に、1つ目のコマンドの出力にある OwningProcess の値に置き換えてください。結果が表示されない場合、確認したTCPポートがその時点で待ち受け状態ではないことを示すだけで、UDPポートの競合までは否定できません。

macOS：指定したTCPポートの待ち受けを確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN
  1. ポートを使用しているのが別のクライアントインスタンスなら、まずタスクトレイのメニューから正常に終了し、スタートアップ項目が重複していないか確認してください。
  2. ポートを使用しているのが別のアプリなら、ローカルのテスト用設定で mixed-port を一時的に 17890 に変更し、再起動して確認します。
  3. ポートを変更したら、システムプロキシとブラウザー独自のプロキシ設定も確認してください。コアのポートだけ変更しても、システムプロキシの接続先が古い 127.0.0.1:7890 のままになっていることがあります。

正体の分からないシステムプロセスを強制終了したり、エラーを解消するためにコントローラーを外部公開アドレスで待ち受けさせたりしないでください。ローカル専用のコントローラーは、たとえば 127.0.0.1:9090 のようにループバックアドレスへバインドします。

5. コアファイルの不足・アーキテクチャの不一致・TUNの権限

ログに「ファイルが見つかりません」「実行できません」「アクセスが拒否されました」と表示された場合は、ログに記載されたコアのフルパスを確認してください。プログラムの更新中断、セキュリティソフトによる隔離、実行ファイルだけをコピーして関連ファイルをコピーし忘れたことなどが原因で、GUIは起動してもコアが動かない場合があります。

TUNには通常、追加のシステム権限やサービスが必要です。必要な条件はプラットフォームとクライアントの実装によって異なります。まずTUNの自動有効化をオフにし、通常のプロキシモードでコアが安定して動作することを確認してから、クライアントのサービスインストールまたは権限設定の画面でTUNを再設定してください。通常のプロキシが使えるようになっても、TUNのDNSやルーティング設定が正しいとは限りません。

6. 設定を切り戻す：旧データを分離して確認する

再インストール後もクラッシュする場合、新しいプログラムが古いデータディレクトリを読み込んでいることがあります。切り戻しでは、すべてのデータをすぐに削除するのではなく、元に戻せる比較用の環境を作り、元の設定に問題があるかを切り分けます。

手順に沿って進める切り戻し

  1. 関連プロセスを終了：クライアントを正常に終了し、データを書き込み続けているコアが残っていないことを確認します。バックグラウンドサービスがある場合は、クライアントに用意されたサービス管理画面から操作してください。
  2. データディレクトリ全体をバックアップ：Profile、サブスクリプション情報、ローカルオーバーライド、ルールファイル、GUI設定を保存します。バックアップ名は clash-backup-2026-08-06 のように付けられます。サブスクリプションの認証情報が含まれる場合があるため、非公開の場所に保存してください。
  3. 古いディレクトリを分離：実際のデータ保存先を確認してから、名前を変更して保存します。ポータブルモードや独立したデータディレクトリに対応しているクライアントもあります。テスト環境はクライアントの説明に従って作成し、別のクライアントの起動オプションを流用しないでください。
  4. 最小構成を作成：古いサブスクリプションの自動インポート、オーバーライドの自動適用、TUNを無効にし、まず設定の解析とローカルの待ち受けだけを確認します。
  5. 項目ごとに復元：サブスクリプション、プロキシグループ、ルール、ローカルオーバーライド、TUNの順に戻します。一度に一項目だけ復元し、その都度再起動して結果を記録してください。

以下の設定は、記載されたフィールドに対応するClashまたはmihomoコアのテスト用です。混合ポートに 17890 を使用し、すべての通信を直接接続するため、プロキシノードは含まれていません。元のサブスクリプションを上書きせず、独立したローカルファイルとして保存してください。このポートも使用中の場合は、前述の手順で空いているポートに変更します。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

この設定で確認できるのは基本的な起動だけで、プロキシノードの有効性は検証できません。この設定で安定して動作し、元の設定に戻すとすぐエラーが出る場合は、原因を元の設定、オーバーライド、依存リソースに絞り込めます。この設定でも起動できない場合は、インストールファイル、GUIの実行環境、システムのクラッシュ記録を確認してください。

7. 復旧の確認と問い合わせに必要な情報

一度起動に成功しただけでは、トラブルシューティングは完了していません。クライアントを続けて3回再起動し、同じエラーがログに再び出ないことを確認します。次にサブスクリプションを更新し、ローカルでの修正がリモート設定に上書きされないことを確かめてください。最後に、実際の利用状況に合わせてシステムプロキシとTUNを戻し、それぞれ個別にテストします。同時に有効にすると、原因を特定しにくくなります。

問い合わせる場合は、クライアントとコアの完全なバージョン番号、OSのバージョンとアーキテクチャ、障害発生時刻、最初のエラー前後のログ、最小構成で起動できるかを共有してください。サブスクリプションURL、ノードのパスワード、コントローラーのキー、個人名を含むディレクトリ名はマスキングします。設定項目の階層、エラー行番号、例外の種類は残すと、原因を特定しやすくなります。

確認は、終了した箇所の特定、最初のエラーの確認、実際の設定のテスト、ポートの確認、コアの確認、古いデータの分離の順に進めます。再インストールが必要な場合は、まずダウンロードページで対応プラットフォームを確認してください。フィールドやルールの関係は上級設定、基本設定は入門ガイドをご覧ください。