v2rayNGのコア起動エラー対処法｜ログから設定ミスを特定

まず確認：コアが起動しないのか、起動後に接続できないのか

v2rayNGはAndroid向けクライアントです。この記事では、使用しているXrayコアのログをもとにトラブルを調べます。接続後にVPNアイコンが表示されても、Android側でサービスが開始したことを示すだけで、ノードが使えるとは限りません。一方、Webページが開けなくても、コアの起動失敗とは限りません。ローカルの待ち受けが確立し、初回アクセス時にタイムアウトする場合は、リモート接続経路を確認しましょう。

1つのログに>で複数段階の原因がつながって表示されることがあります。先頭の「起動失敗」は結果であり、その後に続く文字・ポート・証明書についての説明が根本原因に近い情報です。ログを読むときはエラーの流れ全体を残し、末尾から具体的な対象を探してください。目立つ赤い1行だけを切り取らないようにしましょう。

ログを一度きれいに取得する：接続ボタンを押すところから

現在のノードとカスタム設定を保存してから、ログを取得します。v2rayNGはバージョンによって翻訳やメニューの場所が異なる場合があります。一般的には、メイン画面左上のメニューに「ログ」があり、ログレベルは「設定」で変更できます。同じ名前の項目が見つからない場合は、使用中のバージョンの画面を確認してください。デスクトップ版v2rayNの「パラメーター設定」の手順を流用しないでください。

1. 環境を記録する

   Androidの「設定」→「アプリ」→「v2rayNG」のアプリ情報でクライアントのバージョンを確認し、Androidのバージョン、ノードのプロトコル、カスタム設定の使用有無も記録します。ログにコアのバージョンが表示されている場合は、それも控えてください。

2. 接続を停止する

   v2rayNGのメイン画面に戻り、接続ボタンを押してサービスを停止します。AndroidのVPNサービス切り替えによる影響を避けるため、ほかのVPNアプリも一時的に停止してください。

3. ログレベルを変更する

   「設定」→「ログレベル」を開き、まずinfoを選択します。手がかりが足りない場合は、一時的にdebugへ変更してください。完全なカスタムJSONを使っている場合は、log.loglevelも確認します。

4. 問題を再現する

   「ログ」を開いてログを消去し、メイン画面に戻って一度だけ接続します。サービスが動作し続ける場合は、Webページに一度アクセスしてからログに戻り、同じ時間帯の記録を確認してください。

5. 前後の記録を残す

   最初の失敗の前後を含め、ログ全体をコピーします。共有する前に、サブスクリプションURL、UUID、パスワード、サーバー情報を伏せてください。ただし、フィールド名、エラーの順序、同じアドレス同士の対応関係は残します。

debugは詳細な情報、infoは通常の処理、warningは注意が必要な状態、errorは処理の失敗を示します。ノードの良し悪しを評価するものではありません。特定のリクエストでエラーが出ても、コア全体が終了したとは限りません。エラーが記録されない場合も、ログレベルが高すぎる可能性があります。調査が終わったら、詳細なログレベルを元に戻し、不要な記録を減らしてください。

JSON構文エラー：まず形式を直し、その後ノードを確認

カスタム設定を読み込んだ直後に起動できない場合は、まず解析エラーを確認します。JSONのキー名と文字列には半角の二重引用符が必要です。全角引用符、カンマの抜け、末尾の余分なカンマはエラーの原因になります。設定の移行やトラブル調査をしやすくするため、ここではコメント機能の拡張に依存しない厳密なJSONを例に使います。

次の部分例では、"warning"の後に余分なカンマがあります。エラー位置はカンマではなく次の行の閉じ波括弧を示すことがあるため、特定するときは1行前も確認してください。

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

修正後の例は次のとおりです。logの書き方を示すだけで、単独で接続できる完全な設定ではありません。元のファイルで該当するオブジェクトだけを置き換え、既存のinbound、outbound、ルーティングは上書きしないでください。

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

ポート競合：ローカル待ち受けを確認し、サーバー側のポートは変更しない

bindエラーはローカル待ち受けの段階で発生します。リモート接続の失敗とは別の問題です。以下の数値は調査用の例で、すべてのv2rayNG環境における初期設定ではありません。「設定」に表示されるローカルポートと実際のログを確認してください。

ログに127.0.0.1:10808のバインド失敗が明記されている場合は、ローカルSOCKSポートを未使用の10818に変更して再起動する方法があります。そのSOCKSポートを利用するほかのアプリも、同じポートに変更してください。ノード編集画面のリモートポートだけを変更しても、ローカル待ち受けは解放されません。正しいノード設定を壊すおそれもあります。

キーの誤記とコアの対応状況：JSONが正しいだけでは不十分

JSONを解析できても、すべての値をXrayが受け付けるとは限りません。たとえばstreamSettingsのnetworkには、コアが対応するトランスポート名を指定します。WebSocketの場合はwsであり、任意にwebsocketと書くことはできません。クライアント画面に表示されるプロトコル名が、設定内の文字列と一致するとも限りません。

• 大文字・小文字を確認：streamSettings、serverName、wsSettingsは設定仕様どおりに記述します。似た綴りから推測しないでください。
• フィールドの型を確認：真偽値はtrueまたはfalseとし、引用符を付けて文字列にしないでください。ポートは通常、数値で指定します。
• 配置する階層を確認：TLSのserverNameは対応するtlsSettings内に記述します。outboundオブジェクトの最上位に移動しないでください。
• パラメーターの組み合わせを確認：VLESSとVMessはプロキシプロトコル、WebSocketはトランスポート、TLSはセキュリティ層です。読み込み時にはそれぞれを個別に確認し、互いに置き換えないでください。

以下はWebSocketとTLSの構造を確認するための例です。ドメイン名とパスはサンプル値のため、実際にはサーバー側の設定と一致させてください。このオブジェクトだけでは完全なoutbound設定になりません。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/tunnel",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

未知のフィールドがあっても、必ず起動エラーになるとは限りません。読み込み時に無視され、設定したつもりの項目が反映されないことがあります。一方、新しいパラメーターを非対応の古いコアに渡すと、設定の構築に失敗する場合があります。更新前にクライアントとコアの情報を記録し、元の設定を保存してください。更新後はまず元のノードをテストし、プロトコルとルーティング全体を同時に変更しないようにしましょう。

通信・証明書のエラー：通常は起動後に発生

コアがローカル待ち受けを開始し、Webページにアクセスしたときだけ次のエラーが出る場合は、JSONのカンマを調べ続ける必要はありません。まずノードのアドレスとリモートポートを確認し、TLS、セキュリティ設定、通信設定を照合します。以下はよくあるエラー例です。ログの先頭部分や付加される文言は、コアのバージョンによって異なります。

TLSのserverNameは、サーバー名に関するハンドシェイクと証明書検証に使われます。WebSocketのHostはHTTP層のリクエストに使われます。両者が同じ場合もあれば、サーバーの構成によって異なる場合もあります。エラーを消すために証明書の検証を無効にしないでください。ドメインや証明書の設定ミスが隠れてしまいます。

修正後に再テスト：記録を残し、手当たり次第に変更しない

設定を1か所変更したら、サービスを停止して古いログを消去し、再接続します。まずコアが動作し続けることを確認し、次にWebページへ一度アクセスして、そのリクエストで新しいエラーが発生していないか調べます。サブスクリプションの更新でノードが再生成されると、手動変更が上書きされることがあります。「今は使える」とだけ覚えるのではなく、変更した理由を記録してください。

最後に、クライアントのバージョン、使用中のコア情報、最初に発生したエラーの全体、変更した項目、再テストの結果を簡潔に記録しておきましょう。同じエラーが再発しても、以前の問題が戻ったのか、次の段階で新たな問題が起きたのかを判断しやすくなります。