まずカーネルプロセスが本当に終了したかを確認し、今回の起動ログから最初の具体的なエラーを探します。v2rayNの設定読み込み・起動時のトラブルを対象に、JSONの解析、項目の意味、ルーティングとリソースの読み込み、ポートの待ち受けの順で確認します。有効なログを残しながら一つずつ修正し、起動失敗と起動後の接続失敗を切り分けましょう。
まず切り分ける：カーネルの終了か、接続の失敗か
ウェブページが開かないからといって、V2Rayの起動に失敗したとは限りません。v2rayNはノード、サブスクリプション、プロキシ設定を管理するクライアントです。接続を処理するのは選択中のカーネルで、Xrayの場合もV2Flyの場合もあります。メイン画面が開いていても、クライアントが動作しているだけで、カーネルの起動完了を示すものではありません。
起動時のトラブルは通常、設定の読み込み、インバウンド／アウトバウンドの構築、ルール用リソースの読み込み、またはローカルポートのバインド中に発生します。カーネルがすでにローカルポートを待ち受けていて、その後にノード接続のタイムアウトやTLSハンドシェイクの失敗が起きる場合は、ネットワークやノード設定を確認してください。ローカルのJSON構文エラーを、サブスクリプションの更新を繰り返して解決しようとしないでください。
| ログや症状 | まず確認すること | 次の手順 |
|---|---|---|
| 設定の解析エラー後、プロセスがすぐ終了する | 設定の読み込みに失敗 | エラーが示すファイルと項目を確認する |
| ローカルの10808番ポートをバインドできない | 待ち受けの開始に失敗 | ポートを使用しているプロセスを調べる |
| 起動メッセージが表示され、設定上のポートが実際に待ち受け状態になっている | カーネルは起動済みの可能性が高い | システムプロキシ、ルーティング、外部への接続を確認する |
| ウェブページにアクセスしたときだけタイムアウトする | 実行中の接続トラブル | ノードのアドレス、ポート、通信方式の設定を確認する |
表の10808はトラブルシューティング用の例です。実際のポートは「設定」→「パラメーター設定」のローカル待ち受け設定と、生成された設定ファイルで確認してください。このポートが使われていても、別のクライアントが待ち受けている可能性があります。プロセスもあわせて確認しましょう。
起動時のログを一式保存する
設定を変更する前に、まず証拠となるログを残します。ログの末尾は「起動失敗」という概要だけの場合が多く、原因はその前のカーネル出力に記録されています。エラーの流れを確認し、最も具体的な解析エラー、ファイル読み込みエラー、またはシステムエラーを探してください。単独のエラーメッセージより、同じ起動時の前後のログが役立ちます。
-
実行環境を記録する
v2rayNのバージョン、OS、選択中のカーネル、カーネル起動ログに表示されたバージョンを記録します。クライアントとカーネルのバージョンは別々に記録し、一方で他方を代用しないでください。
-
設定を確認する
「設定」→「パラメーター設定」を開き、ローカル待ち受けポートを記録します。現在のバージョンに「Coreタイプ」の設定がある場合は、その選択内容も記録してください。画面上の項目の配置はバージョンによって異なるため、今回のログに記載された実際の実行ファイルを基準にします。
-
一度だけ再現する
メイン画面でログまたは情報出力欄を開いて現在時刻を記録し、対象ノードに対して「アクティブサーバーに設定」を一度実行します。ログが今回の起動に対応していることを確認し、以前の速度テストで出力された一時的なカーネルログを混ぜないようにしてください。
-
エラーの流れを保存する
カーネルのバージョン行から終了メッセージまでを保存します。設定ファイルのパス、エラーが示す項目、システムエラーの原文を残してください。他者に共有する前に、サブスクリプションのトークン、ノードの認証情報、個人名を含むディレクトリ名を伏せましょう。
-
一つずつ修正する
設定は一度に一種類だけ変更し、再起動して確認します。エラーが解析失敗からポート競合に変わった場合は、次の調査段階に進んだということです。この二つのログを同じ原因として扱わないでください。
JSON構文：カンマ、引用符、値の型を確認する
JSONの解析エラーは、設定項目が使われる前に発生します。厳密なJSONでは、オブジェクトのキーと文字列を半角の二重引用符で囲み、最後の要素の後に余分なカンマを付けてはいけません。カーネルによってはコメントなどの拡張構文を読み込めますが、すべてのツールで同じ書き方が使えるとは限りません。
エラー：invalid character '}' looking for beginning of object key string
原因：オブジェクトの最後の要素の後にカンマが残っていると、パーサーは次のキーを期待してエラーになります。
対処法：エラー位置の直前の行を確認し、閉じ中括弧の前にある余分なカンマを削除して、使用中のカーネルで設定をテストします。
エラー：unexpected EOF
原因：ファイル末尾まで読み込んでも内容が完結していません。括弧が閉じていないか、ファイルが途中で切れている可能性があります。
対処法：末尾の中括弧、角括弧、二重引用符を確認し、ファイル全体がエディターに保存されていることを確かめます。
エラー：cannot unmarshal string into Go value of type uint16
原因：整数が必要な項目に文字列が指定されています。詳細なログには通常、該当する項目や構造体も記載されます。
対処法：使用中のカーネルの項目定義に合わせて値の型を修正します。すべての数値を一律に引用符で囲んだり、文字列の引用符を一括削除したりしないでください。
以下は厳密なJSONで末尾のカンマが問題になる例です。そのまま実行できる完全なプロキシ設定ではありません。カーネルによってポートの記述方法が複数認められていても、JSONのオブジェクト構造は正しく記述する必要があります。
{
"listen": "127.0.0.1",
"port": 10808,
}上の10808の後ろに余分なカンマがあります。修正後：
{
"listen": "127.0.0.1",
"port": 10808
}- エディターが示すエラー位置は、実際の問題より後ろの場合があります。閉じ括弧のエラーが出たら、まず直前の行を確認してください。
- 文字列内のバックスラッシュは正しくエスケープする必要があります。WindowsのパスをJSONに記述する場合は、バックスラッシュを二重にするか、ローダーが対応するスラッシュ区切りのパスを使用します。
- 認証情報を含む設定ファイル全体を、オンラインのフォーマッターに送信しないでください。ローカルのエディターとカーネルのテストコマンドを使いましょう。
項目とルーティング：解析できても使えるとは限らない
JSONの形式が正しいことは、内容を読み込めるというだけで、カーネルがプロトコル、通信方式のオプション、ルールを認識することまでは保証しません。項目名は大文字と小文字を区別することが多く、クライアントの設定、サブスクリプションのテキスト、カーネルの実行設定はそれぞれ構造が異なります。サブスクリプションの内容をそのままカーネル用JSONとして使うことはできません。
項目名の誤記が、必ずしも「不明な項目」エラーになるとは限りません。ローダーによっては未知のキーを無視するため、必要な項目が不足したり、オプションが初期値に戻ったりすることがあります。テストに通っただけで、カスタム項目がすべて反映されたと判断しないでください。
| 確認対象 | 具体的な確認ポイント | 修正方法 |
|---|---|---|
| プロトコルと通信方式 | protocolと通信方式の設定が、使用中のカーネルでサポートされているか | 使用するカーネルを確認し、別のカーネル向けの設定全体をそのまま流用しない |
| アウトバウンドのタグ | outboundTagの値が、実際のアウトバウンドのtagと一致しているか | 大文字・小文字も含めて名称を統一し、テスト後に通信の経路も確認する |
| ルーティングルール | routing.rulesが配列で、各ルールに有効なマッチ条件があるか | 意図しない空のルールを削除し、domainやipなどの項目の型を確認する |
| リソースの参照 | geosite:cn、geoip:privateに対応するファイルとタグが存在するか | リソースのバージョン、パス、参照タグを一致させる |
以下はよく使われるルーティング設定の例です。既存の完全な設定に組み込んでください。directというタグのアウトバウンドがすでにあり、カーネルが該当するタグを含むリソースファイルを読み込めることが前提です。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}結論：まずルールを絞り、段階的に振り分けを戻す
現在のルーティング設定をバックアップしてから、クライアント内蔵のシンプルな設定に一時的に切り替えます。同じノードで起動できたら、カスタムルールを少しずつ戻してください。一度に一つのグループだけ戻し、エラーの原因となるリソース参照やルール項目を特定します。
起動後はルールの順序も確認します。条件が広いルールを前に置くと先に通信にマッチし、後続の細かなルールが適用されないことがあります。これは振り分けのロジックの問題であり、JSONの解析失敗とは分けて対処してください。詳しくは応用設定のルーティング解説をご覧ください。
ポート競合：プロセスを確認し、すぐに終了させない
ローカルの待ち受けポートの競合は、リモートノードのポートとは関係ありません。カーネルが127.0.0.1:10808をバインドしようとしても、別のプロセスが同じアドレスとポートを使用していると起動できないことがあります。よくある原因は、別のv2rayNが動作中、または前回のカーネルプロセスが終了していないことです。
エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：Windowsでは、すでに待ち受けているアドレスへの重複バインドが拒否されます。詳細なエラーには通常、競合しているアドレスとポートが表示されます。
対処法：待ち受けているプロセスを特定してから、重複しているインスタンスを通常の方法で終了するか、ローカルポートを変更し、そのポートを使用するアプリの設定も更新します。
エラー：bind: address already in use
原因：Linuxなどの環境で、同じ待ち受けアドレスとポートがすでに使用されています。
対処法：システムのポート確認ツールで使用中のプロセスを特定し、同じ設定のカーネルを二つ同時に起動しないようにします。
Windows PowerShellでは、以下の2つのコマンドでTCP 10808番ポートの待ち受けプロセスとプロセス名を確認できます。プロセスは終了しません。別のポートを使っている場合は、10808をログに記載された実際の値に置き換えてください。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -LocalPort 10808 -State Listen |
ForEach-Object { Get-Process -Id $_.OwningProcess }- プロセスがどのウィンドウに属するかとファイルの場所を確認してから、未知のプロセスを強制終了するのではなく、クライアントから通常の方法で終了してください。
- 10818に変更する場合は、「設定」→「パラメーター設定」でローカルポートを保存してから再起動し、システムプロキシやブラウザーの手動プロキシが引き続き10808を指定していないか確認してください。
- 通常のローカルプロキシのポート競合は、管理者権限では解決できません。TUNの権限エラーは、ログに基づいて別途調査してください。
- 設定によってはTCPとUDPの両方で待ち受けます。TCPの確認で結果が出なくても、UDPポートが空いているとは限りません。必要に応じて
Get-NetUDPEndpoint -LocalPort 10808で確認してください。
geoデータ：ファイル不足とタグ不足を切り分ける
geosite.datはドメインの分類情報、geoip.datはIPアドレスの分類情報を提供します。ルールがこれらのリソースを参照している場合、ファイルが見つからない、読み込めない、または必要なタグが内部に存在しないと、設定を構築できないことがあります。ノードを変更しても、ローカルリソースの読み込みエラーは解決しません。
エラー例：failed to load geosite
原因：ドメイン用リソースの読み込みに失敗しています。後続のエラーから、ファイルの読み込みと分類タグの不足のどちらが原因かを確認できます。
対処法：詳細なログでパスとタグを確認してから、リソースを復元するかルールの参照を修正します。この一文だけを見て、ファイルが破損していると判断しないでください。
エラー例：no such file or directory
原因：ログが示すファイルが存在しません。パスが実際にgeoファイルを指している場合に限り、リソース不足として扱います。
対処法：リソースの保存先と実際の起動場所を確認し、該当するファイルを補完します。起動プロセスに読み取り権限があることも確認してください。
- パスを確認：エラーに含まれるファイル名とディレクトリを残します。クライアント経由で起動する場合と、ターミナルから直接起動する場合では、作業ディレクトリやリソースの検索設定が異なることがあります。
- タグを確認：エラーにリストが存在しないとある場合は、ルール内の分類名を確認します。ファイルが存在していても、任意のタグを使えるとは限りません。
- リソースを復元：現在のv2rayNに備わっているリソース更新機能を使うか、完全なクライアントパッケージから対応ファイルを復元します。出所や形式が不明なデータを混ぜないでください。
- 範囲を絞って検証：バックアップを取ったうえで、該当する分類を参照するルールを一時的に削除し、再テストします。これは原因を特定するための手順で、最終的な振り分け設定が完成したことを意味しません。
同じカーネルでテストし、正常に起動することを確認する
テストには、v2rayNで実際に選択されているカーネルと設定ファイルのコピーを使います。XrayとV2Flyではコマンドラインの起動方法が異なります。以下に、一般的なXrayコマンドとV2Fly 5.xのサブコマンド形式を示します。実行前に、各プログラムのヘルプで引数を確認してください。別のカーネルのコマンドをそのまま使わないでください。
# PowerShell：使用するカーネルのディレクトリで実行。config.jsonはテスト用コピー
.\xray.exe -test -config .\config.json
# V2Fly 5.xのサブコマンド形式
.\v2ray.exe test -c .\config.json設定テストに通っても、実際の起動に成功するとは限りません。テストモードで主に確認するのは解析と構築であり、実際のポート待ち受けの代わりにはならず、リモートノードへの接続も保証しません。ターミナルからのテストでは、作業ディレクトリの違いによってリソースパスのエラーが起きることもあります。テスト環境をクライアントの起動環境に合わせてください。
テストに通ったのに、起動時にエラーが出るのはなぜ？
正常起動時のログをもう一度確認します。ポートのバインドに失敗している場合は、実際のポートを使って占有プロセスを調べます。リソースパスのエラーが再発した場合は、クライアントとターミナルの起動ディレクトリを比較してください。「設定を解析できる」ことと「ネットワークに接続できる」ことを混同しないでください。
カーネルを変更してから失敗する場合、まず何を直せばよい？
まず元のカーネルに戻して、設定が引き続き使えるか確認します。次に、新しいカーネルがプロトコルと通信方式に対応しているか確認してください。カスタム設定は項目ごとに調整する必要があり、実行ファイル名を変えるだけでは不十分です。通常のノードの場合は、クライアントでの選択と実際の起動ログを確認します。
サブスクリプションを更新したら、どのノードも起動しなくなった？
まず共通で使うローカルポート、ルーティング設定、geoデータを確認します。すべてのノードで同じローカルエラーが出る場合は、共通設定を優先して調べてください。特定の種類のノードだけ失敗する場合は、そのノードのプロトコルと通信方式の設定を確認します。
問い合わせるとき、何を共有すればよい？
クライアントとカーネルのバージョン、一度の起動で出たエラーの全体、カスタムルーティングの有無、直近の変更内容、実行したテストの結果を共有してください。サブスクリプションURL内のトークンやノードの認証情報を隠し、設定パスに含まれる個人情報も伏せてください。
- 確認項目1：設定テストでエラーがなく、通常起動してもすぐに終了しない。
- 確認項目2：使用するポートを今回起動したカーネルプロセスが待ち受けており、別のクライアントが占有していない。
- 確認項目3：アプリが正しいプロキシの接続先を使い、リクエストが実際に完了し、想定したルールどおりに通信が振り分けられる。
この順番で確認すれば、「起動失敗」を検証可能な小さな問題に切り分けられます。上記3項目を確認できても特定のウェブサイトに接続できない場合は、DNS、ノード、ルーティングを調査してください。テストに通ったJSONをさらに変更する必要はありません。その他のよくあるトラブルはヘルプセンターをご覧ください。