v2rayNが起動時にクラッシュする・開かない場合の対処法：.NETランタイム、macOSの権限と隔離属性を確認

まず、画面のクラッシュかコアの起動失敗かを切り分ける

v2rayNはデスクトップクライアントです。画面のプロセスがサブスクリプション、ノード、設定を管理し、選択したコアがプロキシ接続を処理します。ウィンドウは開くもののログにコアの終了が記録されるケースと、ダブルクリックしてもウィンドウがまったく表示されないケースは別の問題です。VLESSやVMessの設定、サブスクリプションURLに誤りがある場合は、画面が起動してから確認しましょう。最初からすべてのノードを削除する必要はありません。

まず、WindowsのタスクマネージャーまたはmacOSのアクティビティモニタでv2rayNを検索します。プロセスが残っている場合は、タスクトレイやメニューバーを確認し、ウィンドウが隠れているだけかどうかを調べてください。プロセスを終了する必要がある場合は、クライアントのものと確認できたプロセスだけを終了し、一度再起動してエラーの全文と発生時刻を記録します。

Windows：.NETデスクトップランタイムとインストーラーのアーキテクチャを確認

Windowsでランタイムに関する警告が表示されても、「.NETをインストール済み」というだけでは必要な依存関係がそろっているとは限りません。.NET Runtime、ASP.NET Core Runtime、.NET Desktop Runtimeでは提供されるコンポーネントが異なります。Windowsデスクトップフレームワークに依存するビルドには、対応するデスクトップランタイムが必要です。別のUIを使ったビルドや自己完結型パッケージでは要件が異なる場合があるため、使用中のパッケージの説明と起動時のメッセージを確認してください。

1. OSの種類を確認

   「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。x64とARM64は異なるアーキテクチャです。プロセッサのメーカーだけでインストーラーを判断しないでください。

2. 必要なフレームワークを確認

   アプリのフォルダーにv2rayN.runtimeconfig.jsonがある場合は、テキストエディターで開き、frameworkまたはframeworksを確認します。たとえばMicrosoft.WindowsDesktop.Appのバージョンが8.0.0なら、対応する.NET 8デスクトップランタイムを確認します。これは見分け方の例であり、すべてのバージョンが.NET 8に依存するという意味ではありません。

3. インストール済みのフレームワークを一覧表示

   ターミナルで次のコマンドを実行し、フレームワーク名とメジャーバージョンを照合します。dotnetが見つからない場合、共有ランタイムが未インストールの可能性も、PATHの設定に問題がある可能性もあります。自己完結型パッケージは、システムにランタイムをインストールしなくても動作する場合があります。

4. 終了時の記録を確認

   Win+Rを押してeventvwr.mscと入力し、「Windowsログ」→「Application」を開きます。同じ時刻に記録された「.NET Runtime」または「Application Error」のイベントを探し、例外の種類と障害モジュールを記録してください。

dotnet --list-runtimes
dotnet --info

圧縮ファイルから実行ファイルだけを取り出して起動しないでください。設定、依存関係、リソースのフォルダーが欠けていると、起動に失敗することがあります。まずはアプリ一式を、現在のユーザーが書き込めるローカルフォルダーに置いて試してください。通常の書き込みエラーを「管理者として実行する必要がある」と誤解しないようにしましょう。システムの保護履歴にファイルの隔離が記録されている場合は、入手元と検出内容を確認し、保護機能全体を無効にしないでください。

macOS：隔離警告、署名エラー、実行権限を切り分ける

Macで表示される「開発元を検証できません」「破損しています」「アクセス権がありません」は、すべて同じコマンドで解決できるわけではありません。まずAppleメニューの「このMacについて」でチップを確認し、対応するmacOS用インストーラーを選びます。アプリをディスクイメージから「アプリケーション」フォルダーにコピーしてから起動してください。読み取り専用のディスクイメージから使い続けたり、イメージ内で上書き更新したりしないでください。

以下のコマンドは、実際のインストール先が/Applications/v2rayN.appである場合の例です。Finderに表示されるアプリ名が異なる場合は、先に実際のパスを確認してください。最初の2つのコマンドでアーキテクチャと拡張属性を読み取り、残りで署名とシステムのセキュリティ評価を確認します。アプリは変更されません。

uname -m
xattr -l "/Applications/v2rayN.app"
codesign --verify --deep --strict --verbose=2 "/Applications/v2rayN.app"
spctl --assess --type execute --verbose=4 "/Applications/v2rayN.app"

arm64はAppleチップのネイティブアーキテクチャ、x86_64はIntelアーキテクチャです。セキュリティ評価で拒否された理由は、出力全体を確認して判断してください。公証の有無とアプリファイルの改変は別の問題です。入手元を確認できない場合や、署名チェックでリソースの破損が明示されている場合は、対処を続けず、ファイルを再取得してください。

xattr -dr com.apple.quarantine "/Applications/v2rayN.app"

コマンドで権限不足が表示されても、すぐに管理者権限を付けて実行しないでください。別のアカウントでアプリがインストールされていないか確認し、必要なら権限のあるアカウントから再インストールします。クラッシュ記録を確認するには、「コンソール」→「クラッシュレポート」を開き、アプリ名と時刻で記録を探してください。共有する前に、ユーザー名、個人用フォルダー、サーバー情報が含まれている場合は削除します。

Linux：ターミナルから起動し、不足している依存関係を補う

Linuxでデスクトップアイコンをダブルクリックしても反応しない場合、再インストールするよりターミナルの出力を確認するほうが有効です。まずuname -mを実行してアーキテクチャを確認し、ディストリビューションとパッケージ形式を照合します。Debian系では通常DEB、RPM系のパッケージ管理を採用するディストリビューションでは対応するRPMを選びます。パッケージ形式が合っていても、OSのバージョンやランタイムの依存関係が満たされているとは限りません。

• パッケージでインストールする場合：ディストリビューションのソフトウェアインストーラーまたはパッケージマネージャーを使い、依存関係エラーの出力を保存してください。Debian系ではsudo apt --fix-broken installを実行して、インストール済みソフトウェアの依存関係を修復できます。実行を確定する前に、インストールまたは削除される項目を確認してください。
• 展開して実行する場合：ファイルマネージャーでメインプログラムの実際のファイル名を確認し、そのフォルダーに移動してターミナルから起動します。配布パッケージ内のファイル名を推測したり、同じフォルダーにある依存ファイルを省いてメインプログラムだけをコピーしたりしないでください。
• グラフィカルセッション：現在デスクトップにログインしているユーザーのターミナルから起動してください。リモートのGUIなしセッションで実行した場合、ディスプレイサービスへの接続失敗はクライアントファイルの破損を意味しません。この問題を回避するために、rootでデスクトップアプリを起動しないでください。

uname -m
cat /etc/os-release
dotnet --list-runtimes
journalctl --user -b -n 80 --no-pager

最後のコマンドは、今回の起動に関するユーザーログの末尾80件だけを表示します。クライアントのエラーが記録されているかどうかは、起動方法によって異なります。ターミナルに直接表示された出力も保存してください。GLIBC_2.xx not foundのようなバージョン要件が表示された場合、システムの基幹Cライブラリを手動で上書きしないでください。互換性のあるビルドを選ぶか、ディストリビューションの手順に沿ってOSをアップグレードします。

ウィンドウは開くが接続できない場合：ポート、コア、TUNを確認

ここまで進んでいる場合、デスクトップアプリ自体は動作しています。.NETのインストールを続けるのではなく、コアのログを確認してください。Xrayの設定エラー、ノードパラメーターの不足、ローカルの待ち受けポートの競合などにより、「ウィンドウは表示されるが接続できない」状態になることがあります。Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。インストール方法やデスクトップ版の起動依存関係とは異なるため、デスクトップ版向けのランタイム対処をそのまま適用しないでください。

ログにTCPポート10808のバインド失敗が明記されている場合、Windowsでは最初のコマンドを、macOSまたは必要なツールをインストール済みのLinuxでは2つ目のコマンドを使用できます。ここで示すポート番号は例であり、すべてのバージョンで標準的に使われるとは限りません。まずログに記載された実際の番号を確認してください。

netstat -ano | findstr ":10808"
lsof -nP -iTCP:10808 -sTCP:LISTEN

• address already in useまたはOnly one usage of each socket addressと表示された場合は、まずポートを使用しているプロセスを特定します。重複して起動したクライアントであれば、余分なインスタンスを終了してください。正体の分からないシステムプロセスを終了しないでください。
• 待ち受けポートを変更した後は、アプリ内で手動入力したプロキシアドレスも確認してください。システムプロキシとアプリ内プロキシの設定は別です。古いポートが残っていると、「コアは正常なのに、特定のアプリだけネットにつながらない」状態になることがあります。
• TUNを有効にした後にだけ失敗する場合は、まずTUNを無効にして通常のプロキシモードで試します。TUNには追加のネットワークインターフェースと権限が必要です。クライアントのフォルダー全体に書き込み権限を付与しても解決しません。
• ログに特定のコアファイルを実行できないと記録されている場合は、そのファイルが隔離されていないか、完全か、アーキテクチャが合っているかを確認してください。別バージョンのコアファイルを組み合わせて、現在のインストールに上書きしないでください。

最後に設定を切り分け、復元できるバックアップを残す

同じインストーラーが新しい設定では起動し、古い設定を読み込むと終了する場合に限り、設定の互換性やローカルデータの破損を詳しく調べます。上書きインストールではユーザーデータが自動的に削除されないことが一般的です。そのため、「再インストールしてもクラッシュする」からといって、インストールファイルに問題がないとも、ユーザーフォルダー全体を消す必要があるとも限りません。

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

   クライアントを完全に終了し、使用中のパッケージの説明とエラーログをもとにデータフォルダーを確認して、フォルダー全体をバックアップ先にコピーします。プラットフォームやインストール方法によって保存場所は異なるため、共通のパスだと決めつけてファイルを削除しないでください。

2. アプリのデータを分離

   新しいアプリを別の場所に配置します。パッケージがアプリのフォルダー内にデータを保存すると明記している場合に限り、別の場所への展開でデータを分離できます。同じユーザーデータフォルダーを読み込む場合は、先にバックアップを取り、対象と確認できたデータフォルダーの名前を変更して残してください。

3. 設定を1つずつ戻す

   まず空の設定で起動と正常終了を確認し、次にサブスクリプショングループを1つ戻します。その後、ルーティングなどの設定を復元してください。古いフォルダー全体を上書きすると、障害の原因となった内容まで戻ってしまいます。

4. トラブル記録を整理

   OSのバージョン、CPUアーキテクチャ、インストーラーの種類、エラーの発生時刻、エラーメッセージ全文を記録します。ログを共有する前に、サブスクリプションURL、ノードの認証情報、UUID、プライベートなドメイン名、個人用パスを伏せてください。例外名とスタックトレースの位置は残します。

新しい設定でもクラッシュする場合は、最小限の再現条件を保ちます。インストールのみ行い、サブスクリプションを追加せず、TUNも有効にせずに、終了時の情報を記録してください。その後、よくある質問を確認して原因をさらに絞り込めます。安定して起動するようになったら、使い方ガイドに沿ってサブスクリプション、システムプロキシ、ルーティングを復元してください。すべての詳細設定を一度に戻す必要はありません。