v2rayNGを起動してすぐ停止する、設定の読み込みに失敗する、自分で用意したconfigを読み込んでも動作しない場合に役立ちます。まず起動ログを一通り保存し、構文、フィールド、待ち受け、outboundの順に確認しましょう。通常のサブスクリプションノードは編集画面で設定を直し、カスタム設定の場合に限ってJSONを直接確認します。最初からクライアントを再インストールする必要はありません。
まずログを開き、起動失敗と接続失敗を見分ける
v2rayNGのメイン画面で左上のメニューを開き、「ログ」を選択します。サービスを停止して古いログを消し、メイン画面に戻って問題のノードを選び、一度起動します。その後、再び「ログ」を開き、今回の起動記録をすべて保存してください。バージョンによってメニューの場所が異なる場合があるため、画面上の「ログ」を探します。「起動失敗」という最後の行だけでなく、その前の記録も確認してください。原因はその前に出ていることがよくあります。
-
設定をバックアップする
現在のノード名と設定の種類を記録します。手動で管理しているJSONはコピーを保存し、サブスクリプションノードは所属グループを控えておきましょう。後から更新した際に、一時的な修正が上書きされるのを防げます。
-
環境情報を記録する
サイドメニューの「このアプリについて」でクライアントのバージョンを確認します。起動ログにXrayのバージョンが表示されている場合は、あわせて記録してください。クライアントとコアのバージョン番号は別です。
-
一度だけ再現する
サービスを停止してログを消し、一度だけ起動します。AndroidのVPN接続許可が表示された場合は、設定エラーと取り違えないよう、先に許可してください。
-
原因をたどる
failed to load configまたはfailed to start以降のログを読みます。原因が複数段階にわたる場合は、具体的なフィールド名、ポート番号、JSON解析エラーの記述まで確認してください。
ログがリクエストの受信段階まで進んだ後に connection refused、i/o timeout、証明書のハンドシェイクエラーが出る場合は、通常は接続段階の問題であり、コアが起動していないわけではありません。この場合、JSONの句読点を何度も変更しても、接続先ポートに到達できない問題や証明書の不一致は解決しません。
最初の3段階で失敗する場合は、この記事で扱う設定やポートを優先して確認します。後半の2段階で失敗する場合は、ルーティング、DNS、ノードへの接続性、TLSを確認してください。ログの表現はXrayのバージョンによって異なります。以下はよくあるエラーの一部で、ログ全体が完全に一致する必要はありません。
1つ目：JSON構文エラーは括弧とデータ型から確認
カスタム設定を貼り付けた直後に起動できなくなった場合は、まずJSONを確認します。オブジェクトのキーと文字列は、どちらも半角の二重引用符で囲みます。オブジェクトや配列の最後の要素の後に余計なカンマを付けてはいけません。パーサーによる違いを避けるため、確認時はコメントを含まない標準JSONを使ってください。
エラー：invalid character '}' looking for beginning of object key string
原因：オブジェクトを閉じる前に余計なカンマがあり、パーサーが次のキーを待っている可能性があります。対処：エラー位置の直前にある要素を確認し、末尾のカンマを削除します。対応する波括弧が余分にないかも確認してください。
エラー：unexpected EOF
原因：オブジェクト、配列、文字列が閉じられる前に内容が途切れています。対処：コピーした範囲を確認し、本当に不足している部分を補ってください。ファイル末尾に機械的に括弧を追加するだけでは解決しません。
エラー：cannot unmarshal string into Go struct field
原因：フィールドの型がコアの想定と異なります。対処：後続のフィールドパスも確認し、該当フィールドの要件に合わせて数値、真偽値、配列、オブジェクトのいずれかに修正します。
以下は構文を説明するための一部分であり、そのまま読み込める完全なプロキシ設定ではありません。port は数値、listen は文字列で指定し、最後の要素の後にはカンマを付けません。型の誤りが見つかった場合は、フィールドごとに修正してください。数値をすべて文字列に変える必要はありません。
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks"
}2つ目：フィールド名の誤り。JSONが正しくても設定が有効とは限らない
構文を確認したら、フィールド名、階層、列挙値を確認します。トップレベルには通常、単数形ではなく inbounds と outbounds の2つの配列を指定します。通信設定には streamSettings を使い、その中の network にはコアが対応する値を指定してください。キーの大文字・小文字も変更しないでください。
- 階層の誤り：
streamSettingsをsettingsの中に置いても、現在のoutboundにトランスポート層を設定したことにはなりません。 - 列挙値の誤り：WebSocketのnetwork値には
wsを指定します。独自に省略したwebsoketと書かないでください。 - フィールドの混同：共有リンクのパラメーター名を、そのままJSONのキー名として使わないでください。リンクのパラメーター名とコア設定のTLSフィールド名は、必ずしも一致しません。
- バージョンによる違い：新しい設定フィールドには、より新しいコアが必要な場合があります。クライアントを更新した後も、実際に動作しているコアのバージョンを確認してください。ダウンロードした日付だけでは判断できません。
エラー：unknown transport protocol: websoket
原因：トランスポートプロトコル名が認識可能な列挙値ではありません。対処：サーバーの指定に合わせて streamSettings.network を修正します。サーバーがWebSocketを使う場合は ws を指定してください。
注意点として、不明なフィールドはエラーにならず、パーサーに無視されることがあります。そのため、構文エラーがないだけでは設定が反映されたとは限りません。通常のノードはメイン画面に戻り、対象ノードの編集画面でアドレス、ポート、プロトコル、通信設定を一つずつ確認します。フィールドを一つ修正するために、ノード全体をカスタムJSONに変更しないでください。
3つ目：inboundの待ち受け競合はアドレスとポートを確認
ログに bind: address already in use と表示される場合、ローカルの待ち受け先がすでに使われています。これは端末上のポート競合であり、ノードサーバーが接続を拒否しているわけではありません。ほかのプロキシサービスを停止し、カスタム設定で同じ待ち受けアドレス、ポート、トランスポートプロトコルが重複していないか確認してください。
これらの数値は確認方法を説明するための例であり、すべてのバージョンのデフォルト値を示すものではありません。通常の設定では、サイドメニューの「設定」からローカルSOCKSポートを探します。変更後はサービスを停止して再起動してください。項目名は使用中のバージョンによって異なります。カスタムJSONの場合は、実際の inbounds 内にある listen と port を確認します。共通設定がカスタム設定にも適用されるとは限りません。
エラー：listen tcp 127.0.0.1:10808: bind: address already in use
原因：このTCP待ち受け先は、ほかのプロセスによって使用されています。対処：使用中のサービスを停止するか、空いていることを確認した高い番号のポートに変更します。その後、このプロキシポートを手動設定しているアプリのポートも同じ値に変更してください。
結論：変更するのはローカルポート。ノードのポートは変更しない
ログに listen と bind が出ている場合は、まずローカルのinboundを確認します。ついでにリモートサーバーのポートまで10818に変更しないでください。リモートポートはサーバーが実際に待ち受けている番号と一致させる必要があります。
0.0.0.0 はすべてのアドレスで待ち受ける設定を示し、同じポートで特定のIPv4アドレスを指定した待ち受けと競合する場合があります。2つのinboundが競合するかどうかは、TCP・UDPやアドレスファミリーにも左右されます。ポート番号だけで判断しないでください。また、問題を回避するためにLANからの接続を安易に許可すると、ローカルプロキシにアクセスできる範囲が広がります。
4つ目：outboundパラメーターの不足はプロトコルごとの必須項目を確認
outboundでは、接続先サーバー、使用するプロトコル、認証方法を指定します。VMessとVLESSの一般的なJSON outboundでは、サーバーを settings.vnext、ユーザーを users に記述します。Trojanでは通常 settings.servers を使います。異なるプロトコルのフィールドを混在させると、JSONとして正しくてもoutboundの構築に失敗する場合があります。
| プロトコル | まず確認する設定パス | よくある問題 |
|---|---|---|
| VMess | settings.vnext[].address / port / users[].id | アドレスが空、ポートが未設定、ユーザーIDの形式が不正 |
| VLESS | settings.vnext[].users[].id / encryption | UUIDが不正。通常の設定ではencryptionにnoneを指定し、使用中のコアの要件を満たす必要があります |
| Trojan | settings.servers[].address / port / password | vnext形式を誤って使用、またはパスワードやサーバーアドレスが不足 |
エラー：invalid UUID
原因：ユーザーIDを、このコアが受け付ける形式として解析できません。対処：元のノード情報からID全体をコピーし直し、空白、欠落、全角文字がないか確認してください。サーバー側のアカウントに代えて、適当なIDを生成しないでください。
エラー：failed to build outbound handler
原因：これはoutboundの構築に失敗したことを示す上位のエラーで、この文だけでは不足しているパラメーターを特定できません。対処：内側の原因メッセージまで読み、対象プロトコルに応じてサーバー一覧、ユーザーパラメーター、トランスポート設定を確認してください。
接続先アドレス、TLSのサーバー名、WebSocketのHostはそれぞれ用途が異なります。ドメイン名のように見えるからといって、相互に置き換えることはできません。VLESSとREALITYを組み合わせる場合は、サーバーと一致する公開鍵、サーバー名、その他の関連パラメーターも確認してください。フィールド名や対応状況は、実際に使用しているコアのバージョンによって異なります。不足しているパラメーターは、別のノードから値を流用せず、設定の提供元に確認してください。
変更後に再起動し、元に戻せる状態で記録を残す
一度に変更するのは1種類の問題だけにし、サービスを停止して再起動した後、新しいログを確認します。構文を直してからフィールドやパラメーターを修正し、最後に待ち受けが成功するか確認してください。ポート、DNS、プロトコル、ルーティングを同時に変更すると、接続が復旧しても、どの修正が有効だったのか分かりにくくなります。
- 通常のサブスクリプションノード：まずサブスクリプショングループのメニューから更新し、インポート結果を確認します。失敗したノードが一つだけなら、そのノードのログを保存し、グループ全体を削除しないでください。
- カスタム設定：変更前と変更後のコピーを保存し、変更したフィールドと日時を記録します。唯一使える設定ファイルを直接上書きしないでください。
- 動作確認済みのノード：同じ端末で比較します。起動できる場合は、すぐにすべての設定をリセットせず、問題のノードを優先して確認してください。
- 起動できない場合：クライアントとコアのバージョン、機密情報を伏せた原因の全ログ、設定の入手元の種類、直近の変更内容を共有してください。「接続できない」という画面のスクリーンショットだけでは、configの誤りを特定できません。
コアが起動しているのにAndroid VPNが確立されない場合は、システムの接続許可と、VPNを使用中のほかのアプリを確認してください。Androidでは、通常、同じユーザー環境で同時に有効にできるVPNは1つです。この問題はシステムのVPN状態を確認し、UUIDを何度も変更したり、証明書の検証を無効にしたりする必要はありません。