トラブル対処 読了時間：約12分

Clashが起動直後にクラッシュする原因と対処法｜6つの原因を解説

設定ファイルの構文エラー、ポート競合、コアの欠落、権限不足、システムコンポーネント不足、キャッシュ破損の原因別に、各OSでの確認方法と起動復旧の手順を解説します。

まずウィンドウとコアの終了を切り分ける

Clashを起動した直後にクラッシュしても、すぐに再インストールする必要はありません。デスクトップクライアントは通常、GUI、プロキシコア、バックグラウンドサービスで構成されています。ウィンドウが消えても、トレイに最小化されただけの場合があります。画面は開くのに接続できない場合は、コアの起動に失敗している可能性もあります。それぞれ確認すべきログは異なります。

  1. まず、Windowsの通知領域またはmacOSのメニューバーにアイコンが残っていないか確認します。アイコンからメインウィンドウを開いて正常に表示される場合、起動時のクラッシュではありません。
  2. Windowsでは「タスク マネージャー」→「詳細」でクライアントとコアのプロセスを確認します。macOSでは「アクティビティモニタ」でアプリ名を検索してください。ウィンドウの有無だけでプロセスの状態を判断しないようにしましょう。
  3. 起動操作を行った正確な時刻を記録し、その前後1分間のアプリログとシステムのクラッシュ記録を保存します。まず最初のエラーを確認してください。最後に表示される「プロセス終了」は、原因ではなく結果であることがほとんどです。

以下では、6つの原因を順に確認します。表のエラーメッセージは問題を特定する手がかりであり、すべてのクライアントで同じ文言が表示されるとは限りません。

手がかりまず確認する項目
yaml: line …設定ファイルの構文とクライアント側の上書き設定
address already in useプロキシポート、コントロールポート、DNS待ち受けポートの競合
no such file / exec format errorコアのパスとCPUアーキテクチャ
permission deniedデータフォルダー、実行権限、TUNサービス
DLLまたは共有ライブラリの不足使用中のクライアントが必要とするシステムコンポーネント
アップデート後に画面を復元できないウィンドウの状態、フロントエンドのキャッシュ、設定データベース

1. 設定ファイルの構文エラー

サブスクリプションの更新、上書きファイルの編集、設定の切り替え後に問題が起きた場合は、まず設定を確認します。YAMLのインデントにはスペースを使い、同じ階層の項目をそろえてください。コロンの後のスペースや、リスト項目のハイフンが抜けていると、解析に失敗することがあります。また、mihomo向けの設定を古いClashコアに読み込ませているケースもよくあります。YAMLの構文が正しくても、設定項目やルール機能に互換性がない場合があります。

実際に読み込まれているファイルを特定する

クライアントによっては、サブスクリプション、上書き設定、画面上の設定を統合して実行用の設定を作成します。そのため、サブスクリプションの元ファイルを解析できても、最終的な設定で起動できるとは限りません。ログに記録された設定ファイルのパスを確認してください。画面を開ける場合は、設定またはプロファイル管理からデータフォルダー、実行用設定、ログの場所を探します。ボタン名はクライアントによって異なるため、インストールフォルダー内にあるというだけで config.yaml を上書きしないでください。

Windows上のmihomoを例に説明します。実際にコアがあるフォルダーでPowerShellを開いてください。設定ファイルが C:\ClashData\config.yaml にあり、データファイルも同じフォルダーにある場合は、次のコマンドを実行します。

.\mihomo.exe -t -d "C:\ClashData" -f "C:\ClashData\config.yaml"

-t は設定をテストして終了するオプション、-f は設定ファイル、-d は作業フォルダーを指定します。パスは実際の環境に合わせ、クライアントに付属するコアを使用してください。このコマンドをすべてのGUIクライアントの起動オプションとして使うことはできません。Geoデータベースやルールプロバイダーのファイルが不足している場合もテストに失敗するため、エラー内容を確認して原因を絞り込みましょう。

  • ログで20行目が指摘されている場合は、19行目も確認してください。直前の行で引用符が閉じていないと、次の行でエラーとして表示されることがあります。
  • 「ポリシーが見つからない」と表示された場合は、ルールの接続先とポリシーグループ名を、空白や大文字・小文字も含めて照合してください。
  • 未対応のルールタイプが表示された場合は、クライアント名だけで判断せず、実際に使用しているコアを確認してください。

復旧時は、まず最近追加した上書き設定を無効にするか、最後に正常動作した設定に戻します。設定項目の用途が分からない場合は設定項目のドキュメントを参照してください。DNSやルール設定をまとめて削除するのは避けましょう。

2. ポート競合によるコアの終了

ポート競合は、プロキシクライアントを複数起動した場合、古いコアが終了していない場合、バックグラウンドサービスと手動起動したコアが重複した場合などに発生します。7890は混合プロキシポート、9090はコントロールインターフェースでよく使われますが、すべてのクライアントで固定されているわけではありません。ログに記録された実際のアドレスとポートを確認してください。

ポートの使用元を調べる。正体不明のプロセスは終了しない

Windowsでは、ターミナルで次のコマンドを実行します。一番右の列がプロセスID（PID）です。

netstat -ano | findstr :7890
netstat -ano | findstr :9090

ローカルアドレスに対応するポートのうち、状態が LISTENING の記録を確認します。「タスク マネージャー」→「詳細」でPIDを照合し、プログラムを特定してください。macOSでは次のコマンドを使用できます。

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

Linuxでは ss -lntp でTCPの待ち受け状態を確認できます。他のユーザーのプロセス情報を確認するには、適切な権限が必要な場合があります。DNSのUDP待ち受けに関するエラーの場合は、TCPだけでなくUDPも確認してください。

  1. 使用中のプロセスが古いクライアントだと確認できたら、クライアントの終了メニューから正常に停止し、バックグラウンドサービスが動作し続けていないか確認します。
  2. 2つの設定を同時に使う必要がある場合は、プロキシとコントロールインターフェースにそれぞれ異なるポートを割り当てます。たとえば、片方の混合ポートを 7893 に変更します。
  3. 変更後は、システムプロキシとブラウザーの手動プロキシ設定も合わせて変更してください。コアが新しいポートで待ち受けているのに、アプリが古いポートへ接続していると、「起動は成功するがインターネットに接続できない」状態になります。

ログにソケットへのアクセス拒否が記録され、待ち受け中のプロセスが見つからない場合は、Windowsの予約済みポート範囲やセキュリティポリシーも確認してください。バインドに失敗する原因をすべて、他のプログラムによるポート使用と決めつけないようにしましょう。

3. コアの欠落またはアーキテクチャの不一致

GUIが表示された後にコアの起動失敗が通知される場合、アーカイブの展開漏れ、メインプログラムだけのコピー、アップデート後も古いパスを参照していること、セキュリティソフトによるコアの隔離などが原因として考えられます。クライアントによってはコアを別途ダウンロードするため、ダウンロードの中断でGUIは正常でもコアが欠落した状態になることがあります。

  • no such file or directory：ログに記載された完全なパスと、ファイルの有無を確認します。Linuxでは、必要な動的ローダーが存在しない場合にも表示されることがあります。
  • exec format error：まずアーキテクチャとファイル形式を確認します。たとえば、ARM64版のLinuxコアをx86_64版のLinuxで使っていないか確認してください。
  • 「指定されたファイルが見つかりません」：主プログラムではなく、コアまたはその依存ファイルが見つからない可能性があります。

開発元の公式配布元から、OSとアーキテクチャに合った完全なインストーラーを入手し、クライアントの修復または再インストール手順に従って復旧します。macOSでは「Appleメニュー」→「このMacについて」でチップの種類を確認できます。Windowsでは「設定」→「システム」→「バージョン情報」でシステムの種類を確認してください。Linuxでは uname -m を使い、x86_64 と aarch64 を判別できます。

システムに隔離の記録がある場合は、ファイルの配布元と検出理由を確認してから、システムの案内に従って対処してください。セキュリティ保護をすべて無効にしたり、出所不明のファイル共有サイトから同名の実行ファイルだけを入手して置き換えたりしないでください。クライアントとコアは連携して動作するため、無関係なバージョンを組み合わせると、起動エラーの原因が分かりにくくなることがあります。

4. 権限不足またはTUNサービスの異常

通常のシステムプロキシを使うだけなら、クライアントを常に管理者権限で実行する必要はありません。一方、TUNデバイスの作成、ルートの変更、バックグラウンドサービスのインストールには追加の権限が必要な場合があります。TUNを無効にすると起動できる場合は、サブスクリプションを何度も変更するのではなく、サービスの状態、仮想ネットワークアダプター、権限を確認しましょう。

OSごとに必要な権限を絞り込む

  • Windows：重複して起動しているインスタンスをすべて終了し、クライアントのサービス管理画面でサービスのインストール状態と起動可否を確認します。サービスのインストールや修復に管理者権限が必要な場合に限り、管理者としての認証を行ってください。アプリのデータフォルダーが読み取り専用になっていないかも確認します。
  • macOS：アプリを「アプリケーション」フォルダーに移動してから起動します。ヘルパーツールの認証やシステムのセキュリティ警告が表示された場合は、開発元と配布元を確認してから、画面の案内に従って必要な操作を許可してください。セキュリティ属性を一括削除するコマンドでエラーを回避しないでください。
  • Linux：ターミナルから起動して標準エラーを確認します。信頼できる配布元から入手したコアに実行権限がない場合は、そのファイルに実行権限を設定してください。TUNについては、/dev/net/tun が存在するか、サービスに必要な権限があるかを別途確認します。
  • Android：VPNモードを初めて有効にするときは、システムの接続要求を許可してください。同じユーザーまたはプロファイルでは、通常、同時に有効にできるVPNは1つです。他のVPNアプリを停止してから接続を試してください。

「設定ファイルに書き込めない」場合と「ネットワークアダプターを作成できない」場合も区別しましょう。前者は、設定ファイル、データベース、ログフォルダーへの書き込みエラーとして記録されることが一般的です。後者はTUNの初期化時に発生します。GUI全体を常に管理者権限で実行しても、フォルダーのアクセス権の問題は解決しません。

5. システムコンポーネントまたは実行環境の不足

アプリのログが生成される前に、起動ツールがDLL、WebView、共有ライブラリの不足を通知する場合は、まずGUIの実行環境を確認します。Clashクライアントによって使用するGUI技術は異なります。Electron、Tauri、Flutterでは依存コンポーネントが異なるため、別のクライアント向け手順に従ってランタイムをすべてインストールしないでください。

  1. Windows：通知に表示されたコンポーネント名を正確に記録します。WebView2が不足していると明記されている場合は、Microsoftの公式配布元から該当するランタイムをインストールしてください。Microsoft Visual C++ランタイムが不足している場合は、プロジェクトの要件に合ったアーキテクチャを選びます。DLLだけをダウンロードしてシステムフォルダーにコピーしないでください。
  2. macOS：「コンソール」→「クラッシュレポート」で該当するプロセスを探し、macOSのバージョンがサポート対象外か、アーキテクチャの読み込みに失敗していないか確認します。必要な最小OSバージョンは、クライアントの現行バージョンのリリースノートを参照してください。
  3. Linux：ターミナルから起動して、不足している共有ライブラリを確認します。信頼できるプログラムの場合は ldd で動的依存関係を確認できます。ディストリビューションに適合するパッケージを優先し、システムのパッケージマネージャーで依存関係を補ってください。システムのコアライブラリを手動で置き換えないでください。

Windowsでは Win + R を押し、perfmon /rel と入力すると信頼性モニターが開き、同じ時刻のアプリケーション障害を確認できます。障害が発生したモジュール名と例外コードは記録しておきましょう。ただし、システムDLLの名前が表示されたからといって、そのDLLが破損しているとは限りません。

6. キャッシュまたはアプリの状態データの破損

アップデートの中断、突然の電源断、バージョンをまたいだ移行などにより、ウィンドウの状態、GUIのキャッシュ、ローカルデータベースが破損することがあります。ウィンドウが真っ白になる、起動直後に終了する、前回の画面を復元するたびにクラッシュするといった症状が見られます。キャッシュの削除は後の手順として検討し、最初に行うのは避けてください。

デスクトップ版：バックアップ後に作り直す。フォルダー全体は削除しない

  1. GUI、コア、バックグラウンドサービスを終了し、データを書き込んでいるプロセスが残っていないことを確認します。
  2. プロジェクトのドキュメントまたはログで実際のデータフォルダーを特定し、フォルダー全体をバックアップします。名前の似たクライアントでも、データの保存先が共通とは限りません。
  3. まず、クライアントにキャッシュ削除や画面リセット機能があれば使用します。画面を開けない場合は、ドキュメントにキャッシュまたはウィンドウ状態ファイルと明記されているものだけを、削除せずに名前を変更して保存します。
  4. アプリのデータフォルダー全体を再作成する必要がある場合は、サブスクリプションとカスタムルールのバックアップを確認します。その後、フォルダー名を変更してバックアップとして残し、新しいデータを作成させてください。
  5. 初期状態で起動できたら、サブスクリプションと上書き設定を1つずつ戻します。古いフォルダー全体をすぐにコピーし直さないでください。

Windowsのアプリデータは %APPDATA% または %LOCALAPPDATA%、macOSでは ~/Library/Application Support/、Linuxでは ~/.config/ に保存されることがあります。ただし、いずれも上位フォルダーの例であり、そのまま削除してよい対象ではありません。

Android：キャッシュ削除とデータ削除を区別する

Androidの「設定」→「アプリ」→該当するクライアント→「ストレージとキャッシュ」で、まず「キャッシュを削除」を試します。メーカーによって項目名は多少異なる場合があります。「ストレージを消去」または「データを消去」を実行するとアプリのデータがリセットされ、サブスクリプション、設定、認証状態も失われる可能性があります。必ずバックアップしてから行ってください。インストーラーのアーキテクチャが合わない場合や、OSのバージョン要件を満たしていない場合は、キャッシュを消去しても解決しません。

復旧後は順番に動作を確認する

ウィンドウが開くことは、最初の確認にすぎません。「画面の安定性」「コアの待ち受け」「プロキシ接続」「TUN」の順に復旧させ、各段階の確認後に次へ進みましょう。複数の設定を一度に有効にすると、原因を特定しにくくなります。

  • クライアントを2回続けて起動・終了し、新たなクラッシュ記録がないことを確認します。
  • 正常動作を確認済みの設定を使い、TUNは一時的に無効にします。ログに読み込み失敗やポートのバインドエラーが残っていないか確認してください。
  • システムプロキシを有効にし、設定したポートが現在コアの待ち受けポートと一致していることを確認してから、アプリのネットワーク接続をテストします。
  • 最後にTUN、上書きルール、自動更新を元に戻します。問題が再発した段階に応じて、該当する機能を調べてください。

それでもクラッシュする場合は、OSのバージョン、CPUアーキテクチャ、クライアントとコアのバージョン、インストーラーの種類、発生日時、個人情報を伏せたログを添えて問題を報告してください。アップデート後、設定のインポート後、TUNの有効化後など、発生したタイミングも記載します。「起動できない」の一言より、これらの情報があるほうがメンテナーによる再現と調査につながります。再インストールする場合は、ダウンロードページでOSとアーキテクチャに合ったものを確認してください。設定の復元方法は入門ガイドを参照できます。

クライアントをダウンロード