Clashが起動直後にクラッシュする場合の対処法｜ログ・ポート競合・設定の復元

まずはウィンドウが終了したのか、カーネルの起動に失敗したのかを切り分ける

まずタスクトレイやメニューバーを確認し、次にプロセス一覧を見ます。ウィンドウを閉じてもトレイアイコンが残っている場合は、「閉じるとトレイに最小化」の設定が有効なだけで、クラッシュではない可能性があります。ウィンドウは開くのに接続エラーやプロキシが利用できないと表示される場合は、カーネルが起動していない可能性が高いでしょう。カーネルは設定の読み込み、ルールの照合、通信の転送を担うプログラムで、GUIは操作用の窓口です。

障害が起きる直前に行った操作を記録します。サブスクリプションの更新後に問題が起きたなら設定を、TUNを有効にした後なら権限や仮想NICを確認します。クライアントのアップデート後、ウィンドウすら表示されない場合は、アプリのクラッシュレポートとインストーラーのアーキテクチャを確認してください。ソフトの更新、サブスクリプションの変更、ポートの変更を同時に行うと、どの操作で解決したのか分からなくなります。

ログを確認する：最初の失敗が起きた前後の情報を残す

画面が開く場合は、まずカーネルログを探す

クライアントの「ログ」画面を開くか、「設定」から「設定フォルダーを開く」「ログフォルダーを開く」などの項目を探します。メニュー名はクライアントごとに異なるため、別のクライアントのフォルダーをそのまま当てはめないでください。今回の起動時刻付近の記録を優先し、エラーの前後約20行を保存します。末尾で「接続を再試行」が繰り返されているだけなら、それは多くの場合、エラーの結果です。

アプリログとカーネルログを区別してください。アプリログにはウィンドウ、更新、サービス呼び出しの記録が残り、カーネルログには設定の解析、ポートの待ち受け、ルールの読み込み、接続処理が記録されます。画面に「コントロールポートに接続できません」と表示された場合は、設定エラーでカーネルが先に終了していないか、ログをさかのぼって確認します。すぐにコントロールポートの競合と決めつけないでください。

ウィンドウが開かない場合は、システムログを確認する

• Windows：Win + R を押し、eventvwr.msc を実行して「Windowsログ」→「Application」を開きます。発生時刻を手掛かりにアプリケーションエラーを探してください。perfmon /rel を実行して信頼性モニターを開き、アプリの失敗記録を確認する方法もあります。
• macOS：「コンソール」アプリを開いて「クラッシュレポート」を確認し、プロセス名と発生時刻から該当するレポートを探します。例外の種類、終了理由、障害が発生したスレッドを確認してください。レポートのタイトルだけを切り取るのではなく、内容も確認します。
• Linux：ターミナルから実際のクライアント実行ファイルを起動し、標準エラー出力を確認します。ユーザーサービスから起動している場合は、journalctl --user -b で今回の起動時のユーザーサービスログを確認してください。

まずキーワードで範囲を絞ります。yaml、unmarshal、parse は設定の解析、address already in use はアドレスやポートの競合、permission denied、operation not permitted は権限の問題を示すことがよくあります。ログに error とあっても、必ずしもプログラムがクラッシュしたとは限りません。たとえばルールソースのダウンロードが1件失敗しても、その後起動が続いているかを確認する必要があります。

設定を確認する：まずYAMLを検証し、次にカーネルの対応状況を確認

まず直近で変更した数行を確認します。YAMLはインデントで階層を表す設定形式です。インデントにはスペースを使い、タブを混在させないでください。よくあるミスは、コロンの後にスペースがない、リスト項目のハイフンが抜けている、引用符が閉じていない、rules を dns の下に書いている、といったものです。エラー行はパーサーが最終的に問題を検出した位置にすぎない場合もあるため、直前のブロックも合わせて確認します。

実行中のカーネルを確認します。Clash、Clash Meta、mihomoでは、対応する設定項目の範囲が完全には一致しません。また、GUIの名称とカーネルの名称が同じとは限りません。「バージョン情報」や起動ログで、クライアントとカーネルのバージョンを確認してください。インストーラーの名前だけを根拠に、特定の項目に対応していると判断しないでください。

同じカーネルで設定のコピーをテストする

確認したいファイルを recovery.yaml にコピーし、コピー側で作業します。以下のコマンドはmihomo用です。まず -v でバージョンを確認し、次に -t で設定をテストします。クライアントが実際に使用するカーネルを使い、別バージョンを適当にダウンロードして代用しないでください。

# Windows PowerShell：カーネルとテスト用ファイルのあるディレクトリで実行
.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\recovery.yaml

# macOS / Linux：該当するディレクトリで実行
./mihomo -v
./mihomo -t -d . -f ./recovery.yaml

-f は設定ファイル、-d は作業ディレクトリを指定します。ここでの . はカレントディレクトリを表します。元の設定が相対パスでルールファイルを参照している場合は、必要なファイルもテスト用ディレクトリにコピーしてください。ローカルリソースが不足しているとテストに失敗することもあり、すべてをYAML構文エラーと判断することはできません。

最小構成でサブスクリプションと上書き設定を切り分ける

どの部分に問題があるか分からない場合は、コピーしたファイルで以下のmihomo設定を一時的に使えます。TUNと内蔵DNSを無効にし、ローカルの混合プロキシポートだけを提供して、リクエストを接続先へ直接送ります。基本的な起動確認用であり、リモートプロキシ機能はなく、完全なサブスクリプション設定としては使えません。

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

tun:
  enable: false

dns:
  enable: false

rules:
  - MATCH,DIRECT

最小構成で起動できたら、「サブスクリプション本体 → カスタムルール → DNS → TUN」の順に、各段階で再起動しながら戻します。サブスクリプションの自動更新後にだけ再発する場合は、形式とクライアントの上書き処理を確認してください。多くのクライアントは実行用設定を再生成するため、生成されたファイルを直接編集しても次回起動時に反映されないことがあります。

ポート競合を調べる：まずプロセスを特定し、必要に応じてポートを変更する

ログに記録されたポートを基準に確認します。7890 はHTTPとSOCKSの混合プロキシポート、9090 はコントロールインターフェースに使われることが多いものの、どちらも変更可能です。また、待ち受けの失敗と接続の失敗を区別してください。bind の付近にエラーがあればローカルの待ち受けが原因の可能性がありますが、リモートノードへの接続タイムアウトは、ローカルポートの競合を意味しません。

Windows：待ち受けプロセスのPIDを確認する

PowerShellを開いて、以下のコマンドを実行します。PIDはプロセス識別子で、待ち受けポートを具体的なプログラムと対応づけるために使います。コマンドの出力がなければ、確認時点で該当するTCP待ち受けが見つからなかったという意味です。プログラムの起動時にも競合がなかったとは限りません。

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

# 待ち受けプロセスの名前を一覧表示
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique |
  ForEach-Object { Get-Process -Id $_ -ErrorAction SilentlyContinue }

macOS / Linux：TCPポートを待ち受けているプロセスを確認する

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

まず古いクライアントを通常の方法で終了し、カーネルやバックグラウンドサービスが残っていないか確認します。ポートが使用中だからといって、見覚えのないプロセスを強制終了したり、システムサービスを停止したりしないでください。混合ポートを 7895 に変更する場合は、新しいポートが空いていることを確認してから、ブラウザーの手動プロキシ設定、ターミナルの環境変数、その他の利用元も合わせて変更します。

コントロールポートは分けて確認します。external-controller を変更した場合、GUIも新しいアドレスに接続する必要があります。クライアントによってはこの項目を独自に管理しているため、手動で上書きするとGUIから接続できなくなることがあります。ログにDNSの 53 番ポートが示されている場合は、UDP/TCPの待ち受けとシステムの名前解決サービスを別途確認してください。先ほどのTCP確認だけではDNSの競合を調べきれません。

権限とサービスモードを確認する：まずTUNを無効にして検証

まずTUNを無効にし、通常のプロキシを起動します。TUNは仮想NICを使って通信を取り込む方式で、通常はシステムのルーティングやネットワークインターフェース、高い権限が関係します。TUNを無効にすると起動できる場合、原因を仮想NIC、権限、サービス、関連設定に絞れます。サブスクリプションを何度も変更する必要はありません。

1. バックグラウンドサービスの状態を確認します。クライアントの設定で「サービスモード」または関連するサービス管理項目を確認してください。Windowsでは services.msc を実行し、クライアントに表示される正確なサービス名、状態、実行ファイルのパスを確認します。名前が似ているだけで判断しないでください。
2. アップデート後のパス変更を確認します。ポータブル版の配置場所を移動した場合や、古いサービスが削除済みのファイルを参照している場合、サービスを起動できないことがあります。まずクライアントを終了し、付属のサービス修復機能を使うか、サービスの再インストール項目から対処してください。
3. 設定フォルダーへの書き込み権限を確認します。バックアップ用フォルダーに通常のテキストファイルを作成できるか試してください。アプリの設定フォルダーが読み取り専用の場所にある、別のユーザーが所有している、またはセキュリティソフトにブロックされている場合は、ログを確認して該当するアクセス権を修正します。
4. 最後にTUNを再度有効にします。通常のプロキシが安定してからTUNを個別に有効にし、ログを確認してください。ルーティングを制御するプロキシやVPNを複数同時に動かすと、仮想NICやルーティングルールが互いに干渉するおそれがあります。

「常に管理者として実行」を万能な解決策と考えないでください。一時的に権限を上げて確認すれば、権限の問題かどうかを切り分けられますが、恒久的な対処にはクライアントが用意するサービスのインストール手順を使います。macOSのバックグラウンドヘルパーやLinuxのサービス権限も、各クライアントの案内に従って設定してください。プログラムのフォルダー全体に無制限の書き込み権限を与えることは避けましょう。

安全に設定を戻す：最後に動作した設定を復元し、フォルダー全体を削除しない

まず障害発生時の状態を残してから、最後に正常だった状態へ戻します。設定フォルダー全体を削除すると、サブスクリプションの参照先、ルールの上書き、問題調査に必要な記録まで失うおそれがあります。初期化する場合も、すぐに削除するのではなく、バックアップしてから名前を変更してください。

1. 完全に終了します。ウィンドウを閉じた後、トレイやメニューバー、関連プロセスを確認します。バックグラウンドサービスがカーネルを管理している場合は、クライアントからサービスまたはカーネルを正常に停止してください。
2. バックアップをコピーします。実際の設定フォルダーを、clash-backup-2026-09-30 のように日付付きの名前でコピーし、障害ログも別に保存します。
3. 問題に関係する項目だけを復元します。ルールの変更後に問題が起きたなら、まず上書きルールを戻します。サブスクリプションの更新後なら、動作していた設定に切り替えます。最初からアプリの設定をすべて置き換えないでください。
4. 自動更新を一時停止します。クライアントが対応している場合は、復元した設定が再び上書きされないよう、そのサブスクリプションの定期更新を一時停止します。修復が完了したら更新を再開してください。
5. 3つの状態を確認します。画面が安定して動作すること、ログで再起動が繰り返されないこと、使用するポートが正常に待ち受けていることを確認します。その後、完全なサブスクリプション設定で実際のプロキシ通信を検証してください。

アプリの設定自体が破損していると思われる場合は、バックアップを取ってから設定フォルダーの名前を変更し、クライアントに新しいフォルダーを作成させます。ただし、データフォルダーの場所はクライアントによって異なります。ポータブル版ではプログラムと同じ場所、別のクライアントではユーザーデータフォルダーを使う場合があるため、ログに記録された実際の場所を確認してください。初期化後、古い設定一式をすぐに戻すと、問題まで再発するおそれがあります。

バージョンアップ直後に問題が起きた場合は、更新前後のクライアントとカーネルのバージョンを記録し、プロジェクトの正式な配布元から既知の正常なバージョンへ戻すことを検討します。新しいバージョンが保存したデータ形式は、古いバージョンと互換性がないことがあります。更新前と更新後のバックアップを両方保存し、古いバージョンで唯一のデータフォルダーを何度も書き換えないでください。

クラッシュが続く場合：再現できる形で調査記録をまとめる

情報を整理してから問題を報告します。「起動するとすぐ消える」だけでは、GUIのクラッシュ、カーネルの終了、バックグラウンドサービスの失敗を区別できません。システム関連のエラーについてはトラブルシューティングを、設定のインポート先が分からない場合は使い方ガイドを確認してください。

• 環境：OSのバージョン、CPUアーキテクチャ、クライアントとカーネルの正確なバージョン、通常インストール版かポータブル版か。
• 発生手順：起動から終了までの時間、特定のサブスクリプションのインポート後、TUNの有効化後、またはサービスモードの切り替え後だけに発生するか。
• 確認結果：最小構成で起動できるか、設定テストに通るか、7890または実際に使うポートをどのプロセスが待ち受けているか。
• ログの抜粋：今回の失敗時刻、最初に出た重要なエラー、その前後の記録。ウィンドウがクラッシュした場合は、システムレポートの障害モジュールまたは例外の種類も添えてください。

「ログ → 設定 → ポート → 権限 → 復元」の順に確認し、一度に変更する条件は1つだけにします。原因を絞り込みやすくなり、明確な復旧手順も保てます。起動の問題を直すために、新たな設定差分を持ち込むことも避けられます。