V2Rayが接続できない
トラブル対応まとめ

再現可能な診断手順を先に作る

まず障害がどの層で起きているかを判断する

V2Rayクライアントの接続は、基本ネットワーク、クライアント画面、プロキシコア、リモートノード、システムプロキシまたは仮想ネットワークアダプター、DNS名前解決、対象アプリという少なくとも7つの段階を通ります。ページが開かないのは最終的な症状にすぎず、ノードの停止を直接示すものではありません。基本ネットワークの切断、コアの未起動、古いポートを向いているシステムプロキシ、ノードパラメータの不一致、ドメイン名の解決異常など、似た症状はさまざまな原因で発生します。効果的な確認方法は、すべてのスイッチを何度も切り替えることではなく、障害の境界を先に見極めることです。クライアントの接続を無効にした状態で通常のネットワークにアクセスできるか、クライアントログにコアの起動成功が出ているか、ローカルの待受ポートが存在するか、ノード接続がTCP確立時に失敗しているのかTLSまたはプロトコルのハンドシェイク時に失敗しているのか、ブラウザだけに影響しているのかすべてのアプリに影響しているのかを確認します。

現場の情報として、使用中のプラットフォームとクライアント、障害発生前に行った変更、影響を受けるアプリの範囲、ログに最初に出たエラーの4点を先に記録しましょう。最後の数十行をコピーするより「最初のエラー」を記録する方が有用です。その後に続く接続終了や再試行失敗は、連鎖的に発生した結果であることが多いためです。購読更新後に問題が起きた場合は、すぐに削除せず古い設定グループも残してください。古い設定は動作し、新しい設定だけが動作しないなら、確認範囲を購読内容や新しいパラメータに絞れます。新旧どちらも動作しない場合は、ネットワーク、システムプロキシ、クライアントの動作状態を優先して確認します。

変更する変数を最小限にして再現する

各テストでは条件を1つだけ変更し、変更後は完全に再接続してください。たとえばノードをテストする場合は、同じネットワーク、同じクライアント、同じルーティングモードを固定し、ノードだけを1つ切り替えます。システムプロキシをテストする場合は、接続できることが分かっているノードを固定し、「システムプロキシを無効」「システムプロキシを自動設定」「TUNモード」を個別に比較します。ノード変更、購読更新、コア切り替え、DNS変更を一度に行うと、接続が復旧しても何が効いたのか分からず、次の障害も繰り返します。

最小限のテスト環境はできるだけ単純にします。重複して起動しているプロキシツールを終了し、ネットワークスタックを変更するデバッグソフトを閉じ、ブラウザ独自のプロキシ設定を一時停止し、クライアントの標準ルートを使用します。デスクトップではまずv2rayNを基準にテストし、Androidでは購読が必要とするコアに応じてv2rayNGまたはv2flyNGを選びます。クライアントの入手元やアーキテクチャが不明な場合は、先にダウンロードページでプラットフォームとインストール形式を確認してください。コアが起動できない状態でルーティングルールを調べ続けても、上位層のテストはすべて意味を失います。

ログは段階を示すキーワードに注目して読む

ログは「error」だけを検索するのではなく、処理段階ごとに読み取ります。待受アドレスとポートが表示されていれば、コアが設定を読み込み、ローカル接続の受付を開始したことを示します。接続拒否は、対象ポートでサービスが動作していないか、中間機器が明示的に拒否している可能性があります。タイムアウトは、所定時間内に接続が完了しなかったことを示します。証明書のドメイン不一致、ハンドシェイク失敗、サーバー名に関する表示が出た場合は、システム時刻、SNI、TLS、トランスポート設定を確認してください。DNSクエリ失敗が出た場合は、まず名前解決の経路を確認します。ログにはサーバーアドレスや購読情報が含まれることがあるため、他人に渡す前にアカウント識別子、認証情報、完全な購読URLを削除してください。

クライアントを起動するとまったくインターネットに接続できない

基本ネットワークの障害とプロキシ引き継ぎの障害を分ける

最初にv2rayNのシステムプロキシを無効にするか、Androidクライアントの接続を終了します。ただし設定を急いで削除してはいけません。その後、ブラウザで普段開けるサイトにアクセスし、LANゲートウェイも確認します。プロキシを無効にしてもアクセスできないなら、原因は基本ネットワーク、無線接続、ゲートウェイ、システムDNSにあり、ノードを切り替えても意味がありません。プロキシを無効にした直後に復旧するなら、クライアントは通信を引き継いでいるものの、ローカルプロキシが正しく転送できていません。よくある原因は、コアが起動していない、システムプロキシのポートと実際の待受ポートが一致していない、選択した設定が利用できない、ルートがすべてのリクエストを誤った出口へ送っていることです。

デスクトップでは、障害の影響範囲も確認します。ブラウザとシステムコンポーネントの両方が失敗するなら、まずシステムプロキシを確認します。特定のアプリだけが失敗する場合は、そのアプリがシステムプロキシを無視していないか、独自のプロキシアドレスを保存していないかを確認します。LANアドレスにもアクセスできない場合は、ルーティングモードがプライベートアドレスまで誤ってプロキシ経由にしていないかを確認します。TUNモードで全アプリが同時にオフラインになる場合は、仮想ネットワークアダプター、ルーティングテーブル、DNSの引き継ぎ、実行権限を重点的に確認します。「システムプロキシ」と「TUN」は同じ機能ではありません。前者は主にシステムプロキシ設定に従うアプリの入口となり、後者は仮想ネットワークアダプターを通じてより広範な通信を引き継ぎます。障害が起きる箇所も異なります。

ローカルコアと待受ポートを確認する

v2rayNの画面でサーバーが選択されていても、プロキシコアが正常に動作しているとは限りません。設定を切り替えたらログの冒頭を確認し、コア設定の読み込み完了と、ローカルSOCKSまたはHTTPの待受情報が表示されているか確認します。アドレスが使用中と表示される場合は、別のクライアントプロセス、前回の異常終了後に残ったバックグラウンドプロセス、または他のソフトが同じポートを使用している可能性があります。重複しているクライアントを終了し、システムツールでポートの使用状況を確認します。Windowsでは、次のコマンドをターミナルで実行できます。例のポートはクライアント設定に表示されるローカルポートへ置き換えてください。

netstat -ano | findstr LISTENING
netstat -ano | findstr :10808
tasklist /fi "PID eq プロセス番号"

macOSとLinuxでは、lsof -iTCP -sTCP:LISTENまたはss -lntpで待受状態を確認できます。ポートが表示されない場合は、クライアントログに戻ってコアの起動エラーを処理します。ポートが存在する場合は、システムプロキシが同じポートを向いているか確認します。ポートを変更した後は、システムプロキシも再適用してください。クライアントの待受値だけを変更してシステム設定を更新しないと、アプリは古いポートへ接続し続け、接続拒否が発生します。

ルーティングモードと残った設定を確認する

トラブル対応の初期段階では、クライアントに用意された基本ルーティングモードを選び、複雑なカスタムルールから始めないでください。「LANと中国本土のアドレスを迂回」モードでは動作するのに、カスタムモードで完全にオフラインになる場合は、ルールの順序、デフォルトのアウトバウンド、ドメイン一致を確認します。ルーティングは通常、上から順に適用されます。範囲が広すぎるブロックルールを前に置くと、後続のプロキシルールが遮断されます。部分的なルールだけを定義して適切なデフォルト出口を用意していない場合も、未一致の通信先が不明確になります。接続が復旧したら、ルールを1つずつ戻し、ドメイン、純粋なIP、LANアドレスの3種類を毎回テストします。

Windowsでは、クライアントが異常終了した後にシステムプロキシが残ることがあります。この場合、ブラウザは停止したローカルポートへ接続しようとするため、ソフトを終了するとすべてのサイトが開けなくなります。v2rayNを再起動してシステムプロキシを無効にするか、システムのネットワーク設定で手動プロキシを無効にしてください。macOSでは、現在のネットワークサービスでWebプロキシと安全なWebプロキシが有効なままになっていないか確認します。Linuxのデスクトップ環境では、HTTP、HTTPS、SOCKSの設定が個別に保存されている場合もあります。残った設定を処理する際は、クライアントが設定したと確認できる項目だけを消去し、ネットワーク設定全体をむやみにリセットしないでください。

ノードのタイムアウト、接続拒否、ハンドシェイク失敗

3種類のエラーを分けて処理する

「タイムアウト」「接続拒否」「ハンドシェイク失敗」は、それぞれ異なる段階を示します。タイムアウトは、クライアントが接続を開始した後、期待した応答を長時間受け取れていない状態です。アドレスに到達できない、ポートがフィルタリングされている、経路でパケットが失われている、サーバーが応答していないなどの可能性があります。接続拒否は通常、対象ホストには到達できるものの、指定ポートでサービスが動作していないか、中間機器が明示的に拒否したことを示します。ハンドシェイク失敗は、基本接続が確立した後にTLS、プロトコル認証、トランスポート、サーバー名の検証で問題が起きている可能性を示します。3つをすべて「ノードの停止」と扱うと、ローカル時刻、SNI、通信経路、パラメータの転記ミスを見落とします。

まず1つのノードを固定して、基本ネットワークのテストを行います。ドメイン名を使うノードでは、名前解決の可否、解決結果の安定性、TCP接続を確立できるかをそれぞれ確認します。WindowsではPowerShellのTest-NetConnection、macOSとLinuxではncを使用できます。これらのテストで確認できるのはネットワークとポートだけで、VMess、VLESS、Trojan、TLSのパラメータは検証されません。したがって、ポートに到達できても完全なプロキシが使えるとは限りませんが、到達できない場合は先にアドレス、ネットワーク、サーバー側の状態を確認します。

Test-NetConnection example.com -Port 443

nc -vz example.com 443

例のドメインは、設定にあるサーバーアドレスへ置き換えてください。ドメイン名からアドレスを解決できない場合はDNSの章へ進みます。正常に解決できてもポートが継続的にタイムアウトする場合は、別のネットワークで比較します。同じノードの結果がネットワークによって異なるなら、原因は現在のネットワーク経路にある可能性が高くなります。すべてのネットワークで失敗し、同じ購読の別ノードが使えるなら、ノード本体またはノードパラメータを疑います。

プロトコルとトランスポートのパラメータを項目ごとに確認する

手動設定では、サーバーアドレス、ポート、ユーザーID、暗号化方式、トランスポート形式、パス、Host、TLS、SNI、フィンガープリントなどをサーバー側と一致させる必要があります。購読のインポートで自動入力される場合でも、更新失敗、形式変換、古い設定の残存によって項目が欠けることがあります。確認時はアドレスとポートだけを比較しないでください。WebSocketのパスにスラッシュが1つ多い、gRPCのサービス名が異なる、TLSの有効・無効が一致しない、SNIに誤ったドメインを指定している、といった違いだけでTCP接続の直後に切断されることがあります。

TLS関連のエラーでは、まずシステムの日付、時刻、タイムゾーンを確認します。証明書の有効期間はローカル時刻を基準に判定されるため、大きなずれがあると「まだ有効ではない」「期限切れ」と判断されます。次に、SNIが証明書の対象ドメインになっているか確認し、サーバーのIPアドレスを適当に指定しないでください。証明書検証をスキップする設定を通常の解決策にしてはいけません。ドメイン、証明書、サーバー設定の問題を隠してしまうだけです。証明書エラーの詳しい種類はTLS証明書エラーの確認リストも参照してください。

クライアントのテストと実際のアクセスの違いを理解する

クライアント内の接続テスト、遅延テスト、実際のWebアクセスでは、異なるリクエスト方式が使われることがあります。あるテストに失敗してもWebが使えるなら、テスト結果だけを理由にノードを削除しないでください。テストに成功してもWebが開かない場合は、システムプロキシ、DNS、ルーティングの引き継ぎを確認します。トラブル対応では、実際のアプリのリクエストとコアログを中心に確認し、テスト方法も記録します。1回だけの瞬間的な結果を比較せず、同じネットワーク、同じルーティング、近い時間帯で繰り返し検証してください。

1つの購読グループにある全ノードで同時にハンドシェイク失敗が起きる場合は、システム時刻、クライアントコア、購読内容の構造変化、共通して使用するドメインやポートが現在のネットワークの影響を受けていないかを優先して確認します。単一ノードだけが失敗する場合は、その設定を重点的に照合します。v2rayNでコアの種類を切り替えた後にエラーが出始めたなら、設定で使われているプロトコル機能が現在のコアでサポートされているか確認します。XrayとV2Flyには共通のルーツがありますが、一部のプロトコル拡張への対応は完全には同じではありません。コア名だけを置き換えて、すべての設定が互換だと判断しないでください。

購読の更新に失敗する、またはインポート後に一覧が空になる

購読リクエストが実際に送信されたかを先に確認する

購読の更新には、購読URLの解析、ネットワークリクエスト、サーバーの応答、コンテンツのデコード、設定変換という複数の段階があります。「更新に失敗しました」と表示されたら、まずログのHTTPステータス、タイムアウト情報、形式エラーを確認します。リクエストのタイムアウトは、現在のネットワークから購読URLにアクセスできないか、更新リクエストが想定どおり利用可能なプロキシを経由していない可能性を示します。未認証やアクセス禁止は、リンクの失効、アカウント状態、アクセス制限に関係することが多く、成功したのに一覧が空の場合は、応答内容がクライアント対応の購読形式かを確認します。

購読URLをコピーするときは、末尾のクエリパラメータまで完全に残してください。チャットツール、メモアプリ、ブラウザのアドレスバーによって末尾の文字が切れたり、特殊文字が表示用の文字列に変換されたりすることがあります。元の配布元からもう一度コピーし、クライアントのURLを上書きするのがおすすめです。購読URLはアカウント認証情報の一部なので、公開ページやスクリーンショットに載せないでください。購読グループ名はローカルでの識別にしか影響せず、リモートリンクを修復するものではありません。同じ名前のグループでも、内容が同じとは限りません。

直接更新とプロキシ経由の更新を分けて確認する

環境によっては、購読URLへのアクセスに、すでに利用できるプロキシが必要です。接続できる設定が1つもない状態で更新にもプロキシが必要だと、「接続するには購読が必要だが、更新するには接続が必要」という循環に陥ります。既知の動作する古い設定を1つ残し、先に接続してから更新するか、サービス提供元の案内に従って初期設定をインポートしてください。更新に失敗したからといって、サーバー一覧をすぐにすべて消去しないでください。古い設定が購読リクエストを復旧する唯一の基準になることがあります。

v2rayNの購読更新オプションでは、システムプロキシまたは現在のプロキシを使える場合があります。具体的な動作はログと合わせて確認してください。ログの購読リクエストが直接タイムアウトする一方、ブラウザではプロキシ有効時に同じドメインを開けるなら、クライアントの更新経路がプロキシを通っていない可能性があります。Androidでは、v2rayNGまたはv2flyNGがバックグラウンドで更新を実行する際のネットワーク権限と、システムのデータ制限も確認します。無線ネットワークとモバイルネットワークを切り替えて比較すると、現在の接続ネットワークの問題かどうかを素早く判断できます。

「更新成功なのにノードがない」場合の対処

更新成功は、リクエストと解析の処理で明らかなエラーが出なかったことを示すだけで、有効なノードが含まれているとは限りません。まずグループにフィルターがかかっていないか、ノードが別のグループに入っていないか、画面に検索キーワードが残っていないか確認します。フィルターを解除しても空の場合は、応答のコンテンツ形式を確認します。一般的な購読には、エンコードされたリンクの集合、構造化設定、クライアント専用形式などがあります。サーバーがログインページ、エラー説明、空のテキストを返している場合、クライアントには認識できない形式として表示されることがあります。

更新後に古いノードがすべて置き換わった場合は、購読設定の更新方式を確認します。購読で一元管理するグループには上書き更新が適していますが、手動で変更したノードを同じ自動上書きグループに混在させるべきではありません。ローカルのパラメータを残す必要がある場合は、先に別のグループへコピーしてから更新します。デスクトップとAndroidの標準インポート入口は購読リンクのインポート手順を、更新間隔、プロキシ経由の更新、失敗原因は購読更新に失敗した場合の対処法を参照してください。

接続は成功するが速度が遅い、または大きく変動する

まずテスト方法による誤判定を除外する

速度は比較可能な条件で判断します。1つのWebページだけが遅い場合、対象サイト、ブラウザ拡張機能、キャッシュ、画像リソースが原因かもしれず、プロキシ経路全体が遅いとは限りません。同じネットワーク、同じ端末、同じダウンロード先を選び、プロキシ無効、プロキシ有効でノード固定、別ノードへ切り替えの3状態を個別にテストしてください。各テストの前にバックグラウンド同期、大容量更新、クラウドストレージの処理を停止し、複数の速度測定ツールを同時に実行しないようにします。安定したスループット、初回接続時間、長時間接続が切れないかを重視し、一度だけの瞬間的なピーク値だけを見ないでください。

プロキシを無効にしても遅いなら、まずローカルの無線信号、ルーターの負荷、通信事業者の経路を確認します。直接接続は正常なのにすべてのノードが遅い場合は、クライアントのルーティング、TUN、DNS、端末リソースを確認します。特定のノードだけが遅い場合は、そのノードの回線、混雑、リモート側の負荷である可能性が高くなります。同じネットワークでデスクトップとAndroidの両方が同じ設定で遅いなら、端末要因の優先度を下げられます。1台だけが遅い場合は、省電力設定、バックグラウンド制限、仮想ネットワークアダプター、セキュリティソフトを確認します。

遅延、帯域幅、パケットロスを区別する

遅延は接続確立と操作への応答に影響し、帯域幅は継続的な転送速度に影響し、パケットロスは再送と大きな変動を引き起こします。これらは同じ指標ではありません。接続確立は遅いもののダウンロードが安定するノードは、遅延が大きくても帯域幅は十分かもしれません。初期応答は速いのに転送速度が何度も落ちるノードは、混雑やパケットロスが疑われます。クライアントの基本テストは参考情報にすぎないため、最終的には実際の利用場面で確認します。一度の遅延順位だけでノードを頻繁に自動切り替えないでください。既存の接続が切れ、検証条件も揃わなくなります。

プロトコルのカプセル化、TLS、トランスポート方式、ルーティング経路はいずれもオーバーヘッドを増やしますが、プロトコル名だけで速度を判断すべきではありません。同じプロトコルでも、サーバー、ネットワーク、時間帯によって結果は大きく変わります。まずパラメータが正しく安定して接続できるノードを選び、その後でネットワーク経路を比較します。ログに接続リセット、再試行、書き込みタイムアウトが継続して出るなら、速度低下は端末の処理能力ではなく接続品質が原因かもしれません。

TUN、MTU、迂回ルートを確認する

TUNモードはより多くの通信を引き継ぐ一方、仮想ネットワークアダプター、DNS、ルーティングの処理も増やします。システムプロキシモードは正常なのにTUNだけ明らかに遅い場合は、他の仮想ネットワークアダプター、重複ルート、セキュリティソフトのフィルタリングを確認します。ネットワークによってはMTUが合わないと、小さなWebページは開けるのに大容量ファイルが止まる、特定サイトの読み込みが完了しないといった症状が出ます。MTUを極端な値に変更せず、まずクライアントの標準値に戻し、現在のネットワークに合わせて小さい値を段階的にテストしてください。変更するたびに再接続します。

分流ルールが迂回経路を作ることもあります。対象ドメインが先にリモートDNSで想定外のアドレスへ解決され、その後IPルールで再度判定されると、出口の方向が変わる可能性があります。複雑なルールセットが重なる場合は、ログのルーティング適用結果を確認します。トラブル対応中は一時的に単純なモードを使い、速度が戻ったことを確認してから、ドメインルール、IPルール、リモートDNSを1つずつ追加します。ルールが多いほど判断が正確になるわけではなく、数より明確な優先順位が重要です。

端末リソースと同時接続数を確認する

デスクトップでリソース使用率が高い場合は、画面プロセス、プロキシコア、その他のアプリのどれが消費しているかを確認します。大量の同時接続、継続的な詳細ログ出力、TUNによる引き継ぎ、リアルタイムセキュリティスキャンはいずれも負荷を高めます。不要な詳細ログを無効にし、重複起動しているクライアントを減らし、複数のプロキシを同時に有効にしないでください。Android端末では、省電力モード、高温、バックグラウンド制限により接続が低速化または停止することがあります。バックグラウンド実行を許可する対象にクライアントを追加してからテストします。

速度低下が特定のアプリだけで起きる場合は、そのアプリがQUIC、独自DNS、内蔵プロキシを使っていないか確認します。ブラウザとシステムのダウンロードツールを一時的に比較し、アプリ層に限定された問題か判断します。固定した時間帯にすべてのアプリが同時に遅くなるなら、発生時刻、ネットワーク種別、ノードグループを記録し、クライアントを次々に変更しないでください。安定して再現できて初めて、ローカル設定と外部経路の変化を区別できます。

DNSの名前解決失敗、汚染キャッシュ、分流のずれ

DNS障害に典型的な症状を見分ける

DNSの問題では、ドメイン名では開けないのに既知のIPアドレスには応答がある、一部のドメインだけ断続的に失敗する、クライアントログにlookupやresolveのエラーが出る、ネットワークを切り替えると一時的に復旧するといった症状が現れます。さらに分流のずれが隠れていることもあります。ドメイン名の解決は成功していても、返されたアドレスが誤ったルールに一致し、通信が想定外の方向へ進む状態です。DNSを調べるときは、誰がクエリを発行したか、どのDNSへ送信したか、解決結果がルーティングにどう使われたかの3点を確認します。

まずプロキシを無効にしてシステムDNSをテストし、その後クライアントを有効にして結果を比較します。WindowsではnslookupまたはPowerShellのResolve-DnsName、macOSではdigとscutil --dns、Linuxではresolvectl queryでsystemd-resolvedの結果を確認できます。テストではドメイン名、返されたアドレス、使用したサーバーを記録し、「DNSが通らない」だけで済ませないでください。

nslookup example.com
Resolve-DnsName example.com

dig example.com
scutil --dns

resolvectl query example.com
resolvectl status

キャッシュを消す前に証拠を保存する

システム、ブラウザ、クライアントコア、アプリのそれぞれが名前解決の結果をキャッシュすることがあります。すぐにすべてのキャッシュを消去すると一時的に復旧する場合はありますが、判断材料を失います。まずシステムツールとブラウザの結果を比較してください。システムツールは正常でブラウザだけ失敗するなら、安全なDNS、拡張機能、ブラウザ自身のキャッシュを確認します。システムツールとクライアントログの結果が異なるなら、クライアント内蔵DNSを確認します。すべてのツールで失敗する場合は、現在のネットワークが提供するDNSと接続性を確認します。

消去が必要だと確認できたら、Windowsではipconfig /flushdnsを実行します。macOSでは現在のネットワークサービスを再起動するか、システムの名前解決キャッシュを更新します。Linuxでは実際に使用している名前解決サービスに応じて該当コンポーネントを再起動します。消去後はクエリを再実行して結果を記録してください。消去するたびに短時間だけ復旧するなら、根本原因はキャッシュではなく、上流DNS、ルール、ネットワークが異常な結果を継続して返していることにあります。

クライアントDNSとルーティングの関係を確認する

V2Ray設定のDNSは、単に「サーバーアドレスを1つ入力する」だけではありません。クエリはドメインルールに応じてローカルまたはリモートのリゾルバーを選び、返されたIPはさらにIPルーティングの判定に使われることがあります。ドメインをローカルで解決した後に通信をプロキシ経由にすると、解決結果とプロキシ出口から見える対象が一致しない場合があります。fake DNSやTUNによるDNS引き継ぎを有効にしている場合は、仮想アドレスをコアが正しく元に戻せるかも確認します。まず複雑なドメイン分流とfake DNSを無効にし、明確な1つの解決経路で検証してから、高度な設定を戻してください。

次の例は、Xray形式の設定における簡略化したDNS構造を示します。実際のサーバーアドレスとクエリ方針はネットワーク環境に合わせて設定してください。重要なのは、ローカルとリモートの役割を明確に分け、ルーティングルールとDNSのタグを対応させることです。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

設定例を既存の完全な設定にそのまま上書きしないでください。コアの種類、ルールリソース、ネットワーク条件が異なる可能性があります。現在のクライアントを購読で管理している場合は、画面のDNSとルーティング設定から変更することを優先し、次回の購読更新で手動編集が上書きされないようにします。V2Flyコアを使用するv2flyNGでは、関連フィールドが現在のコアの対応範囲に含まれるかも確認してください。

ブラウザとシステムの結果が一致しない場合の対処

最近のブラウザは独自の安全なDNSを有効にし、システムの名前解決経路を迂回することがあります。システムコマンドでは解決できるのにブラウザが誤ったアドレスへアクセスするなら、まずブラウザのネットワーク設定で解決方式を確認し、拡張機能を一時的に無効にして比較します。アプリによっては接続と名前解決の結果をキャッシュするため、システムDNSを更新しても古いプロセスが以前の結果を使い続けることがあります。ページを更新するだけでなく、アプリを完全に終了して再起動してください。

TUNモードでドメイン名だけが失敗し、純粋なIPリクエストには到達できる場合は、DNS通信が仮想ネットワークアダプターに引き継がれているか、53番ポートを他のソフトが使用していないか、システムに複数のアクティブなネットワークインターフェースがないかを確認します。無線、LAN、仮想ネットワークアダプターが同時に有効だと、システムが優先度の高いものの利用できないインターフェースへDNSクエリを送ることがあります。まず不要なインターフェースを停止して検証し、その後に長期的な優先順位を調整します。

システムプロキシが効かない、一部アプリがプロキシを使わない

システム設定とクライアントの待受を一致させる

システムプロキシは、対応するアプリのリクエストをローカルHTTPまたはSOCKSポートへ向ける仕組みです。クライアントに「システムプロキシ有効」と表示されても、システム設定のアドレスとポートがコアの実際の待受と一致しているか確認してください。通常、ローカルアドレスはループバックインターフェースを指し、ポートはv2rayNの設定画面とログにある待受ポートと同じである必要があります。ポートを変更した、設定ディレクトリを切り替えた、複数のインスタンスを同時に起動している場合、システムには古い値が残っている可能性があります。

Windowsではシステムネットワークのプロキシ画面で手動プロキシを確認でき、コマンドでWinHTTPの状態も確認できます。

netsh winhttp show proxy

Windowsのユーザー単位のシステムプロキシとWinHTTPプロキシは、完全に同じものではありません。ブラウザがユーザープロキシ経由でアクセスできても、システムサービスやコマンドラインツールが同じ設定を使うとは限りません。macOSのプロキシはネットワークサービスごとに保存されるため、無線と有線を切り替えた後はそれぞれ確認します。Linuxではデスクトップ環境、ターミナルの環境変数、個別アプリが別々にプロキシ設定を持つことがあります。まず対象アプリがどの設定を読み取るかを明確にしてください。

一部のアプリだけが直接接続する場合の対処

一部のアプリはシステムプロキシに従わず、HTTPプロキシだけに対応してSOCKS設定を読み取らないことがあります。この場合、ノードとコアは正常でもアプリの通信は直接接続されます。まずブラウザでローカルプロキシを確認し、対象アプリに独自のプロキシ設定があるか調べます。対応している場合は、クライアントのローカル待受アドレスと対応するプロトコルのポートを入力します。対応しておらず、どうしても通信を引き継ぐ必要がある場合は、TUNモードを検討します。1つのアプリのためにすべてのルーティングルールを変更せず、まずそのアプリがローカルプロキシの入口へ入っているか確認してください。

コマンドラインツールは通常、環境変数を読み取ります。一時的なテストでは現在のターミナルだけに設定でき、ターミナルを閉じれば自動的に無効になります。次の例ではローカルHTTPポートを使います。ポートはクライアントの実際の値へ置き換えてください。

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

前半の2行はWindowsのコマンドプロンプト用、後半の2行はmacOSとLinuxで一般的なshell用です。テスト終了後は変数を削除し、クライアントが動作していないときにも無効なポートを向き続けないようにします。アプリ内プロキシ、環境変数、システムプロキシが重なる場合は、通常アプリ自身の設定が優先されます。そのためシステム設定が正しいのに失敗する場合は、アプリに古いプロキシが保存されていないか確認します。

PAC、グローバルプロキシ、TUNを区別する

PACまたは自動設定モードは、ルールに応じてプロキシを使うリクエストを決めます。システムプロキシに従い、自動設定に対応するアプリに適しています。グローバルシステムプロキシは、対応するリクエストをより広くローカルポートへ渡しますが、システムプロキシを完全に無視するプログラムまでは対象にできません。TUNは仮想ネットワークアダプターを通じてより広い通信を処理する一方、正しいルーティング、DNS、権限の設定が必要です。モードは対象アプリの範囲に応じて選び、TUNをすべての問題を直す第一手段にしないでください。

PACモードでは一部サイトがプロキシを使わないのに、グローバルモードでは使える場合、原因の多くはPACルール、キャッシュ、アプリのPAC対応にあります。まずシステムプロキシ設定を更新して対象アプリを再起動し、ルールの一致を確認します。グローバルシステムプロキシも効かないのに、アプリへローカルポートを直接入力すると動作するなら、そのアプリがシステム設定を読み取っていません。TUNを有効にした後にすべてのアプリがオフラインになる場合は、第2章に戻って仮想ネットワークアダプターとルーティングを確認し、ノードをさらに変更しないでください。

クライアントが起動しない、強制終了する、コアが繰り返し終了する

画面プロセスとコアプロセスを分けて確認する

v2rayNはグラフィカルインターフェースとプロキシコアが連携して動作します。画面は正常に開いても、設定エラー、ポート競合、権限の問題でコアだけがすぐ終了することがあります。逆にコアがバックグラウンドに残っていると、画面を再び開いた際にポート競合が表示される場合があります。タスクマネージャーやシステムのプロセス一覧で、どのプロセスが終了しているかを先に確認します。画面が強制終了する場合はアプリログとシステムイベントを確認し、コアが終了する場合はクライアントログで起動コマンドの直後に出る最初のエラーを優先して確認します。

設定ファイルの破損もよくある原因です。新しいノードのインポート、ルーティングの編集、購読更新の後に問題が発生したなら、まず以前動作していた設定へ戻します。設定ディレクトリ全体を直接削除せず、先にバックアップをコピーしてから、新しい空の設定でクライアントを起動します。空の設定で起動でき、元の設定を読み込むと終了するなら、問題は設定内容またはデータベースに集中しています。空の設定でも起動できない場合は、実行環境、権限、ファイルパス、セキュリティソフトの処理履歴を確認します。

ポート、パス、実行権限を確認する

コアの起動時には、設定の読み込み、ルールリソースのロード、ログの作成、ローカルポートの待受が必要です。インストール先への書き込み権限がない、パスが同期ソフトにロックされている、ファイルを他のプログラムが使用しているといった状況で起動に失敗することがあります。デスクトップでは、現在のユーザーが読み書きできる通常のディレクトリにクライアントを置き、圧縮ファイルのプレビュー画面から直接実行しないことをおすすめします。ダウンロードするプラットフォームやアーキテクチャを間違えても実行できないことがあるため、ダウンロードページでWindows、macOS、Android、Linuxの入口を再確認してください。

ポートの使用状況は第2章の方法で確認できます。古いコアプロセスが見つかった場合は、まずクライアントを正常終了し、プロセスが終了するのを待ってから起動します。終了できない場合に限り、システムツールで停止します。ランダムなポートへ何度も変更して重複プロセスを隠さないでください。システムプロキシやアプリ内プロキシが古いポートを向き続ける可能性があります。ポート変更後はシステムプロキシも更新し、ファイアウォールがローカルのループバック通信を許可しているか確認します。

アップデート後の起動異常に対処する

クライアントのアップデート後に異常が出る場合、古い設定項目と新しい画面の非互換、実行依存関係の変更、コアファイルの置換不完全、古いプロセスによるファイル占有などが考えられます。まずクライアントとコアを完全に終了してから再起動します。それでも失敗する場合は、購読URL、ルーティング、必要な設定をバックアップし、新しいディレクトリで現在のインストールパッケージを起動してから項目ごとにインポートします。古いディレクトリを新しい場所へそのまま上書きしないでください。破損ファイルや互換性のない設定まで戻してしまう可能性があります。

v2rayNのデスクトップ版と従来のWPF版では、画面技術と対応プラットフォームの範囲が異なります。表示や実行環境の問題が起きたら、まずどちらを使っているか確認し、2つの版のディレクトリ間で設定ファイルを混在させないでください。違いについてはv2rayNデスクトップ版とWPF版の選び方を参照してください。版を切り替える前に購読とカスタムルールをバックアップし、独立したディレクトリでテストすると、古いファイルの影響を避けられます。

リソースやルールがクラッシュを引き起こしているか分析する

クライアントが購読更新、速度測定、TUNの有効化のときだけ終了するなら、特定の操作が引き金になっている可能性があります。購読に大量の設定が含まれると、解析、重複除去、テストによって一時的なリソース使用量が増えます。複雑なルーティングリソースの読み込みに失敗し、コアが起動直後に停止することもあります。まず自動速度測定と自動更新を無効にし、手動設定を1つだけ使って基本動作を確認してから、機能を1つずつ戻します。特定の購読グループだけで起きる場合はログを保存し、そのグループに異常な項目がないか確認します。

ログが継続的に急増すると、ディスクを圧迫して動作にも影響します。トラブル対応では短時間だけ詳細ログを有効にし、再現後すぐに通常レベルへ戻して重要な部分を保存します。完全な接続情報を含むデバッグログを長期間残さないでください。システムの空き容量が不足すると、クライアントが設定を書き込めない、リソースを更新できないことがあります。まず空き容量を確保し、ディレクトリへ書き込めるか確認します。

復旧できる設定管理の習慣を作る

安定して動作した後は、購読URL、カスタムルーティング、クライアント設定を分けてバックアップし、復旧を1つのプログラムディレクトリだけに依存しないようにします。更新前に使用中のクライアントの種類、コアの種類、重要なポートを記録しておけば、問題が起きたとき正確に戻せます。バックアップは管理された場所に保管し、購読URLや認証情報を公開しないでください。

クライアントが空の設定で安定して動作するなら、復元の順番は、ノードを1つ追加して接続を確認、購読を追加、システムプロキシ設定を戻す、最後にカスタムDNS、ルーティング、TUNを追加する、という流れがおすすめです。各段階で一度起動し、ログを確認します。再びクラッシュしても、どの種類の設定が引き金になったか特定でき、ディレクトリ全体を最初から推測し直す必要がありません。

Androidで接続が切れる、バックグラウンドで制限される

仮想ネットワークの権限とクライアントの状態を確認する

v2rayNGとv2flyNGはAndroid上で、通常システムの仮想ネットワークインターフェースを通じて通信を引き継ぎます。初回接続時やシステムリセット後に権限を再設定した場合、システムが接続の許可を求めます。クライアント画面が起動中のまま有効な接続にならない場合は、隠れた権限確認ダイアログがないか確認し、ステータスバーに仮想ネットワークの状態が表示されているか確認します。別のネットワークツールが同種のインターフェースを使用している場合は、古い接続を先に切断してから現在のクライアントを起動します。

設定をインポートした後は、接続するノードを1つ明確に選択してください。購読グループが存在しても、接続可能な設定が選択されているとは限りません。更新成功もコアの起動を意味しません。接続後にログを開き、コアが設定を読み込み、ローカルの入口を作成し、リモートへの接続を試みているか確認します。起動段階で設定エラーが出る場合は、まず単純なノード1つで確認し、アプリごとのプロキシ、複雑なDNS、カスタムルーティングを同時に有効にしないでください。

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

Androidの省電力機能は、画面ロック、待機、メモリ不足の際にバックグラウンドプロセスを制限することがあります。前面での使用中は正常なのに、しばらく画面をロックすると接続が失われ、クライアントを開き直すと復旧するのが典型的な症状です。システムのバッテリー管理とバックグラウンド管理で、v2rayNGまたはv2flyNGの継続実行を許可し、自動休止の対象になっていないことを確認します。端末によって設定名は異なりますが、同じノードを固定し、画面点灯中、短時間のロック、長時間のロックを個別にテストして、クライアントプロセスと接続状態がシステムに停止されていないか観察する方法は共通です。

最近のタスク一覧でアプリを固定するだけでは不十分な場合があります。バックグラウンド通信、データセーバー、省電力制限も確認してください。スリープ中に無線ネットワークが切断されても接続が中断します。モバイルネットワークへ切り替えた後はクライアントが再接続を必要とすることがあります。ネットワーク切り替え後の短い再接続は正常ですが、長時間復旧しない場合は手動で切断して再接続し、ログで古いネットワークインターフェースを使い続けていないか確認します。

アプリごとのプロキシと迂回設定を確認する

アプリごとのプロキシでは、指定したアプリだけを引き継ぐことも、一部のアプリを除外することもできます。しかし選択ロジックを誤ると、「ブラウザは使えるが他のアプリは直接接続する」またはその逆の症状になります。まずアプリごとの機能を無効にして、全体の引き継ぎが正常か確認します。正常なら再度有効にし、現在のモードが「選択したアプリだけをプロキシ」なのか「選択したアプリを迂回」なのかを確認します。アプリの更新、再インストール、仕事用プロファイルによってアプリ識別子が変わると、以前の一覧が一致しなくなることがあります。

システムコンポーネントまたは特定のアプリだけが接続できない場合は、除外対象になっていないか、独自DNSを使っていないか、仮想ネットワークが制限されていないか確認します。明らかにアプリ範囲の問題なのに、ノードを何度も切り替えて対処しないでください。アプリ一覧を変更した後は再接続し、ルーティングルールを完全に読み込み直します。仕事用プロファイルとメインユーザー領域ではネットワークポリシーが別になることがあるため、一方の設定がすべての領域に適用されると決めつけず、それぞれ確認します。

無線ネットワークとモバイルネットワークを比較する

同じノードが無線では使えるのにモバイルではタイムアウトする、または逆の結果になる場合、設定自体は有効で、接続ネットワーク、DNS、アドレスファミリー、MTUに差がある可能性があります。両方のネットワークでドメイン名の解決、接続エラー、使用されたトランスポート方式を記録します。モバイルネットワークがIPv6を優先し、ノードのドメイン名から返されたアドレスに到達できない場合は、クライアントのアドレス選択とDNSクエリ方針を確認します。無線ネットワークにWeb認証が必要なポータルがある場合は、クライアントの引き継ぎを無効にして先に認証し、その後に再接続してください。

ネットワークを切り替えると、古い接続が元のインターフェースに残り、短時間リクエストが失敗することがあります。まずクライアントの自動再接続を待ちます。復旧しない場合は、一度切断して再接続します。切り替えるたびにアプリの再起動が必要なら、システムがバックグラウンドのネットワーク変化通知を制限していないか、クライアントが停止状態になっていないか確認します。アプリデータを頻繁に消去しないでください。購読、グループ、ルーティング設定が削除されるだけで、ネットワーク切り替えの問題が解決するとは限りません。

v2rayNGとv2flyNGの基準を選ぶ

Androidでは、まず設定が必要とするコアに応じてクライアントを選びます。v2rayNGはXrayコアを使用し、Xray関連のプロトコル機能が必要な設定に適しています。v2flyNGはV2Flyコアを使用し、対応するエコシステムの設定に選べます。両方をインストールしている場合は同時に接続せず、同じ設定が異なるコアで完全に同じ対応になると決めつけないでください。比較テストではネットワークとノードを固定し、クライアントだけを変更して具体的なエラーを記録します。

v2rayNGでは接続できるのにv2flyNGではできない、または逆の場合は、まずプロトコルとトランスポート機能が対応するコアでサポートされているか確認します。問題をスマートフォンのネットワークだけのせいにしないでください。XrayとV2Flyの機能範囲についてはXrayとV2Flyのコアの違いを参照してください。再インストールが必要な場合は、Androidダウンロード入口で端末のアーキテクチャに合う版を選び、元の購読情報を残してから移行します。