V2Rayトラブル対処
接続・サブスクリプション・システムプロキシ

インターネットに接続できない：通信が途切れる箇所を特定する

すべてのWebページが開けない場合も、設定をすぐに削除しないでください。通信は通常、アプリ、通信の入口、ローカルのコア、リモートサーバー、接続先の順に進みます。画面上で実行中と表示されても、すべての区間が正常とは限りません。他のプロキシツールを終了し、いったんTUNを無効にして、システムプロキシを「システムプロキシをクリア」に設定します。普段、直接アクセスできるサイトを開き、基本ネットワーク、Wi-Fi認証、デフォルトゲートウェイが正常か確認してください。

まず直接接続を確認し、次にローカルの待ち受けを調べる

プロキシをクリアしてもアクセスできない場合は、ネットワークへのログインが必要か、システム時刻が正確か、同じネットワーク上の他の端末は正常かを確認してください。この段階でサーバーを次々に切り替えても、解決につながらないことがあります。直接接続が復旧したらv2rayNを起動し、既存のサーバーを選択して「サービスを再起動」を実行します。ログにコアの終了、設定の解析エラー、待ち受けの失敗がないか確認してください。タスクトレイのアイコンだけでは判断できません。ウィンドウが開いたままコアが終了していると、ブラウザーは存在しないローカルサービスに接続しようとします。

「設定」から「パラメータ設定」を開き、「ローカル混合待ち受けポート」の値を記録します。以下のコマンドはポートが10808の場合の例です。異なる場合は、先にコマンドを修正してください。まず待ち受けの有無を調べ、次にプロセスを照合します。このポートを使用しているというだけで、任意のプログラムを正しいコアと判断してはいけません。待ち受けが確認できても、分かるのはローカルの入口が用意されたことだけです。リモート接続は次の手順で検証します。

# Windows PowerShell：待ち受けアドレス、ポート、プロセスを確認
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# ローカルHTTPプロキシに明示的なリクエストを送信
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

コマンド内の接続先はリクエスト方法を示す例であり、現在のネットワークからアクセスできるとは限りません。実際の調査では、アクセス可能なことが分かっている接続先を選び、前後のテストで同じものを使用してください。接続先からHTTPレスポンスが返れば、アクセス拒否やリダイレクトであっても、接続タイムアウトとは異なります。何らかのHTTPサービスまでリクエストが届いたことを示します。証明書エラーが出た場合は、時刻、接続先名、証明書チェーンを確認してください。証明書検証を無効にしてエラーを隠してはいけません。

推測ではなく、結果を見て次の手順を決める

明示的なプロキシでリクエストが成功した場合は、「システムプロキシを自動設定」を選び、ブラウザーを完全に終了してから再起動し、もう一度テストしてください。それでも失敗する場合は、プロキシ拡張機能を入れていない別のブラウザーでも確認します。一つのアプリだけで問題が起きるなら、そのアプリのプロキシ設定、キャッシュ、ネットワーク権限を調べてください。すべてのアプリで問題が起きる場合は、システム側の通信経路を確認します。シークレットウィンドウでも拡張機能がすべて無効になるとは限らないため、拡張機能の影響を完全に除外する根拠にはなりません。

一部のサイトだけで失敗する場合は、ドメイン名、エラーの種類、発生時刻を記録し、直接接続ルールに一致していないか確認します。ルーティングを一時的に切り替えるのは比較テストに限り、問題を隠すためにすべての通信を長期間同じ経路に流してはいけません。元のルールに戻し、接続先のドメイン判定、名前解決の結果、ルールの順序を確認してください。ルートを変更した後は新しい接続を確立します。既存の接続には以前の出口が使われることがあるため、すぐにページを再読み込みしても新しい設定が反映されるとは限りません。

今回の調査を終える前に、「直接接続は正常か」「ローカルで待ち受けているか」「明示的なプロキシは成功するか」「アプリに設定が反映されているか」の4点を記録してください。「インターネットに接続できない」という一言より、次の切り分けに役立ちます。個別の質問はよくある質問をご覧ください。待ち受けポートを確保できない場合は、ローカルポートの競合を調べるに進み、クライアントの再インストールを繰り返さないでください。

サーバーがタイムアウトする：通信接続とプロトコルのハンドシェイクを切り分ける

サーバーの接続テストでタイムアウトしても、サーバーが停止しているとは限りません。名前解決、接続の確立、暗号化ハンドシェイク、テスト用接続先からの応答のどの段階でも止まる可能性があります。まずテストの接続先と方法を確認し、テスト先にアクセスできないだけの状態を、すべての通信が失敗していると誤解しないようにしてください。現在のサーバー設定は残したまま、同じサブスクリプションにある既知の正常なサーバーと比較します。サブスクリプションの更新、コアの切り替え、通信パラメータの変更を一度に行うと、どの変更が結果に影響したのか分からなくなります。

ログを順に追い、最初のエラーを特定する

まずサーバーアドレスとポートが正しいか確認します。コピー時に空白や改行が混入していないか、ポートが欠けていないかも確認してください。名前解決に失敗する場合は、まず名前解決の問題を調べます。接続拒否は、そのアドレスに該当するサービスがないか、途中の機器が明示的に拒否したことを示す場合があります。接続タイムアウトだけでは、どこに原因があるか特定できません。最初に見つかった関連エラーを記録してください。その後に続く接続キャンセルは、最初の失敗による連鎖反応かもしれません。

Windowsでは、リモートポートへの通常のTCP接続を確立できるか確認できます。以下の例ではPowerShellの対話入力を使い、既存の設定にあるアドレスとポートを入力するため、実際の情報がコマンド履歴に残りません。テスト成功が示すのはTCP層で到達可能ということだけで、認証情報、通信経路、TLSの設定が正しいとは限りません。失敗してもサーバー側の故障を直接示すものではありません。UDPのみを使う通信の確認には適さないため、結果はテストしたプロトコルの範囲で解釈してください。

$server = Read-Host "設定済みのサーバーアドレスを入力"
$port = [int](Read-Host "設定済みのサーバーポートを入力")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

通常の接続は確立できるのにクライアントがハンドシェイクエラーを表示する場合は、プロトコルとトランスポート層の設定を確認します。VMess、VLESS、Trojanの認証情報は相互に置き換えられません。WebSocketのパスとHost、gRPCのサービス名は、いずれもサーバー側の設定と一致させる必要があります。TLSを使う場合、接続先アドレスとサーバー名が異なることがあります。アドレスにIPを指定しているからといって、サーバー名を削除しないでください。REALITYの公開鍵、ショートIDなどのパラメータも正しい設定から取得する必要があります。別のサーバーの設定を参考にして継ぎ合わせてはいけません。

時刻、ネットワーク、コアを個別に確認する

証明書の有効期間や認証時刻に関するエラーが出る場合は、まずシステムの日付、タイムゾーン、自動時刻合わせの結果を確認します。時刻のずれは証明書や一部の認証処理に影響しますが、時刻の調整ですべてのタイムアウトが解消するわけではありません。証明書名が一致しない場合は、サーバー名と設定の入手元を確認してください。証明書検証を無効にすることを恒久的な対処にしてはいけません。社内ネットワークで認証が必要な場合や、管理対象のセキュリティソフトがある場合も、保護機能を無効にするのではなく、まず接続ポリシーを確認してください。

別のネットワークで再テストする場合、クライアント、サーバー、接続先は変えないでください。利用が許可されたモバイルホットスポットなどで同じリクエストを実行し、元のネットワークでもテストします。特定のネットワークだけで失敗するなら、ネットワーク認証、出口の制限、アドレスファミリーの到達性を確認してください。すべてのネットワークで失敗し、他のサーバーは正常なら、そのサーバーの稼働状況と設定を重点的に調べます。デュアルスタック環境では、名前解決で得たIPv6アドレスへの経路が使えない場合がありますが、それを理由に端末全体のIPv6を恒久的に無効にしないでください。

Xrayなどの対応コアに切り替える前に、対象のコアがサーバーのプロトコルと通信方式をサポートしているか確認します。画面上で設定項目を保存できても、どのコアでも同じ意味で処理されるとは限りません。元の設定を残したうえで、サブスクリプションとクライアントに合った組み合わせを個別にテストしてください。新しい設定をインポートしてから問題が起きた場合は、直前まで使えていた設定と比較できます。ただし、取り消し済みまたは期限切れの認証情報を正しい基準として使わないでください。

設定の提供元に結果を伝えるときは、発生時刻、ネットワークの種類、プロトコル、TCP接続の成否、機密情報を除いた最初のエラーを記載してください。サブスクリプション全体や認証情報を含む画面のスクリーンショットは送らないでください。一つのサーバーで一部の接続先だけが使えない場合は、出口のルーティングとDNSも確認します。すべての接続先が同じ段階で失敗すると確認できた場合に限り、サーバー自体の問題として扱いましょう。復旧後は一時的な詳細ログ設定を解除し、テスト用ルートを元に戻してください。

サブスクリプションを更新できない：取得・解析・適用を分けて確認する

サブスクリプションの更新失敗には、URLからデータを取得できない、取得したデータを認識できない、リストは更新されたが選択中のサーバーが使えない、という少なくとも3つのケースがあります。ログでどの段階まで進んだかを確認し、「サブスクリプショングループ設定」の対象グループを調べてください。同じ名前のグループを次々に作成したり、エラーの整理を急いで最後に使える設定を削除したりしないでください。更新前にグループ名、サーバー数の変化、選択中の項目を記録しておくと、更新後の選択変更をサブスクリプション全体の不具合と取り違えずに済みます。

URLが有効で、取得内容が設定データであることを確認する

まずURLが完全か確認します。クエリパラメータ、大文字と小文字、末尾の文字もリクエストに影響することがあります。サブスクリプションURLはアクセス権限を含むことが多いため、アカウント情報と同様に扱い、公開チケット、スクリーンショット、オンライン変換ツールに入力しないでください。Webページのボタンから取得した場合は、コピーしたものがサブスクリプションURLであり、アカウントページ、QRコード画像のURL、ブラウザーのリダイレクト先ではないことを確認します。ブラウザーで表示された内容は参考になりますが、クライアントが同じレスポンスを受け取るとは限りません。

未認証、アクセス禁止、リソースが見つからないといったレスポンスが返る場合は、サブスクリプションの期限切れ、トークンの再発行、URLの変更がないか確認してください。この場合、DNSを何度も変更しても権限の問題は解決しません。ログインページ、CAPTCHA、メンテナンスのお知らせが返る場合、ステータスコードが成功を示していても、ノード設定ではありません。設定の提供元から正しいURLを取得してください。Webページの本文を手作業でエンコードしてクライアントにインポートしないでください。

リクエストがタイムアウトする場合は、更新時の通信経路を切り分けます。既存の接続が正常なら、プロキシ経由での更新を試せます。使えるサーバーが一つもない場合は、メニューの「プロキシを経由せずにサブスクリプションを更新」に相当する経路を試してください。両方を無条件に使うのではなく、サブスクリプションサーバーへの到達性に応じて選びます。更新リクエストの経路はブラウザーと同じとは限りません。ブラウザー拡張機能、システムプロキシ、TUNの組み合わせによって、比較結果が誤解を招くことがあります。

形式を確認し、更新後の選択状態も確認する

クライアントによって、対応するサブスクリプション形式や拡張パラメータは異なります。専用ルールを多く含む完全な設定ファイルは、サーバーリスト用のサブスクリプションとして直接インポートできるとは限りません。インポートに成功しても、拡張フィールドがすべて保持されるとは限りません。v2rayNまたはAndroidクライアント向けと明記された形式を入手してください。変換が必要な場合は、どのフィールドが処理されるかを確認し、信頼できる環境で実行します。特に、トランスポート層、TLS、REALITYのパラメータが失われていないか確認してください。

更新後にサーバーが消えた場合、サブスクリプショングループのフィルターや検索欄を確認してください。サブスクリプションからデータが返っていないとすぐに判断してはいけません。空白や大文字・小文字の違いを含むフィルターキーワードによって、利用可能な項目がすべて隠れていることがあります。一時的な検索条件をクリアし、意図したグループが更新されたか確認してください。既存サーバーがサブスクリプションで置き換わった場合、以前選択していた項目がなくなっていることがあります。リストからサーバーを選び直してサービスを再起動し、グループの更新表示だけで判断せず、明示的なプロキシリクエストで確認してください。

自動更新の間隔を設定する前に、手動更新を一度行い、通信経路が安定していることを確認してください。間隔が短すぎるとリクエストが重複し、サーバー側の制限を受けることがあります。端末がスリープ中、オフライン、またはバックグラウンド処理を停止されている場合、タイマーは実時間どおりに動くとは限りません。予定された更新が一度抜けただけで、複数の更新タスクを同時に有効にしないでください。頻繁に失敗するグループは一時的に手動更新へ戻し、失敗時刻とレスポンスを記録してから、ネットワークと権限を調べます。

手動更新は成功するのに自動更新だけ失敗する場合は、端末の復帰時刻、ネットワークの切り替え、更新時のプロキシ状態を比べます。すべてのクライアントで同時に失敗する場合は、URLとサーバー側の状態を確認してください。調査記録にはエラーの種類だけを残し、サブスクリプションURL全体を保存しないでください。グループの更新方法や間隔については、サブスクリプション更新失敗と自動更新の設定をご覧ください。URLの更新後もタイムアウトする場合は接続の問題に戻り、成功を期待して更新を繰り返さないでください。

速度が遅い：遅延、スループット、パケットロスを切り分ける

Webページの表示開始が遅い、ファイルのダウンロードが遅い、動画が何度も止まる、といった症状はそれぞれ原因が異なります。最初のリクエストに時間がかかる場合、名前解決、接続確立、ハンドシェイクが原因かもしれません。ダウンロード速度が継続して低い場合は、リモート側の出口、接続先サイト、Wi-Fi、本体の負荷などが影響します。「最初の表示は遅いが再読み込み後は正常」「大きなファイルはすべて遅い」のように、再現できる症状を記録してください。一度の遅延テストだけでサーバーを順位付けして原因を決めつけないでください。往復時間が短くても、スループットが高いとは限りません。

テスト条件を固定して、通信経路を比較する

同じ接続先、同じファイル、近い時間帯で比較し、クラウド同期、OSのダウンロード、その他のネットワーク使用タスクを一時停止します。直接接続とプロキシ接続で異なる接続先を使うと、経路の違いだけを比較できません。CDNの配信先が変わることでも結果が変動します。まず一つのサーバーで2～3回繰り返し、次に別のサーバーを試してください。速度測定を同時に複数実行すると帯域を奪い合い、正常な接続まで遅く見えることがあります。

以下のコマンドは取得したデータを破棄し、リクエストの各段階にかかった時間と平均ダウンロード速度だけを出力します。小規模な繰り返しテストに適しています。接続先とポートは実際の環境に合わせてください。HTTPプロキシ経由の場合、名前解決や接続時間の意味はプロキシの方式によって異なります。各項目をリモートDNSやリモートサーバーの独立した処理時間とみなすことはできません。小さなページの平均速度はハンドシェイクの影響を受けやすく、大きなファイルの上限を推測する用途には向きません。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" https://example.com/

接続のたびに通信速度は速いのに最初のデータが届くまで時間がかかる場合は、接続先サービスの応答とリモート側の出口を確認します。最初のデータがすぐ届く一方、転送中に何度も停止する場合は、Wi-Fiの電波、パケットロス、システムリソースを調べてください。通常のpingが拒否されてもサービスへの接続失敗とは限りません。pingが連続して成功しても、暗号化接続に問題がないとは言えません。実際に使うプロトコルでリクエストを試し、ネットワーク診断ツールの結果は参考情報として扱い、一つの数値だけで全体を判断しないでください。

ローカルリソースと通信経路の影響を除外する

タスクマネージャーまたはシステムモニターで、コアプロセスのCPU使用率、メモリ、ディスクの動作を確認します。古い端末、省電力モード、温度制限は、暗号化や転送に影響することがあります。ログが長時間詳細レベルになっていると、追加の書き込みが発生する場合もあります。まず通常のログレベルに戻し、不要なバックグラウンドタスクを終了してから再試行してください。リソースを節約するためにセキュリティソフトを安易に無効化しないでください。また、異常な高負荷をすべてクライアントのせいにせず、その時点で実際にどの通信が行われていたかも確認します。

明示的なプロキシ、システムプロキシ、TUNをそれぞれテストする場合は、毎回一つの経路だけを有効にします。TUNだけ遅い場合は、仮想ネットワークアダプター、ルートの競合、他のネットワークフィルターソフトを確認してください。大きなファイルや特定の経路だけで停止する場合は、既定値を記録したうえでMTUの適合性を調べます。インターネット上の数値をコピーして、恒久的に設定しないでください。MTUの変更後は接続を再確立し、複数の接続先で検証します。小さなページが正常でも、問題が解決したとは限りません。

動画の再生停止は、接続先の速度制限、CDNの配信場所、アプリ独自のバッファリング方法が原因の場合もあります。一つのサーバーで特定のサイトだけ遅く、他のサイトは正常なら、すぐに再インストールせず、その接続先へのルートと出口を確認してください。ブラウザーのセキュアDNS、拡張機能、キャッシュにより、コマンドラインとは異なる経路が使われることがあります。アプリがUDPを使っている場合、通常のWebページを使ったTCPテストでは実際の動作を確認できません。比較時はアプリ、接続先、トランスポートの種類を記録してください。

夜は遅く昼は正常で、端末リソースとWi-Fiが安定しているなら、時間帯による混雑を仮説として確認します。別のネットワークで改善する場合は、ローカル回線をさらに比較してください。設定を変更した直後に一度速くなっただけで、変更が原因だと決めつけないでください。元の設定に戻して逆方向の比較も行います。改善を再現できると確認してから、必要な変更だけを残してください。ルールを複雑にしても速度は上がりません。重複するプロキシ設定や不要なフィルターを減らすほうが、複数の「高速化」設定を追加するより安定しやすくなります。

DNSの問題：接続先ドメインをどこで名前解決するか確認する

ドメイン名では開けず一部のIPアドレスには接続できる場合、名前解決の経路を調べる手がかりにはなりますが、DNSだけが原因とは限りません。HTTPSサイトはサーバー名と証明書を使うため、IPアドレスを直接開くとリクエストの条件が変わります。システムの名前解決、ブラウザーのセキュアDNS、プロキシコアでの名前解決、リモート側での名前解決を切り分けてください。同じドメインでも、名前解決する場所によって異なる結果が返ることがあります。どのアプリがどのプロキシ方式でリクエストを送ったのかを記録してから、調整する箇所を判断します。

まず名前解決の結果を確認し、その後キャッシュを処理する

Windowsでは以下のコマンドでシステムの名前解決結果を調べ、各ネットワークインターフェースのDNS設定も確認できます。有線、無線、仮想ネットワークアダプターが同時に存在する場合があります。実際にシステムが使用している経路が、確認中のアダプターとは限りません。複数のアドレスが返ること自体は異常ではありません。CDNやデュアルスタック対応のサービスでは複数のレコードが返ることがあります。名前解決エラーが出ていないか、想定外のプライベートIPアドレスが返っていないか、そのアドレスに現在のネットワークから到達できるかを確認してください。

# Windows PowerShell：システムの名前解決結果とインターフェースのDNSを確認
Resolve-DnsName example.com
Get-DnsClientServerAddress

# 名前解決の設定を修正した後、必要に応じてシステムキャッシュを消去
Clear-DnsClientCache

キャッシュの消去は設定を修正した後に行います。上流に問題が残っていれば、消去しても同じ誤った結果を再取得するだけです。ブラウザー、クライアントのコア、アプリにも独自のキャッシュがある場合があり、システムコマンドですべてを消去できるわけではありません。必要に応じて対象アプリを完全に終了し、コアを再起動してから試してください。毎回の名前解決確認で端末全体を再起動する必要はありません。スリープからの復帰後やネットワーク切り替え後だけ問題が起きる場合は、以前のインターフェースのDNS設定が残っていないか確認します。

SOCKSでは、接続先の名前解決をローカルで行う方法と、プロキシに任せる方法があります。以下の2つのコマンドで異なるのは名前解決の場所であり、「片方が安全で片方が危険」という違いではありません。ローカルの混合ポートが該当するサービスを提供している場合のみ、この方法でテストしてください。リモート側で名前解決する方法だけ成功する場合は、ローカルの名前解決とルーティングを確認します。両方失敗する場合は接続ログも調べてください。DNSアドレスを変更するだけでは原因を特定できません。

# 接続先ドメインをローカルで名前解決
curl.exe --socks5 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

# 接続先ドメインの処理をSOCKSプロキシに任せる
curl.exe --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

ドメイン判定とルーティングルールを合わせて確認する

v2rayNのルーティング設定にあるドメイン戦略は、IPルールの判定に必要な名前解決のタイミングに影響します。Xrayの動作を例にすると、AsIsはルーティングのために接続先ドメインを能動的に名前解決しません。IPIfNonMatchはドメインルールに一致しない場合に、名前解決後のIPアドレスでの判定を試みます。IPOnDemandはIPルールの処理時に名前解決を行う場合があります。実際に選べる項目や動作は使用中のコアによって異なるため、一つのコアの説明を別のコアにそのまま当てはめないでください。

以下の断片はルーティングの動作を理解するための例であり、クライアントが生成した設定ファイルを置き換えられる完全なファイルではありません。ドメイン戦略とルールの関係を示すもので、汎用DNSアドレスを提示したり、クライアント画面での設定を代替したりするものではありません。次回サービスを再起動した際に自動生成された設定で上書きされないよう、実際の変更はクライアントの画面から行ってください。ルールは上から順に確認します。先に一致した直接接続ルールによって、後続のプロキシルールが適用されないことがあります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

暗号化DNSを使う場合、リゾルバーへの接続にも到達可能な経路が必要です。リゾルバーのドメインを最初に名前解決する処理、接続の出口、プロキシの起動順序が相互に依存すると、ループが起きることがあります。DNSがないとプロキシに接続できず、プロキシがないとDNSにアクセスできない状態です。まず基本的な名前解決を復旧させてから、高度な設定を一つずつ有効にしてください。システム、ブラウザー、コアを一度に同じ新しいリゾルバーへ変更すると、どの設定が実際に使われたのか分からなくなります。

社内ネットワーク、家庭内の端末名、パブリックドメインでは、必要な名前解決の範囲が異なる場合があります。すべての問い合わせをパブリックDNSに送ると、内部の名前が解決できなくなることがあります。内部アドレスを無理にリモートへ送ると、ローカルアクセスが壊れる場合もあります。復旧後は、パブリックサイト、LAN内サービス、スリープからの復帰時の動作をそれぞれ確認してください。IPv6を使う場合は、デフォルトルートとアドレスへの到達性を先に確認します。そのうえで必要なら特定アプリのアドレス選択を調整し、経路の切り分けをせずにシステム全体のIPv6を無効にしないでください。

システムプロキシが効かない：まずアプリを確認し、次にTUNを調べる

「システムプロキシを自動設定」にしてもアプリが直接接続する場合は、そのアプリがシステムプロキシを参照するか確認してください。システムプロキシはアプリに提供する設定であり、すべての通信を強制的に中継するものではありません。独自の設定を使うアプリもあれば、コマンドラインツールのように環境変数だけを参照するものもあります。TUNは仮想ネットワークインターフェースとルーティングを使って通信を処理するため、より広い範囲が対象です。目的の異なる方式なので、システムプロキシが機能しないからといって、すべての通信経路を同時に有効にしないでください。

システムプロキシの3つの選択肢が適用される範囲を理解する

「システムプロキシを自動設定」は通常、システムの通信入口をクライアントのローカル待ち受け先に設定します。「システムプロキシをクリア」は該当するプロキシ設定を削除します。「システムプロキシを変更しない」は、クライアントが既存の設定を変更しないという意味であり、必ず直接接続になるわけではありません。切り替え後はOSのネットワーク設定でアドレスとポートを確認し、手動プロキシと自動設定スクリプトが併用されていないか特に注意してください。他のソフトがシステム設定を書き換えることもあります。画面に一度成功と表示されても、その後も設定が維持されるとは限りません。

ブラウザーのプロキシ拡張機能、管理ポリシー、アプリ内の設定がシステムの通信経路より優先されることがあります。該当する拡張機能を一時的に無効にし、アプリを完全に終了してから開き直してください。組織が管理するブラウザーの場合、ポリシーを勝手に変更しないでください。Windowsではネットワークコンポーネントによって異なるプロキシ設定を使うこともあります。システムサービスと現在のユーザーのブラウザーで設定が共有されない場合もあります。したがって、ブラウザーが使えるだけでは、更新サービス、ターミナル、バックグラウンドプログラムも同じ経路を使っているとは言えません。

コマンドラインでは、まず明示的なプロキシ指定でテストし、成功してから環境変数を確認してください。環境変数を長期間変更すると、元に戻し忘れることがあります。以下の例は現在のPowerShellセッションだけに適用され、該当する変数をサポートするツールで使えます。参照する変数名や優先順位はプログラムによって異なります。NO_PROXYに接続先を指定すると、その接続先はプロキシを経由しません。広すぎるドメインのサフィックスが含まれていると、「一部のサイトだけ常に直接接続する」原因になります。

# 現在のPowerShellセッションのみ。ポートはクライアントの実際の設定に合わせて変更
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

# テスト終了後に今回の設定を解除
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

最小限の設定でTUNを個別に検証する

プロキシ設定を参照しないアプリの通信を取り込む必要がある場合に限り、「TUNモードを有効にする」を確認してください。他の仮想ネットワークツールや重複するプロキシを終了し、コアが正常で、通常のプロキシリクエストが成功することを確認してから、クライアントの案内に従って権限を設定します。権限不足、仮想インターフェースの作成失敗、ルート設定の失敗が起きた場合はログで原因を調べ、スイッチを何度も切り替えないでください。権限を昇格する前に、起動しようとしているものが正しいクライアントか確認します。調査のためにダウンロードフォルダー全体の権限を恒久的に緩めないでください。

TUNを有効にした後、すべての通信ができなくなった場合は、まずデフォルトルートがループしていないか、クライアントからリモートサーバーへの通信が再び仮想インターフェースに送られていないか確認してください。複数の仮想ネットワークツールが同時にルートを変更すると、画面上の優先順位と実際の通信経路が異なる場合があります。まずツールを一つずつ終了し、クライアントを一つだけ起動してテストしてください。ルートを確認する場合、Windowsではroute print、Linuxではip routeを使えます。まず記録し、見知らぬコマンドでデフォルトルートを削除しないでください。

TUNを使った場合だけLANに接続できないなら、プライベートIPアドレスのルール、インターフェースの選択、DNSを確認します。「LANからの接続を許可」を有効にするのは適切な対処ではありません。この設定が制御するのは、他の端末がローカルのプロキシ待ち受けに接続できるかどうかであり、この端末からLANにアクセスできるかとは別の問題です。待ち受けを公開する場合は、ファイアウォールと信頼できるネットワークの範囲も考慮する必要があります。LANの問題すべてに使える対処ではありません。端末自身の通信経路の調査と、他の端末にプロキシを提供する目的を分けて考えてください。

クライアント終了後にネットワークへ接続できなくなった場合は、まずシステムプロキシをクリアし、仮想インターフェースとルートが解除されているか確認します。必要であれば通常の画面操作で物理ネットワークに再接続してください。ネットワーク全体をリセットすると、固定IPアドレス、社内ネットワーク、他の仮想アダプターに影響する可能性があるため、すぐに実行しないでください。復旧後は、通常終了とスリープからの復帰をそれぞれテストします。ブラウザーとターミナルの切り分けはシステムプロキシが効かない場合の対処をご覧ください。アプリごとの違いをサーバーの問題と誤解しないようにしましょう。

クライアントがクラッシュする：画面、コア、システム環境を切り分ける

ダブルクリックしてもウィンドウが表示されない、ウィンドウがすぐに閉じる、接続時にコアが終了する、といった症状は分けて対処します。タスクマネージャーまたはシステムモニターで、すでにプロセスが起動してタスクトレイに常駐していないか確認してください。二重起動によるポート競合を避けられます。ウィンドウが残っていてログにサービスの終了が記録されている場合、画面のクラッシュではない可能性があります。ウィンドウ自体が消える場合は、アプリのログとシステムイベントを確認してください。起動時、更新時、インポート時、TUNの有効化後のどの段階で発生したかを記録すると、再起動を繰り返すより原因を絞り込めます。

インストール形式と実行ディレクトリを確認する

クライアントのダウンロードページから、OSとCPUアーキテクチャに合ったパッケージを選択してください。Windowsのデスクトップ版と従来のWPF版は異なるUI技術を使っているため、一方の実行環境の要件をもう一方にそのまま当てはめることはできません。macOSではApple SiliconとIntel、Linuxではディストリビューションのパッケージ形式とCPUアーキテクチャを確認します。アーキテクチャが合わない場合、クライアントに明確なエラーが表示されず、実行できないことがあります。インストール方法を回避するために、ファイルの拡張子を変更しないでください。

アーカイブ版を使う場合は、完全に展開してから決まったフォルダーで実行してください。圧縮ファイルのプレビュー画面から起動したり、付属リソースを残して実行ファイルだけコピーしたりしないでください。インストーラー版は、OSの方法に従って修復または再インストールします。ユーザーデータの保存先に書き込めるか、ディスク容量が十分か、クラウド同期によって設定ファイルがロックされていないか確認してください。頻繁に権限昇格が必要な一時フォルダーへ配置し、管理者として常時実行してフォルダーの問題を隠さないでください。

セキュリティソフトにブロックされた場合は、記録された対象ファイルと理由を確認し、入手元とインストール手順を確認してから、組織や端末の管理方針に沿って対処してください。最初から保護機能を全体的に無効にしたり、ディスク全体を除外対象にしたりしないでください。実行コンポーネントが不足しているという警告が出た場合は、使用するクライアントのビルド要件に従います。出所不明の単体DLLをダウンロードして補わないでください。リソース不足、アクセス拒否、アーキテクチャの不一致はそれぞれ別の問題であり、追加コンポーネントのインストールで解決するとは限りません。

バックアップを取って、初期設定と比較する

設定のインポートや更新後にクラッシュするようになった場合は、まずプロセスを正常に終了し、現在のユーザーデータをバックアップしてから、クライアントがサポートする方法で独立したテスト環境を作成してください。データの保存場所が分からないまま、ファイルをまとめて削除しないでください。テスト環境では自動起動、TUN、自動更新を有効にせず、画面の起動と必要最小限の設定だけを確認します。初期状態なら正常に動く場合は、グループ、ルール、その他の設定を少しずつ戻します。同じようにクラッシュする場合は、サーバーの設定を削除し続けず、システム環境とインストールリソースを優先して確認してください。

Windowsではイベントビューアーのアプリケーションログから、発生時刻をもとに障害モジュールを探せます。macOSではOSが生成したクラッシュレポートを確認してください。LinuxではターミナルからGUIプログラムを起動して標準エラーを確認し、現在のユーザーのシステムログも調べます。ログの場所はディストリビューションや起動方法によって異なり、どのシステムでも同じファイルに記録されるとは限りません。以下のコマンドは直近のユーザーログを表示しますが、個人用パスや他のプログラムの情報が含まれる場合があります。共有前に必要な箇所だけに絞ってください。

# Linux：現在のユーザーの直近10分間のログを確認
journalctl --user --since "10 minutes ago" --no-pager

ログにローカルポートの競合が明記されている場合は、まず使用中のプロセスを確認してください。ネットワーク関連のプロセスを無差別に終了しないでください。Windowsでは、待ち受けの確認で得たプロセスIDをGet-Process -Idに渡すと、プロセス名を確認できます。その後、該当するプログラムを通常の方法で終了してください。「ローカル混合待ち受けポート」を変更する必要がある場合は、新しい値を記録し、手動設定したブラウザー、ターミナル、他のアプリにも反映します。システムプロキシを再設定してください。環境変数の値はクライアントのポートを変更しても自動では更新されません。

Linuxでデスクトップのランチャーが応答せず、ターミナルからは正常に起動する場合は、ランチャーの実行パス、作業ディレクトリ、環境変数を確認してください。自動起動に失敗する場合、ネットワークの準備ができていない、権限の確認画面が表示されないといった可能性もあり、プログラム自体が実行できないとは限りません。導入時の注意点はLinuxへのデスクトップ版インストールと自動起動をご覧ください。修正後は、まず手動起動を確認し、次に自動起動を戻して、最後に再起動と通常終了をテストしてください。

コアを切り替えた後にだけ問題が起きる場合は、元の組み合わせに戻し、設定が対象コアに認識されるか確認してください。クラッシュを報告する際は、OSのアーキテクチャ、インストール形式、発生させた操作、機密情報を除いたエラー箇所を伝えます。根拠のないバージョン情報を付けたり、「更新後に動かない」とだけ書いたりしないでください。再現に必要な最短の操作手順は、長い画面録画より分析に役立ちます。修正を確認してから自動タスクを再開し、テスト中に更新やサブスクリプションの再読み込みで条件が変わらないようにしてください。

Androidのトラブル：VPN権限、バックグラウンド動作、アプリごとの経路を確認

Androidクライアントが接続済みと表示されているのにアプリの通信ができない場合は、VPNサービスの起動成功とリモート接続の成功を分けて確認します。v2rayNGの接続ボタンが実行中になっても、分かるのはローカルサービスが起動したことだけです。実際のリクエストとログも確認してください。V2Flyコアの代替としてv2flyNGを使う場合も、対応する設定とメニューを確認します。2つのクライアント間で設定を何度もインポートしただけで、同じサーバー設定だと判断しないでください。拡張フィールドやコアの機能によって実際の接続動作が変わることがあります。

まずシステムの許可とVPNの競合を確認する

初回接続時は、システムのVPN権限の確認を完了してください。許可を拒否した場合、端末管理ポリシーで制限されている場合、バックグラウンドで停止された場合は、サービスが起動しないことがあります。Androidでは通常、2つのVPNサービスが同時に通信を取り込むことはできません。仕事用VPN、ネットワークフィルター、他のプロキシアプリが使用中でないか確認します。先に通常の方法で停止してから、対象のクライアントを起動してください。接続ボタンを何度も押すと、ログ上のサービス状態が分かりにくくなります。

システムの「常時接続VPN」または「VPNを使用しない接続をブロック」が有効だと、クライアント停止後に直接接続も遮断されることがあります。この症状は、プロキシ設定の残留とは限りません。システムのVPN設定を確認し、元の状態を記録してください。変更が許可されている端末で必要に応じて設定を調整し、再テストします。管理対象端末では組織のポリシーに従い、管理コンポーネントを削除して調査しないでください。テスト後は必要な保護設定を元に戻し、通常の切断動作も確認してください。

クライアントのログを開き、既知の接続先に一度リクエストを送って、対応する記録が出るか確認します。リクエストの記録がない場合は、アプリの対象範囲と通信の入口を確認してください。名前解決エラーが出た場合はDNSの項目へ、ハンドシェイクエラーが出た場合はサーバーのタイムアウトの項目へ進みます。接続時間やアイコンの色だけで判断しないでください。モバイルデータとWi-Fiを比較する際は、同じサーバーを使い、先にWi-Fiのログイン画面で認証を完了します。ポータル認証が済んでいないと、プロキシ接続も通常のWeb閲覧も失敗することがあります。

画面ロック後の切断とアプリごとの経路を確認する

接続後すぐは使えるのに、しばらく画面をロックすると切断される場合は、バッテリー最適化とバックグラウンド制限を優先して確認します。メーカーによってメニュー名は異なるため、別のブランド向けの手順をそのまま使わず、アプリ情報からバッテリー使用、バックグラウンド動作、自動起動の権限を確認してください。まず対象クライアントに必要な設定だけ変更し、通知が表示される状態で画面ロックと復帰をテストします。すべてのアプリの制限を解除しないでください。電力消費が増えるうえ、サーバーが原因だと証明できるわけでもありません。

一部のアプリだけ使えない場合は、アプリ別のルーティング設定が「選択したアプリのみプロキシを使用」と「選択したアプリを除外」のどちらの意味で動作するか確認します。モードによって、同じチェック操作が対象に含める場合と除外する場合があります。変更後はVPNを停止して再接続し、対象アプリも完全に終了してから再起動してください。既存の接続には以前の経路が使われることがあります。仕事用プロファイルのアプリが別の管理範囲に属していないかも確認します。個人用プロファイルでの設定がすべてのアプリに適用されるとは限りません。

スマートフォンでテザリングを有効にしても、接続した端末の通信がスマートフォンのVPNを自動的に通るとは限りません。テザリングの転送、スマートフォン自身のリクエスト、LANへのプロキシ待ち受けの公開は別々の経路です。スマートフォンのブラウザーが使えることだけで、共有も成功したと判断しないでください。スマートフォン自身の接続を調べる場合は、まずテザリングを無効にします。信頼できる端末へプロキシを提供する必要がある場合は、待ち受けアドレス、認証、ネットワークへのアクセス範囲を別途確認してください。信頼できないネットワークにプロキシを公開してテストしないでください。

サブスクリプション、ネットワーク切り替え、インストールの問題を分ける

v2rayNGの「サブスクリプショングループ設定」を開き、グループURLと有効状態を確認してから「サブスクリプションを更新」を実行します。利用可能な接続がない場合、更新リクエストを直接接続で送る必要があることがあります。メニューとログで経路を確認してください。ブラウザーでアクセスできるからといって、クライアントの通信経路も正常とは限りません。更新後はサーバーを選び直して接続します。サブスクリプションURLにはアクセス権限が含まれるため、共有クリップボードの履歴ツールに長期間保存したり、QRコード全体を他人に渡して調査を依頼したりしないでください。

Wi-Fiからモバイルデータに切り替えた後に接続が切れる場合は、いったん停止して再接続し、新しいネットワークでサービスを起動します。それで復旧する場合は、システムのバックグラウンド通信制限、古い名前解決状態の引き継ぎ、2つのネットワークでのリモートアドレスへの到達性を確認してください。最初からネットワーク設定全体をリセットしないでください。デュアルスタックネットワークやキャリアのアドレス変換によって接続条件が変わることがあります。通常のWebページが開けても、UDPを使うアプリの通信を完全に確認したことにはなりません。実際に使うアプリで比較してください。

最後に一通り確認します。接続後に目的のサイトを開き、画面をロックしてから復帰し、ネットワークを切り替えて再接続し、通常の方法で切断した後に直接接続も確認してください。すべての手順が正常に完了して初めて、モバイル利用時の動作を確認できたと言えます。問題が残る場合は、OSのバージョン、クライアント名、ネットワークの種類、画面ロックとの関連、機密情報を除いた最初のエラーをまとめ、よくある質問を確認してください。基本設定をやり直す場合はクイックスタートガイドに戻り、一時的なテスト設定を通常の設定として使い続けないでください。