v2rayNでコアの終了が表示される、v2rayNGやv2flyNGでサービスを起動できない、またはコアを手動実行すると設定エラーが出る場合に役立ちます。まず実際に読み込まれたファイルとコアを確認し、ログをたどって解析、フィールド、リソース、待ち受けの各段階を調べましょう。ローカルでの確認コマンド、よくあるエラー例、修正後の確認方法を紹介します。ポート番号と設定例はトラブルシューティング用であり、接続先ノードのパラメーターではありません。
1. 起動エラーと接続エラー：まず発生段階を確認
クライアントのウィンドウが開いても、コアが動作しているとは限りません。v2rayNは管理用の画面で、受信、ルーティング、送信を実際に処理するのは起動されたコアのプロセスです。起動時には通常、設定を読み込み、プロトコルやルーティングのオブジェクトを構築してから、ローカルで待ち受けを開始します。いずれかの段階で失敗すると、その後のプロキシ要求を処理できません。
起動直後にログへ Failed to start と表示された場合は、後続の行を確認して、より具体的な原因を探します。待ち受け開始の記録があるのに、接続先へのアクセス時だけタイムアウト、認証エラー、TLSハンドシェイクエラーが発生するなら、問題は通常、接続段階にあります。この場合、JSONのカンマを繰り返し変更しても解決しません。画面に「接続失敗」と表示されただけで、コアが起動していないと判断するのも避けてください。
- 解析段階：
invalid characterやunexpected EOFなどのメッセージに注目し、まずファイルの内容を確認します。 - 構築段階：プロトコル名、トランスポート設定、ルーティングタグ、リソースファイルのパスを確認します。
- 待ち受け段階：
bind、address already in use、権限に関するメッセージを確認します。 - 接続段階：コアの起動後に、サーバーアドレス、DNS、システム時刻、サーバー側の設定を確認します。
2. ログ全体と実際に読み込まれた設定を確認
最後の「プロセス終了」だけを切り取らないでください。原因は同じエラーの連鎖の末尾にあり、>などの区切り文字でつながっていることがあります。終了メッセージより前に現れる場合もあります。コアのバージョン、起動コマンドから終了理由まで、今回の起動ログを続けて保存し、前回の接続エラーと今回の起動エラーを混同しないようにしましょう。
-
状況を保存する
ログ画面から今回の起動記録をコピーし、現在のカスタム設定をバックアップします。ログを共有する前に、サブスクリプションURL、ユーザーID、パスワード、秘密鍵、サーバーアドレスなどの機密情報を削除してください。ローカルの元ファイルは変更せずに保管します。
-
コアを確認する
起動ログから実行ファイル名、バージョン、設定ファイルのパスを確認します。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。v2rayNについてはクライアント名だけで推測せず、実際の起動記録を確認してください。
-
設定を確認する
デスクトップ版v2rayNでは、「設定」→「パラメーター設定」からローカル待ち受けに関する設定を確認できます。バージョンによってサブ画面の名称が異なる場合があるため、実際の画面に従ってください。画面に表示されるポートと、生成された設定の
inboundsを照合します。 -
単独でテストする
まずクライアントのプロキシサービスを停止し、複数プロセスによる干渉を防ぎます。ログに記録された設定ファイルを、対応するコアの設定テストコマンドで検証してください。別のディレクトリにある、たまたま同名の
config.jsonで代用しないでください。
以下は現在よく使われるコマンド形式です。コアのあるディレクトリで実行してください。1つ目はWindows版Xray用、2つ目はtestサブコマンドを備えたV2Fly用です。旧バージョンでは引数が異なる場合があるため、対象の実行ファイルでhelpまたは-hを実行して確認してください。ファイル名に空白が含まれる場合は、必ず引用符で囲みます。
.\xray.exe run -test -config ".\config.json"
./v2ray test -c ./config.json3. JSON構文エラー：文字の位置を特定してからフィールドを確認
構文解析はプロトコルの検証より先に行われます。この段階でエラーがあれば、ノードのアドレスやポートが正しくてもコアは設定を読み込めません。エラー文字の近くにある引用符、カンマ、中括弧、角括弧を優先的に確認してください。エラー位置は解析が停止した場所であり、実際に不足しているカンマが前の行にあることもあります。
エラー：invalid character '}' looking for beginning of object key string
原因：オブジェクトの末尾に余分なカンマが残っている可能性があります。解析器は次のキー名を待っています。対処：閉じ中括弧の直前の行を確認し、末尾のカンマを削除してから再テストします。
エラー：unexpected EOF
原因：ファイルが途中で終わっています。コピー漏れや閉じ括弧の不足がよくある原因です。対処：ファイル末尾を確認し、エディターの括弧対応機能で閉じられていないオブジェクトや配列を探します。
エラー：invalid character 'h' looking for beginning of value
原因：読み込まれた内容が、引用符で囲まれていないテキストから始まっている可能性があります。たとえば、サブスクリプションURLを誤ってJSONとして読み込んでいるケースです。対処：ファイルの先頭行を確認し、コア設定であることを確かめます。サブスクリプションURL、ダウンロードエラーのページ、共有リンクではないことを確認してください。
以下は厳密なJSON形式の受信設定例です。文字列、数値、括弧の構造を示すものであり、完全な設定ではありません。また、元ファイルの代わりに単独で使うこともできません。JSONでは半角の二重引用符を使用します。キー名に日本語の引用符は使えません。文字列内のWindowsパスでは、バックスラッシュをエスケープする必要があります。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
]
}- 厳密なJSONでは末尾のカンマを使用できません。解析器による違いを避けるため、トラブルシューティングではまずコメントなしの標準的なJSONを使ってください。
"port": 10808は数値で指定します。すべての数値を文字列に変える必要はありません。- パスは
"C:\\proxy\\access.log"のように記述できます。ディレクトリが実在し、プロセスに書き込み権限があることが前提です。 - 機密情報を含む設定はローカルのエディターで確認し、オンラインの整形サービスにアップロードしないでください。
4. ポート競合：何度も再起動せず、使用中のプロセスを確認
設定テストに成功しても、実行時にポートをバインドできるとは限りません。古いコアのプロセスが終了していない、クライアントを2つ同時に起動している、HTTPとSOCKSの受信設定で同じ待ち受けアドレスとTCPポートを使っている、といった状況で競合が起きます。WindowsではOnly one usage of each socket address、ほかのシステムではaddress already in useというエラーがよく見られます。
これらの数値は説明用であり、すべてのバージョンの既定値ではありません。まず「設定」→「パラメーター設定」で実際のポートを確認してから、次のコマンドを実行してください。Windows PowerShellでは、以下の2つのポート例を待ち受けているプロセスを確認できます。検索結果がない場合でも、その時点で該当するTCP待ち受けが見つからなかったことを示すだけで、権限やアドレス設定の問題がないとは限りません。
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 |
Select-Object LocalAddress,LocalPort,OwningProcess
# 前の手順で確認したプロセスIDを -Id に入力します。4560は例です
Get-Process -Id 4560Linuxでは次のコマンドで待ち受けアドレス、ポート、プロセスを確認できます。他のユーザーのプロセス情報を表示するには、追加の権限が必要な場合があります。0.0.0.0または::で待ち受けているプロセスにも注意してください。ローカルアドレスで新たに待ち受ける際に競合する可能性があります。
ss -ltnp 'sport = :10808 or sport = :10809'- 古いコアのプロセスの場合：対応するクライアントから通常の手順でサービスを停止し、プロセスの終了を確認してから起動します。
- ほかのアプリのプロセスの場合：用途の分からないプロセスを安易に終了しないでください。プロキシに空いているポートを割り当て、システムプロキシやアプリのプロキシ設定も合わせて変更します。
- ポートを変更しても
permission deniedが出る場合は、システムポリシーとポートの予約状況を確認してください。ファイアウォールを無効にする方法を万能な解決策と考えないでください。 - コアが待ち受けを開始できていない場合、ブラウザーのプロキシやDNS、リモートノードを変更しても、ローカルのバインドエラーは通常解決しません。
5. 未対応のプロトコルやフィールド：コアの対応状況を確認
JSON構文が正しいことは、ファイルを解析できることを示すだけで、フィールドの組み合わせが有効であることまでは保証しません。XrayとV2Flyには共通のルーツがありますが、プロトコル、トランスポート、セキュリティ設定を名前だけで互換と判断することはできません。特にREALITYやXray固有のフロー制御パラメーターを含む設定では、その機能に明確に対応したコアとバージョンを使用してください。
| ログまたは設定の手がかり | 優先して確認する項目 | 対処方法 |
|---|---|---|
unknown config id | protocolに対応する実装があるか | 綴り、大文字・小文字、コアの対応状況を確認します。プロトコル名だけを変更しないでください。 |
unknown field | フィールドの階層と解析器の要件 | 実行中のバージョンが想定するフィールド構造と照合し、クライアント設定用の項目ではないことを確認します。 |
streamSettings.securityがreality | 実際に起動しているプロセスが、その機能に対応するXrayか | 対応するコアを選び、トランスポートとセキュリティのパラメーター一式を確認します。 |
ルーティングがoutboundTagを参照している | 名前が送信設定のtagと一致しているか | タグを修正します。不一致があっても、要求のルーティング時まで表面化しない場合があります。 |
未知のフィールドがすべてエラーになるとは限りません。解析方法によっては、認識できないキーが無視されます。そのため、「unknown field」という表示がないからといって、設定が反映されたとは限りません。サブスクリプショングループや自動更新間隔などのクライアント設定も、コアのJSONにむやみに追加せず、クライアント側の該当設定で管理してください。
6. geoファイルが見つからない：リソース名、パス、権限を確認
ルーティングのgeoip:とgeosite:ルールでは、対応する地理データリソースが必要になることがあります。ログにfailed to load GeoIPまたはfailed to load geositeが表示されたら、エラーの連鎖をさらに確認してください。ファイルが見つからない、読み込めない、分類タグが見つからない、という3つの問題はそれぞれ原因が異なります。
エラー：no such file or directory
原因：エラーの連鎖に記録されたgeoファイルのパスから、実際のリソースディレクトリでデータファイルを見つけられていない可能性があります。対処：ログに示されたディレクトリを確認し、クライアントのリソース更新機能を使うか、プログラムのディレクトリ一式を復元してください。
エラー：permission denied
原因：プロセスにリソースファイル、またはその親ディレクトリの読み取り権限がない可能性があります。対処：実行ユーザーとディレクトリの権限を確認してください。ログファイルがエラーの対象なら、ログディレクトリへの書き込み権限を確認します。
- ファイル名を確認：一般的なファイル名は
geoip.datとgeosite.datです。拡張子が非表示になっていないか確認し、二重に付けていないことを確かめます。 - リソースディレクトリを確認：リソースの検索場所はクライアントの起動方法、コア、環境設定によって異なります。常にターミナルのカレントディレクトリと同じとは限りません。
- 分類を確認：ファイルが存在してもルールで指定した分類が存在しない場合は、対応するデータセットを更新するか、ルールの分類名を修正します。同じファイルを繰り返しコピーするだけでは解決しません。
- 更新結果を確認：更新に失敗すると、空のファイルや不正な内容が残ることがあります。クライアントから適合するリソースを再取得してからテストしてください。ファイル名を変えるだけで対処しないでください。
原因を絞り込むには、バックアップしたコピーからgeoデータを使うルーティングルールを一時的に削除し、設定テストを実行します。コピーでテストに成功しても、問題の範囲をリソースまたはルールに絞れたというだけです。実運用に戻す前に元のルールを修正してください。修正しないと、トラフィックの振り分けが変わります。
7. 修正後の再テスト：設定の合格とプロキシの動作を切り分ける
1回の変更で変える項目は1つにし、変更前後のエラー行を記録します。設定テストに成功したら、コアを起動して待ち受けを確認します。最後に、アプリの要求が該当する受信設定に届いているか、ルーティングで想定した送信先が選ばれているかを確認してください。ウェブページを一度開けても、すべてのルーティングルールが正しいことの証明にはなりません。
設定テストは成功したのに、クライアントが起動しないのはなぜですか？
まず、テストとクライアントが同じ設定ファイルと同じコアを使っているか確認します。次に、実行時のポートのバインド、ログへの書き込み、実行権限を確認してください。設定テストのコマンドでは、通常、ポートが利用可能かどうかやリモートサーバーへの接続性までは確認できません。
config.jsonを修正したのに、再起動すると元に戻るのはなぜですか？
そのファイルはクライアントが一時的に生成したものかもしれません。ノード編集、ルーティング設定、またはカスタム設定の元データを変更してから再生成してください。手動で見つけた同名ファイルより、起動ログに記録された実際のファイルパスを優先します。
常に管理者として実行する必要がありますか？
すべての起動エラーに対する決まった対処として、管理者実行を使うべきではありません。権限エラーがどのファイル、ポート、ネットワークデバイスを指しているかを確認してください。通常のローカル高位ポートを使うプロキシなら、まずディレクトリと待ち受け設定を修正します。TUNなどシステム機能を使う場合は、クライアントの案内に従って権限を付与してください。
コアは起動しているのにウェブページを開けない場合は？
まず、アプリで正しいプロキシの種類とポートを指定しているか確認します。要求が受信設定に届いているなら、送信接続のログ、ノードのパラメーター、システム時刻を確認してください。この段階では接続エラーとして調査し、すべての問題をJSON構文に結び付けないようにします。
問題を報告する際は、クライアント名、実際のコアのバージョン、OS、機密情報を削除した起動エラー全体の連鎖、再現に必要な最小限の設定例を添えてください。基本操作はクイックスタートを、受信・送信・ルーティングのフィールドは設定ガイドを参照してください。