v2rayNのコア起動エラーを解決する方法｜ログからポート競合・設定ミスを特定

1. コアの終了と接続タイムアウトを見分ける

v2rayNはGUIの管理ツールで、プロキシ接続は呼び出されたコアが処理します。メインウィンドウが開いても、コアが動作しているとは限りません。また、Webページが開けない原因がコアの起動失敗とは限りません。まずメイン画面下部のログを確認してください。起動後に設定の読み込みエラーや待ち受けの失敗が表示され、その後プロセスが終了している場合は、この記事の手順で調査します。

ログに待ち受け成功のメッセージが表示された後、Webサイトへのアクセス時に i/o timeout が発生する場合は、ノードへの接続、DNS、ルーティングの振り分けを優先して確認してください。実行中のリクエストエラーを起動エラーと混同しないようにしましょう。起動に成功していない段階で、システムプロキシを何度も変更する必要はありません。システムプロキシはアプリの通信先を指定するもので、コアのJSON構文エラーは修正できません。

1. 現在の状態を記録する

   「ヘルプ」→「バージョン情報」でv2rayNのバージョンを記録します。起動ログから、実際に使用されているコアの名称とバージョンも確認してください。メニュー名は画面のバージョンによって異なる場合があるため、現在の画面表示に従ってください。

2. エラーを再現する

   現在のノードを選択し、Enterキーを押してアクティブサーバーに設定します。今回の起動時刻付近のログを確認し、設定の読み込みから終了までをすべて保存してください。「起動失敗」の最後の一文だけを切り取るのは避けましょう。

3. 根本原因を見つける

   failed to、コロン、または > でつながったエラーの連鎖を後ろまで読み、ポート、フィールド名、ファイルパス、行・列番号を確認します。上位の概要メッセージよりも、こうした情報のほうが原因特定に役立ちます。

4. 一度に変更するのは1項目だけ

   設定またはカスタム設定を先にバックアップし、該当する問題だけを修正します。ノードを再度有効にしたら、新しいログを確認して元のエラーが消えたことを確かめてから、次の問題に進みましょう。

2. ポート競合：PIDから待ち受けプロセスを特定

エラーの連鎖に listen tcp、bind、または address already in use が含まれている場合は、まずローカルの待ち受けポートを確認します。以下はエラーの種類を見分けるための例です。エラー全文の冒頭部分は、OSやコアのバージョンによって異なります。Windowsのバインドエラーは、ポートの予約やセキュリティポリシーが原因の場合もあります。bind の表示だけで、別のプロセスによるポート占有と決めつけないでください。

Windowsのターミナルで次の2つのコマンドを実行します。1つ目で10808を含むTCPレコードを検索します。LISTENING の行の右端にあるPIDを確認し、2つ目のコマンドの1234を実際のPIDに置き換えてください。「ローカルアドレス」列も確認し、リモートポートがたまたま10808の接続をローカルの待ち受けと誤認しないようにします。

netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 1234"

• プロセスの重複：タスクトレイから別のv2rayNインスタンスを正常に終了し、ポートを再確認します。プロセスが残っている場合は、タスクマネージャーで実行ファイルのパスを確認してからタスクを終了してください。
• 別のプログラムによる占有：「設定」→「パラメーター設定」を開き、ローカルのインバウンド待ち受けポートの項目を探します。10818が空いていると確認できた場合は、10808から10818に変更できます。この数値は例であり、すべてのPCで利用できるとは限りません。
• 手動設定も変更：ブラウザーなどのプログラムに 127.0.0.1:10808 を手動で入力している場合は、待ち受けポートの変更に合わせて設定も更新してください。v2rayNのシステムプロキシメニューを使っている場合は、システムプロキシを再適用します。
• 待ち受けプロセスが見つからない：アドレスの競合ではなくアクセス拒否がログに表示される場合は、netsh interface ipv4 show excludedportrange protocol=tcp を実行して、予約済みポートの範囲を確認します。この問題への対処として、ファイアウォールを無効にしたり、システムの予約項目を削除したりしないでください。

3. JSON構文エラー：形式を直してからプロトコルのフィールドを確認

カスタム設定で起動に失敗する場合、まずJSONの解析段階で止まっていないか確認します。よくある原因は、末尾の余分なカンマ、日本語の引用符、閉じていないオブジェクトの括弧、Windowsのパスに含まれるエスケープされていないバックスラッシュです。通常のサブスクリプションノードでは、v2rayNが実行用の設定を生成します。設定を手動で編集していない場合も、感覚でファイル全体を書き換えるのではなく、サブスクリプションの内容と生成処理を確認してください。

以下は意図的に誤りを残した例です。"warning" の後ろにあるカンマは、オブジェクトの最後のフィールドの後には置けません。構文を説明するための例であり、実際に使えるプロキシ設定ではありません。

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

このカンマを削除すると、JSONの構文は正しくなります。ただし、構文が正しくてもコアの設定として有効とは限りません。フィールド名、値の型、プロトコルの対応範囲も確認してください。パスは "C:\\Tools\\v2rayN\\rules" のように記述します。JSON文字列に単独のバックスラッシュをそのまま入れることはできません。

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

4. 未知のフィールド：使用中のコアと設定元を確認

JSONを解析できても、コアが特定のフィールドやプロトコルを受け付けない場合があります。設定に対応するコアと、そのバージョンを確認してください。v2rayNとコアのバージョンは別物です。画面のプログラムを更新しても、すべてのコアが更新されるわけではありません。判断の基準は、ログに記録された実際の実行ファイルとバージョンです。

XrayとV2Flyの設定方式には共通点がありますが、すべての項目を相互に使えるわけではありません。たとえば、REALITYやXTLS VisionはXrayに関連する機能です。これらの設定を含む設定を、そのままV2Flyに渡すことはできません。Xrayを使っている場合でも、古いコアでは新しい設定項目を認識できないことがあります。

• 「設定」→「パラメーター設定」でコア関連の項目を探し、現在のノードで使用しているコアを確認してください。画面のレイアウトが異なる場合は、起動ログに表示される名称を最終的な判断材料にします。
• 「更新を確認」にある該当コアの更新機能からバージョンの問題に対処します。更新後にノードを再起動し、新しいバージョンのログを確認して、更新が適用されたことを確かめてください。
• 手動で設定した場合は、まずフィールドが属するオブジェクトを確認し、次に値の型を確認します。数値、文字列、配列を自由に入れ替えることはできません。また、未知のフィールドの扱いはパーサーによって異なる場合があります。
• サブスクリプション内の1つのノードだけが失敗し、ほかのノードは正常に起動する場合は、まずそのノードのプロトコル、トランスポート方式、セキュリティ設定を比較してください。クライアント全体をすぐにリセットする必要はありません。

5. geoファイル不足：ログに記載されたパスからルール用ファイルを復元

設定の geoip: と geosite: のルールには、通常、対応するリソースファイルが必要です。ルールの初期化は起動時に行われるため、リソースの不足、読み取り権限の不足、ファイル形式の不一致でもコアが終了することがあります。ログにファイル名が表示されたら、ダウンロードフォルダーに同名のファイルがあるかだけでなく、実際に読み込もうとしているパスを確認してください。

1. 読み込み対象を確認。エラーの連鎖からファイル名とパスを控えてください。読み込み対象がコアの設定、ルール用リソース、実行ファイルのどれかを見分けます。「ファイルが見つからない」という同じメッセージでも、常にgeo関連の問題とは限りません。
2. ディレクトリ構成を復元。プログラムを移行した直後であれば、メインプログラムだけをコピーしていないか確認します。設定をバックアップしてから関連ファイルを復元し、異なる提供元のリソースをむやみに組み合わせないでください。
3. リソースを更新。「更新を確認」からGeoファイル関連の更新項目を探し、更新が完了してからコアを再起動してください。リソースごとに更新項目が分かれている場合は、それぞれの更新結果を確認します。
4. 項目名を確認。ファイルがあるのに特定のカテゴリが見つからない場合は、ルーティングルールのカテゴリ名と現在のデータファイルの内容を照合してください。再ダウンロードしても、もともと存在しないカテゴリ名は解決できません。

6. 修正後の確認：待ち受けを確認してからリクエストをテスト

修正の効果はウィンドウが開いたままかどうかではなく、同じ種類のエラーが消えたかで判断します。ノードを再度有効にし、まずコアがすぐに終了しないことを確認します。次に待ち受けポートを確認し、最後にシステムプロキシを有効にしてアクセスをテストしてください。ここでTLS、DNS、タイムアウトのエラーが出た場合は接続段階に進んでいます。新しいエラーの種類に応じて調査してください。

• プロセス：起動後に終了するメッセージがログに繰り返し表示されず、コアのプロセスが実行中のままであること。
• 待ち受け：netstat -ano -p tcp | findstr ":10808" を実行します。ポートを実際の設定値に置き換え、ローカルアドレスで想定どおりに待ち受けていることを確認してください。
• アプリ：タスクトレイの「システムプロキシ」で「システムプロキシを自動設定」を選び、ブラウザーから実際にリクエストを送信します。手動でプロキシを設定している場合は、アドレスとポートを確認してください。
• 設定の保持：別のノードに切り替えてから元のノードに戻し、修正が維持されていることを確認します。エラーが再発する場合は、自動的に上書きされる生成ファイルだけを変更していなかったか確認してください。