v2rayNでサーバーを切り替えた直後にコアの起動失敗が表示される場合や、カスタム設定を読み込むと終了する場合、コア更新後にルールを読み込めない場合に役立つガイドです。ログから「設定を読み込めない」「ローカルで待ち受けできない」「起動後の接続に失敗している」のどれかを見極め、ポート、JSON、フィールドの互換性、geoデータを順に確認します。最後に設定テストと実際のリクエストを別々に検証し、サブスクリプションの取得失敗をコアの不具合と混同しないようにしましょう。
1. コアの起動失敗と接続失敗の違い
v2rayNは管理用の画面で、プロキシ設定を実行するのはXrayまたはV2Flyのコアプロセスです。メイン画面が開き、サーバー一覧が表示されても、コアが正常に動作しているとは限りません。起動失敗は通常、設定の読み込み、インバウンド／アウトバウンドの構築、ローカルポートのバインド時に発生します。一方、ノードのタイムアウト、証明書の不一致、接続先からの拒否は、コアの起動後に起きる場合があります。
まず、どのタイミングで失敗するかを確認します。アクティブサーバーを設定するたびにすぐ設定解析エラーが出るなら、ローカル設定を優先して調べます。起動時に異常はなく、Webページを開いたときだけ接続エラーになるなら、サーバーアドレス、ネットワーク、TLS、トランスポート設定が主な確認対象です。この場合、ローカルの待ち受けポートを何度も変更しても解決しないことがほとんどです。
| ログ・症状 | 発生段階 | 最初に確認すること |
|---|---|---|
failed to load config | 設定の読み込み・構築 | 続きのログでJSON、プロトコルのフィールド、データファイルに関する原因を探す |
failed to listen TCP | ローカルでの待ち受け開始 | 待ち受けアドレス、ポート競合、システムの予約ポート |
connection refused | 接続先への接続 | エラーに記載された接続先がローカルのインバウンドか、リモートサーバーかを確認する |
context deadline exceeded | タイムアウト | 前後の状況から、DNS、接続、ハンドシェイクのどの段階でタイムアウトしたかを判断する |
2. ログ画面で使用中のコアと設定ファイルを確認する
調査で確認すべきなのは、プログラムフォルダーにたまたまあるファイルではなく、「今回の起動で実際に使われたコアと設定」です。v2rayNは通常、アクティブサーバーやルーティング設定に応じて実行用の設定を生成します。生成ファイルを手動で編集しても、ノードを切り替えると変更が上書きされることがあります。恒久的に反映させたい変更は、パラメーター設定、ルーティング設定、または該当するカスタム設定の元で行ってください。
-
状態を記録する
メイン画面下部のログから今回のエラーをコピーし、直前に行った操作が起動、サーバー切り替え、ルーティング変更のどれかを記録します。再現可能な唯一の設定を上書きしないよう、編集前にカスタム設定をバックアップしてください。
-
コアを確認する
「設定」→「パラメーター設定」を開き、「Coreタイプ」に関する項目を確認します。起動ログに表示されるXrayまたはV2Rayのバージョン情報とも照合してください。バージョンによって項目の区分や名称が異なる場合があるため、最終的にはログに記録された実際のプロセスを基準にします。
-
ファイルを特定する
起動情報またはエラーに表示されたパスから、実際に読み込まれている設定ファイルを特定します。画面に完全なパスが表示されない場合は、クライアントのログと実行フォルダーを確認してください。ファイル名だけで判断したり、サブスクリプションの応答を実行用の設定とみなしたりしないでください。
-
一項目ずつ再試行する
一度に変更するのは一項目だけにし、コアを再起動して新しいエラーを保存します。前のエラーが消えて次のエラーが表示されたなら、調査は先に進んでいます。すべての設定を元に戻して最初からやり直す必要はありません。
設定の解析ログが出る前に、実行ファイルがない、プロセスを作成できない、アクセスが拒否されたと表示される場合は、まずコアファイルが揃っているか、プログラムフォルダーに読み書きできるか、セキュリティソフトにブロックされていないかを確認してください。これは設定がコアに渡される前に起きる問題なので、JSONを変更しても解決しません。
3. ポート競合：PIDを調べてからローカルの待ち受けを変更
以下の数値は調査用の例で、すべてのバージョンの既定値ではありません。「設定」→「パラメーター設定」でローカルの待ち受けポートを確認し、コマンド内の数値を実際の値に置き換えてください。バージョンによっては混合ポートを使うため、SOCKSとHTTPの独立したポートが必ず両方あるとは限りません。
エラー：bind: address already in use
原因：その待ち受けアドレスとポートを別のプロセスが使用しています。別のv2rayNで起動したコアが残っている可能性もあります。
対処法：使用中のプロセスを特定し、重複して起動したインスタンスを通常の方法で終了してください。両方のプログラムを使う必要がある場合は、片方に別のローカルポートを割り当てます。
エラー：Only one usage of each socket address
原因：Windowsのポートバインド競合でよく見られるメッセージの一部です。完全なエラーには待ち受けアドレスとポートも記載されます。
対処法：ログに記載された正確なポートでPIDを調べてください。バインドエラーが出たからといって、すべてのコアプロセスを終了しないでください。
Windowsで待ち受けプロセスを確認する
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"ローカルアドレスの列で該当ポートとLISTENING状態が表示された行だけを、待ち受けの根拠にしてください。コマンドの検索結果にはリモートアドレスが含まれる場合もあるため、数字が一致しただけで競合と判断してはいけません。一番右の列がPIDです。タスクマネージャーの「詳細」タブで照合できます。PowerShellでプロセス名を直接確認することもできます。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess,
@{Name='ProcessName';Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}ポイント：ポートを変更したら接続元も更新する
ローカルポートを10808から別の値に変更した場合、プロキシを手動設定しているブラウザー、ターミナル、アプリのポートも合わせて変更してください。v2rayNのシステムプロキシを使っている場合は、「システムプロキシを自動設定」を再適用します。コアが新しいポートで待ち受けを再開しても、アプリがそのポートに接続しているとは限りません。
アクセス権に関するforbidden by its access permissionsが表示され、待ち受けプロセスも見つからない場合は、システムの除外ポート範囲も確認してください。netsh interface ipv4 show excludedportrange protocol=tcpを実行します。使用中でも予約済みでもないポートを選び、システムの予約範囲を直接削除しないでください。
4. JSON構文エラー：句読点と階層を修正する
標準JSONでは、オブジェクトのキーと文字列を半角のダブルクォーテーションで囲みます。末尾の余分なカンマは使えず、日本語の引用符も区切り記号として使えません。読み込み方法によってはコメントなどの拡張に対応する場合もありますが、設定をコピーする際は標準JSONにしておくと、複数のツールで検証しやすくなります。構文チェックに通っても、プロトコルやルーティングのフィールドが有効とは限りません。
エラー：invalid character '}' looking for beginning of object key string
原因：オブジェクトの最後の項目の後にカンマが残っていると、パーサーは次のキーを待っているところで閉じ波括弧を読み込み、このエラーが発生することがあります。
対処法：エラー箇所とその直前の項目を確認し、末尾のカンマを削除して括弧の対応も確認してください。
エラー：unexpected EOF
原因：構造が終わる前に内容が途切れています。コピー漏れ、閉じていない文字列、閉じ括弧の不足などがよくある原因です。
対処法：完全な元ファイルと照らし合わせて欠けている内容を復元してください。ファイルの末尾に手当たり次第に括弧を追加するのは避けましょう。
以下は、入れ子の階層とカンマの位置を示す、構文上正しいログ設定の例です。完全なプロキシ設定ではないため、実行ファイル全体の代わりには使えません。
{
"log": {
"loglevel": "warning"
}
}- 引用符を確認：
"loglevel"は有効なキー名ですが、日本語の曲線引用符は使えません。 - カンマを確認：同じ階層の要素の間にはカンマが必要ですが、最後の要素の後には不要です。
- パスを確認：JSON文字列内のWindowsのバックスラッシュはエスケープが必要です。例：
"C:\\proxy\\error.log"。 - ファイルの内容を確認：冒頭がHTMLタグなら、エラーページを保存している可能性があります。サブスクリプションのエンコード文字列も、実行用のネイティブJSONではありません。
認証情報を含む設定をオンラインの整形ツールにアップロードしないでください。ローカルのエディターで句読点を確認した後、同じコアの設定テストコマンドで意味的な妥当性を検証します。v2rayNが生成するファイルで同じ問題が繰り返される場合は、生成後のファイルを毎回手動修正するのではなく、カスタム設定やテンプレートの元を確認してください。
5. 未知のフィールドとコアの違い：プロトコル、型、階層を確認する
XrayとV2Flyの設定には共通する部分がありますが、一方で追加されたトランスポート、セキュリティ、プロトコルのパラメーターを、もう一方にそのまま適用できるとは限りません。どちらもJSON形式でも、コアのバージョンによって認識されないフィールドがあります。VLESSやVMessはプロトコル名であり、汎用の設定形式ではありません。クライアントで共有リンクを読み込めても、すべてのコアバージョンがその全パラメーターに対応しているとは限りません。
| エラーの手がかり | 考えられる原因 | 対処 |
|---|---|---|
unknown field | 現在のローダーがフィールドを厳密に検証している、またはフィールドの階層が誤っている | 該当コアのバージョンにおけるフィールド定義と入れ子の位置を確認する |
unknown config id | プロトコルまたはトランスポートの種類が未対応、または名前の入力ミス | エラーが示す種類と実際に使っているコアを確認し、異なるコア間で設定をコピーしない |
cannot unmarshal | 文字列、数値、配列、オブジェクトの型が一致していない | エラー全体を手がかりにフィールドを特定し、パーサーを通すためだけに引用符を変えない |
| エラーは出ないが設定が反映されない | 未知のフィールドが無視されているか、編集したファイルが実行時に使われていない | 生成された設定と実際の動作を照合し、テストが正常終了しただけで判断しない |
未知のフィールドがすべて起動失敗につながるわけではありません。動作はコアのバージョンと設定の読み込み方法によって異なります。そのため、unknown fieldが表示されなくても、フィールドが有効になったとは限りません。まずv2rayNに対応した構造化編集機能を使ってください。カスタムJSONが必要な場合は、実際に使うコアのヘルプ、設定の階層、対応バージョンを確認します。
6. geoファイルが見つからない：ファイル、パス、コレクション名を切り分ける
ルーティングでgeosite:cnはドメインのコレクションを、geoip:cnはIPアドレスのコレクションを参照します。一般的なDAT形式で読み込む場合、それぞれgeosite.datとgeoip.datが必要です。コアがデータファイルを見つけられることに加え、参照先のコレクションがファイル内に存在する必要があります。ファイルがあること、読み込めること、コレクションが存在することは、それぞれ別の条件です。
エラー：failed to load geosite
原因：ドメインルールの読み込みに失敗しています。続くエラーには、ファイルがない、内容を解析できない、コレクション名が存在しないなどの詳細が示される場合があります。
対処法：エラー全体を確認し、まず実際のデータフォルダーを特定してから、ファイルと参照先のコレクションを別々に確認してください。ファイル名だけを見て判断しないでください。
エラー：no such file or directory
原因：前後のログでgeoデータのパスが示されている場合、コアがその場所で必要なファイルを見つけられていません。Windowsでは「指定されたファイルが見つかりません」と表示されることもあります。
対処法：エラーに記載された完全なパスにデータファイルを戻すか、リソースフォルダーを修正してください。別の場所に同名ファイルがあるだけでは、修復できた証拠になりません。
- ファイルがない場合：クライアントのデータファイル更新機能から再取得してください。バージョンによってメニューの場所が異なる場合があるため、更新結果と実際のリソースパスを確認します。
- ファイルが破損している場合：コアが読み込みまたは解析に失敗すると報告した場合は、データファイルを完全な状態で再取得してください。ダウンロードしたエラーページを
.datにリネームしないでください。 - コレクションが存在しない場合：
geosite:またはgeoip:の後に指定した名前を確認してください。データの提供元が異なると、同じコレクションが含まれているとは限りません。 - 外部データを参照している場合：
ext:ファイル名:コレクション名を使うときは、カスタムファイル名、リソースフォルダー、コレクション名をすべて確認してください。既定のファイルだけを更新しても解決しません。
一時的な切り分けとして、自分で追加したルールのうちエラーを引き起こしているgeoルールを無効にし、設定を再生成して起動できます。これで確認できるのは、原因がそのルールまたはデータ依存関係にあることだけで、恒久的な修復ではありません。振り分けルールを削除すると接続経路が変わることがあります。ルールを戻した後、直結、プロキシ、ブロックの対象が意図どおりになっているか再確認してください。
7. 設定テストと実際のリクエストを分けて検証する
設定テストでは、v2rayNが実際に呼び出すコアのバージョンを使い、同じデータリソース環境で実行してください。そうしないと、作業ディレクトリの違いでgeoファイルが見つからなかったり、別のコアを使ったことで結果が異なったりする場合があります。以下はWindowsでの例で、現在のディレクトリにコアの実行ファイルと確認対象のconfig.jsonがある想定です。別の場所にある場合は実際のパスを指定してください。
.\xray.exe version
.\xray.exe run -test -config .\config.jsonV2Flyのコマンドラインはメジャーバージョンによって異なります。サブコマンド形式を採用しているV2Flyのバージョンでは、以下の書式を使えます。コマンドが不明と表示された場合は、他バージョンの起動オプションをそのまま使わず、現在の実行ファイルのヘルプを確認してください。
.\v2ray.exe version
.\v2ray.exe help
.\v2ray.exe test -c .\config.json設定テストで通常確認できるのは、読み込みと構築の処理までです。実行時の待ち受けを実際に開始するわけではなく、リモートサーバーへの接続も行いません。そのため、テストに成功してもポート競合、接続先への到達不能、ハンドシェイク失敗は否定できません。修正後はv2rayNからコアを通常起動し、次の順に確認してください。
- 起動を確認：同じ起動時のログに、設定解析、データ読み込み、待ち受けの失敗が出ていないことを確認します。
- 待ち受けを確認：ポート確認コマンドを使い、想定したポートで待ち受けていることと、プロセスが今回起動したコアであることを確認します。
- 接続元を確認：システムプロキシまたはアプリに手動設定したプロキシのアドレスを確認します。システムプロキシが有効かどうかと、コアが起動できるかどうかは別の問題です。
- リクエストを確認：実際にアクセスし、ログから接続がコアに届いているか、どの接続先のどの段階で失敗したかを確認します。
- ルーティングを確認：ルーティングを変更した場合は、直結とプロキシの対象をそれぞれ確認します。一時的に無効にしたルールを戻してから再テストしてください。
8. よくある質問：再インストール、管理者権限、ログレベル
再インストールしても起動しません。もう一度やり直すべきですか？
同じユーザー設定やカスタムルーティングを引き継いでいないか、まず確認してください。プログラムファイルを更新しても、設定エラーが削除されるとは限りません。バックアップを取ったうえで、動作が確認済みのサーバー設定とシンプルなルーティングを使って検証し、カスタム設定を一項目ずつ戻します。問題のある設定全体を一度に復元しないようにしてください。
管理者として実行しないと修復できませんか？
通常、ローカルの高い番号のポートで待ち受けるのに管理者権限は必要ありません。まずポート競合、フォルダーへのアクセス拒否、追加の権限が必要なネットワーク機能を切り分けてください。権限を昇格しても、JSONの句読点、誤ったフィールド、存在しないコレクションは修正されません。プロセスやパスの確認に代わるものでもありません。
ログが少なすぎます。debugにすれば原因がわかりますか？
「設定」→「パラメーター設定」でログレベルを探し、一時的にdebugへ変更して再起動し、問題を再現してください。ログ機能の初期化前に設定の読み込みで失敗する場合は、起動時の出力も確認する必要があります。調査が終わったら通常のログレベルに戻し、共有前に接続情報などの機密情報を削除してください。
別のノードに切り替えたら正常になりました。元のノードは使えなくなったのでしょうか？
必ずしもそうとは限りません。ノードごとにプロトコル、トランスポート、セキュリティ設定が異なり、一方だけが現在のコアで未対応の設定を使っている可能性があります。まず切り替え時の起動ログを比較してください。元のノードでもコアは正常に起動し、リクエストだけが失敗する場合は、サーバーアドレス、ポート、ハンドシェイクの条件を確認します。
問題を再現できるよう、個人情報を伏せたログ、該当するコアのバージョン、問題を起こした操作、修正内容を保存しておきましょう。次に似た問題が起きたときは、設定をすべてリセットするより、まずエラーの発生段階を確認してから最も根本的な原因を調べるほうが、有効な設定を保ちやすくなります。システムプロキシと接続動作を詳しく確認する場合は、トラブルシューティングガイドもご覧ください。