V2Rayコアが起動しないときの対処法|v2rayNのログで設定エラーを特定

起動に失敗したら、まずログを確認。ポート競合、JSON構文エラー、未対応フィールド、ルールファイルの不足を見分け、順番に修正する方法を解説します。

この記事の概要

v2rayNが起動していても、通信を担うコアが動作しているとは限りません。起動直後に終了する、再起動を繰り返す、ローカルプロキシのポートが待ち受け状態にならない場合は、デスクトップ版のログを確認しましょう。起動ログをもとにポート、設定の構文、コアの互換性、ルール用リソースを順に調べ、ローカルの待ち受けと実際のリクエストで修復を確認します。ノードを何度も切り替える必要はありません。

1. コアの起動失敗と接続失敗を見分ける

v2rayNはクライアントの画面で、V2RayやXrayは設定の解析、待ち受けの開始、プロキシ通信の処理を担うコアです。画面にサーバー一覧が表示されていても、クライアント側のデータを読み込めているだけの場合があります。コアのプロセスが終了すると、ローカルプロキシの接続先も使えなくなることがあります。この段階では、システムプロキシの設定変更や速度テストを繰り返しても、起動エラーは解決しません。

メイン画面下部のログ欄で、直近の起動記録を確認します。ログ欄が折りたたまれている場合は、該当するパネルを開いてください。パネル名はバージョンによって異なることがあります。起動時刻、コア名とバージョン、最初のエラー、終了時の情報を記録し、特にfailed、error、ファイルパス、ポート番号を含む行は全文を残します。「起動失敗」という最後の一文だけを切り取らないでください。

設定を生成 設定を読み込み ルールを読み込み 待ち受けを開始 リクエストを処理

この流れは障害の発生段階を切り分けるための目安であり、すべてのコアが必ず同じ順序で処理するわけではありません。設定の読み込み、ルール用リソースの読み込み、待ち受けの開始に失敗した場合は、リモート接続の確認より先に対処します。一方、コアが動作を続けてポートも待ち受け中なのに、アクセス時にi/o timeoutやハンドシェイクエラーが出る場合は、ノードのアドレス、ネットワーク、トランスポート、安全性の設定を確認しましょう。

2. ポート競合:使用中のプロセスを確認して待ち受け設定を変更

ポート競合は、以前のコアが終了していない、クライアントを二重に起動した、別のローカルサービスが同じポートを使っているときによく発生します。以下では127.0.0.1:10808を例に確認します。この数値は説明用で、現在のインストール環境の既定値ではありません。「設定」→「パラメータ設定」で実際のローカル待ち受けポートを確認し、コマンド内の数値を置き換えてください。

10808
例:現在のローカルプロキシポート
10818
例:空きが確認できた変更先ポート
127.0.0.1
このPCからのみ接続するループバックアドレス

エラー例:bind: address already in use

原因:指定したアドレスとポートが、別の待ち受けプロセスに使用されています。エラー行のTCPまたはUDPも確認してください。

対処法:ポートを使用しているプロセスを特定し、重複して起動したインスタンスを正常終了します。または空いていることを確認したポートに変更し、固定ポートを指定しているアプリの設定も合わせて変更してください。

エラー例:Only one usage of each socket address

原因:Windowsでよく見られるソケットのバインド競合です。通常、エラー行には待ち受けアドレスも表示されます。

対処法:エラー行にあるアドレスを使っているプロセスを確認します。エラーのない別のインバウンドポートだけを変更しないようにしてください。

Windows PowerShellで、まず次のコマンドを実行します。出力のOwningProcessはプロセスIDです。2つ目のコマンドでプロセス名と、取得できる場合は実行ファイルのパスも確認できます。最初のコマンドで結果が返らなくても、その時点で該当するTCPの待ち受けがないことを示すだけです。UDPの競合やシステム予約ポートの問題までは否定できません。

Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess } |
  Select-Object Id, ProcessName, Path

Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

判断のポイント:所有者を確認してから終了する

終了操作は、使用中のプロセスが残存コアまたは重複インスタンスだと確認できた場合に限ります。別のサービスが使っている場合は、先にクライアントのポートを変更してください。エラーがアドレス競合ではなくアクセス権限に関するものなら、予約ポートやセキュリティポリシーを別途確認し、システムプロセスをむやみに終了しないでください。

3. JSON形式エラー:構文の破損と設定フィールドの非互換を切り分ける

カスタム設定を読み込んだ直後に起動できなくなった場合は、まずJSONを解析できるか確認し、その後にフィールドがコアに対応しているか調べます。JSONの構文エラーには、余分なカンマ、引用符の欠落、括弧の不整合などがあります。一方、フィールドの互換性エラーは、構文が正しいファイルでも起こることがあります。対処の順番が異なるため、設定エラーをすべてサブスクリプションの無効化が原因だと決めつけないでください。

エラー例:invalid character

原因:想定外の文字が読み込まれています。JSON末尾の余分なカンマ、曲がった引用符、Webページの内容を設定ファイルとして保存した場合などが考えられます。

対処法:エラー箇所の前後を確認してください。ファイルの先頭がHTMLタグなら、Webページを一文字ずつ修正するのではなく、正しい設定ファイルを取得し直します。

エラー例:unexpected EOF

原因:必要な内容を読み終える前にファイル末尾に達しています。コピー漏れやファイルの切り詰めが考えられます。

対処法:元の設定と照らし合わせて全体を確認し、欠けた部分を復元します。末尾に閉じ括弧を1つ追加するだけで、それ以前の欠損を隠さないでください。

厳密なJSONでは、オブジェクトの最後の要素の後にカンマを置けません。以下は構文の例であり、そのまま起動できる完全なコア設定ではありません。カスタムファイルを検証するときは、ノードの認証情報を含むファイルをオンラインの整形サービスに送らず、まずローカルのエディターで構文を確認してください。

{
  "log": {
    "loglevel": "warning"
  }
}
  1. 最初に元のカスタム設定をバックアップし、エラーに記録されたパスと行・列番号を残します。エラーによっては文字位置しか示されないため、前後の内容も確認してください。
  2. 通常のノードを使い、v2rayNがパラメータから設定を生成する場合は、ノード編集画面に戻ってフィールドを修正してください。一時的に生成された実行ファイルだけを変更しないでください。
  3. 完全なカスタム設定を使う場合は、元のファイルを修正してから再読み込みします。再起動は一度だけ行い、その起動時のログを比較してください。
  4. 構文エラーが解消しても起動できない場合は、プロトコル、トランスポート、安全性の設定、ルール用リソースを引き続き確認します。「解析できる」ことと「動作する」ことは別です。

4. 未知のプロトコルやフィールド:実際に起動したコアを確認する

v2rayN、V2Ray、Xrayのバージョンはそれぞれ別のものです。クライアント画面を更新しても、使用中のすべてのコアファイルが更新されるとは限りません。新しいコアがディスク上にあっても、今回の起動で選ばれているとは限りません。起動ログに記録されたコア名とバージョンを基準に、ノードが必要とする機能を確認してください。インストールパッケージの名前から推測せず、実際のバージョンを記録しましょう。

エラー例:unknown field

原因:現在の設定ローダーがそのフィールドを受け付けていません。バージョンの違い、階層の誤り、別形式の設定を使っている可能性があります。ローダーによっては、未知のフィールドをエラーにせず無視することもあります。

対処法:ログに示されたフィールド名を手掛かりに設定の階層を確認し、実際のコアが対応する形式に修正します。フィールドを削除しただけで接続設定が揃ったと判断しないでください。

エラー例:unknown config id

原因:設定の構築時に対応する登録済みの型が見つかりません。プロトコル名やトランスポート名が関係している場合があるため、同じエラーの流れにある具体的な識別子を確認します。

対処法:識別子の綴りと機能の対応状況を確認してください。別のコアの機能に依存する設定なら、名前だけを変更せず、設定と互換性のあるコアを使用します。

確認項目確認する内容避けるべき修正
VMess / VLESSプロトコルの種類、認証情報、使用中のコアの対応状況プロトコル名だけを入れ替え、ほかの設定はそのままにする
トランスポート設定トランスポートの種類、対応する設定オブジェクト、フィールドの階層別形式の設定からフィールドをそのまま貼り付ける
安全性の設定TLSまたはREALITYに必要なパラメータとコアの対応状況エラーを回避するために安全性の設定を直接無効にする
実行ファイル起動ログに記録されたコアとバージョンクライアントのバージョンだけを見て、機能が必ず使えると判断する

VLESSプロトコルとREALITYの安全性設定は、別々の項目です。VLESSに対応するコアだからといって、設定内のすべてのトランスポートや安全機能に対応しているとは限りません。サーバー側で必要な条件は維持したうえで、互換性のあるコアを選びます。安全性のフィールドをむやみに削除すると、起動エラーが後続のハンドシェイクエラーに変わることがあります。

5. ルールファイルが見つからない:パス、リソース形式、アクセス権を確認する

ルーティング設定が外部リソースを参照している場合、ファイルが存在しない、または読み込めないと起動を妨げることがあります。V2RayやXrayの設定では、geoip.datはIPアドレスの分類に、geosite.datはドメインの分類に使われます。ほかのコアでは別のルール形式を使う場合があるため、拡張子だけ変更して流用しないでください。エラー行に記録された実際のパスとリソースの種類を確認します。

エラー例:failed to open file

原因:参照先のリソースを開けません。続くエラーには通常、ファイル名と、ファイルが存在しないのかアクセス権がないのかが示されます。

対処法:パス全体、ファイルの有無、現在のユーザーの読み取り権限を確認し、クライアントのリソース更新機能を使って対応するルールファイルを復元してください。

エラー例:failed to load geosite

原因:ドメイン分類用のリソースを読み込めません。ファイルの欠落や破損のほか、ルールで参照したカテゴリが現在のリソースにない可能性があります。

対処法:エラーの詳細をさらに確認します。ファイルがない場合はリソースを復元し、カテゴリがない場合はルールの記述とリソースのバージョンが合っているか確認してください。

6. 一度に一項目だけ変更し、待ち受けとリクエストで確認する

修正前に現在の設定とログを保存し、変更は一度に一項目だけにします。基本的には「ポートのバインド、JSON構文、プロトコルフィールド、ルール用リソース」の順に確認します。ただし、ログにファイル不足が明記されている場合は、手順にこだわらずそのエラーを先に解決してください。各変更と結果を記録し、サブスクリプション更新、コアの切り替え、ルーティングの変更を同時に行って原因が分からなくなるのを防ぎます。

  1. 最小限の条件に戻す:TUNと、当面不要なカスタムルールを無効にします。必要なパラメータが揃ったノードを1つ選び、通常のローカルプロキシ待ち受けは有効にしておきます。
  2. 一度だけ再起動する:今回の起動時刻からログを確認し、すぐに終了しないことを確かめます。実際のコア名とバージョンも記録してください。
  3. ローカルの待ち受けを確認する:前述のコマンドで実際のポートを調べ、その待ち受けが別のクライアントではなく、今回起動したコアのものか確認します。
  4. プロキシ経由のリクエストを送る:該当ポートがSOCKSを提供している場合は、以下のコマンドで確認できます。リクエストログも見て、DNS、接続、ハンドシェイクのどの段階で失敗したか判断します。
  5. 機能を一つずつ戻す:まずルーティングルールを戻し、その後にTUNを有効にします。項目を追加するたびにログを確認し、問題が再発する境目を特定してください。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

このWindows向けコマンド例では、接続タイムアウトを10秒、全体のタイムアウトを20秒に設定しています。実行前に実際のSOCKSポートへ置き換えてください。socks5hは接続先のドメイン名の解決をプロキシ側で行う指定です。ローカルでHTTPプロキシだけを使っている場合は、対応するプロキシ形式に変更します。HTTPレスポンスが返っても、そのリクエストに応答があったことを示すだけで、すべてのWebサイトに接続できるとは限りません。リクエストのタイムアウトだけでコアの起動失敗と判断することもできません。

まとめ:起動の成功とプロキシの通信可否は別々に確認

コアが動作を続け、正しいプロセスが待ち受けを開始していれば、起動段階は完了しています。その後もタイムアウトやハンドシェイクエラーが続く場合は、リクエストログをたどってリモート接続を確認します。クライアントを何度も再インストールする必要はありません。

7. ログによるトラブル対処のよくある質問

最後の行に「プロセスが終了しました」とだけ表示される場合、どこを見ればよいですか?

同じ起動ログをさかのぼり、最初に現れた具体的なエラーと、その後に続く原因の説明を確認します。終了メッセージは結果にすぎません。実際に対処するための情報は、その前のポート番号、フィールド名、ファイルパスに記録されていることが多くあります。

v2rayNを管理者として実行すれば解決しますか?

一般的な解決策にはなりません。通常のループバックプロキシの待ち受けに管理者権限は不要です。TUNや特定のネットワーク操作には追加の権限が必要な場合があります。まずTUNを無効にして比較してください。JSON構文のエラーやプロトコルの非互換は、権限を上げても自動的には解決しません。

サブスクリプションの更新に成功したのに、起動できないのはなぜですか?

更新の成功が示すのは、サブスクリプションの取得と処理が完了したことだけで、最終的な実行設定との互換性までは保証されません。必要なパラメータが揃ったノードに切り替え、現在のコアと全体のルーティング設定を確認してください。全体ルールの誤りは複数のノードに影響することがあります。

ログを添えて問い合わせるとき、何を残せばよいですか?

OSとクライアントのバージョン、実際に使用したコアのバージョン、再現手順、一度の起動で記録されたエラー全体を残してください。サブスクリプションのURL、認証情報、秘密鍵などの機密情報は伏せます。ローカルポート、エラーに出たフィールド名、個人情報を除いたディレクトリ構成はできるだけ残してください。

v2rayNをダウンロード