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

インターネットに接続できない：リクエストが止まる箇所を確認

「クライアントが起動している」ことと「アプリがプロキシ経由で通信できる」ことは別です。通常、通信はアプリ、システムプロキシまたは仮想ネットワークアダプター、ローカルインバウンド、ルーティングルール、リモートノードを経て、接続先のサービスに届きます。どこか一つでも機能していなければ、Webページが開かないことがあります。まず、すべてのアプリで失敗するのか、特定のブラウザーだけなのか、すべてのサイトで失敗するのか、特定のドメインだけなのかを記録してください。クライアントを終了したときに通常のネットワーク接続が戻るかも確認しましょう。こうした範囲の特定は、単独のエラーメッセージより原因の絞り込みに役立ちます。

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

ほかのプロキシツールを終了し、v2rayNのシステムプロキシとTUNを無効にして、普段から直接アクセスできるページが開くか確認します。この状態でも失敗する場合は、ネットワーク接続、ゲートウェイ、Wi-Fiの認証ページ、システムDNSを先に確認してください。ノードを切り替えるのはその後です。公衆Wi-Fiでは先にログインが必要なことがあり、プロキシ起動後は認証ページが表示されなくなる場合があります。通常接続に問題がないことを確認したら、v2rayNを起動し、設定済みのノードを選択してシステムプロキシを有効にし、同じブラウザーで同じテストページにアクセスします。

続いてクライアントのログを開き、表示を消去するか開始時刻を記録してから、リクエストを一度送信します。新しい接続記録がなければ、アプリがシステムプロキシを使っているか、ローカルポートが正しいか、ブラウザーの通信が拡張機能に横取りされていないかを確認しましょう。ログに接続先のドメインとアウトバウンドが記録されていれば、リクエストは少なくともコアに届いています。次に、名前解決、リモート接続、ハンドシェイク、接続先の応答のどこで失敗したかを調べます。通常はログレベルを「情報」に設定すれば十分です。詳細レベルへの変更は、問題箇所を特定するときだけ一時的に行ってください。

システムプロキシを介さずローカルインバウンドをテスト

以下ではSOCKSインバウンドを使って比較します。ポートはクライアントの設定画面に表示されている実際の値に変更してください。例の10808は、すべての環境で共通する固定ポートではありません。Windowsではターミナルでcurl.exeを、macOSとLinuxでは通常curlを使います。テスト用のURLは接続が完了するかを確認するためのもので、すべての用途で正常に動作することを示すものではありません。HTTPステータスが返っても、それだけでプロキシの異常とは限りません。接続が確立したかどうかも併せて確認しましょう。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --noproxy "*" --connect-timeout 10 -I https://example.com

1つ目はプロキシを明示して、2つ目はプロキシを経由せずに実行します。それぞれの結果を記録してください。socks5hでは接続先ドメインの名前解決をプロキシ側に任せるため、今回のテストにアプリ側のローカルDNS解決が混ざるのを防げます。1つ目でローカルポートへの接続に失敗した場合は、コアが起動してリッスンしているかを確認します。プロキシ経由のリクエストは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ設定、拡張機能、キャッシュが原因である可能性が高いでしょう。HTTPインバウンドのポートをSOCKSのポートとして使わないでください。プロトコルが一致しないと、応答が空になったりプロトコルエラーが発生したりします。

ルーティングの誤りと接続先サービスの障害を見分ける

リクエストがコアに届いたら、実際に選択されたアウトバウンドがdirect、proxy、blockのどれかを確認します。あるサイトへの通信が誤ってblockに振り分けられている場合、ノードを切り替えても解決しません。どのドメインルールに一致したかを確認しましょう。誤ってdirectに振り分けられた場合も、接続がタイムアウトすることがあります。切り分けのため、一時的にシンプルなプロキシルーティングへ切り替えて同じリクエストを再試行してください。復旧した場合は、ルールを一つずつ元に戻します。この比較は原因の特定に使うもので、すべての通信を長期的に同じアウトバウンドへ送ることは推奨しません。特に、LANやノードサーバーへの適切な直接接続経路は確保してください。

よく使うサービスは複数動作するのに、特定の接続先だけ失敗する場合は、接続先サイトのメンテナンス、アカウント制限、サーバー側の地域制限、ブラウザーのセッション異常も考えられます。クライアントの再インストールを繰り返すより、別のブラウザーセッションや同じネットワーク上の別の端末と比較するほうが効果的です。修復後は、プロキシ経由の接続先、直接接続する接続先、LAN内の接続先をそれぞれテストし、ログ上のアウトバウンドが想定どおりか確認してください。接続が戻ってもルーティングが誤っていれば、完全に修復したとはいえません。

ノードのタイムアウト：アドレス・ポート・ハンドシェイクを切り分ける

ノードのテストがタイムアウトしても、サーバーが停止しているとは限りません。クライアントのテストには、ドメインの名前解決、トランスポート接続の確立、プロトコルのハンドシェイク、テスト用URLへのアクセスなどが含まれる場合があり、どの段階の失敗もタイムアウトとして表示されることがあります。まず、すべてのノードで同時に失敗するのか、特定の設定だけなのかを確認してください。現在のネットワークだけで失敗するのか、別のネットワークでも失敗するのかも比較します。すべてのノードで問題が起きている場合は、ローカルネットワーク、DNS、プロキシのループ、テスト用URLを優先して確認しましょう。特定のノードだけ失敗する場合は、そのノードの設定を一つずつ確認します。

接続先を確認し、設定値の入力場所を間違えない

ノードの編集画面を開き、サービス提供元の設定情報と照らし合わせてサーバーアドレス、ポート、プロトコル、トランスポート方式、セキュリティ設定を確認します。サーバーアドレスには通常、ドメイン名またはIPアドレスを指定します。Webページのプロトコル部分やパスを含めないでください。WebSocketのパス、Host、TLSのSNIは別々の項目です。文字列が似ていても相互に置き換えることはできません。ポートにはリモートサービスの待ち受けポートを指定します。ローカルSOCKSポートはアプリからクライアントへ接続するためのものです。これをサーバーポートに入力すると、接続先が誤ったサービスになります。

サブスクリプションから取得したノードの場合は、変更されたアドレスを使い続けないよう、先にサブスクリプションを更新してください。ただし、更新するとサブスクリプション管理下のノード設定が上書きされます。手動で変更する前に、比較用のコピーを保存しておきましょう。比較では変更する項目を一つに絞り、トランスポート、ポート、セキュリティ設定を同時に変更しないでください。パスワード、ユーザーID、公開鍵などは書式が正しくてもサーバー側の設定と一致しない場合があります。タイムアウト時間を延ばしても解決しないため、有効な設定を改めてインポートしてください。

エラーの種類から接続が止まった段階を判断する

ログにconnection refusedと表示される場合、接続要求が拒否された可能性があります。ポート、サービスの稼働状況、中継機器のポリシーを確認してください。i/o timeoutやダイヤルタイムアウトは、制限時間内に処理が完了しなかったことを示すにすぎません。network is unreachableは、ローカルのルーティングやアドレスファミリーの問題が考えられます。これらをすべて同じ原因として扱わないでください。また、サーバーからping応答がないだけでプロキシが使えないと判断するのも避けましょう。サーバーがその種の探査を許可していなくても、通常の接続は受け付けている場合があります。

TCP接続の確立後にTLSや認証のエラーが発生する場合は、ハンドシェイク設定を確認します。まずシステム時刻を同期し、SNI、証明書のドメイン名、クライアントで選択したトランスポートがサーバー側と一致しているかを確認してください。REALITYでは公開鍵、Short ID、サーバー名、フィンガープリントなども確認し、選択したコアがその組み合わせに対応していることを確かめます。切り分けの際は、サービス提供元が明確にサポートする設定を使いましょう。別のプロトコル用の値を現在のノードに混在させないでください。

ネットワーク経路とプロキシループを確認する

同じノードを、別の信頼できるネットワークでテストします。スマートフォンのテザリングでは接続できるのに、現在のWi-Fiでは失敗する場合は、Wi-Fi側の外向き接続制限、アドレスファミリーへの対応、ファイアウォールを重点的に確認してください。どのネットワークでも失敗する場合は、設定とリモートサービスを調べます。ネットワークを切り替えた後は接続を確立し直し、切り替え前のセッションを使い続けないでください。ノードのドメイン名が複数のアドレスファミリーのアドレスを返す場合、名前解決できても到達できないアドレスが接続を遅らせることがあります。実際にダイヤルしたアドレスを確認してから、アドレス選択の設定を見直しましょう。

TUNを有効にした後にタイムアウトする場合、ノードサーバーへの通信が再びプロキシに送られ、ループしている可能性があります。ノードサーバーのアドレスが正しく除外されているか、クライアントが対応する直接接続ルートを維持しているかを確認してください。もう一つの原因は、サブスクリプションURLやノードのドメイン名の名前解決が、まだ確立していないプロキシのアウトバウンドに依存していることです。まずTUNを無効にし、通常のネットワークで名前解決とサブスクリプション更新を行ってから、機能を一つずつ戻すと、依存関係の問題とリモート側への到達不能を切り分けられます。

最後に、ノードへの接続と実際のサービスへのアクセスを分けて確認します。クライアントのテスト用URLに問題があると、正常な複数のノードがまとめて失敗と表示されることがあります。Webページに実際にアクセスできる場合は、すべてのノードをすぐに削除せず、テスト用URLとテスト方法を確認してください。エラーが発生した時刻、使用したネットワーク、エラーの種類を記録し、サービス提供元に問い合わせる際は認証情報を伏せましょう。証明書に関する問題は、TLSハンドシェイクと証明書エラーの対処法も参照してください。修復後は元のルーティングと動作モードに戻して確認します。

サブスクリプション更新失敗：ダウンロード・解析・ノード更新を切り分ける

サブスクリプションの追加には、URLの保存、サブスクリプション内容のダウンロード、内容のノード一覧への変換という3つの段階があります。リンクを保存できてもダウンロードに成功したとは限らず、テキストを取得できてもクライアントが解析できるノード形式とは限りません。まず、どの段階でエラーが起きたか、更新後に一覧が実際に変わったかを確認しましょう。登録済みのノードは接続できるのに更新だけ失敗する場合は、使える設定を残したまま更新経路の修復を優先してください。調査に必要な接続手段を失わないよう、ノード一式を削除するのは避けましょう。

URLとサービスの状態を先に確認

サブスクリプションのグループ設定でURL全体を確認します。コピー時に改行、前後の空白、全角記号が混ざっていないか、特に注意してください。URLにクエリパラメーターやアクセストークンが含まれる場合、「?」より前だけを残したり、文字を変更したりしないでください。ブラウザーで開く管理ページとサブスクリプション用のAPIは、同じとは限りません。サービス提供元がサブスクリプションURLとして明示しているアドレスを使いましょう。URLの期限切れ、アカウント状態の変更、アクセストークンの再発行などにより、以前のURLがエラーページを返すこともあります。

応答の種類から原因を絞り込めます。認証エラーやアクセス拒否は、認証情報、アカウント権限、サービスのポリシーに関係することが多く、リソースが見つからない場合はパスが変更された可能性があります。リクエスト制限がかかっているときは更新頻度を下げ、再試行が許可されるまで待ってください。サーバーの一時的なエラーを、ノードのパスワード変更で解決しようとしないでください。応答ステータスが成功を示していても、ログインページや案内文が取得されている場合があります。クライアントの解析エラーも確認し、受信した内容がWebページではないことを確かめましょう。

「サブスクリプションにプロキシが必要、プロキシにはサブスクリプションが必要」という依存を解消する

現在のネットワークから直接アクセスできず、利用可能なプロキシ経由での更新が必要なサブスクリプションURLもあります。その場合はクライアントのプロキシ経由での更新機能を選び、現在のノードが実際に接続できることを確認してください。クライアントをインストールしたばかりでノード一覧が空の場合、利用可能なアウトバウンドがないためプロキシ経由の更新は失敗します。まずサービス提供元から取得した単一ノードの設定で初回接続を確立し、その後にサブスクリプションを更新してください。単独で使える設定がない場合は、アクセス可能なサブスクリプションURLをサービス提供元に確認しましょう。接続できないノードを何度も切り替えるのは避けてください。

反対に、直接アクセスできるサブスクリプションURLがプロキシ経由の更新で失敗する場合は、プロキシ側のDNS、証明書、外向き接続の制限が原因かもしれません。同じURLを使い、直接接続とプロキシ経由の両方で更新して結果を記録してください。一方だけ失敗する場合は、ダウンロード経路に問題を絞り込めます。ブラウザーでは開くのにクライアントで失敗するときは、ブラウザーが別のプロキシ、ログインセッション、自動リダイレクトを使っていないかも確認しましょう。ブラウザーのアカウント状態がクライアントのサブスクリプションリクエストに引き継がれるとは限りません。

形式を確認し、解析エラーをネットワークタイムアウトと混同しない

v2rayN、v2rayNG、v2flyNGで対応するプロトコルや設定形式は、それぞれの実装と使用するコアによって異なります。サービス提供元がクライアントごとに異なる接続先を用意している場合もあり、別の種類の設定ファイルをダウンロードすると、内容が完全でもインポートできないことがあります。まずサブスクリプションURLが現在のクライアント向けかを確認し、エラーが形式の認識失敗、未対応ノードの一部、データが空のいずれなのかを調べてください。未対応の項目があっても、インポートを成功させるためにセキュリティ設定をむやみに削除しないでください。元の接続の意味が変わる可能性があります。

更新に成功したのに新しいノードが見つからない場合は、選択中のサブスクリプショングループ、検索フィルター、並び順を確認してください。更新によりノードIDが置き換わると、選択中のノードがなくなることがあります。その場合はノードを選び直し、設定を適用します。ノード名が同じでも、サーバーアドレスやパラメーターが更新されている可能性があるため、詳細を比較してください。一部のノードしか表示されない場合は、プロトコルの対応状況やサブスクリプションサービスから返された内容を確認してから、クライアント側のデータ欠落を疑いましょう。

更新頻度を調整し、実際の結果を確認する

更新ボタンを連続して押すことを再試行の手段にしないでください。リクエストが多いとサービス側の制限にかかることがあり、ログから個々の操作を特定しにくくなります。自動更新をいったん停止し、手動更新を一度だけ実行して、時刻、ダウンロード経路、エラーを記録してから原因に対処しましょう。自動更新を再開するときは適切な間隔を設定し、複数の端末から同じURLへ短時間に何度もアクセスしないようにしてください。ネットワークが復旧した直後は、まずノードへの接続を確認してからサブスクリプションを更新すると、失敗したリクエストが重なるのを防げます。

修復後は、グループの更新が成功したこと、ノードを選択できること、コアに新しい設定が読み込まれたことを確認してから実際に接続します。サブスクリプションで同期されるのは通常ノードの情報であり、デスクトップとAndroidのルーティング、DNS、アプリごとの振り分け、TUN設定まで完全に一致するとは限りません。PCで更新に成功しても、スマートフォン側の確認にはなりません。端末間の設定同期については、v2rayNとv2rayNGのマルチデバイス設定同期を参照してください。使える設定は安全な場所にバックアップし、認証情報を含むエクスポートファイルを公開ディレクトリに保存しないでください。

速度が遅い：接続確立の遅さと継続通信の遅さを切り分ける

速度低下には、ページを開くまでに時間がかかる、転送開始後も遅い、通信が途切れて再開するという少なくとも3つの症状があります。それぞれDNSやハンドシェイク、継続的な帯域や輻輳、ネットワーク切り替えやパケットロスが原因かもしれません。速度テストの数値だけでなく、実際の症状を記録してください。小さなファイルはすぐダウンロードできるのに大きなファイルは遅い場合と、どのWebサイトも初回表示が遅い場合では、調査する箇所が異なります。ノードの性能差と接続先サーバーの違いを混同しないよう、同じノード、接続先、端末で比較しましょう。

条件を固定し、再現できる比較を行う

ネットワークを使用中の同期、ダウンロード、システム更新を停止してから、同じ操作をもう一度行います。Wi-Fiではアクセスポイントの近くで比較し、可能であれば有線接続と無線接続も比べてください。プロキシを使わない通信も遅い場合は、まずローカルネットワークを調べましょう。プロキシ経由の通信だけが遅い場合は、同じネットワークで利用できる2つのノードを比較します。ノードの切り替えとDNSやルーティングの変更を同時に行うと、改善しても原因を判断できません。

テストする接続先も統一しましょう。ダウンロードサイトによっては単一接続の速度を制限しており、Webページ内の外部リソースも異なるネットワークにある場合があります。一つの速度テストだけで動画、オンライン会議、ファイルのダウンロードすべてを評価することはできません。最大瞬間速度より、最初の応答までの待ち時間、転送開始後の安定性、接続の繰り返しを記録するほうが実用的です。同じノードでも時間帯によって速度が変わる場合は、ネットワークの混雑が考えられます。似た条件で繰り返し確認し、すぐにクライアントを再インストールするのは避けましょう。

初回アクセスが遅い場合は、DNS・ハンドシェイク・リトライを確認

ページの初回表示が遅く、2回目以降は明らかに速い場合は、名前解決にかかる時間、アドレスの選択、接続の再利用を確認します。ノードや接続先のドメイン名が複数のアドレスを返すと、クライアントが到達できないアドレスを先に試し、失敗後に別のアドレスへ切り替えることがあります。ログに繰り返しのダイヤル、ハンドシェイクの失敗、名前解決のタイムアウトがないかを確認しましょう。「速度テストの数値が低い」という情報より、原因に近い手掛かりになります。システム時刻、トランスポート設定、DNS経路を確認し、何度も再試行した末に偶然つながっていないかを見極めてください。

ページの主要部分はすぐ表示されるのに、画像、フォント、スクリプトの読み込みが長引く場合は、リソースのドメインが別のアウトバウンドに振り分けられているか、ブロックルールがページの読み込みに影響している可能性があります。ブラウザーのネットワークパネルで失敗したリソースのドメインを確認し、クライアントのログと照合してください。サイト全体をノードの速度低下と決めつけないようにしましょう。ルーティングを一時的にシンプルな設定にして復旧する場合は、ルールの順序とルールセットの内容を一つずつ確認します。具体的なドメインのルールは、より広い範囲に適用されるルールより前に置き、先行ルールに先に一致しないようにしてください。

転送中の速度が遅い場合は、輻輳・端末の負荷・通信条件を確認

転送開始後から安定して遅い場合は、まず端末のCPU、メモリ、ディスクが上限近くまで使用されていないか確認します。バックグラウンドの大量接続、詳細すぎるログ、リアルタイムスキャン、省電力モードも負荷を増やすことがあります。モバイル端末は発熱による性能低下で、同じ接続が徐々に遅くなる場合があります。デスクトップでは通常の電源モードで再テストし、Androidでは温度とバックグラウンドの処理も確認してください。効果を判断しにくい最適化設定を重ねるより、不要な同時接続を減らすほうが原因を特定しやすくなります。

TUNモードで大きなファイルの転送が止まり、システムプロキシでは正常な場合は、仮想ネットワークアダプターの経路、MTU、追加のカプセル化を確認します。小さなパケットは通るのに大きなパケットを正常に処理できない経路では、接続の確立後に転送が止まることがあります。インターネット上で見つけたMTUの固定値をそのまま設定するのは避けましょう。まず2つのモードを比較し、仮想ネットワークアダプターを使う経路で問題が起きると確認できてから、クライアントが提供する設定を少しずつ変更してください。変更を元に戻せるようにし、実際に利用する操作で再テストします。

プロトコル名だけで速度は決まりません。VMess、VLESS、Trojan、Shadowsocksの速度は、トランスポートの組み合わせ、サーバーの負荷、ネットワーク経路にも左右されます。サーバー側で対応する設定がないままプロトコルだけを変更しても、速度の改善にはつながりません。まずプロキシプロトコルの違いと用途を読み、各設定の役割を理解したうえで、サービス提供元が対応する組み合わせを選んでください。修復後はよく使うサービスに加え、ルーティングの変更で直接接続する通信が遅くなっていないかも確認します。

DNSの問題：システム・コア・プロキシ側の名前解決を区別する

DNSはドメイン名をIPアドレスに変換しますが、プロキシ環境ではすべての名前解決が同じ場所で行われるわけではありません。アプリがローカルで名前解決してからIPアドレスをプロキシに渡す場合もあれば、ドメイン名をSOCKSまたはHTTPプロキシに渡し、コアやリモート側で処理する場合もあります。TUNがシステムのDNSリクエストを引き受けることもあります。そのため、システムのコマンドでアドレスを取得できても、その経路が動作していることしか確認できず、ブラウザー、コア、リモート側の経路が正常とは限りません。調査を始める前に、どのドメインで失敗しているか、どの層が名前解決しているかを確認してください。

ノードのドメイン名と接続先のドメイン名を別々に確認

ノードサーバーにドメイン名を使っている場合、クライアントはまずノードのアドレスを名前解決する必要があります。接続が確立してから、接続先のWebサイトへアクセスできます。この2つの名前解決は別の処理です。ログでノードのドメイン名を解決できていない場合は、起動時に使われるDNSを確認し、接続先サイトのルーティングは変更しないでください。接続先のドメイン名を解決できない場合は、アプリがドメイン名を渡しているか、コアで必要なDNS設定が有効か、選択したDNSサーバーが想定するアウトバウンド経由でアクセスできるかを調べます。

Windows、macOS、Linuxでは、必要なツールが使えるターミナルで以下のクエリを実行し、基本的な比較ができます。出力があるかどうかだけではなく、返されたアドレス、使用されたDNSサーバー、エラーの種類を確認してください。システムでの問い合わせが成功してもプロキシ経由の通信が失敗する場合は、コアのログを調べます。クエリ結果がキャッシュ由来の可能性もあるため、設定変更後は新しい経路で名前解決が行われたかを確認しましょう。Webページを何度も再読み込みしても、ブラウザーに保存された古い結果が使われ続けることがあります。

nslookup example.com

プロキシを使ってローカルとプロキシ側の名前解決を見分ける

SOCKSのテストでは、通常socks5を使うとcurlがローカルで接続先ドメインを名前解決し、socks5hではドメイン名をプロキシ側に渡します。同じ接続先をそれぞれの方式でテストすると、ローカルDNSが問題に関係しているかを調べられます。ここでも実際のSOCKSポートに置き換えてください。一方の方式が成功しても、もう一方を恒久的に無効にすべきとは限りません。2つの経路に違いがあることを示す結果です。実際のルーティング要件とアプリの動作に応じて方式を選びましょう。

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

プロキシ側の名前解決は正常でローカル側が失敗する場合は、システムDNS、ブラウザーのセキュアDNS、ネットワーク事業者が提供するDNSを確認してください。両方失敗してもログのエラーが異なる場合は、それぞれ個別に対処し、複数箇所を一度に変更しないでください。ブラウザー独自の暗号化DNSが有効だと、システムDNSを変更しても影響しない場合があります。反対に、ブラウザーでの名前解決が正常でも、ほかのアプリが正常とは限りません。切り分けのため、ブラウザーに一時的にシステム設定を使わせて比較し、確認後は用途に合った設定に戻してください。

ルーティングにおけるドメイン判定の仕組みを理解する

domainStrategyは、ルーティングの照合時にドメイン名をIPアドレスへ解決するかどうかに影響します。V2Ray系のコアでは、AsIs、IPIfNonMatch、IPOnDemandの目的はそれぞれ異なり、単純な速度設定の段階として考えることはできません。以下はルーティング設定の一部であり、そのまま起動できる完全な設定ではありません。direct、proxy、blockという名前のアウトバウンドと、対応するルールデータがすでにあることを前提としています。GUIクライアントでは、生成済みの設定全体を直接上書きせず、ルーティング設定画面から入力することを優先してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

末尾に一致するルールが明示されている場合、それ以降の名前解決の動作はルールの順序とコアの実装にも左右されます。特定の戦略を選べばすべてのリクエストで必ずIP照合が行われるとは考えないでください。変更後は設定名だけで判断せず、実際のログを確認します。広告ドメイン、LANのIPアドレス、地域別ドメインのルールでは、それぞれ必要な情報が異なります。ルールセットの欠落や無効なカテゴリ名が設定の読み込み失敗につながることもあります。ルールの順序について詳しくは、geositeとgeoipを使ったルーティング設定の実践を参照してください。

名前解決の依存ループを避け、仮想IPを慎重に扱う

暗号化DNSサーバーへの接続も必要です。DNSサーバーへの通信にプロキシが必要なのに、ノードのアドレス解決にも同じDNSサーバーが必要な場合、依存ループが発生することがあります。起動に必要な名前解決へ到達できる経路を確保し、DNSリクエストが想定したアウトバウンドを通るか確認してください。仮想IPによるマッピングを使う場合、システムが返すアドレスは実際のサーバーアドレスとは限りません。これは仕組みの一部です。ただし、クライアント終了後に残ったルート、古いキャッシュ、LAN内のドメイン名の誤ったマッピングにより、アプリが接続できなくなることがあります。

修復する際は、まず最小限のDNS設定に戻し、競合するDNSの引き継ぎ機能を無効にしてから、一つずつ追加します。LAN内のホスト名、プリンター、内部サービスは通常ローカルで名前解決する必要があるため、すべてをリモート側に任せるのは適切ではありません。変更のたびに、ノードのドメイン名、プロキシ経由の接続先、直接接続先、LAN内の名前をテストし、4つの用途すべてが正常か確認してください。fake DNS、ドメイン判定、ルールセットの意味は用語クイックリファレンスで確認できます。一つのWebサイトを開くためにDNS全体の仕組みを壊さないようにしましょう。

システムプロキシが効かない：アプリの接続経路とTUNの対象範囲を確認

システムプロキシはOSがアプリに提供するプロキシ設定であり、すべての通信を強制的に引き受けるものではありません。システム設定に従うブラウザーは通常これを使いますが、コマンドライン、一部のゲーム、独自のネットワークスタックを持つソフトウェアは無視することがあります。TUNは仮想ネットワークアダプターとルーティングを使って通信を引き受けます。対象範囲が異なるうえ、権限、ルーティング、DNSなど追加の条件もあります。アプリがシステムプロキシを使わない場合は、まずそのアプリの通信方式を確認してください。「システムプロキシが有効」だけでは、すべての通信がコアに届く証拠にはなりません。

システムに実際に保存されている設定値を確認する

v2rayNでシステムプロキシを有効にしたら、OSのネットワーク設定を開き、プロキシのアドレスとポートが現在のクライアントのローカルHTTPインバウンドまたは混合インバウンドに切り替わっているか確認します。アドレスには通常ループバックアドレスを使いますが、ポートは実際の設定値である必要があります。コアのリッスンポートを変更してもシステムプロキシが古いポートを指したままだと、システム設定に従うアプリはすべて接続できません。システムに手動プロキシではなく自動構成スクリプトが表示される場合は、どちらの方式が使われているかも確認し、設定が互いに上書きされないようにしてください。

ブラウザーのプロキシ拡張機能、別のプロキシツール、端末管理ポリシーなど、プロキシ設定を書き換える可能性のあるソフトウェアを終了します。会社の端末や管理対象端末では、ポリシーによってプロキシ設定が固定され、クライアントで変更しても元に戻る場合があります。この場合は端末管理の要件に従い、システム設定を何度も上書きしないでください。個人端末では、クライアントの有効化前後で値が変わるかを確認し、v2rayNが現在使用中のネットワーク設定を操作しているかを確かめます。すでに切断された接続の設定を変更していないかも確認しましょう。

アプリのログからプロキシ経由かどうかを確認する

新しいリクエストを送信し、クライアントの接続ログを確認します。ログがない場合は、アプリ独自のプロキシ設定を確認してください。ログがあるのにアウトバウンドがdirectの場合は、システムプロキシ自体は機能していて、ルーティングによって直接接続されている可能性があります。外部IPを確認するページでアドレスの変化を見る方法には限界があります。そのページへの通信が直接接続のルールに一致していると、表示が変わらなくてもプロキシの故障とは限りません。リクエストがコアに届いたか、どのアウトバウンドが選ばれたかを併せて確認し、入口とルールのどちらに問題があるか判断してください。

ターミナルのプログラムは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYの影響を受けることがあります。小文字の環境変数だけを認識するアプリや、一部の設定しかサポートしないアプリもあります。まずコマンドでプロキシを明示してローカルインバウンドが動作するか確認し、その後で環境変数を調べてください。NO_PROXYに接続先のドメインやネットワークが含まれていると、そのリクエストはプロキシを経由しません。環境変数を変更した後は、アプリやターミナルを再起動する必要がある場合があります。起動中のプロセスが新しい値を読み込むとは限りません。

TUNの起動失敗と、起動後の異常を分けて対処する

TUNを起動できない場合は、まずログに記録された権限、仮想ネットワークアダプターの作成、ルート設定のエラーを確認します。デスクトップOSでは権限の昇格やネットワークコンポーネントの許可が必要な場合がありますが、システムの保護機能を恒久的に無効にしないでください。ログで拒否された操作に限って対処します。コアが起動していても仮想ネットワークアダプターの作成に失敗している場合、画面に稼働中と表示されてもTUNによる通信の引き継ぎは成功していません。クライアントの動作モード、アダプターの状態、起動ログを確認してください。

TUNの起動後にネットワークが使えなくなった場合は、TUNを無効にして同じノードをシステムプロキシでテストします。システムプロキシでは正常なら、ルーティング、DNSの引き継ぎ、ほかの仮想ネットワークアダプターとの競合が疑われます。複数のVPNや仮想ネットワークツールを同時に動かすと、デフォルトルートが何度も切り替わることがあります。ノードサーバーへの通信には正しい外部経路が必要で、LAN用の除外ルールも必要です。除外項目をすべて削除するとノードへの接続やローカルサービスまで引き受けることがあるため、避けてください。

終了後にネットワークを復旧し、元に戻せる手順を残す

クライアントが異常終了すると、システムプロキシがすでに閉じたローカルポートを指したまま残ることがあります。この場合、ブラウザーでは接続できないのに、プロキシを使わないテストは成功するという結果が手掛かりになります。システムプロキシの設定を開いて残った項目を削除し、TUNのアダプターやルートも残っていないか確認してください。通常は、クライアントを正常に終了して再起動し、設定画面から無効にするほうが、アダプターを直接削除するより安全です。ネットワーク設定を手動で変更する前に、特に管理対象ネットワークでは元の値を記録しておきましょう。

修復の最後に、ブラウザー、ターミナル、システムプロキシに従わないアプリをそれぞれテストしてください。一つのアプリだけを確認して修復済みと判断してはいけません。LAN内の端末と直接接続する接続先にアクセスできること、クライアント終了後に通常のネットワークが復旧することも確認します。アプリ単位のプロキシとTUNにはそれぞれ適した用途があります。必要を満たせる、変更項目の少ない方式を優先してください。基本操作はクイックスタートガイドで確認できます。トラブルシューティング中に新しいルーティングテンプレートや別の通信モードを同時に導入するのは避けましょう。

クライアントのクラッシュ：画面・コアの終了と設定エラーを切り分ける

クライアントのウィンドウが突然閉じる、ウィンドウは開いたままなのに通信できない、起動ボタンを押すとすぐ停止する。これらの症状は原因が異なります。v2rayNのGUIとプロキシコアは別の要素です。画面が正常でもコアが動作しているとは限らず、コアが終了してもウィンドウが閉じるとは限りません。まず、起動直後、特定のノードをインポートした後、TUNを有効にした後、しばらく使用した後など、発生条件を記録してください。一つの操作で安定して再現できることが、問題を特定する最良の手掛かりです。

設定とログを保存してからインストールを修復する

画面を開ける場合は、クライアントの機能で必要な設定をエクスポートし、現在のサブスクリプショングループ、ルーティングモード、DNS設定を記録します。バックアップには認証情報が含まれる場合があるため、安全な場所に保存してください。画面を開けない場合も、ユーザーデータのディレクトリをすぐに削除しないでください。先にディレクトリのコピーを保管し、起動ログやシステムのアプリケーションエラー記録を確認しましょう。問い合わせ用にログをコピーする前に、サーバーの認証情報、サブスクリプションURL、ユーザーパスなど不要な機密情報を削除してください。

再インストールする前に、ダウンロードページでOSとプロセッサーのアーキテクチャを確認してください。Windows版v2rayNのデスクトップ版と従来のWPF版は別の画面構成です。一方のプログラムファイルをもう一方のフォルダーに混在させないでください。macOSではチップに合ったパッケージを選び、Linuxではプロセッサーのアーキテクチャとディストリビューションのパッケージ形式を確認します。依存関係が不足していると表示された場合は、具体的なエラーに基づいて公式の実行環境を追加してください。出所不明のポップアップから修復コンポーネントを入手しないでください。

画面がクラッシュする場合は、起動時のエラーとリソースを確認する

起動直後に終了する場合は、システムがアプリの実行をブロックしていないか、インストールが完了しているか、ユーザーデータの保存先に書き込み可能かを確認します。macOSではアプリを適切なアプリケーション用フォルダーへ移動してから、システムのセキュリティ警告に対処してください。Linuxではグラフィカルターミナルからインストール済みのプログラムを起動し、標準エラー出力とデスクトップセッションに必要なコンポーネントを確認できます。パスの権限や依存関係の異常には具体的な手掛かりがあるはずです。エラー全体を隠すために管理者権限で使い続けないでください。

しばらく使ってからクラッシュする場合は、多数の接続、ログの蓄積、スリープからの復帰、表示環境の変化との関連を確認します。ディスクの空き容量とメモリの負荷を調べ、不要な詳細ログを減らし、同じ操作で再現するかテストしてください。スリープ後にネットワークインターフェースが変わることがあります。アプリを再インストールする前に、接続を再起動してみましょう。特定の画面操作だけで問題が起きる場合は、その操作を一時的に避けて接続を維持し、再現手順を記録してください。まれなシステムの問題を、すべてのノード設定の破損と誤認しないようにしましょう。

コアがすぐ終了する場合は、最初に表示された設定エラーを確認する

設定の読み込みに失敗すると、項目、アウトバウンドのタグ、ルールデータ、待ち受けポートなどがログに示されます。まずログの中で最初に記録された有効なエラーに対処してください。その後に続く大量のエラーは、最初のエラーに起因する場合があります。ポートが使用中なら、どのプログラムが使用しているかを調べ、二重起動したクライアントを終了するか、ローカルインバウンドのポートを変更してからシステムプロキシの設定も合わせます。コアを起動するために、すべてのルーティングルールを削除するのは避けてください。ルールデータの不足とアウトバウンド名の誤りは別々に修正します。

特定のノードだけでコアが終了する場合は、プロトコルとコアの対応状況を確認します。v2rayNGは主にXrayコアを、v2flyNGはV2Flyコアを使用しており、対応する機能は完全には同じではありません。v2rayNでコアを切り替えても、未対応の組み合わせが自動的に互換性を持つわけではありません。ノード、トランスポート、コアの対応を確認し、必要であれば有効なサブスクリプションから改めてインポートしてください。REALITYなど接続に必要な項目を削除して読み込みエラーを回避しないでください。起動できても、正しく接続できるとは限りません。

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

バックアップを保存してから、利用実績のあるノードを1つ、基本的なルーティング、デフォルトのDNSだけを使った比較環境を作ります。TUN、複雑なルール、カスタム設定は一時的に無効にしてください。最小構成で正常に動作する場合は、サブスクリプショングループ、ルーティング、DNS、通信の引き継ぎ機能を一つずつ戻し、そのたびに再テストします。これにより、問題の原因を具体的な設定層に絞り込めます。比較環境で元の環境と同じポートを同時にリッスンしたり、複数のクライアントでシステムプロキシ設定を取り合ったりしないでください。

修復後は正常に終了して再起動し、サブスクリプション、ノード、システムプロキシ、TUNが実際に動作しているか確認してください。再インストールだけで復旧しても、古い設定を戻した後に再発するなら、インストーラーではなく設定に問題がある可能性が高いでしょう。コアとクライアントの関係については、このサイトとProject Vエコシステムについてを参照してください。問い合わせ時には、設定全体をアップロードするより、OS、アーキテクチャ、クライアント名、発生手順、機密情報を除いたエラー文を伝えるほうが安全で、再現にも役立ちます。

Androidの接続トラブル：VPNの許可・アプリの振り分け・バックグラウンド制限を確認

Android版のv2rayNGとv2flyNGはシステムのVPNインターフェースを使って通信を引き受けるため、デスクトップのシステムプロキシとは調査方法が異なります。ステータスバーにVPNアイコンが表示されても、システムインターフェースが確立したことを示すだけで、リモートノードへの接続成功までは確認できません。有効なノードを選び、起動時の許可を完了してから、ブラウザーでリクエストを送信しクライアントのログを確認してください。起動直後に停止する場合は、許可、設定の読み込み、ほかのVPNとの競合を先に調べます。起動状態を保っているのに接続できない場合は、ノード、DNS、ルーティングの順に確認しましょう。

システムの許可とVPNの使用状態を確認する

初回接続時には通常、システムのVPN接続リクエストを許可する必要があります。許可画面をキャンセルした、別のウィンドウの背後に隠れている、端末のポリシーでVPN機能が制限されているといった理由で、インターフェースを確立できない場合があります。システムのVPN設定で現在の接続状態を確認し、通信を引き受けているほかのVPNアプリを停止してください。ローカルの通信フィルターアプリの中にも同じインターフェースを使うものがあり、一見関係がなくても競合することがあります。まず通信を引き受けるアプリを一つだけにして比較し、日常的な利用時の起動順を検討してください。

システムで常時接続VPNやVPNを経由しない通信のブロックが有効になっていないか確認します。指定されているVPNアプリが別の停止中のアプリだと、通常のネットワークにも接続できなくなる場合があります。現在のクライアントが異常終了し、VPNを経由しない通信を禁止する設定が有効なままの場合も、端末全体がオフラインになります。設定を変更する前に機能を理解し、テスト後は用途に合わせて元の設定に戻してください。すべての制限を恒久的に無効にするのは避けましょう。管理対象端末では管理者のポリシーに従ってください。許可の制限を再インストールの繰り返しで解決することはできません。

一部のアプリだけ接続できない場合は、アプリの振り分けリストを確認する

アプリごとの振り分けには、選択したアプリだけをプロキシ経由にする方式と、選択したアプリを除外する方式があります。同じリストでもモードが違えば結果は正反対です。まず現在のモードを確認し、接続できないアプリがリストに含まれているか調べてください。システムコンポーネント、仕事用プロファイルのアプリ、個人用アプリでは、通信の引き継ぎ対象が異なる場合があります。ブラウザーでは接続できるのに別のアプリで失敗するときは、すぐにノードを切り替えず、そのアプリのリクエストがクライアントのログに記録されるかを確認しましょう。

アプリの通信がVPNに入った後も、ドメイン名やIPアドレスに基づくルーティングが適用されます。アプリのリストは通信を引き受けるかを決め、ルーティングは引き受けた後にどのアウトバウンドを使うかを決めます。両者は互いに置き換えられません。独自のDNS、固定IP、長時間接続を使うアプリは、ブラウザーと異なる動作をすることがあります。ルーティングを変更した後は、アプリを完全に終了してから再起動し、古い接続が従来の経路を使い続けないようにしてください。LAN内の端末に接続できない場合は、すべての通信をプロキシに送るのではなく、LANの直接接続ルールとアプリの対象設定を確認します。

画面消灯後に切断される場合は、バッテリーとバックグラウンドの制限を確認

画面を表示している間は正常なのに、消灯後に失敗する場合は、バックグラウンド制限が原因である可能性があります。システムのバッテリー設定でクライアントのバックグラウンド動作が許可されているか、省電力モード、バックグラウンドデータ制限、端末メーカー独自のタスク終了設定が有効か確認してください。設定名は端末によって異なるため、機能を手掛かりに探します。変更後は同じように画面を消灯した状態で接続を観察してください。画面が点灯している間だけテストしても、バックグラウンドの問題が解決したとはいえません。

プロセスの停止と一時的なネットワーク切断も区別してください。クライアントがすでに終了している場合はバックグラウンド管理を重点的に確認します。クライアントが動作中なのにログに切断が記録される場合は、Wi-Fiとモバイルネットワークの切り替え、ネットワークのスリープ、リモート側のセッション終了が考えられます。バックグラウンド実行を許可しても、すべてのセッションが切断されなくなるとは限りません。ネットワークの変化後にクライアントが再接続する必要があります。切り替え後は新しい接続が確立するまで待ち、新しいリクエストを送信して確認してください。古いセッションの失敗だけで、現在のネットワークが使えないと判断しないようにしましょう。

モバイルネットワークとWi-Fiを別々に確認

同じノードがWi-Fiでは正常でモバイルネットワークでは失敗する場合は、アドレスファミリーとDNSの違い、システムのデータセーバーによる制限を確認してください。切り分けのため、追加設定したプライベートDNSを一時的に無効にして比較する方法もありますが、恒久的な無効化を勧めるものではありません。UDPを使う通信だけが失敗する場合は、ノード、トランスポート、サーバーが該当する転送に対応しているか確認します。Webページが開くからといって、すべてのプロトコルが正常とは限りません。通常のHTTPリクエストで確認できるのは別の種類の通信経路です。

Wi-Fiの切り替え後、初回接続が遅い場合は、古いDNSキャッシュやアドレスの変化が関係していることがあります。まず接続を停止して再起動し、ログに記録されたサーバーアドレスが現在の名前解決結果に基づくか確認してから、DNS設定を見直してください。認証が必要な公衆ネットワークでは、VPNの起動前にログインを済ませます。クライアント終了後もネットワークに接続できない場合は、システムのネットワーク設定とVPNポリシーを確認し、ノードの設定は変更しないでください。TLSに影響することがあるため、Android端末の時刻とタイムゾーンが自動で同期されているかも確認しましょう。

用途に合ったクライアントを選び、接続全体を検証する

Androidではv2rayNGを第一候補とし、V2Flyコアを使うv2flyNGを代替候補にできます。ただし、クライアントの変更ですべての問題が解決するわけではありません。特定のコア機能を必要とするノードは、互換性を確認してからインポートしてください。端末のアーキテクチャに合ったインストールパッケージを選び、判断できない場合はAndroidのダウンロードガイドで該当する項目を確認しましょう。インストールに失敗したからといって、ノードのプロトコルをむやみに変更しないでください。2つのクライアントでサブスクリプションを共有していても、アプリのリスト、DNS、ルーティングはそれぞれ確認する必要があります。

最後に、画面表示中のアクセス、消灯後の新しいリクエスト、Wi-Fiとモバイルネットワークの切り替え、LANへのアクセス、VPN停止後の通常接続の復旧を確認します。それぞれ同じ用途で比較し、ほかの場面に悪影響がないことも確かめてください。初回設定の手順はサブスクリプションの追加と接続ガイドを参照してください。用語が分からない場合は、まず用語クイックリファレンスを確認しましょう。正常に動作する設定と、個人情報を除いた調査記録を残しておけば、同じ症状が再発したときに確認済みの箇所から調査を続けられます。