トラブルシューティング 読了目安 12 分

Clashクライアントが起動直後に落ちるときの対処法：実行環境の確認から設定復元まで

画面のクラッシュとコアの起動失敗を切り分け、システムアーキテクチャ、実行依存関係、権限、設定ファイルを順に確認し、ログとバックアップを残して設定を復元する方法を解説します。

まず切り分ける：ウィンドウのクラッシュ、バックグラウンド動作、コアの終了

「Clashが開かない」と検索する前に、消えたのがウィンドウだけなのか、プロセス全体なのかを確認しましょう。Clash系クライアントは画面表示、サブスクリプションの取り込み、設定管理を担当し、ClashまたはClash Meta（mihomo）コアはプロキシ接続、ルール照合、DNS処理を担当します。画面は正常に表示されてもコアだけ起動できない場合があり、反対にコアは動作したまま画面だけ閉じることもあります。必要なログや修復箇所は状況によって異なります。

一度起動したら約10秒待ち、システムトレイ、アクティビティモニタ、またはタスクマネージャーを確認します。プログラムを連続してダブルクリックしないでください。既存のインスタンス、バックグラウンドサービス、新しい起動要求が混在すると、ポートの競合や終了時刻を判断しにくくなります。

確認できた現象優先して確認する項目残しておく証拠
ウィンドウは消えるが、トレイメニューは開けるトレイに格納する設定、起動時の最小化設定トレイの状態、画面プロセスが継続して存在するか
ウィンドウと画面プロセスの両方が終了するアーキテクチャ、画面の実行依存関係、アプリデータシステムクラッシュ記録、画面のログ
画面は開くが、コアの起動失敗が表示される設定の解析、リソースパス、待ち受けポートコア終了前に出た最初の具体的なエラー
TUNを有効にした後だけエラーまたは終了が発生するサービス権限、仮想ネットワークアダプター、ルーティングの競合TUN有効化前後のログの違い
画面とコアは正常だが、ウェブページにアクセスできないプロキシの適用、DNS、ノード、ルール接続記録。これだけでクラッシュとは判断しない

操作前にバックアップ：設定、ログ、バージョン情報を残す

いきなりアンインストールすると、壊れたユーザーデータが残ったり、書き出していないサブスクリプションや上書き設定が削除されたりすることがあります。「再インストールしても落ちる」からといって、インストーラーの問題とは限りません。まずクライアントの正式名称とバージョン、コアのバージョン、OSのバージョンとアーキテクチャを控え、クライアント更新、サブスクリプション更新、設定変更のどの後に問題が起きたかを記録します。クライアントのバージョンとコアのバージョンは別情報なので、「最新版」とだけ書かないでください。

バックアップに含めるもの

  • 元の設定とサブスクリプション：ローカルのYAML、サブスクリプションの記録、正常に動作していた旧設定を保存します。サブスクリプションURLには通常アクセス情報が含まれるため、パスワードと同じように管理してください。
  • 上書きとマージのロジック：ルール追加、設定マージの断片、スクリプトを別々に保存します。サブスクリプションの原文が正しくても、最終的に生成される実行設定が正しいとは限りません。
  • クライアント設定：システムプロキシ、TUN、サービスモード、ローカル待ち受けポート、コントロールインターフェースの設定を記録し、必要に応じてスクリーンショットも残します。
  • 障害ログ：起動前後およそ1分間の記録を保存します。コアのログだけでなく、画面プロセスのエラーも確認してください。

画面を開ける場合は、クライアントに用意された設定フォルダーを開く、ログフォルダーを開く、またはエクスポートする機能を優先して使います。クライアントによってメニュー名は統一されていません。完全に起動できない場合は、そのクライアントのドキュメントでデータフォルダーを確認してください。Windowsの %APPDATA% と %LOCALAPPDATA%、macOSの ~/Library/Application Support/ は、いずれも上位フォルダーの候補にすぎません。フォルダー全体を削除したり、インストール先をそのままユーザーデータフォルダーと見なしたりしないでください。

コピーする前にクライアントを正常終了し、関連プロセスがファイルへ書き込んでいないことを確認します。サービスモードを使っている場合は、クライアントが対応するサービス管理画面から該当サービスも停止してください。プロセス名だけで曖昧に判定し、タスクを一括終了しないでください。ログを共有する場合は、別途マスキング済みのコピーを作成し、サブスクリプションのトークン、ノードのパスワード、コントロールインターフェースのキー、個人用ドメイン、ユーザー名を隠します。

実行環境の確認：システムアーキテクチャ、依存関係、完全な展開

ファイル名ではなく、デバイスのアーキテクチャに合うパッケージを選ぶ

Windows 11では「設定」→「システム」→「システム情報」で「システムの種類」を確認できます。IntelまたはAMDの一般的なデスクトップPCは通常x64を選び、ARMデバイスではプロジェクトがARM64パッケージを提供しているか確認してください。macOSではAppleメニューの「このMacについて」で「チップ」または「プロセッサ」を確認し、Apple SiliconとIntelを区別します。Linuxでは uname -m でアーキテクチャを確認できます。一般的な出力の x86_64 と aarch64 は、それぞれx64とARM64に対応します。

プロセッサのアーキテクチャが一致していても十分ではありません。OSの最低バージョン、Linuxのランタイムライブラリのバージョン、デスクトップ環境にも条件がある場合があります。Exec format error と表示されたら、まず実行ファイルのアーキテクチャを確認します。GLIBC_… not found と明確に表示された場合は、ディストリビューションとプログラムのビルド要件を確認し、システムの中核ランタイムを手動で置き換えないでください。Androidのインストールパッケージは、端末が対応するABIに合わせて選びます。「64ビットプロセッサ」だけを根拠に、古い端末で任意のARM64アプリが動くと判断することはできません。

依存関係は、使用するクライアントの実装に合わせる必要がある

  • WindowsのWebView画面：WebView2に依存するクライアントでランタイムの欠落や初期化失敗が表示された場合は、プロジェクトのドキュメントに従って該当ランタイムを修復します。Electronクライアントは別の依存関係を使うため、WebView2のインストールを一般的な解決策と考えないでください。
  • DLLの欠落：エラーまたはプロジェクトの説明がVisual C++ランタイムなど特定のコンポーネントを明示している場合に限り、対応するアーキテクチャのランタイムを修復します。出所不明の単体DLLをダウンロードしてシステムフォルダーへ入れないでください。
  • ポータブル版：まず現在のユーザーが読み書きできるローカルフォルダーへ完全に展開し、その展開先から起動します。圧縮ファイルのプレビューから直接実行すると、コア、リソース、隣接ファイルが見つからない場合があります。
  • システムによるブロック：Windowsの「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」、またはmacOSの「システム設定」→「プライバシーとセキュリティ」に表示される関連通知を確認し、ブロックされた具体的なファイルと理由を特定します。システムの保護機能全体を無効にしないでください。

Windowsでは Win + R で eventvwr.msc を入力し、「Windowsログ」→「アプリケーション」で起動時刻付近のエラーを探します。障害が発生したアプリケーション、障害モジュール、例外コードを記録してください。モジュール情報は画面の描画異常とコアの終了を切り分ける手掛かりになりますが、モジュール名だけで原因を特定することはできません。

権限とポートの確認：まずTUNを無効にして範囲を絞る

TUNを有効にした後、またはサービスをインストールした後に問題が起きた場合は、まず画面でTUNを無効にしてから終了し、もう一度起動します。TUNはネットワーク層で通信を取り込むため、通常はシステム権限、サービス、仮想ネットワークアダプターが関係します。システムプロキシは、システムプロキシ設定に従うアプリへプロキシの入口を提供するもので、両者は同じスイッチではありません。通常の画面起動やローカルの高位ポートでの待ち受けに、管理者権限を常時使う必要はありません。

TUNを無効にすると起動できる場合は、クライアントのサービス状態、システムのVPN権限、ほかのVPNや仮想ネットワークアダプターソフトとの競合を確認します。Windowsのサービスモードは、使用中のクライアントのドキュメントに従って修復してください。Androidでは、VPN許可や別アプリによるVPNスロットの占有を、アプリ画面のクラッシュとは分けて対処します。仮想ネットワークアダプターをすべて削除したり、データフォルダー全体に全ユーザーの書き込み権限を与えたりしないでください。

ローカルポート7890を例に待ち受けの競合を確認する

ログに address already in use またはWindowsの Only one usage of each socket address が出た場合は、まず具体的に競合しているアドレスとポートを特定します。以下のコマンドは設定で実際に 7890 を使用している場合だけ適用してください。コントロールインターフェースやDNSポートを指している場合は、ログに記録されたポートを調べます。

# Windows PowerShell：7890を待ち受けているプロセスを検索
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：TCPを待ち受けているプロセスを検索
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受け一覧とプロセス情報を確認
ss -ltnp

出力されたプロセス識別子から占有しているプロセスを確認します。Linuxでは、一般ユーザーが他ユーザーのプロセス情報をすべて確認できない場合があります。占有者が別のプロキシクライアントなら、まず正常終了させます。現在のクライアントの残ったサービスなら、対応する管理画面から処理してください。ポートを変更する場合は、ブラウザーやシステムプロキシの入口も同時に変更します。そうしないと、コアが復旧してもアプリは古いポートへ接続し続けます。

設定の確認：コアが実際に読み込んでいるYAMLを検証する

画面は開くのにコアが繰り返し終了する場合は、最後に表示された「起動失敗」だけでなく、ログにある最初の具体的なエラーを探します。よくある原因は、YAMLのインデントエラー、存在しないプロキシグループを指すルール、コアが対応していないノード種別、リソースファイルの欠落です。Clashとmihomoでは対応するフィールドの範囲が異なります。あるクライアントがサブスクリプションを取り込めても、呼び出されたコアがすべてのフィールドを実行できるとは限りません。

まずマージ結果を確認し、その後にサブスクリプション原文を確認する

  1. 現在選択されている設定ファイルを確認し、ログまたはクライアントの機能から実際に実行されている設定を特定します。
  2. 上書き、スクリプト、ルール追加、プロキシプロバイダーが有効になっているか確認し、最近追加した処理を一時的に無効にします。
  3. YAMLがスペースでインデントされているか確認し、プロキシグループ名、ルールの対象、プロキシ参照が完全に一致しているか照合します。
  4. サブスクリプションのダウンロード失敗と設定解析失敗を切り分けます。ログイン画面やエラーページを返すURLを、YAMLとしてコアに解析させることはできません。

mihomoを使用し、単体の実行ファイルを起動できる場合は、まず設定テストを行えます。以下のコマンドは、現在のフォルダーに mihomo という実行ファイルと diagnostic.yaml があることを前提としています。Windowsではファイル名を mihomo.exe とします。実際の名前は使用中のクライアントに付属するファイルに合わせてください。テストのためにクライアントのコアを勝手に置き換えないでください。

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

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

-v はコアのバージョンを記録するため、-t は設定をテストするために使います。設定が相対パス、プロキシプロバイダー、ルールプロバイダーを参照する場合は、コアのヘルプに従って -d で対応する作業フォルダーも指定してください。そうしないと、リソースの場所が異なることで別のエラーが発生する場合があります。テストに合格しても、そのテスト環境で設定を確認できたことを示すだけです。ポートをバインドできること、TUNの権限があること、リモートノードへ接続できることまでは保証されません。

最小限の直接接続設定でサブスクリプションの問題を切り分ける

以下はmihomo用の診断例で、プロキシノードを含まず、プロキシ出口も提供しません。バックアップを作成し、システムプロキシとTUNを無効にし、7890 が使用されていないことを確認したうえで、単独のテストファイルとして使ってください。サブスクリプションの元ファイルに上書きしないでください。クライアントが自動追加する上書き設定も一時的に無効にします。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

最小設定で起動できて元の設定で起動できない場合は、プロキシノード、プロキシグループ、ルール、DNS、上書き設定を1つずつ戻し、最初に失敗した変更を特定します。最小設定でも同じ依存関係、権限、ポートのエラーが出る場合は、実行環境の確認に戻ります。Fake-IPの切り替えやDNSサーバーの変更など、ネットワークパラメーターで画面プロセスのクラッシュを直そうとしないでください。

設定の復元：古いデータを隔離し、いきなり全削除しない

実行環境を確認し、ログがローカル設定の読み込み失敗を示している場合、または更新後に古いユーザーデータがあるときだけ異常が起きる場合は、データフォルダーを隔離してテストできます。目的は、障害が古いデータとともに発生するかを判断することであり、元の設定を永久に捨てることではありません。

  1. バックアップを完了して終了：クライアントと対応するサービスを停止し、残ったプロセスが書き込みを続けていないことを確認します。
  2. 正しいフォルダーを確認：現在のクライアントのドキュメントに従ってデータフォルダーを特定します。独立した設定フォルダーやポータブルモードに対応している場合は、プロジェクトが提供する隔離方法を優先してください。
  3. 元のフォルダーを残す：確認済みのデータフォルダーの名前を変更します。バックアップ名には client-data.backup-20260819 などを使い、削除しないでください。
  4. 初期設定で起動：クライアントに新しいユーザーデータを作成させ、まずはTUNを有効にせず、サブスクリプションも取り込まず、設定全体も復元しません。
  5. 段階的に復元：まず正常動作が確認できている設定を取り込み、コアの起動を確認します。次に必要なルールと上書き設定を戻し、最後にシステムプロキシまたはTUNを有効にします。

空のデータフォルダーでもクラッシュする場合、古い設定だけが原因ではない可能性が高いため、システムクラッシュログとバージョンの互換条件を見直します。ある項目を戻した後に再び失敗した場合は、完全な再インストールよりも、その前後の差分を残すほうが原因を特定しやすくなります。旧フォルダーを戻すときは、まずプログラムを終了し、今回作成した新しいフォルダーを残したうえで元の名前に戻します。2つのデータベースやキャッシュを直接混在させないでください。

復元後の確認と障害報告チェックリスト

ウィンドウが再び表示されるのは最初の一歩にすぎません。まず画面とコアが安定して動作しているかを確認し、次にローカルの待ち受けポートを確認して、最後にプロキシ通信をテストします。以下では 127.0.0.1:7890 で待ち受けるHTTP混合ポートを例に、アクセス権があり現在のネットワークから到達できるHTTPSアドレスを選んで検証します。例に使うアドレスの到達性は、利用地域のネットワーク環境にも左右されます。

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# Windows：curl.exeを明示的に呼び出す
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

ここでの10秒の接続タイムアウトと20秒の総タイムアウトは診断上限であり、遅延性能を示すものではありません。200 Connection established だけでは、対象へのリクエストが成功したとは判断できません。続くTLSとHTTPの結果も確認してください。前述の最小設定を使っている場合、通信は直接接続されます。実際のプロキシ出口を確認するには、有効なノードと対応するルールを戻し、接続記録で適用されたポリシーを確認します。

フィードバックを送るときは再現に必要な情報を残す

  • クライアント名、完全なバージョン番号、コアの -v 出力、OSのバージョンとアーキテクチャ。
  • インストールパッケージの種類、ポータブルモードまたはサービスモードの使用有無、TUNの有効・無効。
  • 再現手順。例：「初期設定では正常起動 → 設定の取り込みも正常 → 上書き設定を有効にするとコアが終了」。
  • 障害が発生した時刻、最初の具体的なエラー、終了コード、マスキング済みの前後のログ。
  • 初期データフォルダーのテスト、最小設定のテスト、ポート確認でそれぞれどのような結果になったか。

問題が一度のクライアント更新後にだけ発生した場合は、上記の証拠を添えて該当プロジェクトへ報告します。別のクライアントを選ぶ前に、クライアント選定ガイドでプラットフォームとコアの対応範囲を確認できます。設定に関する問題は設定リファレンスと照合しながら項目ごとに確認してください。再現手順を確立し、特定の段階まで切り分けるほうが、何度も再インストールするより検証可能な解決策につながります。

Clashをダウンロード