v2rayNのコアが起動しないときの対処法：ログから設定エラーを行単位で特定

まずv2rayNの起動の流れを整理する

起動ボタンを押しても、v2rayNがすぐにプロキシ接続を確立するわけではありません。現在のサーバー、ルーティング、DNS、ローカルポートの設定を読み込み、コアが使う設定を生成してから、XrayまたはV2Rayのコアプロセスを起動します。コアが設定を読み込み、ローカルポートの待ち受けを開始した後、リモートサーバーへの接続を試みます。

そのため、「コアの起動に失敗する」問題と「コアは動作しているのにウェブサイトを開けない」問題は別物です。前者では、プロセスが起動直後に終了する、タスクトレイの状態がすぐ元に戻る、ログに設定の解析エラーや待ち受け失敗が出る、といった症状が見られます。後者では、ローカルのSOCKSやHTTPポートが待ち受け状態になっている一方、ハンドシェイク、名前解決、ルーティングの段階で失敗していることが多いです。

切り分けでは、まず次の3点を確認します。

1. コアプロセスは本当に起動し、動作し続けているか？
2. ローカルプロキシポートは正常に待ち受け状態になっているか？
3. 最初の致命的なエラーは、設定の読み込み、ポートの待ち受け、リモート接続のどの段階で発生しているか？

ログ画面を開き、起動プロセス全体を記録する

v2rayNのメイン画面でログエリアまたはログ画面を開き、現在のコアを停止します。ログを確認しやすくしてから対象サーバーを選び、起動ボタンを1回だけ押してください。連続して再試行すると複数回の記録が混ざり、短時間だけ動作した古いプロセスが残ってポート競合の判断も難しくなります。

ログを読むときは、まずタイムスタンプが直前の操作のものか確認し、そのうえでv2rayN自身の出力とコアの出力を区別します。画面側は設定の生成とプロセスの呼び出しを担当し、XrayやV2Rayの出力のほうが実際の失敗箇所に近い情報を示します。手がかりはおおむね次のグループに分けられます。

• 設定の解析：invalid、failed to parse、unexpected、unknown fieldなどのキーワードが表示される。
• ポートの待ち受け：bind、listen、address already in use、access deniedなどが表示される。
• プロトコルパラメータ：UUID、security、flow、transport、Reality、TLSなどのフィールド名が表示される。
• ファイルとプロセス：file not found、permission denied、cannot execute、パスエラーなどが表示される。
• リモート接続：timeout、connection refused、handshake、certificate、DNSクエリ失敗などが表示される。

ログに「プロセス終了」や終了コードしか表示されない場合は、数行上へスクロールしてください。終了コードからプロセスが正常に完了しなかったことは分かりますが、具体的なフィールドまでは分からないことがあります。実際に対処できる情報は、その直前にあることが多いです。一時的にログレベルを上げる方法もありますが、修正後は通常のレベルに戻し、大量のデバッグ記録で重要なエラーが埋もれないようにしてください。

ログを管理者や開発者に共有する前に、サブスクリプションURL、サーバーアドレス、ユーザー識別子、パスワード、Reality公開鍵に関する設定、完全な共有リンクを削除してください。エラーの種類、フィールド名、発生順序、クライアントのバージョン、コアの種類を残せば、通常は原因の特定に十分です。

bindやaddress already in useが表示される場合：ポート競合に対処する

v2rayNは、SOCKSやHTTPなどのローカル入口ポートを待ち受ける必要があります。別のプログラム、終了しきれていないコアプロセス、または2つ目のv2rayNが同じポートを使用していると、新しいプロセスはすぐに終了します。ログにはbind failed、address already in use、または1つのソケットアドレスは一度しか使用できないというシステムメッセージが表示されることがあります。

まずv2rayNの設定で現在のローカルポートを控えます。ポート番号は固定とは限らないため、現在の画面と今回生成された設定を基準にしてください。Windowsのターミナルでは、次のコマンドで使用中のプロセスを確認できます。例のポート番号は実際の値に置き換えてください。

netstat -ano | findstr :10808
tasklist /FI "PID eq プロセスID"

1つ目のコマンドの末尾にプロセスIDが表示され、2つ目のコマンドでそのIDをもとにプログラム名を確認できます。使用中のプロセスが前回の異常終了で残ったコアなら、まずv2rayNから正常にコアを停止し、プロセスが終了したか確認してください。別のプロキシツールやローカル開発サービスであれば、競合するプログラムを終了するか、v2rayNで未使用のポートに変更します。

ポートを変更した後は、ブラウザー、ターミナルの環境変数、手動でプロキシを設定するアプリも確認してください。コアが起動してもアプリが古いポートを参照していると、「起動したのにアクセスできない」という二次的な問題が起きます。競合を避けるために複数のポートを無作為に変更しないでください。毎回1項目だけ変更し、変更前後の値を記録します。

parseやinvalid characterが表示される場合：JSONとルール構造を修正する

v2rayNは通常、画面上の設定に基づいて設定ファイルを生成します。カスタム設定、手動編集したアウトバウンド、複雑なルーティングルールを使っている場合や、インポートした内容自体が不完全な場合、コアが解析できないJSONが生成されることがあります。代表的なログにはunexpected end、invalid character、failed to parse config、unknown field、cannot unmarshalなどがあります。

unexpected endは、右中括弧や右角括弧が欠けるなど、内容が途中で切れていることを示す場合があります。invalid characterは、余分なカンマ、日本語の句読点、誤った引用符、記述できないコメントなどを指していることが多いです。標準JSONのキー名と文字列には半角の英語ダブルクォーテーションを使い、最後の項目の後に余分なカンマを置かず、コメントも直接記述しないでください。

次のような構造は、末尾の余分なカンマが原因で失敗します。

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

修正時は、ログに表示された行番号だけを見ないでください。パーサーは「これ以上読み取れない」と判断した位置でエラーを報告することが多く、実際に不足している記号は前の行にある場合があります。まずエラー行の前後にあるカンマ、引用符、括弧が対応しているか確認し、次にフィールドの型を確認します。たとえばポートが数値であるべき場合、余計な文字を含むテキストとして記述してはいけません。

ルーティング設定では、構造は正しくてもフィールドの内容が無効になることがあります。ドメインルール、IPルール、アウトバウンドのタグはそれぞれ意味が異なります。存在しないoutboundTagをルールから参照すると、コアが設定を拒否したり、実行時に意図した振り分けができなかったりします。新しいルールを追加した後にエラーが出た場合は、サブスクリプションをすべて削除するのではなく、直近に追加したルールを無効にして再起動してください。

カスタム設定を使う場合は、元ファイルのコピーを保存してから、最小限の動作する構造を起点にDNS、ルーティング、アウトバウンドを少しずつ追加するのが安全です。追加するたびに1回起動します。これなら数百行の設定を何度も推測しながら調べるのではなく、直近の変更に原因を絞り込めます。

設定は解析できるのに、プロトコルパラメータが一致しない

JSON構文が正しくても、接続パラメータが正しいとは限りません。VMessとVLESSは異なるプロトコルであり、認証フィールド、転送設定、暗号化関連のオプションを相互に流用することはできません。サブスクリプションをインポートすると、v2rayNは各項目からアウトバウンド設定を生成します。サブスクリプションの内容が古い、フィールドが不足している、手動編集でプロトコルを間違えた、といった場合、起動時のチェックや初回接続時にパラメータが無効だと報告されることがあります。

VLESSの項目を確認する

VLESSの項目では、少なくともサーバーアドレス、ポート、ユーザー識別子、転送方式、セキュリティ層を確認します。REALITYを使う場合は、serverName、公​​開鍵、shortId、フィンガープリント、flowなどがサーバー側の情報と一致しているか確認してください。一般的なflowの値は転送方式との組み合わせによって異なるため、別のノードで使われている値をそのまま流用しないでください。

ログにunsupported flow、invalid public key、Reality handshakeなどが出た場合は、まずサブスクリプションの提供元に戻って項目を更新し、推測でフィールドを追加しないでください。サーバーアドレスを解決でき、ポートに接続できても、ネットワークが宛先に到達したことしか示しません。REALITYのパラメータが一致している証拠にはなりません。

VMessの項目を確認する

VMessも、正しいユーザー識別子、ポート、転送パラメータに依存します。古い設定にはalterIdなどの旧来のフィールドが含まれている場合がありますが、新しいサーバーでは異なる推奨設定が使われることがあります。クライアントの項目は現在のサーバー設定を基準にし、古いノードのパラメータを新しいノードに継ぎ足さないでください。サブスクリプション更新後に1つのVMessノードだけ失敗する場合は、そのノードを複製して比較できますが、元の項目を変更して参照先を失わないようにしてください。

転送層を確認する

TCP、WebSocket、gRPCなどの転送方式には、それぞれ異なるフィールドがあります。WebSocketではパスとHost、gRPCではサービス名、TLSではserverNameが関係することが多いです。パスのスラッシュが1つ多い、サービス名の大文字・小文字が違う、Hostの指定先が誤っている、といった違いにより、コアは正常に起動してもハンドシェイク段階で失敗することがあります。

ノード固有の問題か全体設定の問題かを判断するには、同じサブスクリプション内の、動作確認済みの別サーバーを試します。すべてのノードがコア起動前に失敗するなら、ローカル設定、ポート、コアファイルを優先して確認します。1台のサーバーだけが接続段階で失敗するなら、その項目のプロトコルパラメータとサーバー側の状態を優先して確認します。

コアの種類、ファイルパス、読み書き権限を確認する

v2rayNは管理画面であり、実際のネットワーク処理はXrayまたはV2Rayのコアが行います。プロトコル機能やフィールドの一部は、特定のコアバージョンでのみ対応しています。unknown field、unsupported security、認識できないReality設定などが表示された場合は、まず項目で選択しているコアの種類を確認し、次にそのコアのバージョンが必要な機能に対応しているか確認してください。

設定エラーを隠すために、コアを何度も切り替えないでください。VLESSとREALITYの構成では、通常、対応するXrayの機能が必要です。一般的なVMess設定でも、選択したコアの形式に合うフィールドを指定しなければなりません。切り替え後にエラーが「未知のフィールド」から「ハンドシェイク失敗」に変わった場合、設定が次の段階まで進んだことは分かりますが、リモート側のパラメータは引き続き確認が必要です。

file not foundやcannot executeは、コアファイルの欠落、パスの変更、実行権限の不足を示していることが多いです。まずv2rayNの設定でコアのフォルダーを確認し、対象ファイルが実際に存在するか調べてください。プログラム全体を移動した、一部のファイルだけコピーした、旧バージョンに上書きアップデートした、といった場合、画面に記録されたパスが元の場所を指したままになっていることがあります。

設定フォルダーにも書き込み権限が必要です。v2rayNは起動前に一時設定や実行設定を生成します。現在のユーザーが書き込めない場所にプログラムがあると、コアを起動する前に失敗することがあります。現在のユーザーが通常どおり読み書きできるフォルダーにプログラムを置き、再起動して設定が生成されるかログで確認してください。長期的な対策として高い権限での実行だけに頼らないでください。設定ファイルの所有者が変わり、通常起動時に新たな読み書きの違いが生じる可能性があります。

セキュリティソフトやシステムポリシーがプロセスをブロックすると、ログには起動失敗やファイルアクセスエラーしか残らないことがあります。その場合は、システムのセキュリティ記録で具体的にブロックされたファイルとルールを確認し、実行を許可するか判断してください。テストのために保護機能全体を無効にしないでください。対象を明確なファイル、フォルダー、プロセスに絞るほうが、元に戻しやすく原因も確認しやすくなります。

再現性のある切り分け手順

ポート、ノード、ルーティング、DNSを同時に変更すると、結果を比較できなくなります。次の順番で操作し、各手順で1回ずつ再起動して、ログの最初のエラーを記録してください。

1. 現状を保存する。v2rayNのバージョン、コアの種類、対象サーバーのメモ、ローカルポート、最初のエラーを控えます。ログをコピーする前に、接続に関する機密情報を削除してください。
2. 古いプロセスを停止する。画面からコアを停止し、2つ目のv2rayNや、同じポートを待ち受け続ける残存コアがないことを確認します。
3. ローカルの待ち受けを確認する。bindやaccess deniedが出た場合は、リモート側のプロトコルパラメータを変更する前に、ポートと権限を解決してください。
4. 直近の変更を戻す。追加したばかりのカスタムルーティング、DNS、アウトバウンド設定を一時停止し、変更前の状態に戻します。
5. サブスクリプションを更新する。既存のサブスクリプショングループから更新を実行し、更新後の項目を選択します。サブスクリプションURLを単一ノードの共有リンクとしてインポートしないでください。
6. 同じ種類の別サーバーで試す。単一ノードのパラメータエラーと全体設定のエラーを区別するため、テスト中はローカルポートとルーティングを変更しないでください。
7. コアの対応機能を確認する。unknown fieldやunsupportedが表示された場合は、項目が必要とするプロトコル機能と現在のコアが一致しているか確認します。
8. 振り分け設定を戻す。コアが安定して動作してから、ルーティングとDNSを1項目ずつ有効に戻します。毎回1グループのルールだけを復元してください。

最小限のテスト環境を作る場合は、一時的にデフォルトルーティング、デフォルトDNS、パラメータが完全なことを確認したサーバー1台を使い、追加のカスタムインバウンドとアウトバウンドを無効にします。最小構成で起動できたら、サブスクリプショングループ、ドメイン振り分け、IPルール、カスタムDNSを順番に追加します。問題が発生した段階で、原因の範囲をその設定グループに絞れます。

よくある質問