V2Ray トラブル対処マニュアル

比較できる基準を作る

まずクライアントを終了するかシステムプロキシを無効にし、普段安定して開けるサイトをブラウザーで表示します。同時に、ローカルネットワークから正常にアドレスを取得できることも確認してください。直接接続も失敗する場合は、ルーター、無線LAN、LANケーブル、認証ページ、または端末のネットワークスタックを先に確認します。プロキシクライアントで基礎ネットワークの断絶を直すことはできません。直接接続が正常なら、v2rayN、v2rayNG、v2flyNGを再起動し、元のノードとルーティングモードを変えずに同じサイトへアクセスします。この比較で「ネットワーク自体の問題」と「プロキシ経路の問題」を切り分けられます。

デスクトップでは、「コアが動作している」ことと「システムの通信がコアに取り込まれている」ことも区別します。v2rayNの実行ログには、ローカルインバウンドの待受に成功した記録が出るはずです。ポートを別のプロセスが使用していると、コアが起動直後に終了しても、トレイアイコンだけ残ることがあります。設定でローカルHTTPポートとSOCKSポートを確認し、ブラウザーまたはシステムプロキシが同じポートを使っているか確認してください。ブラウザーのプロキシ拡張機能を手動設定している場合は、古いポートを向いていないかも確認します。

1. STEP 01プロキシを無効にして直接接続を確認
2. STEP 02コアとポートの待受を確認
3. STEP 03システムプロキシのアドレスを確認
4. STEP 04ノードを変更して比較

ローカルポートが実際に待ち受けているか確認

WindowsではPowerShellで対象ポートを確認できます。以下は一般的なローカルポートの例です。実際の確認では、クライアントの設定画面に表示される値へ置き換えてください。何も出力されなければ、ポートは作成されていません。プロセス情報が表示されても、現在のクライアント以外のプロセスならポート競合が起きています。「ポート番号が正しそう」というだけで判断せず、待受プロセスを有効な証拠にしてください。

WINDOWS / LOCAL LISTENER

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10809 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id (Get-NetTCPConnection -LocalPort 10809 -State Listen).OwningProcess

macOSとLinuxでは、システム標準のネットワークツールで待受状態を確認できます。結果が 127.0.0.1 のみで待ち受けている場合、アクセスできるのは同じ端末上のプログラムだけです。デスクトップ単体で使う場合は正常な範囲です。LAN内の端末から接続する明確な理由がある場合に限り、LAN接続を許可してください。単体の障害を調べる段階で待受範囲を広げると変数が増えるだけで、システムプロキシの向き先の誤りも解決しません。

MACOS / LINUX / LOCAL LISTENER

ss -lntp | grep -E '10808|10809'
lsof -nP -iTCP:10809 -sTCP:LISTEN

症状からプロキシ・ルーティング・リモート障害を切り分ける

ルーティングモードは、この症状で最も見落とされやすい変数です。ルールモードでは、ドメイン、宛先アドレス、ルールセットに応じて、直接接続かプロキシのアウトバウンドかが選択されます。グローバルモードでは、より多くの通信がプロキシのアウトバウンドへ送られます。診断のために短時間だけグローバルモードへ切り替えてください。グローバルモードで復旧するなら、ノード自体は使える可能性が高く、問題はルールの一致またはDNSの応答結果にあります。グローバルモードでも失敗する場合は、ノードとトランスポート層を確認します。診断後は元のモードに戻し、該当するルールを修正してください。診断用モードを恒久的な解決策にしないでください。

最後に、既知の正常な別ノードで比較します。変更するのはノードだけにし、ルーティング、DNS、システムプロキシは変えません。別ノードで復旧するなら、原因は元のノードまたはそのトランスポートパラメータです。すべてのノードで失敗するなら、ローカルの待受、システムプロキシ、クライアントコアに戻って確認します。1つの変数だけを置き換えることで、ノード障害をソフトウェア障害と誤認したり、意味なくクライアントを再インストールしたりするのを防げます。

サーバーアドレスとポートを先に確認

現在のノードの編集画面を開き、アドレス、ポート、ユーザーID、暗号化オプション、トランスポート方式、TLSの有効化、サーバー名、パス、Hostを順に確認します。サブスクリプションから追加したノードは、通常これらの項目を手動で書き換える必要はありません。問題の切り分けで項目を変更したことがある場合は、まずサブスクリプションの元データと照合してください。アドレス欄にはホスト名またはアドレスだけを入力し、プロトコルの接頭辞、パス、ポートまで一緒に貼り付けないでください。ポートは有効な数値で、サーバー側の待受ポートと一致している必要があります。

ノードがドメイン名を使う場合は、まず端末でそのドメインを解決できるか確認します。名前解決に成功しても、対応するポートへ到達できるとは限りません。Windowsでは Test-NetConnection でTCP接続を確認でき、macOSとLinuxでは nc を使用できます。コマンド内のドメイン名とポートは、実際のノードの値に置き換えてください。TCP確認に失敗する場合、クライアントのプロトコルパラメータを調整しても意味がありません。先にネットワーク経路、アドレス、ポートを確認します。

TCP / REACHABILITY

Test-NetConnection server.example.net -Port 443

nc -vz server.example.net 443

テスト結果は状況と合わせて解釈します。ドメインを解決できるのにポートだけ失敗する場合、リモート側が待ち受けていない、アドレスが変わった、中間ネットワークで遮断されている、端末のセキュリティソフトが妨げている可能性があります。ポート接続に成功してもクライアントがタイムアウトするなら、TLS、WebSocket、gRPC、プロトコル認証の層に近い問題です。ブラウザーでノードのドメインを開けるかどうかでサービスの正常性を判断しないでください。ブラウザーはHTTPリクエストを送りますが、ノードはまったく異なるパスやハンドシェイク形式を使うことがあります。

TLSとトランスポートパラメータがセットで一致しているか確認

TLSを使う場合、サーバー名は通常、証明書とハンドシェイクの照合に使われます。ノードアドレスがIPアドレスでも、サーバー名には設定提供元が指定したドメイン名を入力する必要があります。両者を機械的に同じ値へ変更すると、ハンドシェイクに失敗することがあります。ログに証明書名の不一致、ハンドシェイクの早期終了、プロトコルバージョンのネゴシエーション失敗が出た場合は、検証を無効にして回避するのではなく、サブスクリプションのサーバー名とセキュリティ設定へ戻します。時刻が大きくずれていると証明書の有効期間判定にも影響するため、まずシステム時刻とタイムゾーンを自動同期へ戻してください。

WebSocketノードでは、パスとHostを同時に確認します。パスは通常スラッシュで始まり、大文字・小文字や末尾の文字もサーバー側の照合に使われることがあります。gRPCノードではサービス名を確認します。VMessやVLESSなどのプロトコル項目は、トランスポート層から切り離して判断できません。プロトコル認証が正しくても、トランスポート経路が間違っていれば認証前に失敗します。サブスクリプション更新後に古いノードの一部だけがタイムアウトする場合は、サーバー側のパラメータが変更され、クライアントに古い複製が残っている可能性があります。古い複製を削除し、サブスクリプションから再生成してください。

比較対象を使って障害範囲を絞る

3種類の比較を用意します。同じクライアントの別ノード、同じノードを別のネットワークで接続した場合、同じサブスクリプションを別の端末で使った場合です。別ノードが使えるなら、クライアントの基本経路は正常です。同じノードが別ネットワークで使えるなら、元のネットワーク経路に違いがあります。同じノードがすべての端末で失敗するなら、リモートノードの状態またはサブスクリプションパラメータの問題が考えられます。毎回1つの条件だけを変えて結果を記録してください。3回の比較は、何度も再起動するより多くの情報を与えます。

遅延テストも正しく解釈する必要があります。クライアントに表示される接続遅延は、特定のプローブリクエストが完了するまでの時間であり、すべての通信の速度と同じではありません。特定のプローブ方式に応答しないノードでも、実際の接続は使えることがあります。逆に、プローブは速くても、その後のTLSやアプリケーションリクエストが失敗する場合もあります。実際のWebページへのリクエストと実行ログを同時に確認してください。すべてのノードが同時にタイムアウトする場合は、各ノードを個別に編集するのではなく、システム時刻、DNS、システムのセキュリティポリシー、クライアントコアの読み込み状態を確認します。

ノードをサブスクリプションで管理している場合、最終的な修復はサブスクリプション元に戻って行います。サブスクリプションが有効か確認し、更新後にノードパラメータが変わっていないか確認してから、手動変更で作られた重複項目を削除します。ノードパラメータに問題がないのにリモートへ継続して到達できない場合、ローカルクライアントに追加で直せる設定はありません。ログに段階情報を残し、利用可能なノードへ切り替えてください。これにより「リモート側が利用できない問題」と「ローカル設定の誤り」を明確に分けられます。

リンク自体と更新経路を確認

まずサブスクリプション管理画面から現在のリンクをコピーし、先頭や末尾に空白、改行、日本語の句読点、重複文字が混入していないか確認します。チャットツールで転送した長いリンクは途中で改行されることがあり、コピー時に表示部分だけ取得される場合もあります。手動でデコードしてから貼り付けないでください。クライアントに必要なのは完全な元のリンクです。提供元がサブスクリプションアドレスを更新した場合は、古い項目を削除してから再追加し、似た名前のサブスクリプションが2つ残って古いリンクを更新する状態を避けます。

次に、「サブスクリプション更新にプロキシを使う」場合と「直接更新」を区別します。現在のネットワークからサブスクリプションアドレスへ直接アクセスできないのに、クライアントが直接更新に設定されていると、名前解決または接続の段階で失敗します。逆に、すでに無効なノードを経由するよう強制しても、サブスクリプションを取得できません。v2rayNではサブスクリプション更新に関するプロキシ設定を確認し、Androidクライアントでは更新時のVPN接続状態とアプリごとのルールを確認します。更新経路の切り替えは診断として行い、利用可能な経路を確認したら設定を固定してください。

1. STEP 01完全なリンクを確認
2. STEP 02リクエストが成功したか判断
3. STEP 03レスポンス内容を確認
4. STEP 04解析の互換性を確認

レスポンス結果から問題の段階を判断

ログにHTTPステータスが出る場合は、まず種類で判断します。リダイレクトは必ずしもエラーではありませんが、クライアントが最終アドレスまで追従できる必要があります。権限関連のレスポンスは、リンクの認証情報、有効期限、アクセス条件が変わったことを示す場合があります。サーバーエラーは、サブスクリプション側が一時的に正常な内容を生成できていないことを示します。成功ステータスでも解析できるとは限りません。ログインページ、案内ページ、ゲートウェイのエラーページも成功ステータスで返ることがあり、その後クライアントが形式エラーやノード数ゼロを報告します。

サブスクリプションリンクを公開の検査ページへ貼り付けないでください。相談用のスクリーンショットにも完全なリンクを表示しないでください。リンクにはアクセス用の認証情報が含まれることがあるため、確認時はドメイン、レスポンスステータス、エラーの種類だけを記録します。リンクを比較する場合は、長さ、先頭、末尾の少数の文字だけを比べ、中間のパラメータは隠してください。クライアントログに完全なアドレスが出力される場合も、共有前にクエリパラメータを削除します。

解析失敗とノード一覧が空になる問題

リクエストは成功したのに解析に失敗する場合は、まずクライアントの種類を確認します。デスクトップではv2rayN、Androidではv2rayNGを推奨し、v2flyNGはV2Flyコアを使う選択肢です。古いクライアントは、サブスクリプションに追加された新しいプロトコル項目やトランスポートオプションを認識できないことがあります。その場合はダウンロードページから現在のインストールパッケージを取得し、サブスクリプションを再更新してください。古いクライアントで不明な項目を1つずつ削るのは避けてください。ノードを保存できても、実際のハンドシェイクは失敗する可能性があります。

ノード一覧が空になる原因として、サブスクリプショングループ、フィルター、重複排除設定も考えられます。まず名前フィルターを解除してすべてのグループを表示し、更新対象が現在のサブスクリプションになっているか確認します。備考で重複排除を設定していると、同名ノードが1つだけ残ることがあります。古いノードの自動削除を有効にしている場合、レスポンスが空だと元の一覧まで削除されることがあります。重要な設定は更新前にバックアップをエクスポートし、調査中は一覧構成を変える自動ルールを無効にして、レスポンスの問題とローカルフィルターが重ならないようにします。

同じサブスクリプションが一方の端末では更新でき、別の端末では失敗する場合は、クライアントのバージョン、更新時のプロキシ、DNS、システム時刻を優先して比較します。すべての端末で同じエラーになる場合は、リンクとレスポンス側を重点的に確認します。復旧後も「更新成功」の表示だけで判断せず、ノード数が妥当か、古いノードが想定どおり置き換わったかを確認し、ランダムに1つのノードを選んで実際に接続してください。リクエスト、解析、接続の3段階がすべて通って、初めてサブスクリプション経路が復旧したと判断できます。

固定した対象で比較する

直接接続で安定し、容量が比較的固定されたWebページまたはファイルを選び、プロキシ無効、現在のノード、別ノードの3状態でテストします。各テストの前に現在のダウンロードが終わるまで待ち、帯域幅を使う同期、更新、動画再生を停止して、同じネットワークを維持してください。複数の速度測定ページの平均を取るのは避けます。測定サーバーの位置や接続数が異なり、新しい変数が入るためです。目的は見栄えのよい数値ではなく、ボトルネックがノード、ネットワーク、特定の接続先のどれに伴って変わるかを確認することです。

最初の表示だけ遅く、表示後の転送は正常なら、DNS、TCP接続、TLSハンドシェイクを重点的に確認します。継続速度が低く遅延が正常なら、ノードの出口帯域、経路の混雑、トランスポート方式を確認します。速度が周期的に低下し、再送を伴うなら、無線LANの品質、パケットロス、経路の変動が関係していることが多いです。1つのサイトだけ遅い場合は、そのサイトからノードの出口までの経路、またはサイト側の制限が考えられます。これらを分けて見るほうが、クライアントの遅延だけを見るより有効です。

ローカル経路とプロトコルのオーバーヘッドを確認

まず同じ端末で直接接続をテストします。無線信号が弱い、周波数帯が混雑している、バックグラウンドのアップロードが上り帯域を使い切っている、といった状態はプロキシ接続を大きく遅くします。上り帯域が埋まると確認パケットや制御パケットをすぐに送れず、ダウンロード帯域に余裕があってもWebページが停止したように見えます。一時的にクラウド同期、システム更新、大容量アップロードを停止し、有線LANまたはアクセスポイントに近い場所で再テストしてください。直接接続がすでに不安定なら、プロトコルを切り替えても安定した結論は得られません。

トランスポートのカプセル化には、ヘッダーやハンドシェイクのコストが加わります。ただし、性能問題を特定のプロトコル名だけに帰すべきではありません。WebSocket、gRPC、TLSなどの組み合わせによる結果は、実際の経路とサーバー設定に左右されます。サブスクリプションで提供されるノードパラメータは通常セットで設計されているため、速度だけを求めて安全層を無効にしたり、トランスポート方式を変更したりしないでください。誤った組み合わせは接続できることがあっても、継続転送中に再試行を発生させます。正しい方法は、設定が完全な別ノードと比較することであり、既存ノードを分解して変更することではありません。

ルーティング・同時接続数・測定誤差

ルールモードでは、ドメインごとに異なるアウトバウンドを通ることがあります。速度測定ページのメインページ、測定API、静的リソースも複数のドメインに分かれている場合があり、最終的には混在した経路を測ることになります。診断時は一時的にグローバルモードを使い、関連するすべてのリクエストが同じノードを通るか確認します。グローバルモードで明らかに改善するなら、ノードの性能異常と決めつけず、ルールの一致を確認してください。ログのアウトバウンドタグから、リクエストがプロキシ経由か直接接続かを確認できます。

同時接続数も結果を変えます。速度測定ツールには、多数の同時接続で帯域を使い切るものがありますが、通常のブラウジングは短い接続を多数使います。前者の数値が高くても、後者が快適とは限りません。逆に、単一接続の速度が低くても、総スループットまで低いとは限りません。Webページの遅さを調べるならDNSとハンドシェイク、ダウンロードの遅さなら1つの対象ファイル、動画のバッファリングならコンテンツ配信ノードの選択を確認します。症状に合った指標を使い、1つの数値ですべての体感を説明しないでください。

すべてのノードが特定のネットワーク上だけ遅く、ネットワークを変えると復旧するなら、ローカルの接続環境またはネットワーク経路の問題が考えられます。同じノードがすべての端末で遅く、他のノードは正常なら、まずノードを変更します。特定の接続先だけ遅いなら、ルーティングと接続先側までの経路を確認します。切り分け後は、一時的に停止したバックグラウンドサービス、ルーティングモード、テスト設定を元に戻してください。速度測定のために、日常用途に合わない設定を残さないようにします。

システムDNSと内蔵DNSを見分ける

通常のシステムプロキシモードでは、アプリがまずシステムDNSで宛先アドレスを取得し、そのアドレスをプロキシへ渡すことがあります。アプリによっては暗号化DNSを独自に有効にし、システム設定に従いません。仮想NICモードでは、より多くのDNSリクエストをクライアントが処理することがあります。3つの経路が併存すると、同じドメインでも異なる結果になります。調査前にブラウザー独自のDNS機能を一時的に無効にして、テスト経路をできるだけ1つにします。そのうえで、クライアントログに該当ドメインが出ているか確認してください。

システムの問い合わせツールで基準を作れます。Windowsでは Resolve-DnsName、macOSとLinuxでは nslookup または dig を使用できます。まずサーバーを指定せず、システムの既定の結果を確認し、クライアントログの宛先アドレスと比較します。システムでは解決できるのにクライアントが解決失敗を報告するなら、クライアント内蔵DNSの設定を確認します。両方で失敗するなら、現在のネットワークが提供する名前解決サービス、システムのネットワーク設定、ドメイン名の綴りを確認してください。

DNS / BASELINE

Resolve-DnsName example.com

nslookup example.com

dig example.com A
dig example.com AAAA

アドレスファミリーとルーティングの一致を理解する

ドメインはIPv4とIPv6のアドレスを同時に返すことがあります。現在のネットワークのIPv6経路が不完全だと、アプリがIPv6を優先して試行し、失敗してからフォールバックするため、初回アクセスが大幅に遅くなる場合があります。クエリ結果と接続ログで、実際にどのアドレスファミリーを使っているか確認し、いきなりシステム全体のIPv6を無効にしないでください。クライアントにアドレス戦略の設定がある場合は、ローカルネットワークの能力に合ったものを選びます。変更後はIPv4のみを返すドメインと、両方を返すドメインをそれぞれテストし、新しいアクセス差が生じていないか確認してください。

ルーティングルールは、ドメインまたは名前解決後のアドレスで一致させられます。適切なスニッフィングやドメイン保持機能が有効でない場合、アプリが宛先アドレスだけを渡すと、ドメインルールに一致しないことがあります。逆に、アドレスルールへ依存しすぎると、コンテンツ配信アドレスの変化に影響されます。診断時はログで一致したルールとアウトバウンドタグを確認します。一時的なグローバルモードでルールが原因か検証できますが、最終的な修正は明確なドメインルールまたはアドレスルールに戻してください。

V2RAY / DNS STRUCTURE EXAMPLE

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

この例は構造の関係を示すためのもので、クライアントが自動生成する完全な設定をそのまま上書きしないでください。servers の順序とドメイン範囲は問い合わせ先に影響し、localhost はシステムの名前解決経路を使うことを示します。queryStrategy は受け入れるアドレス種別を決めます。GUIクライアントは保存時に設定を再生成することがあるため、DNS設定はまず画面から変更してください。自動生成の仕組みを明確に理解している場合に限り、カスタム設定の断片を編集します。

キャッシュ・汚染された結果・検証の循環

DNSを変更しても古いアドレスが返る場合、システム、ブラウザー、クライアントのキャッシュが残っている可能性があります。Windowsでは ipconfig /flushdns でシステムキャッシュを削除できます。ブラウザーは完全に終了してから再起動し、クライアントはコアを再起動します。キャッシュ削除は設定変更後だけ行えば十分で、各手順で繰り返す必要はありません。削除後に一時的に復旧して再び異常になる場合は、キャッシュを根本原因と決めつけず、実際の問い合わせ先を確認してください。

WINDOWS / CLEAR SYSTEM DNS CACHE

ipconfig /flushdns

有効な修復サイクルには3つの確認が必要です。システムツールで妥当な結果が得られること、クライアントログで問い合わせが想定した経路を通っていること、実際の接続が想定したアウトバウンドに一致することです。DNSアドレスを変えるだけで後の2つを確認しなければ、一時的に結果が変わるだけです。テスト後はブラウザーの元の設定に戻し、複数のアプリで確認して、1つのテストページだけでなく実際の利用経路全体が直っていることを確認します。

アドレス・ポート・プロキシ種別を確認

v2rayNでシステムプロキシを設定すると、Windowsのプロキシ画面にローカルアドレスと対応するHTTPポートが表示されます。よくある誤りは、HTTPプロキシ専用の場所にSOCKSポートを入力すること、またはクライアントのポートを変更した後もシステム側に古い値が残ることです。まずクライアントの設定画面でHTTPポートとSOCKSポートを記録し、システム画面と項目ごとに比較します。アドレスは通常ループバックアドレスです。変化したLANアドレスを入力していると、オフライン時やネットワーク切り替え後に使えなくなることがあります。

システムには、自動構成スクリプト、企業ポリシー、ブラウザー拡張機能、他のプロキシソフトがあり、制御権を奪い合うことがあります。クライアントが設定を書き込んだ数秒後に元へ戻る、ブラウザーとシステム画面で異なるプロキシが表示される、といった症状が典型です。調査中は、プロキシを変更する他のプログラムやブラウザー拡張機能を一時的に無効にし、制御元を1つだけにします。端末が管理ポリシーの対象なら、システムの案内を確認し、レジストリへの書き込みを繰り返してポリシーに対抗しないでください。

WINDOWS / CURRENT USER PROXY

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable,ProxyServer,AutoConfigURL

出力の ProxyEnable で手動プロキシが有効か確認でき、ProxyServer には現在のアドレスとポートが表示されます。AutoConfigURL は自動構成スクリプトの有無を示します。結果は診断だけに使い、変更はシステム設定とクライアント画面から行ってください。レジストリを直接編集することは推奨しません。クライアント終了後もプロキシが有効なままだと、ブラウザーが閉じたローカルポートへリクエストを送り続け、「クライアントを終了するとインターネットにまったく接続できない」状態になります。この場合はシステムプロキシを無効にして直接接続へ戻します。

システムプロキシと仮想NICモードを区別

システムプロキシは、OSのプロキシインターフェースに従うアプリに適しています。仮想NICモードはより低い層で動作し、プロキシ設定を持たないプログラムにも対応できます。ただし、両方を有効にすればよいわけではありません。同時に有効にして設定を誤ると、通信がクライアントへ重複して入り、ループが発生することがあります。システムプロキシを診断する場合は、まず仮想NICモードを無効にし、ブラウザーがローカルHTTPインバウンド経由でアクセスできるか確認します。システムプロキシを使わないアプリも対象にする場合は、その後に仮想NICモードとルーティング範囲を個別に検討してください。

コマンドラインツールには独自のプロキシ変数があることが多いです。たとえば一部のツールは HTTP_PROXY と HTTPS_PROXY を読み取りますが、デスクトップのシステムプロキシを自動的には使いません。テストでは現在のターミナルセッションだけに変数を設定し、最初から全体の永続値にしないでください。プロキシアドレスにはクライアントの実際のHTTPポートを使い、クライアント終了後は変数も削除して、後続のコマンドが無効なポートへ接続し続けないようにします。

SHELL / SESSION PROXY EXAMPLE

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

unset HTTP_PROXY
unset HTTPS_PROXY

アプリごとにリクエストがコアへ入っているか確認

クライアントログを消去し、対象アプリから識別しやすいリクエストを1つだけ送ります。ログに対応するドメインまたはアドレスが出れば、アプリの通信はすでにコアへ入っています。次にルーティングとアウトバウンドを確認します。何も記録されなければ、問題はアプリからローカルインバウンドまでの間にあります。ブラウザーではまずすべてのプロキシ拡張機能を無効にして再起動し、オフィスソフトや開発ツールでは各アプリのネットワーク設定を確認します。ブラウザーが使えるからといって、すべてのアプリがシステムプロキシを使うとは限りません。

修復完了の基準は、システムのスイッチが有効と表示されることではありません。対象アプリのリクエストがクライアントログに現れ、想定したルーティングを通って正常に返ることです。ログにリクエストが一度も出ないなら、リモートノードを替え続けても意味がありません。リクエストが入っているのに失敗する場合は、ノード、DNS、ルーティングの章へ戻って確認します。ログを境界にすると、「アプリが通信を渡していない問題」と「コアが通信を届けていない問題」を正確に分けられます。

画面プロセスとコアプロセスを区別

v2rayNのデスクトップ版には、グラフィカルインターフェースと実際に通信を処理するコアプロセスがあります。画面を操作できるのにすべてのリクエストが失敗する場合は、コアが正常に起動していない可能性があります。画面が直接閉じる場合は、アプリログとシステムイベントを確認します。まず、起動時、ノード切り替え時、サブスクリプション更新時、仮想NIC有効化時のどのタイミングでクラッシュしたかを記録してください。安定して再現できる操作が手掛かりになります。「たまにクラッシュする」より、「特定の設定を追加して接続をクリックするとすぐ終了する」と記録するほうが有効です。

タスクマネージャーまたはアクティビティモニタで、古いコアプロセスが残っていないか確認します。古いプロセスがポートを使用していると、新しいコアが起動できないことがあります。複数のクライアントを同時に動かすと、システムプロキシ、仮想NIC、待受ポートを奪い合う場合もあります。関連するクライアントをすべて終了し、プロセスが終わるまで待ってから、1つのクライアントだけでテストします。プロセスが正常に終了しない場合は、まずログを保存してから該当プロセスを終了し、残留状態を隠すためにすぐ端末を再起動するのは避けてください。

設定破損と権限の問題に対処

設定編集やサブスクリプション更新の直後にクラッシュする場合は、まず現在の設定をエクスポートし、最小構成のテスト環境を作ります。直近で追加した異常なノードを削除し、自動起動、自動サブスクリプション更新、仮想NICを無効にして、構造が明確なノードを1つだけ残します。最小構成で起動できたら、設定を1項目ずつ戻します。古いデータディレクトリ全体を新しいインストール先へ一括コピーしないでください。破損した設定や古いパスまでそのまま持ち込むことになります。

インストール先の権限は、ログ、データベース、コアファイルの書き込みにも影響します。デスクトップクライアントは、現在のユーザーが読み書きできる場所に置き、継続的な権限昇格が必要なディレクトリは避けてください。圧縮ファイルから実行する場合は、完全に展開してから起動します。圧縮ツールの一時表示から直接実行しないでください。セキュリティソフトがコアファイルを隔離すると、画面だけ残って接続できなくなることがあります。システムのセキュリティ記録で処理理由を確認し、インストールパッケージページからプラットフォームに合ったクライアントを再取得してください。

Windowsデスクトップ版と従来のWPF版では、使用するUI技術が異なります。特定の画面が現在のシステム環境で安定して起動しない場合は、まず実行環境とシステム更新を確認し、ダウンロードページにある別のデスクトップ版入口で比較します。バージョンを切り替える前に、サブスクリプションアドレスとルーティング設定を保存し、初回起動はクリーンなディレクトリで行ってください。元のディレクトリを上書きしないことで、問題がUI実行環境にあるのか、共有設定にあるのかを判断できます。

ログ・リソース・再現条件

ログレベルが高すぎると、長時間の実行中に大量のディスク書き込みが発生します。特にすべての接続を詳細なデバッグ情報として記録すると顕著です。通常の利用では標準レベルを維持し、詳細レベルにするのは問題を再現する短時間だけにしてください。再現前に古いログを消去し、発生操作を1回行ったらすぐ保存します。これにより個人設定の露出を抑え、数万行の古い記録から本当のエラーを探す手間も減らせます。

ディスクの空き容量、メモリ使用量、システムのスリープ復帰も確認します。空き容量不足では、データベースやログの書き込みに失敗することがあります。スリープ復帰後はネットワークインターフェースが変わり、古い接続や仮想NICの状態が正しく再構築されない場合があります。復帰後だけクラッシュするなら、まずクライアントを終了して再起動し、復帰処理の問題か確認します。完全な再起動後にも起きるなら、設定と実行環境を引き続き確認してください。

再インストールは、設定と環境を比較した後に行います。正しい再インストールテストは、古いディレクトリを上書きせず、新しいディレクトリで現在のインストールパッケージを起動し、古い設定をすべて読み込まず最小構成だけを追加することです。新環境が安定したら、サブスクリプションとルーティングを段階的に移行します。新環境でも同じ操作でクラッシュするなら、システム環境、ドライバー、特定の設定形式に原因がある可能性が高くなります。v2rayN Windowsのインストール設定とよくある落とし穴も参照して、デスクトップ実行環境とシステムプロキシの残留を確認してください。

VPNインターフェースと独占使用を確認

接続を開始すると、システムにVPN許可の確認が表示され、対応する状態が示されます。Androidでは通常、同時に1つのアプリだけがシステムVPNインターフェースを使用できます。そのため、他のVPN、通信フィルターツール、仕事用プロファイルのネットワークサービスがv2rayNGやv2flyNGのインターフェース作成を妨げることがあります。まず他のVPN系アプリを切断し、現在のクライアントへ再接続します。許可ダイアログが表示されなくなり、状態がすぐ閉じる場合は、システムのVPN設定から古い許可を削除して再試行してください。

「VPNを常時オン」と「VPN未使用の接続をブロック」はシステムレベルのポリシーです。正しく設定すれば通信経路を制限できますが、クライアントコアの起動失敗、サブスクリプションの無効化、ノードの利用不能時には、端末全体がオフラインになったように見えます。調査中はまずこの2項目を無効にし、通常の接続が戻ることを確認してからクライアント単体をテストします。切り分け後に再有効化するかどうかは、実際のネットワーク方針に基づいて決め、システムの遮断をクライアントの終了不能と誤認しないでください。

バックグラウンド制限とバッテリー制限を解除

一部の端末では、画面消灯、アプリ切り替え、一定時間の非アクティブ状態をきっかけにバックグラウンドプロセスが制限されます。接続直後は正常なのに、数分ロックするとすべてのリクエストが止まり、クライアントを再表示すると復旧するのが典型例です。システムのアプリ設定でクライアントのバックグラウンド実行を許可し、バッテリー設定を「制限なし」にして、必要なバックグラウンドデータも許可します。端末によってメニュー名は異なりますが、確認すべき点は同じです。画面消灯後もクライアントプロセスが維持されているか、VPN状態がシステムに回収されていないかを確認します。

複数のクライアントに自動接続を同時設定しないでください。v2rayNGとv2flyNGは異なるコアの用途で使い分けられますが、1回の調査ではどちらか一方だけを起動します。2つのアプリがVPN権限を交互に奪い合うと、ステータスバーのアイコンが点滅したり、接続直後に切断されたり、システムが常に別のアプリへ戻したりします。テスト対象でないクライアントを強制停止し、現在のクライアントのバッテリー制限と自動起動設定を確認してください。

アプリごとの設定、プライベートDNS、ネットワーク切り替えを確認

アプリごとのプロキシでは、VPNへ通すアプリを選択したり、除外方式を使ったりできます。ルールの方向を誤解すると、ブラウザーは正常なのに対象アプリが直接接続される、または除外したアプリだけ使える、といった症状が起きます。診断時はまずアプリごとの機能を無効にし、すべてのアプリを同じ経路に通します。接続が正常になったら、アプリを1つずつ追加または除外してください。ルールを変更するたびに対象アプリを完全に終了して再起動し、古い接続が以前の経路を使い続けないようにします。

システムのプライベートDNSとクライアント内蔵DNSが同時に動作することがあります。プライベートDNSのホストへ到達できないと、ドメインリクエストがクライアントへ入る前に失敗する場合があります。アプリが独自に暗号化DNSを使う場合、クライアントのルーティングからはDNSサービスへの接続しか見えないこともあります。調査時はプライベートDNSを一時的に自動へ戻し、ブラウザー独自のDNSを無効にして、システムの問い合わせ経路をテストします。復旧したら、システムのプライベートDNSとクライアントDNSのどちらを使うか決め、複数の層で重複して処理しないようにします。

無線LANからモバイルネットワークへ切り替えると、ローカルアドレス、デフォルトルート、利用可能なアドレスファミリーが変わります。既存の接続が自動的に移行されず、VPNは接続中と表示されてもリクエストが停止することがあります。ネットワーク切り替え後はシステムが安定するまで待ち、クライアントを切断して再接続します。一方のネットワークだけで失敗する場合は、ノードとクライアント設定を変えず、そのネットワークのDNS、IPv6経路、認証ページを比較してください。公共無線LANでは、直接接続の状態で先にWeb認証を完了してからVPNを起動します。

Androidでは、サブスクリプション更新もバックグラウンドデータと現在のVPN経路の影響を受けます。更新結果が空の一覧でも、すぐに既存ノードを削除しないでください。まずクライアントの通信が許可されているか、サブスクリプションリンクが完全かを確認し、接続中と切断後の両方で更新をテストします。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用するため、サブスクリプション内の一部項目で対応範囲が異なる場合があります。比較時は同じネットワークと同じサブスクリプションを維持し、コア、ノード、DNSを同時に変更しないでください。

最後に、アプリログの時系列を確認します。VPNインターフェースが作成されたか、コアが起動したか、ノードのハンドシェイクが完了したか、DNSが結果を返したかを確認してください。インターフェースが作成されていなければシステム権限を確認します。インターフェースは作成されたのにコアが終了するなら、設定とクライアントを確認します。コアは動作しているのにノードがタイムアウトするなら、ノードの章へ戻ります。特定のアプリだけ失敗するなら、アプリごとのルールを確認します。この境界に沿って進めれば、端末全体のネットワーク設定を消去せず、すでに検証済みの設定も維持できます。