ウィンドウの終了・画面のクラッシュ・コアの停止を切り分ける

「Clashを起動するとすぐ落ちる」場合、実際にはウィンドウがトレイに隠れている、GUIプロセスがクラッシュしている、画面は開いたままコアの起動に失敗している、という3つの可能性があります。設定ミスやポート競合でまず影響を受けるのは通常コアで、クライアント全体が終了するとは限りません。まず問題の箇所を切り分け、設定を調べるか実行環境を修復するか判断しましょう。

  1. バックグラウンドプロセスを確認します。Windowsでは Ctrl + Shift + Esc でタスクマネージャーを開きます。macOSでは「アクティビティモニタ」、Linuxでは ps -ef を使います。画面が消えてもクライアントやコアが動作している場合は、通知領域やメニューバー、マルチディスプレイ上のウィンドウ位置を確認してください。
  2. 再現条件を記録します。初回インストール直後、アップデート後、サブスクリプションの読み込み後、TUNの有効化後のどのタイミングで失敗するかを切り分けます。OSのバージョン、CPUアーキテクチャ、クライアントとコアのバージョンも記録し、「最新版」とだけ書くのは避けてください。
  3. 一度完全に終了します。トレイメニューからクライアントを終了し、関連プロセスが停止したことを確認してから再度起動します。古いプロセスがバックグラウンドでポートを使用している場合があります。何度も起動を繰り返すと、原因の切り分けが難しくなります。

ログの確認：起動時刻と最初のエラーを記録する

クライアントログ、コアログ、システムのクラッシュレポートでは、確認できる内容が異なります。クライアントログではGUIの初期化、コアのパス、サービスへの接続を確認します。コアログではYAML、待ち受けポート、ルールの読み込みを調べます。システムレポートはランタイムや共有ライブラリ、プロセスの異常終了の特定に役立ちます。

OSごとに起動失敗の記録を確認する

  • Windows：Win + R を押して eventvwr.msc と入力し、「Windowsログ」→「アプリケーション」を開きます。障害が起きた時刻の「Application Error」などを確認し、障害が発生したアプリケーション名、障害モジュール、例外コードを記録してください。クライアントのデータは %APPDATA% または %LOCALAPPDATA% に保存されることがあります。ポータブル版ではアプリのフォルダー内の場合もあるため、クライアントのドキュメントと起動ログを確認してください。
  • macOS：「コンソール」でクラッシュレポートを確認します。~/Library/Logs/DiagnosticReports/ を調べる方法もあります。プロセス名、例外の種類、終了理由を記録してください。同じ時刻に出力された別アプリのレポートを、代理クライアントのログと取り違えないようにしましょう。
  • Linux：インストールされた実際の実行ファイルをターミナルから起動し、標準エラー出力を確認します。systemdを使用している場合は、journalctl --user -b --since "10 minutes ago" を実行します。クラッシュ情報の収集が有効なら、coredumpctl list で該当プロセスを探します。収集の仕組みはディストリビューションによって異なり、利用できない場合もあります。

エラーのキーワードから次の確認項目を絞る

ログの内容まず確認する項目確認方法
yaml: line、unmarshalインデント、フィールドの型、設定のマージ同じコアで実際に読み込むファイルをテストする
address already in useポートを別のプロセスが使用中ログに記録されたポートに対応するPIDを確認する
permission denied実行権限、ディレクトリへの書き込み権限、TUNの権限対象がファイルかネットワークデバイスかを切り分ける
no such file、exec format errorコアのパス、ファイルの欠落、CPUアーキテクチャファイルの有無とアーキテクチャの適合性を確認する
WebView、共有ライブラリ、障害モジュールの記録GUIの実行環境クライアントが使用するGUI技術に応じて依存関係を確認する

ログ末尾の「コアが停止しました」は、原因ではなく結果を示していることがほとんどです。今回の起動ログをさかのぼり、最初に記録された具体的なエラーを探して前後約30行を保存してください。共有する前に、サブスクリプションURL、認証情報、コントロールインターフェースのキー、個人名を含むディレクトリ名を伏せます。プロキシノードのアドレスも機密情報にあたる場合があります。

設定の復元：実際に読み込まれるYAMLを検証する

サブスクリプションの更新直後に起動できなくなった場合は、設定の変更をまず疑います。配信されたファイルが、そのままコアに読み込まれる最終設定とは限りません。クライアントがオーバーライド、スクリプト、ルール断片、TUN設定を重ねていることがあります。ダウンロードしたファイルだけを検証しても、マージ処理で発生したエラーは見つけられません。

  1. クライアントを完全に終了し、現在のサブスクリプション、オーバーライドファイル、クライアント設定をバックアップします。データディレクトリをいきなり削除しないでください。
  2. 最後に起動できた設定に戻し、新しく追加したオーバーライドやスクリプトを一時的に無効にします。画面を開けない場合は、バックアップを取ったうえでクライアントのドキュメントに従い、該当する設定ファイルを復元してください。内部データベースの構造を推測して操作しないでください。
  3. クライアントに同梱されているコアで、最終設定をテストします。旧版Clashとmihomoでは対応するプロトコルやフィールドが異なります。別のコアでテストに成功しても、問題がないとは判断できません。
  4. 起動できる状態に戻ったら、サブスクリプション更新、ルールセット、カスタムDNS、TUNを1つずつ有効にし、どの変更で問題が再発するかを確認します。

mihomoを例に説明します。ターミナルでコアのあるディレクトリに移動し、確認する設定のコピーをそのディレクトリ内の config.yaml として保存してから、該当するコマンドを実行します。設定から相対パスを参照している場合は、-d で正しいデータディレクトリを指定し、関連ファイルの配置もそろえてください。

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

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

-t は設定をテストするオプションです。リモートのルールセット、ノードへの接続、実行時の権限まで検証できるわけではありません。ログに行番号が表示された場合は、その直前の行も確認してください。コロンの抜け、Tabによるインデント、リスト階層の誤りなどがあると、パーサーが次の行で初めてエラーを報告することがあります。

最小構成の設定で問題を切り分ける

以下の設定は、コアが基本的な起動を完了できるか確認するためのものです。プロキシノードは含まず、すべての通信を直接接続します。独立したテスト用ファイルとして保存し、確認後は元の設定に戻してください。プロキシとして使えるサブスクリプション設定ではありません。

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

rules:
  - MATCH,DIRECT

最小構成で起動でき、元の設定では失敗する場合は、ノードのプロトコル、ポリシーグループの参照先、ルールセットのパス、オーバーライドの結果を確認します。最小構成でも起動できない場合は、ポート、コアファイル、システム環境を引き続き調べてください。例にある 17890 が使用中でないことも確認が必要です。

ポート競合：待ち受けプロセスから使用元を特定する

一般的な設定では、混合プロキシに 7890、コントロールインターフェースに 9090 を使うことがありますが、すべてのクライアントで固定された値ではありません。ログと最終設定を確認してください。HTTP、SOCKS、DNSの待ち受けポートも、それぞれ競合する可能性があります。

Windowsで待ち受けPIDを確認する

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

Get-Process -Id 4321

2つ目のコマンドにある 4321 は例示用のPIDです。1つ目のコマンドで表示された値に置き換えてください。古いクライアントが見つかった場合は、まずトレイメニューから終了します。別のサービスが見つかった場合は、用途を確認してから対処し、正体のわからないシステムプロセスを終了しないでください。詳細情報の参照に権限が必要な場合は、必要に応じて管理者としてターミナルを実行します。

macOS・Linuxでポートを確認する

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

# Linux
ss -lntp

これらのコマンドはTCPの待ち受けを対象とします。DNSのUDP待ち受けでエラーが発生している場合は、lsof -nP -iUDP:1053 またはLinuxの ss -lnup も使い、1053 を実際のポート番号に置き換えてください。ポートを変更したら、システムプロキシ、ブラウザー拡張機能、コマンドラインのプロキシ環境変数も更新します。変更しないと「クライアントは起動するのにアプリがネットにつながらない」状態になることがあります。

コアファイルとTUNの権限：失敗対象に応じて修復する

アップデートの中断、セキュリティソフトによるファイルの隔離、インストール先への書き込み不可などが原因で、クライアントがコアを見つけられないことがあります。まずログで実際のコアのパスを確認し、ファイルが存在するか調べてください。任意の場所から入手したバイナリをリネームして置き換えるのは避けてください。クライアントが特定の起動オプションやコントロールインターフェースの動作、関連リソースに依存している場合があります。

  • Windows：「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」で該当する記録があるか確認します。入手元と警告の内容を確認してから対処し、保護機能全体を無効にしないでください。インストーラー版は元のインストーラーで修復し、ポータブル版は現在のユーザーが書き込める新しいディレクトリに展開して試します。
  • macOS：インストーラーがAppleシリコンまたはIntelのどちらに対応しているか確認します。システムにアプリのブロックが明示された場合は、入手元を確認したうえで「システム設定」→「プライバシーとセキュリティ」にある関連項目を確認してください。ダウンロードフォルダー全体からセキュリティ属性を一括で削除しないでください。
  • Linux：uname -m でマシンのアーキテクチャを、file ./mihomo でコアのファイル形式を確認します。ファイルが存在するのに実行できない場合は、権限不足と決めつけず、動的ローダー、マウントオプション、アーキテクチャも確認してください。

Linuxでは、対象ファイルが信頼でき、実行ビットが不足していることを確認した場合に限り、そのファイルに chmod u+x ./mihomo を実行してください。ユーザーディレクトリ全体に再帰的な広い権限を設定したり、データディレクトリの権限エラーを回避するためにGUIをrootで常用したりしないでください。

TUNを有効にしたときの問題を切り分ける

まずTUNを無効にし、コアとローカルのプロキシポートだけを起動します。通常のプロキシモードでは動作し、TUNを有効にするとデバイス作成、ルーティング、権限のエラーが出る場合は、仮想ネットワークインターフェースまたは特権サービスに原因を絞れます。Windowsクライアントでは通常、管理者権限またはサービスモードを使います。macOSでは補助プログラムのインストールが必要な場合があります。Linuxでは /dev/net/tun やネットワーク管理権限が関係することがあります。具体的なインストール方法はクライアントのバージョンによって異なるため、そのバージョンのサービス設定手順に従ってください。

複数のツールがデフォルトルートを変更するのを避けるため、ほかのVPNや別のTUNクライアントも一時停止してテストします。修復後は通常のプロキシを先に確認し、その後TUNを有効にしてください。DNS、ルート、サブスクリプションを同時に変更すると、何が有効だったのか特定しにくくなります。

GUIの実行環境：WebView2、Electron、システムコンポーネント

コアは単独で起動できるのにウィンドウが真っ白になる、またはすぐ消える場合は、GUIの実行環境を確認します。クライアントによって採用している技術は異なり、Windowsクライアントの一部はWebView2に依存し、ElectronやFlutterを使うものもあります。「Clash」と表示されるからといってWebView2を一律に再インストールしても、実際の問題と無関係な場合があります。

  1. クライアントの依存関係を確認します。該当バージョンのインストール手順とシステム要件を確認してください。WebView2に依存するWindowsクライアントでは、「設定」→「アプリ」→「インストールされているアプリ」で「Microsoft Edge WebView2 Runtime」を検索します。項目の場所はWindowsのバージョンによって異なることがあります。
  2. 公式の手順で修復します。Microsoft公式配布のWebView2 Runtimeインストーラーを使って修復または再インストールし、クライアントを再起動してください。不明なサイトからDLLを単体でダウンロードして、アプリのフォルダーに入れないでください。
  3. 障害モジュールを確認します。ElectronまたはFlutterを使うクライアントでは、ログに基づいてランタイム、グラフィックドライバー、アプリのリソースを調べます。ハードウェアアクセラレーションの無効化は、クライアントのドキュメントで明確にサポートされている場合に限って試してください。別のクライアントの起動オプションを流用しないでください。

Linuxでは、WebKitGTK、グラフィカルセッション、共有ライブラリへの依存関係はインストーラーの種類によって異なります。まずターミナルで不足しているライブラリ名を特定し、ディストリビューションのパッケージマネージャーで対処してください。ほかのディストリビューションのライブラリを混在させないでください。macOSでは、クライアントを再インストールする前に、現在のインストーラーが要求するシステムバージョンを満たしているか確認します。

データディレクトリを切り分け、元に戻せる状態を残す

設定の検証、ポートの確認、実行環境の修復でも解決しない場合は、新しいユーザーデータで起動を試します。アンインストールして再インストールしても、ユーザーディレクトリが削除されるとは限りません。「再インストールしてもクラッシュする」だけで、インストーラーに問題があるとは判断できません。

  1. 関連プロセスをすべて終了します。バックグラウンドサービスがファイルを書き込み続けている場合は、クライアントがサポートする方法で停止します。バックアップ中にファイルが変更されるのを防ぎます。
  2. 実際のデータディレクトリを確認します。ログ、ドキュメント、クライアントのディレクトリを開く機能を手がかりに保存先を特定します。インストール先、システムキャッシュ、ユーザー設定を混同しないでください。
  3. コピーして名前を変更します。まずディレクトリ全体をバックアップし、元のディレクトリ名を client-data-backup-20260929 のように日付付きに変更します。すぐに完全削除したり、ディレクトリ全体を公開アップロードしたりしないでください。
  4. 初期状態で起動します。サブスクリプションを読み込まず、TUNも有効にせず、画面とコアが正常に動作することを確認します。その後、サブスクリプション、カスタムルール、オーバーライド、各種設定を1つずつ戻してください。

初期状態で正常に動作し、項目を戻した後に再び失敗する場合は、その項目だけを含む最小の再現用コピーを残してください。ディレクトリ全体を上書きで戻すと、破損した状態ファイルまで復元されることがあります。初期状態でも失敗し、同じコアが単独では正常に動く場合は、プロキシルールの変更を続けるのではなく、GUI側のクラッシュ情報を報告してください。

修復後の動作確認と問い合わせ時の記録

ウィンドウが開くだけでは修復完了とはいえません。コアが安定して動作すること、ポートが正しく待ち受けていること、サブスクリプションを読み込めること、必要な機能を有効にしても終了しないことを確認してください。システムプロキシとTUNは別々にテストし、元のシステムプロキシ設定が想定どおりに戻っているかも確認します。

  • 起動確認：正常な起動と終了を2回続けて行い、終了後に同じポートを使用するプロセスが残っていないことを確認します。
  • 設定確認：サブスクリプションを手動で1回更新し、最終設定のテスト結果とルールセットの読み込み状況を確認します。失敗した場合は、唯一の正常な設定を自動で上書きせず、旧設定を残してください。
  • モード確認：まずローカルプロキシを確認し、次にシステムプロキシをテストします。必要に応じて最後にTUNを有効にし、各段階でログを確認してください。
  • 問い合わせに添える情報：OSのバージョン、アーキテクチャ、クライアントとコアのバージョン、再現手順、最初のエラー、機密情報を伏せたログを提示します。最小構成と新しいデータディレクトリで起動できるかも記載してください。

問い合わせる際は、「アップデート後に起動から2秒で終了。最小構成では正常で、特定のオーバーライドを戻すと再現」のように状況を明記すると、エラー画面の画像だけを添付するより原因を特定しやすくなります。調査後は、一時的に上げたログレベルを通常の設定に戻し、正常に動作する設定のバックアップを保管してください。機密情報を含む一時的な診断ファイルも削除します。