Clash Vergeが起動直後に落ちる原因と対処法｜起動クラッシュの確認手順

まず症状を切り分ける：ウィンドウのクラッシュ、バックグラウンドでの動作、コアの起動失敗

Clash Vergeの画面プロセス、プロキシコア、システムサービスはそれぞれ別のコンポーネントです。ウィンドウが消えても、クライアント全体が終了したとは限りません。画面が表示されていてもコアの起動に失敗することがあり、その場合はWebView2が原因とは限りません。OSのバージョン、クライアントの正確なバージョン、インストーラーのアーキテクチャ、更新後・サブスクリプションのインポート後・初回インストール時のどのタイミングで発生したかを記録してください。

旧版のClash Vergeと、後継のメンテナンス版であるClash Verge Revは、同じリリースとして扱わないでください。データディレクトリ、サービス名、設定項目が異なる場合があります。画面を開ける場合は「設定」のバージョン情報を記録します。開けない場合は、インストーラーのファイル名や実行ファイルのプロパティで確認し、デスクトップのショートカット名だけで判断しないでください。

1. タスクバーの通知領域を確認します。Windowsでは隠れているアイコンを表示し、macOSではメニューバーを確認してください。
2. クライアントを終了してから、タスクマネージャーまたはアクティビティモニタを確認します。クライアントのものと確認できた残存プロセスだけを終了してください。
3. 一度だけ起動し、正確な時刻を記録してください。続けて何度もクリックすると、単一インスタンスのロックや複数の起動記録が判断を妨げます。

手順1：WindowsでWebView2とアプリケーションエラーを確認

Windows版Clash Vergeの画面はWebView2に依存しています。Microsoft Edgeが正常に開いても、WebView2 Runtimeが正常とは限りません。メインウィンドウが白くなる、WebView2の作成失敗が表示される、またはクラッシュ記録にWebView2コンポーネントが含まれる場合は、サブスクリプションを何度も変更するのではなく、まず実行環境を確認してください。

ランタイムを修復する手順

1. クライアントを終了します。Windows 11で「設定」→「アプリ」→「インストールされているアプリ」を開き、Microsoft Edge WebView2 Runtimeを検索してください。システムによってアプリ一覧の表示方法は異なります。検索結果に表示されないことだけで、未インストールとは判断できません。
2. 項目に「変更」または修復の操作があれば、画面の指示に従って実行します。表示されない場合は、Microsoft公式のEvergreen WebView2 Runtimeインストーラーで修復または再インストールしてください。オフライン環境では、該当アーキテクチャ用のスタンドアロンインストーラーを使用できます。
3. インストール完了後、クライアントを再起動します。インストーラーからシステムの再起動を求められた場合は、作業内容を保存してから再起動してください。
4. それでも起動直後に落ちる場合は、Win + Rを押してeventvwr.mscと入力し、「Windowsログ」→「アプリケーション」を開いて、記録した時刻のエラーを探します。

イベントソースがApplication Error、イベントIDが1000の記録は手がかりになりますが、すべての障害で記録されるわけではありません。「障害が発生しているアプリケーション名」「障害が発生しているモジュール名」「例外コード」を控えてください。ntdll.dllと表示されても、システムファイルの破損とは断定できません。例外が最終的に発生した場所を示しているだけの場合があります。

白画面とクラッシュは分けて対処

ウィンドウが白くてもプロセスが残っている場合は、まず画面のログを保存し、ランタイムとユーザーデータを確認します。プロセスも残らない場合は、システムのアプリケーションエラーも確認してください。ネット上で見かけるGPU無効化オプションを、すべてのバージョンにそのまま適用しないでください。ビルドによって対応するオプションが異なり、未確認の起動オプションは反映されない可能性があります。

WebView2の確認が必要なのはWindowsだけです。macOSはシステムのWebKitを使用し、Linux版は通常WebKitGTKなどのシステムコンポーネントに依存します。Windows用ランタイムをインストールしても修復できません。

手順2：ポートの競合を確認し、プロキシ用とコントロール用を区別

ログにaddress already in useまたはOnly one usage of each socket addressと表示される場合は、まず待ち受けポートを確認してください。ポートの競合でコアの起動に失敗することはありますが、画面のクラッシュにつながるとは限りません。画面も終了する場合は画面のログも確認し、別々の症状を混同しないでください。

設定のmixed-portは混合プロキシの入口、external-controllerはコントロール用インターフェースです。以下では7897と9090を例に確認しますが、すべてのバージョンで共通の既定値ではありません。ログまたは現在の設定にある実際のポートに置き換えてください。

Windows：待ち受け中のプロセスを特定

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

Get-Process -Id 4321

PowerShellで最初のコマンドを実行し、次に2つ目のコマンドの4321を実際のOwningProcessの値に置き換えてください。何も表示されなければ、確認時点でこれらのTCPポートに待ち受けがないという意味にすぎず、コアの他のポートが正常だとは限りません。例にあるPIDをそのまま終了しないでください。

macOS・Linux：待ち受けプロセスを確認

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

# Linux
ss -ltnp 'sport = :7897'
ss -ltnp 'sport = :9090'

• 競合しているのが別のプロキシクライアントなら、タスクトレイまたはメニューバーから正常に終了してから、もう一度試してください。
• 前回の起動で残ったコアの場合は、別のユーザーやソフトウェアのサービスを誤って停止しないよう、まず実行ファイルの場所を確認してください。
• ポートを変更する必要がある場合は、クライアントのポート設定から変更してください。上書き設定がある場合は、最終的に適用される値も確認します。サブスクリプションの元ファイルだけを変更しないでください。

プロキシポートを変更したら、ブラウザー拡張機能、ターミナルのプロキシ環境変数、その他の手動設定も合わせて変更します。コントロールポートを変更した場合は、クライアントとコアの接続先を一致させてください。ローカルの問題を回避するために、コントロールインターフェースを0.0.0.0に公開しないでください。

手順3：ユーザーデータをバックアップし、破損した設定を切り分ける

サブスクリプションのインポート、YAMLの編集、アップグレードの直後に問題が起きた場合は、設定とローカル状態を重点的に確認します。アンインストールしてもユーザーデータが残ることが多いため、再インストールだけでは起動時に読み込まれる内容が変わらない場合があります。先にバックアップを取り、新しいデータディレクトリで起動させるのが確実です。

ソフト名からパスを推測せず、保存先を特定する

画面を開ける場合は、「設定」にある設定ディレクトリまたはログディレクトリを開く項目を優先してください。配布版によって「設定ディレクトリ」「設定フォルダーを開く」「アプリケーションディレクトリ」など名称が異なる場合があります。画面を開けない場合は、以下のシステム上の場所にあるアプリ専用のサブディレクトリを確認し、更新日時、ログ、アプリの識別情報から該当するものを特定してください。

• Windows：エクスプローラーのアドレスバーに%APPDATA%と%LOCALAPPDATA%をそれぞれ入力します。設定とWebViewのキャッシュは別々に保存されている場合があります。
• macOS：Finderで「移動」→「フォルダへ移動」を選び、~/Library/Application Support/にある該当アプリのフォルダを確認します。
• Linux：${XDG_CONFIG_HOME:-$HOME/.config}と${XDG_DATA_HOME:-$HOME/.local/share}にあるアプリのディレクトリを確認します。XDG環境変数を変更している場合は、実際のパスを確認してください。

フォルダ名を変更して初期状態で起動する

1. クライアントと、それに属すると確認できたバックグラウンドプロセスを終了します。必要に応じて該当するサービスも先に停止してください。
2. アプリの設定ディレクトリ全体を別の場所にコピーしてバックアップします。バックアップにはサブスクリプションURL、ノードの認証情報、コントロールインターフェースのキーが含まれる場合があるため、アクセスを制限してください。
3. 元の設定ディレクトリ名を変更し、.backup-20261017など判別しやすい接尾辞を付けます。AppData、Library、.config全体を削除しないでください。
4. 古い設定をインポートせず、TUNも有効にしない状態でクライアントを起動し、メインウィンドウが安定して開くか確認します。
5. 新しい環境で正常に動作する場合は、まず正常と確認できたサブスクリプションを1つインポートし、その後ルールの上書き、スクリプト、その他の設定を1つずつ戻してください。

ログにyaml: line、unmarshal、ポリシー名が存在しないなどのエラーがある場合は、該当行、フィールドの型、参照先を確認してください。YAMLのインデントにはスペースを使い、同じ階層のフィールドを揃えます。プロキシグループが参照するノード名やグループ名が実際に存在するかも確認してください。クライアントの画面が開いても、現在のコアが古い設定のすべてのフィールドに対応しているとは限りません。

手順4：サービスの残留とTUNの権限を確認

サービスモードはバックグラウンドのコンポーネントを必要な権限で動かすための機能で、TUNは仮想ネットワークアダプターを通じて通信を処理します。関連はありますが、同じ設定ではありません。システムプロキシは使えるのにTUNを有効にすると失敗する場合は、WebView2を再インストールするのではなく、サービスの状態、権限、仮想ネットワークアダプターを優先して確認してください。

通常のプロキシ接続に戻してからサービスを確認

1. 設定画面を開ける場合は、まずTUNを無効にし、クライアントに用意されているサービス管理機能からサービスの停止または修復を行います。ボタンの名称や操作は、現在のバージョンに表示される内容に従ってください。
2. WindowsではWin + Rを押し、services.mscと入力します。対象候補のサービスの「プロパティ」を開き、実行ファイルのパスが古いインストール先を指していないか確認してください。
3. アップグレード後も古いサービスが残っている場合は、まず旧クライアントまたは対応するインストーラーのアンインストール・修復機能で処理し、その後、現在のクライアントからサービスをインストールしてください。
4. 再起動後はTUNを無効にした状態で画面とコアを確認し、その後TUNを個別にテストしてください。

表示名が似ているだけで判断してsc deleteを実行したり、仮想ネットワークアダプターをまとめて削除したりしないでください。古いサービスのパス切れ、サービスの起動失敗、ルートの競合はそれぞれ別の問題です。管理者権限で解決するのは権限の問題の一部に限られ、設定ファイルの破損やポートの競合は修復できません。

macOSのバックグラウンドヘルパーやLinuxのsystemdサービスも、実行ファイルのパスを確認してください。別のクライアントが現在も使用しているサービスファイルなら、ついでに削除しないでください。会社支給の端末ではネットワークポリシーによる制限も考えられるため、端末管理上の要件を先に確認してください。

手順5：セキュリティソフトのブロック履歴を確認し、保護機能を一律に無効化しない

「昨日まで使えていたのに、今日は急に開かない」という場合、アプリの更新、コアファイルの隔離、セキュリティポリシーの変更が関係している可能性があります。Windowsでは「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、クラッシュした時刻にクライアント、コア、補助サービスのファイルが検出されていないか確認してください。

• 処理されたファイルの完全なパス、検出名、時刻を記録してください。デスクトップのアイコンが残っていても、プログラムファイルがそろっているとは限りません。
• インストーラーが該当プロジェクトの正式な配布元から入手したものか確認し、リリースノートとシステムに表示される署名情報を確認してください。入手元が不明な実行ファイルを復元しないでください。
• 誤検知と確認できた場合は、組織のポリシーに従って申請するか、必要最小限の範囲で例外を設定してください。ダウンロードフォルダやユーザーフォルダ全体を除外対象にしないでください。
• フォルダーアクセスの制御によって書き込みがブロックされ、アプリが状態を保存できない場合もあります。信頼できると確認した特定のプログラムだけに許可を与えてください。

macOSで「開発元を検証できない」または「アプリが破損している」と表示された場合は、まず対応アーキテクチャ用の正式なインストーラーを再ダウンロードし、システムのセキュリティ警告を確認してください。隔離属性を一括で削除するコマンドを安易に実行しないでください。Linuxでは実行権限、システムログ、インストールパッケージの依存関係エラーも確認します。

OS別のクリーン再インストール：証拠を残し、段階的に復元

ここまでの確認で原因を特定できない場合に、クリーン再インストールを行います。クラッシュログ、バージョン情報、ユーザーデータのバックアップを保存し、システムプロキシを無効にしてください。アンインストール後にブラウザーが存在しないローカルポートへ接続し続けるのを防げます。インストールするのは、現在のOSでサポートされているメンテナンス版です。古いインストーラーを手当たり次第に探すのは避けてください。

Windows

1. クライアントを正常に終了し、確認済みのサービスを停止してから、「設定」→「アプリ」→「インストールされているアプリ」で該当プログラムをアンインストールします。
2. そのアプリに属すると確認できた残存設定ディレクトリは、名前を変更して保管してください。共有コンポーネントのWebView2 Runtimeは削除しないでください。
3. システムのアーキテクチャに合ったものを再インストールします。ファイルが使用中、またはサービスが実行中というメッセージが表示された場合は、残存プロセスを処理し、必要に応じてシステムを再起動してください。
4. 初回起動時は古い設定を復元しません。画面が正常に開くことを確認してから、サブスクリプション、システムプロキシ、サービスモード、最後にTUNの順でテストします。

macOS

1. メニューバーからクライアントを終了し、クライアントがサポートする手順で補助サービスをアンインストールしてから、「アプリケーション」内の古いアプリを削除します。
2. 該当するApplication Supportのデータディレクトリをバックアップし、名前を変更して保管してください。Library全体を消去しないでください。
3. Appleメニューの「このMacについて」で、Appleシリコン搭載かIntelプロセッサ搭載かを確認し、対応するインストーラーを選択してください。
4. それでもクラッシュする場合は、「コンソール」でクラッシュレポートを確認し、~/Library/Logs/DiagnosticReports/にある該当時刻のレポートも確認してください。

Linux

1. インストール形式がDEB、RPM、その他のどれかを確認してください。デスクトップの起動項目が複数の配布元から残らないよう、元のパッケージ管理方法で先にアンインストールします。
2. ターミナルから実際の実行ファイルを起動し、標準エラー出力を保存します。不足しているライブラリ、ディスプレイセッション、権限のエラーを確認し、ディストリビューションの手順に従って依存関係をインストールしてください。
3. 該当するXDGデータディレクトリをバックアップして名前を変更してから、再インストールしてください。WebKitGTKの依存パッケージ名はディストリビューションやビルドによって異なるため、別のシステム向けの古い依存関係一覧をそのまま使わないでください。
4. 通常のデスクトップウィンドウが安定して動作してから、サービスとTUNを設定します。ウィンドウを開くために、グラフィカルクライアント全体をroot権限で常用しないでください。

復旧後の確認：設定は一度に1つずつ戻す

修復完了の目安は、ウィンドウが表示されることだけではありません。コアが継続して動作し、ログに同じエラーが繰り返し記録されず、終了後にシステムのネットワーク接続が復旧することも確認してください。以下の順でテストし、問題が再発した段階に戻って調べましょう。最初からアンインストールをやり直す必要はありません。

1. 初期状態で起動：古いデータをインポートせず、起動と終了を2回続けて行い、ウィンドウ、タスクトレイ、バックグラウンドプロセスの動作が毎回同じか確認します。
2. 設定を1つだけ追加：正常と確認できたサブスクリプションをインポートし、設定が選択されているか、コアが正常に読み込まれるか確認します。
3. システムプロキシ：実際の待ち受けポートを確認し、システムプロキシを有効にして普段使うWebサイトにアクセスします。リクエストが接続ログに記録されるか確認してください。
4. カスタムルール：上書き設定、スクリプト、ルールセットを1つずつ戻します。問題が再発したら、今回追加した項目とエラー行を記録してください。
5. TUNとサービス：最後に有効にし、他のVPN、仮想ネットワークアダプター、企業向けネットワークソフトとの競合がないか確認します。

問題を報告する際は、OSのバージョンとアーキテクチャ、クライアントとコアのバージョン、インストール方法、発生時刻、再現手順、初期設定でも再現するか、関連ログを添えてください。サブスクリプションURL、ノードのアドレス、パスワード、コントロールキー、個人情報を含むパスは削除します。「初期設定では起動するが、特定の上書き設定を戻すと失敗する」のように説明すると、「起動直後に落ちる」とだけ伝えるより原因を特定しやすくなります。