v2rayNのコア起動トラブルを解決

起動失敗と接続失敗を見分ける

v2rayNは設定・管理用の画面で、実際に接続を確立するのは選択したコアです。メイン画面が開いていても、コアが動作しているとは限りません。ブラウザーでページを開けない場合も、コアの起動失敗とは限りません。timeoutが表示されたからといってクライアントを再インストールすると、本当の原因を見落とすことがあります。

メイン画面下部のログまたは情報欄を開き、起動時に出力されたエラーの流れを一通り保存します。画面構成はDesktop版とWPF版で異なります。クライアントの「起動失敗」という通知だけでなく、コアの出力を確認してください。エラー内の>は、原因を階層ごとにつないで表示するために使われることがあります。先頭の概要より、末尾の記述のほうが具体的な場合が多いです。

条件を固定して一度だけ再現する

サーバーやコアを何度も切り替えたり、ルーティングを変更したりすると、ログが混在します。現在使用中のコア、サーバーの種類、ローカル待ち受けポートを記録してから、一度だけ再現してください。以下の手順は一般的な日本語UIを想定しています。メニュー構成が異なる場合は該当する設定項目を探し、別バージョンのフォルダー構成をそのまま当てはめないでください。

1. 現在の設定を記録する

   メイン画面で現在のサーバーとルーティングモードを記録します。「設定」→「パラメーター設定」を開き、ローカル待ち受けポートを控えます。続いて「Coreタイプ」関連の設定を確認し、使用するプロトコルにどのコアが選択されているかを確認してください。

2. システムプロキシを一時解除する

   トレイメニューの「システムプロキシ」から「システムプロキシをクリア」を選びます。システムプロキシの接続先を解除する操作であり、コアの問題を修復するものではありません。トラブルの調査中に、ほかのアプリが使えないローカルポートへアクセスし続けるのを防げます。

3. 一度分のログを保存する

   まず既存のエラーをコピーしてから、ログ表示をクリアするか時刻を記録します。サーバーを再度選択して有効にし、新しい起動ログを確認してください。サブスクリプションの更新や一括テストは同時に実行しないでください。

4. エラーに応じて修正する

   一度に変更するのは1項目だけにします。保存してコアを再起動し、最初に出る具体的なエラーが変わったか確認してください。待ち受けが復旧したら、システムプロキシを再設定して実際のリクエストをテストします。

ポート競合：待ち受け中のプロセスを調べる

ログにbind、listen tcp、または「通常、各ソケット アドレスに対して使用できるのは 1 回のみです」といったメッセージがある場合は、まずローカルポートを確認します。別のv2rayNのプロセスや、前回終了した際に残ったコアプロセスがポートを使用している可能性があります。エラーの表現はOSによって異なるため、文言の完全一致ではなく、待ち受けアドレスとポートを確認してください。

Windowsのコマンドプロンプトで次のコマンドを実行します。ポート番号は「設定」→「パラメーター設定」に表示されている実際の値に置き換えてください。出力ではローカルアドレス、LISTENINGの状態、最後の列のPIDを確認します。リモートアドレスにその番号が含まれているだけでは、ローカルポートが使用中とは判断できません。

netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"

• 「タスク マネージャー」→「詳細」を開き、PIDから該当するプログラムを探します。必要に応じてPID列を表示し、実行ファイルの場所も確認してください。
• 別のクライアントが使用している場合は、そのクライアントを通常の手順で終了します。正体が分からないPIDを強制終了しないでください。
• ほかのプログラムがそのポートを使う必要がある場合は、「設定」→「パラメーター設定」でローカル待ち受けポートを変更し、保存してコアを再起動します。
• 変更後は、プロキシのポートを手動で設定しているブラウザーやツールの設定も更新してから、システムプロキシを再設定します。すべてのアプリが自動的に追従するとは限りません。

設定項目：エラーの流れから原因を特定する

failed to load configだけでは、JSONの形式、ユーザーID、プロトコルの互換性のどれが原因か判断できません。通常のサーバー設定は画面から実行用設定が生成されるため、サーバーの編集画面に戻って修正してください。カスタム設定を使っている場合に限り、対応する元ファイルを直接確認します。起動時に生成されるファイルは次回起動時に上書きされることがあるため、恒久的な修正箇所には適しません。

コアの種類が異なる場合、「VLESS」という表記が同じだからといって互換性があるとは限りません。トランスポート方式、セキュリティ層、flowなどのパラメーターもすべて一致させる必要があります。これらの項目を手動で変更した場合は、まずサブスクリプションの元の設定に戻し、サーバー側の要件を一つずつ確認してください。セキュリティ層を暗号化なしに変える方法は、一般的な解決策ではありません。

• 通常のサーバー：メイン画面で使用中のサーバーを編集し、アドレス、ポート、ユーザーID、トランスポート、TLSの設定を確認します。
• カスタム設定：JSONの構文と項目の階層を確認します。別のコアで使えるという理由だけで、設定値をそのまま流用しないでください。
• サブスクリプションから生成された設定：必要なバックアップを取ってからサブスクリプションを再更新し、問題が再現するか確認します。サーバーの手動変更は、次回の更新で上書きされることがあります。

コアファイル：パスとアーキテクチャを確認する

プロセスの作成時に「指定されたファイルが見つかりません」と表示される場合、通常はまだ設定の解析に進んでいません。この段階でサーバー設定を繰り返し変更しても意味はありません。ログに表示された実行ファイルのパスを確認し、選択中のコアファイルが存在するか調べてください。特定バージョンのbinディレクトリ構成を、すべてのバージョンに共通するルールとして扱わないでください。

アーカイブのプレビュー画面からメインプログラムを直接実行しないでください。また、メインプログラムだけを取り出して、ほかのフォルダーを残さない状態にしないでください。調査を始める前にクライアントを終了し、ユーザー設定をバックアップします。そのうえで、プログラム一式を新しい専用フォルダーにすべて展開して動作を確認してください。新しいフォルダーでは起動でき、元のフォルダーでは起動できない場合は、ユーザーデータをすぐにすべて上書きせず、ファイルと権限の違いを引き続き調べます。

ルールファイル：欠落・タグ・パスを切り分ける

特定のルーティングモードを有効にした場合だけ起動に失敗し、エラーにgeoip.dat、geosite.dat、geoip:、geosite:が含まれる場合は、ルール関連のリソースを確認します。ルールファイルはIPアドレスやドメインの分類に使われます。存在しない分類タグを参照している場合も、起動後に通信を振り分けられないだけでなく、設定の読み込み段階で起動が止まることがあります。

• 現在のルーティング設定をバックアップしてから、最近追加したGeo分類を参照するカスタムルールを一時的に無効にし、そのルールを無効にするとエラーが消えるか確認します。
• 名前が違うだけで同じ不足リソースを参照するルーティングモードに切り替えても解決しません。テスト用の設定がエラー対象のリソースに依存していないことを確認してください。
• 外部ルールファイルのパスは、ログと実際の設定を基準に確認してください。コマンドラインから起動したコアと、クライアントから起動したコアでは、リソースの検索環境が異なる場合があります。
• リソースを復旧したら元のルールを再度有効にし、起動できるかだけでなく、対象の通信が想定したアウトバウンドに振り分けられるかも確認します。

復旧確認とよくある質問

修復できたかどうかは、ログ欄から赤い文字が消えたかでは判断できません。コアが動作し続け、想定したポートで待ち受け、実際のリクエストが期待する経路を通ることを確認します。まず1つのアプリでテストし、その後、プロキシに依存するほかのツールを戻してください。複数のプロキシ設定を同時に追加しないでください。