接続・設定リファレンス

V2Ray 接続トラブル解決ガイド

症状からアプリ、クライアント、コア、リモート間の問題箇所を特定します。一度に変更する設定は1つに絞り、同じリクエストで再確認してください。

初回インストールやサブスクリプションの追加方法は、まずクイックスタートガイドをご覧ください。このページでは接続トラブルの原因を調べます。デスクトップ版は v2rayN、Android版は v2rayNG と v2flyNGについて説明します。再インストールする場合は、クライアントのダウンロードページで対応プラットフォームとプロセッサーアーキテクチャを確認してください。

インターネットに接続できない：通信が止まっている場所を特定する

まず通常のネットワーク接続を確認する

クライアントを終了するかプロキシをオフにし、OSのネットワーク設定で手動プロキシが解除されていることを確認します。通常のWebサイトも開けない場合は、ノードを変更する前にWi-Fiの認証、ゲートウェイ、システム時刻、ネットワーク接続を確認してください。ホテル、学校、公共のWi-Fiでは、先にブラウザーで認証が必要な場合があります。プロキシを有効にすると認証ページへ移動できないこともあります。通常の接続が復旧してからクライアントを起動し、利用可能と確認できている設定を選びましょう。ネットワークへの接続不良をプロキシの問題と取り違えずに済みます。

次に、画面上で「実行中」と表示されているだけなのか、コアが実際にポートをリッスンしているのかを確認します。v2rayNのメイン画面にあるログ欄を開き、設定の読み込み、インバウンドの待ち受け、起動失敗に関する記録を探してください。アドレスの競合、設定の解析エラー、コアの終了が発生している場合、ブラウザーからリモートに接続する段階には達していません。設定の「基本設定」や「インバウンド設定」で、実際のローカル待ち受けポートを確認します。画面の項目名はバージョンによって異なる場合があるため、現在の設定と起動ログを基準にしてください。チュートリアルのポート番号をそのまま使ったり、リモートサーバーのポートをシステムプロキシに設定したりしないでください。

明示的なプロキシ接続で問題を切り分ける

以下のコマンドは、ローカルでHTTPプロキシを提供しており、実際のポートが10808であることを前提としています。Windowsでは、コマンドが端末のエイリアスに置き換えられないようcurl.exeを使用してください。それ以外のデスクトップOSではcurlを使えます。テストURLはリクエスト経路の確認用です。ローカルでSOCKSインバウンドのみを有効にしている場合は、対応するSOCKS用の引数に変更してください。SOCKSポートにHTTPプロキシのハンドシェイクを送ると、プロトコルが一致せずテストに失敗します。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

明示的なプロキシ接続では成功し、ブラウザーだけ失敗する場合は、システムプロキシ、ブラウザー拡張機能、ブラウザー独自のプロキシ設定を確認します。コマンドがローカルアドレスに接続できない場合は、待ち受けポート、コアのプロセス、セキュリティソフトのルールを確認してください。ローカル接続後にタイムアウトする場合は、ノード、ルーティング、DNSを調べます。Webサイトから返るステータスコードが成功を示すものでなくても、アクセス拒否などの応答によってリクエストが宛先に届いたと分かる場合があります。想定したアウトバウンドが使われたか、ログも確認してください。

グローバルモードは短時間の診断に使う

一時的にTUNをオフにしてシステムプロキシだけを使い、クライアントのルーティングをグローバルプロキシに切り替えて同じURLを再テストします。これで復旧する場合は、ノードの認証よりもルーティングルールや直結経路に問題がある可能性が高いでしょう。グローバルルーティングは、コアに届いた通信のアウトバウンドをプロキシに統一する機能であり、すべてのプロセスの通信を自動的に取り込むわけではありません。切り替え後も特定のアプリが通信できないからといって、ノードが完全に使えないとは限りません。テスト後は元のモードに戻し、プロキシ経由の通信範囲を広げたままにしないでください。

特定のWebサイトだけ開けない場合は、同じブラウザーでほかのサイトを開き、証明書、リダイレクト、ログイン状態に関連したエラーか確認します。プロキシ経由のリクエストがすべて失敗する場合は、別のノードで比較してください。最初からトランスポートプロトコルを変更するのは避けましょう。プロトコル、ポート、パス、フロー制御、サーバー設定は一式で一致している必要があります。サーバー側に対応するインバウンドがなければ、クライアントだけでプロトコルを変えても改善せず、新たな問題の原因が増えるだけです。

ノードがタイムアウトする：通信経路と認証を分けて確認する

テスト方法で確認できる範囲を把握する

ノード一覧の遅延テストが、必ずしもプロキシ経由の完全なリクエストを試しているとは限りません。通常のTCPテストではサーバーのポートに接続できるかを確認しますが、実接続テストではプロキシのハンドシェイクを経てテストURLにアクセスします。そのため、TCP接続に成功しても実接続に失敗することはあり、認証、TLS、通信経路、テスト先に問題がある可能性があります。逆に、一覧でタイムアウトと表示されても、すべてのアプリがアクセスできないとは限りません。まず選択中のテスト方法とタイムアウト時間を確認し、実際のWebアクセスでも再現するか調べてください。

一度にテストするノードは1つにし、同じ時間帯のログも確認します。一覧全体を連続テストすると大量の接続が同時に発生し、リモート側の速度制限や同時接続数の制限、ローカルのリソース競合を招いて元のエラーが分かりにくくなります。エラーが名前解決、接続、TLSハンドシェイク、応答の読み込みのどの段階で起きたかを記録してください。ログが単にタイムアウトとしか示さない場合は、テスト対象を1つの接続先と1つの宛先に絞り、一時的にログの詳細度を上げます。原因を特定したら、通常のログレベルに戻してください。

まずアドレスとポート、次にハンドシェイク関連の項目を確認する

サーバーアドレスの前後に空白がないか、ポート番号に間違いがないか、ドメイン名を正常に名前解決できるか確認します。同じサービスの全ノードで同時に問題が起きる場合は、アカウントの状態、サーバーメンテナンス、サブスクリプションの期限切れが考えられます。1つのノードだけ失敗する場合は、そのノード固有の設定や経路を疑いましょう。別のネットワークから接続して比較すれば、ローカルの通信経路とリモート側の問題を切り分けやすくなります。ただし、比較のたびにノードやほかの設定を変えると、どの変更が影響したのか判断できません。

TLSを使用する接続では、サーバー名、証明書との一致、トランスポート方式、システム時刻を確認します。接続先アドレスと証明書検証に使う名前は異なる場合があります。接続先にドメイン名が設定されているからといって、サーバー名を任意に上書きしないでください。WebSocketのパスとHost、gRPCのサービス名もサーバー側の設定と一致させる必要があります。これらは自由に書き換えてよいメモではありません。サービス提供元から指示がない限り、インポートした設定を維持し、ネット上のサンプルにあるパスやリクエストヘッダーを既存ノードにコピーしないでください。

ログの手がかりまず確認する項目この情報だけでは判断できないこと
接続が拒否されたリモートの待ち受け、ポート、ファイアウォールの拒否ルールユーザーIDが必ず間違っている
ハンドシェイクがタイムアウトしたネットワーク経路、トランスポート方式、サーバーからの応答ローカルDNSに必ず問題がある
証明書の検証に失敗したシステム時刻、サーバー名、証明書チェーン証明書検証を無効にすべき
読み込み中にEOFが発生した前後のログ、認証、トランスポート設定の整合性この1行だけで原因を特定できる

REALITYとフロー制御は組み合わせを一致させる

VLESSとREALITYを組み合わせる場合は、サービス提供元が指定した公開鍵パラメーター、Short ID、サーバー名、フロー制御も確認してください。画面によって項目名が異なる場合があるため、クライアントの説明に従います。クライアントの公開鍵パラメーターをサーバーの秘密鍵欄に入力しないでください。フロー制御のxtls-rprx-visionは汎用の高速化スイッチではありません。使用中のコアとサーバーの組み合わせに対応している必要があります。仕組みと各項目の関係はREALITYとXTLS Visionの解説をご覧ください。

「証明書の検証を許可しない」設定を通常の修復方法として使わないでください。これは認証の安全性を損ない、ポート番号の誤り、REALITYの設定ミス、サーバーの停止には効果がありません。システム時刻やサーバー名、設定の取得元を正し、必要に応じて接続先が現在も有効かサービス提供元に確認してください。古いコアが項目に対応していない場合は、まずダウンロードページで適切なクライアントを選び、実際に動作しているコアを確認します。画面だけ更新されても、コアの対応機能まで同じとは限りません。

サブスクリプションを更新できない：取得・解析・適用を切り分ける

既存ノードを残し、サブスクリプションの取得元を確認する

サブスクリプションの更新は、URLへのリクエスト、応答内容の解析、結果の対象グループへの反映という3つの段階に分かれます。更新に失敗しても、既存ノードをすぐに削除しないでください。既存ノードがまだ使える場合、ネットワークの復旧やサブスクリプション取得時のプロキシ経路として利用できます。まずサブスクリプショングループの設定を開き、どのグループを更新しているか確認してから失敗ログを調べます。似た名前のグループがあると、期限切れのURLと現在使用中のURLを取り違えやすくなります。

サービス提供元からサブスクリプションURL全体を再取得し、コピー時にクエリパラメーターが欠けていないか、改行が混入していないか、不要な記号が付いていないか確認します。サブスクリプションURLにはアカウントの認証情報が含まれることが多いため、公開オンライン変換ツールに貼り付けたり、スクリーンショットで公開したりしないでください。ブラウザーで開いたときに、クライアントが認識できるノード一覧ではなくログイン画面、期限切れの案内、Webページのエラーが表示される場合、サイトへのリクエスト自体は届いていますが、有効なノード一覧が返っていません。繰り返し更新しても解決しません。

応答状態と内容を分けて確認する

リクエストがタイムアウトする場合は、ネットワーク経路とドメインの名前解決を確認します。認証されていない、またはアクセスが拒否されたと表示される場合は、サブスクリプションの権限、URLの再発行の有無、アカウントの状態を確認してください。リクエスト過多の応答が返った場合は、手動での連続操作をやめ、サーバー側で許可されてから再試行します。成功ステータスが返っても、内容が正しいとは限りません。Web認証、ログインフォーム、メンテナンス画面を返すURLでは、その後クライアント側で解析エラーが発生します。リクエスト結果とコンテンツの種類をあわせて確認してください。

ログに形式を認識できないと表示される場合は、サブスクリプションが現在のクライアントに対応した形式か確認します。通常の共有リンクの一覧、エンコードされたリンク、ほかの設定形式は、それぞれ同じものではありません。ファイルの拡張子だけで互換性を判断したり、理解できない項目を手作業で削除して元のサブスクリプションを上書きしたりしないでください。v2rayN、v2rayNG、v2flyNGに対応したURLをサービス提供元に確認します。まずテスト用のグループ1つだけにインポートし、正常に使えることを確認してから元のグループを置き換えるか決めてください。

更新リクエストが直結かプロキシ経由か確認する

クライアントには、プロキシ経由で更新する設定やプロキシを使わずに更新する設定があります。具体的な項目の場所は画面によって異なります。サブスクリプションURLに直結できない場合は、利用可能なノードで接続中にプロキシ経由の更新を試せます。現在のノードが使えず、更新にもそのノードが必須だと、復旧手段が行き詰まります。その場合は直結での更新、まだ使える旧ノードの利用、別のネットワークへの切り替えを試し、失敗するノードでの再試行を続けないでください。

更新に成功してもノードが見つからない場合は、グループの絞り込み、検索条件、一覧の並び順、インポート件数の表示を確認します。名前によるフィルターが有効だと、サーバーから取得したノードがすべて除外されていることがあります。更新時に既存内容を置き換える設定では、使用中のノードが無効になっている場合もあります。新しいノードを1つ選んでアクティブにし、実接続テストを行ってください。更新に成功したことが示すのは設定を取得できたことだけです。すべてのノードがオンラインであることや、システムプロキシが自動的に有効になることを意味しません。

自動更新だけ失敗する場合は、タスク実行時のネットワーク状態、アクティブなノード、プロキシモードを記録し、手動更新時の経路と比較してください。PCの起動後にネットワークがまだ利用できない場合や、スリープから復帰した直後、ノードの切り替え中には、一時的に失敗することがあります。最後のエラー行だけでなく、失敗した時刻も記録してください。ネットワーク上のイベントと重なっていたか判断できます。設定の考え方はサブスクリプション更新失敗と自動更新の間隔をご覧ください。

通信速度が遅い：接続時の待ち時間と継続的な転送を分けて確認する

どの段階で遅くなるかを整理する

「速度が遅い」には、Webページを開くまでの待ち時間が長い、ページ内のリソースが順番に読み込まれる、継続的なダウンロード速度が低い、という少なくとも3つの現象があります。最初の待ち時間はDNS、接続確立、TLSハンドシェイク、再試行が原因になりやすく、ダウンロード速度は回線の混雑、サーバーの送信帯域、アカウントの制限、ローカル帯域の影響を受けます。同じサイトに続けて2回アクセスしてから大きなファイルを転送し、挙動を確認してください。あるノードの1回だけの遅延測定から、すべての性能を判断することはできません。遅延が小さくても、利用可能な転送速度が低い場合があります。

テスト前にほかのダウンロード、クラウド同期、システム更新を一時停止し、Wi-Fiの電波とローカルネットワークが安定していることを確認します。クライアントは1つだけ起動し、通信を取り込む方法も1つに絞ってください。複数のプロキシアプリが互いに通信を転送する状態を避けます。ノード、テスト対象、時間帯を固定し、その後に変更する設定は1つだけにします。異なるWebサイトを比較すると、サーバーの場所、キャッシュの有無、コンテンツのサイズが異なる場合があります。結果は特定のアクセス経路を示すものとして扱い、ノードの総合ランキングと決めつけないでください。

直結・システムプロキシ・TUNを比較する

通常のネットワーク接続も遅い場合は、まずローカルネットワークの問題を解消します。プロキシ経由の通信だけ遅い場合は、ノードとリモートへの回線を確認してください。システムプロキシでは正常でTUNだけ遅い場合は、通信の取り込み範囲、DNSの経路、ほかの仮想ネットワークアダプター、アプリのプロトコルの違いを確認します。TUNではより多くのアプリの通信がクライアントに入るため、バックグラウンド更新や同期が帯域を使うことがあります。TUNで全通信量が増えただけでコアの性能が落ちたと判断せず、テスト中にどのプロセスが通信していたか確認してください。

ページのメイン文書はすぐ表示されるのに画像や動画の読み込みが止まる場合、リソースごとに異なるドメインが別のルーティングを使っている可能性があります。ブラウザーのネットワークパネルで待ち時間が発生しているドメインを確認し、クライアントのログから使用されたアウトバウンドを調べます。リソースのドメインが誤って直結と判定されると、ページ全体が遅いように見えることがあります。ルールを変更する場合は、問題を確認できたドメイン範囲だけを対象にしてください。1つのサイトのためにルーティングルール全体を削除すると、ほかのアプリの通信にも影響します。

多重化、UDP、MTUの変更は慎重に行う

多重化は、どのプロトコルにも使える高速化スイッチではありません。接続の確立を繰り返すコストを減らせる場合がある一方で、複数のリクエストが同じ下位接続の輻輳や障害の影響を受けることもあります。有効にするかどうかは、プロトコル、フロー制御、コアの実際の対応状況に従ってください。比較テストではこの項目だけを切り替え、同じ状況で確認します。同時に並列数、トランスポート方式、DNSを変更しないでください。サービス提供元から指定がない場合は、クライアントとノード設定の初期動作を維持しましょう。

アプリによってはUDPベースの通信を優先しますが、現在の通信取り込み方式やリモート側がその経路に対応していないと、失敗後に再試行や切り替えが発生し、最初の応答が遅くなることがあります。UDPを一律に無効にするのではなく、ログとアプリのプロトコルを確認してください。同様に、一部のWebサイトで読み込みが止まり、TUNまたは特定のネットワークでのみ発生する場合に限り、経路MTUの確認を検討します。変更前に現在値を記録し、少しずつテストしてください。ネット上の固定値をそのまま設定すると、別の互換性問題が起きることがあります。

最後に、時間帯とネットワークを変えて確認します。同じノードが複数の接続先で継続的に遅く、別のノードにすると改善する場合は、具体的な時間帯、接続先の種類、テスト条件を添えてサービス提供元に連絡してください。複数のノードが同じWi-Fiでのみ遅い場合は、ネットワークや端末を優先して調べます。1回のテスト結果を追い求めてノードを何度も切り替えないでください。繰り返し再現する条件を比較すれば、一時的な変動と継続的な障害を切り分けやすくなり、不要な設定変更も減らせます。

DNSの問題：名前解決を行う場所とクエリ経路を確認する

OS・ブラウザー・コアの名前解決を区別する

同じ端末でも、OSのリゾルバー、ブラウザーのセキュアDNS、クライアントのコアDNS、TUNによるDNS制御が同時に使われる場合があります。ブラウザーでドメイン名を解決できても、コアが同じ結果を使っているとは限りません。OSのコマンドで名前解決に失敗しても、プロキシ経由のリクエストが必ず失敗するとは限りません。まず、どのアプリで、どのプロキシモードを使い、どのドメインで問題が起きているかを特定し、その経路に対応するDNS設定を確認します。すべてのDNS設定を同じアドレスに変更すると、経路の違いが隠れてしまいます。

ログにある「ホストが見つからない」「名前解決のタイムアウト」「接続先アドレスへの接続失敗」は、それぞれ異なる段階の問題です。最初の2つはDNSクエリを優先して確認します。最後のケースは、アドレスを取得できていても接続を確立できない可能性があります。まずOSのツールでドメイン名からレコードが返るか調べ、その後、プロキシ経由のリクエストでコアが接続できるか確認します。Windowsではnslookup example.comを使えます。それ以外のOSでは、インストール済みの名前解決ツールを使用してください。OSでの結果は比較用であり、ブラウザーやコアが実際に同じ結果を使うとは限りません。

ルーティング用の名前解決とプロキシ経由の名前解決の違い

ルーティング設定のdomainStrategyは、ドメイン名とIPアドレスを使ってルールを照合する方法を指定する項目です。全体のDNS設定を切り替える項目ではありません。IPIfNonMatchの場合、最初にドメイン関連のルールを照合し、一致しなければ必要に応じて名前解決してからIPルールを照合します。すべてのリクエストを事前に名前解決したり、最終的な宛先が特定のDNSサービスを使うことを保証したりするものではありません。ログ上で誤ったアウトバウンドに接続している場合は、ルールの順序、ドメイン条件、解決後のIPアドレスの種類も確認してください。

以下は、カスタム設定の参考用にXrayのDNSオブジェクトを抜粋したものです。クライアント設定全体ではなく、クライアントが生成した設定ファイルに上書きして使用することもできません。各項目の役割を示すため、クエリ方針を明示しています。パブリックDNSへの接続可否は、現在のネットワークによって異なります。GUIクライアントでは、まずDNS設定の該当項目を変更し、生成された設定が意図した内容になっているか確認してください。クライアントが設定を再生成する場合、一時ファイルを直接編集しても変更は保存されません。

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

IPv6、キャッシュ、暗号化DNSの初期名前解決を確認する

ネットワークによってはIPv6アドレスが返されても、端末から宛先までIPv6で接続できず、断続的な待ち時間が発生することがあります。比較のために一時的にIPv4のみを問い合わせる方法はありますが、すべてのネットワークでIPv6を恒久的に無効にすべきという意味ではありません。DNSクエリの優先順位と、実際のアウトバウンド接続方式も区別してください。これらは異なる設定です。変更しても解決しない場合は、キャッシュに古い応答が残っていないか確認し、新しいリクエストを開始してください。既存の接続が以前のアドレスを使い続けるのを防げます。

暗号化DNSでは初期名前解決も考慮する必要があります。リゾルバー自身のドメイン名も、最初に名前解決しなければなりません。この処理が未確立のプロキシに依存し、プロキシサーバーのアドレスも同じリゾルバーに依存する場合、循環参照が起きる可能性があります。クライアントが独立した初期名前解決の設定に対応しているか、クエリが直結かプロキシ経由かを確認してください。暗号化DNSのアドレスをすべての入力欄に同じように設定しないでください。入力欄によってサーバーアドレス、URL、ルール、ポリシーなど意味が異なります。

TUNで仮想アドレスのマッピングを使う場合、OSのツールに表示されるアドレスは、接続先サイトの実アドレスではなくクライアントが管理するマッピング結果のことがあります。クライアントのDNSモードをあわせて確認し、見慣れないアドレスだけで改ざんと判断しないでください。逆に、アプリにマッピング済みのアドレスがキャッシュされていても、リクエストが対応するTUNに入らなければ接続に失敗することがあります。通信の取り込み方式を切り替えた後は、テスト対象のアプリを完全に終了してから再起動してください。必要に応じて関連キャッシュを消去し、同じドメインで再テストします。

システムプロキシが効かない：アプリが設定を読み取っているか確認する

システムプロキシはすべての通信を取り込むわけではない

システムプロキシはアプリが参照するネットワーク設定であり、すべてのパケットを自動的にリダイレクトするルールではありません。ブラウザーはOSの設定に従うことがありますが、コマンドラインツールは環境変数だけを参照する場合があり、アプリ独自のプロキシ設定を使うものもあります。そのため、ブラウザーでは使えてもターミナルでは失敗することがあります。まずプロキシを明示するコマンドでローカルの接続口とリモートへの経路が使えることを確認し、アプリの設定を変更するか、用途に合ったTUNを有効にするか判断してください。アプリの挙動をコアの障害と取り違えないようにしましょう。

v2rayNでシステムプロキシの状態が「クリア」や「変更しない」になっていないことを確認し、OSのネットワーク設定にも反映されているか調べます。Windowsでは「設定 → ネットワークとインターネット → プロキシ」、macOSでは現在のネットワークサービスのプロキシ設定、Linuxのデスクトップ環境では通常ネットワーク設定のプロキシ項目を確認します。アドレスはローカルの待ち受けアドレスと一致させ、ポートにはクライアントの実際のインバウンドポートを指定してください。ネットワークアダプターを切り替えた場合も、現在のネットワークサービスに正しい設定が適用されているか確認します。

設定の上書きとプロキシの迂回を1つずつ確認する

ブラウザーのプロキシ拡張機能、自動プロキシスクリプト、組織のポリシー、アプリ内蔵のプロキシ設定がシステム設定より優先されることがあります。テスト用のブラウザーでは関連する拡張機能を一時的に無効にし、独自のプロキシモードが設定されていないか確認してください。自動プロキシスクリプトはアドレスに応じて直結とプロキシを選択するため、すべての通信をローカルポート経由にする設定とは異なります。一部のドメインだけが迂回される場合は、除外リストやスクリプトのルールを確認します。クライアントのプロキシを何度もオンに切り替える必要はありません。

ターミナルでは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYなどの環境変数も確認してください。環境変数の名称や優先順位はツールごとに異なり、古い変数がすでに停止したポートを指している場合があります。ツールの動作を確認せず、環境変数をまとめて恒久設定しないでください。診断時は、まずコマンド固有のプロキシ引数を使います。動作を確認した後、ツールの説明に従って設定し、ローカルアドレスや特定ドメインを迂回するルールがないかも確認してください。

以下のSOCKSテストも、実際のSOCKSインバウンドが10808であることを前提としています。socks5hは宛先ドメインの名前解決をプロキシ側で行う指定です。ローカルの名前解決経路との比較に役立ちますが、OSのDNSが修復されたという意味ではありません。SOCKSテストには成功し通常のアクセスだけ失敗する場合は、リモートのノードを次々変更するのではなく、アプリのプロキシ設定やローカルの名前解決を確認してください。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

TUNは別の通信取り込み要件に適している

システムプロキシを読み取らないアプリの通信もプロキシ経由にしたい場合は、現在のプラットフォームでTUNを利用できるか確認します。TUNは仮想ネットワークインターフェース、権限、ルーティング設定に依存し、システムプロキシとは別の機能です。有効にした後は、インターフェースが作成されたか、ルートが正しく設定されたか、DNSが想定どおり処理されるか確認してから、問題のあるアプリでテストします。起動時に権限エラーが出る場合、ノード設定を変えても通信の取り込みは直りません。まずクライアントの案内に従って権限を許可してください。

別のVPN、仮想ネットワークアダプターを使うツール、別のTUNが同時に動作すると、ルーティングが競合することがあります。診断時は通信を取り込むプログラムを1つだけ起動し、終了後に元のルートが復旧しているか確認してください。ローカルから接続できるようにするため、サーバーの待ち受けをすべてのネットワークインターフェースに設定するのも避けてください。ローカルプロキシは通常ループバックアドレスで十分です。待ち受け範囲を広げるとネットワークへの公開範囲が変わります。LANで共有する必要がある場合は、今回のローカル接続のトラブルシューティングとは分けて、アクセス制御とファイアウォールを設定してください。

クライアントがクラッシュする：画面、コア、システム環境を切り分ける

どのプロセスが終了したかを確認する

ウィンドウが表示されたまま接続できない場合は、コアの起動に失敗しただけかもしれません。ウィンドウ全体が消えた場合は、画面側のプロセスがクラッシュした可能性を調べます。クライアントログ、OSのイベント、プロセスの状態を確認し、起動時、ノード切り替え時、TUN有効化時、サブスクリプション更新時のどの段階で終了したか記録してください。画面が正常でもコアが正常とは限らず、コアが正常でもシステムプロキシが有効とは限りません。プログラムのフォルダーを丸ごと削除するより、発生した段階を分類するほうが診断に必要な手がかりを残せます。

クライアントを正常に終了し、バックグラウンドにプロセスが残っていないことを確認してから、ユーザー設定とサブスクリプショングループの情報をバックアップします。バックアップには完全なサブスクリプションURLや認証パラメーターが含まれる場合があるため、アクセスを制限できる場所に保存してください。データフォルダー全体を公開アップロードしたり、バックアップをWebサイトの公開ディレクトリに置いたりしないでください。再インストールする場合は元のコピーを残し、新しい設定環境でテストします。古いディレクトリにそのまま上書きすると新旧ファイルが混在し、問題が以前の設定に由来するのか判断できなくなることがあります。

プラットフォーム、アーキテクチャ、書き込み権限を確認する

ダウンロードページでパッケージの種類を再確認してください。Windowsのv2rayNデスクトップ版と従来のWPF版は画面が異なります。macOSではApple SiliconとIntelを区別し、Linuxではプロセッサーアーキテクチャとディストリビューションのパッケージ形式の両方を合わせます。アーキテクチャの不一致、必要なランタイムの不足、インストールの不備によって起動できない場合があります。必要な依存関係はインストーラーとOSのエラー表示を確認し、古い手順を参考に出所の分からないランタイムをダウンロードしないでください。

設定やログはユーザーデータの保存先に書き込める必要があります。制限されたディレクトリ、読み取り専用のメディア、同期ツールが繰り返しファイルをロックする場所では、保存失敗、設定の巻き戻り、起動エラーが起こることがあります。実行ファイルのある場所だけでなく、クライアントが実際に使用するデータディレクトリを確認してください。すべてのユーザーに全ファイルへのアクセスを許可せず、対象のユーザーディレクトリのアクセス権を修正します。管理者権限が必要な操作と、通常の設定ファイルへの書き込みも分けて考えてください。

コアの起動失敗では、最初のエラーを確認する

アドレスが使用中というエラーは、インバウンドポートを別のプロセスが使っているか、前のインスタンスが終了していないことを示します。Windowsでは、OSのリソース監視ツールで待ち受け中のプロセスを調べるか、以下のコマンド例でポートを確認できます。プロセス情報の確認には権限が必要な場合があります。競合するプロセスを確認したら正常に終了させるか、クライアントで空きポートを指定し、システムプロキシやアプリの設定も合わせて更新してください。正体の分からないシステムプロセスを終了したり、コアのインバウンドを変えずにシステムプロキシのポートだけを変更したりしないでください。

netstat -ano | findstr :10808

設定の解析エラーは、ログに最初に現れた項目や行番号から確認します。その後の「接続失敗」は、先行するエラーの結果かもしれません。JSONを手作業で編集した場合は、余分なカンマや引用符、フィールドの型を確認します。自動生成された設定の場合は、該当するGUI設定に戻って修正してください。GeoIPやGeoSiteファイルが見つからない場合は、パス、ファイルの有無、クライアントからの読み取り可否を確認してから、クライアントの更新機能を使って復旧します。別のプログラムからデータベースをコピーすると、タグや形式が異なる場合があります。

カスタムルールの変更直後に問題が起きた場合は、テスト用設定で既定のルーティングに戻し、動作が確認できているノードを1つだけ追加します。最小構成で正常に動作したら、元の設定を1つずつ戻してください。設定の問題とインストール環境の問題を切り分けやすくなり、古いディレクトリ全体を復元してクラッシュを繰り返すことも避けられます。コアの互換性についてはXray-coreとV2Flyの違いをご覧ください。2つのコアがまったく同じ項目に対応しているとは限りません。

Android特有の問題：権限、バックグラウンド動作、対象アプリを確認する

VPNアイコンが示すのは通信取り込みの入口があることだけ

v2rayNGとv2flyNGは、AndroidのVPNサービスを使って端末の通信を取り込みます。初回接続時には、OSの確認画面で許可する必要があります。許可を取り消すと、ノードをインポートできていても通信を取り込めません。ステータスバーにVPNアイコンが表示されても、クライアントのログと実際のリクエストを確認してください。アイコンが示すのは該当サービスがOSに作成されたことだけで、リモート認証、DNS、ルーティングがすべて正常だとは限りません。まずノードを1つ選んでテストし、複雑なアプリ別ルールは使わないでください。

Androidでは通常、同じユーザーまたはプロファイルで有効にできるVPNサービスは1つだけです。別のプロキシ、VPNインターフェースを使うファイアウォール、通信フィルターが現在の接続を置き換えることがあります。ほかの同種サービスを終了してから、目的のクライアントを起動してください。OSで「常時接続VPN」や「VPN未接続時に接続をブロック」が有効な場合、現在のクライアントが対象になっているかも確認します。クライアントの停止や権限エラー時に、OSのポリシーによってネットワークが遮断されることがあります。

画面点灯中は正常で、ロック後に切断される場合はバックグラウンド制限を確認

ロック後にだけ接続が切れる場合は、OSのバッテリー管理、バックグラウンド動作、自動起動の制限を優先して確認します。必要なバックグラウンド動作を許可し、省電力モードによってフォアグラウンドサービスが停止されていないか調べてください。端末ごとに設定名は大きく異なるため、ほかのメーカーのメニューをそのまま当てはめず、アプリ情報からバッテリーやバックグラウンド管理を開きます。変更後は一度画面をロックして待ち、復帰後にサービスが動作中か、通知が残っているか、ログにネットワーク再接続の記録があるかを確認してください。

バックグラウンド制限とリモート側のセッションタイムアウトが同時に起きていることもあります。クライアントのサービスが動作を続け、復帰後に最初のリクエストだけ遅い場合は、接続を再確立している可能性があります。サービス自体が終了している場合は、OSによるプロセス回収やアプリの終了が疑われます。画面ロック時の問題を直すために、すべての接続タイムアウトを過度に長くしたり、接続維持のために全ノードを頻繁に速度測定したりしないでください。まずサービスの終了や接続再確立を示す記録を探してから該当する設定を調整します。原因を解決せずにバッテリー消費だけを増やさないようにしましょう。

アプリ別プロキシとネットワーク切り替えを分けて再テストする

ブラウザーは使えるのに特定のアプリだけ使えない場合は、アプリ別プロキシの対象リストを確認します。リストが「選択したアプリだけをプロキシ経由にする」のか、「選択したアプリをプロキシから除外する」のかも確認してください。2つの設定は動作が逆で、同じアプリにチェックを入れても結果が異なります。変更後は対象アプリを完全に終了してから再起動し、接続を作り直します。仕事用プロファイル、複製アプリ、別ユーザーのプロファイルには独立したネットワーク境界がある場合があります。メインプロファイルのVPNが同じように通信を取り込めるとは限らないため、OSの権限範囲を確認してください。

Wi-Fiからモバイルネットワークに切り替えた後に問題が起きた場合は、まず新しいネットワーク自体が使えることを確認してから、クライアントの接続を一度停止して再起動します。ネットワークを切り替えるとアドレスやルートが変わり、既存のセッションをそのまま使えない場合があります。一方のネットワークでのみ失敗する場合は、ノードを変更せず、そのネットワークのDNS、IPv6、UDP経路を調べます。新しいネットワークでノードのドメイン名が別のアドレスに解決される場合はログも確認し、モバイルネットワークの問題をすぐにクライアントのバージョンに結びつけないでください。

必要なプロトコルに合わせてクライアントを選ぶ

Androidでは通常、まずv2rayNGを使用します。V2Flyコアの設定が必要な場合はv2flyNGを検討してください。名前を置き換えるだけで完全に同じ動作になるわけではなく、サブスクリプションのプロトコルや項目が使用するコアに対応している必要があります。インストールパッケージは端末のプロセッサーアーキテクチャに合わせて選び、比較的新しい端末では通常arm64を使用します。分からない場合は端末情報を確認し、必要に応じて汎用パッケージを選んでください。詳細はAndroidのダウンロード विकल्पをご覧ください。設定の互換性を確かめずに上書きインストールを繰り返さないでください。

最後に、ノード1つ、ブラウザー1つ、既定のルーティング、安定したネットワークで最小構成のテスト環境を作ります。正常に動作したら、アプリ別ルール、カスタムDNS、ほかの項目を1つずつ戻し、その都度再テストしてください。まだ失敗する場合は、権限の状態、ネットワークの種類、コアのエラー、再現手順をまとめ、スクリーンショットからサブスクリプションや認証情報を削除します。インポートから接続までの手順を確認するにはクイックスタートガイドに戻ってください。用語の意味は用語集で確認し、似た名前の別の設定を変更しないようにしましょう。

トラブルの記録と再テストの手順

操作ごとに「症状 → 現在のモード → 最初のエラー → 変更した設定1つ → 再テストの結果」の順で記録します。修復後は、もともと失敗していたアプリでもう一度確認し、日常的に使うルーティングとバックグラウンド設定に戻してください。一時的な変更でしか改善しない場合は、その変更が影響する範囲を引き続き確認します。診断用の設定をそのまま恒久設定にしないでください。

このページでは、クライアントとネットワーク経路のトラブルシューティング方法を説明します。リモートアカウント、接続先の有効期限、サーバーの状態は、該当するサービス提供元に確認してください。

クライアントをダウンロード