V2Rayクライアント
トラブルシューティング

インターネットに接続できない：通常のネットワークとプロキシ経路を切り分ける

プロキシを停止し、通常のネットワークが使えるか確認する

v2rayNではシステムプロキシを解除し、Tunモードをオフにします。v2rayNGでは接続を停止します。普段プロキシなしで開けるサイトにアクセスし、ネットワーク接続にWeb認証が必要か確認してください。公共Wi-Fiは接続済みと表示されていても、ログインが済んでいない場合があります。プロキシアプリが起動していても、インターネットに接続できるとは限りません。アプリを停止してもアクセスできない場合は、Wi-Fiの電波状況、ルーターの接続状態、システムのネットワーク設定を確認してください。ノードの設定はまだ変更しないでください。

ノードとクライアントの設定は変えずに、別のネットワークに切り替えて再確認します。たとえばWi-Fiからモバイルデータに切り替え、プロキシなしでアクセスできるか確認してください。特定のネットワークだけで失敗する場合は、そのネットワークの認証、名前解決、アクセス制限に原因を絞れます。すべてのネットワークで失敗する場合は、端末側を引き続き確認します。テスト中は、別のVPN、通信高速化アプリ、プロキシ機能付きのセキュリティソフトなど、通信を取り込む他のアプリを停止してください。複数のアプリが同時にルートを変更すると、原因を特定しにくくなります。

「コアの起動」「ノードへの接続」「通信の取り込み」の順に確認する

クライアントを起動し直し、ログにコアの終了、設定の読み込み失敗、ポートの競合がないか確認します。画面上で動作中と表示されていても、コアのプロセスが停止している場合があります。コアが動作し続けていることを確認したら、現在のノードで接続テストを行い、ブラウザーから実際にアクセスします。接続テストに失敗した場合はノードのタイムアウトを確認してください。テストに成功してもブラウザーからアクセスできない場合は、システムプロキシ、アプリごとのプロキシ設定、DNSを重点的に確認します。すぐにプロトコルを変更する必要はありません。

デスクトップでは、原因を絞るためにTunを一時的にオフにし、システムプロキシの自動設定だけを使ってみます。この状態でブラウザーが使えて、Tunをオンにすると失敗する場合は、仮想ネットワークアダプターの作成、実行権限、ルートの競合を確認してください。逆に、Tunでは使えてシステムプロキシでは使えない場合は、アプリがシステムプロキシを参照しているか、システム設定のアドレスとポートが現在のクライアントを指しているか確認します。どちらか一方が使えても、もう一方の設定が正しいとは限りません。通信を取り込む場所が異なります。

少数のアクセス先を使って、全体の問題か特定サイトの問題かを切り分ける

異なる2つのサイトにアクセスし、ほかのアプリの状態も確認します。特定のサイトだけ開けない場合は、サイトのメンテナンス、アカウント制限、証明書エラー、該当ルートの異常などが考えられます。ブラウザーに証明書警告が表示されたら、まずシステムの日付とタイムゾーンを確認してください。証明書の検証を無効にする方法は、通常の対処として使わないでください。特定のアプリだけ失敗する場合は、そのアプリ独自のプロキシ、DNS、キャッシュを確認します。すべてのアプリで同時に失敗する場合は、共通の通信経路やシステムによる通信の取り込みに問題がある可能性が高くなります。

インターネット接続が戻ったら、まずクライアントを一度終了し、システムプロキシが正常に解除されることを確認してから、再接続してテストします。異常終了後にプロキシのアドレスが残っていると、次回の起動時もインターネットに接続できないように見えることがあります。ネットワーク全体をすぐにリセットせず、エラー発生時刻前後のログと元の設定を保存してください。システム側に原因があると判断できた場合にだけ、操作範囲を広げます。基本的な流れは初回接続の確認メモも参考にしてください。

ノードのタイムアウト：接続、ハンドシェイク、テスト先を切り分ける

まず、どの段階でタイムアウトするか確認する

ノード一覧から接続テストを行い、その後ログを開いて同じ時刻のエラーを確認します。接続タイムアウトは、一定時間内に処理が完了しなかったことを示すもので、サーバーが恒久的に停止したとは限りません。ドメイン名の名前解決、サーバーのポートへの接続、暗号化ハンドシェイク、プロキシ接続後のテスト先からの応答など、さまざまな段階で失敗が起きます。エラーに記録された段階と接続先を確認してから、次の手順を決めてください。リストの結果だけを見ると、異なる原因を混同しやすくなります。

ログがサーバーアドレスへの接続で止まる場合は、サブスクリプションを最近更新したか、対象ノードが現在の選択項目になっているか、サーバーのドメイン名を名前解決できるか確認してください。同じグループの別ノードを試し、さらに別のネットワークでも再確認します。1つのノードだけ失敗し、ほかは正常なら、その設定またはサーバー側を疑います。同じグループの全ノードが失敗し、別のグループは正常なら、そのグループのサーバー状態を確認します。すべてのグループで失敗する場合は、端末のネットワーク、システム時刻、クライアントのコア起動状態を確認してください。すべてのノードを同時に変更しないでください。

ポートに接続できても、プロトコルのハンドシェイクが完了したとは限らない

ポートに接続できることから分かるのは、そのポートで接続を受け付けるサービスがあるということだけです。ユーザー識別情報、通信方式、暗号化パラメーターが一致しているかは確認できません。ハンドシェイクエラーが発生したら、プロトコルの種類、サーバーポート、通信方式、TLSの有効・無効、サーバー名、パスを個別に確認してください。WebSocketなどを使う場合は、パスとHostもサーバー側の設定に合わせます。REALITYを使う場合は、公開鍵、Short ID、サーバー名も正確に設定してください。推測で入力せず、信頼できる元の設定から再インポートするのが確実です。

システム設定の「日付と時刻」で自動設定を有効にし、もう一度試します。時刻が大きくずれていると、証明書の有効期間の判定に影響することがあります。プロトコルによっては認証にも時刻を使います。証明書のドメイン名が一致しない場合は、サーバー名がサービス提供元の案内と一致しているか確認してください。安全でない接続を許可する設定に変更しないでください。長期間保存したクリップボードから設定した場合は、改行、全角文字、古いポート番号が混ざっていないか確認します。手動編集の前にノード設定をバックアップし、再インポート後の項目と比較できるようにしてください。

接続テスト先と実際の利用環境の違いを確認する

接続テストでは通常、指定された接続先にプロキシ経由でアクセスします。接続先が一時的に利用できない、応答方法が変わった、ルールによって別の出口に振り分けられたといった理由でも、ノードが失敗と判定されることがあります。クライアントの設定でテスト先を確認し、有効なWebサイトであることを確かめてから、同じノードを使ってブラウザーで別のサイトにアクセスしてください。テストを通すためにタイムアウト時間を繰り返し短くしないでください。テスト先への接続可否だけで、インターネット上のすべてのサービスが利用できるとは判断できません。

さらに調べる場合は、Windows PowerShellでTCPポートを確認できます。以下のコマンドは、本機の例示ポートで待ち受けているプログラムがあるかを調べるもので、ローカルの接続口の確認に使えます。リモートサーバーを確認する場合は、実際のサーバーアドレスとポートを指定してください。成功と表示されても、プロキシ認証が成功したとは限りません。macOSやLinuxでもシステム標準のネットワークツールで同様の確認ができます。1回の調査のためにツール一式を追加でインストールする必要はありません。通常はクライアントのログから十分な情報を得られます。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

同じノードが別の端末で使える場合は、サブスクリプションの更新時期、利用しているコアの機能、手動で上書きした項目を比較します。v2rayN、v2rayNG、v2flyNGの画面が似ていても、すべての設定拡張を相互に使えるとは限りません。サービス提供元の元の設定を保存し、「タイムアウトした」とだけ伝えるのではなく、具体的なハンドシェイクエラーと発生時刻を共有すると原因を特定しやすくなります。ユーザー識別情報、サブスクリプションURL、サーバー情報を含むログを公開しないでください。

サブスクリプションの更新失敗：ダウンロード失敗と内容のインポート失敗を切り分ける

まずサブスクリプショングループのURLと更新方法を確認する

v2rayNでは「サブスクリプショングループ」→「サブスクリプショングループの設定」、v2rayNGでは「サブスクリプショングループの設定」を開き、URLが正しいか確認します。コピー時にリンクの一部しか選択されていない、共有用の説明文までコピーしている、前後に空白が入っているといった問題がよくあります。サブスクリプションURLには個人用の認証情報が含まれる場合があります。確認は端末内で行い、公開されている変換ツールには貼り付けないでください。サービス提供元がURLを再発行している場合は、古いURLが無効になっている可能性があります。現在有効なURLをコピーし直してください。

更新に失敗したら、エラーがタイムアウト、名前解決の失敗、証明書の問題、サーバーからのアクセス拒否のどれかを確認します。タイムアウトの場合は現在のネットワークを確認し、名前解決に失敗した場合はDNSの章を参照してください。証明書の問題では、システム時刻と表示された証明書の警告を確認します。アクセス拒否やリソースが見つからない場合は、アカウントの状態、URLの有効期限、サービス提供元による接続先変更を確認してください。権限を調べるために更新ボタンを何度も押す必要はありません。同じ結果を繰り返しても、新しい判断材料は得られません。

プロキシを使わない更新と、プロキシ経由の更新を切り分ける

サブスクリプションの更新にもインターネット接続が必要です。選択中のノードが使えず、更新もプロキシ経由に設定されていると、「新しいノードを取得するには、先に使えるノードが必要」という状態になります。まず、クライアントにプロキシを使わずに更新する方法があれば試してください。直接更新に失敗しても、別の接続が使える場合は、その接続を維持したままプロキシ経由での更新を試します。メニュー名はビルドによって異なることがあります。大切なのは、更新リクエストが実際にどの経路を通るか確認することです。ボタンだけ切り替えてログを見ないままにしないでください。

更新が成功しても、ノード情報を取得できているか確認してください。ネットワークによっては、サブスクリプションのリクエストがWi-Fiの認証ページにリダイレクトされることがあります。サービス側からアカウントの期限切れを知らせる内容や、通常のWebページが返される場合もあります。この場合、ダウンロード自体は完了しても、パーサーがノード情報を読み込めません。クライアントで更新ログを確認できる場合は、対応していない形式、有効なサーバーがない、内容が空といったメッセージがないか確認します。端末内のブラウザーでログインページが返っているか確認できますが、認証情報を含むページ全体のスクリーンショットを保存したり共有したりしないでください。

元のグループを残し、小規模なインポートテストを行う

最初にグループ全体を削除して更新しないでください。利用できる設定は残し、必要であれば自分だけがアクセスできるディレクトリにエクスポートしてから、同じサブスクリプションを新しいテスト用グループにインポートします。新しいグループではインポートでき、元のグループでは失敗する場合は、元のグループにフィルター、自動並べ替え、別名、その他の上書き設定がないか確認してください。どちらのグループでも失敗する場合は、サービス提供元が案内する形式をクライアントが認識できるか確認します。設定ファイル、単一の共有リンク、複数ノードをまとめたサブスクリプションはそれぞれ別の入力形式です。リンクの見た目だけで用途を判断しないでください。

サブスクリプションを更新すると、以降に自動生成される設定にも影響します。サブスクリプションのノードに手動変更を直接加えると、次回の更新で上書きされることがあります。変更を長期間維持したい場合は、クライアントに独立した上書き設定やカスタム設定の仕組みがあるか確認してください。更新後は選択中のノードが残っているか確認し、有効な項目を選び直してから接続テストを行います。ノード数が変わっただけで問題とは限りません。サービス提供元が項目を追加・削除している可能性もあります。有効な設定と実際の接続状況を基準に判断してください。

新しいプロトコルの組み合わせだけをインポートできない場合は、インストーラーのページでクライアントを確認し、そのクライアントが対応する設定方法を調べてください。Androidではまずv2rayNGを使い、該当するコア設定が必要な場合に限ってv2flyNGを検討します。コアの系統が異なると拡張フィールドにも違いがあり、アプリ名を変えるだけで互換性が得られるわけではありません。一般的なインポート方法やサブスクリプションの仕組みはFAQでも確認できます。形式の問題を、すべてのノードが使えない問題と取り違えないようにしましょう。

速度が遅い：接続開始の遅さと転送速度を切り分ける

遅くなる場面を整理してから測定方法を決める

Webページを最初に開くときだけ時間がかかり、表示後は速い場合と、大きなファイルのダウンロードが終始遅い場合は、別の問題として考えます。前者では名前解決、接続の確立、ハンドシェイクを確認します。後者では帯域幅、パケットロス、サーバー負荷、通信制限が関係している可能性があります。バックグラウンドのダウンロード、クラウド同期、動画再生を停止し、ノード、アプリ、テスト用リソースを固定してください。Wi-Fiの電波が不安定な場合はアクセスポイントに近づき、デスクトップでは可能なら有線接続を試します。ローカルのWi-Fi再送をプロキシの性能と混同しないようにしてください。

プロキシなしでアクセスできる同じリソースを基準にしてから、プロキシ経由でアクセスします。リソース側で速度が制限されていれば、通信経路が正常でも出口の性能は判断できません。サイトごとに異なるコンテンツ配信拠点が選ばれることがあり、同じダウンロードURLでも経路が変わる場合があります。1回の測定で分かるのは、その時点のアクセス経路の状態だけです。接続テストの所要時間をダウンロード速度とみなさないでください。接続テストは主にリクエスト確立までの待ち時間を示し、長時間転送時の混雑や安定性までは測れません。

条件を固定し、ノード、ネットワーク、時間帯を比較する

まず同じネットワークで別のノードを試し、次にノードを固定したままネットワークを切り替え、最後に別の時間帯に再測定します。こうすると、サーバー側の出口、ローカルネットワーク、混雑時間帯の負荷を分けて確認できます。特定のノードだけ遅い場合は、そのノードのサーバー状態を確認します。特定のWi-Fiで全ノードが遅い場合は、電波状況、ルーターの負荷、ネットワーク事業者の経路を確認します。すべての端末で同じサイトが遅い場合は、サイト側または共通の出口が原因かもしれません。各回の状況を記録すれば十分です。回線を長時間使い切る必要はありません。

ルーティングルールによっても速度は変わります。本来は直接アクセスできるリソースが遠いプロキシ出口に送られることがあります。また、ページ本体は直接接続されても、画像やAPIはプロキシ経由になると、一部のコンテンツだけ読み込みが止まったように見える場合があります。現在のルーティングモード、ルールの順序、ログに記録された接続先を確認してください。比較のために一時的に単純なルーティング方式を試す場合は、テスト後に元の設定へ戻します。ルールの問題を隠すために常時すべての通信をプロキシ経由にしたり、特定のサイトで速度が上がっただけで全アプリに同じモードが適切だと判断したりしないでください。

TunとMTUを変更するのは、通信の取り込みに原因があると分かった場合だけ

Tunをオフにするとブラウザーの転送が正常になり、オンにすると大きなファイルのダウンロードが止まる場合は、仮想ネットワークアダプター、ほかのVPN、MTUを確認します。MTUが大きすぎると、経路によってはパケットの分割や再送が発生することがありますが、速度低下の原因が常にMTUとは限りません。元の値を記録し、少しずつ変更して同じリソースで再測定してください。安定した改善がなければ元に戻します。MTU、DNS、通信方式、コアを一度に変更すると、改善してもどの変更が効いたのか分からなくなります。

動画、音声、ゲームなどのアプリは、UDPやQUICを使う場合もあります。ある経路でWebのTCP通信が正常でも、UDP転送も正常とは限りません。こうしたサービスだけが遅い場合は、ノードとクライアントの通信取り込み方式が該当するトラフィックに対応しているか、アプリが別の通信方式に自動で切り替えていないか確認してください。ブラウザーの実験機能を一時的にオフにして比較することはできますが、すべてのユーザーに適用できる最適化ではありません。測定結果を追いかけて無関係なシステム設定を変えないでください。

端末のリソース使用量も確認してください。ルールが多い、ログを頻繁に書き込む、接続数が多いといった状況では、性能の低い端末のCPUやストレージがボトルネックになることがあります。調査中は繰り返しの速度測定を止め、不要なデバッグレベルのログを無効にして通常の利用状況を確認してください。システムの保護機能をオフにして速度を上げようとしないでください。プロキシを共有している場合は、ほかの端末が同じ出口を使っていないかも確認します。関連する範囲と待ち受け設定はLAN共有の設定メモを参照してください。サーバー側の混雑が原因と分かった場合、クライアント側の微調整だけでは解消できないことがあります。利用できる別の出口に切り替えるか、時間帯と測定条件を添えてサービス提供元に連絡してください。

DNSの問題：どこで名前解決し、どの経路で問い合わせるか確認する

ドメイン名の名前解決に失敗しても、プロキシサーバーが使えないとは限らない

ログに名前解決の失敗、ホストが見つからない、名前解決の待ち時間が繰り返し記録される場合は、失敗したのがプロキシサーバーのドメイン名か、最終的なアクセス先のドメイン名かを確認してください。前者はプロキシ接続の確立前に起きます。まだ確立していないプロキシを使わないと名前解決できない設定では、依存関係のループが生じる可能性があります。後者の場合は、クライアントのDNS、ルーティングポリシー、対象アプリの名前解決方法を確認します。ブラウザーの読み込みが続いているという見た目だけでは、端末側とリモート側のどちらのDNSに問題があるか判断できません。

Windowsでは、ターミナルで以下のコマンドを実行し、システムのDNSリゾルバーから応答が返るか確認できます。ここでは公開されているドキュメント用ドメインを使い、現在のシステムDNSの基本動作だけを確認します。IPアドレスが返ってもWebサイトにアクセスできるとは限らず、プロキシのコアが同じ経路で名前解決しているとも限りません。システムの問い合わせが成功してもクライアントのログにDNSエラーが出る場合は、コア設定のDNSサーバーアドレス、問い合わせに使うアウトバウンド、ドメインルールを確認してください。ブラウザーの閲覧履歴を何度も消しても、原因の切り分けにはなりません。

nslookup example.com

システム、ブラウザー、クライアントの3層の設定を確認する

システムのネットワーク設定でDNSを開き、自動取得か手動設定かを記録します。次に、ブラウザーでセキュアDNSが有効か、クライアントに独自のDNSが設定されているかを確認します。3つの設定は共存できますが、同じドメインに異なる結果が返ったり、想定した分岐ルールを通らなかったりする原因になります。調査中は経路を1つに絞り、不要な上書きを一時的に無効にしてから再確認してください。その後、設定を1つずつ元に戻します。社内ネットワークや学校のネットワークで内部ドメインを使っている場合は、必要な内部名前解決を維持してください。

暗号化DNSを使う場合は、DNSサービスのアドレス自体にも接続する必要があります。そのアドレスがドメイン名なら、最初に名前解決を行わなければなりません。さらに、その問い合わせもまだ確立していないプロキシ経由にするルールがあると、依存関係のループが起きる可能性があります。この場合はクライアントのドキュメントに沿って、到達可能なブートストラップ用DNSとアウトバウンドを設定してください。DNSサーバーを増やせば必ず信頼性が上がるわけではありません。並列問い合わせやルート選択が適切でないと、結果がどこから返されたのか分かりにくくなります。

問い合わせと接続の関係をルーティングと合わせて確認する

以下はコア設定におけるDNSとルーティングの抜粋です。フィールドの関係を理解するための例であり、そのままクライアントにインポートできる完全なファイルではありません。DNSサーバーの一覧と、必要に応じて名前解決するポリシーを示しています。実際に動作させるには、インバウンド、アウトバウンド、その他の必須設定も必要です。GUIクライアントでは、クライアント側の該当設定を優先して変更してください。自動生成ファイルを直接編集すると、再起動やノード切り替え時に内容が再生成されることがあります。利用できるフィールドはコアごとに確認してください。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

ドメイン名で照合するルールは、名前解決の前に出口を決める場合があります。IPアドレスの集合で照合するルールでは、先にIPアドレスを取得する必要がある場合があります。名前解決の結果、ルールの優先順位、接続先を合わせて確認してください。直接接続で返されたIPアドレスにアクセスできなくても、すぐにDNSの問題だとは判断できません。多くのWebサイトは正しいドメイン名とTLSのサーバー名を必要とするため、IPアドレスを直接入力することは同等のリクエストではありません。対象サービスの仕様を理解したうえで行う場合に限り、アドレス単位のテストが診断に役立ちます。

DNS設定を変更しても、古い結果がシステム、ブラウザー、アプリのキャッシュに残っている場合があります。Windowsでは新しい設定が有効になったことを確認してから、以下のコマンドを実行し、問題のアプリを再起動して新しいリクエストを送信してください。キャッシュを消去すると新しい問い合わせが発生しますが、到達できないDNSサーバーが直るわけではありません。特定のネットワークだけで名前解決に失敗する場合は、そのネットワークのDNSと認証状態を比較します。Tunをオンにしたときだけ失敗する場合は、DNSの取り込み、仮想ネットワークアダプターのルート、ほかのネットワークツールとの競合を重点的に確認してください。

ipconfig /flushdns

システムプロキシが効かない：アプリの接続先と待ち受けアドレスを確認する

まず、クライアントとシステムが同じポートを参照しているか確認する

v2rayNで「システムプロキシを自動設定」を選び、システムのネットワーク設定にあるプロキシ画面を開きます。アドレスがローカルのループバックアドレスか、ポートがクライアントの実際の待ち受けポートと一致しているか確認してください。よく使われるローカルポートに10808がありますが、現在の設定を優先し、ガイドに記載された番号で強制的に上書きしないでください。コアが起動していない、待ち受けポートを別のアプリが使用している、システムに古いポートが残っている場合は、「プロキシが有効なのにアクセスできない」という状態になります。まずローカルの接続口があることを確認し、その後にリモートノードを調べてください。

クライアントの設定では、待ち受け接続口がどのプロキシプロトコルを受け付けるかも確認します。アプリ側でHTTPプロキシを選んでいるのに、接続先がSOCKSしか受け付けない場合や、その逆の場合は、接続がすぐ失敗したり異常な内容が返されたりすることがあります。複数のプロキシプロトコルを受け付ける混合ポートを備えたビルドもありますが、プロトコルごとに別のポートを設定するビルドもあります。ポート番号だけで種類を判断しないでください。LANからの接続を受け付ける設定と、ループバック接続を受け付ける設定も別のものです。通常、同じ端末から使うだけならLANからの接続を許可する必要はありません。

システムプロキシを参照するアプリだけに影響する

ブラウザーはシステムプロキシを参照する場合もあれば、独自のプロキシ設定や拡張機能を使う場合もあります。まずプロキシ拡張機能を一時停止し、ブラウザーの設定でシステム設定を使うようになっているか確認してから、新しいタブでログを確認します。クライアントに該当リクエストが記録されない場合は、通信がローカルの接続口に入っていない可能性があります。コマンドラインツール、ゲーム、一部のデスクトップアプリはシステムプロキシを参照しないことがあります。アプリごとのネットワーク設定を確認してください。ブラウザーが使えるだけで、すべてのアプリがクライアント経由になるとは限りません。

明示的にプロキシを指定したリクエストと、通常のリクエストを比較できます。以下のコマンドは、ローカルの10808ポートがHTTPプロキシを受け付け、コアと選択中のノードが動作していることを前提とします。ポートやプロトコルが異なる場合は、実際の設定に合わせて変更してください。Windows PowerShellでは、コマンド名の別名による違いを避けるため、システム標準のcurl.exeを使います。明示的なリクエストが成功して通常のブラウザー通信が失敗する場合は、システムまたはブラウザーの接続口を確認します。明示的なリクエストも失敗する場合は、待ち受け状態、ノード、名前解決を確認してください。すぐに通信の取り込み範囲を広げないでください。

curl.exe --proxy http://127.0.0.1:10808 --head https://example.com/

システムプロキシ、自動構成スクリプト、Tunを区別する

システムのプロキシ設定には、手動プロキシ、自動構成スクリプト、自動検出が同時に設定されている場合があります。古いスクリプトのURLや他のアプリが書き込んだ設定が残っていると、画面上の想定とは異なる経路が選ばれる可能性があります。まず元の状態を記録し、プロキシ設定を変更する他のツールを停止してから、今回の調査で必要な方式だけを残します。組織のポリシーで管理されている端末では、設定の変更が禁止されていたり、自動的に元に戻ったりする場合があります。その場合は端末の管理者に相談してください。管理上の制限を回避するために、何度も権限を引き上げないでください。

システムプロキシを参照しない通信も取り込む必要がある場合に、Tunを検討します。有効にする前に、通常のプロキシ経由で現在のノードからアクセスできることを確認してください。有効にした後は、仮想ネットワークアダプターが作成されたか、デフォルトルートが変わったか、権限エラーがログに記録されていないか確認します。ほかのVPN、仮想マシンのネットワーク、セキュリティソフトもルートに関与する場合があります。競合が起きたら、関連するアプリを一度に1つずつ停止して比較してください。LANからの接続許可はTunの前提条件ではありません。解決する問題が異なります。

終了する前に「システムプロキシを解除」を選び、システムの設定が元に戻ったか確認します。クライアントが以前クラッシュしていた場合、停止済みのローカルポートをシステムが参照し続けることがあります。残ったプロキシ設定を手動でオフにし、その後クライアントを正常に起動してください。元の設定値は保存しておきます。業務環境で以前からプロキシを使っている場合、項目をすべて削除してはいけません。システムプロキシとルーティングの基本的な違いはクイックスタートで確認できます。クライアントのプラットフォームごとの差を調べる場合はクライアント比較を参照し、異なるシステムの設定をそのままコピーしないでください。

アプリがクラッシュする：まず状況を保存し、設定を切り分ける

画面の終了、コアの終了、バックグラウンドでの停止を区別する

ウィンドウが消えても、プログラムがクラッシュしたとは限りません。タスクトレイに最小化されている場合もあります。画面が表示されたままでも、コアが正常に動作しているとは限りません。まずタスクバー、通知領域、プロセス一覧を確認し、ログに新しいリクエストが記録され続けているか確認してください。フロントエンドは動作しているのにコアが何度も起動して終了する場合は、設定、ポート、権限を重点的に確認します。起動ボタンを押すとアプリ全体が終了する場合は、システムのアプリケーションエラー記録、実行環境、設定の読み込み状態を確認してください。Androidのバックグラウンド停止については次の章を参照し、デスクトップ版の対処をそのまま適用しないでください。

操作の前に自動再起動を停止し、アプリのログとエラー発生時刻前後のシステム記録を保存します。Windowsではイベントビューアーのアプリケーションログ、macOSではシステムのクラッシュレポート、Linuxではデスクトップの起動メッセージとユーザーログを確認できます。記録全体をアップロードする必要はありません。まずエラーが発生したモジュール、終了理由、時刻を確認してください。ログにはサーバーアドレス、ユーザー識別情報、サブスクリプションの認証情報が含まれる場合があります。外部に共有する前にこれらを隠し、エラーの種類と前後関係は残してください。

アーキテクチャ、インストール方法、ファイルの書き込み権限を確認する

インストーラーのページから、OSとプロセッサーのアーキテクチャに合ったクライアントを選択してください。アプリが起動しない場合は、異なる配布元から実行ファイルやコアのファイルを混在させてコピーしないでください。依存関係が合わなくなることがあります。Windowsのデスクトップ版と従来のWPF版は異なるUI方式です。案内に従って該当する起動方法を選んでください。移行する前に元の設定をバックアップします。macOSではチップの種類、Linuxではディストリビューションのパッケージ形式とシステムアーキテクチャを確認してください。ファイルの拡張子だけで適合性を判断しないでください。

アプリのインストール先、ユーザーデータの保存先、ログの保存先に通常の書き込み権限が必要です。読み取り専用の場所、アクセス制限のあるディレクトリ、空き容量不足、同期ソフトによるファイルの占有などが原因で、設定の保存やコアの起動に失敗することがあります。まずエラーに表示されたパスを確認し、自分が書き込める場所にデータを移してください。ディスク全体のアクセス権を緩めないでください。セキュリティソフトにブロックされた場合は、警告内容とファイルの入手元を確認します。保護機能全体を無効にしないでください。組織管理の端末では、管理者のインストール方針に従ってください。

元のデータを消さず、最小構成で再現を試す

完全なバックアップを取ってクライアントを終了し、データディレクトリの説明に従って独立したテスト用設定を作成します。ポータブル版や独立したデータディレクトリに対応している場合は、正式にサポートされた方法を使い、ディレクトリ指定方法を推測しないでください。テスト環境には、動作が確認できている設定を1つだけインポートし、Tun、カスタムルート、追加の上書き設定は一時的にオフにします。最小構成で起動できる場合は、元の設定または追加オプションに原因がある可能性が高いです。最小構成でもクラッシュする場合は、インストール環境、アーキテクチャ、システムのエラー記録を確認します。

元の設定に戻すときは、サブスクリプション、基本的なプロキシ、ルーティング、Tunの順に1つずつ追加し、その都度起動してテストします。特定の追加後にエラーが再現したら、その前後の違いを記録してください。設定の構文エラーは、ログにフィールド名や位置が示されることがあります。JSONを手動編集した場合は、二重引用符、カンマ、フィールドの型を確認します。テキスト置換でファイル一式をまとめて修正しないでください。自動生成ファイルのエラーは、元となる設定もたどって修正してください。そうしないと、次回のノード切り替えで同じエラーが再生成されることがあります。

更新後に初めて問題が起きた場合は、更新前後のUI方式、コアの系統、設定の変更点を記録してください。記憶に頼ってバージョン情報を推測しないでください。問い合わせる際は、OS、プロセッサーのアーキテクチャ、起動方法、再現手順、最小構成でも失敗するかを伝えます。スリープからの復帰後やネットワーク切り替え後に発生した場合は、電源とネットワークの状態変化も補足してください。復旧後は、終了時にシステムプロキシが解除されることを確認します。一部のアプリの問題がシステム全体の通信障害として残らないことを確かめてから、自動起動を再び有効にしてください。

モバイル端末での問題：VPNの許可、バックグラウンド動作、アプリごとのプロキシ

アプリを開いただけでなく、VPN接続が実際に確立しているか確認する

v2rayNGで「接続」を選びます。初回起動時には、システムからVPNの許可を求められます。この許可により、AndroidのVPNサービスを通じて端末の通信を取り込めるようになります。遠隔サーバーへの接続が確立したことを意味するわけではありません。許可した後も、動作通知、アプリのログ、実際のアクセス状況を確認してください。許可を繰り返し求められる場合は、別のVPNアプリが動作していないか、仕事用プロファイルや端末管理ポリシーで制限されていないか確認します。通常、1つのユーザー環境で複数のVPNが同時に通信を取り込もうとすると競合します。ほかの通信取り込みアプリを停止してからテストしてください。

設定のVPNモードとプロキシのみのモードも区別してください。VPNモードではシステムのインターフェースを通じて対象アプリの通信を取り込みます。プロキシのみのモードでは主にローカルのプロキシ接続口を提供するため、各アプリがその接続口を使う必要があります。プロキシのみのモードを誤って選ぶと、クライアント内のテストには成功しても、通常のアプリの通信には影響しないことがあります。現在のモードを記録し、まずVPNモードで基本的なアクセスを確認してから、必要に応じて高度な設定を行ってください。システムで常時接続VPNやVPNを経由しない通信のブロックを設定している場合は、現在使用しているクライアントが対象になっているか確認してください。

画面をロックすると切断される場合は、バッテリーとバックグラウンドの制限を確認する

システム設定の「アプリ」→「v2rayNG」→「バッテリー」を開き、バックグラウンド動作が制限されていないか確認します。端末が提供する設定に応じて、バックグラウンドでの継続動作を許可してください。メーカーによってメニュー名は「バックグラウンド実行」「自動起動」「バッテリー最適化」など異なります。まず、アプリに継続動作中の通知が表示されることを確認してから、画面ロックのテストを行います。通知がオフでもサービスが停止したとは限りませんが、状態を把握しにくくなります。バッテリーの設定、省電力モード、バックグラウンドデータの制限は、接続の維持に直接影響する場合があります。

画面をオンにした状態、画面ロック後、ネットワーク切り替え後の3つの状態を分けて記録してください。しばらく画面をロックした後だけ失敗する場合は、バックグラウンド制限を確認します。Wi-Fiからモバイルデータに切り替えた後だけ失敗する場合は、ネットワークの復帰と既存接続の再確立を確認します。モバイルデータでは常に失敗し、Wi-Fiでは正常な場合は、データセーバー、アプリのモバイルデータ利用許可、そのネットワークの接続状態を確認してください。省電力設定を変更した後は、接続を再起動し、同じ条件で画面ロックのテストを繰り返します。設定が保存されたというだけで、問題が解決したとは判断しないでください。

アプリごとのプロキシでは、リストの対象方向を確認する

v2rayNGの「設定」→「アプリごとのプロキシ」を開き、「選択したアプリのみプロキシを使用する」か「選択したアプリを除外する」かを確認します。2つのリストは対象が逆です。前者では、プロキシを使わせたいアプリを選択する必要があります。後者では、除外したいアプリを選択しません。ブラウザーは使えるのに特定のアプリだけ接続できない場合は、そのアプリがリストに含まれているか、関連するコンポーネントが別のアプリに属していないか確認してください。Webページの遷移、アカウントへのログイン、ダウンロードをシステムコンポーネントが処理することがあります。1つの操作が常に同じアプリ内で完了するとは限りません。

アプリのリストが原因か確認するには、分割アプリプロキシを一時的に無効にし、対象のアプリを基本的な通信の取り込み対象にしてから、VPN接続を停止・再確立してテストします。正常に戻った場合は、リストの対象方向やコンポーネントの範囲を見直してください。引き続き失敗する場合は、アプリ独自のプロキシ、DNS、対象サービス、UDPへの対応を確認します。複数のフィルタールールを同時に有効にして試行錯誤しないでください。ルールが増えるほど、通信が除外された理由を特定しにくくなります。仕事用プロファイルと通常のユーザー環境ではアプリが別々に存在する場合があります。システムが許可する通信の取り込み範囲もそれぞれ確認してください。

ネットワーク切り替え後に接続を再確立し、コアとの互換性を確認する

Wi-Fiとモバイルデータを切り替えると、ローカルアドレス、ルート、到達経路が変わるため、既存の接続がすぐに復旧しないことがあります。いったん接続を停止し、ネットワークが安定するのを待ってから再接続し、接続テストを行ってください。特定のネットワークだけで失敗する場合は、ノードのタイムアウトとDNSの章に戻って確認します。アプリを何度も再インストールする必要はありません。LANアドレスを迂回する設定を有効にした場合は、ローカル端末へのアクセスを別途確認してください。この設定はローカル宛て通信のルートを調整するもので、インターネット上のノードを復旧させる機能ではなく、アプリごとのプロキシの代わりにもなりません。

Androidではまずv2rayNGを使用します。v2flyのコア設定が必要な場合は、具体的な互換性に応じてv2flyNGを選択できます。いずれもAndroid版インストーラーから端末のアーキテクチャに合ったものを選んでください。切り替える前に元のサブスクリプションと必要な設定を保存し、2つのVPNが同時に通信を取り込まないようにします。プロトコルの拡張機能が原因の場合は、高度な設定をすべてコピーするより、サービス提供元に対応するコアを確認するほうが確実です。最後にVPNの許可とバックグラウンド設定のメモを確認し、画面ロック、ネットワーク切り替え、手動停止の3つの状態をテストしてください。接続ボタンを押した直後だけでなく、各状態から復旧することを確認します。