V2Rayのコアが起動しないときの対処法：ログからconfig.jsonの設定ミスを特定

まず起動段階の失敗か確認する

コアの起動失敗とノードへの接続失敗は別の問題です。起動に失敗すると、V2RayまたはXrayのプロセスは通常、config.jsonの読み込み、インバウンドの待ち受け作成、アウトバウンド設定の初期化中に終了します。一方、ノード接続の失敗ではコアは動作を続けていますが、接続先へのアクセス時にタイムアウト、ハンドシェイク失敗、サーバーによる拒否などが発生します。確認すべき入口が異なるため、「Webページが開けない」だけで判断してはいけません。

ログを開いたら、今回の起動に対応する最初の error または failed を上方向に探します。その後に出る「プロセス終了」「再起動失敗」は結果にすぎず、本当の原因は通常その前の1〜5行にあります。たとえば設定解析エラーでは先に文字位置が示され、その後にコアの終了コードが表示されます。ポート競合では待ち受けアドレスが先に示され、続いて起動失敗が報告されます。

v2rayN 7.xを例にすると、まず「設定」→「パラメータ設定」→「Coreタイプ」で、現在のノードがXray Coreとv2fly Coreのどちらを呼び出しているか確認し、メイン画面に戻ってログ欄を開きます。Coreタイプを切り替えた後は一度再起動し、現在のコアが生成した新しい記録だけをログに残してください。古い設定のエラーを現在の問題と取り違えるのを防げます。

1. コアを停止

   クライアントで停止操作を実行し、ログにプロセス終了の情報が表示されるまで待ちます。古いプロセスがローカルの待ち受けポートを使っていないことを確認してください。

2. ログを消去

   ログ画面を消去するか現在時刻を記録してから、コアを一度だけ起動します。連続して再試行すると同じエラーが大量に記録されます。

3. 最初のエラーを特定

   新しいログの先頭から、failed、error、invalid、unknown のいずれかを含む最初の記録を探します。

4. 前後の情報を記録

   エラー行の前後3行を残し、設定ファイルのパス、行と列の位置、待ち受けポート、アウトバウンドのタグを重点的に記録します。

5. 1項目ずつ修正

   一度に1つの問題だけを修正して保存し、再起動します。複数のフィールドを同時に変更すると、どの修正が反映されたのか新しいログから判断しにくくなります。

JSON構文エラー：行と列の位置から構造を修正

config.jsonは標準JSONの構文に従う必要があります。キー名と文字列には半角の二重引用符を使い、配列とオブジェクトにはそれぞれ角括弧と波括弧を使います。隣り合うフィールドはカンマで区切り、最後のフィールドの後には余分なカンマを置けません。日本語入力による曲がった引用符、閉じ忘れた引用符、コピー時に混入したコメントがあると、コアはプロトコルパラメータを処理する前に停止します。

次の断片では port 行末のカンマが抜けているため、パーサーは次の行の protocol を読めません。ログの行番号は「問題を検出した位置」を指す場合があり、実際に不足している文字は直前の行にあることもあります。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808
      "protocol": "socks"
    }
  ]
}

修正時はエラー文字だけを見ないでください。表示された位置から上に向かって直近の波括弧の組を確認し、各オブジェクト内のキーと値が正しく区切られているか、ファイルの先頭から末尾まで括弧が対応しているかを点検します。エディターがJSON整形に対応していれば先に整形を実行し、整形できない場合は構造がまだ閉じていない可能性があります。

• 日本語入力で入った引用符を半角の二重引用符に置き換えます。特にサーバーアドレス、UUID、タグ、プロトコル名を確認してください。
• 数値が単位付きの文字列になっていないか確認します。たとえばポートは 10808 と記述し、10808ポート とは書きません。
• 真偽値は小文字の true または false を使い、引用符で囲んだ文字列にしないでください。
• 完全なテキストとして保存してからコアを再起動します。プレビュー画面上で変更しただけの未保存コピーを使わないでください。

ポート競合：競合プロセスと重複インバウンドを確認

JSONを正常に解析できると、コアは順番にインバウンドの待ち受けを作成します。v2rayNの古いプロセスが終了していない、別のローカルネットワークツールが同じポートを使っている、config.json内の複数のインバウンドが同じアドレスとポートを使用している、といった場合は待ち受け段階で停止します。ログには通常、listen、bind、address already in use などのキーワードが現れます。

よくあるテスト設定では、SOCKSインバウンドを 127.0.0.1:10808、HTTPインバウンドを 127.0.0.1:10809 に設定します。ただし、これらの番号はすべてのクライアントバージョンで固定された値ではありません。実際の確認ではログと現在のパラメータ設定を基準にしてください。ログで競合ポートが10808と表示された場合は10808だけを確認し、リモートサーバーのポートまで同時に変更する必要はありません。

Windowsでは、ターミナルで次のコマンドを実行して10808に対応するプロセスIDを確認できます。結果の最後の列が6420だった場合は、2つ目のコマンドでプロセス名を調べます。ポートが使用中だからといって任意のシステムプロセスを直接終了せず、終了していない古いコアのインスタンスかどうかを先に確認してください。

netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"

結論：まずポートを解放し、番号変更はその後

古いプロセスが残っている状態で10810へ変更しても、競合を一時的に回避するだけで、システムプロキシは古いポートを指し続けます。まず残ったインスタンスを終了してポートが解放されたことを確認してください。必要なプログラムがポートを継続使用している場合に限り、インバウンドのポートとシステムプロキシ設定を同時に変更します。

フィールド名の誤り：階層、コア、設定形式を区別する

フィールド名の綴りが正しくても、階層を間違えると設定の読み込みに失敗します。TLSのサーバー名を例にすると、serverName は対応するトランスポートセキュリティ設定内に置く必要があり、outboundのルート階層に任意で置くものではありません。ほかにも settings を setting と書く、streamSettings を streamSetting と書く、配列フィールドを単一オブジェクトとして記述するといった例があります。

別のコアや異なるバージョンの設定断片を混在させることも、よくある原因です。v2rayNはノードとCoreタイプに応じて設定を生成できますが、Xray Coreとv2fly Coreでは一部のプロトコル、フロー制御値、トランスポート項目の対応範囲が完全には一致しません。あるコアで使える設定が、Coreタイプを切り替えた後もそのまま読み込めるとは限りません。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

1. v2rayNの「設定」→「パラメータ設定」→「Coreタイプ」で選択したコアが、ノードのプロトコルと一致しているか確認します。
2. ログに表示された実際の設定パスを確認し、バックアップファイルや古いディレクトリのconfig.jsonを編集していないか確認します。
3. 複雑な設定をインバウンド1つ、アウトバウンド1つまで縮小し、起動できることを確認してからDNS、ルーティング、追加のインバウンドを戻します。
4. エラーがサブスクリプションのノードに由来する場合は、クライアントでノードパラメータを編集して設定を再生成します。実行時の一時ファイルだけを変更しないでください。

結論：未知のフィールドを移動して試すだけでは解決しない

まず現在のCoreタイプと設定形式を確認し、フィールドが属するオブジェクトを特定します。フィールドを別の階層へ何度も移動すると、1つのエラーは消えても意味上の誤りが生じ、コア起動後も接続できなくなることがあります。

プロトコルパラメータ不足：インバウンドからアウトバウンドまで順に確認

JSON構文とフィールド階層が正しいと確認された後、コアはプロトコルパラメータを検査します。VMessではユーザーIDの形式不正、VLESSではアドレス、ポート、ユーザーID、暗号化設定、フロー制御パラメータの不一致がよくあります。TLSを使う場合はセキュリティタイプとサーバー名も確認してください。パラメータ不足は必ずしも「missing」と表示されるとは限らず、ユーザーを解析できない、無効なUUID、未対応のフロー制御値などと表示される場合もあります。

サブスクリプションのインポート後にこの種のエラーが出た場合は、まずクライアントで該当ノードの編集画面を開きます。サーバーアドレスの前後に空白がないこと、ポートが1〜65535の範囲にあること、ユーザーIDが完全であること、プロトコルとトランスポートタイプが入れ替わっていないことを確認します。サブスクリプションURLをノードのサーバーアドレスとして扱ったり、ローカルの10808ポートをリモートサーバーのポート欄に入力したりしないでください。

処理がどの段階で止まったかによって、確認範囲が決まります。ログにローカルポートの待ち受け成功が表示された後でルーティングタグが存在しないと報告された場合、SOCKSインバウンドに戻って修正する必要はありません。アウトバウンドのユーザー解析中に終了したなら、DNSとルーティングはまだ動作していないため、ノードのプロトコルパラメータを優先して確認します。

最小構成法：エラー範囲を絞り込む

ログに複数の設定エラーが同時に出る場合、すべてのフィールドを一度に変更するより、起動できる最小構成を作るほうが効果的です。まずローカルインバウンドを1つ、パラメータが揃ったアウトバウンドを1つだけ残し、カスタムDNS、ルーティングルール、追加インバウンド、複雑なトランスポート設定を一時的に外します。コアが継続して動作したら、モジュールごとに1項目ずつ戻します。

モジュールを1つ戻すたびに、停止、起動、ローカル接続テストを実行します。たとえば最初にDNSを戻して名前解決エラーがないことを確認し、次にroutingを戻してルールが参照するinboundTagとoutboundTagの存在を確認し、最後に追加の待ち受けを戻します。これにより、「数十個のフィールドからエラーを探す」作業を「追加した1つのモジュールを確認する」作業に絞れます。

1. インバウンドを残す

   127.0.0.1で待ち受けるローカルインバウンドを1つだけ残し、現在使われていない高位ポートを設定します。

2. アウトバウンドを残す

   パラメータが揃ったVMessまたはVLESSのアウトバウンドを1つだけ残し、テストに使わない予備ノードを削除します。

3. ルーティングを一時停止

   カスタムroutingルールを一時的に削除し、削除済みタグの参照が起動判定を妨げないようにします。

4. 起動を再テスト

   設定エラーがログに再表示されないこと、プロセスが3秒を超えて動作すること、ローカルの待ち受けポートが維持されていることを確認します。

5. 1項目ずつ復元

   DNS、ルーティング、追加インバウンド、トランスポート設定の順に復元し、毎回1つのモジュールだけを追加します。

起動成功を確認：ログ、ポート、接続の3項目をすべて確認

設定エラーが消えただけでは第一段階にすぎません。起動成功と判断するには、コアのプロセスがすぐに終了しないこと、ローカルのインバウンドポートが待ち受け状態であること、クライアントのテストリクエストが対応するアウトバウンドを通過することの3条件を満たす必要があります。「設定の読み込み完了」だけを確認して、その後プロセスが終了した場合は復旧とはいえません。

起動後3〜10秒のログを確認します。動作情報が継続して出力され、新たな failed to start、panic、終了コードがなければ、ポートを確認します。Windowsでは再度 netstat -ano | findstr :10808 を実行し、現在のコアプロセスに対応する待ち受け記録が表示されることを確認します。クライアントで別のポートを設定している場合は、コマンド内の番号を置き換えてください。

続いて、クライアントに搭載された遅延テストまたは接続テストを1回実行します。ここでTLSハンドシェイク、サーバーのタイムアウト、接続拒否が発生した場合、起動の問題は解決しており、障害はリモート接続の段階に移っています。以降はサーバーアドレス、ネットワーク到達性、TLSのserverName、トランスポート方式、ノードの有効性を確認し、JSONの括弧を修正し続けないでください。

• 2回連続で起動しても動作を維持できることを確認し、一時的な古いプロセスの残留を除外します。
• クライアントを停止してローカルの待ち受けが消え、再起動すると待ち受けが復元されることを確認します。
• ログに設定ファイルの行・列エラー、未知のフィールド、ポートのバインド失敗が表示されなくなっていることを確認します。
• システムプロキシが変更前の古いポートではなく、現在のローカルポートを指していることを確認します。
• サブスクリプションを更新して設定を再生成した後も、修正内容が保持されることを確認します。

結論：起動成功とノードの利用可否は分けて確認する

プロセスが継続して動作し、ローカルポートが正常に待ち受けていれば、config.jsonは起動段階を通過しています。その後に発生するハンドシェイクやタイムアウトは、接続経路の問題として確認します。段階ごとに検証すれば、すでに正しい設定構造を何度も変更せずに済みます。

それでも特定できない場合は、今回の起動で最初に出たエラー、その前後3行のログ、現在のCoreタイプ、クライアントのバージョン、問題が発生した設定モジュールをまとめます。ログを共有する前に、サーバーアドレス、ユーザーID、サブスクリプションURLなどの接続情報を削除してください。ただし、エラーの種類、フィールド名、行・列の位置、ポート番号は残します。これらが設定問題を判断する重要な情報です。