V2Ray トラブル対処ガイド

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

「接続成功」と表示されても、クライアントがコアを起動した、またはローカルサービスを開始しただけの場合があります。ブラウザーのリクエストが目的のサイトまで届いたとは限りません。通信経路を、アプリ、ローカルの受信、ルーティング、リモートへの送信先、目的のサービスの5段階に分けて確認しましょう。まず他のプロキシアプリを終了し、同じサイトへのアクセスを繰り返しながらv2rayNのログを開きます。最初からプロトコルやDNSを変更したり、TUNを有効にしてルートをリセットしたりしないでください。複数の変更を同時に行うと、接続が復旧しても原因を特定できません。

ネットワーク接続とローカル待ち受け

まずシステムプロキシを解除し、通常なら直接アクセスできるサイトを開いてください。それでも失敗する場合は、Wi-Fi、ゲートウェイ、ネットワーク認証、システム時刻を確認し、必要に応じて同じ端末で別のネットワークを試します。Web認証が完了したら、クライアントを再接続してください。ネットワーク自体が復旧していない段階では、プロキシログのタイムアウトだけを見ても原因の特定にはつながりません。クライアント終了後にすべてのブラウザーで接続できなくなった場合は、リモートサーバーの障害と決めつけず、システムにローカルポートを指すプロキシ設定が残っていないか確認してください。

次にv2rayNで対象サーバーを選択し、コアの起動エラーが出ていないか確認します。該当する設定を開き、ローカルの待ち受けアドレスとポートを確認したうえで、ブラウザーやシステムプロキシにも同じポートが設定されているか確認してください。ネット上のスクリーンショットを根拠に、ポート番号が固定だと思い込まないでください。設定や受信方式によって値は異なります。ログにポートの競合が記録されている場合は、他のクライアントを終了してからコアを再起動します。ポートを変更する場合は、そのポートを使うアプリ側の設定も合わせて変更してください。ローカルサービスが正常でも、ポートが一致しなければリクエストは届きません。

ログで接続経路と送信先を確認

Webページを再度開き、そのタイミングで新しい接続ログが記録されるか確認します。ログが増えない場合は、まずアプリ側の接続経路を確認してください。ブラウザー拡張機能がシステムプロキシを上書きしていないか、アプリ独自のプロキシ設定がないか、目的のアドレスがシステムのプロキシ除外リストに含まれていないかを調べます。ログの記録有無はログレベルにも左右されるため、表示がないだけで結論を出さないでください。現在のコアのログを見ていることを確認し、一時的に接続を確認できるログレベルに設定します。調査後は元のレベルに戻し、ログが増え続けないようにしてください。

接続がコアに入っているのにdirectへ振り分けられる場合は、ステータスバーのルーティングモードとカスタムルールの順序を確認してください。ルーティングは通常、上から順に一致するルールを探します。条件が広すぎるdirectルールが前にあると、後続のproxyルールが適用されないことがあります。一時的にグローバルプロキシモードに切り替えて、振り分けの問題かどうかを確認し、テスト後は元に戻してください。「グローバル」はクライアント内のルーティング設定です。システム上のすべてのアプリが自動でクライアントに接続するわけではなく、ローカルプロキシを使わないアプリは通信を迂回する場合があります。

通信経路全体の問題か、特定サイトだけの問題かを切り分ける

複数のサイトに接続できない場合は、ノード接続とDNSの章に進んでください。特定のサイトだけで問題が起きる場合は、別のブラウザーで新しいセッションを開き、サイトのメンテナンス状況やログイン要求を確認します。静的ファイルのドメインが別のルートに振り分けられていないかも調べてください。ページの文章は表示されても画像の読み込みが止まる場合、複数のドメインからコンテンツを取得している可能性があります。アドレスバーのメインドメインだけで判断せず、同じ時間帯のリクエストと適用されたルールを照らし合わせると、繰り返し再読み込みするより原因を見つけやすくなります。

ノードがタイムアウトする：アドレスへの接続とプロトコルのハンドシェイクを切り分ける

タイムアウトは、処理のどこかが制限時間内に完了しなかったことを示します。この表示だけでサーバーが使えないと判断することはできません。クライアントのテスト機能は、TCP接続、プロキシ経由でのテスト用アドレスへのアクセスなど、方式によって異なる対象を測定します。まず機能名とログを確認し、ブラウザーからの実際のリクエストでも再現するか試してください。テスト先のアドレス自体が使えない場合、ノード一覧のテスト結果がすべて異常になることもあります。結果だけを根拠にサーバーをまとめて削除したり、既存のサブスクリプションを上書きしたりしないでください。

アドレス、ポート、接続段階を確認

サーバーの編集画面で、アドレスが欠けていないか、ポートがサービス提供元の指定値と一致するか、コピー時に空白や改行が混入していないかを確認してください。アドレスにドメイン名を使っている場合は、システムで名前解決できることも確認します。リモートアドレスへの接続時点でログにタイムアウトが出る場合は、ネットワーク経路、サーバーへの到達性、ポートが主な確認対象です。接続確立後にTLSや認証のエラーが出る場合は、通信のセキュリティ設定やプロトコルパラメーターを確認してください。異なる種類のエラーを混同して設定を変更すると、原因の特定に時間がかかります。

同じ端末で別のネットワークに切り替えると、ローカルネットワークの制限とサーバー側の問題を切り分けやすくなります。同じネットワークで、動作確認済みの別設定を試すと、特定のサーバーに問題が集中しているか判断できます。比較時はクライアント、対象サイト、ルーティングモードを変えないでください。社内ネットワークで試す場合は、Web認証や指定された出口経路が必要か確認し、ネットワークの利用規則に従ってください。テストのためにシステムの受信ファイアウォールを安易に開放しないでください。外向きの接続失敗と、ローカルサービスを外部から利用できるようにすることは別の問題です。

TLS、通信方式、REALITYの設定

接続確立後に証明書関連のエラーが出る場合は、まず端末の日付、時刻、タイムゾーンを合わせ、サーバー名の設定が設定情報の提供元と一致するか確認してください。TLSのサーバー名と接続先アドレスは異なる場合がありますが、経験だけを頼りに置き換えてはいけません。証明書チェーンが信頼されていない、名前が一致しない、ハンドシェイクがタイムアウトする、といった問題はそれぞれ原因が異なります。エラーメッセージ全体を確認して対応してください。証明書の検証を無効にする方法は通常の解決策ではありません。設定ミスを隠し、接続先の認証を弱めるおそれがあります。名前、時刻、サーバー側の証明書を適切に修正してください。

WebSocketやgRPCを使う場合は、通信方式、パス、Host、サービス名を1つずつ照合してください。パスの大文字・小文字、先頭のスラッシュ、サービス名の文字列が一致しないと、接続に影響する場合があります。ポートに接続できても、これらの設定が正しいとは限りません。共有リンクから読み込んだ場合も、各項目が正しく認識されているか確認してください。クライアントが未対応の形式では、項目が欠けることがあります。「通信方式」を自由に選べる高速化オプションだと考えないでください。クライアントとサーバーで互換性のある設定が必要です。

VLESSとREALITYを組み合わせる場合は、サーバーで指定されたサーバー名、公開鍵、ショートID、フロー制御の要件を確認してください。それぞれ役割が異なり、相互に置き換えることはできません。使用するコアがその組み合わせに対応しているかも確認します。v2rayNGとv2flyNGではコアの系統が異なるため、同じ共有リンクがどちらでも同じように動くとは限りません。確実な復旧方法は、有効な設定情報を取得し、全項目を読み込んでテストすることです。別々のガイドから似た項目を寄せ集めて設定しないでください。

再試行の間隔と結果の記録

短時間に何度も再読み込みすると、一時的なネットワーク復旧、サーバー側の接続制限、古いプロセスの終了処理が重なることがあります。設定を変更したら、コアの起動完了を待ち、目的を決めたリクエストを1回だけ送って、その時間帯に最初に出たエラーを確認してください。複数のエラーが続く場合は、最初に発生した問題から対処します。後続の接続終了は、その結果にすぎないことがあります。「ネットワーク、サーバー、アクセス先、停止した段階」を記録し、復旧用に動作する設定を1つ保存しておくと、タイムアウト画面だけを撮影するより役立ちます。

設定情報の提供元に問い合わせる際は、リモート接続の前に失敗するのか、TLSの後に失敗するのかを伝え、機密情報を隠したログの一部を添付してください。サブスクリプションURLや認証情報をそのまま送らないでください。他のサーバーは安定して使えるのに、特定の設定だけが異なるネットワークでも同じハンドシェイク段階で止まる場合、ローカルのルーティングを変更しても効果は期待しにくいでしょう。リモートサービスの状態と設定の有効期限を確認してください。各項目の意味はFAQも参考にし、ネットワークのタイムアウトとプロトコルの非互換を混同しないようにしましょう。

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

サブスクリプションの更新は、まずURLから応答を取得し、次にクライアントが読み込めるサーバー情報へ解析するという2段階で行われます。「更新失敗」と表示されたら、ログに接続、証明書、ステータスコード、解析のどのエラーが記録されているか確認してください。ブラウザーでURLを開けても、応答がサブスクリプションとは限りません。ログインページ、認証ページ、アカウント期限切れの案内が表示される場合もあります。Webページを保存して何度も読み込んだり、一度取得に失敗しただけで使えるサーバー情報を削除したりしないでください。

サブスクリプションURLと取得経路を確認

サブスクリプショングループの設定を開き、URLがすべて含まれているか確認してください。末尾のパラメーター、コピー時に混入した空白、メッセージアプリによる長いURLの切り詰めに注意します。サブスクリプションURLにはアカウントへのアクセス権が含まれることが多いため、機密情報として扱ってください。スクリーンショットや掲示板に公開してしまった場合は、サービス提供元で可能ならURLを再発行し、ローカルのグループを更新してください。一般のWebページ、ユーザー用の管理画面、サブスクリプション用のAPIは別物です。提供元が案内する正しい登録URLを使用してください。

v2rayNでは、ネットワークの状況に応じて「プロキシを使わずにサブスクリプションを更新」する方法と、プロキシ経由で取得する方法を試せます。具体的な項目名は画面に従ってください。直接接続はできなくてもプロキシが使える場合は、既存の動作するサーバーを使って更新できます。プロキシが使えない状態で、そのプロキシ経由の取得に頼ると解決できない状態になります。元のグループを残し、実行可能な取得経路を選んで再試行してください。社内ネットワークのWeb認証や、端末のネットワーク接続が未完了の場合も、想定外の応答が返ることがあります。

応答の種類に応じて対処を選ぶ

ログにHTTPステータスコードが記録されている場合は、アクセス拒否、URLの不在、リクエスト制限、サーバーエラーを区別してください。アクセス権の問題では、サブスクリプションの有効期限やURLのパラメーターを確認します。リクエスト過多の場合は連続操作をやめ、時間を置いて再試行してください。証明書エラーでは端末の時刻とローカルの信頼環境を確認します。すべてのエラーコードを「クライアントが古い」と決めつけたり、サブスクリプション取得のために証明書検証を安易に無効にしたりしないでください。実際の取得経路の問題を見落とすおそれがあります。

共有リンクの一覧、Base64形式のサブスクリプション、ネイティブJSON設定は、ファイル拡張子だけで形式を判断できません。Base64はエンコード方式であり、正しいサーバー情報が含まれているとは限りません。ネイティブのコアJSON設定も、通常のサブスクリプション欄に貼り付けられるとは限りません。クライアントに対応したインポート方法を使い、データ構造がサポートされているか確認してください。共有リンクが1つだけの場合は、まずクリップボードから読み込めるか試すと、形式の問題とリモート取得の問題を切り分けられます。

更新後のグループと接続中のサーバー

更新が完了したら、対象グループに想定したサーバー情報が追加されているか確認し、接続中のサーバーも選び直してください。更新によって名前が変わったり、提供終了した設定が削除されたりすることがあります。以前選んでいた項目がそのまま使えるとは限りません。「更新成功」の表示だけで接続が復旧したと判断せず、サーバーを選択して接続し、決めたサイトにアクセスしてからハンドシェイク設定を確認します。似た名前のグループが複数ある場合は、更新、表示、接続の対象が同じグループか確認してください。

自動更新の間隔を短くしすぎないでください。頻繁に取得しても無効なURLは直らず、APIのリクエスト制限に達することがあります。スリープからの復帰やネットワーク切り替えと自動更新が重なる場合もあります。手動更新は成功し、自動更新だけ失敗する場合は、発生時刻と端末のネットワーク状態に関連がないか確認してください。すべての設定をすぐに作り直す必要はありません。グループ構成を変更する場合は、クライアントのエクスポート機能で復元用コピーを保存し、保護された場所に保管してください。

サブスクリプション形式と変換時の注意点はV2Rayのサブスクリプション形式を解説もご覧ください。調査後は、URLの権限、取得経路、応答形式、設定の互換性のどこに問題があったのかを明確にしましょう。結論が分かれば、誰に問い合わせるか、どこを変更するか判断しやすくなり、次に同じエラーが出た際にクライアントの削除から始める必要もなくなります。

速度が遅い：初回接続、継続転送、アプリごとに確認

「速度が遅い」といっても、Webページを開くまで時間がかかる、画像が途切れながら読み込まれる、ファイル転送が不安定、動画が何度もバッファリングするといった症状があります。それぞれボトルネックは異なります。まず、どの段階で遅くなるかを整理し、同じ端末、ネットワーク、接続先、サーバーでテストしてください。ノードのテスト結果だけで実際のアプリの使用感を判断しないでください。遅延は往復通信やテストリクエストにかかる時間を示すもので、継続的な転送速度やサイト側の状態をそのまま表すものではありません。

比較できるテスト条件を整える

まず大容量の通信を行う他のタスクを一時停止し、端末が省電力モードになっていないか、Wi-Fiの電波が安定しているかを確認してください。バックグラウンド同期、システム更新、他の端末による回線の使用で、プロキシ接続が不安定に見えることがあります。必要なら同じネットワークで有線接続を試すか、Wi-Fiアクセスポイントの近くで再テストします。比較では変更する条件を1つに絞ってください。サーバー、ネットワーク、ブラウザーを同時に変えると、どの要因で改善したのか分かりません。

サイトを初めて開くときだけ遅く、次のページは問題ない場合は、DNSの問い合わせ、接続の確立、TLSハンドシェイクを確認します。ページはすぐ表示されるのに大きなファイルの転送が遅い場合は、出口の帯域、リモート側の負荷、接続先の速度制限、パケットロスを調べてください。動画やダウンロードサイトの一部だけ遅い場合は、別の種類のコンテンツと比較します。接続先サービスが出口の地域、アカウント、コンテンツ配信サーバーに応じて異なる処理をすることがあります。ローカルポートの変更で解決するとは限りません。

実際のルートを確認し、原因の誤認を防ぐ

遅いリクエストが最終的にdirectとproxyのどちらへ進むか確認してください。特にサイトの画像、動画、APIのドメインに注意が必要です。メインページはプロキシ経由でも、静的ファイルは直接接続する場合や、その逆の組み合わせでは、一部のコンテンツだけ読み込みが止まることがあります。カスタムルールの条件が広すぎる場合は対象を絞り、ルールの順序も確認してください。グローバルモードへの一時切り替えは比較に使えますが、それだけで恒久的な解決策と判断しないでください。グローバルモードで変わるのは通信経路であり、Wi-Fiの干渉、リモート側の混雑、接続先サービスの応答遅延は解消されません。

2つのサーバー設定を比較するときは、他の条件を変えず、Webページを開く速さと継続的な転送の感覚を分けて記録してください。複数の接続先で片方だけ遅い場合は、その経路やリモート側のリソースが原因かもしれません。どの設定でも同じ接続先だけ遅い場合は、そのサイトの名前解決やサービス側の制御を確認します。テスト値を上げようとしてコアを何度も再起動しないでください。既存接続が切れたり、キャッシュが作り直されたりして、実際より遅く感じる原因になります。

通信設定とネットワーク境界

マルチプレクシングをむやみに有効にしたり、通信方式を安易に変更したりしないでください。効果はプロトコルの対応状況、接続方式、サーバー側の条件によって異なります。複数のリクエストが同じ混雑経路に集中する場合もあります。WebSocket、gRPCなどの通信方式もサーバー側との一致が必要で、クライアントの選択欄だけで切り替えることはできません。ネット上の「最適化設定」を試す前に、対応するコアとバージョンを確認し、元の設定を保存してください。効果を1項目ずつ比較して確かめ、説明できない設定をそのまま使い続けないようにしましょう。

TUN使用時に小さなページは開ける一方、一部の大きな応答や特定のアプリが何度も停止する場合は、ログ、ネットワークの比較、再現条件を確認したうえでパスMTUやネットワークによるパケット処理を調べます。MTUを下げる方法を、あらゆる速度低下に有効な対策として扱わないでください。まず通常のシステムプロキシ経由で同じ接続先をテストします。その経路で正常なら、TUN、ネットワークアダプター、ネットワーク環境に絞って確認してください。変更前の値を記録し、効果がなければ元に戻せるようにします。

調査後は、普段使うための基準条件を決めておきましょう。テスト用のサイト、動作確認済みのサーバー設定、通常のルーティングモードを固定します。次に問題が起きたときは、最初からあらゆる最適化を試すのではなく、基準条件と比べてください。時間帯によって症状が大きく変わる場合は、発生時刻を記録してサービス提供元に伝えます。ローカルの設定を安定させることで、比較に意味が生まれます。振り分けルールの設定はv2rayNのルーティング設定：directとproxyの使い分けもご覧ください。

DNSの問題：アプリ、コア、ノードの名前解決を切り分ける

DNSの問題は、ドメインにアクセスできない、待ち時間の後に接続が始まる、アプリによって結果が異なるといった形で現れます。調査前に、OSがドメインをどう名前解決するか、クライアントのコアが接続先ドメインをどう解決するか、リモートサーバーのドメインをどう解決するかを分けて考えます。ブラウザーが独自のセキュアDNSを使い、OSの名前解決を経由しない場合もあります。DNSサーバーを1つ変更しても、すべての階層が自動的に切り替わるわけではありません。エラーが出た問い合わせをどの機能が行ったのか確認してください。

エラーメッセージから名前解決の段階を特定する

リモートサーバーのアドレスを解決できないというログが出た場合は、まずノードのドメイン名を通常の方法で解決できるようにしてください。プロキシ経路が確立していないと、その経路を使うリモートDNSも動作しません。リモート接続は正常で、対象サイトのドメインだけ解決できない場合は、どのDNSリゾルバーが使われたか、どの経路で問い合わせたかを確認します。サーバーアドレスを調べた適当なIPに置き換えて終わりにしないでください。サーバー名、証明書、動的アドレスに依存する設定では、一時的に問題を回避できても、その後の保守に支障が出る場合があります。

システムの名前解決コマンドで確認できるのは、システムが取得した結果です。ブラウザーやコアも同じ結果を使っているとは限りません。次のコマンドでシステムの名前解決を比較できます。テスト用ドメインは公開されている例示用ドメインで、アカウント情報は含みません。コマンドが成功しても、アプリのログを見て実際の接続経路を確認してください。システムの問い合わせは失敗するのにブラウザーでは開ける場合、ブラウザー独自のリゾルバーやキャッシュが使われている可能性があります。システムでは成功してクライアントでは失敗する場合は、コアのDNS設定と、その問い合わせに必要な送信経路を確認してください。

nslookup example.com

ルーティングポリシーと名前解決結果の関係

Xrayのルーティングを例にすると、domainStrategyはルールの照合中にドメイン名をIPアドレスへ変換するタイミングを決めます。AsIsはルーティング照合のためにドメインを積極的に解決しません。IPIfNonMatchはドメインルールに一致しない場合にIPルールとの照合を試みます。IPOnDemandはIPが必要なルールに一致させる際に解決を試みます。これはルーティング層の設定であり、DNSサーバー一覧とは別物です。送信先設定にある同名または類似した項目と混同しないでください。変更前に、設定ファイルのどの階層にある項目かを確認します。

以下はルーティング設定の例です。対応する送信先を含む既存の設定に追加してください。クライアント設定全体としてそのまま起動できるものではありません。クライアントにグラフィカルなルート編集機能がある場合は、画面から変更する方法を優先してください。コアはルールの順に照合します。例では指定ドメインを先に処理し、その後にプライベートアドレスを処理しています。実際の送信先ラベルは現在の設定に合わせてください。ドメインがドメイン名のままコアに渡るかどうかは、アプリが使うプロキシプロトコルと名前解決方法にも左右されます。

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

キャッシュ、暗号化DNS、循環依存

DNSを変更した後も、OS、ブラウザー、アプリが古い結果を保持する場合があります。確立済みの接続も、リゾルバーの変更だけでは自動的に作り直されません。対象ページを閉じて接続を再確立し、必要に応じてOSの方法に従ってキャッシュを消去してから新しいリクエストを確認してください。問い合わせの送信先が分からないまま、複数の暗号化DNS機能を同時に有効にしないでください。ブラウザー、クライアントのリモートDNS、システムDNSを重ねると、結果の違いを説明しにくくなり、ドメイン単位の振り分けも正しく確認できない場合があります。

プロキシ経由でアクセスするDNSサービスを使う場合は、循環依存に注意してください。プロキシサーバーのドメイン名が先に解決できなければ、プロキシ経路を確立できません。経路が確立していないと、プロキシを必要とするDNSサービスにもアクセスできません。クライアントの対応機能に応じて、起動時に利用できる名前解決経路を用意し、DNSサービス自身のドメインがどう処理されるかも確認してください。利用できない送信先にすべてのDNS通信を任せたり、異なるコアに同じDNS設定をそのままコピーしたりしないでください。

復旧確認では、問題が起きたドメインと、別の種類の正常なサイトの両方にアクセスし、ルーティングが想定どおりか確認してください。Webページが開けても、すべての接続先が変わっているなら振り分けの調査は完了していません。ログにgeositeやgeoipのデータ不足が記録されている場合は、ルールデータの読み込み問題です。DNSを何度も変更するのではなく、起動・クラッシュの章でデータを確認してください。ルールのプレフィックスと優先順位はXrayのカスタムルーティングルール構文を参照してください。

システムプロキシが効かない：アプリがローカルの受信経路を使っているか確認

システムプロキシとルーティングモードは、別々の階層にある設定です。システムプロキシは、対応アプリにリクエストの送信先を伝えます。ルーティングモードは、コアに届いたリクエストをどの送信先へ進めるか決めます。v2rayNでルーティングを「グローバル」にしても、OS上のすべての通信がクライアントを経由するわけではありません。ブラウザーはシステムプロキシに従うことがありますが、コマンドラインツール、ゲーム、その他のアプリは独自の設定を使う場合があります。まず対象アプリのプロキシ方式を確認し、アプリ内の設定やTUNが必要か判断してください。

ステータスバーにある3つの選択肢

「システムプロキシを自動設定」は、クライアントが必要とするシステムプロキシ設定を書き込みます。「システムプロキシを解除」は、関連する設定を削除します。「システムプロキシを変更しない」は、クライアントが現在の状態を変更しないという意味で、自動的にプロキシを無効にする設定ではありません。以前の誤った設定が残っている場合、「変更しない」を選ぶと問題のある経路が維持されることがあります。テスト前に現在の設定を記録し、社内ネットワークや他のソフトに必要な設定を上書きしないようにしてください。テストに必要な選択肢へ明示的に切り替えます。

システムのネットワーク設定を開き、プロキシのアドレスとポートを確認してください。クライアントのステータスバーが点灯しているかだけで判断しないでください。システムの値が想定と異なる場合、他のプロキシソフト、ブラウザー拡張機能、自動設定スクリプト、管理ポリシーが設定を書き換えている可能性があります。プロキシクライアントは1つだけ起動し、プロキシを制御するブラウザー拡張機能を一時的に無効にして再テストします。管理対象端末では組織のポリシーにより設定が配布されている場合があります。設定が自動で戻るときは、繰り返し上書きせず、管理上の要件を確認してください。

手動設定と環境変数

手動プロキシに対応するアプリでは、クライアントが実際に提供しているローカルアドレスとポートを一時的に入力して比較できます。HTTP受信ポートはアプリが対応するHTTPプロキシとして、SOCKS受信ポートはSOCKSの設定として使用します。ポート番号が似ているからといって、相互に置き換えることはできません。待ち受けアドレスがローカル端末に限定されている場合、他の端末からそのポートには接続できません。端末内の問題を調べるためにLANへの公開は不要です。通常の解決策として、待ち受けをすべてのネットワークインターフェースに変更しないでください。

コマンドラインツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数を参照する場合も、まったく無視する場合もあります。GUIでシステムプロキシを変更しても、起動済みのターミナルのプロセス環境は更新されないことがあります。コマンドラインだけ失敗する場合は、ツール独自のプロキシ設定と現在の環境変数を確認してください。ブラウザーだけ失敗する場合は、拡張機能、設定ファイル、独自のプロキシ設定を確認します。1つのアプリの動作からシステム全体の状態を推測しないでください。アプリごとの差が、接続経路を特定する手がかりになります。

TUNと終了後の設定復旧

TUNは仮想ネットワークアダプター、ルーティングテーブル、権限、DNSの制御が関わる別の通信経路です。システムプロキシ設定の別名ではありません。通常のシステムプロキシ経由で通信できる場合は、まずその経路の基準テストを完了してからTUNを調べてください。両方を有効にしたまま設定が不明確だと、一部の通信が別経路に流れたり、ループしたりすることがあります。権限を求められた場合は必要な権限だけを許可し、クライアントを常に高い権限で起動する方法を唯一の解決策にしないでください。

クライアントを終了した直後にネットワークへ接続できなくなった場合は、システムプロキシが停止済みのローカルポートを指していないか確認してください。クライアントを再起動して「システムプロキシを解除」を実行し、OSのネットワーク設定で復旧を確認します。アプリ独自の手動プロキシ設定も確認してください。プロセスの強制終了、異常終了、ソフトの競合などで終了時の設定解除が中断されることがあります。まず残った設定を整理してから、再インストールが必要か検討してください。再インストールしても、OSに個別に保存されたプロキシ設定が消えるとは限りません。

同じブラウザーから新しいリクエストを送り、対応する接続がログに記録されることを確認したうえで、送信先ラベルがルーティングの想定と一致するか調べます。接続経路は復旧しても送信先が違う場合は、システムプロキシではなく振り分けルールを確認してください。デスクトップ環境によってプロキシ設定の対応範囲は異なります。特にLinuxアプリは独自のネットワークスタックを使う場合があるため、必要に応じてアプリ内で明示的に設定してください。初期設定は使い方ガイドを参考に、再現可能な接続手順を整えましょう。

起動・クラッシュ：画面、コア、設定データを分けて確認

クライアントのウィンドウが開かない、ウィンドウは開くがコアを起動できない、接続中にプロセスが終了する、という3つの問題は別々に調査します。発生タイミングを記録してください。プログラムをダブルクリックするとすぐ終了するのか、サーバーを選んだ後にエラーが出るのか、サブスクリプションやルールの更新後に発生したのかを確認します。v2rayNのGUIとプロキシコアはそれぞれ役割が異なるため、画面が正常に表示されていてもコアが動作しているとは限りません。コアの終了がクライアント全体のクラッシュとは限りません。アプリのメッセージ、コアログ、システムのエラー記録を分けて確認してください。

インストーラー、アーキテクチャ、実行環境

まず、ダウンロードしたインストーラーが端末のOSとプロセッサーアーキテクチャに合っているか確認してください。デスクトップではv2rayNを推奨します。Windowsではデスクトップ版と従来のWPF版で、画面構成や実行環境の要件が異なります。macOSとLinuxでも、チップやディストリビューションに合ったものを選んでください。プログラムを再取得する場合は、クライアントのダウンロードページで対応環境を確認します。アイコンだけでアーキテクチャを判断したり、古いフォルダーから実行ファイルを1つだけ取り出して置き換えたりしないでください。プログラム本体と付属データの組み合わせが合わなくなるおそれがあります。

実行環境が必要な場合は、インストーラーの案内やシステムのエラーメッセージを確認し、対応するコンポーネントを追加してください。似た名前のものを適当にダウンロードしないでください。インストール先に書き込みや実行の権限があるか、制限されたディレクトリにないか、セキュリティソフトがプログラムやデータをブロックしていないかも確認します。ブロック履歴を調べてから対処し、セキュリティ機能全体を無効にしないでください。Linuxではファイルの権限とデスクトップの起動設定、macOSではOSのセキュリティや権限の通知に従って、プログラムの入手元と許可方法を確認してください。

最初のエラーからコアの起動失敗を特定

コアログに待ち受けの失敗が記録されている場合は、まずアドレスやポートの競合を確認します。設定の解析エラーが出ている場合は、JSONの構文、項目の配置、現在のコアが対応している範囲を確認してください。JSONでは末尾のカンマは使えません。数値、文字列、真偽値など、項目に合った値の型も必要です。GUIクライアントが設定を生成している場合は、画面上の元設定を修正してください。一時生成ファイルを手動で編集すると、次回の再読み込みで上書きされ、「直してもまた壊れる」状態になることがあります。

listen tcp 127.0.0.1:1080: bind: address already in use

上のメッセージは、ポート競合でよくあるエラーの例です。ポート番号は例であり、クライアントのデフォルト値を示すものではありません。競合元を特定してから、該当するアプリを終了するか、クライアントの待ち受けポートを変更し、アプリのプロキシ設定も合わせてください。用途の分からないシステムプロセスを強制終了しないでください。古いコアのプロセスが終了していない場合は、クライアントを通常の方法で終了してしばらく待ち、再起動します。プロセスが繰り返し残る場合は、セキュリティソフトの干渉、権限、終了時のログを調べてください。再起動だけを繰り返さないでください。

ルールデータ、コアの互換性、設定の復旧

geositeやgeoipに関するエラーが出た場合は、データファイルが存在するか、読み取り可能か、参照先のセットがそのデータに含まれるかを確認してください。ルール名の誤記とファイル不足は別の問題です。データを更新しても、セット名の誤りは直りません。他のコア環境からコピーしたカスタムルールには、現在のコアが認識しない項目が含まれる場合もあります。まず最後に追加したルールを1つ戻し、コアが起動するか確認してください。すべてのルーティング設定を一度に削除するより、有効な設定を残しやすくなります。

Xray系とV2Fly系のコアを切り替える際は、プロトコル、通信方式、拡張項目の互換性を改めて確認してください。関連するエコシステムですが、すべての設定が共通で使えるわけではありません。特定のコアでだけエラーが起きる場合は、まずそのコアが明確に対応している設定で基準状態を作り、違いを確認します。ファイル名を変更してコアを強制的に置き換えたり、一方のコア固有の項目を別の設定に残したりしないでください。クライアントの切り替え機能と設定の生成方法は、対応する組み合わせで使用してください。

ユーザーデータの読み込み中に画面がクラッシュする場合は、まずプログラムを終了し、クライアントのデータフォルダーをバックアップしてください。クライアントが対応する方法で、独立した新しい設定を作成して比較します。元のフォルダーをすぐに削除しないでください。グループ、ルーティング、サブスクリプションの情報が含まれている場合があります。新しい設定で正常に動作するなら、設定を少しずつ戻して破損や非互換の項目を特定します。新しい設定でも失敗する場合は、実行環境、権限、システムログを確認してください。詳しいエラーの読み方はv2rayNのコア起動失敗をログから調べるをご覧ください。

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

Android版のv2rayNGとv2flyNGは通常、システムのVPNインターフェースを使ってアプリの通信を取り込みます。デスクトップのシステムプロキシとは確認方法が異なります。ステータスバーにVPNアイコンが表示されても、システムに接続状態があることを示すだけで、リモートのハンドシェイクや対象サイトへのアクセスが成功したとは限りません。まずクライアントで接続する設定を選び、接続を開始してログを確認してから、決めたブラウザーでテストしてください。2つのクライアントはコアの系統が異なります。特定のプロトコルや通信方式を使う場合は、画面が似ているかどうかだけで判断せず、互換性を確認してください。

システムの許可とVPNの競合

初回接続時は、システムのVPN接続許可を確認する必要があります。許可を取り消したりシステムポリシーでブロックされたりすると、端末の通信が想定どおりクライアントに入りません。ローカルネットワークのフィルターや仕事用ツールなど、VPNインターフェースを使う別のアプリが動いていないか確認してください。同じ接続経路を取り合い、一方を起動すると他方に影響することがあります。競合するアプリを停止してから接続し直し、システムの通知を確認します。組織管理端末では利用方法に制限がある場合があるため、端末ポリシーを先に確認してください。

システムの「常時接続VPN」と「VPNを使わない接続をブロック」は、切断時のネットワーク動作を変えます。クライアントが起動していない、または接続を確立できていないのに、すべての通信にVPNを要求すると、端末全体がネットワークへ接続できなくなる場合があります。これらの項目を確認する際は、目的を理解し、現在の状態を記録してから比較してください。切断保護による通信遮断をWi-Fiの故障と誤認したり、理由を調べず端末のネットワーク設定をすべてリセットしたりしないでください。まずクライアントとシステムポリシーの状態を合わせます。

アプリ別ルールとネットワーク切り替え

特定のアプリだけ接続できない場合は、クライアントでアプリ別プロキシ設定が有効か、選択したアプリだけをプロキシ経由にするモードか、選択したアプリを除外するモードか確認してください。この2つは動作が逆です。同じアプリを選んでも結果は正反対になります。リストを変更した後は、新しいルールを現在の設定に反映させるため、画面の案内に従って接続を再確立してください。システムアプリ、仕事用プロファイルのアプリ、通常インストールしたアプリは、対象範囲が異なる場合があります。名前が同じだからといって、正しいアプリを選んだとは限りません。

Wi-Fiでは正常でモバイルデータ通信だけ失敗する場合は、いったん接続を切り、対象ネットワークが安定してから再接続します。モバイルデータ通信の権限、データ通信制限、ネットワーク認証も確認してください。ネットワークの切り替えでIPアドレス、ルート、名前解決環境が変わるため、既存の接続が維持されるとは限りません。逆のケースも同じ手順で比較し、サーバーとテストサイトは変えないでください。特定のネットワークだけでDNSエラーやリモート接続エラーが出る場合は、該当する章に戻って調べます。サブスクリプションの内容はネットワークの種類によって自動的に無効になるわけではないため、すぐに全削除しないでください。

画面ロック後の切断とバックグラウンド動作

前面では接続できるのに画面ロック後に切断される場合は、バッテリー最適化、バックグラウンド動作、システムの自動終了設定を優先して確認してください。設定場所は端末によって異なります。システムのアプリ詳細画面で該当項目を探し、常時接続が必要なクライアントだけを調整します。すべての省電力設定を一度に変更しないでください。どの項目が原因だったのか分からなくなります。変更後は画面をロックした状態でしばらく待ち、復帰後にクライアントのプロセス、VPNの状態、ログの時刻を確認し、プロセス終了、一時的なネットワーク休止、リモート接続の切断を切り分けます。

最近使ったアプリの一覧から削除する、ワンタップでクリーニングする、極端な省電力モードを有効にする、といった操作でバックグラウンドサービスに影響が出ることがあります。システムにVPNアイコンが残っていても、アプリのログが更新されない場合は、クライアントを開いて動作状態を確認してください。必要に応じて通常の方法で停止し、再起動します。通知が残っているかどうかだけで接続状態を判断しないでください。バックグラウンド接続は端末のリソースを消費するため、復旧後はバッテリー消費、通信量、安定性も確認します。再接続の繰り返しと異常なリソース使用が見られる場合は、まずネットワークや設定の問題を解決してください。

インストール・更新後の復旧確認

インストーラーはAndroidのダウンロードページで端末のアーキテクチャに合うものを選んでください。アーキテクチャが分からない場合は、端末情報とダウンロードページの説明を確認します。インストールに失敗した場合は、アーキテクチャの非互換、OS要件、ストレージ不足、既存アプリと配布元の違いを切り分けてください。別のインストーラーを試すために、すぐアンインストールしないでください。設定やサブスクリプション情報を先に保存します。v2rayNGとv2flyNGの切り替えは、単なる外観の変更ではありません。読み込む設定が対象のコア機能に対応しているか確認してください。

最終確認では、アプリを前面で使う、画面をロックして復帰する、ネットワークを一度切り替える、という3つの状況を試します。それぞれでリクエストがクライアントに届き、ルーティングも想定どおりか確認してください。アプリ別モードでは、プロキシ対象のアプリと除外対象のアプリを1つずつテストします。復旧に必要な最小限の設定を記録し、他のシステム設定は元の状態に保ってください。問題を報告する場合は、端末のOS、クライアント名、ネットワークの種類、機密情報を隠したエラーの一部を伝えます。基本操作は使い方ガイド、個別設定の疑問はよくある質問をご覧ください。