V2Ray トラブル対処ガイド

インターネットに接続できない：接続が途切れる箇所を特定する

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

「インターネットに接続できない」だけでは、問題を特定できません。すべてのアプリで失敗するのか、ブラウザーだけか、特定のサイトだけかを確認しましょう。プロキシクライアントを終了し、システムのプロキシ設定を元に戻して、通常の直接接続でアクセスできるサイトを開きます。それでも接続できない場合は、ネットワーク接続、Wi-Fi、ゲートウェイ、ログインが必要なネットワークの認証を優先して確認してください。基本のネットワークが使えない状態でノードを何度も切り替えても、問題が複雑になるだけです。

直接接続できることを確認したら、クライアントを起動して、正当に使用できるノードを一つ選びます。デスクトップではv2rayN、Androidではv2rayNGを優先し、V2Flyの設定が必要な場合にv2flyNGを検討してください。システムの通信を制御するツールを複数同時に起動しないでください。まずTUNと複雑なルーティングを無効にし、システムプロキシに対応していると確認できたブラウザーで通常のプロキシ接続をテストして、問題の範囲を絞ります。

リクエストが通る段階を順に確認する

通常、アクセスはアプリのプロキシ設定、ローカルの待ち受けポート、ルーティングルール、ノードへの接続、接続先サービスの順に進みます。クライアントの画面が開くのは、管理プログラムが動作していることを示すだけです。ノードを選択しただけでは、コアが起動したとは限りません。クライアントの実行ログで起動成功、待ち受けアドレスとポートを確認し、アクセス時に該当するリクエストが記録されるかを調べます。リクエストが記録されない場合は、アプリの通信が本当にクライアントへ渡されているかを確認してください。

ログにローカルポートのバインド失敗が記録されている場合は、別のクライアントやプログラムがポートを使用していないか確認してください。待ち受けポートを変更したら、アプリ側のプロキシポートも同じ値に変更する必要があります。ローカルのインバウンドポートにリモートノードのポートを入力しないでください。前者は端末上のアプリからリクエストを受け取り、後者はサーバーへの接続に使います。数値が同じでも、両者が自動的に連携するわけではありません。

一度に一つだけ変更して原因を絞る

ノードはそのままにして、クライアントのルーティングを一時的に明示的なプロキシ経由に変更し、同じ接続先へアクセスします。接続できるようになれば、ルーティングルールに問題がある可能性が高いでしょう。それでも失敗する場合は、ほかの設定を変えずに、正常動作が確認できている別のノードへ切り替えます。変更した項目と結果を毎回記録し、「いろいろ変更したら直ったが、原因が分からない」という状態を避けてください。テスト後は元のモードに戻し、一時的な全通信プロキシを最終設定として残さないようにします。

特定のサイトだけ開けない場合は、まずサイトの稼働状況を確認し、正常に開ける別のサイトと比較します。ページ本体は表示されても画像やログインに失敗する場合、関連ドメインの通信経路が異なるか、接続先サービスが現在の出口を拒否している可能性があります。ノード全体が使えないと判断する前に、失敗したリクエストのドメインとルーティングを確認してください。

復旧したと判断するには、同じ条件で再現できることを確認します。クライアントを終了すると接続できず、決めた設定で起動すると接続できること、ログの接続先とアウトバウンドが想定どおりであることを確認してください。この最小限の動作設定を保存し、その後にルーティング、TUN、アプリ固有の設定を一つずつ有効にします。接続テストの詳細は初回接続と実接続の速度テストガイドをご覧ください。

ノードがタイムアウトする：ポート、ハンドシェイク、プロトコルを切り分ける

まずタイムアウトが発生した段階を確認する

ノードのタイムアウトは、ドメインの名前解決、通信接続の確立、TLSハンドシェイク、プロトコル認証のいずれかで発生する可能性があります。ログから関連する最初のエラーを探し、最後に表示された大まかな接続失敗だけで判断しないでください。接続先ホスト、ポート、エラーの種類、発生時刻を記録します。同じノードを異なるネットワークで試した結果は、一度の速度テストの数値よりも診断に役立つことがあります。テスト中はノードのパラメーターとクライアントのモードを揃えてください。

TCPingで確認できるのは、主にポートへの接続状況です。プロキシプロトコル全体、認証情報、接続先サイトへのアクセスまでは検証できません。ポートに接続できても実際のリクエストが失敗する場合、ユーザーIDの不一致、通信経路の誤り、TLSパラメーターの不一致などが考えられます。反対に、特定のテスト方法で失敗しても、実際の通信がすべて使えないとは限りません。ポートテストとクライアントの実接続テストを併用し、同じ指標として扱わないでください。

リモートアドレスと通信パラメーターを確認する

ノードアドレスの前後に余分な空白がないこと、ポート番号が有効範囲内であること、サーバーから提供された情報と一致することを確認します。続いて、プロトコル、ユーザーID、パスワード、通信方式、追加フィールドを確認してください。WebSocketのパスとHost、gRPCのサービス名は正確に一致させる必要があります。スラッシュや大文字・小文字のわずかな違いでも、別のサービスにリクエストが送られることがあります。他のノードの入力方法を参考に、情報のない項目を推測で埋めないでください。

アドレスにドメイン名を使っている場合は、現在そのドメインを名前解決できるか確認してください。サービス提供元が確認したアドレスへの一時的な変更は、条件を限定した診断にのみ使い、ドメイン検証に依存する設定をむやみに変えないでください。接続アドレス、TLSのserverName、HTTP Hostはそれぞれ役割が異なります。接続先、検証するサービスの識別情報、送信するアプリケーション層のホスト名を指定するものであり、常に同じ値である必要はありません。

TLSとREALITYのエラーを確認する

証明書が有効でない、または期限切れというエラーは、端末の日時設定が誤っている場合も、実際にサーバー証明書に問題がある場合もあります。まずシステムの日付、タイムゾーン、時刻を同期し、SNIがサーバーの指定と一致しているか確認してください。証明書の検証を無効にする方法を通常の解決策にしないでください。ドメインの入力ミス、証明書チェーンの不足、誤ったホストへの接続などの根本原因を見落とす可能性があり、アクセスできても設定が正しい証拠にはなりません。

REALITY接続では、サーバーの公開鍵、shortId、serverName、フィンガープリント、サービス提供元が指定するflowも確認します。各フィールドへの対応は、選択したコアやクライアントの実装によって異なります。ノード名に用語が含まれているだけで、互換性があると判断しないでください。不明なフィールドや未対応プロトコルのエラーが出たら、まずコアの種類を確認し、設定の入手元と照合します。詳しくはXrayとV2Flyのコアの違いをご覧ください。

ネットワークを変えて比較し、サーバー側も確認する

同じ端末で、信頼できるWi-Fiとモバイルデータ通信をそれぞれ使ってテストします。一方のネットワークだけで失敗する場合は、ネットワーク認証、アクセス制限、アドレスファミリー、通信事業者の経路を確認してください。すべてのネットワークで失敗し、ほかのノードは正常な場合は、そのノード自体を重点的に確認します。テスト中はほかのダウンロードを一時停止し、端末の通信混雑でハンドシェイクが遅くなるのを防ぎます。問題を隠してしまうため、タイムアウト時間を際限なく延ばさないでください。

サーバーの管理権限がある場合は、サービスプロセスが正しいアドレスで待ち受けているか、ホストのファイアウォールと上位のセキュリティルールで対象ポートが許可されているかを確認し、同じ時刻のサーバーログも調べます。管理権限がない場合は、機密情報を除いた発生時刻、エラーが起きた段階、テストしたネットワークをサービス提供元に伝えて確認してください。ノードの完全なリンクを公開しないでください。再接続時だけまれにタイムアウトし、その後は安定する場合は、クライアントを再インストールする前に、スリープからの復帰やネットワーク切り替えも確認します。

変更後は、同じ接続先に対して軽いアクセスを数回続けて行い、ハンドシェイクが安定して成功することを確認してから通常のルーティングに戻します。証明書の問題についてはTLS証明書とSNIのトラブル対処をご覧ください。ポートに接続できても認証に失敗する場合は、パラメーターを再確認します。システムプロキシを何度も変更しても解決にはなりません。

サブスクリプションを更新できない：取得・形式・解析を確認する

更新処理を3段階に分けて確認する

サブスクリプションの更新は、アドレスの内容を取得する、内容の形式を識別する、ノードをクライアントに登録する、という3段階で行われます。更新失敗と表示されたら、まずネットワークエラー、HTTPステータスの異常、内容の解析エラーのどれかを確認してください。既存のノードが使えていても、サブスクリプションを正常に取得できるとは限りません。また、更新が成功しても新しいノードがすべて接続できるとは限りません。それぞれの経路を個別に確認し、一方の結果で他方を判断しないでください。

クライアントのサブスクリプショングループでアドレスが完全か確認し、コピー時にクエリパラメーターを落としていないか、改行や説明文が混ざっていないかを確認します。アドレスに含まれる認証情報は機密情報です。公開スクリーンショットやオンライン変換サイトに掲載しないでください。表示しやすくするためにアドレスのエンコードを変更しないでください。パーセントエンコードや区切り文字がサーバー側の識別に使われている場合があります。元のアドレスを保存してから、サービス提供元から渡された完全な内容を貼り直してください。

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

クライアントによっては、サブスクリプションの更新に直接接続を使うか、現在のプロキシを経由するかを選べます。サブスクリプションサービスに直接接続できない場合、使用可能なノードがあれば、プロキシ経由での更新を試せます。使用中のノードがすでに使えない場合は、そのノードでサブスクリプションを取得しようとすると行き詰まる可能性があります。ブラウザーのプロキシを切り替えるだけでなく、更新設定を確認してください。使えるノードがない場合は、通常のネットワークからサービス提供元の有効な設定を取得し、信頼できない変換サービスを安易に利用しないでください。

タイムアウトはアクセス経路や名前解決の問題を示すことが多く、接続拒否はサーバー側でポートが開放されていない可能性があります。認証に関するステータスが返された場合は、サブスクリプションの利用権限を確認してください。リクエスト頻度の制限が発生したら、サービス提供元のルールに従って待ち、更新ボタンを連続して押さないでください。サーバーエラーの場合は、時刻とステータスを記録してから時間をおいて再試行します。分组を削除して作り直しても、リモートサービスの障害は直らず、使えるノードを失うおそれがあります。

拡張子ではなく、返された内容を確認する

サブスクリプションの内容は、エンコードされた共有リンクの集合の場合も、クライアントが対応する別の形式の場合もあります。ネイティブのJSON設定、単一の共有リンク、サブスクリプションURLは別の種類の入力です。それぞれ対応するインポート画面を使ってください。サーバーから返されたログイン画面、期限切れの案内、エラーページは、ステータスが正常に見えてもノードデータではありません。解析に失敗したら内容の種類を確認し、URLの末尾に特定の拡張子があるかどうかだけで判断しないでください。

共有リンクのプロトコルと通信パラメーターは、クライアントが対応している必要があります。基本的なノード情報は認識できても、追加パラメーターを無視するインポーターがあり、「インポート成功」と表示されても接続できないことがあります。インポート後のノード編集画面と元のパラメーターを比較し、TLS、セキュリティ層、通信方式、特殊なプロトコルフィールドを重点的に確認してください。形式の違いと変換の制限についてはサブスクリプション形式と共有リンクの相互変換をご覧ください。

更新成功後にノード一覧を確認する

まずノード一覧の検索とフィルターを解除し、更新したサブスクリプショングループを選択します。クライアントによっては以前選択したサーバーや一覧の状態が残り、新しいノードが登録されていても表示されないことがあります。サーバーから空の一覧が返されている場合は、サブスクリプションの利用権限、プランの状態、サービス提供元のノード絞り込み条件を確認してください。何も考えずに繰り返しインポートしないでください。同じアドレスで複数のグループを作っても使いやすくなるわけではなく、ノードの出所が分かりにくくなります。

使える旧ノードか設定のバックアップを一つ残してから、サブスクリプションを整理してください。自動更新によって、サブスクリプション内の手動変更が上書きされることがあります。長期的な調整には、クライアントが対応している独立した設定やグループのルールを使い、一時的な編集内容がずっと保存されると考えないでください。復旧後は新しいノードの実接続を確認し、次回の更新でも内容を取得できることを確かめます。インポート方法に関するよくある疑問はよくある質問をご覧ください。

速度が遅い：遅延、転送速度、アプリの待ち時間を切り分ける

まず、どの処理が遅いのかを確認する

ページが表示され始めるまで時間がかかる、ファイルのダウンロードが遅い、動画がときどき停止する、という症状はそれぞれ異なります。前者はDNS、接続確立、ハンドシェイクに関係することがあり、後者は経路の帯域幅、パケットロス、接続先サービスの負荷に左右されます。発生時刻、使用したネットワーク、ノード、接続先の種類を記録してください。短時間の接続で測った遅延からダウンロード速度を推測したり、ブラウザーの待ち時間すべてをプロキシ経路のせいにしたりしないでください。

信頼できる同じ接続先を選び、近い時間帯に直接接続とプロキシ経由をそれぞれテストします。実際の利用状況を反映する接続先を使い、キャッシュ済みの静的ページと大容量ファイルのダウンロードを直接比較しないでください。バックグラウンド同期、システム更新、ほかの端末による大容量通信を一時停止してから結果を見ます。Wi-Fiの電波が不安定だったり、ローカルの上り帯域を使い切っていたりすると、ノードが正常でもリクエストが滞り、応答が遅くなります。

再現性のあるノード比較を行う

ネットワークと接続先を変えずにノードだけを切り替え、その後はノードを固定してネットワークを切り替えます。こうすればノード経路の問題とローカル接続の問題を切り分けられます。実接続の速度テストは一連のリクエストを反映しますが、接続先、サービスの負荷、テスト時刻の影響を受けます。すべてのノードを何度も同時に高負荷でテストしないでください。帯域を消費し、サーバー側の制限に触れる可能性があるうえ、結果を比較できなくなります。

ノード名に含まれる地名は、実際のエンドツーエンド経路を示すとは限りません。距離が近くても混雑が少ないとは限らず、遅延が短くても実効速度が高いとは限りません。特定のサービスだけ遅い場合は、そのサービスまでの出口経路、コンテンツ配信先の選択、接続先の速度制限などが原因かもしれません。ローカルの待ち受けポートを何度も変えるより、別の出口と比較するほうが有効です。ただし、サービス自体に障害が起きていないかも確認してください。

通信を重複して制御していないか、誤ったルーティングがないかを確認する

システムプロキシ、TUN、ブラウザーのプロキシ拡張機能、ほかのネットワークツールが同時に有効になっていないか確認します。複数の制御レイヤーが重なると、通信が遠回りしたり、クライアント自身のアウトバウンド通信が再びインバウンドに送られたりすることがあります。テストでは経路を一つだけ残してください。一つのレイヤーを無効にして直った場合は、そのレイヤーの除外ルールとルーティングを確認します。出所の分からない高速化設定に頼り続けないでください。

ルーティングの誤りも「一部のコンテンツだけ遅い」という症状につながります。たとえば、メインページは直接接続、関連リソースのドメインはプロキシ経由となっていると、余分な接続が発生することがあります。プロキシ経由にすべき接続先が不適切な直接接続ルートに送られた場合も、タイムアウトを繰り返すことがあります。ログで実際のアウトバウンドを確認してから、該当ルールを調整してください。ルールは通常、上から順に照合されるため、広範なルールを先に置くと後続の詳細なルールが適用されないことがあります。詳しくはルーティング設定の実践ガイドをご覧ください。

プロトコルと端末リソースの制約

通信の多重化、同時接続、高度なオプションは、どの環境でも使える高速化機能ではありません。ネットワーク、接続先、サーバー設定によっては逆効果になることがあり、互換性のないパラメーターは接続リセットを招く可能性もあります。まずサービス提供元の基本設定に戻し、安定して動作することを確認してから、一つずつ試してください。テスト時間を短縮するために認証やセキュリティ層を無効にしないでください。転送速度の問題とは別の調整です。

端末のリソースも確認します。省電力モード、継続的な高温、長時間のCPU高負荷、ディスク容量不足、詳細ログの連続書き込みは、クライアントの応答に影響することがあります。画面の動作が重くてもダウンロード速度が正常なら、リモート側の帯域より管理画面や端末リソースに問題がある可能性が高いでしょう。不要なリアルタイム更新と長時間のデバッグログを停止し、同じ操作で比較してください。

TUN使用時だけ大容量ファイルが停止し、小さなリクエストは正常な場合は、経路MTUやカプセル化が関係している可能性があります。ただし、先にDNSとルーティングを確認してください。クライアントに該当する設定があり、元に戻す方法も理解している場合に限り、範囲を絞ってテストします。ネットワークパラメーターを安易にそのまま流用しないでください。実際の通信が最後まで完了し、接続が繰り返しリセットされないことを復旧の基準にします。テスト条件を記録し、一時的な最高速度を長期的な性能の結論とみなさないようにしてください。

DNSの問題：リゾルバーとリクエスト経路を確認する

ノードのドメインと接続先のドメインを区別する

DNSには少なくとも二つの対象があります。クライアントはまずノードサーバーを見つける必要があり、プロキシ経由のリクエストでも接続先サイトの名前解決が必要になる場合があります。ノードのドメインを解決できないと、リモートプロトコルに接続する前に失敗します。接続先ドメインの名前解決に問題があると、ノードには接続できても一部のサイトが開けないことがあります。ログでどのドメインの名前解決に失敗したのかを確認し、エラー表示だけを見てすべてのDNS設定をすぐに変更しないでください。

どの仕組みが名前解決を行っているかも確認します。アプリがシステムのリゾルバーを使う場合も、独自の暗号化DNSを使う場合もあります。プロキシコアが独自のDNS設定を持つこともあります。SOCKSリクエストでは、アプリ側で名前解決するか、ドメイン名をプロキシ側に渡して解決するかの違いもあります。そのため、システムのコマンドで正常に問い合わせできても、その問い合わせ経路が正常だと分かるだけで、ブラウザーやコアの名前解決にも問題がないとは限りません。

システムの名前解決結果を確認する

Windows、macOS、Linuxのターミナルでは、次のコマンドを使って、システムの既定リゾルバーが例示したドメインに返す応答を確認できます。ツールがない場合は、OS標準のネットワーク診断画面を使えば十分です。使い慣れないツールを追加でインストールする必要はありません。コマンドが成功しても、結果がIPv4かIPv6か、ドメインが存在しないという明示的な応答か、問い合わせがタイムアウトしたかを確認してください。

nslookup example.com

実際の障害を調べるときは、ログに記録された接続先ドメインを問い合わせてください。例示のドメインはコマンドの書き方を示すためのものです。プロキシクライアントのログと照合し、システムの問い合わせは成功するのにコア側の問い合わせが失敗する場合は、コアのDNSアドレスとアウトバウンド経路を優先して確認します。システムの問い合わせ自体がタイムアウトする場合は、ローカルネットワーク、ルーター、選択したDNSサービスを確認してください。証明書エラーを名前解決の失敗と混同しないでください。発生する段階が異なります。

名前解決のループとアドレスファミリーの問題を確認する

あるDNSサービスへの接続にプロキシが必要なのに、そのプロキシノードのドメイン名も同じDNSに依存している場合、起動時にループが発生する可能性があります。ノードのドメイン名には到達可能な初期名前解決経路を確保し、DNSサービス自体が誤ったルーティングでクライアントに戻されないようにしてください。暗号化DNSの設定では、サービスのドメイン名の名前解決と、その後のリクエストを区別する必要があります。アドレスを一つ入力しただけで、すべての依存関係が解決したと思い込まないでください。

次の設定例は、V2Ray内蔵DNSの基本構造とIPv4だけを問い合わせる診断方法を示すもので、完全なプロキシ設定ではありません。記載されたDNSサービスに、現在のネットワークからアクセスできることが前提です。コアによって対応するフィールドやDNSのルーティング方法が異なるため、それぞれ確認してください。GUIクライアントでは、該当する設定画面から変更するのを優先し、クライアントが再生成する実行ファイルを直接編集しないでください。

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

IPv6経路に明らかな問題がある場合に限り、アドレスファミリーを一時的に制限して比較します。制限後に復旧した場合は、ネットワークのIPv6到達性、ルーティング、クライアント設定を確認してください。IPv6の無効化をすべての端末に適用する固定の解決策にしないでください。ドメインから複数のアドレスが返される場合、アプリによって選ばれるアドレスが異なり、同じ端末でも動作が変わることがあります。

キャッシュとブラウザー独自の設定を確認する

DNSを変更しても、古いキャッシュによってテストが以前のアドレスに接続する場合があります。テスト中のアプリを終了して再起動し、OSの手順に従って名前解決キャッシュを消去してから、もう一度リクエストを送ります。ブラウザーのセキュアDNS、アプリ内キャッシュ、システムキャッシュは、必ずしも同時に消去されません。どの層のキャッシュを消去したかを記録し、同じページを何度も再読み込みして新しい結果を使っていると思い込まないようにしてください。

最後に、接続先ドメイン、問い合わせ方法、返されたアドレスファミリー、実際のアウトバウンドを照合します。特定のドメインだけが失敗する場合は、hostsファイルによる上書きや専用のルーティングがないか確認してください。すべてのドメインで失敗する一方、確立済みの接続で通信できる場合は、名前解決層に問題がある可能性が高いでしょう。復旧後は必要なブラウザー設定を再び有効にし、ノードの起動と初回アクセスがそれぞれ独立して成功することを確認します。キャッシュが残っているときだけ使える設定を残さないようにしてください。

システムプロキシが機能しない：アプリとローカルインバウンドを確認する

システムプロキシで制御できる範囲を確認する

システムプロキシは通常、この設定に対応したアプリにプロキシアドレスを通知する仕組みであり、端末のすべての通信を自動的に転送するものではありません。ブラウザーは使えるのに特定のアプリが直接接続する場合、そのアプリがシステムプロキシを読み取っていない可能性があります。コマンドラインツール、バックグラウンドサービス、一部のゲーム、独自のネットワーク機能を備えたプログラムでは、個別のプロキシ設定を使うこともあります。まずアプリがどの接続方式に対応しているか確認し、システムプロキシ、アプリ内プロキシ、TUNのいずれを使うかを決めてください。

v2rayNのシステムプロキシ状態とルーティングモードは別の設定です。システムプロキシは、アプリの通信をローカルポートへ送るかどうかを決めます。ルーティングモードは、コアに入ったリクエストをどのアウトバウンドへ送るかを決めます。分流モードを選んでも、すべてのアプリにプロキシが自動設定されるわけではありません。システムプロキシを有効にしても、ルーティングでプロキシ経由が選ばれるとは限りません。トレイメニューの一項目だけを見るのではなく、二つの状態を個別に確認してください。

待ち受けアドレス、ポート、プロトコルを確認する

まずクライアントの設定と起動ログで、実際の待ち受けアドレスとポートを確認します。端末内だけで使う場合は、通常、ループバックアドレスが適しています。アプリに入力するHTTPプロキシのポートは、HTTPに対応したインバウンドに合わせてください。SOCKSの場合も、対応するプロトコルが必要です。混合ポートが使えるかどうかはクライアントとコアの設定によります。他のガイドにあるポート番号だけを見て使用できると判断しないでください。

次の例は、二つの独立したインバウンドを説明するためのものです。ノード設定ではなく、リモートへのアウトバウンドも含みません。ポート番号は例なので、必ず端末の設定に合わせてください。この構成では、アプリ側で使用するプロトコルに対応するポートを選ぶ必要があります。クライアントがすでに待ち受け設定を生成している場合、例をそのまま追記しないでください。バインドが重複してコア全体の起動に失敗するおそれがあります。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

プラットフォームの設定が上書きされていないか確認する

Windowsでは、現在のユーザーのプロキシ設定を開き、手動プロキシと自動構成スクリプトを区別します。アプリによって参照するネットワーク設定が異なるため、ブラウザーが使えるからといってバックグラウンドサービスも同じプロキシを使っているとは限りません。クライアント終了後もシステムの接続先がローカルポートのままで、そのポートを待ち受けるプログラムがなくなっていると、直接接続は正常なのにアプリがすべて接続エラーになることがあります。

macOSのプロキシ設定は、現在使っているネットワークサービスに関連付けられています。Wi-Fi、有線接続を切り替えたり、新しいネットワークサービスを追加したりした場合は、以前変更した項目だけでなく、実際に使用中のサービスを確認してください。Linuxデスクトップ環境のプロキシ設定がターミナルやシステムサービスに反映されるとは限りません。環境変数を参照するアプリでは、古いプロセスが起動時の値を保持していないかも確認します。設定変更後は、テストするアプリを再起動すると確実です。

プロキシ拡張機能と除外ルールを確認する

ブラウザーのプロキシ拡張機能、自動構成スクリプト、アプリ内プロキシ、システム設定が互いに上書きし合うことがあります。追加のプロキシ設定を一時的に無効にし、接続方式を一つだけ残した状態でアクセス時にコアのログが記録されるか確認してください。ログがない場合は、アプリの除外リストを確認します。接続先が明示的に直接接続するよう設定されている可能性があります。ログはあるもののアウトバウンドが誤っている場合は、システムプロキシのオン・オフを繰り返すのではなく、ルーティングルールを確認してください。

TUNを使うと、より多くの種類の通信を制御できますが、システム権限、仮想ネットワークインターフェース、正しいルーティングが必要です。システムプロキシが原因不明で機能しないときに、安易な代替手段として使わないでください。まず通常のインバウンド経路を確認し、その後でTUNを個別に有効にします。対象アプリのリクエストが期待どおりログに記録され、正しいアウトバウンドに一致すること、クライアント終了後にシステムのネットワーク設定が想定どおり復元されることを復旧の基準にしてください。ほかのモードについては使い方ガイドの接続手順をご覧ください。

クライアントがクラッシュする：画面、コア、設定を切り分ける

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

ウィンドウが消える、画面が応答しない、コアが終了する、という症状はそれぞれ異なります。ウィンドウを閉じてもトレイアイコンが残る場合は、トレイに最小化されているだけかもしれません。管理画面は正常でも接続がすべて途切れる場合は、コアの起動に失敗している可能性があります。プログラム全体が終了する場合は、システムのエラー記録とクライアントログを確認してください。起動、ノード切り替え、サブスクリプション更新、スリープからの復帰など、発生直前の操作を記録して原因を絞り込みます。

最初に設定フォルダーを削除しないでください。まずプログラムを終了し、関連プロセスが停止したことを確認してから、設定、サブスクリプショングループ、必要なユーザー設定をバックアップします。ログは残してかまいませんが、共有する前に機密情報を削除してください。画面を開けない場合でも、OS標準のファイル管理ツールや診断ツールを使って、最近変更されたファイルやアプリのエラー記録を確認できます。出所不明の修復スクリプトをダウンロードしないでください。

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

再インストールする前に、インストールパッケージがOSとチップの種類に対応しているかを確認します。デスクトップ版v2rayNには、異なる画面実装のデスクトップ版とクラシックWPF版があります。システム要件は、実際に使用するインストールパッケージの説明で確認してください。実行環境の不足、古いOS、アーキテクチャの不一致により、メイン画面が表示される前に終了することがあります。インストール先とプラットフォームの選び方はクライアントのインストールパッケージをご覧ください。ファイル名の一部だけから互換性を推測しないでください。

インストール先に書き込み権限があるか、ユーザーフォルダーに十分な空き容量があるか、プログラムを制限付きのネットワーク上や一時フォルダーに置いていないかを確認します。設定を書き込むプログラムでは、ファイルを作成できないと設定消失、更新失敗、繰り返しの終了が起きることがあります。インストール方法に合ったローカルの場所に移動してからテストしてください。フォルダーのアクセス権の問題を隠すために、常に最高権限で実行しないでください。

起動時に最初に出たエラーを確認する

コアのログでは、ポートの競合、設定の解析エラー、リソースファイルの読み込み失敗、未対応フィールドが明確に示されることがよくあります。最初に発生した有効なエラーを先に解決してください。その後の接続失敗は連鎖的な結果かもしれません。クライアントを二つ同時に起動していないか、以前のプロセスが待ち受けポートを使用していないかも確認します。重複したインスタンスを終了して再起動すれば、ネットワークパラメーター全体を適当に変更するより原因を確認しやすくなります。

設定を手動編集して問題が起きた場合は、直近の変更を元に戻してください。JSONではカンマ、引用符、配列やオブジェクトの括弧を正しい構文で記述する必要があります。構文が正しくても、現在のコアがそのフィールドに対応しているとは限りません。GUIクライアントは実行ファイルを再生成することが多いため、生成済みのファイルを直接変更すると次回起動時に上書きされる可能性があります。長期的なカスタマイズには、クライアントが明示的に対応している設定画面を使ってください。

設定を分離して問題を再現する

バックアップを取り、クライアントのデータ保存場所を把握したうえで、独立したテスト用データフォルダーを使うか、元のデータフォルダーの名前を変更して初期設定で起動します。テスト用インスタンスと元のインスタンスを同時に実行しないでください。初期状態で正常に動作したら、サブスクリプション、ノード、必要な設定を一つずつ戻します。項目を戻した直後に問題が再発すれば、該当データや機能まで原因を絞り込めます。

空の設定でもクラッシュする場合は、システムとの互換性、実行環境、インストールファイル、セキュリティソフトのブロック記録を重点的に確認してください。ブロックを確認した場合は、イベントの詳細と対象の出所を調べてください。セキュリティ機能全体をそのまま無効にしないでください。TUNを有効にした場合だけ失敗するなら、権限と仮想インターフェースを確認します。通常のプロキシで動作するなら、ノードデータ全体を削除して作り直す必要はありません。

スリープ後に固まる、長時間動作させると終了するなどの問題では、メモリ、ハンドル、ディスク、ネットワーク切り替えも確認します。自動速度テスト、頻繁な更新、定期更新などの範囲を絞り、特定の操作が原因かを調べてください。復旧後は、起動、インポート、接続、正常終了の4つを少なくとも確認してから、自動タスクを再開します。問い合わせにはクライアント名、システムアーキテクチャ、再現手順、機密情報を除いたエラーを記載してください。「開かない」だけで済ませたり、設定データベース全体をアップロードしたりしないでください。

Androidのトラブル：VPN権限、バックグラウンド動作、アプリ別ルーティング

端末内のVPN制御とリモート接続を切り分ける

v2rayNGとv2flyNGは、AndroidのVPNサービスを使ってアプリの通信を受け取ることができます。システムにVPNのアイコンが表示されても、端末内の通信制御サービスが動作中だと分かるだけで、リモートノードとのハンドシェイク成功を示すものではありません。まずクライアントログと実際のアクセス結果を確認してから、障害箇所を判断します。初回起動時にはシステムの許可が必要です。許可されていない場合や別のサービスに切り替わっている場合、クライアントは想定どおり通信を制御できません。

通常、同じユーザープロファイルで同時に動作できるVPNサービスは一つだけです。別のVPN、セキュリティ系ネットワークツール、同じインターフェースを使うアプリが現在の接続を奪うことがあります。ほかの通信制御サービスを停止してから、テスト対象のクライアントを再起動してください。システムの「常時接続VPN」や「VPN未使用時の通信をブロック」も有効になっていると、クライアントの起動前に端末全体がインターネットへ接続できなくなることがあります。変更前の状態を記録し、テスト後は利用目的に合わせて戻してください。

インストールパッケージとコアを選ぶ

インストール時は端末のアーキテクチャに合わせてarm64またはユニバーサルパッケージを選びます。最近の主流スマートフォンは通常arm64ですが、購入年だけで判断しないでください。不明な場合は、システムや端末の情報を確認するか、提供されているユニバーサルパッケージを使います。インストールに失敗する原因には、ストレージの空き容量、インストール元の許可、既存アプリとの署名の違いなどもあります。すべてのインストールエラーをネットワークの問題と決めつけないでください。

Androidでは、Xrayコアを採用したv2rayNGを優先して検討してください。V2Flyの設定との互換性が必要な場合はv2flyNGを選べます。二つのアプリは画面だけが異なるわけではなく、対応するプロトコル機能やフィールドはコアによって異なります。REALITYなどの機能を含むノードでは、まず対応状況を確認してください。インストール先はAndroidクライアントのダウンロードをご覧ください。移行前に必要な設定をバックアップし、アプリのデータをそのまま相互利用できると思い込まないでください。

画面ロック後の切断とバックグラウンド終了に対処する

画面点灯中は使えるのに、ロックしてしばらくすると接続できなくなる場合は、バッテリー最適化、バックグラウンド動作、バックグラウンドデータの制限を優先して確認します。設定名は端末によって異なるため、システムのアプリ管理で該当クライアントを探し、必要なバックグラウンド動作を許可して、過剰な省電力制限を端末の手順に従って解除してください。すべてのアプリの省電力制限を一括で無効にせず、接続を維持する必要があるクライアントだけを対象にします。

プロセスの終了と、アイドル状態のネットワーク接続の切断も区別してください。前者ではクライアントの通知やVPNアイコンが消えることがよくあります。後者では接続中の表示が残っていても、最初のリクエストで再接続が必要になる場合があります。復帰前後のログを確認し、バックグラウンド設定とノード接続のどちらを調整するか判断してください。画面を点灯した直後に復旧しても、システムが再び通信を許可しただけかもしれません。その現象だけでサーバーが切断したと決めつけないでください。

アプリ別プロキシ設定とネットワーク切り替えを確認する

一部のアプリだけアクセスできない場合は、アプリ別プロキシの対象に含めるモードと除外するモードを確認します。二つのモードは意味が逆です。リスト内のアプリだけをプロキシ経由にする場合も、リスト内のアプリをプロキシから除外する場合もあります。アプリを追加または再インストールした後は、リストと実際のアプリ識別情報の更新が必要なこともあります。まず動作を明確に確認できるアプリを一つ選び、そのリクエストがログに記録されることを確認してから、対象リストを段階的に戻してください。

Wi-Fiからモバイルデータ通信に切り替えると、アドレスが変わって既存の接続が使えなくなることがあります。接続を停止して再起動し、復旧するか確認してください。切り替えのたびに失敗する場合は、クライアントのネットワーク変更への対応とシステムのバックグラウンド制限を調べます。データセーバー、モバイルネットワークの権限、現在のアクセスポイントも確認してください。特定のWi-Fiだけで失敗する場合は、ノードやDNSの問題と判断する前に、Webページでのネットワーク認証を完了してください。

端末のVPNによる通信制御が、テザリング中のほかの端末の通信まで必ず対象にするとは限りません。端末のブラウザーが正常でも、テザリング先の端末が同じ経路を使っている証拠にはなりません。テザリングの問題を解決するために、ローカルの待ち受けをむやみに公開したり、アクセス範囲を広げたりしないでください。復旧後は、画面点灯中、画面ロック後、Wi-Fiとモバイルデータの切り替え、接続停止後の通常の直接接続を順に確認します。それでも問題が続く場合は、症状に応じて本ページのノード、DNS、サブスクリプションの項目を確認してください。基本の接続手順からやり直す場合は使い方ガイドに戻り、インポートと接続テストを確認します。