V2Rayのトラブル対処
ノード、サブスクリプション、システムプロキシ

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

「ネットに接続できない」だけでは原因を特定できません。まず、プロキシをオフにすると通常のWebサイトを開けるか、オンにするとすべてのサイトに接続できなくなるか、特定のアプリだけで問題が起きるかを確認しましょう。通信を奪い合う設定が重ならないよう、ほかのプロキシやVPNアプリはいったん終了します。現在のノード名とルーティングモードを記録し、以降のテストでは同じページを使ってください。ノード、ネットワーク、DNSを一度に変えると、どの変更が効いたのか判断できなくなります。

プロキシをオフにして通常接続を確認する

v2rayNで「システムプロキシをクリア」を選び、TUNモードもオフにします。メインウィンドウを閉じただけではクライアントが終了していない場合があるため、タスクトレイに残っていないか確認してください。ブラウザーを開き、普段プロキシなしで閲覧できるサイトにアクセスします。ここでも失敗する場合は、Wi-Fi、LANケーブル、ゲートウェイ、ネットワークのログイン画面を確認してください。公衆ネットワークでは認証が必要なことがあります。通常のネットワークが復旧するまでは、ノードの設定を変更しないでください。同じネットワークのほかの端末は使えるのに、このPCだけ接続できない場合は、ファイアウォール、固定プロキシ、手動DNSの設定を確認します。

通常接続が復旧したらv2rayNを起動し、ノード一覧に利用可能な設定があることを確認して、接続先として選択します。ログにコアの終了、設定の解析失敗、ポートのバインド失敗が出ていないか確認してください。ウィンドウが開くのはGUIが動作していることを示すだけで、プロキシコアがポートを待ち受けているとは限りません。設定画面で実際のローカルポートを確認し、ログに出ている待ち受けアドレスと照合します。すべてのクライアントが同じポートを使うとは限りません。また、サーバー側の接続ポートをローカルプロキシのポートに設定しないでください。

ローカルの待ち受けとリモート接続を分けて確認する

ローカルのHTTPまたは混合プロキシの待ち受けを確認したら、システムプロキシの設定を介さず、プロキシを明示してテストできます。以下はWindows PowerShell用のコマンドです。クライアントのHTTPまたは混合プロキシが10808番ポートで待ち受けている例なので、実際の設定が異なる場合は該当ポートに置き換えてください。接続先URLはHTTPSリクエストの経路確認に使うもので、目的のWebサイトが必ず開けることを保証するものではありません。SOCKS専用ポートの場合は、次の項目にあるSOCKSの方法で確認してください。HTTP用の指定は使えません。

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

コマンドがすぐにローカルアドレスへ接続できないと表示した場合は、まずコアが起動しているか、ポートが一致しているかを確認します。ローカルプロキシへの接続後にリモート側のハンドシェイクが失敗した場合は、ノードの項目へ進んでください。コマンドは成功するのにブラウザーだけ失敗する場合は、サーバーを次々に変えるのではなく、ブラウザー独自のプロキシ設定、拡張機能、システムプロキシを確認します。サイトからリダイレクト、アクセス拒否、その他のHTTPステータスが返るなら、アプリケーション層の応答は届いています。単純に「ネットワークに接続できない」とは判断しないでください。

ルーティング、アプリ、接続先サイトに絞って確認する

一時的にクライアントのグローバルプロキシモードへ切り替え、同じノードで再試行します。グローバルモードでは使えるのにルールベースのモードで失敗する場合は、対象ドメインが直接接続ルールに一致していないか、ルールデータが正しく読み込まれているか、DNSの結果がIPアドレスルールに影響していないかを確認します。グローバルモードは切り分けのための比較用です。原因を特定したら元のモードに戻してください。特定のアプリだけで失敗する場合は、そのアプリがシステムプロキシに対応しているか確認します。アプリ独自のプロキシ設定が必要な場合や、TUNまたはVPNで適切に通信を取り込む必要がある場合もあります。

復旧後は、直接接続するページとプロキシ経由で接続するページをそれぞれ確認してください。続いてクライアントを終了して再起動し、設定が維持されるか確かめます。終了後に通常接続が再び失敗する場合は、システムプロキシやネットワーク設定が残っている可能性があります。システムプロキシが効かないの項目も確認してください。初めての設定で迷ったときはクイックスタートに戻って基本手順を確認できます。用語や仕組みに関する疑問はFAQをご覧ください。

ノードのタイムアウト：アドレス、ポート、ハンドシェイクを順に確認

まず「クライアントのテストがタイムアウトする」場合と「実際のアクセスがタイムアウトする」場合を分けます。テスト方法によって、TCP接続、指定サイトへのリクエストなど確認内容が異なります。一種類のテストが失敗しただけで、ノード全体が使えないとは限りません。ブラウザーとプロキシを明示したコマンドの両方で確認し、問題が単一ノード、同じサブスクリプション内の全ノード、すべての入手元のノードのどれに当たるかを特定します。一つのノードだけ失敗するなら設定やサーバーの状態が疑われます。すべて失敗する場合は、まずPC、現在のネットワーク、コアの起動状態を確認してください。

サーバーアドレスとリモートポートを確認する

ノードの編集画面で、サーバーアドレス、サーバー側のポート、プロトコル、トランスポート方式を確認します。特に指定がない限り、アドレス欄にプロトコルの接頭辞、パス、余分な空白を含めないでください。ポートにはサービス提供元が案内する接続先を指定します。10808という数字を見ても、リモートポートまで同じ値に変更してはいけません。サブスクリプションを更新した直後は、更新後の設定が選択されているか確認してください。画面に古い項目や選択状態が残ることがあるため、接続先を選び直す必要があります。

Windows PowerShellでは、以下のコマンドで指定したホストとTCPポートに接続できるか確認できます。例のドメインは説明用です。実際に調べるときは、ノードのサーバードメインと正しいポートに置き換えてください。結果で確認できるのはTCP接続のみで、プロトコル認証、通信経路、TLSパラメーターは検証できません。UDPサービスをTCPとして判定することもできません。接続に失敗したら、まず別のネットワークでも同じテストを行い、接続先が変更されていないかサービス提供元に確認してください。

Test-NetConnection -ComputerName example.com -Port 443

ドメインを解決できない場合は、まずDNSの項目を確認してください。名前解決できてもTCP接続が失敗する場合は、ネットワーク経路、リモート側の待ち受け、ファイアウォール、サービス停止などが考えられます。暗号化オプションを何度も変えても、通常は解決しません。TCP接続に成功してもタイムアウトする場合は、クライアントログにあるハンドシェイクや認証の情報を確認します。エラーの前後数行を記録し、ログを共有する前にサブスクリプションURL、ユーザーID、認証情報を削除してください。設定全体を公開しないでください。

TLS、トランスポート層、プロトコル設定を切り分ける

TLS証明書のエラーが出たら、まずシステムの日付、タイムゾーン、時刻同期を確認し、次にSNIまたはサーバー名を照合します。サーバーアドレスとSNIは異なる場合があるため、両方を同じ値にすればよいとは限りません。WebSocketなどのトランスポートでは、パス、Host、安全な通信層も一致させる必要があります。パスは大文字・小文字が区別され、先頭のスラッシュも結果に影響することがあります。ハンドシェイクの切断は、必ずしも証明書の問題ではありません。接続先のサービスが間違っている可能性もあります。

VLESS、VMess、Trojanでは認証やトランスポートの要件が異なります。プロトコル名だけを変更して、ほかの項目をそのまま流用しないでください。REALITYでは、サーバー提供元が指定する公開鍵、ショートID、サーバー名などのパラメーターを一致させます。元の設定を基準にし、インターネット上の情報を組み合わせて設定しないでください。汎用的な対処として「安全でない接続を許可」を有効にするのも避けましょう。証明書検証を無効にしても、接続経路の誤りは直らず、認証の安全性が低下します。証明書の問題はTLSハンドシェイクとシステム時刻の確認方法もご覧ください。

一度に一つだけ条件を変えて原因を確認する

クライアントがSOCKSポートを提供している場合は、以下のコマンドで対象ドメインの処理をプロキシ側に任せられます。ここではローカルSOCKSポートが10808の例を示しています。まずポートの種類を確認してください。HTTPプロキシによるテストと比較すれば、アプリのプロキシ方式の設定ミスを切り分ける手がかりになります。ただし、すべてのルーティングやDNSリクエストがリモート側で処理されることを示すものではありません。実際の動作はコアのルールによって異なります。

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

同じ設定が別のネットワークでは使えるなら、現在の接続ネットワークを重点的に調べます。同じネットワークでノードを変えて復旧するなら、元のノードまたはその経路が疑われます。すべての比較で失敗する場合は、コアが設定内のフィールドに対応しているか確認し、必要に応じてダウンロードページから対象プラットフォーム用のクライアントを選んでください。原因調査のために複数のコアへ次々に切り替えたり、元の設定を上書きしたりしないでください。詳しい切り分け手順はノードのタイムアウト対処ガイドをご覧ください。問い合わせる際は、実施済みの比較結果も添えてください。

サブスクリプションの更新失敗：取得エラーと解析エラーを切り分ける

サブスクリプションの更新には、内容を取得する処理と、取得した内容をクライアントが扱える設定に解析する処理があります。「更新失敗」はどちらの段階でも発生します。表示されたエラーが接続タイムアウト、HTTPステータス、証明書なのか、形式の認識失敗、有効なノードがない状態なのかを確認してください。前者は接続経路、後者は応答内容やサブスクリプション形式を調べます。最初からサブスクリプショングループを削除すると、古い設定や問題発生前後の比較情報が失われるため避けてください。

サブスクリプションURLと応答内容を確認する

サービス提供元のページからサブスクリプションURLをコピーし直し、前後の空白、改行、チャットアプリが付け加えた句読点がないか確認します。URLにクエリパラメーターが含まれている場合、後半が欠けると認証に失敗することがあります。複雑に見えても、パラメーターを勝手に削除・変更しないでください。アカウントページ、購入ページ、クライアント用のサブスクリプションURLは用途が異なります。ブラウザーでページが開いても、インポート可能なURLとは限りません。URLにはアクセス権限が含まれる場合があるため、公開スクリーンショット、検索欄、第三者の変換サイトに載せないでください。

未認証やアクセス禁止が返る場合は、サブスクリプションの有効期限、URLの再発行、サービス側のアクセス制限を確認します。リソースが見つからない場合は、パスが変更されていないか確認してください。リクエストに成功しても解析結果が空なら、ログイン画面、メンテナンス画面、アクセス確認画面、エラー説明などを受け取っている可能性があります。成功ステータスだけを見てクライアントの故障と決めつけないでください。必要なら応答の冒頭がWebページのテキストか確認します。ただし、認証情報を含む内容全体をログや公開の問い合わせに貼り付けないでください。

適切な更新経路を選ぶ

現在のネットワークからサブスクリプションサーバーへ直接接続できなくても、使えるノードがある場合は、そのノードを選択してクライアントの「プロキシ経由で更新」を試します。通常の更新とプロキシ経由の更新がシステムプロキシ設定に従うかどうかは、クライアントの実装によって異なります。システムプロキシのスイッチだけでは判断できません。逆に、無効になったノード経由で更新リクエストを送っているなら、直接接続に切り替えると復旧する場合があります。URLは変えず、更新方法だけを一度に一つ変更してください。

初期設定で使えるノードがない場合、まだ確立していないプロキシ経由でサブスクリプションを取得することはできません。アクセス可能なネットワークで再試行するか、サービス提供元にクライアント対応の別のインポート方法を問い合わせてください。失敗を回避するために証明書検証を無効にしたり、出所不明の変換サービスを使ったりしないでください。更新は適度な頻度で行いましょう。短時間に何度も実行するとサーバーのレート制限にかかることがあります。制限の応答が返ったら、同じグループを何個も作るのではなく、時間を置いて再試行してください。

形式、エンコード、クライアントの対応状況を確認する

共有リンク、エンコード済みリンクの一覧、構造化設定はそれぞれ異なる形式です。サービスによってクライアント別の内容を配信する場合があるため、v2rayN、v2rayNG、v2flyNGに対応した入口を選んでください。エンコード済みの内容を手動で扱う前に、元のテキストを保存します。二重エンコード、途中での切り詰め、改行の文字列化に注意してください。別のソフトウェア用設定は、拡張子だけを変えてもインポートできません。ファイル名を変えても内部形式は変わりません。プロトコルやフィールドが未対応と表示されたら、エラー項目をむやみに削除せず、クライアントとコアの対応状況を確認してください。

更新成功と表示されても一覧が変わらない場合は、表示中のグループ、検索条件、非表示ルールを確認してください。お気に入りだけを表示しているなど、フィルターがかかっている可能性があります。ノードの削除はサブスクリプション側の変更であり、クライアントのインポート漏れとは限りません。必要であれば一時グループを作って比較しますが、すぐに元のグループを上書きしないでください。復旧後はノードを手動で選び、実際にアクセスできるか確認しましょう。サブスクリプションの更新成功は、ノードへの接続成功を意味しません。詳しいインポート方法はサブスクリプションの追加方法、内容の確認はサブスクリプション解析エラーのチェックリストをご覧ください。

速度が遅い：接続確立、転送速度、アプリの使用感を切り分ける

まず「遅い」と感じる段階を特定します。ページを開く前の待ち時間が長いのか、ページ本体の表示後に画像の読み込みが遅いのか、ダウンロード中の速度が低いのかを確認してください。接続確立の遅れにはDNS、ハンドシェイク、接続先サイトの応答が影響します。継続的な転送速度は帯域、パケットロス、輻輳、サーバーの負荷にも左右されます。クライアントの遅延テストは特定の方法で測定した結果で、ダウンロード帯域を示すものではありません。一度の測定値だけでノードの長期的な品質を判断せず、同じ条件で繰り返せるテストを用意してください。

回線の帯域と端末の負荷を確認する

システム更新、大容量ダウンロード、クラウド同期など、ネットワークを使うタスクを止め、同じネットワークに接続しているほかの端末でも転送が発生していないか確認します。Wi-Fiの電波が強くても、干渉で通信が不安定なことがあります。アクセスポイントに近づくか、有線接続で比較してください。直接接続でも遅い場合は、プロキシ設定を次々に変えるのではなく、まず通常のネットワークを改善します。モバイルホットスポットと固定回線の比較も有効ですが、モバイル通信の料金やデータ容量に注意し、大きなファイルのダウンロードを繰り返さないでください。

タスクマネージャーやシステムモニターでCPU、メモリ、ディスクの使用状況も確認します。端末の高負荷、ストレージ不足、過熱はブラウザーやクライアントの応答に影響します。ネットワークが遅いように見えても、実際のボトルネックは端末かもしれません。大量のアプリ通信を取り込むTUN、複雑なルール、高頻度のログ出力も負荷の原因になります。まず不要なタスクを止め、通常のシステムプロキシとTUNモードを比較してください。見かけ上の速度を上げるために、検証要件を緩めたりシステム保護を無効にしたりしないでください。

ノードと通信経路を同じ条件で比較する

ノードのテストでは、接続先サイト、ネットワーク、クライアントのモード、時間帯をできるだけそろえ、一度に変更するノードは一つにします。複数のノードで大容量のダウンロードを同時に行うと、同じ回線帯域を奪い合います。地理的に近ければ必ず速いとは限りません。ネットワーク間の接続、リモート側の出口、混雑状況も影響します。一つのサイトだけ遅く、ほかのサイトは正常なら、そのサイト自体、コンテンツ配信経路、リモート出口への制限が原因かもしれません。すべてのプロキシ接続の問題と決めつけないでください。

グローバルモードでは速く、ルールベースのモードでは遅い場合は、遅いリクエストがプロキシ経由か直接接続かを確認します。Webページは複数のドメインを使うことがあり、メインページが開いても画像の読み込みが遅い場合は、画像のドメインが別の出口に振り分けられている可能性があります。一時的に必要な範囲でアクセスログを有効にし、失敗したリソースや待ち時間の長いリソースのドメインを特定してからルールを調整してください。アドレスバーのメインドメインだけを見てルールを追加したり、日常のダウンロード中に詳細ログを有効にしたままにしたりしないでください。ディスク負荷が増え、アクセス履歴が記録されるおそれがあります。

多重化、UDP、MTUの影響を確認する

多重化は常に有効にすべき高速化機能ではありません。ハンドシェイクを減らせる一方、通信経路によっては輻輳を悪化させたり、互換性の問題を起こしたりします。ノードの指定に従い、同じ条件で比較してください。HTTP/3などのWeb通信ではUDPが使われることがありますが、システムHTTPプロキシはすべてのUDPリクエストを取り込むわけではありません。アプリが別の接続方式に切り替わり、初回読み込みが遅く見えることもあります。遅延をすべてノードの帯域不足と決めつけず、アプリが実際に使う通信方式と取り込み範囲を確認してください。

特定の大きなページ、アップロード、長時間接続がTUNモードだけで止まり、通常のシステムプロキシでは正常な場合に、次の確認項目としてMTUを調べます。まず既定値を記録し、現在のネットワークとクライアントの説明を参考に、少しずつ調整してください。変更のたびに接続を作り直して再確認します。値が小さすぎると分割処理や処理負荷が増え、Web記事の固定値をそのまま使うと本当の原因を隠すことがあります。MTUでは認証失敗、証明書エラー、リモートサービスの停止は解決できません。基本的な接続を確認した後に調べてください。

復旧できたかどうかは、実際の用途で判断します。ページを安定して開けるか、会議や長時間接続が途切れないか、継続的な転送速度が保たれるかを確認してください。特定の時間帯だけ遅い場合は、複数の時間帯の結果を記録してサービス提供元に伝えます。PC側ですべての設定を頻繁に変えないでください。初回アクセスだけ待たされる場合や、IPアドレスとドメイン名で結果が異なる場合は、次のDNSの項目へ進みます。特定のアプリだけ遅い場合は、ノードを一斉に変えるのではなく、アプリ独自のプロキシ設定とルーティングルールを確認してください。

DNSの問題：名前解決の場所とリクエストの出口を確認

DNSはドメイン名をIPアドレスに変換しますが、アクセス時にはシステムのリゾルバー、ブラウザーのセキュアDNS、クライアント内蔵DNS、プロキシサーバー側の名前解決が関係することがあります。ほかの接続は正常なのにドメイン名でサイトを開けない場合は、まずどの段階で失敗しているか確認します。ログに表示されるサーバードメインの名前解決失敗と、接続先サイトの名前解決失敗は別の問題です。前者ではプロキシ接続自体を確立できないことがあり、後者は出口を選択した後に発生します。パブリックDNSのアドレスを一つ変更しただけで、名前解決経路全体が変わったと考えないでください。

まずシステムの名前解決とキャッシュを確認する

以下のWindowsコマンドでは、システムが取得できる名前解決結果の確認と、ローカルDNSキャッシュの消去ができます。例のドメインは比較用です。実際の調査では、問題のあるドメインとノードのサーバードメインも確認してください。IPアドレスが取得できても、接続先サービスが期待するアドレスとは限りません。リゾルバー、ネットワーク、接続元の地域によって異なる結果が返るのは正常な場合もあります。キャッシュを消去する前に元の結果を記録し、消去後はアプリを開き直して再度確認してください。ページがたまたま復旧しただけで原因を判断しないようにしましょう。

nslookup example.com
ipconfig /flushdns

検索がタイムアウトする場合は、現在設定されているDNSサーバーへ接続できるか、オフラインのLAN機器に固定されていないか確認します。企業や学校のネットワークでは、専用ドメインの解決に内部DNSが必要な場合があります。安易にパブリックDNSへ変更すると、内部サービスが使えなくなることがあります。自動取得に戻す方法も比較できますが、変更前の設定を記録してください。キャッシュの消去で古い結果は削除できますが、上流DNSへの接続、誤ったルーティングルール、サーバー側の登録漏れは直せません。

ブラウザー、システム、プロキシ側の名前解決を区別する

ブラウザーが独自のセキュアDNSを使っていると、コマンドラインの検索が正常でもブラウザーだけ失敗することがあります。ブラウザーがカスタムDNS、プロキシ拡張機能、独自のネットワーク設定を使っていないか確認し、システム設定に従う別のアプリでも比較してください。ブラウザーのセキュアDNS、システムDNS、クライアント内蔵DNSを同時に変更すると、どの設定が影響したか分からなくなります。暗号化DNSを使う場合は、そのサービス自体へ現在のネットワークまたはプロキシ経由で接続できるかも確認してください。一つのドメインの問題を解決するために、新たな接続依存を作らないようにしましょう。

SOCKSのテストでは、socks5hを使うと接続先のホスト名をプロキシ側で処理できます。通常のローカル名前解決とは結果が異なる場合があります。両方の方法で結果に差があれば、ローカル側とプロキシ側の名前解決を比較する手がかりになりますが、クライアント内のすべてのドメインが同じ経路で処理されることを示すものではありません。ルーティングポリシー、コアのDNS設定、アプリ独自の名前解決も結果に影響します。証明書、SNI、仮想ホストは元のドメイン名に依存するため、HTTPSのURLをIPアドレスに置き換えて単純に確認しないでください。

ルーティングの依存関係と名前解決の循環を確認する

ドメインルールでは、ドメイン名に応じて接続先を選ぶことがあります。IPアドレスルールでは、判定前にコアがドメインを解決する場合があります。IPIfNonMatchなどのポリシーは、ドメインルールに一致しない場合に限って名前解決を試すもので、「常にリモート側で名前解決する」設定ではありません。変更前にルールの順序を確認し、対象ドメインが前段のルールで接続先を決定されていないか調べてください。プロキシサーバー自身のドメインを、まだ確立されていないプロキシ経由で解決しようとすると、起動に必要な処理が循環することがあります。

TUNでは仮想DNSアドレスやアドレスマッピングも関係する場合があります。仮想アドレスを実際のサーバーアドレスとしてノード設定に入力しないでください。アプリやコアの再起動後、以前の接続に保持されたマッピングが無効になることもあります。関連設定を変更したら、影響を受けるアプリの接続を作り直し、必要ならクライアントを再起動してください。古いタブの長時間接続をそのまま使わないでください。TUNだけで問題が起きる場合は通常のシステムプロキシに戻して動作を確認し、仮想ネットワークアダプター、DNSの取り込み、ルーティングの競合に範囲を絞ってから詳細設定を調べます。

最後に、プロキシ経由の接続先とLAN内のリソースの両方を確認します。Webページは復旧したのにプリンター、内部ドメイン、ローカルサービスが使えない場合は、ルーティングまたは内部の名前解決を見直す必要があります。未分類のドメインをすべて一つの出口に強制する設定を、恒久的な対策にしないでください。ドメインルール、IPアドレスルール、コアの名称については用語集をご覧ください。ログで正しい名前解決を確認できてもリモート側のハンドシェイクが失敗する場合は、DNS設定を何度も変更せず、ノードの項目に戻って確認してください。

システムプロキシが効かない：モード、待ち受け、アプリの動作を確認

システムプロキシは、その設定に従うアプリへプロキシのアドレスを知らせるもので、すべてのネットワークリクエストを自動的に取り込むわけではありません。v2rayNの「システムプロキシを自動設定」「システムプロキシをクリア」「システムプロキシを変更しない」は、それぞれ設定を書き込む、削除する、現在の状態を維持する操作です。これらはルーティングの「グローバル」「中国本土を迂回」「直接接続」とは別の層です。前者はアプリからクライアントへ入る方法を決め、後者はクライアントに入ったリクエストの出口を決めます。この二つを混同すると、「グローバルを選んだのに効かない」原因になります。

コアの待ち受けとプロキシの種類を確認する

まず設定画面で、実際のローカル待ち受けアドレス、ポート、プロトコルを確認し、システムプロキシの接続先と一致しているか調べます。HTTP、SOCKS、混合プロキシは、ポート番号だけでは見分けられません。混合プロキシで利用できるプロトコルは、クライアントの説明を確認してください。古い設定では別のポートを使う場合があります。ガイドに記載された既定値を無理に当てはめないでください。ローカルループバックアドレスでの待ち受けは、このPCで使う用途に適しています。調査のためにすべてのネットワークインターフェースで待ち受ける必要はありません。公開範囲を広げると、アクセス管理上のリスクも増えます。

Windowsでは以下のコマンドで10808番ポートの待ち受け状態と、対応するプロセスを確認できます。1つ目はPowerShellのコマンド、2つ目はコマンドプロンプトとPowerShellのどちらからも実行できるシステムツールです。結果が表示されない場合は、まずコアのログを確認します。別のプロセスがポートを使用している場合は、プロセスIDを記録し、タスクマネージャーでプログラムの出所を確認してください。正体の分からないシステムプロセスを終了しないでください。また、ポートが待ち受け中でも、現在のクライアントが待ち受けているとは限りません。

Get-NetTCPConnection -LocalPort 10808 -State Listen
netstat -ano | findstr ":10808"

競合が確認できたら、ポートを使用している別のプロキシアプリを正常に終了するか、v2rayNの設定で未使用のポートを選びます。変更後は関連するコアを再起動し、システムプロキシを再設定してください。ブラウザー独自のプロキシ設定、ターミナルの環境変数、その他の手動設定も合わせて変更します。待ち受けポートだけ変えてアプリ側の接続先を変えないと、クライアントは動作していてもリクエストが古いポートへ送られます。詳しくはローカルポートの競合への対処をご覧ください。

プラットフォームごとのプロキシ設定を確認する

プロキシを明示したコマンドは使えるのに、通常のアプリで使えない場合は、まずアプリの設定を確認してください。ブラウザー拡張機能がシステムプロキシを上書きしたり、ターミナルが古いプロキシ環境変数を引き継いだり、サービスプロセスが独自の設定を使ったりすることがあります。Windowsの netsh winhttp show proxy で確認できるのはWinHTTPのプロキシ設定です。すべてのブラウザーやデスクトップアプリが使うプロキシを示すものではありません。このコマンドに直接接続と表示されても、別のシステム設定を何度も書き込まないでください。

終了後に残る設定とTUNの通信取り込みを確認する

クライアントが異常終了した後もシステムプロキシがローカルポートを指していて、コアが停止していると、その設定に従うアプリはすべて接続に失敗します。まずクライアントを再起動してシステムプロキシをクリアし、システムプロキシ画面に手動設定や自動構成スクリプトが残っていないか確認します。組織のポリシーで管理されている場合は、無理に上書きしないでください。正常終了後も通常接続が復旧したか確認し、ウィンドウを閉じただけで済ませないようにします。複数のプロキシアプリが同時に動いていると、後から設定したアプリが先の設定を上書きすることがあります。ほかのアプリを終了してから確認してください。

TUNは仮想ネットワークインターフェースを使って通信を取り込む機能です。適切な権限、ルーティング、ファイアウォールの設定が必要で、システムプロキシの別名ではありません。通常のプロキシが使えることを確認してから、TUNだけを有効にしてログを確認してください。有効にした直後にネットへ接続できなくなった場合は、TUNをオフにして動作確認済みの状態に戻し、仮想ネットワークアダプター、ほかのVPN、セキュリティソフトとの競合を調べます。復旧後はアプリを一つずつ起動して、どの範囲の通信が取り込まれるか確認してください。LAN内の通信や必要な直接接続を維持し、「すべてのリクエストがクライアントに入る」ことと「すべてがリモートプロキシを通る」ことを混同しないでください。

クライアントのクラッシュ：画面の終了とコアの起動失敗を区別する

まず、どの段階で失敗するかを確認します。ダブルクリックしても画面がまったく開かない、画面が開いてすぐ終了する、メイン画面は正常だが接続の開始に失敗する、一定時間後にプロセスが消える、といった状況を区別してください。GUIとプロキシコアは別のプロセスの場合があり、コアが終了してもメイン画面が閉じるとは限りません。発生した操作、エラーの原文、システムのアーキテクチャを記録してから、再インストールが必要か判断します。設定の削除、サブスクリプションの作り直し、コアの変更を続けて行うと、設定を失ううえ、元の問題を再現できなくなるおそれがあります。

起動できない場合はパッケージ、保存場所、実行環境を確認

クライアントのダウンロードページから、OSとプロセッサーに合ったものを選びます。デスクトップではv2rayNを推奨します。Windowsデスクトップ版と従来のWPF版では、UIの技術や実行要件が異なるため、選んだパッケージの要件を確認してください。一方のパッケージにないコンポーネントを、もう一方からコピーしないでください。macOSではApple SiliconとIntelを区別します。Linuxではアーキテクチャだけでなく、ディストリビューションに適したパッケージ形式も選ぶ必要があります。アーキテクチャの違いや実行環境の不足は、プロキシルールを変更しても解決しません。

選択したパッケージを展開する必要がある場合は、書き込み権限のあるユーザーフォルダーへ完全に展開してから実行してください。圧縮ファイルのプレビュー画面から直接起動しないでください。パスが長すぎる、保護されたフォルダーにある、セキュリティソフトがファイルを隔離したといった理由で、起動に必要なコンポーネントが見つからないことがあります。システムの通知やセキュリティソフトの履歴を確認し、どのファイルが処理されたか調べてください。すべての保護機能を無効にしないでください。インストーラー形式のパッケージは通常の手順で導入し、ポータブル版のフォルダーに個別ファイルを混在させないでください。Windows向けの選び方はインストール時の設定とパッケージ形式の解説をご覧ください。

コアが終了する場合は設定とポートを確認

メイン画面は正常なのにコアが起動しない場合は、ログにある最初の明確なエラーを確認します。ポートのバインド失敗ならポートの項目へ進みます。フィールドが認識されない、または設定を解析できない場合は、カスタム設定のインポート、高度なパラメーターの変更、コアの切り替えを直前に行っていないか思い出してください。新しい設定に現在のコアが対応していないフィールドが含まれているか、JSONの構文に誤りがある可能性があります。ログ末尾の「プロセス終了」だけに注目しないでください。原因はその前の解析や起動情報に記録されていることが多くあります。

以下は、ログ設定を説明するための正しいJSONの最小例です。オブジェクト、フィールド、文字列の書き方を示すもので、単独で起動できる完全なプロキシ設定ではありません。実際にはクライアントが対応する設定画面からログレベルを調整するか、完全な設定の正しい位置を変更してください。この断片で設定ファイル全体を上書きしないでください。調査後は通常のログレベルに戻し、アクセス記録が大量に保存されないようにします。

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

余分な末尾のカンマ、閉じていない引用符、真偽値が必要なフィールドへの数値入力は、いずれも解析エラーの原因になります。JSONの構文チェックで確認できるのは構造の正しさだけで、そのフィールドが現在のコアに対応しているかは分かりません。明確な理由がなければ、直前に変更した高度な設定を元に戻し、GUIクライアントで設定を生成してください。コアを切り替えて調べる場合は、そのコアが対応するノードと設定の組み合わせに戻します。XrayとV2Flyはすべてのフィールドを互換利用できる同一のプログラムではありません。

バックアップとクリーンな環境で比較する

クライアントを完全に終了し、保存方式に応じて設定フォルダーをバックアップするか、設定をエクスポートします。バックアップにはサブスクリプションや認証情報が含まれる場合があるため、管理されたローカルの場所に保存してください。元のフォルダーは変更せず、別のフォルダーまたは新しいアプリ設定環境でクリーンな状態を起動します。テスト中は同じポートを取り合わないよう、複数のインスタンスを同時に実行しないでください。クリーン環境で正常なら、古いファイルを一度に上書きするのではなく、サブスクリプションと必要な設定を一つずつ戻します。同じ問題が起きる場合は、実行環境、ファイル権限、システムレベルのエラー記録を確認してください。

アップデート後に問題が起きた場合も、まず現在の状態を保存します。新旧のパッケージが混在していないか、古いプロセスが終了しているか、設定の移行が完了しているか確認してください。クライアントの実行中に使用中のファイルを置き換えないでください。macOSでセキュリティに関する警告が表示された場合は、警告の種類とシステムが案内する対処方法を確認します。Linuxでは、常に高い権限で実行するのではなく、起動時の出力とデスクトップセッションの依存関係を確認してください。復旧したら、サブスクリプション、システムプロキシ、終了時の設定クリアが正常に動作するかを確かめてから、一時テスト用のフォルダーを削除します。問い合わせには必要なエラー、システムアーキテクチャ、再現手順だけを記載し、プライベート設定全体を添付しないでください。

モバイル端末のトラブル：VPN権限、アプリごとの設定、バックグラウンド制限

Androidではv2rayNGを推奨します。Xrayコアを使用します。V2Flyコアの代替としてv2flyNGもあります。両者は対応する設定や画面上の操作が完全には同じではないため、見た目が似ていても設定をそのまま転記しないでください。調査を始める前に、使用中のアプリ、選択中のノード、動作モード、接続ネットワークを記録します。初回から接続できないのか、画面ロック後に切れるのか、ネットワーク切り替え後に使えなくなるのか、一部のアプリだけ失敗するのかを確認してください。一つのネットワークで一つのクライアントを安定して動作させてから調べ、複数のVPN接続を同時に起動して比較しないでください。

初回接続ではVPNの許可と他のVPNの使用状況を確認

VPNモードでは通常、ローカルVPN接続の作成をシステムが確認します。以前に拒否した場合は、接続を開始し直して許可の画面が表示されるか確認してください。ボタンに起動中と表示されても、すべてのアプリの通信がVPNに取り込まれているとは限りません。別のVPN、仕事用プロファイル内のネットワークアプリ、常時接続VPNの設定が競合していないか確認します。プロファイルごとにネットワークを管理できるシステムもあり、個人用と仕事用のアプリで異なる制限が適用される場合があります。通知領域のアイコンだけで、すべてのアプリの通信が取り込まれていると判断しないでください。

プロキシモードは通常、ローカルのプロキシ接続先を提供するだけで、ほかのアプリの通信を自動的にクライアントへ転送しません。システムやアプリにプロキシが設定されていないと、ノードのテストは成功するのにブラウザーがプロキシを経由しないことがあります。これは矛盾ではありません。VPNで通信を取り込むのか、ローカルプロキシだけを使うのかを決め、対象アプリが対応する方法で設定してください。システムのVPN設定でVPNを経由しない接続をブロックしている場合、トンネルが確立されていないと通常のネットワークも使えなくなることがあります。オプションの意味を確認してから比較し、クライアントを何度も再インストールしないでください。

一部のアプリだけ失敗する場合はアプリごとのプロキシ設定を確認

アプリごとのプロキシ設定が有効か、許可リストと除外リストのどちらを使っているか確認してください。同じアプリ一覧でも、許可リストでは記載したアプリだけがプロキシを使い、除外リストでは記載したアプリがプロキシを迂回します。新しくインストールしたアプリ、複製アプリ、仕事用プロファイルのアプリは別の識別情報になっている場合があるため、一覧を確認し直してください。ブラウザーは使えるのに特定のアプリだけ失敗する場合は、除外されていないか、独自のネットワーク方式を使っていないか、対象ドメインがルーティングルールで直接接続になっていないかを確認します。

一つのアプリを復旧させるために、すべてのドメインを同じDNSや出口に変更しないでください。一時的にアプリごとのフィルターを無効にし、同じノードとネットワークで対象アプリをテストできます。復旧したら、アプリ一覧を少しずつ調整します。アプリ内部に接続がキャッシュされることもあるため、設定変更後はアプリを終了して起動し直してください。システムブラウザー、アプリ内ブラウザー、独立したアプリでは通信の動作が異なる場合があります。Webサイトへログインできても、対象アプリでの動作確認の代わりにはなりません。アカウントセッションの調査では、ログイン情報を公開ログに記載しないでください。

画面ロック後の切断とネットワーク切り替え時の失敗を分けて確認

画面ロック中やバックグラウンドにした後だけ切断される場合は、バッテリー最適化、バックグラウンド実行制限、メーカー独自のプロセス終了機能を確認します。バッテリー消費への影響を理解したうえで、使用中のクライアントに必要なバックグラウンド動作を許可し、通知が表示され続けているか確かめてください。すべてのアプリのバッテリー管理を無効にせず、問題のあるクライアントだけで比較します。プロセスが動作しているのに接続が切れる場合は、スリープ中にネットワークが切り替わったか、リモート接続の再確立が必要か、VPNが解除されたことを示すシステムログがないか確認します。

Wi-Fiとモバイルネットワークを切り替えると、接続中のアドレスや通信経路が変わり、既存の接続が使えなくなることがあります。まずクライアントの接続を停止して再起動し、対象アプリで確認します。「再接続すれば復旧する」場合と「特定のネットワークで常に失敗する」場合を区別してください。公衆Wi-Fiだけで失敗するなら、まずログイン認証を完了します。モバイルネットワークだけで失敗するなら、通常の接続、DNS、アクセス経路を確認してください。原因を記録せずに機内モードの切り替えを繰り返したり、根拠なくAPNやシステムのネットワーク設定を変更したりしないでください。

インストールの互換性と復旧後の確認

インストールに失敗した場合は、プロセッサーのアーキテクチャ、システム要件、空き容量、同名アプリの署名が競合していないか確認します。比較的新しい一般的な端末では通常arm64が適しています。判断できない場合はダウンロードページの説明に従って汎用パッケージを選んでください。ほかのアプリのフォルダーからファイルを抜き出して、手動で補わないでください。上書きインストールができない場合は、設定をバックアップし、システムの案内を確認してからアンインストールするか決めます。アンインストールすると、サブスクリプションや設定が削除される場合があります。パッケージはAndroidのダウンロードページから選び、異なるクライアントの設定フォルダーを混在させないでください。

同じノードでv2rayNGは正常なのにv2flyNGが失敗する場合は、端末の異常と決めつけず、プロトコルや設定がそのコアに対応しているか確認してください。問い合わせにはクライアント名、ネットワークの種類、動作モード、アプリごとの設定、問題が起きる操作を記載し、機密情報を削除したエラー部分を添えます。設定の基本手順をやり直す場合はクイックスタートガイドへ、設定の意味だけ確認したい場合はよくある質問をご覧ください。原因の特定を再インストールで済ませないようにしましょう。