Clash Vergeのクラッシュ対処

ウィンドウが消えたのか、カーネルが終了したのかを見分ける

Clash Vergeが起動直後にクラッシュしたら、まずログを保存し、障害が発生した層を切り分けましょう。最初から設定フォルダーを削除するのは避けてください。デスクトップ画面、バックグラウンドサービス、mihomoカーネルはそれぞれ別のプロセスです。画面が終了する場合はWebView2やアプリの状態ファイル、画面は正常でもプロキシが使えない場合はカーネル設定、待ち受けポート、TUNの権限を確認します。ノードの遅延テストに失敗しても、クライアントの起動クラッシュとは限りません。

この記事では、旧Clash Vergeと後継のClash Verge Revの両方を対象に対処方法を紹介しますが、フォルダー構成やメニューが同じとは限りません。利用中のプロジェクト名、正確なバージョン、インストーラーのアーキテクチャ、OSのバージョンを控えてください。Windowsでは Win + R を押して winver と入力すると、OSのバージョンを確認できます。クライアントを切り替える前にバックアップを取り、旧版の状態ファイルを新版のフォルダーにそのまま上書きしないようにしましょう。

Windowsの「タスク マネージャー」→「詳細」でアプリのプロセスが終了しているか確認し、その後、通知領域を確認します。ウィンドウが隠れているだけなら通知領域から復元してください。バックグラウンドのプロセスが応答しない場合は、まず通常の方法で終了し、必要であればこのクライアントのものと確認できたプロセスだけを終了します。「プロキシ」や「サービス」を含む名前のプロセスをまとめて終了しないでください。

起動ログとクラッシュした時刻を確認する

画面を開ける場合：アプリ内のフォルダーを確認する

Clash Verge Revの「設定」から「アプリフォルダー」やフォルダーを開く項目を探し、ログ関連のフォルダーを確認します。項目名はバージョンによって異なる場合があります。Windowsのインストーラー版では通常、ユーザーの %APPDATA% にデータが保存されます。ポータブル版では、プログラムの近くに保存されることがあります。ネット上で見つけたパスだけを根拠に、現在の環境にはログがないと判断しないでください。

アプリを開けない場合は、まず次のPowerShellコマンドで、名前にVergeを含むデータフォルダーの候補を一覧表示できます。この操作はフォルダー一覧を読み取るだけで、ファイルの削除や変更は行いません。フォルダーが見つかったら、更新日時を目安に最新のログファイルを探してください。アプリ、サービス、カーネルのログがある場合は、それぞれ別に保存します。

# Windows PowerShell：ユーザーデータフォルダーの候補を検索
Get-ChildItem -LiteralPath $env:APPDATA -Directory -Force |
  Where-Object { $_.Name -match 'verge' } |
  Select-Object Name, FullName, LastWriteTime

画面をまったく開けない場合：システムの記録も確認する

1. 現地時刻を記録し、クラッシュを一度だけ再現します。連続して起動すると、古いログが上書きされることがあります。
2. Win + R を押して eventvwr.msc と入力し、「Windowsログ」→「アプリケーション」で同じ時刻のエラー記録を確認します。
3. 障害が発生したアプリケーション、障害モジュール、例外コード、パスを記録します。イベントID 1000や1001は手がかりになりますが、クラッシュのたびに必ず記録されるわけではありません。
4. perfmon /rel を実行して信頼性モニターを開き、該当日のアプリケーション障害の詳細を確認する方法もあります。

カーネルログの fatal、error、panic は調査の手がかりであり、それだけで原因が確定するわけではありません。前後約20行もあわせて確認してください。最後の「プロセス終了」は結果にすぎず、原因はその前に発生した設定の解析失敗やポートのバインド失敗かもしれません。GUIアプリが端末に何も出力しないからといって、異常がなかったとは限りません。

設定ファイルの破損：まず検証し、必要なら退避する

ログに yaml: line 18、unmarshal、parse config、または存在しないポリシー名が出ている場合は、設定の読み込み経路から調べます。YAMLはインデントやデータ型に敏感です。Tabによるインデント、リストを文字列として記述すること、削除済みのポリシーグループの参照などが、カーネルの起動を妨げる場合があります。ただし、画面の状態ファイルの解析失敗とプロキシ設定の解析失敗は別の問題です。混同して対処しないでください。

現在のインストールに付属するカーネルでテストする

mihomoには、通常のプロキシ待ち受けを開始せずに設定を検証できる -t オプションがあります。次の例では、端末が mihomo.exe のあるフォルダーにあり、検証するファイルを config-test.yaml にコピー済みとします。パッケージによってカーネルのファイル名が異なる場合があります。別のカーネルに一時的に入れ替えて判断せず、現在のクライアントに付属するファイルを使ってください。

# Windows PowerShell：コピーした設定ファイルを検証
.\mihomo.exe -t -f .\config-test.yaml
$LASTEXITCODE

テストに失敗した場合は、出力全体と終了コードを記録します。ルールセット、地理データ、相対パスを含む設定は、作業ディレクトリや外部リソースにも依存します。「リソースが見つからない」エラーと「YAML構文エラー」は分けて対処してください。テストに成功しても、そのテスト条件で設定を検証できたというだけで、サービスの権限、TUN、ネットワーク接続まで正常とは限りません。

1. 完全なバックアップ：アプリを終了し、関連するプロセスが停止したことを確認してから、ユーザーデータフォルダーを別の場所にコピーします。サブスクリプション、オーバーライドスクリプト、ルール、画面設定などが保存されている場合があります。
2. 直前の変更を元に戻す：ルールやスクリプトの編集後に問題が発生した場合は、まずその変更を元に戻します。サブスクリプションの更新、カーネルの差し替え、ポートの変更を同時に行わないでください。
3. 実際に適用される設定を確認する：クライアントはサブスクリプション、オーバーライド、スクリプトを統合してからカーネルに渡すことがあります。元のサブスクリプションを解析できても、統合後の設定が有効とは限りません。
4. アプリの状態を切り分ける：ログが特定の画面状態ファイルを示している場合に限り、バックアップを取ったうえでそのファイル名を変更してテストします。推測でファイル名を決めて一括削除しないでください。

新しいデータフォルダーでの検証が必要な場合は、クライアントと関連サービスを停止し、元のフォルダーを保存してから、そのバージョンでサポートされている方法で独立した環境を作成します。新環境で起動できても、旧環境の設定や状態をさらに調べる必要があるというだけで、すべてのサブスクリプションを恒久的に破棄すべきという意味ではありません。復元は少しずつ行い、問題が再発したら対象の設定やオーバーライドを絞り込みます。

ポートの競合：待ち受け中のプロセスを確認する

address already in use や bind のエラーは、待ち受けアドレスが競合している可能性を示します。ポートの例として 7890、7897、コントロールインターフェース用の 9090 がありますが、すべてのバージョンで固定されているわけではありません。現在適用中の設定にある mixed-port、port、socks-port、external-controller を確認してください。

# Windows PowerShell：実際にエラーが出たポートに合わせてリストを調整
$ports = 7890, 7897, 9090
Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in $ports } |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 例：1234を前の手順で確認した実際のプロセスIDに置き換える
Get-Process -Id 1234

上記の 1234 はプロセスIDの例であり、そのままプロセスの終了に使わないでください。プロセス名、プログラムのパス、別のプロキシクライアントに属するプロセスではないかを確認します。古いカーネルが残っている場合は、まず元のクライアントから終了してください。プロセスを終了する必要があるときは、対象を確認できたインスタンスだけを終了します。

• 2つのクライアントを同時に使う：プロキシの待ち受けポートとコントロールポートをそれぞれ別に設定してください。プロキシのポートだけを変更しても、コントロールインターフェースが競合することがあります。
• プロキシのポートを変更した：システムプロキシと、プロキシを手動設定したアプリも確認してください。古いポートに接続し続ける場合があります。
• 「アクセスが拒否されました」と表示される：通常のプロセスによる占有とは限らず、ポートの予約やセキュリティポリシーが関係している可能性もあります。ポート競合と同じ原因だと決めつけないでください。

ポートが空いているのにバインドできない場合は、netsh interface ipv4 show excludedportrange protocol=tcp でIPv4 TCPの除外範囲を確認できます。IPv6環境では、対応する設定も確認してください。プロキシを起動するためにシステムの予約範囲をむやみに削除せず、まず使用可能と確認できた別のポートで試すのが適切です。

カーネルの権限とTUN：段階的に復旧する

permission denied、access is denied、TUNデバイスを作成できない、サービスに接続できないといった場合は、「カーネルの起動」と「仮想ネットワークアダプターの作成」のどちらで失敗したかを先に切り分けます。システムプロキシは、システムプロキシ設定に従うアプリに影響します。TUNは仮想ネットワークインターフェースで通信を取り込むため、サービス、権限、ルートも関係し、調査範囲が広くなります。

まずTUNを使わない状態を基準にする

1. 画面を操作できる場合は、TUNをオフにしてルールモードを維持し、システムプロキシで同じWebサイトに接続できるか試します。
2. TUNを使わない場合は接続でき、TUNで失敗する場合は、ノードをすぐに変更せず、サービスの状態、仮想ネットワークアダプター、ルートのログを確認します。
3. 現在のバージョンの設定画面でサービスモードを確認します。サービスのインストールや修復が必要な場合は、その操作に限って権限を許可し、実行後のログを確認してください。
4. Win + R を押して services.msc と入力し、該当サービスの実行状態と実行ファイルのパスを確認します。サービスが古いインストール先を参照している場合があります。

管理者としての実行は、権限の違いを一度だけ確認するための方法にはなりますが、問題を隠す恒久的な対処にはしないでください。権限を上げたときだけユーザーデータファイルにアクセスできる場合は、ファイルの所有者、フォルダーのアクセス権、インストール先を確認します。ディスク全体のアクセス権をむやみに緩めると、セキュリティリスクが高まります。

Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、カーネルファイルやコンポーネントがブロックされていないか確認できます。ファイルの入手元とイベントの詳細を確認してから対処し、すべての保護機能を無効にすることは避けてください。macOSでは「コンソール」と「システム設定」→「プライバシーとセキュリティ」の通知を確認します。Linuxでは起動方法に応じて端末やサービスのログを調べ、Windowsのサービス修復手順をそのまま適用しないでください。

ランタイムとインストーラー：障害モジュールに応じて修復する

Windows版のTauriベースのClash Vergeシリーズは、通常WebView2に依存します。画面表示用ランタイムの不足や破損でウィンドウを作成できなくなることがありますが、ウィンドウが一瞬で消えるだけでWebView2が原因だとは断定できません。システムイベントの障害モジュール、インストーラーのエラー、クライアントのログをあわせて判断してください。

Windowsの「設定」→「システム」→「バージョン情報」でシステムの種類を確認できます。x64版とARM64版は、OSとプロジェクトの対応状況に合わせて選んでください。macOSではAppleシリコン搭載機とIntel搭載機を区別します。アーキテクチャの選択ミス、コンポーネントの混在、古いファイルの置き換え失敗は、「サブスクリプションの破損」よりもこの種の読み込みエラーに当てはまる原因です。

再インストールする場合は、まずユーザーデータをバックアップし、現在のバージョン情報を保存します。その後、クライアントと関連プロセスを終了し、同じプロジェクトの完全なインストーラーを使ってください。再インストールしてもユーザー設定は通常自動削除されないため、再インストール後もクラッシュするからといって、設定の問題を除外することはできません。旧Clash Verge、Clash Verge Rev、ほかのクライアントのプログラムファイルを同じフォルダーに混在させないでください。

復旧後の動作確認と問題の報告

ウィンドウが表示されても、復旧完了とは限りません。以下の順序で確認し、一度に変更するのは1項目だけにしてください。ある手順でエラーが再発したら、その時点のログを保存し、正常に動作していた状態に戻します。

1. 画面の確認：設定画面を開き、一度終了して再起動します。起動が一度だけ成功した状態ではないことを確認してください。
2. カーネルの確認：ログに継続的な解析エラーや待ち受けエラーがなく、カーネルのプロセスが繰り返し終了していないことを確認します。
3. ローカルプロキシの確認：実際に待ち受けているポートを確認し、システムプロキシに従うアプリで接続をテストします。
4. 設定の復元：まず動作確認済みの設定を1つ読み込み、その後、オーバーライド、カスタムルール、サブスクリプションの更新を一つずつ復元します。
5. 最後にTUNを有効にする：DNS、ルート、接続が正常か確認します。システムプロキシが使えることだけを根拠に、TUNも使えると判断しないでください。

調査の流れは、プロセスが本当に終了したか確認し、発生時刻のログを探してから、設定、ポート、権限、ランタイムの該当項目に対処することです。設定項目を確認するときはプロトコルガイドを参照してください。復旧後にシステムプロキシやサブスクリプションの問題が残る場合は、よくある質問もご覧ください。クライアントを切り替える前にカーネルとプラットフォームの対応状況を比較し、すべての起動障害を移行で解決しようとしないでください。