Clash Vergeが起動直後にクラッシュする場合の対処法：ログの場所・残存設定・ポート競合

画面の終了・コアの起動失敗・バックグラウンド動作を切り分ける

「Clash Vergeが開かない」といっても、デスクトップ画面が作成されない、mihomoコアが起動しない、またはトレイでは動作中なのにメインウィンドウが表示されないなど、原因となる箇所は異なります。ポート競合は通常、まずコアに影響し、デスクトップアプリ全体の終了につながるとは限りません。まずプロセスの状態を確認し、設定を見直すか実行環境を修復するか判断しましょう。

この記事では、主にWindows版のClash Verge Revを対象にトラブルシューティングします。旧版のClash VergeとClash Verge Revは別の開発系統で、設定フォルダーやメニュー名が異なる場合があります。デスクトップのショートカット名だけでバージョンを判断しないでください。ウィンドウを開ける場合は、「設定」→「バージョン情報」で完全なバージョン番号を控え、Windowsのバージョン、システムアーキテクチャ、直近の変更内容も記録します。以下のポート番号は例です。実際の値は使用環境の設定を確認してください。

症状	まず確認すること	次の手順
メインウィンドウが表示されないが、トレイアイコンは残っている	バックグラウンドプロセスとウィンドウの状態	複数のインスタンスを続けて起動せず、トレイからウィンドウを再表示する
画面は開くが、コアの起動に失敗する	コアのログ、設定の解析、待ち受けポート	最初のエラーを確認してから、設定またはポートを対処する
プロセスが表示された直後に終了する	アプリのログ、Windowsのアプリケーションイベント	ランタイム、権限、障害が発生したモジュールを確認する
画面が真っ白、または読み込みが終わらない	画面の実行環境、フロントエンドとバックエンドの通信	WebView2とアプリのログを確認する

まずプロキシを経由しないネットワーク接続を復旧する

クライアントを終了した後にウェブページも開けなくなった場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」を確認します。プロキシがこのクライアントによって設定されたもので、対応するローカルの待ち受けが停止していることを確認してから、「プロキシサーバーを使う」をオフにしてください。たとえば、システムのプロキシ先が 127.0.0.1:7890 のままなのに、そのポートを待ち受けるプログラムがなければ、システムプロキシを使うアプリは接続に失敗することがあります。

ログの場所：起動時刻に記録された最初のエラーを探す

画面を開ける場合は、「設定」にある設定フォルダーやログフォルダーへのリンクを優先して使いましょう。ボタン名は配布版によって多少異なることがあります。フォルダー名から場所を推測するより確実です。起動できない場合は、OSのデータフォルダーから探します。

Windowsでよく使われるデータフォルダー

Clash Verge Revのユーザー設定ルートフォルダーは、通常次の場所です。Win + Rを押してパスを貼り付け、Enterキーを押します。見つからない場合は、%APPDATA%を開き、フォルダーの更新日時を参考に実際に使われている開発系統を探してください。

%APPDATA%\io.github.clash-verge-rev.clash-verge-rev

通常、このフォルダーには logs、profilesや複数のYAMLファイルがあります。ログのサブフォルダーやファイル名はバージョンによって変わるため、「直前に起動した時刻」を基準に並べ替えて確認してください。どのバージョンにも同じ名前のログがあるとは限りません。旧版のClash Vergeでは、io.github.clash-verge.clash-vergeがデータフォルダーに使われる場合がありますが、インストール方法によって異なることもあります。

アプリのログ：画面の初期化、ファイルの読み書き、サービスとの通信、バックグラウンド起動時の異常を確認します。
コアのログ：YAMLの解析、ルールプロバイダーの読み込み、DNSの待ち受け、ポートのバインド失敗を確認します。
システムイベント：アプリのログが更新されていない場合は、Win + Rを押してeventvwr.mscと入力し、「Windowsログ」→「アプリケーション」を開きます。同じ時刻のエラーを探し、障害が発生したアプリケーションとモジュールの名前を記録してください。

macOSのアプリデータは通常 ~/Library/Application Support/、Linuxでは ~/.config/から探します。正確な場所はクライアントの設定画面、アプリ識別子、配布パッケージの説明で確認してください。Windowsのパスを他のOSにそのまま当てはめないでください。

末尾の行ではなく、エラーのキーワードから原因を分類する

一度再現させてから、その起動時に記録された最初の明確なエラーを確認します。後続の「コアに接続できません」は、先行する設定解析の失敗やポート競合の結果かもしれません。エラーの前後約20行を保存すると、1行だけの切り抜きより原因を特定しやすくなります。

address already in useまたはbind：待ち受けアドレスとポートを優先して確認します。
yaml、unmarshal、parse：設定の構文、フィールドの型、マージ後の内容を優先して確認します。
permission deniedまたはAccess is denied：拒否されたファイル、サービス、デバイス操作を確認します。
WebView2やシステムイベントにランタイムの異常が記録されている場合は、画面の実行環境を調べます。プロキシルールは先に変更しないでください。

残存設定や破損ファイルへの対処：バックアップして最小構成で起動する

クライアントを再インストールしてもクラッシュする場合、ユーザーデータフォルダーが残っていることがよくあります。インストーラーが更新するのはプログラムファイルであり、サブスクリプションのインデックス、画面の状態、オーバーライド設定までは初期化されない場合があります。すべてのファイルをすぐ削除するのではなく、古いデータを切り離して起動を確認しましょう。

全体をバックアップしてから、設定フォルダーを切り離す

トレイからクライアントを終了します。タスクマネージャーで関連するデスクトッププロセスが終了したことを確認してください。バックグラウンドサービスがある場合は、クライアントが提供する方法で停止します。出所のわからないシステムプロセスは終了しないでください。
ユーザーデータフォルダー全体を別の場所にコピーしてバックアップします。バックアップにはサブスクリプションURLやキーが含まれる可能性があるため、アクセス権を適切に制限してください。
元のデータフォルダーの名前を変更します。たとえば、フォルダー名の末尾に .backup-20260915を追加します。元の内容は復元できるよう、そのまま残してください。
同じクライアントを再起動します。通常は初期データが作成されます。まずサブスクリプションをインポートせず、TUNも有効にせず、画面と基本的なコアが正常に起動するかだけ確認してください。

初期状態のデータで起動できた場合、原因は古い設定または状態に絞られます。それでも終了する場合は、新しく生成されたログを残し、実行環境の確認を続けてください。すぐに古いフォルダー全体を戻すと、同じ問題が再発する可能性があります。

サブスクリプション、オーバーライド、TUNの順に戻す

まず信頼できるサブスクリプションを1つだけ戻し、コアが起動することを確認します。次にルール、設定のマージ、スクリプトを1つずつ戻し、最後にTUNとサービスの設定を復元します。項目を戻すたびに再起動して確認してください。サブスクリプションの元ファイルを解析できても、オーバーライド適用後の最終設定が有効とは限りません。

YAMLのインデントにはスペースを使い、タブは使わないでください。リスト項目のハイフンと、コロンの後のスペースも確認します。
ポート欄に文字列を誤入力していないか、配列を文字列として記述していないか、ポリシーグループが存在しないノードやグループを参照していないか確認してください。
カスタムルールの末尾にあるポリシーグループ名が、現在のサブスクリプションと完全に一致していることを確認します。
古いコアの設定を移行する場合は、現在のmihomoが対応するフィールドか確認してください。旧バージョンで解析できたからといって、現行バージョンでも互換性があるとは限りません。

コマンドラインで確認する場合は、最終設定のコピーに対してコアの設定テストを実行できます。以下のコマンドは、現在のフォルダーに対応するmihomoの実行ファイルとconfig.yamlがあることを前提としています。設定を検証するもので、常駐プロキシは起動しません。

.\mihomo.exe -t -f .\config.yaml

できるだけクライアントが実際に使用しているバージョンと同じコアでテストしてください。ルールプロバイダーや外部ファイルを含む設定は、作業フォルダーやリソースのパスにも依存します。そのため、コマンドラインの結果はクライアントのログとあわせて確認してください。サブスクリプションの元ファイルをテストした結果を、マージ後の最終設定のテスト結果と混同しないでください。

ポート競合：待ち受けプロセスを特定してから設定を変更する

よくある競合は、HTTP/SOCKS混合プロキシのポート、コントローラーのポート、ローカルDNSを有効にした場合のDNS待ち受けポートです。以下では 7890と9090を例に調べます。すべてのClash Verge Revのバージョンで既定値というわけではありません。

WindowsでPIDとプログラム名を確認する

PowerShellで以下のコマンドを実行します。1つ目は指定したポートでTCP待ち受け中のプロセスとPIDを表示し、2つ目はPIDからプログラムを特定します。例の4321は、実際に確認したPIDに置き換えてください。

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

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path

結果にポートが表示されない場合、確認時点で該当するTCP待ち受けがなかったことを示します。DNSなどのUDP競合を調べるには、UDPも確認してください。たとえば、実際の設定が1053の場合：

Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

待ち受けているのが別のプロキシクライアントなら、そのクライアントとバックグラウンドサービスを通常の手順で終了します。現在のクライアントのコアが待ち受けている場合は、複数起動しているか、サービスモードが動作中の可能性があります。プロセスのパス、起動時刻、ログを確認し、mihomoという名前だけを見て強制終了しないでください。権限が不足していると、結果にプログラムのパスが表示されない場合があります。

プロキシポートを変更したらシステム設定も更新する

どうしても同時に起動する必要がある場合は、片方のクライアントの混合ポートを7890から、使用されていない7897などに変更します。変更は現在のバージョンの設定画面または永続化されるオーバーライドから行い、次回起動時に再生成されるファイルだけを編集しないでください。

ポートを変更した後、そのクライアントのシステムプロキシを一度オフにしてから再びオンにします。ブラウザー、コマンドラインの環境変数、その他のアプリに手動で設定されたプロキシアドレスも確認してください。コントローラーのポートはHTTPプロキシとして使えません。アプリのプロキシ先を9090に設定しても、そのポートで待ち受けているだけでは通信できるとは限りません。

ランタイム、権限、TUNサービスを段階的に確認する

コアの起動前に画面が終了する：WebView2とシステムイベントを確認

Windows版Clash Verge Revの画面はWebView2に依存します。ウィンドウが真っ白になる、または作成直後に終了するうえ、イベントやログにWebView2が記録されている場合は、Windowsの「設定」→「アプリ」→「インストールされているアプリ」でMicrosoft Edge WebView2 Runtimeを確認してください。Microsoftの公式インストーラーと、使用中のクライアントのリリースノートに従って修復またはインストールし、アプリを再起動します。

VCRUNTIME140.dllやMSVCP140.dllなど、明確な不足を示すエラーがある場合に限り、Microsoft Visual C++ 2015–2022 Redistributableも確認し、エラーが発生したプログラムのアーキテクチャに合うパッケージを選んでください。DLL配布サイトからファイルを単独でコピーしたり、あらゆるクラッシュを同じランタイムの問題と決めつけたりしないでください。

通常の起動は成功し、TUNを有効にすると失敗する：サービス層を確認

TUNモードでは仮想ネットワークアダプター、ルーティング、高い権限が関係します。システムプロキシとは別の設定です。TUNをオフにすると画面とコアが正常に動作する場合は、サブスクリプションを削除し続けるのではなく、クライアントのサービス、仮想ネットワークアダプターの初期化、他のVPNとのルート競合を調べてください。

TUNをオフにし、通常のプロキシモードで接続できることを確認します。
クライアントの「設定」でサービスモードの状態を確認し、現在のバージョンで提供されるインストールまたは修復の手順を実行します。
他のVPNや仮想ネットワークアダプターを制御するツールを一時的に終了します。業務用ネットワークソフトの設定は必要に応じて維持してください。
TUNを再び有効にし、今回の失敗に対応する最初のサービスまたはコアのエラーを確認します。

修復後の動作確認と再発時の記録

ウィンドウが開くのは最初の一歩にすぎません。修復後は、コア、待ち受け、設定の復元、終了後のネットワーク状態を確認してください。変数を一度に1つずつ戻すことで、サブスクリプション、オーバーライド、ポート、サービスのどれが原因か判断できます。

コールドスタート：通常の手順で終了してから再起動し、ウィンドウとトレイの状態が一致すること、ログに起動エラーが繰り返し記録されていないことを確認します。
設定の読み込み：初期状態の空の設定のままではなく、現在のサブスクリプション、ポリシーグループ、ルールが読み込まれていることを確認します。
待ち受けとリクエスト：実際のプロキシポートを確認し、クライアントの接続履歴で対象、ルール、ポリシーグループが想定どおりか確認します。
TUNの個別確認：TUNが必要な場合にのみ有効にし、対象アプリのネットワーク接続とDNSの動作を確認します。「システムプロキシが使える」ことをTUNの動作確認済みとみなさないでください。
終了後の復旧：クライアントを終了した後、システムプロキシが停止中のローカルポートを参照したままになっていないことを確認します。

再発する場合は、クライアントの完全なバージョン番号、コアのバージョン、OSのバージョン、インストール方法、再現手順、機密情報を伏せたログをまとめてください。「新しいデータフォルダーでも再現するか」「TUNをオフにすると再現するか」「どのプロセスがポートを待ち受けているか」を明記すると、「起動するとすぐ落ちる」という説明だけより原因を特定しやすくなります。インストールと設定の手順は使い方ガイド、用語の違いは用語集を参照してください。