V2Rayトラブルシューティング大全

1. 再現可能な診断基準を作る

症状を先に記録し、原因を決めつけない

有効な切り分けは、再現可能な手順を記録することから始まります。現在のクライアント、選択中のノード、システムプロキシのモード、ルーティングモード、発生時刻、失敗したアプリを記録し、「すべてのサイトが開けない」「特定のドメインだけ失敗する」「ブラウザーは正常だが他のアプリは失敗する」「接続はできるが速度が明らかに低下している」といった症状を区別します。ノード名だけでは利用可能だと証明できず、一覧に表示される遅延値も完全な接続テストの代わりにはなりません。以前動作していたノードや設定を一つ比較対象として残しておくとよいでしょう。同じネットワークで新旧設定の結果が異なる場合、原因をノードのパラメーターまたはルーティングルールへ素早く絞り込めます。

次に、最小構成でテストします。他のプロキシクライアント、ブラウザーのプロキシ拡張、パケットキャプチャーツール、一時的なネットワーク高速化機能を終了し、V2Rayクライアントを一つだけ動かします。カスタムルーティングルールを一時停止し、クライアントの基本プロキシモードに切り替えます。ノードを一つ選んだら変更しないでください。デスクトップではTLS証明書の検証がシステム時刻に依存するため、時刻・タイムゾーン・日付が正しいことも確認します。モバイルネットワークとWi-Fiでは出口条件が異なります。テスト時にどちらを使用しているかを明確にし、ネットワーク切り替え後の結果を元の設定のせいにしないようにします。

層ごとに障害箇所を判断する

一つのリクエストは、おおむねアプリ、システムプロキシまたは仮想ネットワークインターフェース、ローカルインバウンド、ルーティングとDNS、リモートノード、接続先サーバーを通過します。ブラウザーからのリクエストがクライアントログにまったく現れない場合は、まずアプリとシステムプロキシを確認します。ノードへの接続タイムアウトがログに出る場合は、ローカルネットワークからノードまでの経路を調べます。ノードのハンドシェイクは成功したのに接続先ドメインの名前解決に失敗する場合は、DNSが重点です。特定のドメインだけ誤った出口へ送られる場合は、ルールの適用順を確認します。このように層を分ける方がクライアントを何度も再インストールするより効果的で、別々の問題を混同せずに済みます。

ログとローカル待ち受けの証拠を保存する

ログには「クライアント起動—ノード選択—失敗するアクセスを一度実行—テスト停止」までの一連の流れを残します。最後の1行だけを切り取らないでください。本当の原因は、前段の設定読み込みやインバウンドの待ち受け開始に現れることがあります。v2rayNではメイン画面のログ欄とコアログを確認できます。v2rayNGとv2flyNGでは、ログ画面で接続・ルーティング・エラー情報を確認します。ログを共有する前に、サブスクリプションURL、ノードの認証情報、ユーザー識別子、完全なサーバーアドレスを削除し、エラーの種類、発生順序、必要なパラメーターだけを残してください。

デスクトップでは、ローカルプロキシポートが待ち受け中か確認できます。以下のコマンドはローカルポートだけを調べ、リモートノードは検証しません。ポート番号はクライアント設定に表示される実際のSOCKSまたはHTTPポートへ置き換えてください。

netstat -ano | findstr LISTENING
curl --proxy http://127.0.0.1:10809 https://example.com/

ポートが待ち受けていなければ、問題はクライアントの起動、ポート競合、またはコアの読み込み段階にあります。明示的なプロキシを使うコマンドではアクセスできるのにブラウザーではできない場合、通常はシステムプロキシまたはアプリのプロキシ層に問題があります。明示的なプロキシでも失敗する場合は、ノードとDNSを確認します。この段階を終えたら、「ローカルHTTPポートは正常に待ち受け、ブラウザーのリクエストはログに入るが、ノードアドレスへの接続がタイムアウトする」のような短い結論を書けるはずです。これは次の調査の出発点であり、単なる「V2Rayが使えない」ではありません。

2. プロキシ起動後もインターネットに接続できない

ローカルの通信断とプロキシ経路の失敗を区別する

「接続後もインターネットに接続できない」状態には、通常2種類あります。1つ目は、システムプロキシがクライアントを指しているものの、クライアントのローカルインバウンドが正常に待ち受けていないケースです。システムプロキシに従うアプリはすべて直ちに失敗します。2つ目は、ローカルインバウンドは正常で、トラフィックがコアへ届いているものの、リモートノード、ルーティング、DNSのいずれかがリクエストを完了できないケースです。まずクライアントログを確認します。ウェブページへアクセスしても新しい記録がまったくなければ、トラフィックはクライアントに入っていません。接続先ドメインとアウトバウンドの記録があれば、システムプロキシは少なくともリクエストをローカルコアへ送っています。

まずシステムプロキシを無効にしてクライアントを終了し、直接接続そのものが使えるか確認します。直接接続でも普段使うサイトへアクセスできない場合は、Wi-Fi、ネットワークアダプター、ゲートウェイ、ローカルDNSを先に直し、ノードの設定を変更し続けないでください。直接接続が復旧したら、システムプロキシをまだ有効にせずクライアントを起動し、コアがエラーなく起動することを確認します。最後にシステムプロキシを有効にし、固定のテストページへアクセスします。この順番なら、障害が元のネットワーク、コアの起動、プロキシへの切り替えのどこで発生したか判断できます。

ポート、モード、プロセスの所有元を確認する

v2rayNのHTTP、SOCKS、LAN待ち受けは別々の設定です。システムプロキシは、現在実際に待ち受けているHTTPポートを指す必要があり、別の端末や古い設定のポートをそのまま使ってはいけません。ポートが他のプログラムに使用されていると、コアの起動に失敗したり、自動的に切り替わったポートとシステムプロキシの記録が一致しなくなったりします。ログに address already in use、bind failed、listen failed などの記録がないか確認します。競合が見つかったら、使用中のプログラムを終了するか、クライアントで未使用のポートに変更し、システムプロキシを設定し直してください。

ブラウザーではウェブページを開けるのにコマンドラインツールでは開けない場合でも、必ずしもノードの問題とは限りません。多くのコマンドラインプログラムはデスクトップのシステムプロキシを自動的に読み取らず、プロキシ引数や対応する環境変数を明示的に設定する必要があります。逆に、アプリが独自の手動プロキシアドレスを保存していると、システムプロキシを無効にしても古いポートへ接続し続けます。アプリ内のネットワーク設定で、「システムに従う」「手動HTTP」「手動SOCKS」「直接接続」を区別して確認してください。同じプロキシ入口を使ってテストして初めて、結果を比較できます。

最も単純なルーティング設定に戻す

複雑な分流ルールによって、DNS、ノードのドメイン、接続先へのリクエストが誤ったアウトバウンドへ送られることがあります。一時的にカスタムルールセットを無効にし、比較のため基本のグローバルプロキシモードを選択します。グローバルモードで復旧するなら、ノード経路はおそらく正常で、問題はルールの適用にあります。グローバルモードでも失敗するなら、ノードのパラメーターとDNSを続けて確認します。分流を戻すときは、明確な少数のルールから始め、まずプライベートアドレスとローカルネットワークの直接接続、次に確実なドメインルール、最後にデフォルトのアウトバウンドを設定します。ルールは通常上から順に適用されるため、前の広いルールが後の詳細なルールを隠すことがあります。

アウトバウンドのタグが実際に存在するかも確認します。ルールが参照するタグと、現在の設定にあるプロキシ、直接接続、ブロックのアウトバウンドは完全に一致していなければなりません。大文字・小文字や綴りの違いでも、読み込みに失敗したりデフォルトのアウトバウンドへ落ちたりします。サブスクリプション更新後は、クライアントが管理するアウトバウンド構造が変わる可能性があります。別の完全な設定からタグを機械的にコピーしないでください。コアログに outbound が見つからない、invalid field、設定解析エラーなどが明確に出る場合は、まずクライアントが生成したデフォルト設定へ戻し、カスタム項目を一つずつ追加します。

ネットワーク状態を復旧する

クライアントが異常終了すると、システムプロキシがローカルアドレスを指したまま、対応するポートだけ誰も待ち受けていないことがあります。その結果、ブラウザーではすべての通信が切れたように見えます。クライアントを再起動して「システムプロキシをクリア」を実行するか、システムのネットワーク設定で手動プロキシを無効にしてから、直接接続を再テストします。仮想ネットワークモードを使っている場合は、ルーティングテーブルとDNS設定を戻すため、モードを正常に停止してください。プロセスを強制終了するだけでは一時的なネットワーク状態が残ることがあります。復旧後はクライアントを再起動し、直接接続、明示的なローカルプロキシ、システム全体のプロキシの順に確認します。

ローカルネットワークのリソースだけにアクセスできない場合は、プライベートネットワークがプロキシ経由になっていないか確認します。家庭用ルーター、プリンター、ストレージ、社内サービスは通常プライベートアドレスを使うため、直接接続のアウトバウンドで処理します。プライベートアドレスのルールをデフォルトのプロキシルールより前に置き、仮想ネットワークモードがLAN探索のトラフィックを誤ってリモートへ送っていないことを確認します。特定のサイトだけ失敗する場合は、ブラウザーのプライベートウィンドウでキャッシュと拡張機能の影響を除外し、ログでそのドメインが最終的にどのアウトバウンドへ振り分けられたかを確認します。これらを確認すれば、「インターネットに接続できない」をポート、ルール、DNS、ノードの問題へ分解できます。

3. ノードのタイムアウトとハンドシェイク失敗

タイムアウト、拒否、ハンドシェイクエラーを読み分ける

ノード一覧にタイムアウトと表示されても、制限時間内にテストリクエストが完了しなかったことしか分からず、サーバーが恒久的に利用不能だとは限りません。接続タイムアウトは通常、ノードのアドレスとポートへのTCPまたはUDP経路が時間内に確立しなかったことを示します。接続拒否は、アドレスには到達できるものの、そのポートで接続を受け付けるサービスがないことを示します。接続リセットは、経路が確立した後にどこかの端点が切断した状態です。TLSハンドシェイクエラーでは、サーバー名、トランスポート層、セキュリティ設定、システム時刻をさらに確認します。エラーごとに示す層は異なるため、すべてを「ノードが無効」と一括りにしてはいけません。

同じサブスクリプション内の2つのノードで実際の接続テストを行います。現在のネットワークではすべてのノードが同時にタイムアウトし、別のネットワークで復旧するなら、まずローカルネットワークの出口、ファイアウォール、ルーティング経路を確認します。1つのノードだけがタイムアウトし、他は正常なら、そのノードのアドレス、ポート、リモートサービスが原因である可能性が高いでしょう。同じノードが複数の端末と異なるネットワークで失敗する場合は、クライアント設定を変え続けるより、設定提供者にノードの状態とパラメーターを確認する方が直接的です。

ノードのパラメーターを一つずつ確認する

ノードを手動でインポートする場合、アドレス、ポート、ユーザー識別子、プロトコル、セキュリティ層、トランスポート方式、サーバー名、パスは一組として一致している必要があります。VLESS、VMessなどのプロトコルのフィールドを相互に流用することはできません。WebSocket、gRPC、TCPなどのトランスポート方式では、パス、サービス名、リクエストヘッダーも異なります。最も多いのは、古いノードから設定をコピーし、アドレスとポートだけを変更して、サーバー名やトランスポートパラメーターの不一致を残すケースです。クライアントの編集画面と元の設定をフィールド単位で照合し、ノード名だけで判断しないでください。

TLSを有効にすると、サーバー名は通常、証明書の検証とハンドシェイクに使われるため、ノードのIPへ勝手に置き換えないでください。システム時刻が大きくずれると、証明書がまだ有効でない、または期限切れという判定が誤ることがあります。ログに certificate、handshake、server name、verify failed が出たら、まずシステム時刻を合わせ、サーバー名とセキュリティ設定を確認します。必要な検証を無効にしてパラメーターの不一致を隠さないでください。正しい方法は、サーバー側と一致する設定を取得することです。REALITYなどのセキュリティ方式を使う場合は、公開鍵、短い識別子、サーバー名、フロー制御パラメーターも一致させます。

遅延テストだけで利用可否を判断しない

ICMP ping、TCP接続、プロキシのハンドシェイク、ダウンロード速度は、それぞれ異なる段階を測定します。サーバーがpingに応答しなくても、プロキシポートは正常な場合があります。TCPポートで接続できても、プロトコル認証に失敗することがあります。実際の接続遅延が低くても、継続的な転送帯域が限られている場合があります。そのためノードを選ぶときは、まずクライアントの実接続テストでプロキシのハンドシェイクを確認し、実際のウェブページとファイル転送で安定性を検証します。3種類のテストの違いについては、V2Rayの遅延テストの仕組みも参照してください。

テストでは同時実行数も増やしすぎないでください。大量のノードを一斉に測定すると、ローカル接続、DNSクエリ、ネットワーク出口を消費します。ルーターによっては短時間の大量接続を制限するため、一斉にタイムアウトすることもあります。まず少数のノードを順番にテストし、前の接続が解放されてから結果を比較します。モバイルネットワークでは、電波の切り替え、省電力機能、ネットワーク種別の変化によって短時間のテストが不正確になるため、通信が安定してから再測定してください。

アドレス解決とプロトコルに必要なネットワークを確認する

ノードのアドレスがドメインの場合、クライアントは先にそのドメインを解決する必要があります。現在のDNSルールが、まだ確立していないプロキシ経由での問い合わせを要求していると、起動依存が発生します。ノードがないとDNSを解決できず、DNSがないとノードへ接続できません。一時的に信頼できる直接接続のDNSでノードのドメインを解決し、接続先ドメインは既定のポリシーで解決します。UDPを使用する機能には、ローカルネットワーク、クライアントのインバウンド、リモートノード、アウトバウンド経路すべての対応が必要で、クライアントでUDPを有効にしただけでは不十分です。

最終記録には、ノードパラメーターが完全なインポートに基づくか、同じグループの他のノードが使えるか、ネットワーク切り替えで復旧するか、TCP接続確立とプロトコルハンドシェイクのどちらでエラーが起きたかを含めます。1つのノードだけがネットワークをまたいで失敗する場合は、完全な認証情報を公開せず、ログのエラー種別だけを残します。すべてのノードが現在のネットワークでのみ失敗するなら、各ノードを編集し続けるのではなく、ローカルのファイアウォール、ルーター、DNS、ネットワーク出口を重点的に確認します。

4. サブスクリプション更新とインポートの失敗

ダウンロード失敗か解析失敗かを先に判断する

サブスクリプションの失敗は、少なくとも3段階に分けられます。クライアントが内容を取得できない、取得した内容を解析できない、解析は成功したがノードが現在のグループに入らない、の3つです。更新時はまずログと表示メッセージを確認します。HTTPタイムアウト、接続失敗、ドメイン解決失敗は通常ダウンロード段階です。base64、JSON、YAML、unsupported schemeなどの表示は内容の解析段階です。更新完了後も一覧が変わらない場合は、グループ選択、重複除去、フィルター、またはサブスクリプションの内容自体が変わっていない可能性があります。

現在表示しているサブスクリプショングループが更新対象か確認します。v2rayNは複数のサブスクリプショングループに対応しているため、ノード一覧が別のグループに残っていることがあります。更新操作も選択中のグループだけに適用される場合があります。同名のグループへ同じアドレスを何度もインポートせず、まずグループのプロパティでサブスクリプションURL、有効状態、更新結果を確認します。Androidクライアントでも、単一ノードのインポート、クリップボードからの一括インポート、サブスクリプション管理は別物です。3つが自動的に同じ更新元へ統合されることはありません。

サブスクリプションURLの完全性を確認する

チャットツールやウェブページからサブスクリプションURLをコピーすると、前後の空白、改行、エスケープ文字、途中で切れたクエリパラメーターがリクエスト失敗の原因になります。サブスクリプションの編集欄で、プロトコル部分から最後のパラメーターまで途切れず入力されているか確認します。一時トークンや端末パラメーターを含むURLでは、1文字欠けただけで未認証や空の内容が返ることがあります。サブスクリプションURLは設定を取得できる権限を持つことが多いため、公開ログ、スクリーンショット、オンライン解析ツールへ貼り付けないでください。

クライアントがプロキシ経由の更新に対応している場合は、「直接接続で更新」と「現在のプロキシ経由で更新」を別々にテストします。現在のネットワークからサブスクリプションサービスへ直接アクセスできるなら、直接接続が最も単純です。既存ノードを経由しないとアクセスできないなら、まず利用可能なノードが必要です。唯一のサブスクリプションに含まれる古いノードがすべて使えない場合、プロキシ経由の更新は行き詰まります。その際は同じ失敗リクエストを繰り返すのではなく、設定提供者から直接アクセス可能な新しいURLまたは独立した設定を取得してください。

更新成功後も新しいノードがない場合の確認

ノード数だけでなく、更新時刻とログが実際に変化したかを確認します。サブスクリプションサービスが前回と同じ内容を返したり、クライアントがノード識別子で重複除去したりするため、数が変わらないのは正常な場合があります。名前フィルター、正規表現フィルター、特定プロトコルだけを残す設定、古いノードを削除する設定が有効になっていないか確認します。フィルターが広すぎると、解析後に新しいノードがすべて除外されることがあります。フィルター式に構文エラーがある場合、クライアントによっては古い一覧を残したまま更新失敗を表示します。

サブスクリプショングループを変更する前に、現在利用できる設定をエクスポートします。その後、一時グループを新規作成し、同じサブスクリプションをインポートします。一時グループなら、古いキャッシュ、以前のフィルター、重複項目の影響を除外できます。一時グループも空なら、サブスクリプションの応答内容を重点的に確認します。一時グループにはノードがあるのに元のグループにはない場合は、元グループのフィルター、並び順、更新設定を確認します。比較が終わってから元グループを置き換え、最初から唯一使えるノードを削除しないでください。

形式とクライアントの対応範囲の違いを確認する

サブスクリプションの内容は、プロトコルリンクの集合の場合もあれば、構造化された設定の場合もあります。クライアントが解析できる形式とフィールドには限りがあります。完全なコア設定を通常のサブスクリプションとしてインポートしたり、単一の共有リンクをサブスクリプション欄に入れたりすると、形式エラーになることがあります。提供者が案内するインポート方法と現在のクライアントが一致しているか確認してください。v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用するため、一部の新しいフィールドやトランスポートの組み合わせへの対応範囲が異なる場合があります。一方で読み込めても、もう一方が必ず受け付けるとは限りません。

{
  "remarks": "example-subscription",
  "url": "https://example.com/subscription?token=xxxx",
  "enabled": true
}

上の構造は確認すべき論理フィールドを説明するためのもので、実際のサブスクリプションはクライアント画面から追加してください。例をそのままクライアント設定ファイルとして使わないでください。解析エラーが出た場合は、エラー行付近のフィールド名を記録し、クライアントとカーネルが現在のダウンロードページのインストール入口から提供されたものか確認します。互換性をバージョン番号だけで推測せず、クライアントに実際に表示される機能とログを基準にしてください。

サブスクリプションのリクエストが断続的に失敗する場合は、同じネットワークで少し間隔を空けて再試行し、直接接続とプロキシ経由の更新結果を比較します。短時間に何度も更新すると、サーバー側のリクエスト制限にかかることがあり、ログも読みにくくなります。最終的に、リクエストは成功したか、返された内容は解析できたか、ノードは対象グループに入ったか、フィルターで結果が削除されていないかを明確にします。短い疑問については、ヘルプセンターの「インストールと設定」カテゴリも確認してください。

5. 接続は正常だが通信速度が遅い

遅延、帯域幅、安定性を分けて測定する

速度が遅いかどうかを、ノード一覧のミリ秒表示だけで判断しないでください。遅延は短い接続の確立と操作への応答性、帯域幅は継続的な転送速度、パケットロスとジッターは動画・通話・長時間接続の安定性を左右します。低遅延でも出口帯域が限られるノードはありますし、遅延が少し高くても継続ダウンロードが速いノードもあります。テストではまず固定のウェブページを開いて初期表示の応答を確認し、次に継続転送を行い、最後に数分間の通信で繰り返し切断されないか観察します。3つの現象を別々に記録し、1回の速度テストで全体を判断しないでください。

比較対象を作るときは、端末、ネットワーク、対象リソース、テスト時刻をなるべく揃え、ノードだけを変更します。まず直接接続で利用可能な帯域幅を測り、次に異なる経路のノードを2つ測定します。直接接続自体が遅いなら、Wi-Fiの電波、モバイルネットワークの品質、ローカルの帯域使用を優先して確認します。すべてのノードが同じ低い速度に近いなら、端末性能、仮想ネットワークモード、リモートの出口を確認します。1つのノードだけが明らかに遅い場合は、その経路の混雑や出口品質が原因である可能性が高いでしょう。

ローカルのリソースと同時実行の影響を除外する

同期ソフト、システム更新、クラウドストレージ、動画再生、他の端末が上りまたは下りの帯域を消費します。特に上り帯域が埋まると、確認パケットを適時に送れず、下りも途切れて見えます。テスト前に大容量通信を一時停止し、ルーターやシステムのタスクマネージャーでネットワーク使用量を確認します。ブラウザーで大量のページを開く、ダウンローダーの同時実行数を増やす、クライアントで全ノードを並列測定する、といった操作も接続数とCPUを消費し、結果を不安定にします。

クライアントのコアは、暗号化、トランスポートのカプセル化、ルール適用、DNSを処理します。低消費電力の端末では、高スループット時にCPUが飽和し、速度が一定値から伸びなくなることがあります。システムリソースを確認し、転送中に1つのコアが継続的に高負荷なら、複雑なルールを減らし、不要なログレベルを無効にして、システムプロキシモードと仮想ネットワークモードの違いを比較します。速度を求めて理解していないトランスポートパラメーターを変更しないでください。クライアントの設定はリモートサービスと一致する必要があり、一方的な変更は接続失敗につながります。

ルーティングが遠回りしていないか確認する

速度の問題がルーティングにある場合もあります。本来直接接続すべきローカルまたは地域のリソースがプロキシへ送られると、経路と出口の負荷が増えます。本来プロキシを使う対象が誤って直接接続されると、再試行を繰り返すことがあります。ログで対象ドメイン、解決結果、最終アウトバウンドを確認し、ルールが想定どおり適用されているか調べます。geositeとgeoipで分流する場合、ドメインルールとIPルールで異なる結論になることがあり、最終結果はルールの順序で決まります。

まずグローバルプロキシモードでノードの上限を測定し、その後分流モードへ戻します。グローバルモードは速く、分流モードだけ遅いなら、DNSとルールの適用を確認します。両方とも遅いなら、回線と端末を調べます。最初のページ表示だけ遅く、その後は正常なら、DNS問い合わせ、最初のTLSハンドシェイク、接続確立が原因としてよくあります。開始直後は速いのに継続転送で低下するなら、回線混雑、パケットロス、端末温度、帯域制限が考えられます。ルーティングルールの実践方法は、geositeとgeoipの分流実践を参照してください。

再現可能な方法でテストする

複数の速度測定サイトを同時に使い、結果を一緒に扱わないでください。固定のリソースを選び、近い時間帯に直接接続、ノードA、ノードBを測定します。各状態を2〜3回繰り返し、最高値ではなく中央値に近い結果を記録します。テスト中はルーティングモードを揃え、ブラウザーキャッシュがダウンロード結果へ与える影響を抑えます。対象リソースが出口ごとに異なる配信先を選ぶ場合は、別の安定したリソースでも確認し、対象サイト単独の混雑をノード速度と誤認しないようにします。

実接続の遅延テストでは同時実行数を制限し、ノード数が多い場合は分割して実行します。ログに retry、broken pipe、reset、idle timeout が頻繁に出るなら、平均速度が十分でも経路の安定性に問題があります。その場合は遅延が最も低いノードではなく、パケットロスと再接続が少ないノードを優先します。動画やインタラクティブなアプリは安定性を重視し、長時間のファイル転送は継続帯域を重視するため、選定基準は同じではありません。

調査後には、ボトルネックが直接接続のネットワーク、端末処理、ルーティングの遠回り、DNSの初回検索、特定ノードの経路、対象リソースのどこにあるか判断できる状態にします。時間帯で変わるなら時間帯別の比較を残し、ネットワークで変わるならWi-Fiとモバイルネットワークを比較し、クライアントモードで変わるなら仮想ネットワークインターフェースとルールの複雑さを確認します。このような結論の方が、単に「速度測定が遅い」と記録するより次の対応に役立ちます。

6. DNSの名前解決エラー、汚染、漏洩につながる設定の不一致

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

DNSの問題は、ドメインでは開けないのに既知のIPには応答がある、同じサイトでもアプリによって結果が異なる、プロキシモードを切り替えると解決先アドレスが変わる、ログに lookup、resolve、no such host、SERVFAIL、NXDOMAIN などが出る、といった形で現れます。ノード自体には接続できても、対象ドメインが不適切なアドレスへ解決され、最終的にタイムアウトや証明書名の不一致になることもあります。調査では「ノードのドメイン解決」と「対象ドメインの解決」を分けて考えてください。両者は異なる経路を使うことがあります。

システムとブラウザーのキャッシュを先に消去し、同じ問い合わせを再実行します。ブラウザーが独自のセキュアDNSを使っていると、システムやクライアントの設定に従わない場合があります。システム側にも古い回答がキャッシュされます。テスト時はブラウザー独自のDNSを無効にするか、その状態を記録し、システムの問い合わせツールとクライアントログを照合します。Windowsでは nslookup、macOSとLinuxでは dig または nslookup を使えます。問い合わせ結果が違っても、どちらかが自動的に間違いとは限りません。最終的に直接接続側のDNSとプロキシ側のDNSのどちらが処理すべきかを確認します。

nslookup example.com
nslookup example.com 1.1.1.1

dig example.com
dig @1.1.1.1 example.com

ローカル解決とリモート解決を理解する

ローカル解決では、まず端末側でIPを取得し、その後ルーティングルールで接続を処理します。リモート解決では、通常ドメインをプロキシ側で処理します。前者はIPルールによる分流に便利ですが、ローカルDNSの結果に依存します。後者は対象ドメインがローカルの解決経路に左右されるのを避けられますが、クライアントはノードアドレスや一部の直接接続ドメインを解決しなければなりません。具体的なモード名はクライアントとカーネルの設定によって異なるため、スイッチ名だけで判断せず、ログでドメインがローカルとリモートのどちらで解決されたか確認します。

ルーティングルールにドメイン条件とIP条件の両方がある場合、解析方式によってIPルールの照合に使えるアドレスが生成されるかどうかが変わります。ドメインだけで照合するなら、事前解決は必ずしも必要ありません。geoipで判断する場合は、コアが先に解決してから照合することがあります。誤った方式では、「ドメインルールに一致せず、IPルールも想定どおりに働かない」状態になります。まず要件を定義します。ローカルドメインとプライベートアドレスは直接接続、特定ドメインは指定したアウトバウンド、その他はデフォルトのアウトバウンド。その要件に合う解決経路を選択してください。

起動依存と名前解決ループを防ぐ

ノードアドレス自体がドメインで、すべてのDNS問い合わせをそのノード経由にする設定だと、名前解決ループが発生します。プロキシ確立前から使えるブートストラップ解決をノードのドメインに用意するか、ノードのドメインを明確な直接接続DNSへ送ることで解決できます。ブートストラップDNSはプロキシ確立に必要な少数の解決だけを担当し、対象ドメインのポリシーと混同しないでください。ログでノードのドメインへの問い合わせが繰り返され、接続確立前にDNSリクエストが再発しているなら、この依存関係を確認します。

仮想ネットワークモードがシステムDNSを引き継ぐ場合もあります。クライアントの異常終了、ネットワーク切り替え、スリープからの復帰後に、到達できないDNSアドレスがシステムに残ると、プロキシを無効にしても解決できなくなります。まず仮想ネットワークモードを正常に停止し、ネットワークアダプターのDNSが自動または元の設定へ戻っているか確認します。クライアント実行中に複数のネットワークツールでDNSを同時に変更すると、どの設定が最終的に有効か分からなくなるため避けてください。

ログで最終的な回答を検証する

DNSを変更した後、ウェブページがたまたま開くかだけを見ないでください。キャッシュを消去し、固定のドメインを問い合わせ、返されたアドレスを記録し、クライアントログでそのドメインがどのアウトバウンドに一致したかを確認します。同じドメインに複数のアドレスがある場合、短時間の変化は正常な負荷分散によることがあります。重要なのは、アドレスの種類とアウトバウンドがルーティング設計に合っているかです。解決結果、ルールの一致、最終接続の3つが一致して初めて、設定が有効だと判断できます。

特定のドメインだけが継続的に失敗する場合は、ルートドメインとサブドメインを比較し、個別のドメインルール、hostsによる上書き、キャッシュがないか確認します。hostsの項目は通常優先度が高く、古い項目があるとDNS設定がすべて効いていないように見えます。特定のブラウザーだけで起きる場合は、そのブラウザーのDNSと接続キャッシュを消去します。すべてのアプリで同じなら、システムとクライアントの層へ戻ります。DNSサービスの変更は比較用にとどめ、解決経路の確認の代わりにしないでください。

DNS修正後の確認基準は、クライアントをコールドスタートしてノードへ接続できること、システムの問い合わせ結果が想定した解決経路と一致すること、ブラウザーとコマンドラインが同じプロキシ入口を使った場合に同じ結果になること、ネットワーク切り替え・スリープ復帰・正常終了後にシステムDNSが復元されることです。仮想ネットワークモードだけが失敗し、通常のシステムプロキシは正常なら、仮想インターフェースによるDNSの引き継ぎ、ルーティング優先度、システム権限を確認してください。

7. システムプロキシ設定が機能しない

アプリがシステムプロキシに従うか確認する

システムプロキシは、すべてのプログラムが自動的に使う統一トンネルではありません。ブラウザーや一部のデスクトップアプリは通常システムプロキシを読み取りますが、コマンドラインツール、ゲーム、バックグラウンドサービス、独自のネットワークスタックを使うプログラムは無視することがあります。「ブラウザーは正常だが特定のアプリは直接接続する」場合は、そのアプリがシステムプロキシに対応しているか、手動プロキシを保存していないか、HTTPまたはSOCKSを個別に設定する必要がないか確認します。システムプロキシを読み取らないアプリでは、クライアントの仮想ネットワークモードを検討できますが、使用前に権限、ルーティング、DNSの適用範囲を理解してください。

一方、ブラウザーのプロキシ拡張がシステム設定を上書きすることもあります。拡張が古いポート、古いプロトコル、別のプロキシプログラムを指している場合、v2rayNのシステムプロキシ状態はブラウザーが実際に使う経路を決めません。調査時は拡張を一時的に無効にし、ブラウザーの標準ネットワーク設定を使います。正常に戻ったら拡張を設定し直してください。企業の管理ポリシーがプロキシ項目を固定している場合、設定画面が表示されていてもアプリが読む値はポリシーで決まることがあります。システムプロキシ画面に組織による管理の表示がないか確認します。

プロトコルと待ち受けアドレスを確認する

HTTPプロキシとSOCKSプロキシは、ポート番号だけで入れ替えられません。システムプロキシには通常HTTP入口が必要ですが、ツールによってはSOCKSを直接使用できます。クライアント設定で各インバウンドのプロトコル、待ち受けアドレス、ポートを確認し、アプリ側にも対応する値を入力します。127.0.0.1で待ち受ける場合はローカルからのみアクセスできます。LAN接続を許可すると全インターフェースで待ち受けることがありますが、本機のシステムプロキシを有効にするために必要な条件ではありません。通常の利用で、ローカルプロキシを直すためにLAN待ち受けを不用意に開放しないでください。

次の方法で明示的なHTTPプロキシを検証できます。コマンドは成功するのにシステムプロキシモードのブラウザーが失敗するなら、問題はシステムプロキシの登録またはブラウザーによる上書きにあります。コマンドがローカルポートへの接続で拒否されるなら、コアのプロセスとポートを確認します。ローカル接続は成功するがリモート接続が失敗するなら、ノード、ルーティング、DNSを調べます。

curl -I --proxy http://127.0.0.1:10809 https://example.com/
curl -I --socks5-hostname 127.0.0.1:10808 https://example.com/

例のポートは説明用です。必ずクライアントの現在の設定を使ってください。--socks5-hostnameを使うと、ドメインはSOCKS経路で解決され、ローカル解決方式との比較に適しています。システムプロキシを自動設定するプログラムを複数同時に実行しないでください。互いにシステム値を上書きし、画面の状態と実際の登録値やネットワークサービスの設定が一致しなくなることがあります。

異常終了後に残るプロキシを処理する

クライアントを強制終了した、システムが突然シャットダウンした、コアがクラッシュした場合、システムプロキシがローカルポートを指したままになることがあります。システムプロキシに従うアプリはすべて失敗するため、ネットワークが切断されたように見えます。まず元のクライアントを再起動し、システムプロキシのクリアまたは無効化を実行してから正常終了します。システムのネットワーク設定で手動操作してプロキシを無効にすることもできます。直接接続を復旧した後、クライアントを起動して再設定します。ネットワークが切れた状態でいきなりすべての設定を削除すると、残ったポートや元の設定を確認できなくなるため避けてください。

Windowsでは、アカウントと権限コンテキストの違いにも注意が必要です。異なる権限で起動したプログラムは、別の環境変数や設定範囲を読むことがあります。バックグラウンドサービスも、現在のデスクトップアカウントのプロキシを使うとは限りません。macOSのプロキシ設定はネットワークサービスごとに保存され、Wi-Fiと他のネットワークインターフェースで異なる場合があります。インターフェースを切り替えたら、現在アクティブなネットワークサービスのプロキシ状態を確認します。Linuxデスクトップでは、デスクトッププロキシ、環境変数、アプリ独自の設定が同時に存在することがあるため、層ごとに確認します。

環境変数とコマンドラインプログラム

コマンドラインプログラムは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYを読み取ることがよくあります。変数は現在のターミナル、ユーザー設定ファイル、システムサービス、コンテナ環境から設定される場合があります。ターミナルに古いポートが残っていると、デスクトップのシステムプロキシを更新してもコマンドラインのリクエストは失敗します。変数を確認した後にターミナルを開き直し、新しいプロセスが最新値を読むようにします。イントラネットのドメインやローカルアドレスは通常プロキシを通さない範囲に追加しますが、除外項目は正確にしてください。広すぎる除外は、本来プロキシを通すべきリクエストを直接接続させます。

set HTTP_PROXY
set HTTPS_PROXY

env | grep -i proxy

変数を消去する前に、設定元を記録します。現在のターミナルだけで一時変更すると、次回起動時に古い値へ戻ることがあります。コンテナやサブシステムが独立したネットワーク名前空間を持つ場合、127.0.0.1はホストではなくコンテナ自身を指すことがあります。アクセス可能なホストアドレスを使い、クライアントがそのインターフェースからの接続を許可しているか確認してください。これはアプリのネットワーク境界の問題であり、ノードプロトコルの問題ではありません。

最終的に、コアのポートが実際に待ち受けていること、システムプロキシが同じポートと正しいプロトコルを指していること、ブラウザー拡張が上書きしていないこと、コマンドラインの環境変数に古い値がないこと、異常終了後にプロキシを復旧できること、システムプロキシに従わないアプリに明確な接続方法を設定していることを確認します。クライアントを再インストールする場合は、まずクライアント入手ページで対応するプラットフォームを選び、アンインストール前に現在のポート、グループ、ルーティング設定を記録してください。インストール後の設定差をプログラムの問題と取り違えずに済みます。

8. クライアントが起動しない、強制終了する、コアがクラッシュする

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

v2rayNなどのグラフィカルクライアントは、通常、設定管理、サブスクリプション、システムプロキシ、画面表示を担当し、実際の接続はXrayまたはv2flyカーネルのプロセスが処理します。画面は開くのに接続できない場合は、コアが起動していない可能性があります。画面がすぐ終了する場合は、実行環境、設定ファイル、権限、プログラムファイルを優先して確認します。タスクマネージャーやシステムのプロセス一覧に画面プロセスしか見えなくても、コアが正常に動いているとは限りません。ログが「コア起動」の前で止まるか後で止まるかによっても、調査の方向は変わります。

まずクライアントを完全に終了し、画面プロセスとコアプロセスが残っていないことを確認してから、1回だけ再起動します。起動ボタンを連続して押すと、複数のインスタンスが設定ファイルと待ち受けポートを奪い合います。クライアントがすでに実行中と表示する場合は、タスクマネージャーで残ったプロセスを終了し、ポートが解放されるのを待ってから起動します。特定の設定を読み込むたびに終了するなら、現在の設定を一時的にバックアップとしてエクスポートし、最も単純な既知の有効設定へ切り替えてテストします。

設定の解析と書き込み権限を確認する

JSONを手動編集すると、余分なカンマ、誤った引用符、フィールド型の違いだけでコアの読み込みが止まることがあります。failed to parse、invalid character、unknown field、failed to load configなどのログには、フィールド位置が示されることがあります。エラーのあるファイルに追記し続けず、クライアント画面でデフォルト設定を生成し、カスタムDNSとルーティングを一つずつ追加してください。以下は括弧と配列の関係を理解するための、構文が完全な最小JSON構造の例です。直接接続できるノードは含みません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

設定ディレクトリに書き込めないと、サブスクリプション更新、ログ作成、設定保存も失敗することがあります。クライアントの配置先とユーザーデータディレクトリに、現在のアカウントが書き込めるか確認し、読み取り専用の場所から直接実行しないでください。セキュリティソフトがコアファイルを隔離すると、画面にコアが見つからないと表示されたり、起動直後に終了したりします。システムのセキュリティ記録を確認し、ファイルの取得元が本サイトのダウンロード入口と一致することを確認したうえで、本機の管理ポリシーに従って対処します。不明な場所から単一のコアファイルだけを補充しないでください。画面とカーネルの組み合わせが不整合になります。

ポート競合と重複インスタンスを処理する

コアの起動直後に終了する原因として、ローカルポートの使用中がよくあります。ログには bind、listen、address already in use が出ます。まず使用中のプロセスを特定し、それが古いクライアント、別のプロキシプログラム、システムサービスのどれかを判断します。残ったインスタンスなら正常終了させて再起動します。必要なサービスがポートを使っているなら、クライアントでHTTPとSOCKSのポートを変更し、システムプロキシ、ブラウザー拡張、コマンドラインの環境変数も同時に更新します。クライアントのポートだけを変えると、利用側との不一致によって「クラッシュ」が「プロキシが機能しない」状態に変わるだけです。

複数のユーザーアカウント、リモートデスクトップセッション、ログイン時の自動起動タスクが別々のインスタンスを起動することもあります。スタートアップ項目とスケジュールタスクを確認し、システムプロキシを設定するクライアントが1つだけになるようにします。異なる設定を並行して使う必要がある場合は、各インスタンスに独立したデータディレクトリ、ログ、待ち受けポートを割り当てます。ただし通常の調査では原因を特定しにくくなるため推奨しません。

むやみに削除せず、クリーンな状態から復旧する

復旧前に、サブスクリプショングループ、手動ノード、カスタムルーティングをバックアップします。ただしサブスクリプションURLやノードの認証情報は公開場所に保存しないでください。次にシステムプロキシと仮想ネットワークモードを無効にし、クライアントを正常終了します。既存の設定ディレクトリをバックアップ用の名前に変更し、新しいデフォルト設定を生成して、画面とコアが動作することを確認します。その後、単一ノード、サブスクリプショングループ、ルーティングとDNSの順にインポートします。どの段階で再びクラッシュするかによって、確認すべきデータを絞れます。

新しい設定でも起動できない場合は、実行環境、システム権限、プログラムのアーキテクチャ、セキュリティソフトの記録を調べます。macOSではアプリを開く許可を確認し、Linuxではターミナルから起動して不足している依存関係と権限エラーを確認します。Windowsではアプリケーションイベントとクライアントログを確認します。エラーレポートには異常モジュール、終了段階、エラーコードを残しますが、個人のパス、サブスクリプション内容、認証情報は削除してください。

更新や大量の速度測定時だけクラッシュするなら、同時実行数を減らし、メモリとディスク容量を確認します。スリープ復帰後だけなら、ネットワークインターフェースの変化と古いコアプロセスを調べます。仮想ネットワークモードだけなら、ドライバー、権限、他の仮想インターフェースとの競合を確認します。調査後は、画面、コア、設定解析、ポート、権限、実行環境のどこに問題があるかを特定してから、設定修正か再インストールかを決めます。すべての異常をクライアントのバージョンだけに原因づけないでください。

9. Androidの接続とバックグラウンド動作

仮想ネットワークの許可と現在のクライアントを確認する

v2rayNGとv2flyNGはAndroid上で、通常システムの仮想ネットワークインターフェースを使って通信を引き継ぎます。初回接続時にはシステムの許可が必要です。許可を拒否した、別の仮想ネットワークアプリが使用中、再起動後にシステムが許可を取り消した、といった場合、クライアントは起動中と表示されても実際には通信を引き継げないことがあります。同じシステムインターフェースを使う他のネットワークツールを停止し、現在のクライアントを再起動して許可ダイアログを確認します。ステータスバーの接続マークはインターフェース確立の手掛かりにすぎず、ログと実際のアクセスでもノード経路を検証してください。

2つのクライアントを同時に接続状態にしないでください。v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用するため、対応する設定フィールドの範囲が異なる場合があります。同じサブスクリプションを2つのクライアントで比較する場合は、先に一方の接続を停止してから、もう一方を起動します。そうしないとシステム上で有効になるインターフェースが1つに限られ、ノードの故障と誤認します。デスクトップではv2rayNで相互確認できますが、端末間の比較ではWi-Fi、モバイルネットワーク、DNS経路の違いも考慮してください。

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

一部のAndroidシステムは、バックグラウンドプロセス、画面ロック中のネットワーク、バッテリー使用を制限します。前面では正常に接続できるのに、数分ロックすると切断され、クライアントを開き直すと復旧するのが典型例です。システムのアプリ設定でクライアントの継続的なバックグラウンド実行を許可し、厳しいバッテリー制限を無効にします。通知やサービスを自動消去する設定がないことも確認してください。メニュー名は端末によって異なるため、「バッテリー」「バックグラウンド使用」「自動起動」「アプリ起動管理」などを手掛かりに探します。

設定後はクライアントのボタン状態だけを見ないでください。接続を確立して固定のウェブページへアクセスし、画面をロックして待ち、ロック解除後に再度アクセスしてログの時系列を確認します。ログが途中で完全に止まるなら、通常はプロセスがシステムによって停止されています。ログが続いているのに接続が再構築されるなら、スリープ中にネットワークインターフェースが切り替わった可能性があります。リクエストがログに入った後にノードがタイムアウトするなら、ネットワーク経路を確認します。常時表示の通知は、システムが実行中のネットワークサービスを認識する助けになるため、関連する通知カテゴリを不用意に無効にしないでください。

Wi-Fiとモバイルネットワークを切り替える

Wi-Fiからモバイルネットワークへ切り替えると、端末のIP、DNS、最大転送単位、ネットワーク能力が変化します。古い接続は通常再確立が必要で、短時間の失敗は切り替えの一部です。切り替え後も長時間通信できない場合は、クライアントを停止して再起動し、仮想インターフェースを新しいネットワークへバインドし直します。Wi-Fiへ戻す場合も再テストしてください。ログイン認証が必要な公共Wi-Fiでは、まずプロキシを一時停止してネットワーク認証を完了し、その後再接続します。

Wi-Fiでは正常でモバイルネットワークではタイムアウトする場合、ノードのアドレスをモバイルネットワークで解決できるか、アクセスポイントが特定の接続方式を制限していないかを確認し、サブスクリプション内の別ノードと比較します。モバイルネットワークは正常で家庭のWi-Fiだけ失敗する場合は、ルーターのDNS、ファイアウォール、同じネットワーク上の他の端末を確認します。ネットワーク切り替えと同時にノードパラメーターを変更すると、復旧の原因がネットワークか設定か分からなくなるため避けてください。

アプリ別プロキシとバイパス設定

Androidクライアントにはアプリ別プロキシ機能が用意されていることがあります。有効にしたら、「選択したアプリだけをプロキシする」のか「選択したアプリをバイパスする」のかを明確にします。2つのモードは方向が逆で、選択を誤るとブラウザーは正常なのに他のアプリが直接接続したり、一部のアプリだけ失敗したりします。調査時はアプリ別設定を一時的に無効にし、すべてのアプリを同じ経路で接続します。基本接続が正常になってから、アプリを1つずつ追加してテストします。アプリの更新や再インストール後は識別情報が変わることもあるため、一覧を再確認してください。

LANアプリ、キャスト、印刷、デバイス検出ではプロキシをバイパスする必要がある場合がありますが、実際の通信は仮想インターフェースのルーティングにも左右されます。LANへアクセスできない場合は、クライアントがLANバイパスを許可しているか、プライベートアドレスが直接接続になっているかを確認します。すべての通信を対象にする広すぎるバイパス範囲は使わないでください。項目を1つ追加するたびに対象アプリで検証します。アプリ内に独自プロキシやセキュアDNSがある場合も、一時的にデフォルトへ戻し、クライアントの仮想ネットワーク設定との重複を避けます。

モバイル端末のログと最終確認

モバイル端末のログ収集では、接続開始、ネットワーク切り替え、画面ロックからの復帰、失敗したアプリがリクエストを開始した時点を記録します。システムに仮想ネットワーク接続が表示されているか、クライアントサービスが動作し続けているか、リクエストがログに入っているか、ノードが再接続しているかを確認します。ログを共有する前に、サブスクリプションURL、ユーザー識別子、サーバーの完全な情報を削除してください。特定のアプリだけで問題が起きる場合は、そのアプリで独自DNSが有効か、アプリ別ルールの対象になっているか、ブラウザーの比較結果が正常かも記録します。

最終確認には少なくとも4項目を含めます。前面表示中の継続アクセスが正常であること、画面ロックから復帰してもアクセスを続けられること、Wi-Fiとモバイルネットワークの切り替え後に自動または1回の再接続で復旧すること、アプリ別ルールが想定どおりであることです。v2rayNGとv2flyNGで同じ設定の結果が異なる場合は、まずその設定のカーネルフィールド互換性を確認し、どちらを使うか判断します。クライアント名の違いだけを原因にしないでください。インストール入口を再取得する場合は、Androidクライアントのダウンロード欄へ戻ります。

9章の切り分けを終えても特定できない場合は、「どの層で発生するか」「どの比較で結果が変わるか」「ログにどんなエラーが出るか」に圧縮します。例えば、「明示的なローカルプロキシは使えるがシステムプロキシは無効」「Wi-Fiではノードがタイムアウトするがモバイルネットワークでは正常」「サブスクリプションのダウンロードは成功するが解析結果が空」「画面ロック後にコアログが停止する」といった形です。その後ヘルプセンターで該当カテゴリを探すか、使い方ガイドに戻って最小構成を作り直します。体系的な調査の目的は設定を増やすことではなく、少ない変数で検証可能な結論を得ることです。