v2rayNのトラブルシューティング
接続・サブスクリプション・クライアント設定

1. 接続後にインターネットへ接続できない：まず問題の発生箇所を切り分ける

直接接続とプロキシ経由の接続を比較する

「インターネットに接続できない」原因は一つではありません。まずクライアントを終了し、システムのプロキシ設定を元に戻してから、普段直接アクセスできるサイトを開いてください。この状態でも接続できない場合は、Wi-Fi、ゲートウェイ、システム時刻、ネットワークのログイン画面を確認します。ホテル、学校、公共のWi-Fiでは、先にブラウザーで認証が必要なことがあります。クライアントが起動しているだけでは、基本のネットワークがつながっている証拠にはなりません。ネットワークが復旧する前に、プロトコルを何度も変更しないでください。

直接接続が正常になったらクライアントを起動し、サーバー一覧に使用可能なサーバーが実際にあることを確認します。マウスで選択した項目があるだけでは不十分です。次にログを確認し、コアが正常に起動してローカルの待受が始まっているかを調べます。タスクトレイにアイコンがあるのは、GUIが動作していることを示すだけです。コアの起動失敗、ポートの競合、設定生成の失敗があれば、ブラウザーはサービスが動いていないローカルアドレスに接続してしまいます。

同じテストサイトを使い、直接接続とプロキシ経由の結果をそれぞれ記録します。リクエストは一度ずつ実行し、ログで該当箇所を探せるよう時刻も控えてください。ブラウザーにエラーが出てもクライアントに新しいログがまったくない場合は、アプリのプロキシ適用かローカルの入口に原因があることが多いです。外向き接続のエラーが記録されている場合は、サーバーとプロトコルを確認します。ブラウザーに残った古いエラーページを新しいテスト結果と混同しないでください。

明示的なプロキシ接続でローカルの入口を確認する

v2rayNのパラメーター設定で、HTTPまたは混合インバウンドの実際のポートを確認します。以下の例ではポートを10808としています。設定と一致する場合のみそのまま実行し、異なる場合は先にポート番号を書き換えてください。Windowsではcurl.exeを使用すると、環境によって同名の別コマンドが呼び出される問題を避けられます。このテストで確認できるのはリクエストがローカルの入口を通るかどうかです。すべてのサイトへの接続を保証するものではありません。

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

ローカルポートに接続できないというエラーが出た場合は、まずコアのプロセス、待受アドレス、ポートの種類を確認します。すぐにリモートサーバーの設定を変える必要はありません。ローカル接続の後にハンドシェイク失敗やリモートのタイムアウトが発生した場合は、次の章に進んでください。サイトからHTTPレスポンスが返れば、成功ステータスでなくてもアプリケーション層から応答があったことを示します。内容を確認し、接続先の制限、認証の問題、プロキシ経路上の別の問題を切り分けてください。

明示的なプロキシ接続は成功するのにブラウザーでは失敗する場合、ブラウザー独自のプロキシ設定、拡張機能、システムプロキシを確認します。シークレットウィンドウでも、すべての拡張機能が無効になるとは限らず、システム設定を迂回できるとも限りません。独自のプロキシルールがないブラウザープロファイルで比較してください。特定のアプリだけが失敗する場合は、システムプロキシに対応しているかも確認します。ブラウザーが使えるからといって、すべてのアプリが同じ入口を自動的に使うとは限りません。

最小限の設定に戻し、機能を一つずつ追加する

カスタム設定が複数ある場合は、先にバックアップを取り、動作確認済みのサーバー一つとシンプルなルーティング設定だけを残します。追加のプロキシチェーン、複雑なルールセット、重複して動作するネットワークツールを一時的に無効にし、リクエストが複数のローカル入口を循環しないようにします。テスト中は、システムプロキシ、別のトラフィック制御機能、ブラウザー拡張機能のプロキシを同時に有効にしないでください。それぞれの入口と出口が明確でないと、ログから同じ通信経路を追えなくなります。

すべてのサイトに接続できない場合は、共通する入口、名前解決、外向き接続を確認します。特定の種類のドメインだけが失敗する場合は、ルーティングルール、接続先アドレス、サイト側の状態を調べてください。テスト用ドメインを一時的に明示的なプロキシ経由に設定して確認し、テスト後は元のルールに戻します。一時的なグローバルプロキシを恒久的な解決策にしないでください。誤ったルールを迂回しているだけで、元の設定問題が残っている可能性があります。

修復後は、カスタムルーティング、ブラウザー設定、その他のネットワークツールを順に戻し、戻すたびに同じ接続先で再テストします。最後にクライアントを終了して再起動し、設定が再起動後も有効か確認してください。動作した入口、使用中のサーバー、プロキシモードを記録しておくと、次回のトラブル時に基準と比較できます。接続手順に不安がある場合は、大量の設定を再インポートするのではなく、クイックスタートガイドを確認してください。

2. ノードがタイムアウトする：通信接続とプロトコルハンドシェイクを切り分ける

タイムアウトが発生した段階を特定する

クライアントのテストでタイムアウトが表示されても、サーバーのドメイン名を解決できない、接続先ポートに接続できない、通信は確立したがプロトコルのハンドシェイクが完了しないなど、原因はいくつか考えられます。テスト機能によって接続先や方法が異なるため、一覧のテスト結果だけでは実際のアクセス状況を判断できません。まずログで最初に出たエラーを確認してください。その後に続くエラーは同じ失敗に伴う再試行の場合があり、別々の問題とは限りません。

Windowsでは、以下のポートテストを実行できます。アドレスとポートは説明用の例なので、設定にある実際の値に置き換えてください。テスト成功が示すのは対象のTCP接続を確立できたことだけで、VLESS、REALITY、ユーザー認証が正しいことまでは確認できません。テストに失敗した場合も、サーバーが特定のネットワーク経路からの接続のみ受け付けるかを考慮してください。一度の結果だけでクライアントの故障と判断しないでください。

Test-NetConnection -ComputerName your-server.example.com -Port 443

サーバーのトランスポートが単純なTCP接続でない場合、このテストで判断できる範囲はさらに限られます。UDPベースの経路では、ローカルネットワークとサーバー側で該当する通信が許可されているかも確認してください。通常のウェブページが表示できても、すべてのトランスポートが到達可能とは限りません。同じ接続先を使ってWi-Fiとモバイルネットワークを比較すると、複数のプロトコル設定を続けて変えるより、ネットワーク環境の違いを把握しやすくなります。

VLESSとREALITYのパラメーターを項目ごとに確認する

トランスポートのポートに接続できるのにハンドシェイクに失敗する場合は、サーバー提供元の情報と照らし合わせて項目ごとに確認します。サーバーアドレスは接続先を指定し、サーバー名はセキュリティハンドシェイクに使われるため、両者は同じとは限りません。サーバー名を接続先アドレスに自動で置き換えたり、特定のポートを使っているという理由だけでトランスポート層のセキュリティを無効にしたりしないでください。クライアントとサーバーで同じプロトコルの組み合わせを使う必要があります。

XTLS Visionを使う場合は、フロー制御と現在のトランスポート、セキュリティ設定の組み合わせも確認してください。似た設定が別のサーバーで使えるからといって、そのフロー制御の値をコピーしないでください。REALITYの公開鍵、ショートID、サーバー名は、サーバー側の指定と一致している必要があります。ショートIDの設定方法は環境によって異なり、省略できるかどうかもサーバー側の設定次第です。チュートリアルのスクリーンショットだけを唯一の基準にしないでください。

システム時刻のずれも、セキュリティハンドシェイクに影響することがあります。OSの自動時刻合わせを有効にし、日付と時刻が実際の時刻と一致しているか確認してください。エラーが証明書やサーバーの識別情報に関する場合は、サーバー名、証明書の設定、システムの信頼環境を調べます。本人確認を無効にすることを通常の解決策にしないでください。ハンドシェイクエラーを隠して接続できたように見えても、元の設定問題やセキュリティ上の問題は残ります。

サーバー、コア、ローカルネットワークのどこに原因があるかを判断する

同じネットワークで一つのサーバーだけが継続してタイムアウトし、動作確認済みの他のサーバーは正常な場合は、そのサーバーのアドレス、稼働状況、アカウントの有効性を優先して確認します。すべてのサーバーが同時に異常となり、ルーターの設定変更やネットワーク切り替えの直後に発生した場合は、まず共通のネットワーク経路を調べてください。比較テストでは同じ設定を使わないと、差がネットワークと設定のどちらに由来するか判断できません。

選択中のコアが設定に必要な機能をサポートしているかも確認します。XrayとV2Flyの機能は完全には一致しません。共有設定をインポートできることと、コアがその設定を実行できることは別です。REALITYと設定の互換性については、XrayとV2Flyのコアの違いを参照してください。ログに機能非対応が明確に示された場合に限り、設定要件に応じてコアまたはクライアントを変更してください。

設定の提供元に問い合わせる際は、テスト時刻、使用ネットワーク、接続先、エラーが発生した段階、機密情報を伏せた最初のエラーをまとめます。「タイムアウト」と書かれたスクリーンショットだけを送ったり、サブスクリプションの認証情報を公開したりしないでください。同じ設定が別のネットワークでは動作する場合は、両環境の違いも伝えます。どの環境でも失敗する場合は、サーバー側のログも必要です。リモート側で待受がない、アカウントが停止されている、サーバー設定が一致しないといった問題は、クライアントだけでは修復できません。

3. サブスクリプションの更新失敗：取得・解析・更新のどこで問題が起きたかを確認する

URLから正しい内容を取得できているか確認する

サブスクリプションの更新は、URLからの取得、内容の解析、サーバー一覧への書き込みの3段階で行われます。更新失敗と表示されたら、まず具体的なエラーを確認してください。ドメイン名の解決失敗、接続タイムアウト、認証拒否、内容の解析エラーでは対処方法が異なります。サービスによっては正常なHTTPステータスを返しても、実際の内容はログインページやアクセス案内の場合があります。有効なサブスクリプションデータではないため、更新ボタンを何度押しても状況は変わりません。

信頼できる設定管理ページからサブスクリプションURLを改めてコピーし、スキーム、パス、クエリパラメーターがすべて含まれているか確認します。チャットツールでの改行、末尾の文字の削除、コピー時に前後へ入った空白によって、URLが変わることがあります。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、パスワードと同様に扱ってください。公開の速度測定サイト、オンラインデコードツール、掲示板に貼り付けたり、URL全体が写ったスクリーンショットを共有したりしないでください。

ログに認証拒否やリソースが見つからないというエラーがある場合は、元の設定管理ページでサブスクリプションの有効期限、アカウントの権限、URLがリセットされていないかを確認します。サーバーへの接続とサブスクリプションURLの更新は別の機能です。既存のサーバー設定は使い続けられても、サブスクリプションの認証情報は変更されている場合があります。反対に、サブスクリプションを取得できても、そこに含まれるすべてのサーバーへ接続できるとは限りません。

更新リクエストがどのネットワーク経路を使うか確認する

サブスクリプションの更新は直接接続する場合と、クライアントの設定に従って既存のプロキシを経由する場合があります。更新に関するオプションを確認し、必ずシステムプロキシを使うと思い込まないでください。クライアントをインストールしたばかりで使用可能なサーバーがなく、サブスクリプション取得にプロキシが必要な場合、設定がないと設定を取得できないという依存関係が発生します。提供元が許可しているアクセス可能なURLか、信頼できる手動設定の方法を使ってください。同じ失敗する経路を繰り返し試さないでください。

使用可能なサーバーがある場合は、そのサーバーを有効にしたまま、直接更新とプロキシ経由の更新をそれぞれ試します。一度に切り替える更新方法は一つだけにしてください。一方だけが成功する場合、サブスクリプションURLへの接続経路か名前解決環境に原因がある可能性が高いです。システムプロキシ、DNS、更新方法を同時に変更しないでください。複数の条件を一度に変えると、更新できても何が有効だったのか判断できません。

URLがウェブページを返す、リダイレクトがおかしい、セキュリティ接続エラーが出る場合は、システム時刻、ネットワークのログイン状態、上流ネットワークでの認証の有無を確認します。サブスクリプションを取得するために、セキュリティ接続の検証を恒久的に緩めないでください。リクエストがログインページに転送される場合は、通常のサービス管理画面で認証状態を確認してください。ログインページの内容を設定ファイルとして保存してクライアントにインポートしても解決しません。

形式の非互換、重複項目、上書きに注意する

内容を取得できても解析に失敗する場合は、提供された形式が現在のクライアントに適しているか確認してください。共有リンクの一覧、エンコードされたサブスクリプションテキスト、特定の形式の設定ファイルは、自由に相互変換できるものではありません。拡張子だけで形式を判断したり、エンコード層をやみくもに追加・削除したりしないでください。設定の提供元が明示するクライアント用形式を使い、設定内のプロトコル機能が選択中のコアと互換性があるか確認してください。

更新前にサブスクリプショングループと手動で変更した少数の項目をバックアップします。更新によってグループの内容が再構成され、手動で変更した別名、アドレス、トランスポート項目が新しいサブスクリプションの値で上書きされることがあります。手動設定を長期的に残す場合は、独立したグループに分けてわかりやすい名前を付けてください。同じURLを指すグループを複数管理しないでください。サーバー一覧が増えたように見えても、同じ項目が重複しているだけで、選択を間違えやすくなります。

更新後に項目が消えた場合は、グループの絞り込み、名前フィルター、サブスクリプションから返された内容を確認してください。すぐに一覧全体を消去しないでください。空の一覧はフィルターの設定が原因の場合も、URLが空のデータを返した場合もあります。古い設定をバックアップしたうえで、独立したテスト用グループで検証すれば、画面表示の問題とリモート側の内容の問題を切り分けられます。更新成功の表示はクライアントの処理が完了したことを示すだけで、内容が期待どおりとは限りません。

最後に、更新後の項目が明確に選択されていることを確認してから、使用するサーバーに設定して接続をテストします。クライアントによっては、以前使用していたサーバーを新しく作成された項目に自動で引き継がないため、「更新は成功したのに接続できない」原因が使用サーバーの選択にあることもあります。サブスクリプションとサーバー選択の基本については、よくある質問を参照してください。ログがプロトコルのハンドシェイクまで進んでいる場合は、ノードのタイムアウトの章に戻って確認してください。

4. 速度低下や断続的な遅延：同じ条件で比較する

最初の接続が遅い、継続して遅い、特定サイトだけ遅い、の3つに分ける

ページの初回表示だけ遅く、その後の通信は正常な場合、名前解決、接続確立、セキュリティハンドシェイクが原因として考えられます。ダウンロード開始後も速度が遅い場合は、通信経路のスループット、パケットロス、サーバーの負荷、端末の性能が関係している可能性があります。動画がときどき止まる場合は、接続先サービスのキャッシュや配信制御が原因のこともあります。再現できる症状を具体的に整理し、待ち時間をすべて「ノードが遅い」と決めつけないでください。サーバーを替えても本当の原因が隠れるだけの場合があります。

比較するときは、端末、ネットワーク、使用中のサーバー、テスト先、テスト時刻をそろえ、クラウド同期、OSのダウンロード、ほかの大容量通信を一時停止します。汎用の速度測定だけでなく、実際に利用するサービスで確認してください。接続先ごとに通信経路やサービス側の制御が異なることがあります。速度測定の結果が良くても、ファイルのダウンロード、動画、リアルタイム通信が同じように快適とは限りません。

比較前に、テストのリクエストが同じルーティングを通っているか確認します。ルールの更新、名前解決の結果、アプリの設定が変わると、同じドメインでも異なる出口を使うことがあります。接続ログを開き、接続先に選択された最終的なアウトバウンドを確認してください。一方が直接接続、もう一方がプロキシ経由なら、結果を比較できません。少数のテストを繰り返せば十分です。高頻度の同時リクエストで余計な通信を発生させ、観察結果に影響を与えないでください。

ローカルネットワーク、リモート経路、端末のリソースを順に確認する

まずプロキシを使わない通常の通信も遅いか観察します。同じように遅い場合は、Wi-Fiの電波強度、ルーターの負荷、ブロードバンドの上り帯域が使い切られていないかを確認します。上り回線が混雑すると、確認応答や対話的なリクエストが遅れます。ダウンロード帯域に余裕があるように見えても、ウェブページの応答が遅くなることがあります。可能であれば有線接続やルーターの近くで比較してください。ただし、サーバーも同時に変更すると、どの段階で改善したのか判断できません。

プロキシ経由の通信だけが遅い場合は、同じサーバーから複数の接続先へアクセスする比較と、複数のサーバーから同じ接続先へアクセスする比較を行います。前者では接続先サイトと出口の制御を、後者ではサーバーごとの経路の違いを確認できます。ネットワーク間の経路は時間とともに変化するため、短時間のテストでわかるのはその時点の状態だけです。夜間の混雑、サーバー側の速度制限、接続先のリソース不足は、同じ条件で複数回記録して判断してください。一度の最高速度だけで結論を出さないでください。

タスクマネージャーやリソースモニターでシステムの状態も確認します。クライアントやほかのプロセスがCPUを継続的に多く使用している場合や、メモリ不足でページングが頻発している場合は、端末側がボトルネックかもしれません。大量の同時接続、詳細すぎるログ、頻繁な速度測定も負荷を増やします。不要なタスクを減らし、ログレベルは通常の設定にしてください。一時的なCPU使用率の上昇だけで、セキュリティソフトを無効にしたりOSのネットワーク設定を変更したりしないでください。

トランスポート、接続の多重化、トラフィック制御の設定は慎重に変更する

接続の多重化は、すべてのプロトコルやネットワークで効果があるわけではありません。組み合わせによってはヘッドオブライン待ちが増えたり、コアやプロトコルの制限を受けたりすることがあります。設定の提供元がサポートを明示しており、変更前後を比較できる場合に限り、関連項目を調整してください。ネット上の「高速化設定」を一式コピーして、すべてのサーバーに適用しないでください。多重化、フロー制御、トランスポートの設定を誤ると、速度が向上しないだけでなく、安定していた接続まで不安定になることがあります。

シンプルなページは開けるのに、大きなページや長時間接続が頻繁に止まる場合は、トラフィック制御モード、パスMTU、UDPの動作を確認します。ただし、MTUの調整は初期確認ではなく、後から行う項目です。まず明示的なプロキシ接続と現在のトラフィック制御方式を比較してください。問題が制御方式によって変わる場合に限り、ネットワークインターフェースや関連設定を調べます。変更前の値を記録し、少しずつ調整して元に戻せるか確認してください。根拠のない値をいくつも試して、新たな不明点を増やさないでください。

特定のウェブサイトだけが遅い場合は、ブラウザーの開発者ツールやアプリのエラー表示で、メイン文書、画像、スクリプト、APIリクエストを切り分けます。ページが複数のドメインに依存している場合、そのうち一つが誤った経路に振り分けられたり、名前解決に失敗したりするだけで、ページ全体が遅く見えることがあります。すべての通信を同じ出口に恒久的に送るのではなく、ルールの適用範囲を修正してください。接続先サービスによる速度制限やアカウント制限は、クライアントの設定では解消できません。

調整後は、初回表示、継続的な通信、アイドル状態からの再接続を最低限テストし、ある状況が改善する一方で別の状況が悪化していないか確認します。有効だった変更と元に戻す方法を記録し、一時的な速度測定タスクを終了してください。Androidで主に画面消灯後に遅くなる場合は、モバイル端末の章を確認します。バックグラウンドでのアプリ停止と通信経路のスループット不足は似た症状になることがありますが、対処すべきなのはシステムの実行制御であり、接続数をやみくもに増やすことではありません。

5. DNSの問題：どこで名前解決しているかを特定する

システム、ブラウザー、コアの名前解決を切り分ける

DNSの問題は、ドメインにアクセスできない、つながることもある、誤ったアドレスに接続される、最初のリクエストだけ長く待たされる、といった形で現れます。同じ端末上に、システムのリゾルバー、ブラウザーのセキュアDNS、クライアントのコアDNS、アプリ内蔵の名前解決機能が共存している場合があります。これらが同じサーバーや経路を使うとは限りません。まず、実際のリクエストをどの機能が名前解決しているか整理してから、該当する設定を変更してください。システムDNSだけを変更しても、すべてのアプリに反映されるとは限りません。

Windowsでは、以下のコマンドでシステムの名前解決結果を確認できます。確認できるのはシステムの名前解決経路であり、クライアントのコアやブラウザーが実際に使った結果とは限りません。返されたアドレス、エラーの種類、問い合わせ時刻を記録し、クライアントのログと照らし合わせます。IPアドレスを直接入力してウェブサイトを開く方法も、一般的な検証にはなりません。多くのサイトはホスト名、セキュアなハンドシェイク、バーチャルホストに依存しているため、IPアドレスでアクセスできなくてもネットワーク障害とは限りません。

Resolve-DnsName example.com

システムで正常に名前解決できるのにブラウザーで失敗する場合は、ブラウザー独自のセキュアDNSが有効か、選択したDNSサービスに接続できるかを確認します。反対に、ブラウザーでは正常でも特定のアプリが失敗する場合は、名前解決の経路が異なる可能性があります。テストでは一度に一か所だけ設定を統一し、変更前の値を記録してください。ブラウザー、システム、コアの名前解決を同時に変更すると、原因を特定できなくなります。

名前解決のループと起動時の依存関係を解消する

リモートの名前解決サービス自体がドメイン名を使う場合、まずそのドメイン名を解決する必要があります。システムからのすべての問い合わせをそのサービスに送る一方、そのサービスへの接続にはまだ確立していないプロキシが必要だと、起動時の依存関係が循環します。同様に、サーバーアドレスがドメイン名で、その名前解決のリクエストも同じサーバー経由に指定すると、循環が発生することがあります。設定では、明確に到達可能な初期の名前解決経路を確保してください。各段階が次の段階の成功に依存しないようにします。

以下は、名前解決先と問い合わせ方法の関係を示すコア設定のDNS部分です。クライアント全体の設定ではなく、GUIクライアントが自動生成したファイルにそのまま上書きしないでください。実際の設定はクライアントが提供する項目から変更し、使用中のコアのドキュメントで各フィールドの動作を確認してください。この例は通常のDNS問い合わせを示しています。現在のネットワーク環境やプライバシー要件に適するかは、別途検討が必要です。

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

DNSサーバーへの接続性、問い合わせ通信のルーティング、名前解決後の接続確立は、それぞれ別の問題です。DNSサーバーが問い合わせに応答しても、返された結果が現在の接続経路に適しているとは限りません。直接接続とプロキシを使い分ける環境では、ドメインのルール、名前解決の方針、アウトバウンドの選択を一致させてください。「名前解決が速い」ことと「接続先への通信が速い」ことは同じではありません。地理的な振り分け結果も、その後の通信経路に影響することがあります。

IPv6、キャッシュ、ルールの適用状況を確認する

IPv4とIPv6の両方を使う環境では、ドメインから両方のアドレスが返される場合があります。端末がIPv6アドレスを取得していても、実際の出口がIPv6に対応していないと、接続できない経路が先に試され、待ち時間が発生することがあります。まず各アドレスへの到達性を個別に確認し、そのうえで問い合わせ方法や接続方針を調整してください。IPv6アドレスが表示されたというだけで、システム全体のIPv6を無効にしないでください。局所的な設定変更のほうが元に戻しやすく、ほかの機能への影響も抑えられます。

DNS設定を変更しても、古い結果がOS、ブラウザー、コアのキャッシュに残っていることがあります。必要な場合、Windowsではipconfig /flushdnsを実行してシステムのキャッシュを消去できますが、アプリ独自のキャッシュまでは削除されません。テストをいったん止め、必要に応じて関連するアプリやコアを再起動してから再度問い合わせます。設定を確認せずにキャッシュを繰り返し消去しても、現象が変化するだけで原因は解消されません。

一部のドメインだけで問題が起きる場合は、hosts、クライアント独自のドメインマッピング、広告ブロック、安全ソフトが結果を変更していないか確認します。ルールのドメイン照合とIPアドレス照合は異なる段階で行われることがあり、名前解決後のアドレスが別のルールに一致する場合もあります。ルール一覧の順番だけで判断せず、接続ログで最終的なアウトバウンドを確認してください。一時的にルールを追加する場合は、テスト用ドメインに限定し、削除する条件も記録してください。

検証では、システムの名前解決、実際のアプリからのアクセス、クライアントログの3点を確認します。名前解決に成功しても、セキュリティハンドシェイクとページリクエストが完了する必要があります。設定変更後にブラウザーだけが復旧した場合は、ほかのアプリが独自の名前解決を使っていないか調べてください。すべてのドメインを正常に解決できるのに接続がタイムアウトする場合は、トランスポートとハンドシェイクの章に戻ります。問題を分けて考えることで、サーバーのポート障害があるときにDNSを何度も変更する事態を防げます。

6. システムプロキシが効かない：アプリがプロキシを使うか確認する

システムプロキシと端末全体の通信制御の違いを理解する

システムプロキシは、アプリが参照するためのネットワーク設定であり、OSがすべての通信を強制的にクライアントへ送る仕組みではありません。ブラウザーは設定に従うことが多い一方、コマンドラインツール、ゲーム、バックグラウンドサービス、独自のネットワーク機能を使うアプリは無視する場合があります。システムプロキシを有効にしても特定のアプリが直接接続するのは、必ずしもv2rayNの設定失敗ではありません。まずアプリがどのプロキシ方式に対応しているかを確認し、適切な接続方法を選んでください。

まずv2rayNの現在のシステムプロキシ状態を確認します。プロキシを解除する設定や、元の設定を維持する設定になっていないかを調べてください。次にOSのネットワークプロキシ画面で、アドレス、ポート、自動構成スクリプトの有無を確認します。各プロキシ方式の優先順位はOSとアプリによって異なります。手動プロキシと自動スクリプトが同時に設定されていると、誤った判断につながりやすくなります。調査中は明確な方式を一つだけ使い、元の値も記録して、職場のネットワーク要件に影響しないようにしてください。

端末上のアプリは通常、ループバックアドレスでローカルの入口に接続します。127.0.0.1はその端末自身を指します。スマートフォンのプロキシアドレスにもこの値を指定しても、パソコンには接続できません。LAN内で共有するには、ホストのLANアドレス、正しいインバウンドポート、アクセス範囲の設定が必要です。これは端末自身のシステムプロキシとは別の経路です。パソコン上のブラウザーの問題を解決するために、LANからの待受を安易に有効にしないでください。

プロトコル、ポート、アプリ独自の設定を確認する

明示的なプロキシ接続は成功するのにアプリで反映されない場合は、アプリ内に「直接接続」「システム設定を使用」「独自のプロキシ」といった設定がないか確認します。環境変数を参照するツールもあれば、システム設定を参照するツールもあります。同じターミナルから起動したアプリでも、同じ動作をするとは限りません。プロキシを変更した後は、古い接続を閉じるかアプリを再起動してください。確立済みの長時間接続は、新しい出口にすぐ切り替わらないことがあります。

ポートは入口のプロトコルに対応している必要があります。HTTPプロキシのアドレスを、SOCKSだけを受け付けるポートに指定しないでください。混合インバウンドで両方のリクエストを受け付けるかは、現在のクライアント設定で確認します。SOCKSを使い、接続先のドメイン名解決をプロキシ側で行う場合、対応する構文を使えるツールではsocks5hを指定できます。これはローカルで先に名前解決する場合とは動作が異なります。テストでは違いを明確にしてください。

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

上記のポートは仮の値です。まず、実際にSOCKSリクエストを受け付けるか確認してください。HTTPのテストは成功してSOCKSのテストが失敗しても、すぐにサーバーの問題とは判断できません。二つのテストで異なるローカル入口の機能を使っている可能性があります。また、ローカルアドレス、特定のドメイン、ネットワーク範囲などを除外するアプリのプロキシ除外リストも確認します。明示的に除外されたリクエストは、プロキシに送られません。

複数のネットワークツールとの競合や設定の残存を確認する

ネットワークツールを複数起動すると、システムプロキシの設定が何度も書き換えられる場合があります。設定が一度成功してもすぐ元に戻る、クライアント終了後にほかのアプリがすべてネットワークに接続できなくなる、といった症状が起きます。プロキシ管理機能を持つほかのプログラムを終了し、システム設定が安定するか確認してください。ブラウザー拡張機能がシステム設定を上書きすることもあります。システム層とブラウザー層をそれぞれ確認し、タスクトレイの選択状態だけでプロキシが適用されたと判断しないでください。

クライアントが異常終了すると、ローカルポートを指すシステムプロキシ設定だけが残り、そのポートでは待受プロセスが停止していることがあります。クライアントを再起動してシステムプロキシを正常に解除するか、OSのネットワーク設定画面で無効になった手動設定を削除してください。ルーターを何度も再起動する必要はありません。リクエストは端末から出る前に失敗しています。直接接続を復旧した後、同じ問題が再発しないよう、クライアントが異常終了した原因も確認してください。

LAN内で共有する場合は、必要なネットワーク範囲だけにアクセスを許可し、ファイアウォールで該当ポートとネットワークプロファイルを限定します。ファイアウォール全体を無効にしたり、ローカルプロキシの入口をインターネットに公開したりしないでください。共有の詳しい手順は、v2rayNのLAN接続を許可する方法を参照してください。ホストが接続先のネットワークを変更するとLANアドレスが変わることがあり、ほかの端末側でも確認が必要です。

最終確認では、プロキシを有効にする、アプリを再接続する、プロキシを無効にする、クライアントを終了する、の4つを試します。有効にした後はログで正しいアウトバウンドにリクエストが入ることを確認します。無効にした後は直接接続が復旧すること、終了後は使えない入口がシステムに残っていないことを確認してください。システムプロキシに対応していないアプリだけが引き続き接続できない場合は、アプリ独自のプロキシや適切なトラフィック制御方式を使います。同じシステムプロキシのアドレスを書き込み続けても解決しません。

7. クライアントのクラッシュやコアの終了：最初のエラーを記録する

GUIの終了とコアの起動失敗を切り分ける

ウィンドウが消える、タスクトレイには残る、サーバーに接続できない、コアが何度も再起動するといった症状は、それぞれ異なる層の問題です。まずGUIが終了したのか、コアの子プロセスが停止したのかを確認してください。画面は正常でもログに設定エラーがある場合は、生成された設定と機能の互換性を確認します。プログラム全体が起動しない場合は、インストールパッケージのアーキテクチャ、OSの対応状況、実行時の依存関係、ファイルへのアクセス権を調べてください。最初から設定ディレクトリ全体を削除しないでください。

起動直後に終了する、サブスクリプションの更新後に終了する、コアの切り替え後に失敗する、特定の設定画面を開くとクラッシュするなど、発生のきっかけを記録します。次に、該当時刻のクライアントログとOSのイベント記録を確認してください。最初に発生した異常とその前後のログを残します。その後の接続失敗は、すでにプログラムが停止した結果かもしれません。ログが大量にある場合は、まずコピーを保存してから消去し、問題を一度再現してください。有効な情報が新しいログに上書きされるのを防げます。

診断情報を共有する前に、パス、ユーザー名、サブスクリプションの認証情報、設定全体が含まれていないか確認します。ユーザーディレクトリ全体を公開したり、サーバーの認証情報を含むクラッシュレポートをアップロードしたりしないでください。まずクライアント名、システムのアーキテクチャ、発生手順、機密情報を伏せたエラーがあれば調査を始められます。より詳しい情報が必要な場合は、収集する範囲を明確にし、信頼できる方法で共有してください。ローカルのファイルをすべてそのまま投稿しないでください。

インストール環境、アクセス権、ポートの使用状況を確認する

クライアントのダウンロードページでOSとプロセッサーのアーキテクチャに合ったインストールパッケージを選びます。Windowsのデスクトップ版と従来のWPF版では、UIの技術と実行条件が異なります。切り替える前に設定をバックアップし、異なるインストール内容を混在させて上書きしないでください。選び方については、Avaloniaデスクトップ版とWPF版の比較を参照してください。画面の問題を解決するために、提供元が不明な実行コンポーネントを安易にコピーしないでください。

ポータブル版のフォルダーは、現在のユーザーが問題なく読み書きできる場所に置いてください。アクセス制限のある場所、読み取り専用のメディア、頻繁に同期されるフォルダーは避けます。ログにアクセス拒否が記録されている場合は、問題のパスと権限を確認してください。問題を隠すために管理者として恒久的に実行しないでください。セキュリティソフトにブロックされた場合は、まずブロック履歴とファイルの入手元を確認し、OSの仕組みに従って対処します。すべての保護機能を停止することを標準のインストール手順にしないでください。

コアにポート使用中のエラーが出る場合、別のクライアントが起動したままになっているか、ほかのサービスが同じポートを使用している可能性があります。まずタスクトレイとプロセス一覧を確認し、重複したプロセスを終了してから待受が復旧したか確認します。ポートを変更する必要がある場合は、システムプロキシとアプリ独自のプロキシアドレスも同時に変更してください。クライアント側だけを変更すると、ポート競合がローカル入口への接続失敗に変わり、ネットワーク障害のように見えてしまいます。

独立した設定で破損や互換性の問題を切り分ける

設定変更の直後に起動エラーが発生した場合は、まずその変更を元に戻します。画面を開けない場合は、設定の保存場所を確認してバックアップを取ったうえで、独立したテスト用ディレクトリか新しいユーザー設定で動作を確認します。元のディレクトリをそのまま削除しないでください。サブスクリプショングループ、手動で追加したサーバー、ルーティングルールが含まれていることがあります。テスト環境に動作確認済みの設定を一つだけ置けば、プログラム環境と古い設定の破損を切り分けやすくなります。

新しい環境では正常で古い環境では失敗する場合、サーバー、サブスクリプション、ルーティング設定を一つずつ戻し、戻すたびに再起動して確認します。ルールを追加した後に失敗する場合は、ルールファイルのパス、フィールドの形式、コアの対応状況を調べてください。GUIクライアントで項目を保存できても、最終的に生成されるコア設定が必ず有効とは限りません。起動ログのフィールドエラーと実際の動作を基準に判断してください。

最小限の設定をクリーンな環境で使ってもプログラムが終了する場合は、システムリソース、ディスク容量、実行時の依存関係、ソフトウェア間の競合を確認します。更新や再インストールを行う際も元の設定をバックアップし、テスト中に古い設定をすべて同時に戻さないでください。特定の機能が互換性の問題を起こしていると確認できた場合に限り、代替の実装を選びます。再インストールで一時的に直っただけで、それ以前の発生条件を無視しないでください。

修復後はクライアントを完全に終了して再起動し、コアが一つだけ起動すること、ローカルの入口が正常なこと、終了時にシステムプロキシが元に戻ることを確認します。続いてサブスクリプションの更新と普段使うルーティングを検証し、一時的に設定が空になったため問題が隠れているだけでないか確認してください。発生の手順と解決方法を合わせて記録すると、「再インストールで直った」とだけ記録するより役立ちます。環境が変わったときも、同じ問題かどうかすばやく判断できます。

8. Androidの切断やバッテリー消費：権限とバックグラウンド設定を確認する

VpnServiceの許可と、同時に動作しているサービスの数を確認する

Androidでは、サービスが起動しない、起動しているが通信しない、画面消灯後に停止する、の3つを切り分けます。v2rayNGとv2flyNGは、システムのVpnServiceを使って対象の通信を制御します。初回接続時にはシステムの許可が必要です。許可されたことは、ローカルの仮想ネットワークインターフェースを作成する権限があることを示すだけで、サーバーとのハンドシェイク成功を意味しません。実行中と表示されているのにアクセスできない場合は、ログで使用中のサーバー、DNS、アウトバウンドの設定を確認してください。

同じユーザー環境では通常、この種のVPNサービスを同時に有効にできるのは一つだけです。別のネットワークフィルター、業務用ネットワーク、プロキシアプリを起動すると、現在のサービスが置き換わる場合があります。まずシステム設定で実際に動作中のアプリを確認し、常駐通知が表示されているかも調べてください。速度比較のためにv2rayNGとv2flyNGを同時に起動しないでください。前者を完全に停止してから後者をテストしないと、サービスの制御状態の変化が結果に混ざります。

クライアントを切り替えても、元の設定が必ず動作するとは限りません。v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを選択肢として提供します。必要な機能に応じて選んでください。設定がREALITYや特定のフロー制御に依存する場合は、まずコアが対応しているか確認します。ハンドシェイク失敗をシステムの許可の問題と混同しないでください。初回の許可、バックグラウンド設定、アプリごとのプロキシ設定については、v2rayNGのAndroid設定のポイントを参照してください。

画面消灯後の切断とネットワーク切り替えに対処する

画面が点灯している間は正常なのに、消灯後しばらくして切断される場合は、アプリのバッテリー使用設定、バックグラウンド実行の権限、メーカー独自の自動起動管理を確認します。システムによってメニュー名は異なりますが、アプリ情報からバッテリー関連の設定を探せます。必要なバックグラウンド動作を許可してから、画面をロックして再テストしてください。すべてのアプリの制限を一律に緩めないでください。常駐通知はサービスが動作中であることを示します。通知を隠すためにサービスのバックグラウンド動作を妨げないでください。

バックグラウンドの制限を緩めるとバッテリー消費が増えるため、実際に必要な安定性に応じて設定します。一定の間隔で画面消灯の前後のログとシステムのバッテリー統計を確認し、プロセスが終了したのか、ネットワークが停止したのか、リモート接続が自然に切れたのかを判断してください。サービス通知が残っているのにリクエストが失敗する場合は、アプリがシステムに終了されたのではなく、接続の再確立が必要な可能性があります。強制停止やバックグラウンドのクリアを繰り返すと、維持したい動作状態をかえって壊してしまいます。

Wi-Fiとモバイルネットワークの切り替えによってアドレス、ルーティング、到達性が変わり、既存の接続が切れることがあります。まずクライアントが接続を再確立するまで待ってから、新しいリクエストを送信してください。切り替え前に開いたままのページで、現在の状態を判断しないでください。切り替えのたびに失敗する場合は、バックグラウンドでのモバイルデータ通信、データセーバー、クライアントの再接続動作を確認します。各ネットワークでは使えるのに切り替え後だけ失敗することが確認できてから、ネットワーク移行の処理を重点的に調べてください。

アプリごとのプロキシ設定と異常なバッテリー消費を調べる

一部のアプリだけがプロキシを使わない場合は、アプリごとの設定が「選択したアプリのみをプロキシ経由にする」のか「選択したアプリを除外する」のかを確認します。二つのリストは意味が反対です。アプリを選択しても期待どおりにならない場合、モードを取り違えていることがよくあります。設定変更後はサービスを停止して再起動し、対象アプリの既存接続を終了してからテストしてください。システムアプリ、仕事用プロファイル内のアプリ、同じ名前の複製アプリは、それぞれ別の識別情報を持つ場合があります。ホーム画面のアイコン名だけで正しいアプリを選択したと判断しないでください。

バッテリー消費が多い場合は、統計の対象期間、合計稼働時間、前景とバックグラウンドの使用割合を確認します。VPNサービスは中継したネットワーク通信の電力も計上されることがあり、バッテリー画面の割合がすべてクライアントによる追加消費とは限りません。比較する前後で通信量を近づけてください。一方が動画を再生し続け、もう一方が待機している条件では比較できません。電波の弱さ、テザリング、ほかのアプリによる頻繁な通信も確認してください。

アイドル中もログに再接続が続く場合は、サーバーへの到達性、名前解決の失敗、ネットワークの不安定さを確認します。頻繁なハンドシェイク、自動テスト、短い間隔での更新は端末を起動させることがあります。すべてのタイムアウトをむやみに延長するのではなく、不要な定期処理を減らしてください。反対にタイムアウトが短すぎると、一時的な混雑を切断と誤認して再試行が増えることがあります。初期設定か、明確な根拠のある方法を保ち、一つずつ比較するほうが、省電力設定と称する値の組み合わせを一括適用するより確実です。

最後に、画面表示中のアクセス、画面消灯中の待機、ネットワーク切り替え、アプリごとのアクセスの4つを検証し、各条件のサービス状態とエラー発生時刻を記録します。主な問題がバッテリー消費の場合は、v2rayNGのバッテリー消費とバックグラウンド動作のトラブルシューティングも参照してください。すべての状況で同じハンドシェイク段階に失敗する場合は、ノードのタイムアウトの章に戻ります。システムのバックグラウンド制御、コアの互換性、リモート接続はそれぞれ別の原因です。分けて調べることで、再現性のある修復につながります。