Clashが起動直後にクラッシュする原因と対処法｜ログの確認方法

ウィンドウの終了とカーネルの終了を切り分ける

Clashクライアントを起動してすぐ画面が消えても、アプリ全体がクラッシュしたとは限りません。デスクトップクライアントは通常、GUI、プロキシカーネル、独立して動作するサービスコンポーネントで構成されています。ウィンドウが閉じても、トレイアイコンやカーネルプロセスが残っている場合があります。一方、mihomoカーネルだけが起動に失敗し、画面は表示されたままのこともあります。まず終了したのがどの部分かを確認してから、対処方法を選びましょう。

起動前に4つの情報を記録する

• クライアント名と完全なバージョン番号。画面を開ける場合は「バージョン情報」で確認します。開けない場合は、インストーラー名やアプリのファイル情報を確認してください。
• OSのバージョンとアーキテクチャ。例：Windows 11 x64、macOS arm64。「PC版」だけでは情報が不足します。
• 問題が発生した時刻（分単位）と、その前にクライアントを更新したか、サブスクリプションを読み込んだか、TUNを有効にしたかを記録します。
• 終了前に表示されたメッセージ全文と、システム内にクライアント、mihomo、関連サービスのプロセスが残っているかを記録します。

起動ログとシステムのクラッシュ記録を確認する

Clashクライアントによってアプリデータの保存先は異なります。特定のクライアントのログパスを、すべてのクライアントに共通する場所と考えないでください。画面を開ける場合は、まず「ログ」ページを確認するか、「設定」からログフォルダーやアプリフォルダーを開く項目を探します。項目名はクライアントのバージョンによって異なります。障害発生時刻の前後1分ほどのログを保存し、「起動に失敗しました」という最後の1行だけにしないようにしましょう。

Windows：イベント ビューアーとアプリデータ

1. Win + Rを押し、eventvwr.mscと入力します。
2. 「Windowsログ」→「Application」を開き、障害発生時刻付近の記録を探します。アプリのクラッシュでは、イベントソースがApplication Error、イベントIDが1000となることがあります。ただし、終了のたびに記録されるわけではありません。
3. 障害が発生したアプリケーション名、障害モジュール、例外コード、プログラムのパスを記録します。パスを確認すれば、新しくインストールしたバージョンと古いショートカットのどちらを起動したかを判別できます。
4. エクスプローラーのアドレスバーに%APPDATA%と%LOCALAPPDATA%をそれぞれ入力し、クライアント名やプロジェクト名を手掛かりに該当フォルダーを探します。ログはアプリのサブフォルダーにあるlogsに保存されている場合と、画面で指定した場所に保存されている場合があります。

perfmon /relを実行すると、信頼性モニターで日付ごとのアプリの障害記録を確認できます。システムレポートはGUIのクラッシュ調査に、カーネルログはYAML、ポート、リソース読み込みの問題の調査に役立ちます。両者は相互に代用できません。

macOS：診断レポートとコンソール

Finderで「移動」→「フォルダへ移動」を選び、~/Library/Logs/DiagnosticReports/と入力します。クライアントのプロセス名と障害時刻が一致する.ipsまたは.crashファイルを探してください。アプリ独自のログは、~/Library/Logs/または~/Library/Application Support/内の専用フォルダーにあることもあります。「コンソール」を開き、プロセス名でエラーを絞り込み、例外の種類と終了理由を記録しましょう。

Linux：ターミナルから起動してユーザーログを確認

実際にインストールされているクライアントのコマンドをターミナルから実行すると、ダブルクリックで起動したときには表示されない標準エラー出力を確認できます。デスクトップの起動コマンドは、対応する.desktopファイルのExecフィールドで確認できます。プログラムやユーザーサービスがjournalに記録している場合は、直近10分のログを確認します。

journalctl --user --since "10 minutes ago" --no-pager

アプリデータは通常、~/.config/、~/.local/share/、~/.local/state/内のプロジェクト用フォルダーにありますが、具体的な場所はクライアントによって異なります。systemdを使用し、クラッシュ情報が保存されている場合は、coredumpctl listを実行して記録を確認できます。出力がなくても、クラッシュしていないとは限りません。

設定ファイルの構文エラー：実際に読み込まれるファイルを確認

ログにyaml、unmarshal、設定解析時の行番号がある場合は、直近で読み込んだ、または編集したProfileを確認します。YAMLのインデントにはスペースを使い、Tabは使いません。同じ階層の項目はインデントをそろえてください。サブスクリプションの取得に成功しても、設定が有効とは限りません。リンク切れの場合、ログインページやエラーテキスト、変換されていないノード一覧が返されることがあります。

インデント、データ型、ポリシー名を確認

• mixed-port: 7890は数値フィールドの例です。全角コロンや誤った階層指定があると、解析に失敗します。
• リスト項目には正しい- のプレフィックスが必要です。rulesを通常の文字列として記述すると、型変換エラーになることがあります。
• ルールで参照するポリシー名は、設定内のプロキシまたはプロキシグループ名と一致させます。たとえば、ルールにProxyと記載されている一方、設定にPROXYしかない場合は、実際の名前を確認してください。
• フィールドの重複や、新たに追加したマージ設定・上書き設定も確認します。元のサブスクリプションに問題がなくても、マージ後の実行設定にエラーが含まれることがあります。

mihomoを使うClashクライアントでは、カーネルの提供元とバージョンを確認したうえで、設定ファイルのコピーをテストできます。以下では、ターミナルのカレントディレクトリにconfig.yamlがあり、mihomoをそのまま実行できるものとします。

mihomo -v
mihomo -t -f ./config.yaml

カーネルがPATHにない場合は、クライアントが実際に使用しているカーネルの絶対パスを指定します。検証のために別バージョンのカーネルをダウンロードして代用しないでください。設定によっては、指定された作業ディレクトリからルール用リソースやデータベースを読み込む必要があります。その場合は-dで確認済みの作業ディレクトリを指定します。テスト出力では、構文エラー、ポリシー参照エラー、リソース読み込み失敗を区別してください。

クライアントはProfile、全体の上書き設定、画面上の設定をもとに、最終的な実行設定を生成することがあります。そのため、元のサブスクリプションでテストに通っても、実際に読み込まれるファイルにエラーがないか確認してください。変更前のバックアップに戻し、クライアントのバージョンを変えずに再起動するのが効果的です。テストのためにサブスクリプションやルールを恒久的に削除しないでください。

カーネルファイルが見つからない：インストール状態とセキュリティ記録を確認

no such file or directory、実行ファイルが見つからない、カーネルプロセスを作成できないといったエラーがある場合は、ログに記載された実際のパスを確認します。更新の中断、アプリフォルダーの移動、メインプログラムだけのコピー、セキュリティソフトによるコンポーネントの隔離などで、インストールが不完全になることがあります。GUIのファイルが存在していても、カーネルや依存コンポーネントがそろっているとは限りません。

1. ショートカットのリンク先とインストール場所を確認し、古い展開フォルダーから起動していないか調べます。
2. カーネルファイルが存在するか、インストーラーのアーキテクチャがシステムと一致しているかを確認します。LinuxのExec format errorは、実行形式またはアーキテクチャの不一致を示している場合があります。
3. Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、障害発生時刻に該当する隔離の記録がないか確認します。
4. 元のプロジェクトの公式配布ページから完全なインストーラーを入手し、クライアントを終了してから修復または再インストールします。アプリデータはバックアップし、異なるバージョンのファイルを混在させないでください。

WindowsでWebView2Loader.dllやランタイムの初期化に関するエラーが出る場合、問題はYAMLではなくGUIの実行環境にある可能性があります。WebView2に依存するクライアントでのみ、該当するランタイムが必要です。他のクライアントに同じ対処を適用しないでください。クライアントのリリース情報に従って依存コンポーネントを修復し、見知らぬサイトからDLLをダウンロードしてシステムフォルダーに置くことは避けてください。

macOSでシステムのセキュリティ機能にブロックされた場合は、通常、明確な通知が表示されます。通知のないクラッシュとは切り分けて、アプリの入手元、システム要件、診断レポートを確認してください。Gatekeeperの無効化やアプリのセキュリティ属性の一括削除を、最初の対処として行わないでください。

権限不足：フォルダーとTUNを分けて確認

permission deniedやaccess is deniedは、操作が拒否されたことを示しますが、あらゆる場合に管理者として実行すべきという意味ではありません。通常の設定ファイルの読み書きと、TUN仮想ネットワークアダプターでは、必要な権限が異なります。前者はファイルの所有者とフォルダー権限、後者は特権サービス、システムネットワーク拡張、デバイスへのアクセス権に関係します。

フォルダーの読み書きに失敗する

まずログに記載されたファイルのパスを確認します。設定ファイルが読み取り専用メディア、保護されたフォルダー、同期フォルダーにある場合、クライアントがキャッシュやデータベースを書き込めないことがあります。Linuxで以前にsudoを使ってGUIクライアントを起動した場合、アプリデータの所有者がrootになっている可能性があります。ユーザーフォルダー全体の権限を広げるのではなく、該当フォルダーの所有者を確認してください。修復方法としてchmod -R 777を使わないでください。

TUNまたはサービスコンポーネントが動作しない

1. TUNを有効にする前の設定に戻し、まずGUIと通常のプロキシが正常に動作するか確認します。
2. 現在使用しているクライアントのドキュメントに従ってサービスコンポーネントをインストールまたは修復し、画面上のTUNスイッチを使って有効にします。
3. 認証を求める通知、ネットワーク拡張のブロック、サービスの起動失敗が表示されていないか確認し、関連するエラーを保存します。
4. システムのルーティングを変更するツールは、一度に一つだけ有効にします。複数の仮想ネットワークアダプターやルート管理プログラムを同時に動作させないでください。

残留プロセスとポートの競合：使用中のプロセスを確認

更新後も古いカーネルが動作していると、新しいカーネルが使用するポートを占有することがあります。ログのaddress already in useは、「起動に失敗しました」という表示よりも原因の特定に役立ちます。プロキシの待ち受けポートと外部コントローラーのポートは別のものです。7890や9090はよくある設定例にすぎないため、実際の設定とエラーに記載されたポートを基準に調べてください。

ポートを使用しているプロセスを確認

Windowsではコマンドプロンプトで次のコマンドを実行します。最後の列に表示されたPIDを確認し、「タスク マネージャー」→「詳細」でプロセス名と実行ファイルのパスを調べてください。

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

出力にリモートアドレスの一致項目が含まれる場合もあります。ローカルアドレス、ポート、待ち受け状態を確認してください。macOSではTCPの待ち受けプロセスを検索できます。

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

Linuxでは待ち受けソケットを確認できます。プロセス情報の表示は権限に制限されるため、一般ユーザーから他のユーザーのプロセスが見えない場合があります。

ss -lntp 'sport = :7890'
ss -lntp 'sport = :9090'

1. まずトレイから古いクライアントを終了します。独立したサービスは、インストール方法に応じて停止してください。ウィンドウを閉じるだけでは不十分です。
2. ポートを再度確認し、待ち受けがなくなったことを確かめてから、対象のクライアントを起動します。
3. ポートの使用者が必要な別サービスの場合は、対象クライアントのポートを変更し、システムプロキシや関連アプリの設定も更新します。
4. プロセスの所有者を確認してから終了してください。「プロキシに見える名前」というだけで、システムやネットワークのプロセスを一括終了しないでください。

ポートの競合は通常、カーネルの起動失敗を引き起こしますが、GUIが直接クラッシュするとは限りません。ポートを解放してもウィンドウがすぐ閉じる場合は、ポートを何度も変更するのではなく、システムのクラッシュレポートを確認してください。

バックアップ後にリセット：設定を段階的に戻す

ログだけで原因を特定できない場合や、古い設定が新しいバージョンと互換性の問題を起こしている場合は、アプリデータを初期状態にして比較できます。再インストールしても設定はリセットされないことがあります。アプリデータはインストール先とは別の場所に保存されるためです。リセット前に、現在のクライアントが使っているフォルダーを確認し、別のクライアントのデータを誤って操作しないようにしてください。

1. プログラムを終了する。トレイからクライアントを終了し、カーネルやサービスがデータを書き込んでいないことを確認します。
2. データを丸ごとバックアップする。アプリデータのフォルダーをコピーし、ローカルのYAML、サブスクリプション情報、上書きルール、画面設定を保存します。機密情報を含むため、管理されたローカルの場所に保管してください。
3. 古いデータを退避する。確認済みのアプリデータフォルダーを、元の名前の末尾に.backup-20260917を付けるなどして変更します。直接削除しないでください。
4. 初期状態で起動する。クライアントが新しいフォルダーを作成し、そのまま動作するか確認します。この時点では自動接続、TUN、すべてのサブスクリプションを復元しないでください。
5. 設定を一つずつ戻す。まず有効性を確認した設定を読み込み、次に上書きルールを戻し、最後にTUNとサービスの設定を戻します。各段階でログを確認してください。

いずれかの設定を戻した後に問題が再発すれば、再現可能な条件が特定できたことになります。新しいデータでもクラッシュする場合は、設定の優先度を下げ、クライアントのバージョン、実行時の依存関係、OSとの互換性を調べます。バージョンを戻すときも別のバックアップを使い、旧バージョンから新バージョンに移行したデータベースを直接読み込ませないでください。

修復後の動作確認と問い合わせに必要な情報

ウィンドウが開くことは、最初の確認項目にすぎません。カーネルが動作し続けること、設定の読み込みが成功すること、待ち受けポートが想定どおりであることも確認してください。システムプロキシを使う場合は、ブラウザーの通信がそのポートを経由しているか確認します。TUNを使う場合は、ルーティングとDNSの動作も調べてください。ノードのタイムアウトは接続層の問題です。タイムアウトだけを根拠に、クライアントが起動時にクラッシュしていると判断しないでください。

• 完全に終了してからもう一度起動し、残留プロセスに依存せず修復できたことを確認します。
• 修復前後のログを保存し、設定、インストールファイル、権限、サービス状態のどれを変更したか記録します。
• 問い合わせ時は、クライアントとカーネルのバージョン、OSのアーキテクチャ、再現手順、機密情報を伏せた主要なエラーを添えてください。
• レポートに障害モジュールや例外コードが含まれる場合は、そのまま記載してください。「開けない」とだけ書いたり、ウィンドウのスクリーンショットだけを送ったりしないでください。

確認の流れは、終了した箇所を特定し、ログを取得し、エラーに応じて設定、ファイル、権限、ポートを確認し、最後にバックアップ後のリセットで比較することです。インストーラーを選び直す場合はクライアントのダウンロードページをご覧ください。設定の読み込みやシステムプロキシの手順は使い方ガイド、TUNとDNSの設定は詳細設定ガイドで確認できます。