v2rayN のカーネル起動失敗、ノード切り替え直後の停止、システムプロキシを有効にしてもローカルポートが待ち受けない場合に適した内容です。まずクライアントログとカーネルログを区別し、最初の有効なエラーを確認してから、ポート・設定項目・サブスクリプションデータ・ネットワークハンドシェイクの4種類に分けて対処します。
まずカーネルの未起動か、ノードへの接続失敗かを切り分ける
「プロキシが使えない」だけでは原因を特定できません。v2rayN は管理画面であり、設定の解析、ローカルポートの待ち受け、外向き接続の確立を実際に行うのは Xray または V2Ray カーネルです。画面が正常に開いていても、カーネルが設定の読み込み中に終了することがあります。一方で、カーネルは起動済みでも接続先サーバーに到達できない場合もあります。ログの場所は近くても、対処方法はまったく異なります。
最も簡単な判断方法は、ローカルの待ち受け状態を確認することです。一般的な設定では SOCKS の受信接続は10808、HTTP の受信接続は10809で待ち受けますが、ポートを変更している場合は「設定」→「パラメーター設定」に表示される値を基準にしてください。起動後のログに「listening」や「started」が表示され、ポートが待ち受け状態になれば、設定の解析とローカルへのバインドは完了しています。その後にタイムアウト、接続リセット、ハンドシェイク失敗が発生するなら、外向き接続の問題であり、カーネル起動失敗ではありません。
結論：まず起動の境界を確認する
ローカルポートのバインド前にログが止まるなら、まず設定とポートを確認します。待ち受け成功後にエラーが出るなら、ノードのアドレス、通信パラメーター、サーバーへの到達性を確認してください。
v2rayN で本当に役立つログを見つける
トラブル対処では、少なくとも2種類の情報を区別する必要があります。クライアントログにはサブスクリプション更新、設定生成、カーネルプロセスの起動、画面操作が記録されます。カーネルログには JSON 設定の解析、受信ポートのバインド、DNS クエリ、ルーティングの一致、外向き接続が記録されます。「サービスの起動に失敗しました」といった画面の通知だけでは不十分なので、カーネルが返した元のエラーまで確認してください。
v2rayN 7.x の画面レイアウトはビルドの種類によって多少異なります。一般的な入口はメイン画面下部の「情報」エリア、または「ヘルプ」→「ログを表示」です。現在の画面にログパネルが表示されない場合は、「設定」→「パラメーター設定」を開き、ログレベルが無効になっていないか確認します。通常のトラブル対処には warning または info で十分です。ルーティングの一致や接続の詳細を確認するときだけ一時的に debug に切り替え、完了後は元のレベルに戻してください。大量の重複ログによる判断への影響を抑えられます。
1回再現する
まず現在の表示内容を消去し、問題のノードを選択してサービスを再起動します。起動ボタンを連続して押さず、1回の完全な再現でエラーの境界を確認してください。
カーネルの種類を確認する
「設定」→「パラメーター設定」→「Core タイプ」を開き、現在 Xray と V2Ray のどちらを使用しているか記録します。カーネルによって対応する設定項目の範囲が異なる場合があります。
最初のエラーを確認する
起動時刻の位置から下へ読み進め、error、failed、invalid、unable のいずれかを含む最初の記録を探します。その後に続く終了通知は、連鎖的に発生した結果であることが多いです。
前後の状況を残す
エラーの前後5行ずつをコピーし、ノードのプロトコル、通信方式、ローカルポートも記録します。ログを共有する前に、サブスクリプションURL、ノードの認証情報、完全なサーバー情報を削除してください。
項目ごとに検証する
1回の検証で変更する変数は1つだけにし、保存してから再起動します。ポート、カーネル、ノードを同時に変更すると、復旧しても本当の原因を特定できません。
ポート競合：待ち受け段階でカーネルが終了する
ポート競合は、ローカルで発生する起動トラブルの中でも特に一般的です。古いカーネルプロセスが終了していない、別のネットワークツールが同じポートを使用している、v2rayN を二重起動しているといった原因で、新しいプロセスは 127.0.0.1:10808 にバインドできません。この場合、再インストールしてもポートは解放されず、サブスクリプションを更新しても結果は変わりません。
典型的な特徴は、ログに bind、listen、address already in use が明確に含まれることです。Windows では、まずタスクバーの v2rayN を終了し、5秒待ってから再度起動します。それでも同じエラーが出る場合は、「設定」→「パラメーター設定」でローカル SOCKS と HTTP のポートを確認し、競合しているポートを未使用の値へ一時的に変更します。たとえば10808、10809から10818、10819へ変更し、保存して再起動してください。
エラー：failed to listen TCP on 127.0.0.1:10808 > bind: address already in use
原因と対処：10808は別のプロセスまたは残存カーネルによって使用されています。重複して起動しているクライアントを完全に終了するか、「設定」→「パラメーター設定」でローカルポートを変更して再起動してください。
エラー：failed to listen UDP on 127.0.0.1:10808
原因と対処：同じ受信接続で必要な UDP ポートをバインドできません。HTTP ポートだけを変更せず、対応する SOCKS 受信ポートと使用中のプロセスを確認してください。
エラー：access is denied
原因と対処：現在のプロセスに待ち受けの作成または実行ファイルの書き込み権限がありません。重複プロセスを終了し、プログラムフォルダーが書き込み可能か確認してから、通常のローカルフォルダーでクライアントを起動してください。
起動前：127.0.0.1:10808 は待ち受けていない
起動をクリック：設定を生成 → カーネルを読み込む → 受信接続をバインド
正常な結果：10808 と 10809 が待ち受け状態になる
異常な結果：bind / listen エラー後、カーネルが直ちに終了するポートを変更した後は、ブラウザーの手動プロキシ設定、端末の環境変数、固定ポートに依存する他のアプリも合わせて確認します。v2rayN がシステムプロキシの設定を担当している場合は、保存してシステムプロキシを再度有効にすると新しいポートが反映されます。アプリに 127.0.0.1:10808 を手動入力している場合は、新しい待ち受けポートへ自分で変更してください。
設定項目のエラー：最初の invalid から原因を特定する
v2rayN は、ノード情報、ルーティング規則、ローカル設定をもとにカーネル設定を生成します。ノードを手動編集した場合、不完全なリンクをインポートした場合、現在のカーネルが認識しない通信項目を使用した場合は、解析段階で設定の読み込みに失敗することがあります。この種のエラーは通常、ポートの待ち受け前に発生し、ログには invalid、unknown field、failed to parse config、failed to load config files などが表示されます。
生成されたファイルを直接開いて何度も編集しないでください。生成設定は次回起動時にクライアントから上書きされることがあります。エラーに示された項目名を手掛かりに、ノード編集画面、ルーティング設定、パラメーター設定で元データを修正するのが正しい方法です。たとえば security、network、serviceName、path が示されている場合はノードの通信パラメーターを確認し、routing や rule が示されている場合はカスタムルーティング規則を確認します。
エラー：Failed to start: main: failed to load config files
原因と対処：カーネルが設定の読み込みを完了できていません。同じ行の後半にある項目パスを確認し、対応するノードまたはルーティング設定を修正してください。最後に表示された終了通知だけを処理してはいけません。
エラー：invalid character after object key
原因と対処：手動設定に JSON の句読点、引用符、構造の誤りがあります。直前に行った手動編集を取り消し、クライアント画面から設定を再生成してください。
エラー：unknown field
原因と対処：現在の Core タイプが対応していない、または入力を誤った項目が設定に含まれています。「設定」→「パラメーター設定」→「Core タイプ」を確認し、最近追加した通信またはルーティングのパラメーターを見直してください。
エラー：invalid UUID
原因と対処：VMess または VLESS のノード識別子が不完全です。サブスクリプションを再更新するか、ノード編集画面で ID を確認してください。ノード名を識別子の代わりに使用しないでください。
| ログのキーワード | 優先して確認する場所 | 推奨する対処 |
|---|---|---|
| unknown field | ノード編集、ルーティング規則 | 未対応の項目を削除するか、項目名を修正する |
| invalid UUID | VMess、VLESS のノード ID | サブスクリプションを再更新し、識別子全体を確認する |
| failed to parse | 手動設定の内容 | クライアント生成設定に戻し、項目ごとに再構築する |
| failed to load | Core タイプ、設定パス | 後続するエラーの連鎖から具体的な項目を確認する |
結論：一時ファイルではなく元データを修正する
生成設定でエラーが出た場合は、ノード、サブスクリプション、ルーティング規則にある元の項目を修正します。一時的な設定ファイルを直接変更しても検証は1回しかできず、次回の再起動時に再生成された誤った内容で上書きされる可能性があります。
サブスクリプション情報が不完全：インポート成功でもノードが使えるとは限らない
サブスクリプションの更新が成功したという表示は、クライアントが解析可能な応答を受け取ったことを示すだけで、すべてのノードに完全なパラメーターがあるとは限りません。VMess では通常、サーバーアドレス、ポート、ユーザー識別子、通信設定が必要です。VLESS も有効な識別子に加え、サーバー側と一致する TLS、Reality、WebSocket、gRPC などのパラメーターが必要になる場合があります。ポートの欠落、空のアドレス、途中で切れた通信項目は、設定生成時または接続時に問題として現れます。
まず「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行し、正常に動作することが分かっているノードを1つ選んでテストします。1つのノードだけ失敗する場合は、そのノードを重点的に確認します。同じサブスクリプションの全ノードが同時に失敗する場合は、サブスクリプションの内容が完全に更新されているか、Core タイプが適合しているか、クライアントの時刻が大きくずれていないかを確認します。元のノードの項目を続けて上書きせず、先にコピーを作成してからテストすると簡単に戻せます。
エラー：failed to find an available destination
原因と対処：外向きサーバーのアドレスを解決できないか、利用可能な接続先がありません。ノードアドレスの入力と DNS 解決を確認し、アドレスに空白がないことを確かめてからカーネルを再起動してください。
エラー：missing port
原因と対処：サブスクリプションのノードに有効なサーバーポートがありません。サブスクリプションを再更新してください。手動ノードの場合は、編集画面にサービス提供元の正しいポートを入力します。
エラー：failed to dial WebSocket > 400 Bad Request
原因と対処：カーネル自体はすでに起動している可能性が高いですが、WebSocket のパス、Host、サーバー側の入口が一致していません。ノードの通信パラメーターを確認し、ポート競合として対処し続けないでください。
エラー：context deadline exceeded
原因と対処：制限時間内に接続が完了しませんでした。まずカーネルがローカルポートで待ち受けていることを確認し、その後サーバーアドレス、ポート、ネットワークへの到達性、通信パラメーターを確認します。
- 1つのノードだけ失敗：そのノードのアドレス、ポート、ID、通信方式、安全性パラメーターを確認します。
- 同じグループのノードがすべて失敗：サブスクリプションを再更新し、応答が完全か確認してから Core タイプを確認します。
- すべてのサブスクリプションが失敗：ローカルポート、カーネルファイル、システム時刻、共通パラメーター設定を確認します。
- 起動は正常だがウェブページを開けない：システムプロキシ、ブラウザーのプロキシ設定、DNS、ルーティング分岐を確認します。
変更する変数を最小限にして修正と再テストを行う
ログ対処で最も起こりやすいミスは、英語が理解できないことではなく、一度に変更しすぎることです。カーネルの変更、設定のリセット、ポート変更、サブスクリプションの再インポートを同時に行うと、一時的に復旧しても、どの操作が効果を発揮したのか分かりません。次に問題が起きたとき、また最初から調べることになります。
一定の再テスト手順を作ることをおすすめします。元のエラーを残し、1つの変数を変更して再起動し、ローカルポートを確認してから実際の接続を1回試します。各回でログのタイムスタンプと最初のエラーを比較してください。最初のエラーが変わったなら、前の障害点を越えたということです。同じエラーがそのまま出るなら、現在の変更は原因に影響していません。
元のエラーを保存する
最初の失敗時刻、Core タイプ、ローカルポート、最初の有効なエラーを記録し、後続ログで重要な状況が上書きされないようにします。
1つの変数だけ変更する
ポート競合ならポートだけを変更し、項目エラーなら該当項目だけを修正します。サブスクリプション異常なら先に更新し、他の設定を同時にリセットしないでください。
再起動して待つ
カーネルを完全に停止してから再起動し、少なくとも5秒間観察します。process exited や failed to listen が直ちに表示されないことを確認してください。
待ち受けを確認する
10808、10809、またはカスタムポートが待ち受け状態になっているか確認し、システムプロキシが指定するポートも一致しているか確認します。
2種類の通信をテストする
まずブラウザーでシステムプロキシをテストし、次に個別のプロキシ設定が必要な端末アプリをテストします。結果が異なる場合は、プロキシの適用範囲と環境変数を分けて確認してください。
ログレベルを戻す
問題が解決したら debug を warning または info に戻し、必要な記録だけを残します。重複した接続情報が後の判断を妨げるのを防げます。
結論：エラーの変化が対処の進展を示す
修正後、ログがすぐ完全に静かになる必要はありません。元の最初の起動エラーが消え、カーネルがポートの待ち受けを完了すれば、次の段階へ進んだということです。その後の接続エラーは、新しいログの種類に応じて対処してください。
v2rayN ですべてのノードの設定を生成できない一方、同じサブスクリプションを v2rayNG または v2flyNG では正常に解析できる場合、双方のカーネルの種類とサブスクリプション項目の対応状況を比較してください。v2rayNG は Xray カーネル、v2flyNG は v2fly カーネルを使用します。新しい通信パラメーターの中には、すべてのカーネルで同じように対応していないものがあります。比較すべきなのは項目の互換性であり、あるプラットフォームで正常だからデスクトップ側の設定も正しいと単純に判断することではありません。
修正が完了したら、必要なシステムプロキシまたはルーティング分岐モードも再度有効にします。カーネルの起動成功はローカルサービスが稼働していることを示すだけで、アプリの通信がプロキシを経由するかどうかは、システムプロキシ、TUN 設定、アプリ独自のプロキシ、ルーティング規則によって決まります。起動、通信の取り込み、分岐、外向き接続の4段階を分けて検証すると、安定して対処できます。