この記事の要点

v2rayNをダブルクリックするとウィンドウが消える、アップデート後に起動しない、画面は表示されるもののコアがすぐ終了する、といった場合に向けた手順です。まず終了したのが画面かコアかを見分け、ログを保存してから、ランタイム、書き込み権限、ユーザー設定、待ち受けポートの順に確認します。主にWindowsでの操作を説明し、Linuxのターミナルでの確認方法も紹介します。最初からデータフォルダー全体を削除しないでください。

画面のクラッシュとコアの終了を見分ける

v2rayNはクライアントの画面で、プロキシ接続は呼び出されたコアが処理します。画面の起動失敗と、Xrayなどのコアの起動失敗は別の問題です。VMessとVLESSは接続プロトコル、サブスクリプションは設定の取得元です。接続処理が始まる前の画面クラッシュは、通常、サブスクリプションの変更やプロトコルの切り替えでは解決しません。

確認できる症状まず確認する項目保存しておく情報
ウィンドウが表示されず、プロセスもすぐ終了するランタイム、プログラムのアーキテクチャ、起動時の異常システムのエラーダイアログ、イベントビューアーの記録
ウィンドウは閉じたが、タスクトレイのアイコンは残っているタスクトレイに最小化されていないかタスクマネージャーに表示されるプロセスの状態
画面は表示されるが、ログに起動失敗が繰り返し記録されるコアのファイル、生成された設定、待ち受けポートコアのエラーログ全文
画面とコアは正常だが、Webページを開けないシステムプロキシ、ルーティング、DNS、ノード接続ログとアプリのプロキシ設定

Ctrl + Shift + Escを押してタスクマネージャーを開き、v2rayNのプロセスが残っているか確認します。タスクトレイに最小化されているだけなら、アイコンをダブルクリックしてウィンドウを表示します。実際に終了している場合は発生時刻を控え、Win + Rを押してeventvwr.mscと入力します。「Windowsログ」→「アプリケーション」を開き、同じ時刻の「.NET Runtime」または「Application Error」の記録を確認してください。障害が発生したモジュール、例外の種類、ファイルパスを記録します。

.NETランタイム:エラーに合ったフレームワークとアーキテクチャを確認

.NETのインストールを求めるダイアログが表示されたら、まずフレームワーク名、必要なバージョン、アーキテクチャを含むメッセージ全体を確認します。外部ランタイムが必要なパッケージと、自己完結型パッケージでは対処方法が異なります。特定の.NETメジャーバージョンがすべてのv2rayNパッケージに必須とは限らず、新しいメジャーバージョンを入れれば古いプログラムも必ず動くとは限りません。

You must install or update .NET to run this application.

原因:プログラムが必要とする.NETランタイムを検出できていません。対処法:ダイアログに表示されたフレームワーク、バージョン、アーキテクチャに合うランタイムをインストールして、プログラムを再起動します。自己完結型パッケージを使っている場合は、システムに合ったパッケージを改めてすべて解凍してください。

PowerShellで次のコマンドを実行し、現在呼び出せるdotnetホストがどのランタイムを認識しているか確認します。dotnetコマンドが見つからない場合でも、現在のコマンド環境から見つからないというだけで、すべてのアーキテクチャのランタイムが未インストールとは限りません。Windowsの「インストールされているアプリ」とエラーダイアログも確認してください。

dotnet --info
dotnet --list-runtimes

Linuxでは、まずターミナルで解凍先のディレクトリーに移動し、プログラムを起動してエラーを確認します。Permission deniedと表示されたら実行権限を確認し、共有ライブラリーが不足している場合は該当する依存関係を解決してください。WindowsのDesktop Runtimeのインストール手順をそのままLinuxで実行しないでください。

cd ~/Applications/v2rayN
ls -l ./v2rayN
chmod u+x ./v2rayN
./v2rayN

Linuxのコマンド例では、プログラムが実際に~/Applications/v2rayNに置かれているものとします。ファイルの入手元とファイル名が正しいと確認してから、実行権限を付与してください。権限を修正しても、アーキテクチャの不一致やシステムライブラリーの不足は解決しません。

フォルダー権限:実際のデータ保存先に書き込めるか確認

v2rayNは起動時に、設定、ログ、データベース、一時的なコア設定ファイルを書き込むことがあります。プログラムファイルを読み込めても、ユーザーデータフォルダーに書き込めるとは限りません。ポータブル版を保護されたフォルダーに置く、圧縮ファイル内から起動する、読み取り専用のバックアップを作業フォルダーに戻す、といった操作で初期化時にエラーが起きる場合があります。

  1. 終了してバックアップ

    タスクトレイのプログラムを終了し、タスクマネージャーでプロセスが停止したことを確認します。元のプログラムフォルダーと実際のデータフォルダーをコピーし、元のログも保存してください。唯一のデータを使って何度も試さないでください。

  2. すべてのファイルを解凍

    ポータブル版は、現在のユーザーのDocuments\v2rayN-testなどに解凍してテストできます。圧縮ソフトのプレビュー画面からメインプログラムを起動したり、実行ファイルだけを取り出したりしないでください。

  3. 書き込みを確認

    ログに記録されたデータフォルダーにテキストファイルを作成し、保存してから削除します。フォルダーを右クリックして「プロパティ」→「セキュリティ」を開き、現在のユーザーを選択して「書き込み」と「変更」の権限を確認します。

  4. ブロックの有無を確認

    「Windowsセキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、プログラムやコアがブロックされていないか確認します。入手元を確認したうえで、該当するファイルだけを対象に対処してください。セキュリティ機能全体を無効にしないでください。

  5. 通常の権限で起動

    新しいフォルダーから通常のユーザー権限で起動します。画面が開いたら、「設定」→「パラメーター設定」でローカルの待ち受けポートを記録します。メニュー項目はバージョンによって異なるため、実際の画面表示を確認してください。

管理者として起動した場合だけ動くなら、管理者権限での常用を解決策にせず、元のプログラムフォルダーとデータフォルダーのアクセス制御を確認してください。通常のローカルプロキシでは、画面の起動に管理者権限は通常不要です。TUNモードは仮想ネットワークアダプターやルーティングの権限に関わるため、基本の起動を復旧してから別途テストしてください。

設定の破損:ユーザーデータを退避してから一つずつ戻す

アップデートの中断、強制終了、手動での設定変更などにより、JSONの解析エラーやデータベースの読み込みエラーが発生することがあります。画面の設定、サブスクリプションのデータベース、コアが生成する設定ファイルは別のデータです。コアのログでフィールドが無効と表示されても、すべてのサブスクリプションを削除する必要があるとは限りません。画面がデータベースを読み込めない場合も、VLESSのパラメーターを変更して解決するとは限りません。

System.Text.Json.JsonException

原因:JSONの読み込み時に形式やデータ型の問題が発生しています。エラーに続くパスと行番号を手掛かりに原因を特定してください。対処法:エラーに記載されたファイルを先にバックアップし、同じバージョンで新規作成した設定と比較します。内容の分からないファイルをむやみに消さないでください。

database is locked

原因:別のプロセスがデータベースを使用中か、書き込み処理が完了していない可能性があります。破損しているとは限りません。対処法:重複して起動したインスタンスを終了し、プロセスの停止を確認してから再試行します。データベースを開いたままファイルを移動したり、関連ファイルを削除したりしないでください。

初期状態で起動でき、特定の設定を戻すと終了する場合は、問題をそのデータ群に絞り込めます。VMessやVLESSのノードでは、そのノードで実際に使われているトランスポートとセキュリティの設定だけを確認してください。TLS、トランスポート層、ルーティングの項目を互いに置き換えないでください。複雑なルーティング設定は、基本の接続を復旧してから設定ガイドを参考に一つずつ確認できます。

ポート競合:PIDを特定してからプロセス終了かポート変更を判断

ローカルの待ち受けポートが競合すると、プロキシコアの起動に失敗することがありますが、v2rayNの画面が終了するとは限りません。ログにaddress already in useやバインド失敗が表示されたら、まず「設定」→「パラメーター設定」でローカルの待ち受け設定を確認してください。以下では10808と10809を例に使いますが、すべてのバージョンで両方のポートが有効とは限りません。

10808
ローカル待ち受けポートの確認例
10809
別の待ち受けポートの確認例
20808
変更候補のポート。使用前に空き状況を確認

PowerShellで、指定したTCP待ち受けポートを使用しているプロセスを確認します。実際の設定で別のポートを使っている場合は、そのポート番号に置き換えてください。結果が表示されない場合は、今回の検索で該当するTCP待ち受けが見つからなかったことを意味します。UDPやほかのアドレスファミリーの状況まで確認できたわけではありません。

Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in 10808,10809,20808 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Name v2rayN -ErrorAction SilentlyContinue

OwningProcessに表示された数値を使い、タスクマネージャーの「詳細」タブでPIDに対応するプロセス名とパスを確認します。以前起動したv2rayNのインスタンスだと分かった場合は、まずタスクトレイのメニューから正常に終了してください。見覚えのないPIDを見つけても、システムサービスを強制終了しないでください。必要な別のプログラムがポートを使用中なら、v2rayNの該当する待ち受けポートを空いている値に変更し、コアを再起動します。

要点:競合している待ち受けポートだけを変更

元の待ち受けポートを20808に変更した場合は、ブラウザーの手動プロキシ設定、ターミナルのプロキシ環境変数、古いポートを参照するほかのアプリも合わせて変更します。システムプロキシを有効にしている場合は、設定し直して実際のプロキシアドレスを確認してください。サーバー側のポートとローカルの待ち受けポートは別なので、同時に変更しないでください。

Linuxでは次のコマンドで対象ポートの待ち受け状況を確認できます。ポートが使用されていないのにバインドに失敗する場合は、権限不足、待ち受け先アドレスの不在、セキュリティポリシーによる制限がログにないか確認してください。ポートを次々に変更しても、これらの問題は特定できません。

ss -ltnp 'sport = :10808'
ss -ltnp 'sport = :10809'
ss -ltnp 'sport = :20808'

起動復旧後の確認とよくある質問

ウィンドウが再び表示されても、それで解決とは限りません。まず既定のルーティングか最小限の設定にし、動作確認済みのノードを選んで、コアのログが安定するか確認します。その後、システムプロキシを有効にしてブラウザーで接続をテストします。サブスクリプションの更新、カスタムDNS、ルーティングルール、TUNは、一度に一つずつ戻してください。再発時に原因を特定して元に戻しやすくなります。

.NETを入れても起動直後に終了する場合、次に何を確認すればよいですか?

ダイアログに表示されたフレームワークとアーキテクチャを確認し、dotnet --list-runtimesを実行します。ランタイム不足の表示がない場合は、「Windowsログ」→「アプリケーション」にある例外の記録を確認してください。関係のない複数のメジャーバージョンを次々にインストールしないでください。

新しいフォルダーに移したのに、古い設定が読み込まれるのはなぜですか?

プログラムが独立したユーザーデータフォルダーを使っている可能性があります。ログに記載された実際のパスを確認し、終了後にそのフォルダーをバックアップしてから、元に戻せる形で隔離してテストしてください。プログラムファイルを移動しただけでは、新しい設定が作成されるとは限りません。

設定をすべて削除すれば一度で解決しますか?

サブスクリプション、ノード、ルールが失われるうえ、本当の原因が分からなくなることもあります。まずバックアップし、エラーに記載されたデータだけを優先して隔離してください。初期状態で正常に動くと確認してから、設定を分けて戻します。唯一のバックアップをそのまま消さないでください。

画面は正常で、TUNを有効にしたときだけ失敗する場合は?

まずTUNを無効にし、ローカルプロキシでノードとコアが動作するか確認します。通常のプロキシが正常なら、TUNの権限、仮想ネットワークアダプター、ルーティングのログを確認してください。この症状を画面のランタイムの問題と決めつけないでください。

解決しない場合は、OSのバージョンとアーキテクチャ、v2rayNの実際のバージョン、パッケージの種類、発生時刻、直前に変更した内容、機密情報を除いた最初のエラーを整理してください。エラーの前後のログも残し、サブスクリプションURL、UUID、パスワード、接続先アドレスは伏せてください。情報をまとめたうえでよくある質問も確認すると、「起動しない」とだけ伝えるより次の手順を特定しやすくなります。