v2rayNは起動するものの、Xrayが起動後に終了する場合に役立つ内容です。まず起動ログ全体を保存し、設定の解析・パラメーターの構築・ポートの待ち受けという段階に分けて原因を切り分けます。設定テストとローカルポートの確認方法に加え、生成されたconfig.jsonを編集しても変更が消える理由や、修正内容をノードまたはカスタム設定に反映する方法も解説します。
1. 終了しているのがXrayコアか確認する
v2rayNはクライアントの画面、Xrayはプロキシ設定を実行するコアです。メイン画面を操作できても、コアが正常に動作しているとは限りません。一方、ブラウザーでページを開けないだけでは、コアの起動失敗とは判断できません。この記事の手順が必要なのは、ノードの切り替え後に起動エラーが表示される、コアのプロセスがすぐ終了する、またはログが設定読み込み中のまま進まない場合です。
まずメイン画面下部のログパネルを開き、現在のサーバーを選び直して、操作前後のログ全体を保存してください。Failed to start、failed to load config files、failed to listenを含むエラーの連なりを探します。同じエラー内で複数の原因が>でつながっている場合、右端に根本原因が示されていることが多いため、「プロセスが終了しました」という最後の一文だけで判断しないでください。
-
状況を記録する
v2rayNのバージョン、ログに表示されたXrayのバージョン、現在のノードのプロトコル、エラー発生時刻を記録します。ログを共有する前に、サブスクリプションURL、UUID、パスワード、サーバーアドレスなどの機密情報を隠してください。
-
コアを確認する
「設定」→「パラメーター設定」を開き、現在のプロトコルで使うコア設定を確認します。コアのバージョンは起動ログに表示された情報を基準にしてください。バージョンによって設定項目のグループ名が異なる場合があります。別のコアのエラーを、この記事のコマンドに当てはめないようにしましょう。
-
設定を保存する
ログに記載された設定ファイルのパスをたどり、実際に読み込まれているファイルを特定して、調査用のコピーを作成します。ファイル名は
config.jsonの場合も、別の接頭辞が付く場合もあります。ファイル名から推測せず、起動時の引数を確認してください。 -
一度だけ再現する
ノードを続けて切り替えるのはやめ、起動を一度だけ再現します。そのときのログとバックアップした設定ファイルを対応づけ、前のノードのエラーを現在のノードの問題と取り違えないようにしてください。
2. 設定テストで解析エラーと実行時エラーを切り分ける
まず、v2rayNが実際に使用しているXrayプログラムで、バックアップした設定をテストします。同じ設定でも、コアのバージョンによって対応状況が異なる場合があります。古い別バージョンでテストすると、誤った判断につながることがあります。以下はWindows PowerShellでの実行例です。ターミナルをコアのあるフォルダーに移動し、テスト用の設定コピーをconfig.jsonという名前で保存してから実行してください。
.\xray.exe version
.\xray.exe run -test -config ".\config.json"-testは設定の読み込み、構築、テストを行うオプションで、プロキシサービス全体は起動しません。JSONの解析エラー、一部の必須パラメーターの不足、無効なプロトコル設定は検出できますが、実際の起動の代わりにはならず、リモートアカウントの有効性も確認できません。テストに合格しても、待ち受けポートを必ず使用できるとは限りません。ポート競合は起動時に別途確認してください。
| ログの位置・結果 | まず確認する項目 | 次の手順 |
|---|---|---|
| 設定ファイルの読み込みに失敗 | 起動引数、ファイルパス、読み取り権限 | ログに記載された実際の設定ファイルをテストしているか確認する |
| 解析時にinvalid characterが表示される | 引用符、カンマ、括弧、文字列のエスケープ | まず構文を修正し、設定テストをもう一度実行する |
| outboundの構築に失敗 | protocol、settings、ユーザーパラメーター | エラーの連なりをたどり、該当するoutboundを確認する |
| テストは成功したが、起動時の待ち受けに失敗 | 待ち受けアドレス、ポート競合、システムの制限 | ローカルポートとバインドアドレスを確認する |
| 起動後、アクセス時にのみエラーが発生 | リモート接続、TLS、DNS | 接続のトラブルシューティングに進み、JSONの句読点を何度も変更しない |
3. JSON構文エラー：まず記号を直し、次にフィールドを確認
カスタム設定を手動編集する際によくあるのは、末尾のカンマ、カンマの抜け、全角の引用符、エスケープされていないバックスラッシュです。読み込み方法によってはコメントを許可するものもありますが、パーサーの違いを排除するため、再現テストには厳密なJSONを使いましょう。ウェブページの説明文、コードブロックの囲み、行番号をファイルに一緒に貼り付けないでください。
エラー：invalid character '}' looking for beginning of object key string
原因と対処：オブジェクトの最後のプロパティの後ろに、余分なカンマがあるケースがよくあります。右波括弧の直前の行を確認し、不要な末尾のカンマを削除してから設定をテストしてください。
エラー：invalid character '"' after object key:value pair
原因と対処：プロパティ間のカンマが抜けている可能性があります。エラー箇所の直前にある項目の末尾を確認し、指摘された引用符だけを変更しないでください。
エラー：unexpected EOF
原因と対処：ファイルが途中で切れているか、オブジェクト、配列、文字列が閉じられていない可能性があります。まずバックアップファイルの末尾と比較し、括弧が対になっているか確認してください。
上記はよくある解析エラーの一部で、先頭に付く文言はバージョンやローダーによって異なります。JSONパーサーが示すのは「読み込みを続けられない位置」であり、実際の間違いは前の行にある場合もあります。次の完全なJSON例には末尾のカンマがありません。引用符や区切り記号の確認に使えますが、ログ設定の一部であり、プロキシ設定全体ではありません。
{
"log": {
"loglevel": "warning"
}
}- フィールド名と文字列値には、
"loglevel"のように半角の二重引用符を使います。全角の曲がった引用符は使わないでください。 - 真偽値は
trueまたはfalseと記述します。構文を直すために、すべての値を文字列に変更しないでください。 - WindowsのパスをJSON文字列に記述する場合は、
"C:\\Temp\\xray-error.log"のようにエスケープが必要です。また、指定したフォルダーが存在し、書き込み可能であることを確認してください。 - 設定の確認にはローカルのエディターを使い、ノードの認証情報を含むファイル全体をオンラインの整形ツールに送信しないでください。
4. ポート競合：10808を使用しているプロセスを確認
エラーの連なりにlisten tcpが含まれている場合、サブスクリプションを再インポートする前にローカルの待ち受け状態を確認してください。以下は調査用の例で、ローカルSOCKSポートは10808、HTTPポートは10809、バインドアドレスは127.0.0.1です。すべてのバージョンでの既定値ではありません。1つのポートだけで待ち受ける混合インバウンド設定もあるため、実際に生成された設定を確認してください。
エラー：bind: address already in use
原因と対処：Linuxでよく見られるエラーで、指定したアドレスとポートをすでに別のプロセスが使用しています。まずプロセスを特定し、重複して起動したクライアントを終了するか、インバウンドのポートを変更してください。
エラー：Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：Windowsでよく見られるポートのバインド競合です。コアのプロセスが別に残っていないか確認し、設定内の複数のインバウンドが同じアドレスとポートを使っていないか調べてください。
PowerShellで待ち受け中のプロセスを調べます。1つ目のコマンドはTCPの待ち受け状態を確認し、2つ目はプロセスの情報を表示します。PIDには自分の環境で調べた結果を使い、他の人の番号をそのまま入力しないでください。
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
ForEach-Object { Get-Process -Id $_.OwningProcess }クライアントが2つ起動している場合は、不要な方を通常の手順で終了してください。正体の分からないシステムプロセスを強制終了してはいけません。ポートを変更する場合は、「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを探します。たとえば10808を未使用の10818に変更し、保存してからコアを再読み込みしてください。プロキシポートを手動指定しているアプリでも、同じように変更が必要です。クライアント管理のシステムプロキシは、あらためて設定してください。
まとめ：テストに合格して待ち受けに失敗する場合は、まずローカル環境を確認
ポートの調査は、実際のエラーが待ち受けに関係している場合に行います。TCPの待ち受けプロセスが見つからないのにアクセス拒否が表示される場合は、バインド先がこのPCのアドレスか、ポート予約やセキュリティポリシーに問題がないかも確認してください。バインドエラーをすべてノードの問題と決めつけないようにしましょう。
5. フィールド名とプロトコルパラメーター：構文が正しくても設定が有効とは限らない
JSONを読み込めるのは、テキスト構造に大きな問題がないという意味にすぎません。Xrayはprotocolに応じてインバウンドとアウトバウンドを構築し、各プロトコルに必要なフィールドを検証します。たとえばvlessをvlesと記述しても、文字列としては有効ですが、対応するプロトコル設定はありません。また、未知のフィールドが無視されることもあるため、エラーが出ないからといってフィールドが反映されているとは限りません。
エラー：unknown config id: vles
原因と対処：プロトコル識別子のスペルミスです。該当するアウトバウンドのprotocolを、ノードで指定されているプロトコルと照合してください。このエラーを回避するために、別のパラメーターを変更しないでください。
エラー：invalid UUID
原因と対処：無効なユーザーIDが原因の可能性があります。上位のエラーには、関連するプロトコルが示されていることが多いです。元のノード情報からIDをコピーし直し、空白や全角記号が混ざっていないか、パスワードをUUID欄に入力していないか確認してください。
| 確認対象 | 具体的な確認項目 | よくある誤った修正 |
|---|---|---|
| VMess / VLESS | プロトコル、サーバーポート、ユーザーIDが元のノード情報と一致しているか | protocolだけを変更し、別プロトコル用のsettings一式を残す |
| VLESSのユーザーパラメーター | encryptionを確認する。一般的な設定はnoneで、flowにはノードに指定された値を入力する | VMessのユーザー暗号化フィールドをそのまま流用する |
| トランスポート設定 | streamSettingsのトランスポート種別と対応する設定の組み合わせ | トランスポート種別を変更したのに、無関係なパスやサービス名を残す |
| TLS / REALITY | securityとserverName、および対応するセキュリティレイヤーのパラメーター | 異なるセキュリティレイヤーのフィールドを混在させる、または検証を無効にして問題を回避する |
| ルーティング先 | outboundTagが想定するアウトバウンドのtagと一致しているか | 任意の文字列を指定すれば、プロキシの出口が自動的に作成されると思い込む |
ノードアドレス、ポート、UUID、TLSのドメイン名に誤りがあっても、コアの起動は妨げられず、最初の接続時に初めて問題が表面化することがあります。「起動成功」と表示させるためだけに別のプロトコルへ変更しないでください。元の設定エラーが、後の接続エラーに変わるだけです。フィールドの階層やルーティングの関係は、設定リファレンスを参照して一つずつ確認してください。
6. 最小構成で問題を切り分け、設定を一つずつ戻す
設定が長く、複数のインバウンドやルーティンググループを含む場合は、コピー上で最小構成を使い、読み込みと構築の流れを確認できます。次の例はローカルSOCKSインバウンドとdirectアウトバウンドのみで、リモートノードは含まず、プロキシ出口の検証には使えません。minimal.jsonとして別名で保存し、元のサブスクリプションやノード設定を上書きしないでください。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10818,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": false
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}.\xray.exe run -test -config ".\minimal.json"このファイルがテストに合格し、元の設定が失敗する場合は、元の設定を少しずつ戻します。まず実際のプロキシアウトバウンドを追加し、次にトランスポートとセキュリティレイヤー、最後にDNSとルーティングを戻してください。追加するたびにテストを実行し、最初に失敗した変更箇所を重点的に確認します。この最小構成を実際に起動する場合は、10818が空いていることを先に確認してください。すべての通信がdirectで送信されるため、元のノードが使えるかどうかの判断には使えません。
- 変更するのは一度に1項目：ノードの変更、ポートの変更、コアの切り替えを同時に行うと、何が原因で復旧したのか判断できません。
- 変更前後の差分を記録：フィールド名と変更理由を記録し、調査メモに認証情報全体を残さないでください。
- 元の保護設定に戻す：ログレベルを一時的に変更した場合は、すぐに元へ戻してください。アクセスログには接続先ドメインなどが記録されることがあります。
- 最後に動作を確認：コアが安定して動作したら、システムプロキシ、ブラウザーでのアクセス、想定する出口を順に確認してください。
7. 設定エラーのトラブルシューティング：よくある質問
config.jsonを直しても、ノードを切り替えると元に戻るのはなぜ？
まず、そのファイルがv2rayNによって自動生成された実行用設定かどうか確認してください。自動生成ファイルなら、サーバー一覧で該当ノードを編集するか、カスタム設定のソースを修正してから再読み込みします。生成ファイルだけを変更しても、次回まで保持されるとは限りません。
設定テストに合格したのに、起動に失敗するのはなぜ？
起動ログにある待ち受けエラーを確認し、実際のインバウンドポートを調べてください。テストではリモートへの接続状況は検証されず、実行時にポートを使えることも保証されません。テスト合格を、ネットワーク接続全体の確認と混同しないでください。
ログに終了の表示しかなく、具体的なエラーが見つからない場合は？
クライアントに表示された起動コマンドと設定ファイルのパスを記録し、同じXrayプログラムでターミナルから設定テストを実行してください。それでも出力がない場合は、logに記載されたerrorファイルのパスと読み取り権限を確認し、エラーが別のログファイルに出力されていないか調べます。
クライアントを再インストールすれば解決しますか？
まずノードとサブスクリプションの設定をバックアップし、どの段階で失敗しているかを確認してください。ポートを別のプロセスが使用している、サブスクリプションのパラメーターに誤りがある、インバウンドが重複しているといった問題は、通常、再インストールでは解決しません。プログラムファイルの破損やバージョンの非互換性が確認できた場合に限り、適合するバージョンへの変更を検討してください。
調査完了の基準は、エラー画面が消えることではなく、根本原因を説明し、再現して確認できることです。元の設定が失敗した理由、どの変更でテストに合格したか、クライアントの再起動後も正常かを確認してください。実際のネットワーク接続も確認する場合は、使い方ガイドに沿ってノードの選択とプロキシ接続を検証してください。設定の構築、ポートの待ち受け成功、リモートへの接続成功を混同しないようにしましょう。