v2rayNのコア起動トラブル

コアが起動しない場合とノードに接続できない場合を見分ける

v2rayNはクライアントの画面を提供し、XrayやV2Rayなどのコアが設定を読み込み、ローカルで待ち受けて通信を処理します。メイン画面にサーバー一覧が表示されていても、コアが正常に動作しているとは限りません。システムプロキシが有効になっていても、該当するローカルポートで待ち受けが始まっているとは限りません。切り分けはブラウザーの「このサイトにアクセスできません」ではなく、今回の起動ログから始めましょう。

ログに設定読み込み直後の終了が記録され、Failed to start、failed to load config、ポートのバインド失敗などが表示されている場合は、まずローカルの設定を確認します。コアが動作し続け、ローカルのプロキシポートで待ち受けているのに、アクセス時だけタイムアウト、証明書エラー、接続拒否が発生する場合は、ノードのアドレスやTLS、ネットワーク経路を調べます。ログの表現はコアのバージョンによって異なります。以下はよくあるエラー例で、ログ全体が完全に同じ表記である必要はありません。

• 設定の読み込み段階：config、json、line、offsetに注目します。この段階では通常、プロキシの待ち受けはまだ始まっていません。
• 待ち受けの開始段階：listen、bind、ローカルアドレスとポートに注目し、まずポート競合と待ち受けアドレスを確認します。
• リクエストの処理段階：接続先のドメイン名、リモートポート、timeout、x509に注目します。まずJSONの記号を変更するのは避けましょう。

今回のログと実際に読み込まれた設定ファイルのパスを記録する

まず、v2rayNの「ヘルプ」→「バージョン情報」でクライアントのバージョンを記録し、起動ログからコア名、バージョン、設定ファイルのパスも控えます。デスクトップ版とWPF版では、一部のメニューの場所が異なります。この記事で扱う項目は「設定」→「パラメーター設定」から確認できますが、具体的な分類名は現在の画面に従ってください。画面に表示されたバージョンだけでコアのバージョンを判断したり、インストールフォルダーに同名ファイルがあるだけで今回読み込まれた設定だと決めつけたりしないでください。

1. 以前のログを保存する

   現在のエラーをローカルのテキストファイルにコピーし、メイン画面のログ表示を消去します。現在のサーバーを選択してアクティブに設定し、コアを再起動します。この操作で記録された一連のログだけを残してください。

2. コアを確認する

   起動ログに記録された実行ファイル名とバージョンを確認します。コアの選択を変更した場合は、「設定」→「パラメーター設定」のコア関連項目も確認してください。判断には実際の起動ログを優先します。

3. 設定ファイルの場所を特定する

   読み込まれた設定ファイルの完全なパスを記録します。通常のノードが生成する設定と、カスタム設定では扱いが異なります。まずエラーが発生しているファイルを複製し、診断用に使いましょう。クライアントの永続設定を直接上書きしないでください。

4. エラーの末尾を確認する

   同じエラーの連なりを、外側のメッセージから末尾の原因までたどります。たとえば「設定の読み込みに失敗」の後に「ファイルが見つかりません」とある場合、修正すべきなのは後者です。最初の失敗メッセージだけを切り取らないでください。

通常のノード用ランタイム設定は、アクティブサーバーの再設定、ルーティングの切り替え、再起動などで再生成されることがあります。生成されたconfig.jsonを直接編集すると、「直したのに元に戻る」ことがよくあります。原因を確認したら、ノード編集、ルーティング設定、パラメーター設定のいずれかに戻って元の設定を修正してください。カスタム設定を明示的に使っている場合に限り、そのファイルを編集します。

ポート競合：待ち受け中のプロセスを確認してからポートを変更

よくあるのは、別のクライアントや終了後に残ったコアが、ローカルの待ち受けポートを使用しているケースです。以下ではWindowsの127.0.0.1:10808を例に説明します。これは切り分けのための例で、すべてのバージョンがこのポートを使うという意味ではありません。「設定」→「パラメーター設定」でローカルの待ち受けポートを確認してください。現在の画面でSOCKS、HTTP、混合ポートが個別に設定されている場合は、それぞれ確認し、例の数値をそのまま使わないでください。

PowerShellで次のコマンドを実行すると、TCPの待ち受け接続だけを絞り込めます。リモート接続でたまたま同じポート番号が使われているケースを、競合と誤認せずに済みます。出力のOwningProcessはプロセスIDです。終了するかどうかを決める前に、プロセス名と実行ファイルのパスを確認してください。

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

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

結果が何も表示されない場合、検索時点でそのポートのTCP待ち受けが見つからなかったという意味です。設定に問題がないと証明されたわけではありません。ログに記録された実際のアドレス、別のUDP競合の有無、access permissionsのようなシステム制限も確認してください。ポートを10809に変更した場合は、プロキシを手動設定しているブラウザーやターミナルも同じ値に更新します。クライアントがシステムプロキシを管理している場合は、設定し直してポートを反映してください。テスト前に、代替ポートが使用中でないことも確認します。

JSON構文エラー：まず構造を修正し、その後に設定値を確認

JSONの解析エラーは、カスタム設定を手書きしたり、設定の一部をコピーしたり、ルーティングルールを編集したりした後によく発生します。よくある原因は、オブジェクトの項目間のカンマ抜け、全角の引用符、閉じ忘れた括弧、最後の項目の後にある余分なカンマです。コメントなどの拡張構文は、読み込み機能によって対応状況が異なります。バージョンをまたいで原因を調べるためのコピーは、まず厳密なJSON形式で保存してください。

以下は有効な部分オブジェクトの例です。数値のポート、文字列の引用符、配列の閉じ方を示しています。このまま起動できる完全な設定ではありません。ルールの一部を既存ファイルに追加する際は、どの親フィールドに属するかを確認してください。完全なJSONオブジェクトを2つ、続けてつなげることはできません。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

• ログに行番号と列番号がある場合は、まずその位置を確認し、さらに1行前も調べます。解析エラーが示す位置は、単に「これ以上解析できない」と判明した場所にすぎない場合があります。
• バイトオフセットしか表示されない場合、その数値を日本語の文字数として数えないでください。ローカルのエディターにあるJSON検証機能を使って位置を特定し、手作業による数え間違いを防ぎましょう。
• サーバーアドレス、ユーザーID、サブスクリプション情報を含む設定ファイル全体を、オンラインの整形ツールに送信しないでください。エラーを共有するときは構造とフィールド名を残し、認証情報は伏せてください。

未認識のフィールドと未対応の設定値

JSONを解析できることは、ファイルの構造が正しいことを示すだけで、すべてのプロトコル、トランスポート、設定項目をコアがサポートしているとは限りません。v2rayNの画面設定、V2Rayの設定、Xrayの設定はそれぞれ異なるデータ形式です。クライアントの設定ファイルをコアの設定として使ったり、別の種類のコア向け設定をそのまま読み込んだりすると、読み込み失敗や予期しない動作の原因になります。

注意点として、未認識のフィールドが常にエラーになるとは限りません。読み込み処理によっては、認識できないキーを無視します。「unknown field」が表示されないからといって、フィールド名のスペルが正しいとは判断できません。実際には、unknown transport protocolのように、設定値がサポートされていないケースもよくあります。その場合はJSONの記号だけを直すのではなく、トランスポートと実際に動作しているコアを確認してください。

• まず階層を確認：streamSettingsは該当するインバウンドまたはアウトバウンドの設定オブジェクトに属します。設定のルートに移動しないでください。
• 次に型を確認：真偽値のtrueと文字列の"true"は同じではありません。フィールドが要求するオブジェクト、配列、数値は、使用するコアの仕様に合わせて設定してください。
• 最後に互換性を確認：新しいフィールドの使用には、より新しいコアが必要な場合があります。更新時はクライアントと必要なコアコンポーネントをそろえ、出所不明の実行ファイルだけを置き換えないでください。

VMessとVLESSはプロトコル名であり、「試しに」互いへ置き換えるための修正スイッチではありません。サーバーのプロトコル、トランスポート、セキュリティ設定には、それぞれ決まった組み合わせがあります。サブスクリプションからインポートした通常のノードでは、有効な設定を再インポートし、サーバー側の要件を確認してください。カスタム設定では、元のファイルを保管したうえで、問題が疑われる項目と現在のコアの対応範囲を1つずつ比較します。

geoファイル不足：ファイル、パス、カテゴリ名を確認

ルーティングでgeoip:cnやgeosite:cnを使い、従来のDAT形式のデータを参照する設定では、通常、対応するgeoip.datとgeosite.datが必要です。エラーの連なりでは、最初に「ルールの構築に失敗」と表示され、末尾にデータファイルを開けない、またはカテゴリが見つからないと記録されることがあります。前者は結果であり、ファイルを補うべきかルールを変更すべきかを判断するには、後者を確認します。

1. ログからリソースの完全なパスを書き留め、作業ディレクトリがプログラムのフォルダーと同じだと決めつけないでください。カスタムの起動方法やリソースパスの設定で、検索先が変わることがあります。
2. ファイルが見つからない場合は、クライアントのリソース更新メニューと更新ログを確認してください。必要に応じて、完全なクライアントパッケージから関連コンポーネントを復元し、対象フォルダーにファイルが配置されたことを確認します。
3. ファイルが存在するのにカテゴリが見つからない場合は、ルール内のカテゴリ名とデータの出所を確認してください。すべてのデータファイルに同じカテゴリが含まれているわけではありません。ファイル名を変更しても、カテゴリは追加されません。
4. 該当カテゴリを参照するカスタムルールを一時的に無効にして起動できた場合は、問題の範囲をルールとデータ依存関係に絞れます。通常の通信に戻す前に必要なデータをそろえ、ルーティングを再検証してください。

修正後は同じ手順で再テスト

一度に変更するのは1項目だけにし、コアを再起動して新しいログを保存します。ノード、ポート、コアを同時に変更し、ルーティングも削除すると、復旧しても原因を特定できません。カスタムのXray設定は、実際に使用するXray実行ファイルで読み込みテストができます。以下のコマンドは診断用コピーがあるフォルダーで実行してください。ファイル名はconfig.jsonです。

.\xray.exe run -test -config .\config.json

このコマンドは、記載されたコマンドライン形式に対応するXray向けです。別のコアでは、まずそのヘルプを確認し、コマンドをそのまま流用しないでください。テストにはクライアントと同じリソース環境を使用します。環境が異なると、geoファイルの検索パスが変わり、別のエラーが発生することがあります。設定テストに合格しても、リモート接続の正常性や実行時のポートバインドが保証されるわけではありません。クライアントに戻って確認してください。

• 第1段階：設定を読み込める。解析失敗、設定の構築失敗、データファイルの読み込み失敗がログに表示されないことを確認します。
• 第2段階：待ち受けが確立している。ポートを調べ、想定したアドレス、ポート、プロセスが対応していることと、コアがすぐに終了しないことを確認します。
• 第3段階：リクエストが通る。アプリで正しいローカルプロキシを使い、接続ログを確認します。この段階で発生したTLSやタイムアウトの問題は、別途切り分けます。
• 第4段階：設定が保持される。サーバーをアクティブに設定し直してクライアントを再起動し、一時ファイルだけでなく、設定の元ファイルに修正が反映されていることを確認します。

コアの起動失敗に関するよくある質問