v2rayNをダブルクリックしてもウィンドウが表示されない、表示直後に終了する、または画面は開くのにコアが起動しない場合に向けた記事です。まず本体とコアを切り分け、ランタイム、展開先フォルダー、セキュリティソフト、書き込み権限、古い設定の順に確認します。Windowsを中心に、macOSとLinuxでの確認ポイントも紹介します。コマンドは確認例として示しているため、実際の状況は手元のログで判断してください。
1. まず確認：本体がクラッシュしたのか、コアが起動していないのか
v2rayNはノード、サブスクリプション、システムプロキシ、コアのプロセスを管理するデスクトップクライアントです。実際の通信処理はXrayまたはv2flyのコアが担います。両者は別のプロセスなので、コアが終了してもメインウィンドウまで閉じるとは限りません。また、本体が起動しないからといって、ノードに問題があるとも限りません。確認の順序を誤ると、ランタイムの問題なのにサブスクリプションを再インポートすることになりかねません。
| 症状 | まず確認する項目 | まだ変更しない項目 |
|---|---|---|
| ダブルクリックしてもウィンドウもタスクトレイアイコンも表示されない | .NETランタイム、システムのアーキテクチャ、イベントビューアー | サブスクリプションURLとノード設定 |
| ウィンドウが表示されてすぐ消える | アプリケーションエラー、フォルダーの権限、古い設定の読み込み | 接続先サーバーの設定 |
| 画面は正常だが、ログにコアの終了が記録される | コアのファイル、ポートの競合、生成された設定 | 本体のランタイム |
| ウィンドウは見えないが、タスクマネージャーにプロセスが残っている | タスクトレイ、既存のプロセス、ウィンドウの位置 | すぐにクラッシュと決めつけない |
「タスクマネージャー」→「詳細」から、v2rayN.exeが実行中か確認します。タスクバーの隠れているインジケーターも確認してください。ウィンドウを閉じただけで、タスクトレイに最小化されている場合があります。すでにプロセスがある場合は、タスクトレイのメニューから終了してから、もう一度起動します。何度も連続でダブルクリックすると、複数の起動処理が重なり原因を追いにくくなるため避けてください。
2. .NETランタイム不足：バージョンだけでなくフレームワーク名を確認
フレームワーク依存のパッケージでは、必要な.NETランタイムをあらかじめインストールしておく必要があります。一方、自己完結型のパッケージには通常ランタイムが含まれています。「PCに.NETを入れたことがある」だけでは判断できません。.NET Framework 4.8と現行の.NETランタイムは別のもので、x64用とARM64用のパッケージも互換ではありません。
プログラムのフォルダーにあるv2rayN.runtimeconfig.jsonを確認します。このファイルがあれば、runtimeOptions内のframeworkまたはframeworksを確認してください。たとえばMicrosoft.WindowsDesktop.Appと8.0.0が記載されている場合、対応するアーキテクチャの.NET 8 Windows Desktop Runtimeが必要です。ここでの8.0.0はフィールドの例であり、現在配布されているすべてのv2rayNパッケージに共通する要件ではありません。
dotnet --list-runtimesターミナルで上記のコマンドを実行します。デスクトップフレームワークが必要なパッケージでは、Microsoft.NETCore.Appが表示されても、デスクトップランタイムがそろっているとは限りません。対応するMicrosoft.WindowsDesktop.Appも確認してください。コマンド自体が見つからない場合も、自己完結型パッケージが動かないと即断せず、起動時のメッセージとパッケージの種類を確認します。
エラー：You must install or update .NET to run this application.
原因：起動時に、アプリが必要とするフレームワークまたはアーキテクチャが見つかりません。対処：メッセージに表示されたFramework、Version、Architectureに合うランタイムをインストールし、v2rayNを完全に終了してから再起動します。
エラー：The framework 'Microsoft.WindowsDesktop.App' was not found.
原因：Windowsデスクトップランタイムが必要なパッケージで、対応するフレームワークが見つかりません。対処：通常の.NET Runtimeだけでなく、必要なメジャーバージョンのWindows Desktop Runtimeをインストールします。
エラー：This app can't run on your PC
原因：プログラムのアーキテクチャ、システムとの互換性、ファイル破損などが考えられます。ランタイム不足に限ったメッセージではありません。対処：まず「設定」→「システム」→「バージョン情報」でシステムの種類を確認し、対応するパッケージを選んで再度展開します。
デスクトップ環境のバージョンによって必要なフレームワークは異なるため、あるWindows向けパッケージの要件をすべてのプラットフォームに当てはめることはできません。新しいメジャーバージョンをインストールしても、古いメジャーバージョンの要件を満たすとは限りません。異なるバージョン間で動作するかはアプリの設定によります。ネット上の「最新版を入れればよい」という説明ではなく、エラーメッセージとパッケージに含まれるランタイム設定を確認してください。
3. 展開先とファイルの状態：書き込み可能な短いパスで試す
圧縮ファイルのプレビューからメインプログラムを直接ダブルクリックしないでください。起動時に本体だけが一時展開され、同じフォルダーにある依存ファイル、リソース、コアがそろわない場合があります。また、新しいパッケージのファイルを古いフォルダーに一部だけ上書きするのも避けてください。ファイル名が同じでも、古い依存ファイルと新しいプログラムが正常に組み合わせられるとは限りません。
-
古いプロセスを終了する
タスクトレイからv2rayNを終了し、「タスクマネージャー」→「詳細」で古い本体のプロセスが終了したことを確認します。どのアプリのものか確認できないプロセスは終了しないでください。
-
元のフォルダーを残す
元のフォルダー全体をコピーしてバックアップします。バージョンによってユーザーデータが別の場所に保存されている場合は、実際のデータフォルダーもバックアップしてください。サブスクリプションURLやノードの認証情報は機密情報です。
-
圧縮ファイル全体を展開する
ダウンロードセンターから適切なパッケージを選び、圧縮ファイル全体を現在のユーザーが書き込み可能な短いパスに展開します。例：
%USERPROFILE%\Apps\v2rayN-test。メインプログラムだけを取り出さないでください。 -
新しいフォルダーで起動を試す
まず古い設定をコピーせず、新しいフォルダーにあるメインプログラムを起動します。空の画面が開けば、少なくともランタイムと基本的な起動処理は正常です。
日本語のフォルダー名が必ずクラッシュの原因になるわけではなく、空白も通常は問題なく扱えます。ただし、呼び出し処理やエスケープ方法、長すぎるパスによって問題が起きることはあります。短いパスで試すのは原因を切り分けるためであり、「日本語のパスは使えない」という意味ではありません。短いパスで起動する場合は、元のフォルダーのパス長、権限、同期状態、特殊文字を比較してください。
4. セキュリティソフトによる隔離：防護機能全体を無効にせず、対象ファイルを確認
メイン画面は開くのに、ノードを選ぶとコアがすぐ終了する場合は、パッケージに必要なコアのファイルが残っているか確認してください。セキュリティソフトがダウンロード時、展開時、初回実行時にファイルを隔離すると、画面は正常でもコアのプロセスを起動できないことがあります。サブスクリプションを変更しても、ローカルの実行ファイルは復元されません。
- Windows標準の保護機能：「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、エラーが発生した時刻の記録を確認します。
- その他のセキュリティソフト：隔離領域、動作ブロック、アプリ制御の記録を確認し、対象が本体かコアかを特定します。
- 会社の管理対象デバイス：組織のポリシーによるブロックが記録されている場合は、管理者に問い合わせてください。ポリシーを自分で削除したり、アプリ制御を回避したりしないでください。
- ファイルを復元する前に：パッケージの入手元、ファイルの場所、ブロックされた理由を確認します。不審な動作が疑われる場合は実行を中止し、信頼できる配布元からパッケージを再取得してください。
エラー：The system cannot find the file specified.
原因：呼び出されたコア、依存ファイル、またはパスが存在しない可能性があります。対処：エラーの前後関係から対象のファイルを特定し、展開結果と隔離履歴を確認します。信頼できるファイルを復元するか、パッケージ全体を展開し直してください。
エラー：Access is denied.
原因：ファイルへのアクセス、実行権限、セキュリティポリシーによって処理がブロックされています。対処：まずアクセスを拒否されたファイルまたはフォルダーを特定し、権限とセキュリティ履歴を確認してください。このメッセージだけでセキュリティソフトの誤検知とは判断できません。
許可ルールを追加する必要がある場合は、確認済みのプログラムまたはフォルダーに対象を限定し、利用中のセキュリティポリシーに従って設定してください。ドライブ全体を除外対象にしたり、一度起動するためにリアルタイム保護を恒久的に無効にしたりしないでください。起動の問題は原因となっている箇所を修正し、必要以上に防護を外さないようにしましょう。
5. 権限とポート：管理者としての実行は万能な解決策ではない
通常のシステムプロキシモードでは、管理者権限で常時実行する必要はありません。TUNモードでは仮想ネットワークインターフェースやルートの操作が必要なため、バージョンやシステム環境によっては昇格が必要です。本体の問題とTUNの問題を切り分けるには、メイン画面で「TUNを有効にする」をオフにし、通常の権限で起動を試します。TUNを有効にした場合だけ失敗するなら、モードに必要な権限とログを確認してください。
通常の権限では起動に失敗し、管理者として実行すると開く場合は、まずデータフォルダーへの書き込み権限を確認します。エクスプローラーで対象フォルダーにテキストファイルを新規作成すると、書き込み可否を簡単にテストできます。ユーザーが書き込めるフォルダーでは正常で、保護されたフォルダーでは失敗するなら、管理者としての実行を常時有効にするのではなく、プログラムとデータを別の場所に移してください。
netstat -ano | findstr :10808
tasklist /FI "PID eq 4321"上記の10808はポート確認の例です。まず「設定」→「パラメーター設定」に表示されているローカルの待ち受けポートを確認してください。1つ目のコマンドでポートの使用状況を調べます。2つ目の4321はPIDの例なので、実行時は1つ目の出力の末尾にある実際の値に置き換えてください。リモート側のポートが一致しても、ローカルの待ち受けポートが使用中とは限りません。ローカルアドレスの列とLISTENINGの状態を確認します。
エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：待ち受け先のアドレスとポートがすでに使用されています。古いコアが終了していない場合や、プロセスが重複している場合によく発生します。対処：ポートを使用しているプロセスを特定して終了するか、「設定」→「パラメーター設定」でローカルの待ち受けポートを変更し、コアを再起動してください。
ポートを変更したら、ブラウザー、ターミナル、その他のアプリで手動設定したプロキシポートも合わせて変更してください。システムプロキシの接続先とコアの待ち受けポートを一致させる必要があります。メインウィンドウが正常で、コアにバインドエラーが記録されている場合は、コアの起動失敗として対処してください。.NETのインストールを続けても解決しません。
6. 古い設定とクラッシュログ：証拠を残してから切り分ける
アップデート後にクラッシュし、新しいフォルダーからは起動できる場合は、古いデータや残存する依存ファイルを優先して確認します。元のフォルダーは残し、データベース、設定、サブスクリプションをすぐに削除しないでください。起動時の問題より、ノードの認証情報を失った場合のほうが復旧に時間がかかります。
- エラーが発生した時刻を分単位で記録します。「イベント ビューアー」→「Windowsログ」→「アプリケーション」を開き、同じ時刻のアプリケーションエラーまたは.NET Runtimeのイベントを確認します。
- 障害が発生したアプリケーション名、障害モジュール、例外コード、例外メッセージを記録します。イベントID 1000や1026は手掛かりになりますが、クラッシュのたびに必ず記録されるわけではありません。
- プログラムのログが生成されている場合は、実際のログフォルダーを更新日時で並べ替え、新しいファイルを確認します。保存場所はバージョンによって異なるため、決まった一つのパスだけを探さないでください。
- まず新しい空のフォルダーから起動できることを確認し、その後、クライアントの画面からノード、サブスクリプション、設定を一つずつ復元します。古いフォルダー内のファイルをすべて一度に上書きしないでください。
- ある種類のデータを復元した後に再び失敗したら、インポートを中止し、その時点のログとバックアップを残します。一度に復元するデータの種類を一つに絞ると、問題の引き金を特定できます。
空のフォルダーから起動するテストでも、共有ユーザーデータを古い場所から読み込んでいないか確認してください。パッケージによってデータの保存先は異なり、バージョンや起動方法によって別のユーザーデータフォルダーが使われる場合があります。新しいプログラムフォルダーを用意しても、設定環境まで新しくなるとは限りません。今回のログとバージョン情報から実際の読み込み先を確認し、プログラムを終了してから該当データをバックアップし、切り分けてください。
macOS・Linuxでの追加確認
どちらのプラットフォームでも、まずアーキテクチャとパッケージの種類を確認し、ターミナルからインストール済みの実際のプログラムを起動して標準エラー出力を確認します。LinuxでPermission deniedが表示された場合は、起動ファイルの実行権限と、マウント先で実行が制限されていないかを確認してください。フォルダー全体にすべてのユーザーの書き込み権限を再帰的に付与しないでください。macOSでシステムによるブロックが表示された場合は、「システム設定」→「プライバシーとセキュリティ」で具体的なメッセージを確認し、信頼できるアプリに限ってシステムの手順に従って対処します。
- ターミナルに共有ライブラリ不足と表示された場合は、正確なライブラリ名を記録し、利用中のディストリビューションのパッケージ管理方法で依存関係を補います。他のシステムのライブラリファイルを適当にコピーしないでください。
- デスクトップのアイコンからは起動できず、ターミナルからは起動する場合は、起動項目に設定された実際のパスと作業ディレクトリーを確認します。まずコアを再インストールする必要はありません。
- メイン画面は開くがコアが動作しない場合は、選択したコアが本機のアーキテクチャに対応しているか、ログに記録されたパスにファイルが実在するかを確認します。
7. よくある質問：修復後に正常か確認する
.NETをインストール済みなのに、ランタイムがないと表示されるのはなぜですか？
dotnet --list-runtimesを実行し、起動時のメッセージにあるフレームワーク名、メジャーバージョン、アーキテクチャと照らし合わせます。Microsoft.WindowsDesktop.Appが必要なパッケージでは、Microsoft.NETCore.Appだけをインストールしても不足する場合があります。.NET Framework 4.8をインストール済みでも、代わりにはなりません。
再インストールしてもクラッシュします。設定をすべて削除したほうがよいですか？
まずバックアップを取り、書き込み可能な別のフォルダーでテストし、古いデータの保存先を引き続き読み込んでいないか確認します。新しい環境で起動できたら、データを一つずつ移行してください。新しい環境でも失敗する場合は、ランタイムとイベントログを引き続き確認します。サブスクリプションを削除しても、通常はプログラムの依存関係の問題は解決しません。
管理者としてなら起動するのに、通常のダブルクリックでは起動できないのはなぜですか？
まず「TUNを有効にする」をオフにし、フォルダーへの書き込み権限を確認してから、現在のユーザーが書き込める場所に移します。TUNモードだけで管理者権限が必要な場合は、そのモードの要件に従ってください。通常モードでも権限昇格が必要なら、アクセスを拒否されたパスまたはセキュリティポリシーを確認します。
画面は開きますが、Webページが表示されません。修復できていますか？
確認できたのは、本体の起動が復旧したことだけです。次に、コアのログで正常に待ち受けているか確認し、「システムプロキシ」→「システムプロキシを自動設定」と現在のルーティング設定を確認してください。アプリの通信がプロキシを経由しているか、ノードに接続できるかは、その後に行う接続のトラブル対処です。起動時のクラッシュと混同しないでください。
修復後、すぐにOS起動時の自動起動を設定してもよいですか？
まず手動で一度終了し、再度起動してから、サインアウトまたは再起動して動作を確認します。メイン画面、コア、ログが正常だと確認できたら、「設定」→「パラメーター設定」で該当する自動起動オプションを有効にします。手動起動は正常でログイン時の起動だけ失敗する場合は、起動項目のパス、作業ディレクトリー、権限の違いを比較してください。
最後に3点を確認します。通常の権限で繰り返し起動できること、選択したコアが起動直後に終了しないこと、クライアント終了後に古いプロセスとローカルの待ち受けポートが解放されることです。正常に動作したバージョン、フォルダー、対処手順を記録しておけば、次回アップデートで似た症状が起きても、正常時の状態と比較して調査を始められます。