この記事では、Windowsでv2rayNのメイン画面が起動しない場合の対処法を解説します。まず、タスクトレイで動作中なのか、デスクトップアプリがクラッシュしたのか、コアの起動に失敗したのかを切り分けます。そのうえで、イベント ビューアーとランタイム設定から原因を特定します。起動時の状態を記録し、配布パッケージとランタイム、フォルダーのアクセス権を確認してから、旧設定を切り離す順で進めてください。ノードやサブスクリプション、ルーティング規則を先に変更する必要はありません。
まず確認：画面が表示されないのか、プロセスが終了したのか
ダブルクリックしても画面が表示されないからといって、必ずしもクラッシュとは限りません。v2rayNはタスクトレイで動作している場合や、すでに起動しているため二重起動できない場合があります。Ctrl + Shift + Escでタスク マネージャーを開き、「詳細」タブでv2rayN.exeを探してください。タスクバー右側の隠れているインジケーターも確認します。トレイにアイコンがあれば、そこからメイン画面を再表示してください。何度もダブルクリックして起動を繰り返すのは避けましょう。
| 症状 | まず確認すること | 次の手順 |
|---|---|---|
| プロセスはあるが画面が表示されない | タスクトレイ、起動済みのプロセス、ウィンドウの位置 | ウィンドウを再表示する。必要なら終了してから起動し直す |
| プロセスが一度表示されてすぐ消える | ランタイム、例外ログ、設定の読み込み | 終了時刻を記録し、イベント ビューアーを確認する |
| メイン画面は開くが、コアでエラーが出る | コアのファイル、ポートの競合、生成された設定 | クライアント下部のログを確認する。デスクトップ ランタイムは再インストールしない |
| Windowsにブロックの警告が表示される | ファイルの入手元、セキュリティ履歴、組織のポリシー | 配布パッケージの入手元を確認し、ブロックの具体的な理由を調べる |
デスクトップ画面と、XrayやV2Rayなどのコアは別のプロセスです。メイン画面が開いていて、ログにポートの待ち受け失敗が記録されている場合は、別の手順で対処します。一方、メインプログラムの初期化が完了していない段階では、VMess、VLESS、Trojanのノードを切り替えても起動時のクラッシュは解決しません。
起動時の状態を記録：イベント ビューアーで例外を確認
まず、時刻を記録しながら一度だけ起動を試します。「クリックしても反応しない」という情報より、Windowsのイベントログのほうが原因を特定しやすい場合があります。Win + Rを押し、eventvwr.mscと入力して、「Windowsログ」→「アプリケーション」を開きます。起動を試した時刻と一致する記録を探してください。
-
時刻を記録する
プログラムを一度だけダブルクリックし、PCの時刻を記録します。約10秒待ってからタスク マネージャーを開き、プロセスが残っているか、終了したかを確認します。
-
イベントを絞り込む
「Windowsログ」→「アプリケーション」→「現在のログをフィルター」で「エラー」を選択します。ソースが「.NET Runtime」または「Application Error」の記録を確認してください。
-
プロセスを確認する
イベントの「全般」タブを開き、障害が発生したアプリケーションがv2rayNであることを確認します。イベント ID 1026や1000は手掛かりになりますが、番号だけで原因を判断することはできません。
-
情報を保存する
例外の種類、障害モジュール、アプリケーションのパス、関連ファイルのパスを記録します。共有する前に、ユーザー名、サブスクリプションURL、サーバーアドレス、認証情報を隠してください。
-
既存のフォルダーを残す
プログラムと関連するコアを終了し、現在のプログラムフォルダー全体をバックアップします。ログに別のユーザーデータフォルダーが示されている場合は、そちらもバックアップしてください。古い設定を直接上書きしたり削除したりしないでください。
アプリケーションのフォルダーにguiLogsなどのログ用フォルダーがある場合は、更新日時を見て最新のファイルを確認します。名前や保存場所はバージョンやパッケージ形式によって異なることがあります。アプリケーションログが生成されていなくても、クラッシュが起きていないとは限りません。ログ機能の初期化前に例外が発生した可能性もあるため、その場合はWindowsのイベントログを優先して確認してください。
.NETランタイム：配布パッケージの要件を確認して導入
v2rayNは、バージョンやデスクトップ版のビルドによって必要な依存関係が異なります。外部ランタイムに依存するパッケージと、ランタイムを同梱したパッケージは区別してください。古い解説にある特定のメジャーバージョンをそのままインストールするのではなく、現在のパッケージの説明を確認してから、プログラムフォルダー内のv2rayN.runtimeconfig.jsonを確認します。このファイルがある場合は、frameworkまたはframeworksの下にあるnameとversionを確認してください。
You must install or update .NET to run this application.
原因：起動ホストが、プログラムの要件を満たすランタイムを見つけられていません。対処：表示されたFramework、Architecture、バージョンの要件に合わせて依存関係を追加し、プログラムを完全に終了してから再度起動します。
BadImageFormatException
原因：アーキテクチャが合わない、または破損したアセンブリやネイティブコンポーネントを読み込んでいる可能性があります。対処：システムとプログラムパッケージのアーキテクチャを確認し、例外に記載されたファイルを調べます。新しい完全なフォルダーを使って比較テストしてください。
要件にMicrosoft.WindowsDesktop.Appと記載されている場合は、通常、対応するアーキテクチャの.NET Desktop Runtimeが必要です。.NET RuntimeやASP.NET Core Runtimeだけでは代用できません。Microsoft.NETCore.Appと記載されている場合は、そのビルドの要件に従ってください。GUIアプリだからといって、Windows Desktop Runtimeが必ず必要とは限りません。
# 解凍したv2rayNのフォルダーでPowerShellを開く
Get-Content .\v2rayN.runtimeconfig.json
# 現在のコマンドで使われるdotnetホストが認識できるランタイムを確認する
dotnet --list-runtimes
# このdotnetホストの環境とアーキテクチャの情報を確認する
dotnet --info- アーキテクチャを確認：Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。ファイル名が似ているだけで、x64版とARM64版を置き換えて使うことはできません。
- メジャーバージョンを確認：新しいメジャーバージョンをインストールしても、古いメジャーバージョンが必要とするランタイムを満たすとは限りません。メジャーバージョン間の互換性は、プログラムのランタイム設定によって決まります。
- SDKとの違いに注意：アプリケーションの実行にフルSDKは通常必要ありません。ランタイム不足の解消に、開発ツールのインストールは必須ではありません。
- コマンドの意味を確認：
dotnetが認識されない場合、ホストがインストールされていないか、PATHにその場所が含まれていない可能性があります。それだけで、自己完結型パッケージが実行できないと判断することはできません。
フォルダーのアクセス権：完全に解凍して書き込みをテスト
圧縮ファイルのプレビュー画面からプログラムを実行すると、メインプログラムだけが一時的に展開され、依存ファイルが不足する場合があります。古いフォルダーに何度も上書きして更新すると、互換性のないコンポーネントが残ることもあります。まず、パッケージ全体を解凍し、ユーザーフォルダー内に作成したApps\v2rayN-testなど、現在のアカウントで書き込み可能なローカルフォルダーに配置してください。新旧のファイルを混在させないようにします。
UnauthorizedAccessException
原因：対象のファイルやフォルダーへのアクセス権が不足しているか、保護された場所が関係している可能性があります。対処：まず例外に記載された完全なパスを確認し、現在のアカウントで書き込み可能なフォルダーで試します。その後、セキュリティソフトのブロック履歴を確認してください。
The process cannot access the file because it is being used by another process.
原因：別のプロセスがファイルを使用中です。対処：重複して起動したプロセスや古いコアを終了し、対象フォルダーの同期を一時停止してから再度試します。プログラムの実行中に設定を置き換えないでください。
- 対象のフォルダーにテキストファイルを作成して削除し、基本的な書き込みができるか確認します。このテストに成功しても、すべてのサブフォルダーで問題がないとは限りません。例外に記載されたパスと照らし合わせてください。
- 「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、該当時刻にブロックがあったか確認します。すべての保護機能を無効にすることは、通常の対処法として推奨されません。
- コントロールされたフォルダー アクセスを使用している場合は、ブロックされたプログラムのパスを確認します。入手元とファイルの用途を確認してから、システムの案内に従って必要な範囲だけ許可してください。
- 同期フォルダー、ネットワーク共有、ローカルフォルダーから複数のコピーを同時に起動するのは避けてください。切り分け中は、場所が明確なテスト用フォルダーを1つだけ使用します。
設定の破損：クリーンなフォルダーで比較する
例外にJsonException、データベースの読み込みエラー、設定のデシリアライズ失敗が記録されている場合は、ローカルデータの確認を優先します。突然の電源断、プロセスの強制終了、異なるバージョンによる交互の読み書きなどが原因で、設定を読み込めなくなることがあります。ノードへの接続失敗だけでは、クライアントの設定ファイルが破損しているとは限りません。
- 古いプロセスを終了する。タスクトレイから終了します。画面を操作できない場合は、タスク マネージャーで関連プロセスが終了していることを確認してください。
- 元のデータをバックアップする。現在のフォルダーと、実際に使用しているユーザーデータフォルダーをコピーします。バックアップに認証情報が含まれる場合があるため、安全な場所に保存してください。
- 新しいフォルダーを作成する。同じ入手元の完全なプログラムパッケージを新しい場所に解凍します。初回のテストでは、古い設定、サブスクリプションのデータベース、カスタムルーティングをコピーしないでください。
- 結果を比較する。新しいフォルダーから起動できる場合は、古いフォルダーのファイルや設定に原因がある可能性が高くなります。新しい環境でも終了する場合は、ランタイム、システムイベント、セキュリティによるブロックを確認してください。
- 設定を1つずつ戻す。まず必要なサブスクリプションを戻し、次にルーティング、DNS、その他の設定を戻します。項目を1つ戻すたびに終了して起動し直し、どの設定で問題が起きるか確認してください。
ビルドによってはユーザーフォルダーにデータを保存するため、プログラムのフォルダーを変更しても同じ設定が読み込まれる場合があります。新しいフォルダーでも同じ症状が出る場合は、ログやそのバージョンの説明でデータの保存場所を確認してください。バックアップを取り、プログラムを終了してから、該当する設定フォルダーの名前だけを変更します。ユーザー設定フォルダー全体をまとめて削除しないでください。新しいバージョンで保存したデータを古いバージョンで読み込めるとは限らないため、プログラムを戻すときはアップグレード前のバックアップを使用してください。
メイン画面が復旧したら、コアとプロキシを確認
メイン画面が安定して開くようになったら、ネットワーク関連の問題に進みます。デスクトッププログラムの依存関係、コアの依存関係、ルーティング設定は、それぞれ別の問題です。まずTUNを無効にしたままコアが起動することを確認し、その後にシステムプロキシや既存の設定を1つずつ有効にすると、どの手順で問題が起きたか判断しやすくなります。
| 確認項目 | 操作 | 判断時の注意点 |
|---|---|---|
| 待ち受けポート | 「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。実際に表示されている項目を基準にしてください。 | すべてのバージョンで同じポートが使われているとは限りません。 |
| ポートの競合 | 設定したポートが10808の場合は、以下のコマンドでPIDを確認します。 | ポートが待ち受け中でも異常とは限りません。想定したコアのプロセスか確認してください。 |
| システムプロキシ | Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を確認します。 | 接続先アドレスとポートが、現在のクライアントの待ち受け設定と一致している必要があります。 |
| TUNモード | 基本的なプロキシが動作してから有効にし、権限とコアのログを確認します。 | 仮想ネットワークアダプターのエラーと、デスクトップランタイム不足は分けて対処します。 |
# ローカルの待ち受けポートが10808に設定されている場合のみ使用
netstat -ano | findstr ":10808"
# タスク マネージャーの「詳細」タブで、最後の列のPIDとプロセスを照合v2rayNが異常終了した後にブラウザーでウェブページを開けなくなった場合、PC内を指す手動プロキシの設定が残っている一方で、ローカルの待ち受けが停止している可能性があります。現在の設定を記録してから、Windowsのプロキシ設定で該当する手動プロキシを確認し、無効にしてください。組織のポリシーで管理されている設定は、無断で変更しないでください。ネットワークが復旧しても、クラッシュが解決したとは限りません。終了、再起動、コアの起動まで確認してください。
よくある質問：再インストール、管理者権限、サブスクリプションの復元
.NETをインストール済みなのに、ランタイム不足と表示されるのはなぜですか？
起動時のメッセージに記載されたフレームワーク名、バージョン、アーキテクチャを再確認してください。通常のRuntimeとDesktop Runtimeは別物で、x64とARM64も異なります。dotnet --list-runtimesで確認できますが、どのアーキテクチャのホストがコマンドで呼び出されているかにも注意してください。
管理者として実行すれば開く場合、そのまま使い続けてもよいですか？
まず例外に関係するパスを確認し、パッケージ全体を現在のユーザーが書き込めるフォルダーに配置して、通常の権限で起動してください。TUNを有効にしたときだけ権限が必要な場合は、その権限要件とメイン画面の読み書き権限を分けて対処します。
設定を削除して復旧した場合、サブスクリプションは戻せますか？
バックアップからサブスクリプションURLと必要なパラメーターを保管し、新しい設定に再登録してください。古いデータベース全体をすぐに上書きすると、問題が再発するおそれがあります。バックアップがない場合は、さらに復元を試みる前に古いフォルダーを残してください。
何度再インストールしても直りません。次にどんな情報を用意すればよいですか？
Windowsのバージョンとアーキテクチャ、プログラムパッケージの種類、ランタイムの一覧、正確な障害時刻、イベント ビューアーに記録された例外の種類と障害モジュールをまとめてください。クリーンなフォルダーから起動できたかどうかも添えると、「最新版でもすぐ落ちる」という情報だけの場合より原因を特定しやすくなります。
最終確認では、通常の権限でメイン画面を開けること、終了後に再び起動できること、必要な機能を有効にしても起動時の例外が繰り返されないことの3点を確認します。まずクライアントの起動経路を修復してから、サブスクリプション、DNS、ルーティングを戻してください。関係のない変更を減らせるため、今後のアップグレードで新たな問題が起きた場合も切り分けやすくなります。