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

まず確認：コアが起動していないのか、起動後に接続できないのか

v2rayNはノードを管理して設定を生成し、コアを起動するGUIクライアントです。Xrayは設定を読み込み、ポートを待ち受け、通信を処理します。クライアントの画面が開いていても、Xrayが正常に動作しているとは限りません。システムプロキシが有効でも、プロキシのアドレスが設定されているだけで、該当ポートをプロセスが実際に待ち受けているとは限りません。

調査を始める前にシステムプロキシを一時的に無効にし、ブラウザーが使えなくなったローカルポートへ接続し続けないようにします。Windowsでは通常、タスクトレイのメニューから「システムプロキシ」→「システムプロキシをクリア」を選びます。次にメイン画面下部の情報またはログ欄を開き、古い表示を消してから、コアの起動または再起動を1回だけ実行します。ボタン名はバージョンによって異なるため、その起動時に出力されたログを基準にしてください。

connection refused、i/o timeout、TLSハンドシェイクの失敗などがWebリクエストの開始後に起きた場合、通常は設定の読み込み段階の問題ではありません。ログの時刻とローカルポートの状態を先に確認し、英語のキーワードひとつだけでコアの起動失敗と判断しないでください。

ログの読み方：最後の1行だけでなく、エラーの連鎖を残す

Xrayのエラーは、原因が複数のメッセージで順に包まれていることがあります。外側にはFailed to startとだけ表示され、中間で設定ファイルが示され、最も内側でポートやプロトコル項目、リソースファイルの問題が明らかになる場合があります。ログの>はエラー原因をつなぐ記号で、入力するコマンドではありません。

1. 環境を記録：クライアントの「ヘルプ」→「バージョン情報」または同等の画面でv2rayNのバージョンを記録します。Xrayのバージョンは起動ログから確認します。クライアントとコアのバージョンを混同しないでください。
2. 起動ログをひとまとまりで保存：コアを呼び出す最初の行から終了の表示まで保存します。連続した複数回の再試行をひとつのログに混ぜないでください。
3. 原因を具体的に絞る：bind、invalid、failed to load、not foundを検索し、前後の行も確認します。
4. 設定の読み込み元を確認：現在選択しているのが通常のノードか、カスタム設定かを確認します。通常のノードなら、まずノード編集画面やクライアントの設定を修正します。カスタム設定の場合は、実際に読み込まれているJSONファイルを確認してください。

ログの情報が少ない場合は、「設定」→「パラメーター設定」でログレベルを探し、一時的にinfoに変更して1回再起動します。それでも原因が分からない場合に限り、短時間だけdebugを使ってください。デバッグログにはアクセス先が記録されることがあります。調査後は元のレベルに戻し、長期間記録したり公開したりしないでください。

ポートの競合：まず使用中のプロセスを確認し、必要なら待ち受けポートを変更

ポートの競合はローカルで発生するため、接続先サーバーが稼働しているかどうかとは関係ありません。v2rayNを二重に起動している、以前のコアが動作し続けている、別のアプリが同じアドレスとポートを使っている、といったケースがよくあります。以下の10808は例です。実際の調査ではログに記載されたポートに置き換えてください。

WindowsではPowerShellを開き、待ち受けポートと使用中のプロセスを確認できます。次のコマンドは情報を表示するだけで、プロセスを終了しません。

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

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

使用中のプロセスが重複起動したクライアントだと確認できたら、そのクライアントの終了操作を使って閉じてください。正体の分からないシステムプロセスを直接終了しないでください。待ち受けポートを10808から10818に変更する場合は、「設定」→「パラメーター設定」でローカル待ち受けポートを探します。バージョンによっては「ローカル混合待ち受けポート」と表示されます。保存してコアを再起動し、プロキシアドレスを手動で設定しているアプリも更新してください。

JSON構文エラー：まず構文を直し、その後プロトコルの内容を確認

JSONの解析に失敗した場合、コアは正常な接続処理に進んでいません。通常のノードでは、v2rayNが実行用の設定を生成します。生成ファイルを手動で編集しても次回起動時に上書きされることがあるため、ノード編集画面または関連設定から元の設定を修正してください。カスタム設定を使っている場合に限り、読み込まれているJSONファイルを直接確認します。

以下はlog設定の構文例であり、通信にそのまま使える完全な設定ではありません。エラー例では"warning"の後に余分なカンマがあります。

{
  "log": {
    "loglevel": "warning",
  }
}

正しいJSONは次のとおりです。全角の引用符は半角の二重引用符の代わりにはなりません。数値や真偽値をむやみに文字列へ変更しないでください。

{
  "log": {
    "loglevel": "warning"
  }
}

• 構文を確認してから意味を確認：JSONとして解析できても、プロトコル、トランスポート層、サーバーの設定が一致しているとは限りません。
• 行番号は参考として扱う：ログに示された位置は、解析器が問題を検出した箇所です。実際の誤りが直前の行にあることもあります。
• 設定をオンラインに貼り付けない：認証情報を含む設定はローカルで確認し、公開されているフォーマットツールにアップロードしないでください。

プロトコル項目が不足している場合：ノード編集画面から修正

JSONを読み込めると、次にXrayがプロトコルとトランスポートの設定を検証します。VMess、VLESS、Trojanでは必要な認証情報が異なるため、プロトコル名だけを変えても切り替えられません。VLESSではUUID、Trojanではパスワードが一般的です。TLS、REALITY、トランスポート方式、flowもサーバー側の設定と一致させる必要があります。

起動エラーがなくても、すべての項目が正しいとは限りません。たとえばTLSのサーバー名と証明書が一致しない場合、接続先に接続して初めて問題が分かることがあります。証明書の検証を無効にして問題を隠さず、まず端末の時刻、サーバー名、サーバー証明書を確認してください。REALITYの認証パラメーターは、使用するバージョンとサーバーの指定に従って設定します。通常のTLS設定をそのまま流用しないでください。

サブスクリプションのノードを変更しても、次回の更新時に元のパラメーターが再度取り込まれることがあります。問題の切り分けが目的なら、ノードを複製してローカルでテストし、用途が分かる名前を付けてください。元データに問題があると分かった場合は、サブスクリプションの設定元を修正します。一時的な修正を、サブスクリプションに恒久的に反映された設定と混同しないでください。

コアファイルやルールファイルが見つからない場合：ログのパスを確認して復旧

Xrayの実行ファイルが見つからない場合、通常はプロセスの作成段階で失敗しています。一方、geoip.datやgeosite.datが見つからない場合は、プロセスの起動後に、これらのリソースを参照するルーティングルールの読み込みで失敗している可能性があります。状況に応じて別々に対処してください。どちらもサブスクリプションの更新だけで解決するわけではありません。

1. インストール方法を確認：圧縮ファイルを使う場合は、通常のフォルダーにすべて展開してから起動します。圧縮ファイル内から本体を直接開かないでください。
2. アーキテクチャを確認：システムのアーキテクチャに合ったインストーラーとコアを選択します。アーキテクチャが合わない場合、ファイルがないのではなく実行できないという形でエラーが出ることがあります。
3. セキュリティソフトの記録を確認：まずファイルの入手元と隔離された理由を確認し、システムの手順に従って対処します。セキュリティ保護全体を無効にすることを通常のトラブル対処にしないでください。
4. ルーティング用リソースを確認：ログにルールカテゴリが存在しないとある場合は、ルールデータを更新するか、カテゴリ名を修正します。ファイルが存在していても、必要なカテゴリが含まれているとは限りません。

インストール内容を復元する場合は、クライアントのダウンロードページからプラットフォームに合ったインストーラーを選択してください。自分で管理している設定をバックアップしてから、プログラムファイルを復元します。トラブルの調査中にユーザーデータフォルダー全体をむやみに削除しないでください。一般的なファイル不足を解決するために、最初から管理者権限で起動する必要はありません。権限の問題がログに明示されている場合に限り、該当するパスに対処してください。

修正後の確認：一度に変更するのは1項目だけ

項目をひとつ修正するたびに再起動し、新しいログを保存します。まず設定が読み込まれたこと、次にローカルポートが待ち受けていることを確認し、最後にアプリからリクエストを送ります。これにより「起動時のエラーが解決した状態」と「その後に発生した接続先の問題」を切り分けられます。両方が同時に起きることもありますが、ポート、プロトコル、DNS、ルーティングを一度に変更しないでください。

• 手順1：同じ起動のログに、後続の致命的なエラーやプロセス終了がないことを確認します。起動メッセージが表示されたことだけを見て確認を終えないでください。
• 手順2：前述のPowerShellコマンドで実際のポートを調べ、待ち受けているプロセスが今回起動したコアであることを確認します。
• 手順3：システムプロキシを再度有効にし、ブラウザーや対象アプリが使うプロキシの接続先を確認してから、リクエストを1回送りログを確認します。
• 手順4：接続タイムアウトやハンドシェイクエラーだけが発生する場合は、接続先のパラメーターを調べます。読み込みに成功したJSONの構造を何度も修正する必要はありません。

最後に、使用したコアのバージョン、起動を妨げていた設定項目、変更後に待ち受けに成功したポートの3点を記録しておきましょう。「再インストールしたら直った」よりも再利用しやすく、次回のアップデートやサブスクリプションの取り込み、ルーティング変更時にも原因をすぐに確認できます。