v2rayNの問題診断とトラブルシューティング大全

1. 接続済みなのにインターネットへ接続できない

まず問題が発生している層を確認する

「クライアントが実行中」と表示されるのは、ローカルのコアプロセスが起動したことを示すだけで、リモートノードに到達できることや、ブラウザーがプロキシを使用していることまでは意味しません。通信経路は、アプリケーション、システムプロキシまたはVPNインターフェース、ローカル待受ポート、ルーティングルール、DNS、リモートノード、接続先サイトの順に進みます。最初に行うべきことは接続ボタンを繰り返し押すことではなく、端末側とノード側のどちらで途切れているかを判断することです。まずクライアントのシステムプロキシまたはVPNを無効にし、通常のネットワークでよく使うサイトを開けるか確認します。直接接続自体が利用できない場合は、Wi-Fi、LANケーブル、ゲートウェイ、通信事業者の接続を先に修復してください。基本ネットワークが正常になったら、クライアントを再起動します。

続いてv2rayNで、設定が完全であることが分かっているノードを一つ選び、ルーティングを一時的にグローバルモードへ切り替えてシステムプロキシを有効にします。グローバルモードは診断専用です。複雑な分流ルールを一時的に回避できます。これでアクセスが復旧すれば、ノードとコアはおおむね正常で、問題はルーティングルール、DNS、バイパスリストに絞れます。それでも接続できない場合は、ローカル待受、ノードの接続性、アプリのプロキシ適用範囲を確認します。診断後は普段の利用に適したルーティングモードへ戻し、テスト状態をそのままにしないでください。

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

デスクトップクライアントは通常、ローカルループバックアドレス上でHTTP、SOCKS、または混合プロキシのポートを提供します。ポートが他のプログラムに使用されていると、コアの起動に失敗したり、起動後に接続を受け付けられなかったりします。v2rayNのログを開き、「address already in use」「bind failed」「failed to listen」など、意味の明確なエラーを探してください。ポート競合が見つかったら、そのポートを使用しているプログラムを終了するか、v2rayNの設定で未使用のポートへ変更してからコアを再起動します。ブラウザーのプロキシだけを変更してクライアントの待受ポートを無視しないでください。両方のポートを一致させる必要があります。

WindowsではPowerShellから、ポートが待受状態かどうかを確認できます。以下の例にあるポートは、クライアント画面に表示される実際のローカルポートへ置き換えてください。

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Test-NetConnection 127.0.0.1 -Port 10809

ポートが正常に待ち受けているのに特定のアプリだけ通信できない場合は、そのアプリがシステムプロキシに従うか確認します。独自のプロキシ設定を持つアプリ、起動時にだけシステムプロキシを読み込むアプリ、直接接続を確立するアプリがあります。独自のプロキシ設定があるアプリでは、127.0.0.1と対応するHTTPまたはSOCKSポートを明示して比較テストできます。明示的なプロキシは使えるのにシステムプロキシが効かない場合は、問題はノードではなく「システムプロキシが効かない」の章を確認してください。

最小構成でルーティングとDNSを切り分ける

複雑な設定でよくある問題箇所には、ドメインルールが先に直接接続へ振り分ける、宛先IPが誤ってブロックされる、DNSクエリが到達不能な出口へ送られる、サブスクリプションの統合後に無効な出力タグが残る、といったものがあります。診断時はカスタムルーティングを一時的に無効にし、プロキシ用の出力と直接接続用の出力を一つずつだけ残します。最小構成で動作したら、ルールをグループ単位で戻し、各グループを戻すたびに同じアドレス群でテストします。複数のルールセットを一度にインポートして、どれが原因か推測するのは避けてください。

ログは出力経路を判断する主な手がかりです。正常なリクエストでは、宛先ドメインまたはIP、選択された出力タグ、接続結果を確認できます。ログに新しいリクエストがまったくない場合、アプリの通信がクライアントへ入っていません。リクエストはあるのに直後に名前解決エラーが出る場合はDNSを確認します。リモートノードへの接続がタイムアウトする場合は次の章へ進みます。特定のドメインだけ失敗する場合は、まず分流とドメイン解決を確認してください。「ローカルポートへ入ったか、名前解決が完了したか、リモート接続を確立したか」の3点で判断すれば、曖昧な「ネットが使えない」を具体的な問題へ絞り込めます。

システム時刻も確認してください。TLSハンドシェイクには正確な日付、時刻、タイムゾーンが必要です。端末の時刻が大きくずれていると、証明書がまだ有効でない、または期限切れというエラーが発生します。OSの自動時刻合わせを有効にしたら、クライアントを完全に終了して再起動し、テストします。企業ネットワーク、学校ネットワーク、公共Wi-Fiでは、ポータルページでの認証が必要な場合もあります。その場合はまずプロキシを無効にし、ブラウザーでネットワーク認証を完了してからクライアントを有効にします。認証ページがプロキシに遮られると、すべてのWebページを開けないように見えることがあります。

2. ノードのタイムアウト、接続拒否、ハンドシェイク失敗

3種類の接続エラーを区別する

ノードテストに表示される「タイムアウト」「接続拒否」「ハンドシェイク失敗」は、異なる段階のエラーです。タイムアウトは通常、データパケットに規定時間内の応答がない状態で、サーバーへ到達できない、ポートがフィルタリングされている、回線でパケットロスがある、アドレス解決が誤っているなどの可能性があります。接続拒否は対象ホストには到達できるものの、そのポートでサービスが待ち受けていない状態で、ポートの入力ミスやサーバー未起動がよくある原因です。ハンドシェイク失敗はTCP接続後に発生し、プロトコルパラメーター、TLS、伝送方式、認証情報の不一致を示します。段階を先に区別してこそ、無意味な速度テストの繰り返しを避けられます。

クライアントの一覧にある一度きりの遅延テストだけに頼らないでください。TCP接続だけを確認し、プロトコルハンドシェイクを含まないテストもあります。また、特定のURLへアクセスするテストでは、DNSやルーティングの影響も受けます。実行ログを同時に確認し、デスクトップではサーバーアドレスとポートの基本的な到達性もテストしてください。Windowsでは次のコマンドを使用できます。

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443

ここでのnode.example.comは説明用のアドレスです。実際には設定にあるサーバーのドメインを入力してください。ドメインを解決できない場合はDNSを先に確認します。解決結果は得られるのにTCPテストが失敗する場合は、ネットワーク経路、ポート、サーバー状態を確認します。TCPは成功するのにクライアントのハンドシェイクが失敗する場合は、UUID、パスワード、プロトコル種別、伝送方式、TLSの有効化、SNI、Host、パス、REALITYパラメーターを重点的に確認してください。

プロトコルパラメーターを一つずつ照合する

VMess、VLESS、Trojanなどの設定は、サーバーアドレスとポートだけを比較してはいけません。プロトコルの各項目を一体として一致させる必要があります。VLESSを例にすると、ユーザー識別子、フロー制御方式、セキュリティ層、伝送方式、サーバー名には相互関係があります。REALITYでは対応する公開鍵、ショートID、サーバー名も必要です。WebSocketでは正しいパスとHost、gRPCではサービス名の一致が必要です。TLS接続のSNIは、サーバー証明書と入口設定に一致させます。サブスクリプション変換ツールが項目を途中で切り詰めると、TCP成功直後にハンドシェイクが失敗することがあります。

ノードを手動編集する場合は、経験で項目を補うのではなく、提供元の完全な元設定と一項目ずつ照合してください。大文字・小文字、先頭のスラッシュ、空白、不可視文字も差異の原因になります。UUIDやキーをコピーしたら、まずプレーンテキストエディターに貼り付け、前後の空白を確認してからクライアントへ入力します。QRコードや共有リンクからインポートした場合も、ノード詳細を開いて再確認してください。古い形式では新しい伝送項目を保持できない場合があります。同じノードが一方の端末では使えて別の端末では使えない場合、両端のプロトコル詳細を並べて比較するほうが、再インポートより効果的です。

回線、ネットワーク、サーバー側の問題を見分ける

同じ設定がモバイルネットワークでは接続でき、家庭用ブロードバンドではタイムアウトする場合、クライアント設定は有効であることが多く、ローカルネットワーク、ルーター、DNS、上流経路を確認すべきです。逆に、すべてのネットワーク環境で同じ段階に失敗するなら、サーバー側の異常やパラメーター不一致の可能性が高くなります。スマートフォンのテザリングでデスクトップを接続して比較することも、Android端末でWi-Fiとモバイルデータを切り替えることもできます。テスト中はノード、クライアントのルーティングモード、DNS設定を固定し、接続ネットワークだけを変更してください。

ノードアドレスがドメインの場合は、ネットワークによって解決先IPが変わっていないかも確認します。CDN、デュアルスタック解決、ローカルDNSキャッシュにより、2台の端末が異なるアドレスへ接続することがあります。nslookupまたはResolve-DnsNameで結果を記録し、クライアントログの実際の宛先IPと照合してください。ドメインがIPv4とIPv6を同時に返し、現在のネットワークのIPv6経路が不完全だと、接続が長時間待機してからフォールバックすることがあります。この場合は一時的にIPv4優先で検証できますが、根拠なしにシステムのIPv6機能を恒久的に無効化しないでください。

ログに証明書名の不一致、未知の認証局、ハンドシェイクプロトコルの不一致が出ても、「証明書検証をスキップする」ことを通常の解決策にしないでください。まず端末時刻、SNI、サーバー名、TLS設定を確認します。検証を一時的に無効化するのは、問題が証明書チェーンにあるか確認する場合に限り、確認後は必ず元に戻して設定を修正してください。サブスクリプション由来のノードは、まず完全な設定を再取得します。複数のクライアントで同じハンドシェイクエラーが出る場合は、クライアント側で無関係な項目を何度も変えるのではなく、設定提供元にサーバー側の入口を確認してもらう必要があります。

ノードのタイムアウトは、ローカルのセキュリティソフトがコアプロセスを遮断したり、新しい外向き接続を禁止したりして起こることもあります。すべての保護機能をいきなり無効にするのではなく、遮断履歴を確認し、v2rayNが使用するコアプログラムに現在のネットワークへのアクセスが許可されているか確認してください。クライアントのディレクトリを移動したり、コアファイルのパスが変わったりすると、以前のルールが一致しなくなることがあります。現在の実際のパスを再許可してからクライアントを再起動します。確認後は実際のWebページとファイル転送で検証してください。「遅延テスト成功」と表示されるだけでは、通信経路全体が正常とは限りません。

3. サブスクリプション更新失敗、ノードが空、内容が変わらない

リクエスト失敗か解析失敗かを先に判断する

サブスクリプション更新には、ダウンロードと解析の2段階があります。リクエスト失敗ではクライアントがサブスクリプション本文を取得できず、ログにはタイムアウト、名前解決失敗、接続拒否、HTTPステータス異常などが表示されます。解析失敗ではリクエスト自体は成功していても、返された内容がクライアント対応の形式ではなく、ノード数が変わらない、ノード一覧が空、形式エラーが表示されるといった結果になります。トラブルシューティングでは一覧の結果だけで判断せず、まず更新ログを確認してください。2種類の問題では対処方法がまったく異なります。

まずサブスクリプションURLが完全か確認します。URL内のクエリパラメーター、大文字・小文字、特殊文字は認証情報の一部である場合があります。末尾の文字が欠けるだけでも無効になります。以下のURLは構造説明用であり、実際のサブスクリプションには使用できません。

https://example.com/subscription?token=xxxx&client=v2rayN

URLをチャットツールや文書経由で共有すると、自動改行や句読点の追加が起こることがあります。サブスクリプショングループの設定に貼り直し、前後に空白がないか確認してください。Web管理画面のURL、ノード共有ページ、ログインページをサブスクリプションURLとして使わないでください。ブラウザーでページを開けても、返された内容がクライアントで解析できるとは限りません。逆に、ブラウザーに長いエンコード文字列が表示されるのは、正常なサブスクリプション応答である場合が多く、内容が壊れているとは限りません。

更新リクエストをプロキシ経由にするか決める

サブスクリプションサーバーへの経路は、ノード通信の経路と異なる場合があります。クライアントでは通常、更新時に直接接続、現在のプロキシ、システムプロキシのいずれかを選択できます。直接接続がタイムアウトするのに既存ノードは接続できる場合、更新を現在のプロキシ経由へ切り替えます。プロキシノード自体が無効な場合、プロキシ経由の更新を強制すると循環状態になるため、直接接続へ戻すか、先に利用可能なノードをインポートしてください。複数の項目を無作為に切り替えるのではなく、ログで実際にどの出口を通ったかを確認するのが原則です。

初回インストール直後で一覧が空の場合、更新に使える既存のプロキシがありません。まず現在の基本ネットワークからサブスクリプションURLへアクセスできるか確認してください。既存ノードがある場合は、実際に利用可能なノードを選んでから更新します。更新後は、サブスクリプショングループの最終更新時刻、ノード一覧の変化、エラーログを確認します。手動更新は成功するのに自動更新が失敗する場合は、自動更新間隔、端末のスリープ、クライアントの常駐状態、更新タスクの開始時点でプロキシコアが準備できていたかを重点的に確認してください。

更新リクエストがプロキシを経由しない、リンクが無効、タイムアウト、形式異常といった分岐については、v2rayNのサブスクリプション更新に失敗する6つの原因と自動更新の設定方法も参照してください。この記事は自動更新設定を中心に扱い、この章ではログから障害の段階を切り分けます。

形式、キャッシュ、グループの上書きを確認する

一般的なサブスクリプション内容には、base64でエンコードされた共有リンクの集合、1行ごとの共有リンク、ネイティブJSON設定があります。クライアントやコアによって対応する項目の範囲は完全には同じではありません。v2rayNのサブスクリプションには一般的な複数のノード形式を含められますが、v2rayNGとv2flyNGではコアの能力やインポート項目に違いがある場合があります。サーバーがWebページのHTML、ログイン案内、エラーJSON、空のテキストを返している場合、クライアントはノードサブスクリプションとして解析できません。応答の実際の種類を確認し、アカウント状態とサブスクリプション入口も確認してください。

ログ上はダウンロードと解析が成功しているのに一覧が変わらない場合は、サブスクリプショングループのフィルター、別名の上書き、重複排除の設定を確認します。現在のグループだけを表示する、キーワードで絞り込む、備考名で重複排除するといった設定により、新しいノードがインポート済みでも画面上で非表示になることがあります。まず検索欄を空にし、完全なサーバー一覧へ切り替えてから対象グループを確認してください。すぐに古いノードをすべて削除せず、現在の設定をエクスポートするかグループを複製してから上書き更新を実行します。これにより、内容が変わっていないのか、クライアントの統合方式が差分を隠しているのか判断できます。

サブスクリプションキャッシュによって、「更新成功なのに古い内容のまま」になることもあります。クライアントを完全に終了し、再起動してから手動更新してください。キャッシュを削除する、またはキャッシュを使わない設定がある場合は、バックアップ後に実行します。システムプロキシが現在のクライアントを指している場合、コア停止中にブラウザーでサブスクリプションへ接続できるか判断するのは避けてください。ブラウザーのリクエストが、停止済みのローカルポートへ向かう可能性があります。まずシステムプロキシを無効にして直接接続を確認し、その後に比較してください。

ログの表示	主な判断	優先する操作
名前解決に失敗	サブスクリプションのドメインから有効なアドレスを取得できない	システムDNS、プロキシDNS、ネットワーク接続を確認
接続がタイムアウト	リクエスト経路または対象ポートに到達できない	直接接続または現在のプロキシへ切り替えて比較
Webページのテキストが返る	URLがログインページまたはエラーページを指している	完全なサブスクリプション入口を再取得
解析成功だが一覧が変わらない	内容の未変更、フィルター、重複排除	フィルターを解除してサブスクリプショングループを確認

自動更新間隔を短くしすぎないでください。高頻度のリクエストでノード品質が上がるわけではなく、サーバーのレート制限にかかりやすくなり、ネットワーク切り替えや端末復帰時にタスクが重複することもあります。サブスクリプションの実際の更新頻度に合わせて適切な周期を設定し、必要なときだけ手動更新してください。更新後、一部の新しいプロトコルのノードだけ使えない場合は、ノード詳細の項目を確認し、選択したクライアントのコアが対応設定をサポートしているか確認します。形式の違いについては、V2Rayサブスクリプション形式と変換方法の解説を参照してください。

4. 接続できるのにWeb閲覧やダウンロードが遅い、速度が変動する

遅延、スループット、安定性を分けて測定する

遅延が低いからといってダウンロード速度が高いとは限りません。遅延は1往復にかかる時間を示し、スループットは回線容量、混雑、パケットロス、サーバー負荷、TCPの動作に左右されます。安定性は、継続接続中に揺らぎや再送が頻発するかどうかを表します。クライアントのノード一覧に表示されるテスト結果は初期選別に使えるだけで、実際のアクセスの代わりにはなりません。速度問題を診断するときは、同じ端末、同じ接続ネットワーク、同じ時間帯、同じ対象を固定し、直接接続、1つのノード、別のノードを個別に比較してください。対象サイト自身の負荷をクライアントの障害と誤認しないことが重要です。

他のダウンロード、クラウド同期、システム更新、動画再生を停止してから、通常のWebページの初回表示、連続画像の読み込み、合法的なファイルのダウンロードをテストします。同じネットワークですべてのノードが遅く、スマートフォンのテザリングに切り替えると改善する場合は、ローカル回線、Wi-Fi干渉、ルーター性能、上流経路を優先して確認します。1つのノードだけ遅い場合は、ノードの回線または負荷の問題であることが多いです。ブラウザーは速いのに特定のアプリだけ遅い場合は、そのアプリが同じプロキシを使用しているか、UDPを使っているか、独自DNSや接続数制限がないかを確認してください。

ルーティングによる迂回を確認する

分流ルールの誤りにより、本来は直接接続に適した通信がリモートノード経由になったり、プロキシが必要なリクエストがまず直接接続を試してタイムアウト後にフォールバックしたりします。どちらもページの初回表示を遅くします。ログで遅いリクエストが最終的にどの出力タグへ振り分けられたかを確認し、特にドメインルール、IPルール、デフォルトルールの順序を確認してください。ルーティングは通常、上から下、またはコアで定められた優先順位で評価されます。範囲が広すぎるルールが後続の詳細ルールを隠すこともあります。変更前に既存のルールセットを複製し、少数のドメインで検証してください。設定全体をいきなり書き換えないでください。

分流構造を理解するための簡略化したルール例を示します。この断片はgeositeとデフォルト出力の関係を示すもので、実際のタグ名はクライアントに存在する出力名と一致させる必要があります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategyは、ドメインのマッチングと名前解決の関係を決めます。AsIsを使うと、まず元のドメインルールに従って処理し、不要な先行解決を避けられます。IPルールで分流する場合、コアが後の段階で名前解決を行うことがあります。すべてのネットワークに適した設定はないため、ルール構造に応じて選択してください。変更後は設定を再読み込みし、ログで新しいルールが有効になったことを確認します。

MTU、UDP、多重化を確認する

Webページは開けるのに大きなファイルが止まる、動画が断続的にバッファリングする、一部のリクエストだけ長時間停止するといった場合は、経路MTUが関係している可能性があります。VPNインターフェース、トンネル、一部の接続ネットワークではカプセル化のオーバーヘッドが増えます。大きなパケットを正しく分割できないと、小さなリクエストは正常なのに大きな転送だけ異常になります。デスクトップでは、まずシステムプロキシモードと仮想NICモードを比較します。システムプロキシは正常で仮想NICモードだけ異常なら、そのモードのMTU、ドライバー、ルーティングテーブルを確認してください。経験だけでMTUを極端に下げず、段階的に調整しながら大容量転送の安定性を観察します。

UDPはDNS、リアルタイム通信、一部の新しい伝送方式で重要ですが、ノードやネットワークによって対応状況が異なります。UDPを有効にしてから断続的な問題が出た場合は、まずアプリ層で本当に必要か確認し、コアログにUDPタイムアウトがないか確認してください。特定アプリのUDPだけを無効にすることと、UDPを全体で無効にすることは別の操作です。後者はDNSや他のプログラムの動作も変える可能性があります。QUICを使うWebページでは、UDPが不安定なときにブラウザーがフォールバックし、初回表示だけ遅く、その後は正常になることもあります。

多重化は、一部の環境で接続確立の繰り返しを減らせますが、設定値を大きくすれば速くなるわけではありません。パケットロスが目立つ回線では、多くのリクエストが1本の接続を共有することで互いに影響することがあります。サーバー側が同じ方式に対応していない場合は、ハンドシェイクに失敗することもあります。速度変動を調べるときは、同時実行数、キャッシュ、DNS、伝送プロトコルを一度に変更せず、まず多重化を一時的に無効にして比較します。無効化で安定性が向上したら、ノードのサーバー側能力に応じて再有効化するか判断してください。

端末のリソースと無線ネットワークを確認する

コアは暗号化、復号、ルーティング判定、ログ書き込みを行います。古い端末、省電力モード、大量の詳細ログがスループットを制限することがあります。転送中にCPU、メモリ、ディスク使用率を確認します。1つのコアが高負荷を継続している場合は、端末側の処理がボトルネックかもしれません。リソース使用率が低いのにネットワークスループットが周期的にゼロになる場合は、回線のパケットロス、無線干渉、サーバー混雑の可能性が高いです。Android端末では省電力設定やバックグラウンド制限の影響も受けます。詳細はモバイル端末の章を参照してください。

Wi-Fiの電波マークだけでは、回線品質を完全には判断できません。同一周波数帯の干渉、ルーターの過熱、端末との距離、自動バンド切り替えが揺らぎを引き起こします。可能ならまず有線でテストしてください。無線しか使えない場合はルーターに近づき、他の端末による大容量通信を一時停止します。毎日決まった時間帯だけ遅くなり、クライアント設定に変化がないなら、時間帯、接続ネットワーク、ノードの違いを記録してください。クライアントを何度も再インストールするより、複数回の低干渉な比較データを集めるほうが、安定性問題の判断に役立ちます。

5. DNS解決失敗、ドメイン汚染の兆候、アドレス不一致

ドメインの問題か接続の問題かを判断する

DNS障害は、Webページにサーバーが見つからないと表示される、ログに名前解決失敗が出る、同じノードがIPでは接続できるのにドメインではタイムアウトする、一部のドメインが誤ったアドレスへ接続される、といった形で現れます。まず「解決結果がない」のか「利用できないアドレスへ解決された」のかを区別してください。前者はDNSサーバーに到達できない、プロキシDNSの設定ミス、システムキャッシュの異常などが原因です。後者はキャッシュ、分流ポリシー、IPv4とIPv6の優先順位、DNSごとの応答差が関係することがあります。DNSアドレスをいくつも変更するだけでは原因を説明できません。まず現在の解決結果を記録してください。

Windowsでは、次のコマンドでシステムによる解決結果と、指定した種類の応答を確認できます。

nslookup node.example.com
Resolve-DnsName node.example.com -Type A
Resolve-DnsName node.example.com -Type AAAA
ipconfig /displaydns

macOSとLinuxではnslookupを使用できます。環境によってはdigも利用できます。クライアントログの宛先IPと比較し、リクエストがシステムDNS、クライアント内蔵DNS、リモート解決のどれを使っているか判断してください。コマンドラインでは正常なのにクライアントログで名前解決に失敗する場合は、クライアントのDNS設定と出力タグを重点的に確認します。システムとクライアントの両方で失敗する場合は、ネットワークが提供するDNS、ルーターの転送、本体のファイアウォールを先に確認してください。

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

システムプロキシは主にアプリのHTTPまたはSOCKS通信を転送しますが、アプリが行うDNSクエリまで自動的にプロキシ経由になるとは限りません。ブラウザーによっては独自のセキュアDNSを使い、別のプログラムはシステム解決を直接呼び出します。SOCKSクライアントも、ドメインをローカルで解決してIPだけをプロキシへ渡すことがあります。そのため、同じ端末でもアプリによって異なるアドレスが返されます。トラブルシューティングでは、アプリがプロキシへ渡しているのがドメインか、すでに解決済みのIPかを確認し、ブラウザー内蔵DNSの設定がシステムポリシーを上書きしていないか確認してください。

仮想NICモードは通常、より広い範囲の通信を引き継げますが、正しいDNSハイジャック、ルーティング、除外ルールが必要です。有効にした後すべてのドメインで失敗し、IPへの直接アクセスには応答がある場合、仮想インターフェースは通信を引き継いでいるものの、DNSリクエストが利用可能なリゾルバーへ届いていません。クライアントが生成したDNSインバウンド、仮想アドレス範囲、ルーティングテーブルを確認し、DNSサーバー自体が誤った出力を再び経由してループしていないか確認します。仮想NIC関連の設定を変更したら、コアを停止してインターフェースが解放されるまで待ち、その後に再起動してください。

リモート解決は、プロキシ出口にドメインのアドレスを決めさせたい場合に適しています。ローカル解決は、ローカルネットワークに応じた近いアドレスを返すサービスに向いています。どちらが常に優れているわけではありません。ルーティングルールが先にドメインで出力を決める場合は、通常、元のドメイン情報を保持します。IPセットに依存するルールでは、適切な段階で解決する必要があります。複数のDNSサーバーを設定する場合は、各サーバーの対象ドメイン、クエリの出口、失敗時のフォールバックを明確にし、直接接続とプロキシの間でクエリが循環しないようにしてください。

キャッシュ、IPv6、Fake DNSを確認する

DNSを変更しても、OS、ブラウザー、クライアントに古いレコードが残っていることがあります。Windowsではipconfig /flushdnsを実行してシステムキャッシュを消去し、その後ブラウザーとクライアントを完全に終了してからテストします。消去できるのはキャッシュだけで、誤ったルーティングやDNS設定は修復されません。レコードがすぐに再び誤る場合は、実際のクエリ経路を確認してください。ブラウザー自身のキャッシュとセキュアDNSも個別に確認する必要があります。

デュアルスタックネットワークでは、ドメインがAレコードとAAAAレコードを同時に返すことがあります。システムはネットワーク状態とアドレス選択ポリシーに基づいて接続順序を決めます。ルーターがIPv6を通知していても上流接続が不完全だと、アプリはIPv6のタイムアウトを待ってからIPv4へ戻るため、ページの初回表示が遅くなることがあります。AとAAAAを個別に問い合わせ、ログで実際に試行されたアドレスを確認してください。一時的なIPv4優先は検証に使えますが、最終的にはルーターのIPv6、プロキシ出力、クライアントのドメインポリシーを修正し、問題を恒久的に隠さないようにします。

Fake DNSはアプリに予約アドレスを返し、クライアントが元のドメインへ復元してルーティングします。仮想NICによる引き継ぎに適していますが、予約アドレスのプールがLAN、社内ネットワーク、他のVPNと競合しないことが前提です。有効化後にLAN機器へ到達できない、特定アプリが異常なアドレスを検出する、再起動後に以前のマッピングが無効になる場合は、アドレスプール、除外ドメイン、キャッシュの有効期間を確認してください。LANプリンター、ルーター管理用ドメイン、社内業務ドメインは、実際のネットワークに応じてローカル解決または直接接続に設定する必要があります。

症状	考えられる層	確認方法
ドメインは失敗するがIPには到達できる	DNSクエリまたはドメインルーティング	システムの解決結果とクライアントログを比較
初回表示は遅いが、その後は正常	解決のフォールバックまたはIPv6待機	AレコードとAAAAレコードを個別に確認
仮想NICを有効にするとすべての解決に失敗する	DNSハイジャックまたはルーティングループ	DNSインバウンドとクエリの出口を確認
LANドメインが予約アドレスを指す	Fake DNSの除外ルール	内部ドメインをローカル解決に設定

DNSを修復したら、ノードのドメイン、通常のWebサイトのドメイン、LANのドメインを同時にテストします。公開サイトを1つ確認するだけでは、サブスクリプション更新、ノード入口、ローカル機器へのアクセスを網羅できません。特定のアプリだけで問題が起きる場合は、そのアプリが独自DNSを有効にしていないか確認します。複数の端末が同じルーターで同じ症状を示す場合は、ルーターのDNS転送とIPv6を優先して確認します。クライアントを有効にしたときだけ異常になる場合は、コアのDNS、ルーティング出力、仮想インターフェースを順番に確認してください。

6. システムプロキシは有効なのにブラウザーやアプリで使えない

OSのプロキシ値を確認する

v2rayNの「システムプロキシ」スイッチは、OSのプロキシアドレスをローカル待受ポートへ向けます。コアの実行状態とシステムプロキシは別々の状態です。コアが起動していてもシステムプロキシが無効なら、明示的にプロキシを設定したアプリだけがクライアントを経由します。システムプロキシが設定されていてもコアが停止していれば、アプリはサービスのないローカルポートへ接続します。コアの実行状態、ローカルポートの待受、システムプロキシのアドレスを同時に確認してください。

Windowsではシステムのネットワークプロキシ設定から手動プロキシのアドレスとポートを確認できます。PowerShellで現在のユーザーに関する設定を確認することも可能です。重要なのはレジストリの場所を覚えることではなく、画面に表示されるポートがv2rayNの実際の待受ポートと一致しているか確認することです。設定を切り替えてポートが変わった場合、古いシステムプロキシが以前のポートを指し続けることがあります。いったんシステムプロキシを無効にし、クライアントから再度有効にするほうが、複数箇所を手動で変更するより確実です。

macOSのプロキシ設定はネットワークサービスごとに保存されるため、Wi-Fiと有線ネットワークで別々の設定になる場合があります。接続方式を切り替えた後、クライアントが以前のネットワークサービスだけを更新していると、新しい接続ではプロキシが使われません。Linuxデスクトップ環境ではシステムプロキシの対応に差があります。デスクトップ設定を読むアプリ、環境変数を読むアプリ、独自のネットワーク設定だけを使うアプリがあります。そのため「システムプロキシが有効」でも、すべてのデスクトップアプリが自動的に従うとは限りません。

ブラウザーのキャッシュと独自プロキシ設定を確認する

ブラウザーは通常システムプロキシを読み込みますが、拡張機能、企業ポリシー、セキュアDNS、起動パラメーターがシステム設定を上書きすることがあります。ブラウザーでプロキシが効かない場合は、追加拡張機能を読み込まない一時プロファイルを作って比較するか、ブラウザーのネットワーク設定に別のプロキシが明示されていないか確認します。システムプロキシを変更した後はブラウザーを完全に終了して再起動してください。起動時にだけプロキシを読み込むプログラムもあります。新しいプロファイルで使える場合、問題はv2rayNのノードではなく元のブラウザー設定にあります。

コマンドラインでローカルプロキシを明示し、コアがリクエストを受け付けるか確認できます。以下のポートは例なので、クライアントの実際のHTTPポートに置き換えてください。

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

明示的なプロキシでは成功するのにブラウザーが失敗する場合、ノード、コア、ローカル待受は正常で、OSがプロキシを読み込む経路を確認すべきです。両方のコマンドが失敗する場合は、クライアントログにリクエストが届いているか確認します。ログがまったく増えないならポートまたはセキュリティソフトの問題であることが多く、リクエストはあるのに接続に失敗するなら、ノード、DNS、ルーティングの章へ戻ります。--socks5-hostnameを使うと、ドメインはSOCKSプロキシ側で解決されるため、ローカル解決との比較に利用できます。

バイパスリストとPACの動作を理解する

システムプロキシには通常、ローカルアドレス、LANのサブネット、特定ドメインをプロキシから除外するリストがあります。範囲が広すぎるバイパスルールがあると、対象リクエストが直接接続され、プロキシが効いていないように見えます。ワイルドカードが広すぎないか、ドメインサフィックスを誤っていないか、テストサイトを直接接続リストに含めていないか確認してください。LANアドレスは通常プロキシをバイパスする必要がありますが、範囲は実際のネットワークに合わせるべきです。バイパス項目をすべて削除するのは長期的な解決策ではありません。ルーター管理画面、プリンター、内部サービスに影響する可能性があります。

PACモードでは、スクリプトが各リクエストをプロキシ経由にするか直接接続にするか決めます。ブラウザーがPACファイルをキャッシュしている場合や、スクリプトのURLに到達できない場合は、直接接続へフォールバックすることがあります。診断時に固定のシステムプロキシへ一時的に切り替え、すぐ復旧するなら、PACの取得、キャッシュ、マッチングルールに問題があります。修正後はPACへ戻し、プロキシ対象ドメイン、直接接続対象ドメイン、LANアドレスの3種類を検証します。システムプロキシ、グローバルモード、バイパスルールの関係は、システムプロキシ、グローバルモード、バイパスモードの違いを詳しく解説で確認できます。

権限、残留状態、プロキシループを確認する

クライアントが異常終了すると、システムプロキシの設定だけが残ることがあります。次回起動時に別のポートを使うと、ブラウザーは古いアドレスへ接続し続けます。「終了後にネットへ接続できない」場合は、まずシステム設定で手動プロキシを無効にし、自動構成スクリプトがまだ有効でないか確認します。その後クライアントを起動し、コアが正常であることを確認してからクライアントに再設定させてください。複数のプロキシクライアントにシステムプロキシを同時管理させると、設定が交互に上書きされ、状態と画面表示が一致しなくなることがあります。

プロキシループは、クライアントがサブスクリプション更新、ネットワーク確認、ルールのダウンロードを行う際に、無効になった自身のシステムプロキシを再び経由してしまうことで発生します。ログにはローカルポートへの再接続、応答のないリクエスト、コア停止後にすべてのネットワーク操作が失敗するといった症状が現れます。各内部リクエストが直接接続と現在のプロキシのどちらを使うか明確にし、クライアント起動前にまだ構築されていない出口へ依存しないようにします。ノード切り替え時も、新しいコアの待受が完了してからプロキシが必要な操作を実行してください。

システムプロキシに対応しないアプリや、HTTP通信だけをプロキシするアプリもあります。そのようなプログラムでは、アプリ自身の設定にSOCKSまたはHTTPのアドレスを入力するか、対応するデスクトップ環境で仮想NICモードを使って通信を引き継ぎます。仮想NICモードへ切り替える前に、権限、DNS、ルーティングへの影響を理解してください。これはシステムプロキシ問題に対する万能スイッチではありません。1つのプログラムだけに問題がある場合は、そのプログラムのドキュメントでプロキシ対応を確認します。すべてのプログラムで問題がある場合は、OS層とクライアント層を確認してください。

7. クライアントが起動しない、コアが終了する、頻繁にクラッシュする

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

v2rayNはグラフィカルインターフェースで設定を管理し、XrayまたはV2Flyコアを呼び出して通信を処理します。画面は開けるのに接続直後に停止する場合は、コアの起動失敗であることが多いです。画面自体が開かない、ウィンドウがすぐ閉じる、設定画面がクラッシュする場合は、実行環境、設定ファイル、権限、画面関連コンポーネントを確認します。両者ではログの場所と修復方法が異なります。まず、クラッシュが「クライアントを開く」「コアを起動する」「サブスクリプションを読み込む」「転送を開始する」のどの段階で起きたか記録してください。

画面を操作できる場合は、まずログディレクトリを開き、今回の起動前後のエラーを保存します。コアの代表的な起動エラーには、JSON構文エラー、存在しない出力タグ、ポート競合、ルールファイルの読み込み失敗、未対応の設定項目があります。最後の1行だけを抜き出さないでください。根本原因は、前段の設定解析に出ていることが多いです。ログが詳細すぎる場合は、レベルを一時的にwarningまたはinfoへ変更し、もう一度再現します。大量の正常な接続記録で重要なエラーが埋もれるのを防げます。

生成された設定が完全か確認する

ルーティングを手動で追加したり、古い設定から移行したりした後は、カンマ、引用符、括弧の誤りによりコアが起動を拒否することがあります。標準JSONではコメントは使用できず、配列の最後の項目の後に余分なカンマを置くこともできません。以下は階層を理解するための、構造が完全な最小例です。既存のノード設定を直接置き換えるためのものではありません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

クライアントが生成済み設定を表示できる場合は、ログが示したフィールドパスを重点的に確認します。カスタム断片で、クライアントがすでに生成しているトップレベルオブジェクトを重複定義しないでください。また、存在しないoutboundTagを参照しないでください。別のクライアントから設定をコピーする場合は、移行先のコアが同じ項目に対応しているか確認します。XrayとV2Flyには共通する基盤がある一方、対応能力には違いもあります。コアの違いは、XrayコアとV2Flyコアの違いを比較で確認できます。

権限、パス、セキュリティソフトの遮断を確認する

クライアントのディレクトリに書き込み権限がないと、設定の保存、コアファイルの更新、ログの書き込みに失敗することがあります。デスクトップでは、現在のユーザーが通常どおり読み書きできる場所にクライアントを置き、テンポラリディレクトリや自動削除対象の場所は避けてください。管理者権限での起動に長期的に依存しないでください。通常権限で失敗する場合は、具体的にどのファイルや操作が拒否されたかを確認してからディレクトリ権限を修正します。高い権限で実行すると設定ファイルの所有者が変わり、その後の通常起動でも失敗し続けることがあります。

セキュリティソフトが、新しくダウンロードしたコアプロセスの実行を阻止したり、更新後の新しいファイルを未許可のプログラムとして扱ったりすることがあります。システムのセキュリティ履歴と隔離履歴を確認し、実際に遮断されたファイルのパスを特定してください。信頼できる現在のインストールディレクトリだけに、必要な実行権限とネットワーク権限を設定します。保護機能全体を無効にしないでください。v2rayNの画面は正常に起動するのにコアファイルがすぐ消える場合は、まず隔離ルールを処理し、その後Windowsダウンロード入口からクライアントを再取得してください。

パスに特殊文字が含まれる、同期ドライブ上のプレースホルダーファイルを使っている、ディレクトリ階層が長すぎるといった場合、外部コアやルールファイルを正常に読み込めないことがあります。クライアントを短く安定した、ユーザーが書き込めるディレクトリへ移して比較してください。移動前にプログラムを終了し、移動後にコアのパスを再選択します。サブスクリプション、ログ、ルールのディレクトリが古い場所を指していないかも確認してください。実行中にディレクトリを移動すると、画面の保存先とコアの作業ディレクトリが一致しなくなります。

すべてのデータを失わずに壊れた設定を復元する

サブスクリプション更新やルーティング変更の直後に画面がクラッシュする場合は、まず設定ディレクトリ全体をコピーしてバックアップします。その後、最近変更したカスタムルール、画面状態ファイル、単一のサブスクリプショングループを一つずつ別の場所へ移します。復元は最小限の変更から始め、設定をすべて削除しないでください。再び開けるようになったら、サーバーとルーティング設定を一つずつインポートし、毎回再起動して確認します。これにより、破損したファイルを特定し、他の正常なデータを残せます。

クライアントの頻繁なクラッシュは、メモリ不足、巨大なルールセット、ログの継続的な肥大化が原因になることもあります。クラッシュ前のメモリ、ディスク空き容量、ログサイズを確認してください。重複ルールが多いと起動時の解析時間が増え、カスタムドメインリストに異常に長い行があると負荷が増すこともあります。重複項目を削除し、用途別にルールを分け、必要なログだけを残します。大量の接続を転送したときだけクラッシュする場合は、アプリの同時実行数を下げて比較し、システムがリソース制限によってプロセスを終了していないか確認してください。

発生した段階	重点確認項目	保存する資料
画面を開く前	実行環境、設定ディレクトリ、画面状態	システムイベントと起動ログ
コアの起動時	設定構文、ポート、コアのパス	コア冒頭のエラーログ
サブスクリプション読み込み時	異常なノード項目、グループ、キャッシュ	サブスクリプション更新ログ
大量転送時	リソース使用率、ルール規模、同時実行数	リソース監視結果とクラッシュ時刻

復元後は、「画面の起動、コアの待受、単一ノードの接続、サブスクリプション更新、カスタムルーティング」の順に機能を段階的に戻します。各段階で正常に動作することを確認してから次へ進んでください。特定のカスタム断片だけでエラーが出る場合は、現在のコアが対応する項目に基づいて書き直し、古いクライアントが出力した完全設定をそのまま使い続けないでください。再インストールが必要な場合は、ダウンロードセンターから現在のプラットフォーム用パッケージを選び、古いデータをインポートする前に空の設定で正常に起動できることを確認します。

8. Androidで接続が切れる、バックグラウンドで停止する、アプリ分流が効かない

VPN権限とシステムの競合を確認する

v2rayNGとv2flyNGは通常、AndroidのVPNインターフェースを使ってアプリの通信を引き継ぎます。初回接続時にはシステムのVPN許可が表示されます。許可していない、許可が取り消された、別のVPNが使用中といった場合、クライアントはインターフェースを構築できません。ステータスバーにVPNアイコンが表示されても、インターフェースの存在を示すだけです。クライアントログでコアが起動し、選択したノードを読み込んでいることも確認してください。接続をタップするとすぐ切断される場合は、別のVPNが動作中でないか確認し、仕事用プロファイル、企業管理、セキュリティアプリがVPN権限を制限していないか確認します。

Androidでは通常、同時に1つの主要なVPNサービスしか使えません。広告ブロッカー、企業VPN、ネットワーク高速化ツール、他のプロキシクライアントがv2rayNGやv2flyNGと競合することがあります。最近のタスク一覧から画面を消すだけでなく、VPNインターフェースを使用している他のアプリを完全に停止してください。システム設定の「常時接続VPN」や「VPNを使用しない接続をブロック」もクライアント切り替えに影響します。常時接続が別のアプリに固定されていると、新しいクライアントが権限を取得できない場合があります。

クライアントを選ぶ際、v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを基盤としています。一般的な設定には共通部分がありますが、一部のプロトコルや伝送項目の対応が異なります。サブスクリプションのインポート後、特定のノードだけ接続できない場合は、そのノードが特定のコア機能に依存していないかを先に確認してください。同じ設定を2つのクライアント間で無条件にコピーしないでください。インストールまたはパッケージ変更が必要な場合は、Androidダウンロード入口へ進みます。

省電力設定とバックグラウンド制限を確認する

画面ロック後に接続が切れる、アプリを切り替えるとすぐ使えなくなる場合は、通常、バッテリー最適化やバックグラウンド制限が関係しています。システムがクライアントプロセスを停止したり、バックグラウンド通信を制限したり、VPNサービスを回収したりすることがあります。アプリのバッテリー設定でバックグラウンド動作を許可し、端末が提供する設定に応じてクライアントへの厳しい省電力制限を解除してください。一部の端末には自動起動、バックグラウンド表示、タスク固定の設定もあります。「VPNサービスを継続実行できる」ことを目標にし、ネットワークと無関係な権限まで有効にする必要はありません。

省電力設定を変更したら、クライアントを再起動して完全なテストを行います。画面をオンにしたまま一度アクセスし、数分間ロックしてから再度アクセスし、その後Wi-Fiとモバイルデータを切り替えます。ロック中だけ失敗するなら、引き続きバックグラウンドポリシーを確認します。ネットワーク切り替え後に失敗するなら、VPNインターフェースが再構築されていない、古いDNSキャッシュが更新されていない、ノード接続が再確立されていない可能性があります。ログにネットワーク喪失後の新しいデフォルトネットワークがないと表示される場合、クライアントがシステムのネットワーク変化を適時取得できていません。

システムのメモリが不足すると、バックグラウンドプロセスも回収されることがあります。常駐アプリ、ゲーム、ブラウザーのタブが多いほど、その可能性は高まります。中断時にクライアントの通知が消えるか確認してください。通知が消えるならサービス自体が停止した可能性が高く、通知が残っているのにアクセスできないなら、トンネル、DNS、ノード接続が切れた可能性が高いです。常時表示通知を有効にすると、システムがVPNサービスをフォアグラウンドタスクとして扱いやすくなり、サービス停止と経路障害を区別しやすくなります。

アプリ分流とバイパス設定を確認する

Androidクライアントでは、アプリごとにVPNを経由する、VPNをバイパスする、選択したアプリだけをプロキシする、といった設定ができます。リスト設定を誤ると、ブラウザーは使えるのに他のアプリが直接接続する、または一部のアプリだけ通信できないといった症状が出ます。まずアプリごとの分流を一時的に無効にし、通常のアプリをすべてVPNへ入れて基本接続を確認します。その後、ホワイトリストまたはブラックリストを戻し、対象アプリを一つずつ確認してください。「選択したアプリだけをプロキシ」と、それとは逆のバイパス設定を同時に有効にしないでください。

システムコンポーネント、ダウンロードマネージャー、埋め込みWebページは、異なるプロセスからリクエストを開始することがあります。アプリ画面内のダウンロード操作が、そのアプリのパッケージ名から直接実行されるとは限りません。そのためメインアプリだけを選ぶと、ログインはできてもダウンロードに失敗することがあります。このような場合は、クライアントのアプリ別統計やログを確認し、実際の通信がVPNへ入っているか確認してください。LAN機器に依存するアプリでは、必要に応じてローカルネットワークのバイパスを許可します。そうしないと、画面共有、プリンター、ルーター管理機能が使えなくなることがあります。

アプリ別プロキシとコアのルーティングは、異なる層の設定です。前者はアプリの通信をVPNへ入れるか決め、後者はVPNに入った通信をプロキシへ送るか直接接続するか決めます。アプリがそもそもVPNへ入っていなければ、geositeやIPルールを変更しても効果はありません。アプリがVPNへ入っているのに対象ドメインが誤った出力へ振り分けられている場合に、コアのルーティングを調整します。ログにそのアプリのリクエストがまったくないならアプリ分流を確認し、リクエストはあるのに出口が合わないならルーティングルールを確認してください。

ネットワーク切り替え、プライベートDNS、テザリングを確認する

Wi-Fiからモバイルデータへ切り替えると、ローカルアドレス、DNS、MTUが変わることがあります。クライアントはデフォルトネットワークへ再バインドし、トンネルを復旧する必要があります。切り替え後に接続済みと表示されるのにWebページが進まない場合は、ノードを削除せず、いったん停止してから再接続してください。頻繁に起きる場合は、ネットワーク変化後の自動再接続が許可されているか、システムがバックグラウンド通信を制限していないか確認します。デュアルSIM端末では、使用中のデータSIMとシステムのデフォルトネットワークが一致しているかも確認してください。

AndroidのプライベートDNS設定は、クライアント内蔵DNSと並行して動作したり、競合したりすることがあります。ドメインは失敗するのにIPへは接続できる場合、現在のプライベートDNSモードを記録し、一時的に「自動」へ切り替えて比較します。自動モードで復旧するなら、プライベートDNSホストへの到達性とクライアントDNSのルーティングを確認します。変化がなければ、問題はVPN内部の解決経路にある可能性が高いです。プライベートDNSを無効にすることを最終結論にせず、テスト後は実際の解決構造に適した設定を選んでください。

端末でテザリングを有効にした場合、接続先端末の通信がスマートフォンのVPNを経由するかどうかは、システムの能力とクライアントの転送方式によって異なります。スマートフォン本体がアクセスできるからといって、テザリング接続したPCも使えるとは限りません。まず接続先端末が通常のネットワークへ接続できるか確認し、その後、クライアントがテザリング通信の転送を明確にサポートしているか確認します。対応する転送機能がない場合は、スマートフォンのノードを何度も調整するのではなく、接続先端末にデスクトップクライアントを個別にインストールしてください。

最後に、固定した順序で確認します。厳しい省電力制限を解除し、他のVPNを停止し、アプリ分流を無効にし、利用可能と確認済みのノードを選び、デフォルトルーティングのままWebページをテストします。その後、画面をロックし、ネットワークを切り替え、分流を一つずつ戻します。基本状態でも失敗する場合は、ログでDNS、接続、ハンドシェイクのどの問題かを確認し、前の該当章へ戻ってください。基本状態が正常で、特定の設定を戻した後に失敗するなら、その設定が明確な確認対象です。段階的に復元するほうが、アプリデータを何度も消去するよりサブスクリプションとルーティング設定を保持しやすくなります。