V2Rayトラブル対処ガイド

キャッシュの影響を受けないテスト条件を作る

比較用に通常のウェブページと、純粋なIPアドレスへの接続テストを1つずつ用意し、長時間開いたままのページだけで判断しないでください。ブラウザーは古い接続を再利用したり、失敗後のDNS結果を保持したりします。ブラウザーのウィンドウをすべて閉じてから開き直すか、新しいプライベートウィンドウでテストします。一時的に他のプロキシツール、ネットワーク高速化ツール、通信フィルタリング機能を持つソフトを停止し、同時にシステムプロキシを変更するプログラムを1つだけにします。パソコンが有線、無線、仮想NICに同時接続している場合は、実際に使うインターフェースだけを残し、複数の出口間でデフォルトルートが変化しないようにします。

続いてクライアントのメイン画面を確認します。現在のノードが選択され、コアが実行中で、ログに設定解析エラーやポートバインドエラーが連続していないことを確認してください。v2rayNの「システムプロキシを設定」と「コアを起動」は別の操作です。コアが動作していてもシステムプロキシが有効でなければ、通常のブラウザーは自動的にプロキシへリクエストを送りません。TUNモードでは、仮想NICが作成され、確認待ちの権限要求が表示されていないことも確認します。TUNの仕組みと詳しい有効化手順はTUNモードで全通信を引き受ける方法を参照してください。

ローカル待受ポートとアプリのプロキシ設定を確認する

v2rayNの一般的なローカル入口はSOCKSとHTTPの待受ポートです。実際の番号はクライアントの設定画面を確認してください。ガイドの例示ポートを現在の設定としてそのまま使わないでください。Windowsではターミナルから、クライアントのプロセスがポートを待ち受けているか確認できます。結果がなければ、コアが入口を正常に作成できていません。同じポートを別のプロセスが使用している場合は、まずプロセスを特定してから、競合するプログラムを終了するかローカルポートを変更します。詳しい手順はローカルポート競合の対処を参照してください。

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

ブラウザーや他のアプリを手動設定する場合、プロキシの種類を待受入口に合わせます。SOCKS5入口をHTTPプロキシとして入力したり、HTTP入口をSOCKS専用の設定欄に入力したりしないでください。アドレスは通常 127.0.0.1 を使用し、ノードサーバーのアドレスは入力しません。アプリに「プロキシDNS」や「SOCKS経由でドメインを解決する」設定があれば、比較テストのため一時的に有効にできます。ドメイン解決とアプリのリクエストが同じ入口を通るため、ローカルDNSの影響を切り分けやすくなります。

直接接続とプロキシ接続を比較して境界を切り分ける

システムプロキシを無効にして通常のネットワークをテストします。直接接続でもどのウェブページにもアクセスできない場合は、まず端末のネットワーク、ゲートウェイ、現在のネットワーク認証を修復します。V2Ray設定は最初に確認する対象ではありません。直接接続が正常で、プロキシを有効にするとすべて失敗し、ローカルポートが実際に待ち受けている場合は、クライアントログでリクエストがどのアウトバウンドへ送られているかを確認します。接続拒否は通常、リモートアドレスには到達できるものの、そのポートでサービスが待ち受けていない状態です。接続タイムアウトは、ネットワーク経路、アドレスの誤り、リモートノードへの到達不能が疑われます。ハンドシェイク失敗では、プロトコル、トランスポート、セキュリティ層、ホスト名、パスを確認します。

一部のウェブサイトだけ開けない場合は、まず短時間だけルーティングモードを切り替えて比較します。グローバルモードでは正常でルールモードで失敗するなら、問題は通常ルールの適用結果にあり、ノード自体ではありません。ドメインルールが早い段階で直接接続やブロック用アウトバウンドに振り分けられていないか、上から下へマッチする際の優先関係を確認します。ページは開くのに画像、ログイン、認証コードだけ失敗する場合は、ページが参照する別ドメインに異なるルールが適用されていないか確認します。対処後は元の振り分け設定に戻し、ルールの誤りを隠すためにグローバルモードへ長期依存しないでください。

最後にシステム時刻を確認します。VLESS、VMess、TLSなどの経路は、時刻の大きなずれの影響を受けることがあります。OSの自動時刻合わせを有効にし、タイムゾーンが正しいことを確認します。時刻を合わせたらコアを再起動し、新しい接続で再度ハンドシェイクさせます。同じノードが別の端末では使えるのに現在の端末で失敗する場合は、両端の設定項目、システムプロキシの状態、セキュリティソフトのポリシーを優先的に比較します。すべての端末で同時に失敗する場合は、ノード側または現在のネットワーク経路の問題である可能性が高くなります。

テスト方式と実際のアクセスを区別する

TCPテストが確認するのは、対象アドレスとポートで基本接続を確立できるかどうかだけです。VLESS、VMessなどのプロトコルパラメータが正しいかは確認できません。実際の遅延テストはノード経由で指定URLへアクセスし、ローカル入口、リモートハンドシェイク、アウトバウンドリクエスト、接続先の応答まで含むため実利用に近い一方、テストURLの到達性、DNS失敗、ルーティングルールの影響も受けやすくなります。「TCPは使えるが実測テストがタイムアウト」する場合は、プロトコル認証、TLS、トランスポート経路、テストURLを確認します。「TCPが直接タイムアウト」する場合は、サーバーアドレス、ポート、現在のネットワークからリモートへの到達性を優先して確認します。

すべてのノードを高頻度で連続テストしないでください。大量の接続を同時に作る一括テストは、ローカルネットワーク機器の接続数制限にかかったり、ログを同じエラーで上書きしたりすることがあります。設定が明確なノードを1つ選び、数秒間隔でテストし、各テスト後に該当時間帯のログを読みます。ノード名は識別用にすぎず、接続を決めるのはアドレス、ポート、ユーザー識別子、トランスポート方式、セキュリティ層、追加フィールドです。

ノード名ではなく、各フィールドを比較する

設定を手動で追加する場合は、プロトコル種別、リモートアドレス、ポート、ユーザー識別子、暗号化またはフロー制御の設定、トランスポート種別、パス、Host、サーバー名、フィンガープリント系の項目を1つずつ確認します。大文字・小文字、先頭のスラッシュ、空白も結果を変えることがあります。たとえばWebSocketのパスは通常、サーバー側と完全に一致させます。サーバー名はTLSハンドシェイクに使われるため、ノードアドレスがIPだからといって任意に空欄にしないでください。REALITY設定のサーバー名、短いID、公鍵は同じ組のパラメータです。別ノードの項目を混在させると、ハンドシェイク段階で失敗します。

サブスクリプションを取り込んだ後、特定の1ノードだけ失敗する場合は、そのノードを複製し、サブスクリプション本文と各フィールドを比較します。ただし、元のノードを何度も上書きしないでください。比較の基準を失うためです。同じサブスクリプションの全ノードがタイムアウトする場合は、会社のネットワークから家庭やモバイルのネットワークへ切り替えるなど、別のネットワークを試します。別ネットワークで使えるなら、クライアント設定はおそらく正しく、現在のネットワークポリシー、DNS結果、出口ルートに問題があります。すべてのネットワークで失敗する場合は、サブスクリプションを更新し、ノード情報が変更されていないか確認します。

アドレス解決とデュアルスタック経路を確認する

ノードアドレスがドメイン名の場合、クライアントは先にDNS解決を完了する必要があります。システムのターミナルでドメインを照会し、アドレスが返るか、どのアドレス族かを確認できます。IPv6だけが返るのに現在のネットワークに安定したIPv6出口がない場合、長時間待った後にタイムアウトすることがあります。複数のアドレスが返る場合は、1つが到達不能なため初回接続が遅くなる可能性もあります。比較のため一時的に信頼できるDNSへ切り替えるか、クライアントのドメイン解決方式を調整します。ただし、サービス側のアドレスは変わる可能性があるため、サブスクリプションのドメインに対応するIPを長期固定しないでください。

遅延値は表示されるのに実際のアクセスが失敗する場合、テスト経路とアプリの経路が一致していません。テストがカスタムルーティングを迂回していないか、アプリがシステムプロキシを通っているか、ブラウザーが独自のプロキシ拡張機能を有効にしていないかを確認します。最後に1つのノードで実際のウェブページへアクセスしてから、採用するか判断します。遅延順位は候補の絞り込みに使うだけで、安定性、ハンドシェイク成功率、接続先へのアクセス結果のほうが現在のネットワークに適したノードかどうかを示します。

まずサブスクリプションアドレスを確認する

サブスクリプションアドレスをコピーするときは、完全なプロトコルヘッダー、パス、クエリパラメータを含めます。チャットアプリや文書ではリンクの前半だけが認識され、パラメータが切り捨てられることがあります。アドレスの前後に空白、改行、日本語の句読点が混入する場合もあります。クライアントのサブスクリプション管理画面に貼り直し、識別しやすい短い名前を設定してください。単一ノードの共有リンクである vmess:// や vless:// をサブスクリプション欄に入れないでください。これらは単一ノードの取り込み用であり、サブスクリプション欄にはノード一覧を返すアドレスが必要です。

サブスクリプションサービスでは、有効なアクセスパラメータが必要な場合があります。リンクが再生成されていれば、古いアドレスは開けてもエラー説明や空の内容しか返さないことがあります。ブラウザーに「何らかの文字が表示された」だけで有効と判断しないでください。エラーページでも正常なHTTPステータスを返すことがあります。クライアントログには通常、リクエスト状態、レスポンスタイプ、解析失敗位置が記録されます。認証失敗、アクセス禁止、リソース不存在、リダイレクト過多、レスポンス内容が空といった表示を重点的に確認します。

サブスクリプションのリクエストが直接接続かプロキシ経由かを確認する

初回インストールでノード一覧が空の場合、サブスクリプション更新は通常、現在の直接接続ネットワークで行う必要があります。利用可能なノードがある場合、一部のクライアントではプロキシ経由で更新できます。直接接続では失敗しプロキシ経由では成功するなら、現在の直接接続経路からサブスクリプションサービスへ到達できません。逆の場合は、現在のプロキシノードからサブスクリプションアドレスへアクセスできない可能性があります。「更新時にプロキシを使用」と「自動更新」を同時に繰り返さないでください。ログに複数のリクエストが混在します。まず自動更新を無効にし、どちらか一方の経路を手動でテストします。

システムプロキシとクライアント内部のサブスクリプションリクエストは同じ概念ではありません。更新時にコアが直接リクエストするクライアントもあれば、アプリプロセスが行うクライアントもあるため、システムプロキシのスイッチだけで経路が決まるとは限りません。クライアントの設定項目とログを基準にしてください。会社、学校、ウェブ認証が必要なネットワークでは、まず通常のブラウザーで認証を完了します。未認証の状態ではリクエストがログインページへリダイレクトされ、クライアントがHTMLを受け取って形式エラーを報告することがあります。

「更新成功なのに一覧が変わらない」場合の対処

まず正しいサブスクリプショングループを表示しているか確認します。クライアントはサブスクリプション名ごとにグループを作ることがあり、更新後のノードが別グループに入り、現在の画面には古いグループが表示されたままになる場合があります。フィルター、検索語、「利用できないノードを非表示」などの設定を確認してください。次に、ノード数、名前、更新日時のいずれかに変化があるかを確認します。サーバーから返された内容が変わっていなければ、一覧がそのままなのは正常です。ログに解析されたノード数が0と表示される場合は、サブスクリプション形式がクライアントに対応しているか、返却内容が実際にはエラー説明ではないかを確認します。

v2rayNはWindows、macOS、Linuxのデスクトップ環境向け、v2rayNGとv2flyNGはAndroid向けです。サブスクリプションの拡張フィールドへの対応範囲はクライアントによって異なります。同じアドレスを一方では取り込めるのに、もう一方では空になる場合、すぐにすべてのノードを変更しないでください。未認識フィールドがクライアント非対応の拡張形式ではないか確認し、ダウンロードページに掲載されている現行クライアントへ更新します。更新後は新しいテスト用サブスクリプショングループを作り、古いデータベースの残存フィールドが結果に影響しないようにします。

更新後にノードが重複する場合、同じアドレスを複数回追加したか、「ノード追加」と「上書き更新」の方式が異なることが一般的です。サブスクリプション元を1つに絞り、重複する登録を削除してから再度更新します。ノード名だけで一括削除しないでください。異なるサーバーが同じ表示名を使うことがあるためです。端末を移行する場合は、新しい端末でサブスクリプションを再追加するのが優先です。古いデータベースと同じサブスクリプション元を同時に取り込むと、重複記録と古い設定が混在しやすくなります。

最後にシステム日時、ネットワークプロキシ、証明書の信頼設定を確認します。ブラウザーでもサブスクリプションアドレスを開けないなら、まずネットワーク層を対処します。ブラウザーでは開けるのにクライアントで失敗する場合は、クライアントログのリクエスト時刻、ステータス、解析エラーを収集し、該当段階を処理します。サブスクリプションアドレスはアクセス情報です。公開ページやスクリーンショットに貼り付けず、画像を共有する場合は完全なパスとクエリパラメータを隠してください。

再現可能な比較テストを作る

まずプロキシを無効にし、同じネットワーク・同じ端末で通常のウェブページと安定したファイルのダウンロードをテストし、大まかな結果を記録します。1回だけの最大値を追求する必要はありません。次にプロキシを有効にし、ノードを1つだけ選び、ブラウザー、テスト対象、時間帯を揃えます。速度テスト中はシステム更新、クラウド同期、動画再生、他の端末による大容量通信を停止します。無線信号が弱い、ルーターの負荷が高い、モバイルネットワークで基地局が頻繁に切り替わるといった場合は、どのノードでも変動します。まずローカル経路を切り分けてください。

「ウェブページの初回表示が遅い」と「継続ダウンロードが遅い」を区別します。初回だけ遅く後は正常なら、DNS、TLSハンドシェイク、接続確立に時間がかかっている可能性があります。ダウンロード開始は速いのに途中で低下するなら、ネットワーク混雑、リモート側の速度制限、パケットロスによる再送が考えられます。小さなページは正常で大きなファイルだけ遅い場合、基本接続性には問題がないため、経路品質と継続スループットを比較します。1つのウェブサイトだけで結論を出さないでください。接続先サービスの負荷や地域ごとの配信先も結果を変えます。

ノードとトランスポート経路を比較する

地理的な距離とネットワーク経路が妥当なノードを選んで比較します。遅延が低いほど操作性には有利ですが、高帯域幅を保証するわけではありません。遅延がやや高くてもパケットロスが少ないノードのほうが、継続転送では安定することがあります。切り替えるのは毎回ノードだけにし、他の設定は変えません。同じサブスクリプションの全ノードが遅く、直接接続が正常なら、ローカルのプロキシモード、DNS、セキュリティソフトを確認します。1つのノードだけ遅い場合は、まずノードを変更し、クライアント全体を変更する必要はありません。

トランスポート層のパラメータはサーバー側と一致させる必要があり、「高速化」のために任意で切り替えてはいけません。WebSocket、gRPC、TCPなどは接続特性が異なりますが、実際の結果はサーバー設定とネットワーク経路に左右されます。Host、パス、サーバー名の誤りは、すぐにエラーになるのではなく、再試行や断続的な失敗として現れることがあります。ログに接続の再構築、EOF、タイムアウト、ハンドシェイク失敗が連続しているなら、まず安定性を直してから速度を検討します。

ルーティング、同時接続数、端末側の処理負荷を確認する

ルールモードでは、1ページのメイン文書、画像、スクリプト、APIが異なるアウトバウンドに振り分けられることがあります。メインページはプロキシを通るのに静的リソースの直接接続が失敗すると、ページが長時間空白になります。クライアントのルーティングログを開くか、一時的にグローバルモードへ切り替えて比較します。グローバルモードで明らかに改善するなら、ページ関連ドメインに適用されたルールを1つずつ確認します。ルールは明確で具体的な条件から始め、広い範囲のフォールバックルールは後ろに置きます。上位の広範な直接接続ルールがリクエストを先に捕捉しないようにしてください。

TUNモードでは、より多くのプロセスの通信を処理します。有効化後に速度が低下した場合は、システム更新、LANアクセス、大容量ファイルの同期までプロキシに含めていないか確認します。LANと必要な直接接続のルールを適切に設定すると、不要な通信がリモート経路を通るのを減らせます。同時に、システムプロキシ、ブラウザーのプロキシ拡張機能、別の仮想NICによる通信の引き受けを重ねないでください。二重転送でループが発生し、CPU使用率の上昇、ウェブページの再試行、速度の急低下につながります。

クライアントのログレベルを長期間高く設定すると、特に短時間の接続が大量に発生する環境でディスク書き込みが増えることがあります。診断中は詳細度を上げても、確認後は通常レベルに戻し、肥大化した古いログを整理してください。セキュリティソフトが新しい接続ごとに詳細検査を行う場合も初回表示が遅くなります。防御全体を変更せず、クライアントプログラムとローカル待受接続が重複して検査されていないか確認します。

DNSの解決が遅いと、接続確立前にページが待たされます。本ページのDNS章で解決時間を確認し、DNSリクエストとプロキシ経路の設定も参照してください。TUN環境でFakeDNSを使う場合は、仮想アドレスのマッピングとドメイン復元の範囲も理解する必要があります。仕組みはFakeDNSの動作フローを参照してください。性能調整後は、少なくとも2つの対象と2つの時間帯で再テストし、一時的なネットワーク変動を固定設定の問題と誤認しないようにします。

問題がドメイン名だけで発生しているか判断する

ログに対象ドメインの解決失敗が表示され、既知の到達可能なIPへ直接アクセスすると応答がある場合、問題はDNSに集中しています。ドメインがアドレスへ解決されても接続がタイムアウトするなら、リモート経路も確認します。Windowsでは nslookup、macOSとLinuxでは dig または nslookup を使ってシステムの解決結果を確認できます。照会時はIPv4とIPv6の返却アドレスを分けて記録し、コマンドが実行できたかだけで判断しないでください。

nslookup example.com

dig example.com A
dig example.com AAAA

システムの照会が正常でも、クライアント内部のDNSが正常とは限りません。v2rayN、v2rayNG、v2flyNGはコアによる独立した名前解決を行い、ルーティングに応じて異なるサーバーを選べます。ブラウザーの直接接続は正常なのにプロキシ経由でドメインだけ失敗する場合は、クライアントログのDNSサーバー、照会タイプ、アウトバウンド表示を確認します。プロキシ経由でしかアクセスできないDNSへリクエストを送り、プロキシがまだ確立していなければ起動依存が生じます。逆に、プロキシ経由が必要な解決リクエストを直接接続へ強制しても、タイムアウトが続きます。

DNSとルーティングの実行順序を整理する

ルーティングルールはドメイン、IP、ポート、プロセスなどでマッチできます。ドメインルールでは、コアが対象ドメインの情報を保持している必要があります。IPルールでは、先に解決が必要になることがあります。オンデマンド解決を有効にすると、IP条件が必要なルールに対してだけアドレスを照会でき、不要な解決を減らせます。すべてのドメインをルーティング前に強制解決し、返されたIPで振り分けると、動的アドレスを使うサービスが誤ったルールに入ることがあります。対処中はまずシンプルなDNS設定を使い、基本アクセスが復旧してから、振り分け用サーバー、ドメインリスト、アドレス戦略を段階的に追加します。

以下は構造を理解するためのコアDNS例です。実際のアドレスとタグは現在のネットワークや設定に合わせて調整し、クライアントが自動生成した完全な設定をそのまま上書きしないでください。重要なのは、DNSサーバーにアウトバウンドを指定できること、そして照会方針をネットワークが対応するアドレス族に合わせることです。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "skipFallback": false
      },
      "localhost"
    ]
  }
}

キャッシュ、IPv6、FakeDNSの範囲を確認する

DNSを変更した後は、システムキャッシュを消去してブラウザー接続を再確立します。Windowsでは管理者ターミナルで ipconfig /flushdns を実行できます。コア独自のDNSを使っている場合は、システムキャッシュを消去してもコア内部の状態は消えないため、クライアントのコアも再起動します。ブラウザーが独自のホストキャッシュを保持することもあるため、完全終了してから開き直すほうが通常の更新より確実です。ネットワークがIPv4だけを安定してサポートし、解決結果がIPv6を優先する場合は、照会方針を一時的に調整して検証します。確認後に端末のIPv6ルートを修復するか、クライアントで現在到達可能なアドレス族を優先するかを判断します。

FakeDNSはTUNモードと組み合わせて使われることが多く、アプリには予約済みアドレスを割り当て、コアがマッピングから元のドメインを復元してルーティングします。ドメイン情報を保持できる一方、すべてのLANアプリや特殊プロトコルが仮想アドレスに適しているわけではありません。LAN機器の検出に失敗したり、一部アプリが固定IPへ異常接続したりする場合は、LANドメイン、プライベートアドレス帯、必要なシステムサービスをFakeDNSの対象外にします。FakeDNSのアドレスをリモートの実アドレスとしてルールに書いたり、手動接続に使ったりしないでください。

「アクセスはできるが、想定した解決経路と違う」場合は、アプリが発行したDNS、クライアントが使うDNS、ノード接続に必要なDNSを分けて観察します。ノードサーバーのドメイン解決はプロキシ経路の確立前に必要になるため、通常は直接アクセス可能な解決経路が必要です。一方、対象サイトの解決はルーティングに応じて別のアウトバウンドを通せます。この2種類の照会を同じ複雑なルール群に混在させると、循環依存が起こりやすくなります。修復後は、ドメイン解決結果、クライアントログのアウトバウンド表示、実際のウェブリクエストを同時に確認します。詳しい検証方法はDNSリークの検出と修復を参照してください。

システムプロキシの値とローカル待受を一致させる

システムプロキシのアドレスはローカル入口を指し、通常は 127.0.0.1 とクライアントの現在のHTTPポートを組み合わせます。クライアントがローカルポートを変更したのにOSが古いポートを保持していると、プロキシを有効にした直後に通信が切れます。v2rayNが異常終了した場合も古い設定が残ることがあるため、クライアントを開き直したら、まずシステムプロキシを解除し、現在の設定で再設定します。複数のクライアントに同じポートを競合させたり、システムプロキシを繰り返し書き換えさせたりしないでください。

Windowsではシステムネットワーク設定で手動プロキシを確認でき、コマンドでWinHTTP層の設定を読み取ることもできます。ただしWinHTTPと一般的なデスクトップアプリのプロキシ設定は完全には同じではありません。あるコマンドが「直接接続」と表示しただけで、ブラウザーがプロキシを使っていないとは判断できません。macOSでは現在のネットワークサービスごとにHTTPプロキシとHTTPSプロキシを設定します。無線ネットワークサービスを切り替えると、以前のサービスの設定が現在の接続に適用されないことがあります。Linuxのデスクトップ環境では、GUI設定、環境変数、アプリ独自設定が使われる場合があるため、それぞれ確認してください。

netsh winhttp show proxy

scutil --proxy

env | grep -i proxy

システムプロキシを無視するアプリを特定する

コマンドラインツールは通常、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数を読み取りますが、独自設定で指定する必要がある場合もあります。環境変数のプロキシ種別はローカル入口に合わせ、適用範囲も明確にします。現在のターミナルだけで設定した場合、新しく開いた別のターミナルには引き継がれません。グローバル環境へ書き込むと、クライアント終了後も無効なアドレスが残ることがあります。対処中は現在のセッションだけに一時設定し、テスト後に削除することを推奨します。

アプリによってはUDP、直接ソケット、独自DNSを使い、HTTPシステムプロキシに従いません。その場合はTUNモードで仮想NICからネットワーク層の通信を引き受ける方法があります。有効化前に、管理者権限、仮想NICドライバー、ルーティング設定が正常であることを確認し、プリンター、ルーター管理画面、ファイル共有がリモートへ送られないようLANアドレスを除外します。TUNは誤ったノードを修復する代替手段ではありません。ノードのハンドシェイク自体が失敗していると、引き受ける範囲を広げるだけで多くのアプリが同時に失敗します。

プロキシの残留、ループ、LANバイパスを処理する

プロキシループは、ブラウザー拡張機能がシステムプロキシを指し、システムプロキシが別ツールへ転送する場合や、クライアント自身の更新リクエストが誤って自分の待受ポートへ戻る場合に起こります。CPU使用率の上昇、同じ対象への高速な繰り返し、結果が出ないままウェブページが読み込み中になるといった症状が現れます。ブラウザーのプロキシ拡張機能と他のネットワークツールを終了し、クライアントが設定したシステムプロキシだけを残します。復旧を確認してから、アプリ単位のルールが必要か判断してください。

システムプロキシのバイパス一覧には、ローカル端末と必要なLANアドレスを含めます。localhost、127.0.0.1、プライベートネットワーク機器へアクセスするときは、通常リモート経路へ回しません。一方、あいまいなワイルドカードで大量のドメインを広く除外すると、本来プロキシが必要なリクエストまで直接接続になります。各バイパスルールの対象を明確にし、変更後はLANアドレスと外部対象を1つずつ使って確認します。

クライアントが正常終了すると通常はシステムプロキシを元に戻しますが、強制終了、プロセスのクラッシュ、権限不足では完了しないことがあります。クライアントが動いていないのに全体的にインターネットへ接続できない場合は、まずOSで手動プロキシを無効にし、ブラウザーを再起動します。頻繁に起きるなら、クライアントに設定を書き込む権限があるか、セキュリティソフトに阻止されていないか、別のプログラムが定期的にプロキシを書き換えていないか確認します。ポート変更後にシステムプロキシを同期する詳しい操作はローカル待受ポートの競合対処を参照してください。

最終確認では、3種類のアプリを対象にします。システムプロキシを読み取るブラウザー、独自のプロキシ設定で接続するツール、TUNでなければ通信を引き受けられないアプリです。3種類の結果から、システムプロキシとTUNの範囲を明確にできます。1つのアプリを動かすためにすべての引き受け方式を同時に有効にしないでください。対象通信をカバーできる最小構成を選ぶと、その後のルーティングと障害特定が容易になります。

起動ログで終了段階を特定する

クライアントのウィンドウが開くなら、まずログディレクトリとメイン画面の最後の数行を確認します。設定解析エラーは通常、コア起動直後に発生し、フィールド、JSONの位置、非対応の設定項目を示します。ポート競合はバインド失敗として表示されます。数秒動作してから終了する場合は、TUN権限、仮想NIC、ネットワーク環境、実際のリクエストのいずれかが関係している可能性があります。ログが保存される前に何度も再起動せず、発生時刻付近のエラーテキストを先にコピーし、ノードアドレス、ユーザー識別子、サブスクリプションパラメータを隠してください。

画面がまったく開かない場合は、システムのタスクマネージャーまたはアクティビティモニタで残存プロセスを確認します。残存プロセスがデータベースやポートを保持していると、2回目の起動に失敗することがあります。残存プロセスを正常に終了してから再度起動し、複数の起動入口を連続してクリックしないでください。デスクトップではまずv2rayNを使用し、クライアントダウンロードページからOSとCPUアーキテクチャに合うパッケージを選びます。macOSの初回起動でシステムの許可やネットワーク権限が必要な場合は、macOSのインストールと権限設定を参照してください。

ユーザー設定とプログラムファイルを分離する

アップグレード後の突然終了は、プログラム自体の破損とは限らず、古いデータベース、テーマ設定、カスタム設定が新しい構造と互換性を失った可能性もあります。まずサブスクリプションアドレスと必要な設定をバックアップし、クライアントを終了します。元のデータディレクトリを直接削除せず、名前を変更して、空の設定で起動させます。空の設定で正常に動くなら、問題はユーザーデータにあります。サブスクリプションと設定を少しずつ戻し、古いディレクトリ全体を一度に上書きしないでください。

カスタムJSON設定は、コアの起動失敗を招きやすい部分です。まずクライアントが生成した通常のノード設定へ切り替え、コアが動作することを確認してから、カスタムファイルを確認します。JSONでは末尾のカンマは許可されません。文字列内のバックスラッシュと二重引用符は正しく処理し、フィールドの型もコアの要件に合わせる必要があります。以下のコマンドでJSONの基本構文を確認できます。ファイル名は実際のパスに置き換えてください。

python -m json.tool config.json

構文が正しくても、設定の意味まで正しいとは限りません。存在しないアウトバウンドタグ、誤ったルーティングルール参照、重複する待受ポート、現在のコアが対応していないフィールドは、読み込み段階で失敗の原因になります。ログに示された最初のエラーから修正してください。後続のエラーは、最初の失敗による連鎖結果にすぎない場合があります。

権限、セキュリティポリシー、システムリソースを確認する

TUNモードでは仮想NICの作成とルートの変更が必要なため、通常権限では有効化直後に終了することがあります。まずTUNを無効にし、通常のシステムプロキシモードが動作するか確認します。通常モードは正常でTUNだけクラッシュするなら、管理者権限、仮想NICの状態、他のVPN系ネットワークドライバーを確認します。複数の仮想NICが同時にデフォルトルートを変更すると、コア起動後にネットワークを失い、再起動を繰り返すこともあります。

セキュリティソフトがコアの子プロセスを隔離したり、ローカルポートの待受を阻止したり、設定ディレクトリの読み取りを制限したりすることがあります。システムのセキュリティ記録でクライアントの起動時刻に対応するイベントを確認し、明確な記録に基づいて対処します。防御機能をむやみにすべて無効にしないでください。プログラムディレクトリに書き込み権限がないと、ログやデータベースの作成にも失敗します。現在のユーザーが読み書きできる場所にインストールし、圧縮ファイルのプレビュー画面から直接実行しないでください。

しばらく動作した後にクラッシュする場合は、メモリ、ディスク空き容量、ログのサイズも確認します。接続数が多い環境で詳細ログを出し続けると急速に肥大化し、空き容量不足によって設定の書き込みや更新に影響します。古いログを整理してレベルを通常に戻し、もう一度再現させます。特定のノードだけでクラッシュするなら、そのノードを複製してフィールドを比較します。空の設定でもクラッシュが続く場合は、OS、クライアント名、クラッシュ時刻、システムイベントを記録し、現在のアーキテクチャに合うクライアントを再インストールします。対処中に大量のサブスクリプションを同時に取り込まず、設定の問題と実行環境の問題を混在させないでください。

接続ボタンが効かない、VPN権限の取得に失敗する

初回の接続開始時、システムにVPN接続の確認画面が表示されます。確認していない場合、別のVPNサービスがすでに動作している場合、仕事用プロファイルのポリシーで制限されている場合は、クライアントがインターフェースを作成できません。まず他のVPN系アプリを切断し、クライアントに戻って接続を再開し、システムの確認を完了します。ステータスバーにVPNマークが表示されても、インターフェースが作成されたことを示すだけです。ノードのハンドシェイクが成功したかは、クライアントログで確認してください。接続直後に停止する場合は、ノード設定、現在のネットワーク、アプリのバックグラウンド権限を確認し、起動ボタンを繰り返し押すだけにしないでください。

クライアントを切り替えるときは、まず元のクライアントでサービスを停止してから、新しいクライアントを開きます。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。Android上で異なる選択肢になりますが、システムVPNを同時に確立しないでください。サブスクリプションは別々に取り込んでテストし、ノードパラメータは一致させます。クライアントの違いとノードの違いを混同しないためです。再インストールが必要な場合は、Androidクライアントの入口からv2rayNGまたはv2flyNGを選び、端末のアーキテクチャに合うパッケージを優先してください。

バックグラウンド切断とネットワーク切り替えに対処する

システムのバッテリー最適化により、画面消灯後にクライアントのバックグラウンド動作が制限されることがあります。使用中のクライアントをバックグラウンド実行を許可するアプリ一覧に追加し、自動起動やバックグラウンド活動を許可します。端末によって設定名は、バッテリー最適化、バックグラウンド使用、電池管理、スリープ中のアプリなど異なります。実際に使うクライアントだけを調整し、すべてのネットワークアプリに制限解除を与える必要はありません。設定後に数分間画面をロックし、解除してウェブページとログを確認し、サービスが動き続けているか確認します。

無線ネットワークからモバイルネットワークへ切り替えると、ローカルIP、DNS、デフォルトルートが変わります。多くの場合、クライアントは接続を自動的に再構築しますが、古い接続が短時間残ることがあります。切り替え後にアクセスできない場合は、サービスを一度停止して再起動し、VPNインターフェースを現在のネットワークへ再バインドします。2つのネットワークを頻繁に切り替えるとテスト結果が混乱するため、対処中は一方のネットワークに固定して確認し、その後もう一方をテストします。特定のネットワークだけ失敗する場合は、ノードのタイムアウトとDNSの章に戻り、そのネットワークの到達性を判断します。

アプリ振り分けとプライベートDNSを確認する

Androidのアプリ振り分けでは、VPNに入れるアプリを選択できます。ホワイトリスト方式では、新しくインストールしたアプリが初期状態でクライアントを通らないことがあります。除外方式では、除外したブラウザーもプロキシを通りません。「1つのアプリだけ使えない」場合は、まずそのアプリが選択されているか確認し、一時的にアプリ振り分けを無効にして比較します。すべてのアプリが正常になったら、振り分けを戻してルールへ1つずつ追加します。システムコンポーネント、ダウンロードマネージャー、ブラウザーが呼び出す外部サービスは別プロセスの場合があるため、メインアプリだけを選択しても通信経路全体をカバーできないことがあります。

システムのプライベートDNSは、VPNの外側または内側に別の解決経路を作ることがあります。具体的な動作はシステムとクライアントの設定によって異なります。ドメインは失敗するのにIPへは到達できる場合、まずプライベートDNSを自動に戻して比較し、その後クライアントDNSを確認します。ブラウザー独自のセキュアDNSがコアのルールを迂回することもあるため、対処中は標準設定を維持します。クライアントDNSが正常だと確認してから、システム全体のカスタム解決を戻すか判断します。

LANへアクセスできない場合は、LANバイパスが有効か、アプリがプライベートアドレスへアクセスしようとしているか確認します。VPN有効時にVPNを通らない接続を標準で禁止する端末もあり、プリンター、ルーター管理画面、LANサービスへ到達できなくなることがあります。クライアントでプライベートアドレスを明示的に直接接続へ設定し、VPN以外の通信をすべて遮断する厳格な設定がシステムで有効になっていないことを確認します。変更後はLANアドレスと外部ウェブページを個別にテストし、直接接続の範囲を広げすぎないようにします。

QRコードを取り込んだ後に接続できない場合は、プロトコル、アドレス、ポート、ユーザー識別子、セキュリティ層、サーバー名、トランスポート経路を1つずつ比較します。カメラ認識では長い内容が切り捨てられたり、クリップボードに改行が残ったりすることがあります。複数ノードの更新には、手動スキャンよりサブスクリプション取り込みのほうが便利です。ただし、サブスクリプション更新に失敗した場合は、本ページのサブスクリプション章に沿って確認します。最後に安定して再現できるノードを1つ残し、無線ネットワークとモバイルネットワークで個別にテストします。片方のネットワークだけ失敗するなら経路の問題です。両方で失敗し、デスクトップでは同じ設定が使えるなら、AndroidクライアントのDNS、アプリ振り分け、トランスポート項目を重点的に比較します。

アプリがバックグラウンドで安定して動作しているのに、メッセージや同期が遅れる場合は、すべてのアプリをすぐにプロキシへ追加しないでください。まず対象アプリが省電力ポリシーで制限されていないか、除外されたシステムコンポーネントに依存していないか、ドメインが想定したルールにマッチしているか確認します。Androidの対処では、システムVPN、クライアントコア、アプリ権限を分けて検証することが重要です。VPNインターフェースが存在し、コアの接続が成功し、対象アプリがインターフェースに入って初めて、完全な通信経路が成立します。