V2Rayのトラブルシューティング

インターネットに接続できない

「クライアントが起動している」ことは、GUIが動作中であることを示すだけです。コアの起動、サーバーへの接続、アプリのプロキシ接続が確立しているとは限りません。まず、プロキシを無効にしてもインターネットに接続できないのか、プロキシを有効にした場合だけ接続できないのか、特定のアプリやサイトだけで問題が起きるのかを切り分けます。原因によって確認箇所は異なります。すぐにプロトコルを変更したり、何度も再インストールしたりしても、原因の特定にはつながらず、正常だった設定を上書きするおそれもあります。

まず基本ネットワークと問題の範囲を確認

v2rayNのトレイメニューでシステムプロキシを解除し、クライアントを終了してから、普段プロキシなしでアクセスできるサイトをブラウザーで開いてください。Wi-Fiに接続されていること、ゲートウェイに到達できること、公衆Wi-Fiのログイン認証が済んでいることも確認します。この状態でもインターネットに接続できない場合は、まずOSのネットワーク、ルーター、または上位ネットワークの問題に対処してください。AndroidではVPNを停止してから、Wi-Fiとモバイルデータ通信をテストします。基礎となるネットワークの切断を、サブスクリプションの問題と誤認しないようにしてください。

基本ネットワークに問題がなければクライアントを再起動し、現在有効なサーバーを1つだけ選んでテストします。プロキシクライアントを複数同時に起動したり、デスクトップのシステムプロキシと別のツールの仮想ネットワークアダプターを同時に有効にしたりしないでください。接続経路が複数あると、リクエストが別々の経路に分かれ、ブラウザーは開くのに他のアプリはタイムアウトする、あるいは特定のプログラムを終了するとシステム全体が突然復旧するといった現象が起こります。

コア、ローカルの待ち受け、アプリの接続先を確認

クライアントのログを開き、まずコアが正常に起動したか、次にアクセス時に新しいログが出るかを確認します。設定の解析エラー、アドレスへのバインド失敗、ポートの使用中などが表示された場合は、まずローカルの起動問題を解決してください。この段階ではリモートサーバーをテストしても意味がありません。コアが正常に動作しているのに、Webページを開いても関連ログがまったく出ない場合は、アプリがシステムプロキシを使っているか、独自のプロキシが設定されていないか、待ち受けポートが一致しているかを確認します。

次のWindowsの例では、ローカルHTTPプロキシを直接指定して、ブラウザーの設定をテスト対象から切り離します。例のポートは10808です。実行前に、設定画面で有効になっているHTTPまたは混合プロキシの待ち受けポートを必ず確認してください。このポートがSOCKS専用の場合は、対応するプロトコルに変更します。接続先は標準的な例示用ドメインであり、すべてのネットワークからアクセスできるとは限りません。

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

ローカルアドレスに接続できない場合は、待ち受けが存在するか確認します。ローカルプロキシに接続した後でリモート側がタイムアウトする場合は、サーバーのタイムアウトに関するトラブルシューティングに進んでください。接続先サイトからHTTPレスポンスが返れば、アクセス拒否や未対応のリクエストメソッドであっても、そのリクエストが応答先に到達したことは分かります。ただし、すべてのサイトやプロトコルが正常であることを示すものではありません。コマンドの終了コードだけで接続経路全体を判断しないでください。

ルーティングの問題と接続の問題を切り分ける

ローカルプロキシのテストで応答があるのにブラウザーからアクセスできない場合は、ブラウザーのプロキシ拡張機能、システムプロキシ、セキュリティソフトのネットワークフィルタリングを確認します。一部のドメインだけで問題が起きる場合は、まず直結ルールとプロキシルールのどちらに一致しているかを確認し、その後DNSを調べます。切り分けのため一時的に明示的なプロキシルートを選び、テスト後に元のルールへ戻してください。DNS、ルーティング、サーバーを同時に変更すると、どの変更が有効だったのか分からなくなります。

最後に、接続を一通り再テストします。直接接続が正常か、ローカルプロキシが応答するか、ブラウザーが想定どおり接続するか、対象ドメインの出口が正しいかを確認してください。どの段階で失敗したかを記録し、該当する章を参照します。特定のサイトだけでアカウント制限、地域制限、サービス上のエラーが表示される場合は、サイトの応答内容に応じて対処してください。クライアントからまったく接続できない状況とは異なるため、設定を何度も切り替えて本当の原因を隠さないようにしましょう。

サーバーへの接続がタイムアウトする

タイムアウトは、ある処理が制限時間内に完了しなかったことを示すもので、サーバーが必ず停止しているという意味ではありません。クライアントがドメイン名の解決、TCP接続、安全なハンドシェイク、またはテスト先からの応答を待っている可能性があります。同じ時間帯のログを保存し、最初に出たエラーを特定してから、その後の連鎖的なエラーを確認します。最後に表示される一般的なタイムアウトは結果にすぎないことが多く、原因を特定する手掛かりは先行する名前解決エラーやハンドシェイクエラーです。

テストの種類と失敗した段階を見分ける

Tcpingは通常、サーバーのアドレスとポートへのTCP接続をテストするもので、認証情報、トランスポート設定、接続先サイトへのアクセスまでは検証しません。実接続の遅延テストでは、プロキシ経由でテスト先にリクエストするため、テスト先の状態にも結果が左右されます。そのため、Tcpingで応答があってWebページを開けなくても矛盾ではありません。逆に、サーバーが通常のICMPリクエストに応答しなくても、プロキシが利用できないとは限りません。

サーバー設定が現在のサブスクリプションに含まれているか確認してください。以前にコピーした単独の設定ではないことを確認します。アドレス、ポート、プロトコルがそろっているか、同じ名前の別グループにある設定を誤って選んでいないかを確認してください。最近サーバー側の設定が変更された場合は、サブスクリプションを再更新するか、必要な設定をすべて指定してサーバー項目を作り直します。アドレスだけを変更して、古いトランスポート設定をそのまま使わないでください。テストの範囲については遅延テストの仕組みもご覧ください。

ログの種類に応じて設定を確認

TLSを使う場合、サーバーアドレスとハンドシェイクに使うサービス名が異なることがあります。画面のアドレス欄の値を、すべての名前欄にそのままコピーしないでください。システムの日付、時刻、タイムゾーンも確認します。時刻がずれていると、証明書の有効期間の判定に影響します。証明書エラーが出た場合は、設定の入手元とサーバー証明書を確認してください。検証を無効にすると接続が復旧したように見えても、認証設定の誤りが残るおそれがあります。

REALITYを使う場合は、サーバー側で指定された公開鍵、短いID、サーバー名、関連するフロー制御設定をまとめて確認します。余分な空白、コピー漏れ、別のサーバーの設定値などが原因で、ポートには到達できてもハンドシェイクに失敗することがあります。必須項目はサーバー側の設定によって異なるため、別の設定項目を参考に値を補わないでください。基本的な用語はREALITYの用語解説をご覧ください。

条件をそろえてネットワークの範囲を絞り込む

同じサーバーへの接続がWi-Fiでは失敗し、モバイルデータ通信では成功する場合は、クライアントをすぐ再インストールするのではなく、ネットワーク経路、名前解決の結果、ゲートウェイのポリシーを優先して比較します。サーバー、プロトコル、接続先を同じにしてテストしてください。ネットワークを切り替えた後は、古い接続が元の経路を使い続けないよう、接続を確立し直します。すべてのサーバーが同時に使えなくなった場合は、PCのファイアウォールでアプリのルールが最近更新されていないかも確認します。

特定のサーバーだけが継続して失敗し、同じグループの他のサーバーは正常な場合、個別の設定またはサーバー側の問題が考えられます。サブスクリプションを更新したうえで、エラー発生時刻、失敗した段階、個人情報を伏せたログを設定提供元に共有してください。サブスクリプションURL全体や認証情報は送らないでください。コアの対応状況を比較する場合は、まずコアの選び方を確認してください。コアの変更は、あらゆるタイムアウトに有効な万能策ではありません。

タイムアウト時間の延長は、応答が遅いかどうかを確認するためだけに使ってください。アドレスの誤り、待ち受けの停止、ハンドシェイク設定の不一致は解決できません。変更するたびに同じテスト先で再テストし、元の結果も記録します。プロキシ接続が確立した後にテストサイトから応答がない場合は、別の利用可能なテスト先でも確認し、テストサービスの障害をサーバー全体の停止と誤認しないようにしてください。

サブスクリプションの更新に失敗する

サブスクリプションの更新は、コンテンツの取得、形式の解析、グループへの書き込みという3段階で行われます。更新に失敗した場合、URLにアクセスできないこともあれば、コンテンツは取得できていても、ログイン画面、エラーページ、非対応形式が返されていることもあります。まず既存のサーバー項目は残してください。グループ全体をすぐ削除すると、現在使える接続手段が失われ、その後の原因調査が難しくなることがあります。

URLとグループ設定を確認

サブスクリプショングループの設定を開き、URLが1行の完全な状態で入力されているか確認します。説明文、引用符、改行、末尾の空白が一緒に貼り付けられていないかも確認してください。サブスクリプションURLには個人用のアクセス情報が含まれることが多いため、パスワードと同様に扱います。公開スクリーンショットやオンライン変換サイトに載せないでください。確認時はURLの構造だけを見て、判断を依頼するために原文をそのまま送らないようにします。支援を依頼する場合は、応答の状態やエラーの種類を伝えてください。

更新対象のグループが、現在表示しているグループと同じか確認します。同じ名前のグループが複数あると、更新しても変化がないように見えることがあります。用途が分かる名前に変更し、一つずつ更新してください。クライアントに有効化、更新URL、フィルターの設定がある場合は、グループが無効になっていないか、フィルターですべての項目が除外されていないかも確認します。グループが空に見えても、ネットワークのリクエストに失敗したとは限りません。

直接接続とプロキシ経由で個別に更新を試す

サブスクリプションURLには、現在の基本ネットワークから直接アクセスできるものと、既存のプロキシ接続が必要なものがあります。クライアントで選べる更新方法をそれぞれ試し、2回のテストではリクエスト経路だけを変更してください。プロキシ経由で更新する場合は、先に利用可能なサーバーを確保します。現在のプロキシが使えない状態で、それを頼りにサブスクリプションを更新しようとすると、自力で復旧できないループに陥ります。

ブラウザーではURLを開けるのにクライアントでは失敗する場合も、すぐにクライアントの異常と決めつけないでください。ブラウザーにはログインCookieが残っている、独自のプロキシを使っている、認証ページへ自動的に移動しているといった可能性があります。クライアントのリクエストには通常、こうした状態は引き継がれません。設定提供元がクライアント用として案内しているURLか確認してください。対話形式のログインが必要なWebページは、クライアントが読み取れるサブスクリプション応答とは異なります。

応答ステータスを確認できる場合、認証エラーには有効なURLの再取得が必要なことがあります。リクエストが多すぎる場合は、連続更新をやめ、サービス提供元の案内に従って時間をおいてから再試行してください。サーバーエラーは、同じ時間帯の他のアクセス結果も踏まえて判断します。すべてのステータスをクライアントのバージョンが古いせいと決めつけたり、ブラウザー拡張機能で繰り返し再試行したりしないでください。サーバーのアクセス制限がさらに強まるおそれがあります。

形式と書き込み結果を確認

よくある形式には、1行ずつ並んだ共有リンク、エンコードされたリンクの一覧、特定のコア向けのネイティブJSONがあります。ファイル拡張子やURLの末尾だけでは、正しい形式かどうかは分かりません。サブスクリプションAPIがリクエストに応じて異なる内容を返す場合もあります。ネイティブ設定を取得した場合は、クライアントに対応した設定インポート機能を使ってください。すべてのJSONを通常のサブスクリプショングループとして更新できるとは限りません。詳しくはサブスクリプション形式と変換をご覧ください。

更新成功と表示されたのにサーバーが追加されない場合は、「すべて」に切り替えるか、リストの検索条件を解除してから、サブスクリプションのフィルター式、対応プロトコル、ログの解析メッセージを確認します。単一サーバーの共有リンクと、繰り返し更新できるサブスクリプションURLは別のものです。リンクのように見えるという理由だけで、単一サーバー用リンクをサブスクリプションURL欄に入力しないでください。違いについては共有リンクとサブスクリプションURLをご覧ください。

URLの有効期限切れや提供元による変更が確認できたら、元のグループでURLを更新し、もう一度更新して項目の変化を確認します。新しいグループを作って比較する場合は、新しい項目で接続できることを確認するまで古いグループを残してください。複数のグループが同時に自動更新されると、原因の特定が難しくなります。問題を解決したら、一時的なフィルターと重複グループを解除し、適切な更新頻度に戻してください。直近で利用できた設定は、安全な場所にバックアップします。

接続できるが速度が遅い

速度の問題は、まず症状を具体的にします。Webページの表示開始が遅いのか、ファイルのダウンロードが遅いのか、動画が頻繁に止まるのか、特定のアプリだけ応答が遅いのかを確認してください。最初の表示には名前解決、接続、ハンドシェイクが関係し、データの継続的な転送は帯域、パケットロス、混雑、サーバー負荷の影響を受けます。症状を混同すると「遅延が小さければダウンロードも速い」という誤った結論につながり、サイト側の速度制限をクライアントの問題と取り違えることもあります。

再現できる条件をそろえて比較

テストでは端末、ネットワーク、サーバー、接続先サイトを固定し、OSの更新、クラウド同期、その他の大容量通信を一時停止します。Wi-Fiの電波が弱い、または同じ周波数帯が混雑している場合は、ルーターに近づくか有線接続で比較してください。直結でも同じ種類のコンテンツが遅い場合は、まずローカルネットワークを確認します。プロキシ経由だけで明らかに遅くなる場合は、プロキシの経路を調べてください。日付やコンテンツが異なるテスト結果を、同じ条件として直接比較することはできません。

すべてのサーバーで同時にダウンロード速度を測定しないでください。同時テストはローカル帯域を奪い合い、サーバーの負荷も増やすため、安定した接続まで不安定に見えることがあります。候補を少数に絞り、同じ順序で一つずつテストし、各テストの間に回復時間を設けます。開始時刻、ネットワークの種類、コンテンツの取得元を記録すれば十分です。一時的な最高速度を、継続して利用できる性能と見なさないでください。

接続の確立と継続的なデータ転送を分けて確認

すべてのWebページで初回表示だけが遅く、表示後の画像やファイルの読み込みが正常な場合は、DNS、ハンドシェイク、接続の再利用、ルーティングルールを確認します。開始直後は速くてもダウンロード速度が徐々に低下する場合は、Wi-Fiの安定性、長時間接続の品質、接続先の速度制限を比較してください。ブラウザーの開発者ツールにある待機時間も参考になりますが、キャッシュ、サイトのスクリプト、外部リソースの影響を受けます。まず構成がシンプルなページで比較してください。

Tcpingで測定するのは、接続処理の比較的早い段階の特性です。実接続の遅延にはより多くのプロキシ処理が含まれ、ダウンロードテストでは継続的な通信が発生します。この3つは互いに置き換えられません。あるサーバーの遅延が高くても、継続的な通信はより安定している場合があります。接続確立が速いサーバーでも、混雑する時間帯には転送速度が制限されることがあります。サーバーを選ぶ際は、一つの数値順に並べるのではなく、実際の用途を基準にしてください。

ルール分岐、複数の接続制御、トランスポート設定を確認

一部のコンテンツだけ遅い場合は、メインページと画像・動画のリソースに同じルーティングが適用されているか確認します。Webページは複数のドメインに同時アクセスすることがあり、一部はプロキシ経由、他は直接接続となる場合があります。クライアントに接続中と表示されても、ページ全体が同じ出口を使っているとは限りません。一時的に統一ルーティングで比較すると原因の切り分けに役立ちます。確認後はルールの順序を修正し、すべての通信を対象とする一時的なルールに依存し続けないでください。

システムプロキシと仮想ネットワークアダプターによる通信制御を同時に有効にする場合は、コア自身の通信が再びプロキシ経由にならないか確認してください。二重の通信制御、誤った上位プロキシ、チェーン設定によって往復が増え、深刻な場合はループが発生します。速度測定のためにすべてのモードを同時に有効にしないでください。通常のブラウザーテストでは、明確な接続方法を一つだけ使います。システムプロキシに従わないアプリが必要な場合は、仮想ネットワークアダプターのモードを個別に検証してください。

トランスポート設定はサーバー側の設定と一致させる必要があります。多重化をむやみに有効にしたり、トランスポートプロトコルを変更したり、他人の接続設定をそのまま使ったりしても、帯域が自動的に増えるわけではありません。互換性の問題が起きる場合もあります。パケットサイズが経路上の問題に関係していると考えられる場合は、症状とネットワーク環境に基づいて段階的にテストし、元の値を記録したうえで一度に一項目だけ変更します。根拠がないまま、システムのネットワーク「最適化」設定を一式コピーしないでください。

最後に、調整できる項目と外部要因を区別します。クライアントでは誤ったルーティング、名前解決、通信制御の設定は修正できますが、サーバーの負荷、接続先サイトのポリシー、上位ネットワークが常に同じ状態とは限りません。条件を固定した複数回のテストで同じリモート経路に問題があると分かった場合は、発生時刻と症状を設定提供元に伝えてください。一時的なテスト設定をすべて元に戻し、速度測定を続けるのではなく、普段使うアプリで安定性を確認します。

DNSとドメイン名の解決

DNSの問題は、ドメイン名にアクセスできない、同じサービスへの接続が不安定、または接続前にログで名前解決エラーが表示されるといった形で現れます。サーバーのドメイン名と接続先サイトのドメイン名は、別々に考える必要があります。前者はクライアントがプロキシサーバーを見つけるために使い、後者はリクエストが接続先に届く経路を決めます。異なるリゾルバーやルーティングが使われる場合があるため、システムDNSを一つ変更しただけで、すべての名前解決が変わったとは限りません。

まず、どの層で名前解決が行われるかを確認

サーバーアドレスにドメイン名を指定した場合、接続を確立する前に利用可能なIPアドレスを取得する必要があります。この段階で必要な名前解決自体がプロキシ接続に依存していると、起動時に依存関係のループが発生することがあります。まず基本ネットワークでサーバーのドメイン名を解決できることを確認し、その後クライアントのDNS設定で使われる初期経路を調べてください。サーバーのドメイン名を、適当に調べたIPアドレスに置き換えないでください。サーバー側で動的アドレスを使っている場合や、正しいハンドシェイク名が必要な場合があります。

接続先のドメイン名は、アプリ、ローカルシステム、プロキシコアのいずれかで解決されることがあります。どの段階で解決するかは、アプリのプロキシプロトコルとクライアントの設定によって異なります。SOCKSリクエストにも、ローカルで名前解決する方法とプロキシ側に委ねる方法があります。そのため、ブラウザーでアクセスできてもコマンドラインツールが同じ方法を使うとは限りません。調査時にはHTTPプロキシ、SOCKSプロキシ、仮想ネットワークアダプターのどれを使っているか記録し、ログで名前がどの段階でIPアドレスに変換されたか確認してください。

システムコマンドを使って基本的な名前解決の結果を確認できますが、これはシステムの名前解決経路を検証するだけで、コアが最終的に取得する結果を示すものではありません。次のコマンドでは例示用ドメイン名を使用しています。実際のトラブルを調べる場合は問題のある公開ドメイン名に置き換え、アカウントやアクセス情報を含むURL全体をコマンドに貼り付けないでください。結果を確認するときは、複数のアドレスファミリーのアドレスが返されていないかにも注意します。

nslookup example.com

暗号化DNS、アドレスファミリー、キャッシュを確認

ブラウザーのセキュアDNS設定によって、システムリゾルバーを経由しない場合があります。クライアント側で暗号化DNSが個別に設定されていることもあります。比較しやすいテスト経路を作るには、一時的にブラウザーをシステム設定に従わせ、問題が変化するか確認してください。テスト後は必要な設定に戻します。DNSサーバーに到達できるかどうかと、返されたアドレスが接続に適しているかどうかは別の問題です。DNSサーバーが応答しないときに、DNSアドレスを次々と変更してもルーティングの問題は解決しないことがあります。

ドメイン名からIPv4とIPv6の両方のアドレスが返されても、現在のネットワークで両方のアドレスファミリーに到達できるとは限りません。ログで到達できないアドレスファミリーへの接続が繰り返されている場合は、システムのネットワーク状態とクライアントの名前解決ポリシーを比較します。原因の切り分けのために一時的に一方のアドレスファミリーを制限することはできますが、すべての端末で一律に無効化し続けないでください。最終的な設定は、実際に利用できるネットワークとサーバーの対応状況に合わせます。

DNS設定を変更しても、古い結果がブラウザー、システム、コアのキャッシュに残ることがあります。古いタブを閉じるか関連アプリを再起動し、必要に応じてクライアントを再起動してから、同じドメインで再テストしてください。Windowsでは次のコマンドでシステムの名前解決キャッシュを消去できますが、すべてのアプリのキャッシュが消えるわけではなく、上位リゾルバーの誤りも修正されません。問題のある経路を調べず、キャッシュの消去を繰り返して済ませないでください。

ipconfig /flushdns

DNSの経路とルーティングを一致させる

直接接続とプロキシ経由の通信では、適した名前解決経路が異なる場合があります。直接接続用のリクエストで別のネットワーク出口にしか適さないアドレスが返されると、接続に失敗したり遅くなったりします。リモートでの名前解決リクエストが到達できない出口に送られても、タイムアウトが発生します。返されたアドレスだけでなく、DNSリクエスト自体がどの経路から送信されるかも確認してください。

仮想ネットワークアダプターのモードでは、システムDNSがクライアントの想定どおりに制御されているか、別のVPNが同じ設定を書き換えていないかも確認します。仮想アドレスのマッピングなどを有効にしている場合は、名前解決とその後の接続を対応するルールで処理してください。一方の設定だけをコピーしても機能しません。通常のサブスクリプションインポートを使っている場合は、クライアントの画面から確認してください。自動生成される実行設定を直接編集しないようにしましょう。

修正後は少なくとも3点を確認します。サーバーのドメイン名を解決できること、接続先ドメインから応答があること、実際のアクセスが想定したルートを通ることです。特定のドメインだけで問題が続く場合は、そのドメインの権威DNSレコードの変更、サイトの状態、異なるネットワークでの結果を比較し、必要に応じて個別ルールを設定します。DNSはあらゆる接続エラーを解決する設定ではありません。名前解決後にもポート、ハンドシェイク、接続先サービスの問題が残る場合があります。

システムプロキシが機能しない

システムプロキシは、OSがアプリに提供するプロキシ設定であり、すべての通信を強制的に転送するものではありません。ブラウザーは通常この設定に従いますが、一部のターミナルツール、ゲーム、独自のネットワーク機能を持つアプリは自動的に利用しません。そのため「ブラウザーは正常だが、特定のアプリは接続できない」場合は、まずそのアプリの接続方法を確認してください。ルーティングをグローバルに切り替えても、クライアントに入っていないリクエストは処理できません。

待ち受けポートとシステム設定の対応を確認

v2rayNの設定でローカルの待ち受けアドレス、ポート、対応するプロキシプロトコルを確認し、システムプロキシの設定と照合します。ポートは設定によって異なるため、ガイドにある例を現在の端末の固定値として扱わないでください。通常、端末上のアプリはループバックアドレスに接続します。別の端末のアドレスやリモートサーバーのポートを指定すると、システム設定が有効に見えてもローカルの接続先には到達できません。

次のWindows PowerShellコマンドで、例示ポートがTCP待ち受け中か確認できます。出力がない場合は、クライアントのコアが起動しているか、ポートが実際の設定と一致しているかを確認してください。出力がある場合は、さらに該当プロセスを確認できます。待ち受けが存在することは、何らかのプログラムがそのポートを使用していることを示すだけです。目的のプロキシであることや、リモートサーバーが使えることまでは証明しません。

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

別のプログラムがポートを使用している場合は、用途を確認してから競合するプログラムを終了するか、クライアントの待ち受けポートを変更し、アプリ側のプロキシ設定も合わせて更新します。クライアントだけ変更して、システム側に古いポートを残さないでください。また、ローカルからアクセスするためだけに、待ち受けアドレスをすべてのネットワークインターフェイスに広げないようにしましょう。LANからの接続許可には追加のセキュリティ上の考慮が必要です。端末内のシステムプロキシを修復することとは別の問題です。

手動プロキシ、自動設定、アプリ独自の設定を区別

手動プロキシと自動設定スクリプトは別の仕組みです。システム画面に両方の設定が残っている場合もあります。クライアントのモード名が、OSの特定の設定スイッチとそのまま対応するとは限りません。実際に設定されたアドレス、ポート、スクリプトのURLを確認してください。モードを切り替えた後はテスト対象のアプリを終了して再起動します。既存の直接接続をプロセスが再利用していると、設定が反映されていないように見えることがあります。

ブラウザー拡張機能、企業ポリシー、アプリ独自のプロキシ設定が、システム設定より優先される場合があります。まずプロキシ関連の拡張機能を無効にして比較し、アプリが「プロキシを使用しない」設定や別の固定アドレスになっていないか確認してください。コマンドラインツールにはシステムプロキシではなく環境変数を参照するものがあり、Windowsの一部機能も独自のプロキシ設定を使います。トレイのスイッチ一つですべての環境が変更されるとは限りません。

終了後に残る設定と仮想ネットワークアダプターによる通信制御を確認

クライアントが異常終了すると、システムプロキシの設定だけが残り、停止したローカルアドレスを参照し続けることがあります。その結果、クライアントを終了した後にすべてのWebページが開けなくなることがあります。システム設定で残っているプロキシを一時的に無効にし、直接接続が復旧するか確認してから、クライアントを起動して設定し直してください。ネットワークアダプターを削除したり、システム全体のネットワークをリセットしたりする必要はありません。残ったアドレスだけの問題に破壊的な操作を行わないでください。

システムプロキシを使わないアプリの通信を制御する必要がある場合は、クライアントのドキュメントを確認して仮想ネットワークアダプターのモードを検討します。このモードでは、権限、ルーティング、DNSの制御が必要になることがあります。有効にする前に、通常のローカルプロキシ接続が動作することを確認し、その後個別にテストしてください。権限の昇格をシステムプロキシのあらゆる問題に対する解決策と見なさないでください。明確な権限エラーがある場合や、通信制御が必要な場合に限り、対応する権限を設定します。

最後に設定と通信の両方を確認します。システム画面に正しいアドレスが表示されること、クライアントのポートが実際に待ち受けていること、アプリからのリクエスト時にログが出ること、接続先へのアクセスが想定どおり完了することを確認してください。トレイメニューにチェックが表示されるだけでは、これらすべてを確認したことにはなりません。確認後にクライアントを終了し、システム設定が想定どおり元に戻るか調べます。次回の起動前に設定が残り、同じ症状が起こるのを防げます。

クライアントがクラッシュする・起動しない

起動時の問題は、GUIが開かない、GUIは開くがコアが終了する、しばらく動作した後にプログラム全体が終了する、の3つに分けて考えます。それぞれ、GUIの実行環境、生成された設定やコアのネットワークプロセス、システムリソースやバックグラウンドソフトウェアなど、問題の層が異なります。起動直後に終了する、サブスクリプション更新後に終了する、仮想ネットワークアダプターを有効にすると終了するといった、発生時の操作を記録し、該当時刻のログを確認してください。「使えない」とだけ記録しても原因の特定には不十分です。

パッケージ、権限、実行環境を先に確認

クライアントのダウンロードページでOSとプロセッサに合ったパッケージを選んでください。Windowsのデスクトップ版と従来のWPF版では使用するUI技術が異なり、必要な実行環境はパッケージの案内によって変わります。すべてのパッケージに同じ実行環境が必要とは限りません。macOSではApple Silicon版とIntel版を区別します。Linuxではプロセッサのアーキテクチャとディストリビューションのパッケージ形式も確認してください。アーキテクチャの不一致を設定の破損と誤認しないようにしましょう。

展開が必要なファイルを使う場合は、書き込み権限のある場所にすべて展開してから実行してください。圧縮ファイルのプレビュー画面から直接起動しないでください。依存ファイルとメインプログラムが想定したディレクトリにあること、クリーンアップツールによって作業フォルダーが移動されていないことを確認します。インストールや初回起動をシステムのセキュリティ機能がブロックした場合は、表示された具体的な理由を確認し、OSが用意するアプリの許可手順に従ってください。端末全体の保護機能を無効にしないでください。

実行環境がないという明確なメッセージが表示された場合は、OSのアーキテクチャと必要なコンポーネントを確認します。ファイルにアクセスできない場合は、フォルダーの権限、ディスク容量、設定ファイルが他のプログラムに使用されていないかを確認してください。プログラム一式をクラウド同期フォルダーに置くと、ファイルロックや同期の競合が起きることがあります。調査用に通常のローカルフォルダーへコピーして試す場合も、元のフォルダーは残してください。同じ設定に書き込む複数のインスタンスを同時に起動しないようにしましょう。

GUIの問題とコア設定の誤りを切り分ける

GUIが動いたままコアだけが繰り返し終了する場合は、対応していないフィールド、無効なプロトコルの組み合わせ、ポートの競合、ルールファイルの不足などがログに記録されていないか確認します。カスタム設定、ルーティング、DNSを最近有効にした場合は、まずその変更を元に戻してください。通常のサブスクリプションユーザーが、自動生成された実行設定を直接編集するのは避けましょう。次に設定を適用したときに上書きされる場合があり、GUIの状態と実際の設定が食い違うおそれもあります。

ネイティブJSONの構文を調べる必要がある場合、次はオブジェクト、配列、カンマ、真偽値の書き方を確認するための有効な最小限のJSON例です。プロキシ接続を確立できる完全なコア設定ではありません。末尾の余分なカンマ、日本語の句読点、文字列の引用符に注意してください。構文が正しくても、その中のプロトコル設定が現在のコアに対応しているとは限りません。

{
  "log": {
    "loglevel": "warning"
  }
}

コアの互換性を調べる場合は、まずサーバー設定が必要とするプロトコル機能を確認し、クライアントで実際に使われているコアと比較します。v2rayNGとv2flyNGではコアの系統が異なるため、アプリ名を変えるだけで設定が必ず互換になるわけではありません。詳しくはXrayとV2Flyのコアの違いをご覧ください。出所が不明なコアファイルをクライアントのフォルダーに上書きしないでください。

設定を分けて破損の有無を確認

ユーザー設定の破損が疑われる場合は、すべてのインスタンスを終了し、設定、サブスクリプショングループ、カスタムルールをバックアップしてから、クライアントが対応する方法で新しいユーザー設定ディレクトリを使ってテストします。元のディレクトリを直接削除しないでください。新しい設定で起動できた場合は、古い設定や拡張設定が原因である可能性があります。サブスクリプション、ルーティング、その他の設定を少しずつ戻し、どの段階で再発するか確認します。古い内容を一度にすべて戻さないでください。

新しい設定でも終了が再現する場合は、システムイベントの記録、空き容量、メモリ不足、セキュリティソフトによるブロックを確認してください。Linuxデスクトップではグラフィカルセッションとパッケージの依存関係、macOSではシステムの許可に関するメッセージも確認します。発生条件に関する情報を集めてから、更新や再インストールを検討してください。上書きインストールでは破損したユーザー設定が削除されないことがあるため、再インストール後も失敗するからといって、すぐソフトウェア自体の異常と判断しないでください。

動作が復旧したら、まず既知の設定を一つ使って通常のプロキシ接続を確認し、その後複雑な機能を段階的に戻します。再現手順、エラーの原文、確認済みの項目を記録しておくと、インストーラーを次々と試すより原因を特定しやすくなります。初回インストールについてはデスクトップ版の初回インストールと初期設定をご覧ください。この章では異常時の対処を説明しており、通常のインストール手順を置き換えるものではありません。

Androidで接続できない・バックグラウンドで切断される

Androidでよくある接続問題の確認には、まずv2rayNGを使います。V2Flyコアの機能が必要な場合は、v2flyNGの利用を検討してください。どちらのアプリでも、サーバー設定とシステムVPNの接続経路を区別する必要があります。ステータスバーにVPNアイコンが表示されても、システムのVPN経路が確立したことを示すだけで、サーバーとのハンドシェイクが成功したとは限りません。アイコンが正常なのにアクセスできない場合は、ローカルでの通信制御、サーバー接続、ルーティング、DNSの順に確認してください。

VPNの許可とネットワーク状態を確認

初めて接続するとき、システムからVPN接続の許可を求められます。誤って拒否した場合は、もう一度接続を開始し、システムの案内に従って許可してください。仕事用プロファイルや端末管理ポリシーで制限されている端末では、該当する管理ルールに従う必要があります。許可の問題を解決するためにアプリのデータを繰り返し消去しないでください。サブスクリプションやカスタム設定も同時に削除されます。別のVPNアプリを停止し、現在の設定が別のVPN接続に置き換えられていないか確認します。

公衆Wi-Fiでは、最初にログイン認証ページへのアクセスが必要な場合があります。VPN接続の前にプロキシを停止してネットワークにログインし、その後接続し直してください。Wi-Fiからモバイルデータ通信に切り替えた後、古い接続がタイムアウトを待ち続けることがあります。いったん停止して再接続し、新しいネットワークが使われているかログを確認します。一方のネットワークでだけ失敗する場合は、同じサーバーと設定で比較してください。ネットワークとサーバーを同時に切り替えると、原因を判断できなくなります。

Androidの「常時接続VPN」と「VPNを使用しない接続をブロック」は、アプリの画面とは別のシステム設定です。VPNを経由しない通信をブロックする設定が有効な場合、VPN未接続時に一部の通信がシステムポリシーによって遮断されることがあります。「クライアントを停止しても接続できない」場合も、基本ネットワークの故障とは限りません。まずシステムのVPNポリシーを確認し、用途に合わせて設定を戻してください。端末を再起動するだけで原因を回避しようとしないでください。

アプリ別プロキシとDNSをあわせて確認

アプリ別プロキシを有効にした場合、選択したアプリだけをプロキシ経由にするのか、選択したアプリを除外するのかを確認してください。2つのリストは意味が逆です。テストに使うブラウザーが想定したリストに含まれていないと、クライアントをまったく経由しない場合があります。リストを変更した後はVPNを接続し直し、テストするアプリを完全に終了してから再起動してください。リストでアプリのアイコンにチェックがあるだけで、プロキシを使用していると判断しないでください。

特定のアプリだけが失敗する場合は、別のコンポーネントからリクエストを送信していないか、独自のプロキシやセキュアDNS設定がないか確認します。メインアプリと関連コンポーネントが別々の接続経路を使い、ログインはできるのにコンテンツを読み込めない場合があります。まずプロキシ対象であることを確認したブラウザーで基準となる接続をテストし、その後アプリを一つずつ追加します。Androidの設定手順はv2rayNGの使い方をご覧ください。

ローカルDNSやトラフィックのスニッフィングを有効にしても、すべてのアプリの問題が自動的に解決するわけではありません。スニッフィングはルーティング時にドメイン名を識別するのに役立つことがありますが、アプリの内容を復号する機能ではなく、適切なDNSやプロトコル設定の代わりにもなりません。ドメイン関連のエラーが起きる場合は、DNSの章を参考に名前解決が行われる場所を確認し、一度に一項目だけ変更してください。サーバー設定は引き続き必要な項目をすべて照合します。デスクトップのスクリーンショットを参考に、任意のフィールドを追加しないでください。

バックグラウンドで切断される場合は電池とプロセスの制限を確認

画面ロック後に切断され、アプリに戻ると復旧する場合は、バッテリー最適化、バックグラウンド動作の制限、データセーバー、メーカー独自の自動起動管理を確認してください。システムのアプリ設定で必要なバックグラウンド動作を許可し、クライアントが必要とするフォアグラウンドサービスの通知も維持します。設定画面の項目名は端末によって異なるため、実際の画面に従って探してください。一つのクライアントのために、すべてのアプリの電池管理を無効にする必要はありません。

バックグラウンド動作を許可しても切断される場合は、ネットワーク切り替え後、長時間のアイドル後、システムによるメモリ解放後のどのタイミングで発生するか記録してください。画面を点灯したままテストして、ネットワークのアイドル時の切断とプロセスの終了を切り分けます。ログの書き込み停止、VPNアイコンの消失、サーバーへの再接続失敗は、それぞれ異なる手掛かりです。別々に記録してください。再接続の頻度を上げるだけでは、電池を消耗する一方、システムによるプロセスの終了は解決しません。

再インストールが必要な場合は、サブスクリプションとカスタムルールをバックアップしてから、Androidのダウンロードページでプロセッサに合ったパッケージを選んでください。インストールパッケージの変更とプロトコル設定の変更を同時に行わないでください。最終テストでは、アプリを開いた状態でのアクセス、画面ロック後の復旧、Wi-Fiとモバイルデータ通信の切り替えを確認します。それでも失敗する場合は、端末のOS、アプリ名、再現手順、個人情報を伏せたログをまとめ、該当するトラブルの章に戻って原因を絞り込んでください。