V2Ray トラブルシューティングガイド

インターネットに接続できない：まず障害箇所を切り分ける

「クライアントが接続済み」と表示されても、通常はプロキシサービスが起動したことを示すだけで、すべてのサイトにアクセスできるとは限りません。リクエストは、アプリのプロキシ設定、ローカルの待ち受け、ルーティング、名前解決、サーバーへの接続、接続先サイトを経由します。どこか一つでも失敗すれば、ブラウザーが読み込み中のままになることがあります。まず、すべてのアプリで失敗するのか、ブラウザーだけか、特定のサイトだけかを確認してください。症状の範囲によって優先して確認する設定は異なります。すぐに再インストールしたり、ノードを何度も変更したりするのは避けましょう。

クライアントの停止時と起動時を比較する

v2rayNでは、まずシステムプロキシを解除してからプロキシサービスを停止します。仮想NICモードを有効にしている場合は、それも個別に無効にしてください。AndroidではVPN接続を停止します。その状態で、普段直接アクセスできるサイトを開き、現在のネットワークでログイン認証が必要か確認してください。学校、ホテル、公共のWi-Fiでは、先に認証を完了する必要があります。プロキシを起動しても、ネットワークへのログインの代わりにはなりません。停止中もアクセスできない場合は、Wi-Fi接続、ゲートウェイ、ネットワークアカウントを先に確認してから、クライアントの診断に戻ってください。

基本ネットワークが復旧したら、クライアントを起動して、設定が正しくそろったサーバーを一つ選びます。ログに設定の読み込み失敗、待ち受け失敗、プロセス終了の記録がないか確認してください。v2rayNのウィンドウが表示されていても、コアのプロセスが動き続けているとは限りません。Androidの通知欄にサービス通知が表示されても、実際にアクセスできるかどうかの確認にはなりません。起動直後にログエラーが出る場合は、まずローカルサービスを確認し、サイトを次々に試す必要はありません。サービスが安定して動作してから、アクセス結果を比較してください。

アプリの通信がプロキシに入っているか確認する

デスクトップでは、システムプロキシを有効にし、システムプロキシに従うブラウザーで固定のページを開きながら、アクセスログを確認します。新しいリクエストがまったく記録されない場合は、ブラウザーの設定、プロキシ拡張機能、アプリ独自の接続方法に問題がある可能性があります。ログにリクエストが記録されて接続エラーになる場合、入口はおおむね機能しているため、次にプロキシの出側を確認します。Androidではアプリごとの設定も確認してください。除外されたアプリはVPNを経由しないため、ほかのアプリがプロキシを使えていても、そのアプリは直接接続のままになることがあります。

ルーティングの影響を切り分けるには、テストする通信をプロキシ経由にするルールモードへ一時的に切り替え、同じページにアクセスします。一部のクライアントでは「グローバル」はルーティングの選択を指し、システムの通信を取り込む設定ではありません。通信がクライアントに入っていなければ、ルーティングを変えても効果はありません。テスト用のモードでアクセスでき、通常のモードで失敗する場合は、ドメインルール、ルールの順序、デフォルトの出口を確認してください。テスト後は通常のルールに戻し、一時的な診断設定をそのまま使い続けないようにしましょう。

最小構成で動作を確認する

以前は接続できていた場合、すべての設定を一度にリセットするのではなく、直近の変更を優先して元に戻してください。追加したルーティング、DNS、仮想NIC、ブラウザー拡張機能を一つずつ無効にしてテストします。どの手順でアクセスが復旧したかを記録し、該当する設定だけを再構成してください。新しいサブスクリプションを追加したばかりの場合も、古いグループをすぐに削除しないでください。以前の設定と比較することで、クライアント共通の設定変更か、新しいサーバーのパラメーター変更かを判断しやすくなります。

復旧の確認では、ページの本文が読み込まれること、ブラウザーを再起動してもアクセスできること、クライアント停止後にネットワークが想定どおりの状態へ戻ることを確認します。一度アクセスに成功しただけでは、完全に復旧したとは判断できません。初期状態から設定し直す場合は、サブスクリプションの追加と初回接続ガイドを参照してください。用語や設定の違いはよくある質問で確認できます。システムプロキシ、ルーティングモード、コアの起動を同じ設定として扱わないようにしましょう。

ノードがタイムアウトする：接続とハンドシェイクを切り分ける

タイムアウトは、ある段階で所定の時間内に応答がなかったことを示します。それだけでサーバーが停止しているとは判断できません。クライアントのテスト機能は、TCP接続を測定する場合も、プロキシ経由でテスト用URLにアクセスする場合もあり、結果の意味は異なります。ポートに接続できても、その後の認証や通信で失敗することがあります。テスト用URLが一時的に使えず、正常な設定がタイムアウトと判定される場合もあります。実際のアクセスとログの段階を併せて確認し、一覧のテスト結果だけを根拠に設定を削除しないでください。

サーバー設定と端末の時刻を確認する

使用中のサーバーの編集画面を開き、アドレス、ポート、プロトコル、通信方式、安全設定が同じ設定情報に基づいているか確認してください。コピー時に空白が混入したり、サブスクリプションURLをサーバーアドレス欄に貼り付けたりすることがあります。特に指定がない限り、アドレス欄にウェブページのパスやプロトコルの接頭辞を含めないでください。ポート、ユーザーID、パスワードは設定の提供元が示す値を使用し、ほかの項目から推測しないようにします。サブスクリプション更新後は、現在選択している項目が有効かどうかも確認してください。

次に、OSの日付、時刻、タイムゾーンを確認します。時刻が大きくずれていると、証明書の検証や一部プロトコルの認証に影響することがあります。OSの自動時刻設定を有効にし、プロキシサービスを再起動して同じリクエストを再現してください。ログに証明書の有効期間前または期限切れと表示される場合は、端末の時刻の異常か、サーバー証明書の問題かを切り分けます。エラーを隠すために証明書の検証を無効にしないでください。安全性が低下するうえ、サーバー名や接続先アドレスの誤りも解決しません。

ログに示された失敗段階に応じて対処する

接続拒否は、接続先が要求を拒否したか、対象ポートでサービスが待ち受けていないことを示す場合がほとんどです。ネットワーク到達不能の場合は、端末のネットワーク、アドレスファミリー、ルーティングを確認してください。長時間待った後のタイムアウトは、経路上のパケットロス、サーバーの無応答、端末のセキュリティソフトによる遮断などが考えられます。TLSハンドシェイクまで進んでいる場合は、サーバー名、安全性の種類、通信パラメーターを重点的に確認します。エラーメッセージはコアによって異なるため、判断時は前後を含むログを残し、末尾の英単語だけで結論を出さないでください。

VLESSとREALITYでは、公鍵、Short ID、サーバー名、項目で指定されているその他のフィールドも確認してください。WebSocketではパスとHost、gRPCではサービス名を確認します。これらは任意の装飾項目ではなく、同じアドレスとポートでも設定が同一とは限りません。サブスクリプションの変換によってフィールドが欠落する場合は、ネット上で見つけたパラメーターの組み合わせを試すのではなく、完全な設定を再取得してください。

ネットワークと設定を組み合わせて比較する

サーバー、接続先ページ、クライアント設定を同じにしたまま、利用可能な2種類のネットワークでテストします。一方のネットワークだけで失敗する場合は、そのネットワークの名前解決、アドレスファミリー、認証、接続経路を確認してください。すべてのネットワークで失敗し、ほかの項目は正常な場合は、現在のサーバーまたはそのパラメーターを重点的に確認します。反対に、同じ端末ですべての項目が失敗し、別の端末では正常な場合は、すべてのサーバーが同時に故障したと考えるのではなく、端末のプロキシ設定、時刻、コアの状態、セキュリティソフトを優先して確認してください。

プロトコルの対応状況は、使用中のコアとクライアントが設定を生成する方法にも左右されます。インポートできたとしても、クライアントがリンクを認識したことを示すだけで、選択中のコアがすべてのフィールドを処理できるとは限りません。コアを切り替える前に、その項目で必要なプロトコルと通信方式に対応しているか確認し、現在の設定を残したまま同じリクエストで検証してください。コアの系統と設定の互換性については、XrayコアとV2Flyコアの違いを参照してください。切り替えに失敗した場合は元に戻し、状態が不明なまま変更を重ねないでください。

設定の提供元に問い合わせる場合は、接続とハンドシェイクのどちらで失敗するか、特定のネットワークだけで発生するか、ほかの項目は使えるかを伝えてください。共有するのは個人情報を除いたエラーメッセージにとどめ、サブスクリプション全体やアカウント情報は公開しないでください。復旧後は、実際のページへのアクセスと再接続をもう一度試し、一時的な成功ではないことを確認します。リストのテスト結果は参考情報として扱い、それだけで結論を出さないでください。

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

サブスクリプションの更新には、内容の取得、解析、グループへの登録という少なくとも3つの段階があります。ダウンロードできない場合はURLやネットワークの問題が考えられます。取得できても項目が追加されない場合は、返された内容がクライアントの形式に合っていない可能性があります。更新後に項目が表示されても接続できない場合は、サーバー設定の問題として調べてください。状況を切り分ければ、グループを何度も削除して情報を失うことを避けられます。作業前にグループ名、更新方法、エラー発生時刻を記録し、まだ使える古い設定を残してください。

URLが現在もサブスクリプション用か確認する

サブスクリプションURLをコピーし直す際は、末尾のパラメーターが欠けていないか、チャットアプリによって空白、改行、句読点が挿入されていないか確認してください。サブスクリプション用のURLとアカウントのログインページは別物です。ブラウザーで開けても、ログインページをサブスクリプションとして直接インポートすることはできません。URLによっては有効なアカウント状態や認証パラメーターが必要です。アカウントの期限切れ、URLの再発行、データ使用量の変化などによって、返される内容が変わることがあります。状態は元の管理画面で確認し、見知らぬオンライン変換サイトにURLを入力しないでください。

エラーコードは原因の範囲を絞る参考になりますが、過度に断定しないようにしましょう。未認証やアクセス拒否は権限や接続元の制限、リソースが見つからない場合はURLの変更が考えられます。サーバーエラーなら時間をおいて再試行が必要なこともあります。成功ステータスが返っても、設定が取得できたとは限りません。実際にはログインページ、認証案内、メンテナンスページが返されている場合があります。クライアントのログでHTMLの解析エラーが出る場合は、まずリクエストの接続先を確認してください。この段階ではコアはまだ処理に関与していないため、すぐにコアを変更する必要はありません。

サブスクリプション更新の通信経路を確認する

サブスクリプションの取得は直接接続で行う場合と、既存のプロキシを経由する場合があり、更新方法はクライアントによって異なります。現在のネットワークからURLへ直接アクセスできる場合は、まず直接更新を試してください。プロキシ経由が必要な場合は、先に動作する設定を一つ用意する必要があります。すべての設定が無効なのに、それらの設定を使ってサブスクリプションを更新しようとすると、処理が循環してしまいます。その場合はURLにアクセスできるネットワークを使うか、従来の管理経路から有効な設定を取得してください。更新ボタンを何度も押して状態が変わるのを待つのは避けましょう。

プロキシ経由で更新する場合は、選択中のサーバーで通常のウェブページを開けることと、ローカルの待ち受けポートが変更されていないことを確認してください。環境によっては、サブスクリプションのリクエストにネットワーク認証ページが返されることもあります。そのため、ほかのサイトをブラウザーで開けても問題がないとは限りません。同じURLを使い、直接更新とプロキシ経由の更新をそれぞれ試して、成功する経路を確認してください。両方失敗する場合は、アカウントの状態とサーバーの応答を調べ、通信経路の問題を形式の破損と取り違えないようにしましょう。

解析後にグループとフィルターを確認する

更新が完了したのに一覧が空に見える場合は、まず検索欄と種類のフィルターを解除し、該当するグループを選択してください。クライアントによっては前回選択したグループが記憶され、新しい項目が別のグループに追加されて表示されないことがあります。更新後に項目数が変わった場合は、別名、アドレス、プロトコルを比較し、並び順だけで項目が消えたと判断しないでください。提供元が内容を変更すると、古い項目が置き換えられたり、一覧の順序が変わったりすることがあります。選択中のサーバーを改めて確認してください。

形式の互換性に問題がある場合は、元のデータ提供元で解決してください。リンクをコピーできても、すべてのプロトコルや通信フィールドを現在のクライアントが認識できるとは限りません。インポート時に非対応の案内が表示された場合は、クライアントの対応範囲を確認するか、互換性のある形式を提供元に問い合わせてください。エラーを消すために安全関連のフィールドをむやみに削除しないでください。項目が一覧に表示されても、パラメーター不足で接続できないことがあります。Androidでのインポート手順はサブスクリプションの追加ガイドを参照してください。

復旧後は、グループの自動更新設定を確認し、重複したグループが異なるタイミングで内容を上書きしないようにします。まず手動で一度更新し、項目を一つ選んで接続してから、固定のページにアクセスしてください。その後、古いグループを残す必要があるか確認します。頻繁な更新でトラブルを解決しようとしないでください。リクエストが制限される可能性があり、エラーの発生時系列も分かりにくくなります。サブスクリプションを正常に取得できるのに接続がタイムアウトする場合は、「ノードがタイムアウトする」へ進んでください。更新方法をさらに変更する必要はありません。

速度が遅い：段階ごとにボトルネックを測る

アクセスの遅さは、名前解決、初回接続、ページのリソース読み込み、継続的なデータ転送のどの段階でも発生します。ページを開く前に長時間待たされる場合と、ダウンロード開始後の速度が遅い場合は、同じ問題ではありません。リストの遅延テストで分かるのは、特定のリクエストに対する応答時間が中心で、帯域幅、安定性、すべてのサイトでの速度を直接示すものではありません。同じページを開く、同じ公開ファイルをダウンロードするといった実際の操作を固定し、どの段階が遅いか確認してください。

まずローカルネットワークとバックグラウンド通信を確認する

端末の場所を変えずに、OSの更新、クラウド同期、ほかの大容量通信を一時停止し、Wi-Fiの電波状況や頻繁な再接続がないか確認します。同じネットワークを使う別の端末が回線を占有していることもあります。直接接続でも遅い場合、プロキシでWi-Fiの干渉やローカル回線の混雑を解消することはできません。有線接続が可能なデスクトップ端末では、有線でも比較できます。Android端末ではWi-Fiとモバイルネットワークを比較できますが、通信量に注意し、大容量ファイルを長時間ダウンロードする必要はありません。

テストごとに変更する条件は一つだけにしてください。同じサーバーを異なる時間帯に比較すると負荷の変化を確認でき、同じ時間帯に2つのサーバーを比較すると経路の違いを確認できます。同じサーバーで複数のサイトを比較すれば、接続先サイトの問題かどうかを切り分けられます。サーバー、コア、ルーティング、DNSを一度に変更して、速度の変化を特定の設定だけの効果と判断しないでください。テスト結果には、同じ操作での状況とネットワーク条件を記録します。ブラウザーのキャッシュ、バックグラウンド更新、偶発的な再試行に惑わされないようにしましょう。

ログとリソース使用量から処理負荷を確認する

ページの読み込みは速いのに、画像や動画が止まる場合は、パケットロス、サーバーの負荷、接続先サイトのコンテンツ配信経路を確認してください。初回の表示が遅く、再読み込み後は明らかに速い場合は、名前解決、ハンドシェイク、接続の再利用を確認します。特定のサイトだけ遅く、同じサーバーからほかのサイトには正常にアクセスできる場合は、そのサイトとサーバーの出口間に問題がある可能性があります。端末側のプロトコルパラメーターを変更しても効果がないことがあるため、まずサイトとサーバーを組み合わせて比較してください。

デスクトップでは、OSのタスク管理画面でCPU、メモリ、ネットワークの使用状況を確認できます。端末のリソース不足、複数のプロキシプロセスの同時実行、仮想NICによる二重の通信取り込みは、処理負荷を増やすことがあります。デバッグログも追加の書き込みを発生させるため、原因の特定後は通常のログレベルに戻してください。Androidでは発熱や省電力機能にも注意が必要です。高負荷が続くとシステムの動作に影響することがあり、画面消灯後に問題が起きる場合は、モバイル端末のバックグラウンド動作に関する章を確認してください。

複雑な設定で測定の代わりをしない

多重化、並列処理、通信設定は、どの環境でも使える高速化スイッチではありません。有効性はプロトコル、サーバー側の対応、回線品質、リクエストの特性に左右されます。設定が合わないと接続できなくなることもあります。まずサブスクリプションの初期パラメーターを維持し、テストの目的を説明できる場合に限って一項目ずつ変更してください。変更前に戻せるよう記録も残します。特に、使用中のコアに合わない設定例をそのままコピーしないでください。設定が無視されたり、起動に失敗したりする可能性があります。

ルーティングも速度に影響します。同じサイトのページとリソースが異なるドメインを使用し、ルールによって別々の出口へ振り分けられると、ページの表示が不安定になることがあります。テスト対象のドメインを一時的に同じ出口へ割り当てて確認し、その後ルールを調整してください。すべての通信を恒久的に同じ方法で処理する必要はありません。システムプロキシとルーティングの役割については、システムプロキシモードの解説を参照してください。まず通信がどこから入るかを把握し、そのうえで経路の負荷を比較します。

復旧したかどうかは、単独のテスト数値ではなく、最初に問題が起きた操作を基準に判断してください。普段使うページを安定して開けて、連続したデータ転送も途切れないなら、パラメーターを追加し続ける必要はありません。特定の時間帯やサーバーだけで速度が継続的に遅い場合は、再現条件を記録し、出口や負荷の確認を設定提供元に依頼してください。クライアントのローカル設定だけで、遠隔の回線容量を増やせるとは限りません。ボトルネックが端末にないと確認することも、適切な診断結果です。

DNSの問題：名前解決が行われる場所を特定する

DNSはドメイン名をアドレスに変換しますが、プロキシ環境では名前解決がOSだけで行われるとは限りません。ブラウザーでセキュアDNSが有効になっていたり、クライアントに独自のDNS設定があったり、接続先のサーバーがドメイン名を受け取り、自身で名前解決したりすることがあります。システムDNSを変更しても変化がないからといって、設定が保存されていないとは限りません。対象のリクエストがシステムDNSを使っていない可能性もあります。診断前に問題のドメイン、発生時刻、使用したアプリを確認し、どの層が名前解決を担当しているかを特定してください。

名前解決の失敗と接続の失敗を見分ける

ブラウザーにサーバーが見つからないと表示され、ログに名前解決エラーが出る場合は、まずDNSを確認します。ログでアドレスを取得できているのに、そのアドレスへの接続がタイムアウトする場合は、接続経路を調べてください。すべてのドメインのアクセス失敗をDNSの問題とみなさないようにしましょう。サイトのドメインをIPアドレスに置き換える方法も、信頼できる検証にはなりません。多くのサイトはHTTPSのサーバー名やバーチャルホストを必要とするため、アドレスでアクセスすると証明書エラーや別のサイトが表示されることがあります。それだけで元のドメインの名前解決に問題があるとは判断できません。

同じドメインを2つのアプリで開き、ブラウザーだけで失敗するか確認してください。ブラウザーのセキュアDNS、プロキシ拡張機能、独自のネットワーク設定によって、システムの通信経路が使われないことがあります。一時的にシステム設定に従う状態へ戻して再テストしてください。次に、直接接続とプロキシ経由の結果を比較します。プロキシ経由だけで失敗する場合は、クライアントのDNSサーバーに到達できるか、その通信がどの出口を使うか確認します。両方で失敗する場合は、ドメインが有効か、現在のネットワークで認証が完了しているかも確認してください。

循環依存とアドレスファミリーを確認する

よくある循環依存の一つは、プロキシサーバーへの接続にそのドメインの名前解決が必要なのに、DNSリクエストもまだ確立していないプロキシ経由に設定されている状態です。暗号化DNSサーバーのアドレスがドメイン名で指定されていて、その名前を解決するための初期経路がないケースもあります。起動後に名前解決エラーが続く場合は、このような依存関係がないか確認してください。対処するには、DNSサーバーをむやみに追加するのではなく、最初の名前解決に使える経路を確保します。具体的なフィールドやブートストラップの方法は、使用中のコアの対応状況に合わせて設定してください。

IPv4とIPv6は分けて確認してください。ネットワークからIPv6アドレスが返されても、端末から接続先までのIPv6経路が安定しているとは限りません。特定のネットワークで待機後に別の経路へ切り替わる場合は、クライアントの対応範囲内でアドレスファミリーの優先順位を一時的に変更し、同じドメインで再テストします。結果がアドレスファミリーの問題を明確に示す場合に限り、変更を維持してください。一度失敗しただけで、ほかのアプリやローカルネットワークサービスにも影響する設定をシステム全体で恒久的に無効にするのは避けましょう。

名前解決の設定とルーティングの設定を対応させる

ドメインを条件にするルールと、IPアドレスを条件にするルールでは、適用される条件が異なります。以下は、ドメインとプライベートアドレスに基づいて直接接続する構成を示すルーティングオブジェクトの一部です。完全なクライアント設定ではなく、既存の設定と置き換えることはできません。この例では、directという名前のアウトバウンドが設定済みで、コアが対応するルールデータを読み込める必要があります。クライアントが設定を自動生成する場合は、次回起動時にファイルが上書きされないよう、同等のルールをGUIで編集してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIsは、ルーティング時に受け取った宛先情報をそのまま条件に使用することを示します。すべてのIPルールに適用するために、ドメインを自動でIPアドレスへ名前解決するという意味ではありません。また、接続中にDNSが一切不要という意味でもありません。ルールがIPアドレスを条件とし、受信した宛先がドメイン名の場合に名前解決されるかどうかは、ルーティングの設定によって異なります。変更前に、ドメインの名前解決を直したいのか、特定のIPルールを適用させたいのかを明確にしてください。この二つの目的を「リモートDNS」という一つの設定でまとめて考えることはできません。

変更後はプロキシサービスを再起動し、テストするアプリも開き直してください。必要に応じて、OSが提供する方法でDNSキャッシュを更新します。ブラウザー、OS、クライアントがそれぞれ結果をキャッシュしていることがあり、1回の再読み込みですべての古い接続が解消されるとは限りません。同じドメインでテストを繰り返し、エラーが名前解決の段階から接続の段階へ移ったか確認します。名前解決が復旧しても接続先に到達できない場合は、次の段階を調べ、DNSサーバーをさらに変更しないでください。用語の意味は用語集を参照し、DNSサーバー、名前解決の経路、ルーティングの出口を区別してください。

システムプロキシが機能しない：通信を取り込む範囲を確認する

システムプロキシは、アプリが読み取れるようプロキシアドレスをOSに設定する機能ですが、すべてのプログラムが利用するとは限りません。ルーティングルールが処理するのは、すでにクライアントへ入った通信だけです。仮想NICモードは別の通信取り込み経路で、個別の権限、ルーティング、DNS設定が必要です。診断時はまず入口を一つ選び、複数の方式を同時に有効にしないでください。その入口にアプリが従うかどうかを確認してから、次の手順に進みます。クライアントにルーティングモードが表示されていても、システムプロキシが正しく設定されているとは限りません。

待ち受けアドレスとポートを確認する

まずv2rayNで、実際に有効なローカル受信方式、待ち受けアドレス、ポートを確認し、OSのプロキシ設定と照合してください。HTTPプロキシ、SOCKSプロキシ、混合受信は、ポート番号の見た目だけで互換性があるとは判断できません。アプリが必要とする方式に合った入口を指定してください。待ち受けアドレスがローカルループバックの場合、アクセスできるのは同じ端末だけです。端末内のブラウザーの問題を直すために、待ち受け先をすべてのネットワークインターフェースへ変更しないでください。接続可能な範囲が広がります。

ログにポート使用中と表示された場合は、古いクライアントのインスタンスや別のプロキシプログラムを終了してから起動してください。GUIでローカルポートを変更する方法もありますが、その場合は手動設定したアプリもすべて同じポートに変更する必要があります。システムプロキシはクライアントが自動で更新できても、ブラウザー拡張機能、ダウンロードツール、開発ソフトに独自設定したプロキシは自動で追従しません。クライアントのポートだけを変更し、アプリ側を更新しないことは、「一部のプログラムは使えるが、ほかは使えない」というよくある原因です。

OS、ブラウザー、アプリのプロキシ設定の優先関係を確認する

ブラウザーはシステム設定に従う場合も、拡張機能で指定したプロキシや自動設定スクリプトを使う場合もあります。まずプロキシ関連の拡張機能を一時的に無効にし、ブラウザー独自のネットワーク設定が優先されていないことを確認してください。OSのシステムプロキシを読み取らず、プログラム内でHTTPまたはSOCKSの入口を指定する必要があるアプリもあります。独自のネットワークサービスを通じて接続するアプリもあります。ブラウザーでアクセスできても、すべてのアプリがプロキシを経由するとは限りません。特定のアプリが直接接続していても、システム設定全体が機能していないとは限りません。

Windowsではネットワークコンポーネントによって参照するプロキシ設定が異なる場合があります。macOSではプロキシ設定が現在のネットワークサービスに関連付けられるため、有線と無線を切り替えた後は再確認してください。Linuxのデスクトップ環境で設定したプロキシも、すべてのプログラムに自動適用されるわけではありません。ログイン後だけ問題が起きる場合は、クライアントのコアが起動しているか、システムプロキシが待ち受け中のポートを指しているか確認してください。自動起動の流れはLinuxのインストールとデスクトップログイン時の自動起動ガイドも参考にしてください。

プロキシの入口とルーティング結果を分けて検証する

固定のサイトにアクセスし、対象の通信がアクセスログに記録されるか確認してください。記録がない場合は、まず入口を調べます。ログに記録され、直接接続へ振り分けられている場合はルーティングを確認します。プロキシ側のエラーが記録されている場合は、サーバーを確認してください。ログが無効になっていたり、アプリが既存の接続を再利用していたりすると、新しい記録がすぐに表示されないことがあります。再テスト前にページを閉じてアプリを開き直してください。一行のログがないことだけを根拠に、通信がクライアントへ入っていないと判断せず、複数の情報を組み合わせてください。

仮想NICによる通信取り込みも使っている場合は、まずそれを無効にし、システムプロキシだけを有効にして比較します。仮想NICをテストするときも、システムプロキシを併用する必要があるか明確にしてください。二重に通信を取り込むと、転送の重複、例外ルールの不一致、DNS経路の変化が起きることがあります。仮想NICの起動失敗はOSの権限やドライバーの状態にも関係するため、ルーティングモードを何度も切り替えても解決しません。権限はクライアントが必要とする範囲だけ許可し、関連プログラムすべてを常に高い権限で実行しないでください。

修復後は、プロキシ有効時、無効時、再ログイン後の3つの状態でそれぞれ確認してください。有効時はテストするアプリがプロキシを経由できること、無効時は想定どおり直接アクセスできること、再ログイン後はポートと起動状態が正しいことを確認します。LAN内の別端末からこの端末のプロキシを使う必要がある場合は、待ち受け範囲、アクセス権限、ファイアウォールルールを別途設計してください。その要件を端末内のトラブルシューティングと混同しないようにしましょう。システムプロキシと「グローバル」「中国本土を除外するルール」の違いは、システムプロキシモードの解説を参照してください。

起動失敗・クラッシュ：エラー発生時の状態を残す

ウィンドウが開かない、画面は正常でもコアが終了する、しばらく使うとプログラム全体が終了する。これらはそれぞれ異なる問題です。起動失敗ではインストーラー、実行環境、権限を確認します。コアが終了する場合は設定とポートを優先して調べます。使用中にクラッシュする場合は、リソース使用量と発生操作も確認してください。最後に正常に使えた時点から最初のエラーまでに起きたことを記録します。更新、保存先の移動、設定変更、OSのセキュリティ通知などを確認し、手がかりを失わないよう、すべてのデータをすぐに削除しないでください。

OS、アーキテクチャ、インストール先を確認する

デスクトップではv2rayNを推奨します。クライアントダウンロードページで、OSとプロセッサーのアーキテクチャに合ったインストーラーを選択してください。macOSではApple SiliconとIntel、Linuxではディストリビューションのパッケージ形式とプロセッサーのアーキテクチャを区別する必要があります。Windowsデスクトップ版と従来のWPF版は異なるUI系統のため、それぞれの説明に記載された実行環境を確認してください。同じパッケージ形式でもアーキテクチャが同じとは限りません。インストーラーが起動できるかどうかはプロキシ設定の内容とは別の問題です。まずプログラムを起動できる状態にしてください。

インストーラーの種類に応じてインストールするか、アーカイブをすべて展開してください。圧縮ファイルのプレビューから直接起動したり、関連ファイルを残して実行ファイルだけコピーしたりしないでください。正常に書き込みできる場所へデータを保存し、空き容量とフォルダーのアクセス権を確認します。セキュリティソフトがプログラムを処理した場合は、まずOSの記録で対象ファイルと検知理由を確認し、組織や端末のセキュリティポリシーに沿って対応してください。クライアントを起動するためにOSの保護機能全体を無効にしたり、不明な配布元から不足ファイルを入手したりしないでください。

画面の問題とコア設定の問題を切り分ける

画面が開き、接続ボタンを押すとすぐに停止する場合は、まずコアのログを確認します。よくある原因は、JSONの構文エラー、非対応フィールド、存在しないアウトバウンドタグ、ルールデータを読み込めないこと、待ち受けポートの競合です。エラーには設定箇所や関連フィールドが示されることが多いため、直近で追加した設定を優先して元に戻してください。サブスクリプションの更新後に問題が起きた場合は、以前使えていた項目と比較し、特定の項目の生成に問題があるのか、すべての設定で失敗するのかを確認します。

以下は、XrayとV2Flyの設定で一般的に使われるログレベルを示すログオブジェクトの一部です。完全な起動設定ではありません。クライアントにGUIでログレベルを選ぶ機能がある場合は、そちらで変更してください。より詳しい情報が必要な場合は、一時的にデバッグレベルを有効にして一度だけ再現し、該当部分を保存した後、通常のレベルへ戻します。詳細ログを長期間有効にするとディスクへの書き込みが増え、アクセス先の情報が多く記録されることもあるため、通常の設定として残さないでください。

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

設定を手動編集する場合は、引用符、カンマ、括弧も確認してください。標準のJSONではコメントや末尾の余分なカンマを使用できません。ドキュメント内の説明用の断片も、そのまま連結して完全な設定として使うことはできません。クライアントが生成したファイルを一時的に編集すると、次回起動時に再生成されて上書きされることがあります。該当する設定項目は、できるだけGUIから編集してください。見慣れないフィールドを削除して起動させるだけでは、認証、安全性、ルーティングの動作が変わる可能性があります。

元に戻せる方法で破損した設定を切り分ける

ユーザー設定の破損が疑われる場合は、まずクライアントを完全に終了し、バックグラウンドプロセスが停止したことを確認してから設定フォルダーをバックアップしてください。設定フォルダーの場所は、OS、インストール方法、データ保存モードによって異なります。クライアントの説明や画面から場所を確認し、ネット上の固定パスを根拠に複数のファイルをまとめて削除しないでください。バックアップ後、独立した初期状態のデータ環境で起動をテストします。起動できた場合は、サブスクリプション、ルーティング、画面設定を段階的に戻し、どの種類の設定で問題が起きるか確認してください。

アップグレード後に問題が起きても、すぐに旧バージョンへ戻す必要があるとは限りません。パッケージが正しく配置されたか、古いプロセスが動いたままではないか、新しい画面が以前の設定項目に対応しているかを確認してください。バージョンを戻す場合は、アップグレード前後のデータを先にバックアップし、異なる系統のクライアントが唯一の設定ファイルを交互に書き換えないようにします。再インストールしてもユーザーデータが消えるとは限りません。設定を確認せず同じプログラムを何度もインストールしても、同じエラーが再発することがあります。クライアントの選び方や系統の違いはクライアント比較を参照してください。

復旧後は、サブスクリプション更新、サーバー切り替え、ルーティング設定の表示、OSへの再ログインなど、問題のきっかけとなった操作をもう一度試してください。問題を報告する際は、OSの種類、アーキテクチャ、インストール方法、個人情報を除いたログを共有し、ユーザーデータの保存場所は公開しないでください。特定の設定で再現する場合は、使用しているプロトコルと通信方式を説明します。初期状態の設定でもクラッシュする場合は、実行環境やプログラム自体を重点的に確認し、二つの問題を混同しないようにしましょう。

Android特有の問題：権限、バックグラウンド動作、ネットワーク切り替え

Androidではv2rayNGを推奨します。Xrayコアを採用しています。V2Flyコアを採用するv2flyNGは代替の選択肢です。モバイル端末では、サーバーやサブスクリプションに加えて、VPNの許可、アプリごとのルール、バックグラウンド制限、Wi-Fiとモバイルネットワークの切り替えも確認する必要があります。OSにVPNアイコンが表示されても、プロキシサーバー経由で接続先にアクセスできるとは限りません。まず実際に起動しているクライアントを確認し、この章の順序に従って比較してください。複数のアプリの状態を混同しないようにしましょう。

VPNの許可と接続の競合を確認する

初めて接続を開始する際は、OSに表示されるVPN接続の許可を確認してください。許可が完了していない、誤ってキャンセルした、端末管理ポリシーで制限されているなどの理由で、サービスが確立できないことがあります。Androidの一般的なアプリ用VPN接続は、同種のアプリが複数同時に使うことはできません。ほかのVPNツールや、ローカルVPNを使って通信をフィルタリングするアプリを停止してから、現在のクライアントを起動してください。仕事用プロファイルや管理対象端末には別の制限がある場合があります。サーバーを変更してOSの管理上の制限を回避しないでください。

VPNを常時接続にする設定や、VPNを経由しない通信をブロックする設定を有効にしている場合は、切断時の動作を理解しておきましょう。プロキシサービスを停止すると、OSの設定によってはほかのネットワーク通信もブロックされることがあります。そのため、「停止後もインターネットに接続できない」からといって、必ずしもネットワークが壊れているとは限りません。診断時は元の設定を記録し、一時的に変更して比較した後、利用目的に合った設定へ戻してください。クライアントのボタンだけで判断せず、OSのVPN設定で現在の接続先と制限項目を確認します。

画面消灯後の切断とバックグラウンド制限を確認する

画面が点灯している間はアクセスできるのに、消灯してしばらくすると切断される場合は、OSのバッテリー最適化とバックグラウンド実行の制限を確認してください。「バックグラウンドでの動作を許可」「自動起動」「バッテリー最適化」などの名称は端末によって異なります。現在のOSの画面で該当する項目を探してください。継続動作が必要なクライアントだけに適切な権限を与え、すべてのアプリの省電力機能を無効にしないでください。設定後は、画面点灯中、消灯中、アプリを再度開いた後の3つの状態をテストし、サービス通知が消えるか、OSによって再作成されるか確認します。

データセーバーやバックグラウンドでのモバイルデータ通信制限により、サービスが動作中でもデータを転送できなくなることがあります。特に、Wi-Fiからモバイルネットワークに切り替えた後の状態を確認し、使用中のネットワークでクライアントの通信が許可されているか確認してください。切り替えのたびに再接続が必要な場合は、古い接続が再確立されていないのか、DNS経路が変わったのかを比較します。すぐにサブスクリプションを削除しないでください。機内モードのオン・オフはネットワークを再接続するための比較手段であり、恒久的な解決策ではありません。

アプリごとの設定とローカルネットワークへの通信を確認する

アプリごとのプロキシ設定には、対象アプリだけを含める方式と、対象アプリを除外する方式があり、意味は逆です。リストを変更した後はVPNを再接続して設定を反映させ、リスト内とリスト外のアプリを一つずつテストしてください。ブラウザーでは接続できるのにほかのアプリで失敗する場合は、対象アプリがVPNを経由しているか、アプリ内部に独自のプロキシやネットワーク設定がないか確認します。アプリ単体のキャッシュ、アカウントの接続状態、接続先サービスの問題は、すべての通信のルーティングを切り替えても正確に判断できません。

LAN内の端末にアクセスできない場合は、ローカルアドレスがプロキシへ送られていないか、クライアントにLANをバイパスする設定があるか確認してください。プリンター、家庭用ストレージ、ルーターの管理画面は、現在のLAN経路を必要とします。リモートプロキシでその経路を代用することはできません。プライベートアドレスのルール、OSのVPNルーティング、アプリ独自の機器検出が同時に関係することがあるため、まずVPNを停止して比較し、その後設定を一つずつ戻してください。LANアクセスの問題を解決する一般的な方法として、LANへの待ち受け権限をむやみに広げないでください。

インストール後・復旧後の確認手順

Androidダウンロードページで、端末のアーキテクチャに合ったインストーラーを選択してください。インストールに失敗した場合は、ストレージの空き容量、OSのインストール通知、プロセッサーの互換性、現在のインストール元を確認します。サブスクリプションやカスタムルールが削除される場合があるため、すぐにアンインストールしないでください。再インストールが必要な場合は、クライアントが対応する方法で必要な設定を保存し、アカウント情報を安全に保管してください。汎用パッケージとアーキテクチャ専用パッケージは、端末の実際の仕様に合わせて選びます。

復旧後は、通常のウェブページへのアクセス、アプリごとの動作、画面消灯中の接続維持、ネットワーク切り替えの順に確認します。各段階で同じ有効なサーバーを使ってください。モバイルネットワークだけで失敗する場合は、DNSとタイムアウトの章に戻って経路を比較します。バックグラウンドでだけ失敗する場合は、OSの制限を確認してください。クライアントの違いは3つのクライアントの違いを比較を参照してください。普段の利用環境で安定したことを確認してから、自動更新やほかのカスタム設定を戻し、次回の診断に備えて動作する設定を一つ保存しておきましょう。