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

1. まず確認：コアが起動していないのか、通信できないのか

v2rayNはクライアントの画面を提供し、XrayやV2Flyなどのコアが設定の読み込み、インバウンドの待ち受け、アウトバウンド接続を担います。画面が開き、サブスクリプションを更新できても、コアが正常に動作しているとは限りません。反対に、ブラウザーでページが開けなくても、必ずしもコアの起動失敗とは限りません。リモート接続のタイムアウト、証明書の検証失敗、DNSクエリの異常は、コアの起動後に発生することがあります。

この流れはエラーが発生した段階を特定するためのもので、すべてのコアバージョンで内部処理が厳密にこの順序になるわけではありません。まず起動失敗ログから、最も詳細な原因を探してください。コアが動作を続けた後に connection refused や i/o timeout が出た場合は、宛先を踏まえてローカル接続かリモート接続かを判断します。すぐにJSONエラーと決めつけないでください。

• 設定段階：解析エラー、プロトコルの識別失敗、ルールデータの読み込み失敗が出た場合は、まず設定やリソースのパスを修正します。
• 待ち受け段階：bind、listen tcp などのキーワードがある場合は、ローカルアドレス、ポートの競合、権限を優先して確認します。
• リクエスト段階：インバウンドで受信した記録があり、その後リモート接続がタイムアウトする場合は、ノード、DNS、ルーティング、サーバーへの接続状況を確認します。

2. 起動ログを一連の流れで記録する

ログは起動操作の前からエラー発生後まで記録してください。「起動失敗」の一言だけを切り取るのは避けましょう。画面上のメッセージは結果にすぎず、実際の原因は後続の failed to、ファイル名、システムエラーなどに含まれていることがあります。続けて何度も起動すると複数回分のログが混在するため、いったんサービスを停止し、1回だけ再現してください。

1. 環境を記録

   OS、クライアントのバージョン、現在のコア名とバージョンを記録します。v2rayNGはXray、v2flyNGはV2Flyを使用します。v2rayNでは現在選択中のコアを確認し、ウィンドウ名だけで判断しないでください。

2. ログを開く

   v2rayNではメイン画面下部のログ欄を確認します。折りたたまれている場合は、ログパネルを展開してください。v2rayNGではメイン画面のメニューから「ログ」を開きます。バージョンによって場所が異なる場合があるため、現在の画面に表示されている項目名を確認してください。

3. 1回だけ再現

   接続を停止し、現在時刻を記録してから1回起動します。起動前後のログを続けて保存し、最初の失敗メッセージとその原因の流れを全文記録してください。最後の1行だけでは不十分です。

4. バックアップしてから変更

   カスタム設定とルーティングルールをバックアップし、1回につき変更する項目は1つにします。ログを共有する前に、サブスクリプションURL、ノードの認証情報、UUID、サーバーアドレス、個人名を含むディレクトリ名を伏せてください。項目名、エラーの種類、ポート番号は残します。

クライアントがコアプロセスを作成できず、コアからの出力もまったくない場合は、まずコアの実行ファイルが存在するか、アーカイブが正しく展開されているか、OSのセキュリティ機能に実行を阻止されていないか、インストールパッケージがCPUアーキテクチャに合っているかを確認してください。この問題は設定の解析前に発生するため、ノードのパラメータを何度も変更しても解決しません。

3. ポート競合：待ち受け中のプロセスを調べてからポートを変更

ローカルプロキシは、待ち受けアドレスとポートをバインドする必要があります。同じアドレスの同じTCPポートを、複数の独立したリスナーが同時に使用することは通常できません。クライアントの多重起動、終了しきれていないコア、ほかのプログラムによる同一ポートの使用などが原因で、新しいコアがすぐに終了することがあります。リモートサーバーのポートとローカルのインバウンドポートを混同しないでください。

上記の数値はトラブルシューティング用の例であり、すべてのバージョンの既定値ではありません。ログに 127.0.0.1:10808 のバインド失敗が記録されている場合は、Windows PowerShellで以下のコマンドを実行します。使用中ポートのプロセスIDを確認したら、続けてプロセス名を調べてください。

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

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 10808).OwningProcess

Linuxでは ss -ltnp 'sport = :10808'、macOSでは lsof -nP -iTCP:10808 -sTCP:LISTEN を実行します。結果がない場合でも、検索時点で該当するTCP待ち受けがなかったことを示すだけです。起動時の一時的な競合、UDPの競合、権限制限までは否定できません。ログに記録されたネットワーク種別と合わせて確認してください。

• 古いコアのプロセスが見つかった場合は、まず所属するクライアントから通常の方法で終了し、ポートが解放されたことを確認してから対象のクライアントを起動します。
• 10818 に変更する場合も、事前に空いていることを確認してください。変更後は、手動設定したブラウザーやターミナルのプロキシなど、ほかのローカル接続設定も更新します。
• ログに存在しないローカルIPアドレスが示されている場合は、待ち受けアドレスを修正してください。ローカルからのみアクセスする場合は、用途に応じて 127.0.0.1 を使用できます。エラーを消すためだけに、すべてのネットワークインターフェースで待ち受ける設定にしないでください。

4. JSON構文エラー：「形式の誤り」と「項目の非互換」を切り分ける

厳密なJSONでは、キー名と文字列を半角のダブルクォーテーションで囲み、配列やオブジェクト内のカンマも正しい位置に置く必要があります。全角の引用符、末尾の余分なカンマ、コピー時の括弧の欠落があると、設定の読み込みに失敗します。読み込み方法によってはコメントなどの拡張構文に対応する場合もありますが、対応していない場合もあります。差異を減らすため、検証用のコピーでは厳密なJSONを使ってください。

以下は構文の説明用であり、そのまま実行できる完全なプロキシ設定ではありません。loglevel の後に余分なカンマはなく、外側と内側のオブジェクトをそれぞれ閉じています。

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

JSONの形式チェックに通っても、テキスト構造が正しいことしか確認できません。プロトコル名、トランスポート設定、項目の型が正しいとは限りません。認識されない項目がエラーにならず、無視される場合もあります。実際に使用しているコアで設定をテストしてください。

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

• 上記の例は、このコマンドを提供するバージョンのXrayで使用できます。まず .\xray.exe help run を実行して引数を確認してください。LinuxとmacOSでは、対応する実行ファイルのパスを使用します。
• config.json は、ローカルに実在する設定ファイルのコピーである必要があります。クライアントが設定を自動生成する場合は、テスト対象が現在のノードで実際に使われる内容と一致していることを確認してください。
• コマンドラインでのテストとクライアントの起動では、作業ディレクトリ、環境変数、リソースのパスが異なる場合があります。テストに成功した後も、クライアント上で再確認してください。
• ノードの認証情報を含むJSON全体を、見知らぬオンライン整形サービスにアップロードしないでください。ローカルのエディターやコアのテスト機能を使いましょう。

5. 未知のプロトコルや項目のエラー：実際に動作しているコアを確認

共有リンク、サブスクリプションの内容、ネイティブ設定は、それぞれ異なる入力形式です。vless:// や vmess:// の共有リンクはクライアントで解析する必要があり、JSON設定として保存してコアに直接読み込ませることはできません。サブスクリプションのノードが一覧に表示されていても、現在のコアがすべてのトランスポートやセキュリティ設定に対応しているとは限りません。

VLESSはプロトコル名で、REALITYは関連するセキュリティ設定の一部です。どちらも protocol の値として互いに置き換えられるものではありません。トランスポート方式、セキュリティ設定、サーバー名、認証情報はサーバー側の指定に合わせてください。起動できるプロトコル名に変更しただけでは、ノードに接続できるとは限りません。

• v2rayN：現在のノードで使われているコアと、その起動ログを確認してください。コアを切り替えた後は設定を再生成し、前回の設定ファイルを誤ってテストし続けないようにします。
• v2rayNG：クライアントに付属するXrayの機能に基づいて確認します。新しいパラメータを認識しない場合は、まずクライアントとコアのバージョンを確認し、更新が必要か判断してください。
• v2flyNG：V2Flyの設定仕様に基づいて確認します。Xray向けのJSON全体をそのまま読み込んでも、同じ動作になるとは限りません。

6. geoファイルが見つからない：データ名、パス、ルールの参照先を確認

ルーティング設定の geosite: と geoip: の参照には、対応するデータが必要です。設定の構文が正しくても、実行環境からデータファイルを見つけられない場合や、データに参照先のカテゴリがない場合は、ルールの構築に失敗することがあります。まずエラーが「ファイルを開けない」のか「カテゴリが見つからない」のかを確認してください。対処方法はそれぞれ異なります。

1. エラーに記載された geosite.dat や geoip.dat などのファイル名と、完全なパスを記録してください。クライアントのインストール先からリソースの場所を推測しないでください。
2. ファイルが読み取り可能で、空ではないことを確認します。Linuxではファイル名の大文字・小文字が区別され、ディレクトリの権限もコアの読み込みに影響します。
3. クライアントに用意されたデータ更新機能を使い、対応するデータファイルを復元してください。画面に更新機能がない場合は、そのクライアントのリソース管理方法に従います。異なる形式のデータをむやみに混在させないでください。
4. ファイルが存在するのにカテゴリが見つからない場合は、geosite: の後のカテゴリ名のスペルと、現在のデータ内容を確認してください。サードパーティーのカテゴリ名が、すべてのデータファイルに含まれているとは限りません。
5. バックアップを取ったうえで、問題のあるルールを一時的に1つ削除し、起動をテストしてください。起動できた場合でも、原因がそのルールかリソースに絞られただけです。正式な設定に戻す前に、データとルールを補完してください。

トラブルシューティング中にすべてのルーティングルールを削除すると、リクエストの経路が変わります。本来は直接接続するリクエストがプロキシに送られたり、プロキシを通すリクエストが直接接続になったりする可能性があります。原因を特定したら元のルーティング方針に戻し、outboundTag が実在するアウトバウンドのタグに対応しているか確認してください。

7. Androidのサービス異常と修正後の確認

v2rayNGはAndroidのシステムVPNインターフェースを使って通信を取り込みます。VPNの許可に関する失敗と、Xrayの設定解析エラーは別の段階の問題です。前者はシステムの許可、ほかのVPNサービス、端末のポリシーを確認し、後者はJSON、プロトコル、リソースに関するログを調べてください。V2Flyコアを使うv2flyNGでも、この区別を保って切り分けます。

• サービス開始直後に停止する：まず起動ログの最初のエラーを確認し、システムVPNの許可が完了しているか調べてください。ステータスバーのアイコンだけで原因を判断しないでください。
• ほかのVPNが動作中：競合するVPNサービスを停止してください。Androidでは通常、同じユーザーで通信を制御できるアクティブなVPNサービスは1つだけです。
• 画面ロック後に切断する：起動時は正常でも、バックグラウンドでしばらく動作した後に停止する場合は、システムのバッテリー最適化やバックグラウンド制限を確認してください。設定の読み込み失敗でよく見られる症状ではありません。
• サービスは動作するが通信がない：アプリごとのプロキシ対象、DNS、ルーティング、現在のノードへの到達性を確認してください。システムVPNインターフェースが有効でも、すべてのアプリのリクエストが目的のアウトバウンドに届くとは限りません。

修正後は、同じノードと同じテスト条件で確認します。まずコアがすぐに終了しないことを確認し、次にローカルの待ち受けまたはAndroidのVPNサービスが正常であることを確かめてから、Webページへのアクセスをテストしてください。システムプロキシ、VPN接続、コアプロセスはそれぞれ別の段階です。どれか1つが正常なだけでは、接続全体が使えるとは判断できません。

1. 再起動して確認

   サービスを停止してからもう一度起動し、元のエラーが再発しないことを確認します。別のエラーが出た場合は、そのエラーが属する段階から調べてください。

2. 接続設定を確認

   デスクトップでは実際の待ち受けポートとシステムプロキシの設定を、AndroidではVPNサービスと対象アプリの範囲を確認します。ポートを変更した場合は、手動で設定した接続先もすべて更新してください。

3. リクエストを送信

   ブラウザーで正常に使えることがわかっているHTTPSページを開き、対応するリクエストがログに記録されるか確認します。リモート接続のタイムアウトだけが発生する場合は、ノードやネットワークを調べ、JSONの句読点を何度も変更するのはやめてください。

4. 設定を元に戻す

   調査中に一時変更したルーティングとログレベルを元に戻し、最終的な設定のコピーを保存します。「エラーの原文、変更内容、検証結果」を記録しておくと、次回の更新後に比較できます。