V2Rayのトラブル対処ガイド：タイムアウト・サブスクリプション・システムプロキシ

01 / 影響範囲を確認する

インターネットに接続できない：ローカル接続から確認

「接続成功」と表示されても、通常はクライアントが通信の処理を開始したことを示すだけで、接続先のウェブサイトにアクセスできるとは限りません。ブラウザーでページを開けない場合は、発生時刻、使用中のノード、プロキシモード、影響を受けるアプリを記録し、すべての接続が切れているのか、特定のサイトだけ失敗するのかを確認します。条件を記録しておけば、後のテスト結果を比較できます。ノードとネットワークを同時に切り替えると、一時的に復旧しても何が効いたのか判断しにくくなります。

まず基本のネットワーク接続とプロキシ経路を切り分ける

まずクライアントでシステムプロキシを解除し、有効になっているTUNモードも一時的に停止してから、普段は直接アクセスできるサイトを開きます。それでも接続できない場合は、Wi-Fiにウェブ認証が必要か、LANケーブルが接続されているか、システムの日付が正しいか、ほかの端末から同じネットワークを利用できるかを確認してください。この段階では、サブスクリプションやルーティングを変更しないでください。プロキシ以前の基本接続に問題があるため、先にネットワークを復旧してからクライアントを再起動します。

基本のネットワーク接続に問題がなければ、v2rayNを開き、テストする設定を選んでアクティブサーバーに指定し、画面下部またはログウィンドウを確認します。目立つエラーを探すだけでなく、起動直後に設定の解析失敗、待ち受けアドレスの競合、コアプロセスの終了が起きていないかを確認してください。画面が開いても、コアが起動しているとは限りません。コアが正常に待ち受けていないと、ブラウザーからローカルポートへリクエストを送っても先へ進めません。

「設定 → パラメーター設定」でローカルの待ち受けポートを確認します。画面によっては「Core 基本設定」に関連項目があり、名称は実装によって異なります。チュートリアルの例をそのまま入力せず、実際の値を記録してください。ここに記載する 10808 はあくまで例です。クライアント側の設定が異なる場合は、テストコマンドのポートも合わせて変更します。システムプロキシ、ブラウザーの手動プロキシ、クライアントの待ち受けポートは一致している必要があります。

プロキシを明示したテストで原因を絞り込む

以下のWindowsコマンドは、まずループバックアドレスでプログラムが待ち受けているか確認し、次にSOCKSプロキシを明示してリクエストを送ります。2つ目のテストは、そのポートでSOCKSサービスが提供されている場合に限り有効です。混合ポートを使う場合も、該当プロトコルに対応しているか確認してください。例ではテスト用ドメインを使用しています。実際の再テストでは、アクセス可能とわかっているHTTPSアドレスを選びます。例のサイトに一時的にアクセスできないだけで、クライアントの故障と判断しないでください。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

ポートテストに失敗した場合は、コアの起動状態とポートの競合を確認します。ポートテストは成功するのにリクエストが失敗する場合は、同じ時刻のコアログを確認し、ノード接続とドメイン名の解決を調べてください。プロキシを明示したリクエストが成功する一方、ブラウザーでは失敗する場合は、少なくともそのプロキシ経路は機能しています。クライアントをすぐに再インストールせず、ブラウザーの拡張機能、システムプロキシ、アプリ独自のプロキシ設定を確認しましょう。

すべてのアプリの問題か、特定のアプリだけの問題かを見分ける

特定のウェブサイトだけ開けない場合は、同じ種類の別のサイトでも試し、ログでどのアウトバウンドが選択されているか確認します。他のサイトに問題がなければ、接続先サイト、ルーティングルールの適用、証明書、アカウント状態が原因かもしれません。ブラウザーにHTTPエラーページが表示される場合は、接続タイムアウトとは状況が異なります。明確な応答ステータスが返っているなら、リクエストが何らかのサービスに届いている可能性があり、すべてのページエラーをノードの切断とみなすことはできません。

特定のアプリだけ失敗する場合は、システムプロキシを参照するアプリか確認します。独自のネットワーク設定を使うプログラムもあれば、UDP通信を使うものもあります。ブラウザーでページが開けるからといって、すべてのアプリが正常に動くとは限りません。まずアプリ設定でプロキシのプロトコルとポートを確認してください。より多くの通信を経由させる必要がある場合は、TUNモードの権限とルーティングへの影響を確認してから使いましょう。複数の通信制御ツールを同時に有効にして試すと、通信の経路を特定しにくくなります。

02 / 接続の確立過程を確認する

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

タイムアウトは、ある処理が制限時間内に完了しなかったことを示すもので、ノードの設定ミスを直接意味するわけではありません。クライアントの遅延テスト、TCP接続、TLSハンドシェイク、実際のウェブリクエストでは、接続先やテスト方法が異なる場合があります。そのため、結果を相互に置き換えることはできません。まず元のエラーと発生時刻を記録し、「ローカルの待ち受け → サーバーアドレスの名前解決 → サーバーポート → プロトコルのハンドシェイク → 接続先へのアクセス」の順に確認します。

クライアントが実際に使っている設定を確認する

v2rayNで、アクティブサーバーが今テストした項目と一致しているか確認します。同じ名前のノード、異なるサブスクリプショングループ、更新後に再表示された古い設定に注意してください。ノード名はラベルにすぎず、実際のアドレスやプロトコルを示すものではありません。編集画面を開き、サーバーアドレス、ポート、ユーザーID、トランスポート方式、TLS設定を確認して、設定提供元の情報と一つずつ照合します。見覚えのある値だからといって、手動で補完しないでください。

TLSを使用する設定では、サーバーアドレスとハンドシェイクに使うサーバー名が異なる場合があります。後者は通常、SNIまたはserverNameに対応します。WebSocketを使う場合はパスとHost、gRPCを使う場合はサービス名も確認してください。各項目には用途があるため、ウェブサイトのドメイン名に安易に置き換えてはいけません。サブスクリプションから正しくインポートした設定は、まず元の値を保ったまま、別の項目や古い設定を誤って選んでいないか確認しましょう。

システム時刻もハンドシェイクに影響します。ログに証明書の有効期間前、期限切れ、名前の不一致が表示された場合は、まず端末の日付、タイムゾーン、自動時刻設定を確認し、次にサーバー名を照合してください。証明書検証の無効化を通常の修復方法にしないでください。アドレス設定の誤りや中間機器による干渉を見逃すおそれがあります。端末の時刻が正しいのに証明書に問題がある場合は、サービスの管理者に証明書とサーバー設定を確認してもらいましょう。

ポートへの到達性とプロトコルの動作を分けて確認する

Windowsでは、以下のコマンドでリモートのTCPポートを確認できます。ここに記載するアドレスとポートは構文の例なので、設定にある実際の値に置き換えてください。テスト中は、ユーザーIDを含む完全なリンクを公開しないでください。成功しても、確認できたのはTCP接続が確立したことだけです。認証、TLS、トランスポート層、プロキシのアウトバウンドが正常とは限りません。失敗の原因も、クライアントの画面とは限らず、ファイアウォール、ネットワーク経路、サーバーの待ち受け状態などが考えられます。

Test-NetConnection -ComputerName example.com -Port 443

TCPポートに接続できない場合は、まず同じ端末で正常とわかっている別のネットワークに切り替えて再テストし、別の設定とも比較します。接続タイムアウトには時間がかかるため、短時間に大量のテストを繰り返さないでください。特定のネットワークだけで失敗するなら、ネットワークの違いを手がかりとして記録します。複数のネットワークから同じサーバーポートに接続できない場合は、サービスの管理者に待ち受けポート、受信ルール、証明書の更新状況、サービスの稼働状態を確認してもらいましょう。

よくあるログの手がかりと次に確認する項目
ログの手がかり	可能性のある段階	まず確認する項目
`connection refused`	接続の確立	接続先ポートが待ち受け中か、接続が明示的に拒否されていないか
`timeout`	前後のログを含めて判断	エラー直前の接続先アドレス、プロトコル、接続段階
`certificate`	TLSハンドシェイク	端末の時刻、サーバー名、証明書の有効期間
`EOF`	接続が切断された	認証、トランスポート設定、サーバー側の対応ログ

照合結果をもとに修復箇所を決める

ポートには到達できるのにハンドシェイクが失敗する場合は、プロトコルとトランスポートの設定を見直し、使用中のコアがその組み合わせに対応しているか確認します。V2FlyとXrayの機能は、すべての項目で完全に同じではありません。設定をインポートできても、現在のコアで実行できるとは限りません。起動ログに未対応の項目や機能が明示されている場合は、エラーが消えるまで項目を削除するのではなく、設定に対応したクライアントを選んでください。

ノードテストは成功するのに実際のリクエストだけ失敗する場合は、サーバーから接続先への到達性とクライアントのルーティングを確認します。ノードテストの成功が示すのは、テスト対象の経路が正常ということだけです。修復後は元の接続先へ再度リクエストを送り、ログで想定したアウトバウンドが選択されたか確認してください。段階ごとの詳しい解説はノードのタイムアウトを調べる手順をご覧ください。どの段階まで成功したか記録しておけば、最初から原因を推測し直さずに済みます。

03 / 取得と解析を切り分ける

サブスクリプションの更新失敗：まず更新経路を確認

サブスクリプションの更新には、URLからのコンテンツ取得、形式の判別、ノード一覧への反映という少なくとも3つの段階があります。「更新失敗」はどの段階でも発生し、保存済みノードに接続できるかどうかとは必ずしも関係ありません。まず現在のグループを残し、すべてのノードを削除するのは避けてください。「サブスクリプションを更新（プロキシを使用しない）」を使ったのか、プロキシ経由で更新したのか、ログに残った最後のサブスクリプション関連エラーは何かを記録します。

完全なURLを確認し、アクセス情報は公開しない

「サブスクリプショングループの設定」で対象グループを開き、URLに余分な空白、改行、日本語の句読点が入っていないか、クエリパラメーターが途中で切れていないか確認します。サブスクリプションURLにはアカウントを特定できる情報が含まれることが多いため、信頼できる提供元から完全なテキストを取得してください。ブラウザーに表示された一部だけをコピーしてはいけません。ここに記載する https://example.com/sub は例であり、有効なサブスクリプションではありません。ノードを取得する目的でクライアントに入力しないでください。

元のURLがチャット、スクリーンショット、公開文書などに掲載されたことがある場合は、提供元の手順に従ってサブスクリプションのアクセス情報をリセットし、新しいURLを使ってください。トラブル対処で記録するのは、ドメイン名を解決できるか、応答ステータス、エラーの概要だけで十分です。完全なURLを他人に渡す必要はありません。一時的に問い合わせる場合でも、クエリパラメーター、ユーザーID、サブスクリプションの応答内容は隠してください。ノード一覧にほかの接続情報が含まれている場合もあるため、名前を隠すだけでは不十分です。

アカウントが有効か、サブスクリプションの提供先が変更されていないか確認します。一覧が空の場合、現在のグループに利用可能な項目がない可能性もあれば、提供元がそのアカウントに設定を割り当てていない可能性もあります。クライアントがデータを解析できない問題とは別です。まず更新ログの応答内容と項目数を確認し、提供元にアカウントの状態を問い合わせてください。URLのパスを推測したり、アクセス情報を手動で変更したりして代わりの入口を探さないでください。

プロキシを使わない更新と、プロキシ経由の更新を個別にテスト

現在のノードが使えなくなり、サブスクリプションの更新にもそのノードが必要だと、「新しいノードを取得するには更新が必要だが、更新には新しいノードが必要」という循環に陥ることがあります。現在のネットワークからサブスクリプションのドメインに直接アクセスできる場合は、まず「サブスクリプションを更新（プロキシを使用しない）」を試します。直接接続できず、正常に使える設定が別にある場合は、プロキシ経由で更新します。どちらも失敗した場合は、結果を分けて記録し、「サブスクリプションが開けない」とだけ書かないでください。

ブラウザーでサブスクリプションURLを開くと、認証ページやウェブ上の案内が表示されるか確認できます。ただし、それだけでクライアントから更新できるとは限りません。ブラウザーは別のプロキシ設定、キャッシュ、ログイン状態を使用している場合があり、クライアントが受け取る応答も異なる可能性があります。ログイン、ウェブ認証、ネットワーク認証を求めるページでは、ステータス上は成功に見えても、クライアントが認識できるサブスクリプションデータではなくHTMLが返されることがあります。

サブスクリプションのエラー別対処
症状	優先して確認する項目	対処の方向性
ドメイン名の解決または接続がタイムアウトする	基本のネットワーク接続と、更新がプロキシ経由かどうか	更新経路を変更して再テスト
401または403が返る	アクセス情報、権限、提供元のアクセス方針	アカウントとサブスクリプションの入口を確認
404が返る	URLのパスが完全か、入口が移転していないか	完全なURLを再取得
取得は成功するが解析に失敗する	応答形式がクライアントに対応しているか	対応するサブスクリプション形式を選択

形式の互換性と更新後の変更を確認する

サブスクリプションの入口によっては、クライアントの種類に応じて異なる形式を返します。ブラウザーでダウンロードできても、その内容がv2rayN、v2rayNG、v2flyNGに適しているとは限りません。ログに取得済みと表示されているのにノードが認識されない場合は、提供元のサブスクリプション設定でクライアントに合った形式を選んでください。任意の設定ファイルの拡張子を変更したり、完全なサブスクリプションを出所不明の変換サービスに渡したりしないでください。接続情報が漏れるおそれがあります。

更新後にノード数が変わった場合は、項目が本当に失われたと判断する前に、現在の絞り込み条件、選択中のサブスクリプショングループ、一覧の並び順を確認します。同じ名前の項目でも更新後にアドレスが変わる場合があり、古い項目が置き換わっていても問題とは限りません。手動で追加した設定は独立したグループで管理しましょう。更新前に必要なローカルバックアップを取る場合も、公開共有フォルダーや自動アップロードされるスクリーンショット用フォルダーに保存しないでください。

04 / テスト条件をそろえる

速度が遅い：遅延と通信速度を切り分ける

ウェブページの表示が遅い、ダウンロード速度が低い、動画が頻繁にバッファリングする、といった症状は同じ種類の性能問題ではありません。ウェブページの表示には名前解決、接続、ハンドシェイク、複数のリソース取得が関わります。ダウンロードは継続的な転送能力、リアルタイムアプリはジッターやパケットロスの影響を受けます。まず何をするときに遅いのかを具体的にし、それに合った比較テストを選びましょう。ノード一覧の遅延値だけで順位を付けても、あらゆる用途で速いノードとは判断できません。

再現可能な条件で速度を比較する

テストでは端末、ネットワーク、接続先を同じにし、時間帯もなるべくそろえます。バックグラウンド同期、システム更新、ほかのダウンロードは停止してください。まずプロキシを使わない通信も遅くなっていないか確認し、同じリクエストでノードを比較します。テストサイトとノードを同時に変えると、接続先サーバーの負荷の違いが結果に混ざります。速度の変化はあくまで手がかりです。同じ条件で再テストし、一度の変動を安定した結果とみなさないようにしましょう。

v2rayNのテスト機能を使う場合は、まずTCP接続テストと実際のリクエストテストを区別します。前者は主に接続確立までの速さを確認し、後者はより多くの通信経路の影響を受けます。結果が空欄やタイムアウトでも、テスト先にアクセスできないだけで、すべての接続先に失敗しているとは限りません。テストの種類と接続先を記録し、ブラウザーでの実際のアクセス結果と合わせて判断してください。見栄えのよい数値を出すために設定を何度も変更すると、比較できなくなります。

Wi-Fiの電波が強くても、通信が安定しているとは限りません。同じPCでルーターに近づいてテストするか、可能なら有線接続と比較します。モバイルネットワークでは、電波状況の変化、テザリング、通信速度制限を確認してください。家庭内で複数の端末が大量のデータを同時に送受信している場合は、回線の混雑がすべてのノードに影響します。この場合、クライアントを変更しても解決しないことがあります。まずローカルネットワークの混雑を解消し、その後もプロキシ経由の通信が明らかに遅いか確認しましょう。

遅くなる段階を確認する

最初にページを開くときは遅いものの、更新後は明らかに速い場合は、DNS、接続の再利用、ハンドシェイクを確認します。開始直後は速いのにダウンロード中に徐々に速度が落ちる場合は、サーバーの帯域、接続先による速度制限、ネットワークの混雑を調べましょう。特定のサイトだけ遅い場合は、同じ種類の別サイトと比較し、ルーティングルールが適用されているか確認します。リクエストが適切でないアウトバウンドに送られていないかも確認してください。1つのサイトのために、すべての通信を同じルーティング方式に変更しないでください。

ログで接続が頻繁に再確立されていないか、名前解決が繰り返し失敗していないかを確認できます。ただし、トラブル対処中でも、非常に詳細なログを長期間有効にするのは避けてください。大量のディスク書き込みは負荷を増やし、アクセス履歴も多く残ります。問題の前後の短い時間だけ記録し、原因を特定したら通常のログレベルに戻してください。ログを共有する場合はエラーの前後だけを残し、サブスクリプションURL、ユーザーID、公開する必要のない接続先を削除します。

UDPを使うアプリでは、プロトコルの組み合わせ、クライアント設定、サーバーが該当する通信に対応しているか確認してください。ブラウザーでウェブページが開けても、リアルタイムアプリの通信経路が同じとは限りません。ネットワークによってUDPの扱いが異なることもあるため、アプリ自身の接続状態を確認します。TUNモードに切り替える前に、通信を取り込む範囲を確認してください。帯域を増やす機能ではなく、通信の入口を変えるものであり、出口の通信能力が増えるわけではありません。

リスクの高い設定で速度問題を覆い隠さない

大きなページの一部が読み込み中に止まる、接続によって長時間待たされる、といった場合は、追加の調査項目としてパスMTUを確認できます。ただし、最初から極端に小さな値を設定しないでください。まずDNS、プロトコルの互換性、接続先の問題を除外し、特定のネットワークやトンネルモードとの関連を確かめます。その後、クライアントの説明に沿って少しずつ調整し、元の値を記録してください。変更のたびに正常なサイトと問題が起きた接続先の両方で再テストし、一方の修復がほかの接続に影響しないか確認します。

トランスポート方式、マルチプレクス、並列処理の設定は、大きくするほどよいわけではありません。サーバーのリソースが限られていたり、通信経路が不安定だったりすると、並列数の増加で競合がひどくなる場合があります。設定が合わないと、マルチプレクスによる互換性の問題も起きます。まず設定提供元が案内する組み合わせを使い、明確な比較条件を用意できる場合に限って、一項目ずつ試してください。ローカル設定を変えずに別の利用可能なノードへ切り替えるだけで復旧するなら、設定を追加するよりノードの違いを記録するほうが有用です。

05 / どこでドメイン名を解決しているか確認

DNSの問題：名前解決の経路をたどる

DNSはドメイン名を接続に必要なアドレスへ変換しますが、プロキシ環境では、システム、ブラウザー、クライアント、リモート側が名前解決に関わる場合があります。「サーバーが見つからない」やドメイン名に関するタイムアウトが発生しても、すべてのDNSアドレスを同じパブリックサービスに置き換えるのは避けてください。まず失敗しているのがノードのサーバー名か、アクセス先サイトのドメイン名かを確認します。そのうえで、どの段階が名前解決を行い、クエリ自体に利用可能なネットワーク経路があるかを調べましょう。

接続先サーバーのドメイン名と、アクセス先のドメイン名を区別する

ノードに接続する前にサーバーアドレスの名前解決エラーが表示される場合、問題はプロキシの入口より前にあります。このとき、まだ確立していないプロキシにすべての名前解決を任せると、依存関係が循環するおそれがあります。まずシステムのツールでノードのドメイン名を検索し、現在のネットワークでDNSサービスに到達できるか確認してください。必要であれば設定提供元の案内に従って適切な名前解決経路を使用します。ただし、ノードのドメイン名を検索で見つけた任意のアドレスに置き換えないでください。証明書やルーティングがドメイン名に依存している場合があります。

ノードには接続できるのに一部の接続先ドメインだけ失敗する場合は、クライアントログの名前解決エラーとアウトバウンドの選択を確認します。ドメイン名に基づくルールで通信を振り分ける場合、ドメイン名が保持されるか、どの段階でアドレスに変換されるかがルールの適用に影響します。ブラウザーで独自のセキュアDNSを有効にしている場合、システムの検索結果と異なることもあります。現在の設定を記録したうえで、一度に1項目だけ変更して比較してください。ブラウザー、システム、クライアントのDNSを同時に変更しないでください。

以下のコマンドは、Windowsと一般的なデスクトップ環境で使用できます。コマンドで確認できるのは、主に現在のシステムの名前解決経路です。クライアント内蔵のリゾルバーでも同じ結果になるとは限りません。名前解決に成功した場合も、実際のHTTPSリクエストをテストしてください。解決されたIPアドレスへ直接アクセスする方法は同等のテストではありません。多くのウェブサイトは、証明書検証、仮想ホストの選択、コンテンツ配信にドメイン名を使用します。

# Windows PowerShell
Resolve-DnsName example.com

# nslookup が利用できるシステム
nslookup example.com

プロキシを使ったテストで名前解決の担当箇所を確認する

SOCKSのテストでは、socks5hを使うと接続先ドメイン名の解決をプロキシ側に任せます。一部のツールでsocks5を使うと、先にローカルで解決します。結果が異なる場合は名前解決経路の調査が必要ですが、この違いだけで問題の発生箇所を特定することはできません。クライアントのDNS設定、ルーティング方針、ログも確認し、リモートの名前解決リクエストがどこへ送られているか、誤ってローカルに戻されていないかを調べてください。

暗号化DNSを使う場合も、まずDNSサービス自体に接続できることを確認します。DNSサービスにドメイン名のアドレスを指定している場合は、その名前解決を行うための経路が必要です。DNSサービスへの接続が現在問題のある経路に依存していると、起動時に待ち続けることがあります。出所不明の設定全体をそのままコピーしないでください。どのドメイン名を処理するのか、どのアウトバウンドを使うのか、失敗時にどうするのかを明確にし、使用中のコアが対応する形式で設定しましょう。異なるコア用の項目を混在させないでください。

IPv4とIPv6の到達性の違いによって、「開けるときと開けないときがある」という症状が起きることもあります。ドメイン名から両方のアドレスが返されても、現在のネットワークでは一方にしか完全な経路がない場合があります。まずログを確認し、実際にどちらのアドレスが試されたかを比較します。その後、クライアントが対応する範囲で一時的な設定比較を行います。一度失敗しただけで端末全体のIPv6を恒久的に無効にしないでください。変更が問題に関係していることを確認し、元に戻すための記録も残しましょう。

DNSとルーティングルールを合わせて確認する

ルーティングの調査は、シンプルなルールから始めましょう。以下はXray形式のルーティング例であり、そのまま起動できる完全な設定ではありません。proxyとdirectは、既存のアウトバウンドのタグに合わせる必要があります。この例はドメイン名のルールとアドレスのルールの違いを示すもので、クライアントが生成した設定全体を置き換えるものではありません。GUIクライアントは通常、実行時の設定を再生成します。設定を維持する場合は、「ルーティング設定」など、サポートされている方法を使ってください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールは通常、上から順番に評価されます。先に範囲の広すぎるルールがあると、後続の細かいルールが適用されない場合があります。LANのアドレスを安易にリモートプロキシへ送ると、ローカルの管理ページやイントラネットのサービスに影響します。DNSを修正した後、同じ接続先が想定したアウトバウンドを使っているか確認してください。名前解決でアドレスが返っても、ルーティングと接続が完了したとは限りません。実際のリクエストログを1件残しておくと、動作確認に役立ちます。

キャッシュの削除は最後に検討します。Windowsのipconfig /flushdnsで消去されるのはシステムのDNSキャッシュだけです。ブラウザー独自のキャッシュ、クライアントのキャッシュ、リモート側のキャッシュは自動的に消去されません。まず原因を修正してから、対象のアプリを終了して再起動し、再テストしてください。キャッシュの削除で一時的にしか復旧しない場合は、何度も消去するのではなく、名前解決の設定とネットワーク切り替えを調べましょう。

06 / アプリの通信経路を確認する

システムプロキシが効かない：通信を取り込む範囲を確認

システムプロキシは、OSがアプリに提供するプロキシ設定であり、すべてのネットワーク通信を強制的に取り込む機能ではありません。v2rayNで「システムプロキシを自動設定」を選択すると、通常は該当する設定を参照するアプリだけがプロキシを使います。アプリ独自のプロキシ設定、ブラウザーの拡張機能、コマンドラインの環境変数、TUNモードが別の通信経路として使われている場合もあります。調査ではまず、対象のアプリがどの設定を参照しているか確認してから、該当箇所を修正してください。

システムのプロキシアドレスとローカルの待ち受けを確認する

Windowsでは、まずv2rayNの「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、次にシステムの「設定 → ネットワークとインターネット → プロキシ」で実際のアドレスとポートを確認します。設定項目は、クライアントの動作方法によって手動プロキシやセットアップスクリプトとして表示されることがあります。トレイアイコンの色だけで判断しないでください。ほかのプログラムがシステム設定を書き換えても、クライアントの画面にすぐ反映されるとは限りません。

アドレスがローカルループバックの場合は、クライアントが実際に待ち受けているポートと一致している必要があります。127.0.0.1は現在の端末だけを指し、同じ端末のアプリからクライアントに接続する際に使います。スマートフォンからPCのプロキシに接続するためには使えません。ポートを変更したことがある場合、システムやブラウザーに古い値が残っている可能性があります。まずプロキシを明示したリクエストで新しいポートをテストし、利用可能だと確認してからシステムプロキシを再設定してください。待ち受けていないアドレスに対して、モードを何度も切り替えるのは避けましょう。

macOSでは「システム設定 → ネットワーク」で現在のネットワークサービスを選び、「詳細 → プロキシ」から設定を確認します。画面の名称はシステムのバージョンによって多少異なります。Wi-Fiと有線接続で別々のネットワークサービスが使われることがあるため、ネットワークを切り替えた後は現在の項目を確認してください。Linuxのデスクトップ環境では、システムプロキシの設定場所やアプリがその設定を参照する方法が一様ではありません。独自の設定しか使わないアプリもあるため、別のデスクトップ環境の手順をそのまま当てはめないでください。

複数のプロキシ設定が上書きし合っていないか確認する

ブラウザーとほかのアプリで動作が異なる場合は、ブラウザーのプロキシ拡張機能を一時的に無効にし、起動オプションや管理ポリシーも確認します。コマンドラインツールでは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYなどの環境変数が参照される場合があります。環境変数を変更しても、起動済みのプロセスには古い値が残ることがあります。ターミナルやアプリを再起動してください。システムプロキシを切り替えても、これらの環境変数が連動して変更されるとは限りません。

通信経路ごとの確認箇所
通信経路	対象範囲	見落としやすい点
システムプロキシ	システム設定に従うアプリ	アプリ独自の設定やポリシーで上書きされる場合がある
アプリの手動プロキシ設定	指定したアプリ	プロトコルとローカルポートが一致している必要がある
環境変数	環境変数を参照するツール	起動済みのプロセスに古い設定が残る場合がある
TUNモード	仮想インターフェースとルーティングを使って通信を取り込む	適切な権限が必要。ルーティングの競合にも注意

システムプロキシやデフォルトルートを変更するツールを同時に複数実行しないでください。プロキシアドレスを交互に上書きしたり、直接接続するはずのプロキシ通信を別のトンネルへ送り直したりして、ループが発生するおそれがあります。まずほかの通信制御ツールを終了し、単一のクライアントと明確な通信経路だけを残して対象アプリをテストします。複数のツールを併用する必要がある場合は、各段階の待ち受けアドレスと通信の流れを確認してください。既定の設定が自動で連携すると決めつけないでください。

「システムプロキシを変更しない」は、「システムプロキシを解除する」という意味ではありません。前者は通常、現在のシステム設定を維持します。後者はクライアントが設定したプロキシを積極的に解除します。ウィンドウを閉じる、トレイから終了する、プロキシを解除する操作も、それぞれ別のものです。クライアント終了後にインターネットへ接続できなくなった場合は、システムプロキシがまだローカルポートを指していないか確認します。設定を正常な状態に戻してから再テストしてください。使えなくなったノードを再起動して基本ネットワークを維持しようとしないでください。

LAN共有とTUNを分けて調べる

スマートフォンからPCのプロキシを使う場合は、PCの「パラメーター設定」で「LANからの接続を許可」を有効にし、待ち受けポートとPCのLANアドレスを確認してから、必要に応じてファイアウォールの受信ルールを設定します。ファイアウォールのルールは信頼できるネットワークと必要なポートだけに限定し、トラブル対処のために保護機能全体を無効にしないでください。スマートフォンとPCがLAN内で相互に通信できる必要があります。ゲストネットワークの端末隔離やテザリングの制限で接続できないこともあります。

TUNモードに問題がある場合は、仮想インターフェース、権限、ルートが正常に作成されたか確認します。有効にした後、ノードサーバー自体にも接続できなくなった場合は、出口の通信が再び取り込まれるループが起きていないか調べてください。まずTUNを無効にし、ローカルプロキシを明示してノードが使えることを確認します。その後、TUNだけを有効にして比較してください。LAN共有の詳しい手順はLAN接続を許可する設定をご覧ください。再テストでは、対象アプリだけでなく、ローカルネットワークのサービスにも引き続きアクセスできるか確認します。

07 / 画面とコアプロセスを切り分ける

クライアントがクラッシュする：状況を記録してから修復

クライアントが起動しない、ウィンドウがすぐ閉じる、ノードのコアが終了する、といった問題は分けて対処します。前の2つは主にGUIに影響しますが、コアの終了では画面が表示されていてもすべてのリクエストが失敗する場合があります。OS、CPUアーキテクチャ、ダウンロードしたパッケージの種類、起動・インポート・接続のどの段階で問題が起きたかを記録してください。ユーザーディレクトリ全体をすぐ削除するのは避けましょう。サブスクリプショングループ、ルーティングルール、問題のログまで消え、原因を特定しにくくなることがあります。

インストールパッケージとシステム環境を確認する

まずクライアントのダウンロードページで、プラットフォームとアーキテクチャが合っているか確認します。Windows版v2rayNのデスクトップ版と従来のWPF版は異なるUI実装です。動作に必要な依存関係やシステム要件は、選択したパッケージの説明で確認してください。macOSではApple SiliconとIntelを区別し、LinuxではCPUアーキテクチャとディストリビューションのパッケージ形式を確認します。ダウンロードが完了しても、端末に適したパッケージとは限りません。アーキテクチャが合わない場合、起動時に終了することがあります。

Windowsで実行環境の不足が明示された場合は、エラーに記載されたコンポーネントとアーキテクチャに対応してください。出所不明のDLLファイルを個別にダウンロードしないでください。ポータブル版はフォルダー全体を解凍してから実行します。メインプログラムだけを圧縮ファイルから取り出して実行してはいけません。パスのアクセス権、テンポラリーフォルダーの削除、セキュリティソフトによるファイルの隔離も、起動不良の原因になることがあります。システムの通知を見ながら一つずつ確認し、すべての問題をOSのバージョンのせいにしないでください。

macOSで開発元を確認できないと表示された場合は、まずファイルの入手元とダウンロードしたパッケージの種類を確認し、「システム設定 → プライバシーとセキュリティ」に表示される案内に従ってください。アプリを開くためにシステムのセキュリティ機能全体を無効にしないでください。ファイルの破損、コンポーネントの不足、アーキテクチャの不一致も、すべて権限の問題とは限りません。macOSでの初回起動と権限を参考に、ブロックの通知と実際のプログラム異常を切り分けてください。

何度も再起動せず、ログを確認する

画面が開く場合は、クライアントログとコアログがそれぞれ出力されているか確認します。インポート直後に設定エラーが表示されるなら、最初に記録された解析失敗や未対応項目を探してください。その後に大量の接続エラーが続いていても、最初のエラーの影響かもしれません。接続をクリックするたびにポート競合が表示される場合は、別のインスタンスがすでに実行されていないか確認します。ポートを次々に変更すると、システムプロキシと待ち受けポートの設定がさらに食い違うおそれがあります。

Windowsでは、以下のコマンドで例示したポートを待ち受けているプロセスIDを確認できます。番号が表示されたら、タスクマネージャーでプログラムを特定してください。不明な番号だけを根拠にシステムプロセスを終了しないでください。同じクライアントが複数起動している場合は、余分なインスタンスをトレイから正常に終了し、1つだけ再起動します。別のサービスがそのポートを必要としている場合は、クライアントに空いているポートを設定したうえで、そのポートを参照するアプリの設定もすべて更新してください。

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

LinuxのGUIプログラムが起動直後に終了する場合は、インストール済みのプログラムをターミナルから起動し、依存関係、ディスプレイ環境、権限に関するエラーを確認できます。アプリをテストする前に、パッケージインストーラーのエラーも解消してください。実行ファイルだけを手動でコピーしても、必要な依存関係がそろうとは限りません。通常のユーザー権限で動作するなら、利便性のために管理者権限で起動し続けないでください。ネットワークの通信制御に特別な権限が必要な場合は、その機能だけ個別に対応します。

最小限の設定で問題の範囲を特定する

ユーザー設定の破損が疑われる場合は、まずプログラムを終了し、クライアントがサポートする方法で設定フォルダーをバックアップします。元のファイルは変更せずに保管してください。新しい設定環境が必要なら、新しいユーザーデータディレクトリを使うか、説明に従ってリセットします。インストール先を変えただけで設定も独立するとは限りません。まず初期状態で画面が開くことを確認し、次に正常とわかっている設定を1つだけ追加します。すべてのルーティング、サブスクリプション、カスタム設定を一度にインポートしないでください。

最小構成で問題がなければ、サブスクリプション、ルーティング、特殊なネットワーク機能の順に一つずつ戻し、そのたびにテストします。特定の項目を戻した後にクラッシュが再現すれば、すべての設定を破棄せずに原因の範囲を絞れます。GUIのバージョンによって動作が異なる場合は、デスクトップ版とWPF版の違いを確認し、システムに合ったものを選んでください。ただし、UIの変更をノードやDNSの問題全般に対する解決策と考えないでください。

08 / Androidのネットワークとバックグラウンド制限

モバイル端末のトラブル：権限とネットワーク切り替え

Androidでは、まずv2rayNGを使用します。V2Flyコアとの互換性が必要な場合は、v2flyNGも選択肢になります。画面上の操作は似ていますが、コアの対応範囲や一部の設定が完全に同じとは限りません。接続済みなのにアクセスできない、画面ロック中に切断する、ネットワークの切り替え後に使えなくなる場合は、サーバーやDNSの設定に戻る前に、VPNの許可、アプリごとのルーティング、バックグラウンドでの動作状態を確認してください。モバイルOSの制限をサーバーの故障と誤認しないようにしましょう。

VPNサービスが実際に起動したか確認する

初めて接続を開始するとき、システムからVPN接続の許可を求められます。許可した後、クライアントは対応するローカル仮想ネットワークインターフェースを作成できます。ステータスバーにVPNのアイコンが表示されても、わかるのはサービスが作成されたことだけで、リモートノードに接続できたとは限りません。起動後すぐにアプリのログを確認し、設定の解析失敗、権限の拒否、サービスの即時終了がないか調べてから、接続できるとわかっているサイトにアクセスしてください。

同じユーザー環境では、通常、複数のアプリがVPNサービスを同時に制御することはできません。別のネットワークツール、仕事用プロファイルのポリシー、システムサービスが通信経路を使用していると、新しい接続で既存サービスが置き換えられたり、接続できなくなったりする場合があります。まず他の通信制御アプリを停止し、クライアントを1つだけ起動してください。組織の管理下にある端末では、管理ポリシーがVPN設定を制限していないか確認します。端末自体の権限要件を回避するために、異なるクライアントを次々にインストールしないでください。

「常時接続VPN」や「VPNを使用しない接続をブロック」が有効だと、クライアントが未起動または接続失敗の際に、システムポリシーによってほかの通信もブロックされることがあります。トラブル対処を始める前に、これらの設定を記録してください。必要であれば基本ネットワークとの比較中だけ一時的に無効にし、終了後に必要に応じて元に戻します。アプリ内の接続を停止しただけで、無効になったサービスを経由するようシステムが引き続き要求していないかも確認してください。

アプリごとのプロキシ設定とバックグラウンド動作を確認する

一部のアプリだけに問題がある場合は、クライアントでアプリごとのプロキシや除外リストが有効になっていないか確認します。現在のモードが「選択したアプリのみをプロキシ経由にする」か、「選択したアプリをプロキシから除外する」かにも注意してください。同じアプリ一覧でも、モードによって意味が逆になります。設定を変更した後は接続を再確立し、対象アプリも完全に終了してから起動し直します。古い接続が以前の経路を使い続けるのを防ぐためです。仕事用プロファイルと個人用プロファイルが分かれている場合は、テスト中のアプリがどちらに属しているかも確認してください。

画面をロックすると切断し、画面を点灯すると復旧する場合は、システムのバッテリー最適化、バックグラウンド通信、メーカー独自の自動起動管理が原因かもしれません。設定のアプリ情報でバッテリー設定とバックグラウンド通信の権限を確認し、接続を維持する必要がある場合は適切な権限を付与してください。端末全体の省電力機能を無効にする必要はありません。切断時にVPNアイコンが消えるか、アプリのサービスが再起動するか、ログに再起動の記録があるかを確認し、プロセスの終了とリモート接続のタイムアウトを切り分けましょう。

フォアグラウンドサービスの通知は、動作状態を確認する手がかりになります。通知表示を個別に管理するシステムもあります。通知が消えても、コアが停止したとは限りません。システムのVPN状態とログを合わせて判断してください。一方、通知が残っていてもリモートへの接続が使えるとは限りません。バックグラウンド権限を見直しても同じ条件で切断される場合は、画面ロックの時間、電源の状態、ネットワークの種類を記録して、一つずつ比較しましょう。システム設定を複数同時に変更しないでください。

ネットワーク切り替え後に名前解決と通信経路を再確認する

Wi-Fiからモバイルデータに切り替えると、既存の接続が使えなくなり、DNS、IPv6、デフォルトルートも変わることがあります。まずネットワークの準備が整うのを待ち、クライアントを切断して再接続してから、新しいリクエストをテストしてください。特定のWi-Fiだけで失敗する場合は、ウェブ認証の有無や端末の隔離を確認します。モバイルデータだけで失敗する場合は、すべてのアプリデータをリセットするのではなく、ノードのポートへの到達性と名前解決の結果を比較しましょう。

スマートフォンからPCの共有プロキシに接続する場合は、Wi-Fiのプロキシ設定にPCのLANアドレスと実際のHTTPポートまたは混合ポートを入力します。スマートフォン自身のループバックアドレスは使えません。また、SOCKS専用のポートをHTTPポートとして指定しないでください。この設定が影響するのは、通常、Wi-Fiのプロキシ設定に従うアプリだけです。テスト前にPCが起動していること、クライアントが待ち受けていることを確認し、システムプロキシの章を参考にLAN接続とファイアウォールを確認してください。

インポートは成功するのに起動時にエラーが出る場合は、設定が必要とするコアの機能を確認します。v2rayNGとv2flyNGは、それぞれが対応する設定形式と機能の組み合わせで使ってください。ノード名を変更しても互換性は確認できません。再インストールが必要な場合は、AndroidのダウンロードページからCPUアーキテクチャに合ったパッケージを選びます。比較的新しい端末の多くはarm64に対応しています。判断できない場合は、ファイルサイズから推測せず、汎用パッケージの説明を確認してください。