V2Rayトラブル対処大全：接続・サブスクリプション・DNS・システムプロキシの問題

01 / LOCAL CHAIN

接続済みなのにインターネットへ接続できない：まずローカル経路を確認

「インターネットに接続できない」を検証可能な症状に分ける

クライアントに「接続済み」と表示されても、設定がコアで動作していることを示すだけで、ブラウザー、ターミナル、その他のアプリがノード経由で対象アドレスへ接続できるとは限りません。まずシステムプロキシを無効にするか現在の設定を停止し、通常のネットワークで普段安定してアクセスできるサイトを開けるか確認します。直接接続も失敗するなら、ルーター、無線ネットワーク、ネットワークアダプター、通信事業者側の問題を先に確認してください。直接接続は正常で、クライアントを有効にするとすべて失敗する場合に、ローカルプロキシ、ルーティングルール、リモートノードへ範囲を絞ります。

続いてブラウザーとコマンドラインを個別にテストします。ブラウザーは使えるのにターミナルだけ失敗する場合、両者でプロキシ設定の読み取り方が異なる可能性が高いです。両方とも失敗するなら、ローカルポートとコアのログを確認します。また、「すべてのドメインが開けない」のか「一部のサイトだけ失敗する」のかも分けて考えます。前者はローカルプロキシやノード経路の切断、後者は分割ルーティング、DNS、対象サイト側のネットワークポリシーが原因になりやすいです。接続ボタンを何度も押すより、症状を正確に記録する方が有効です。

コアプロセスとローカルの待ち受けポートを確認

v2rayN、v2rayNG、v2flyNGはいずれも、対応するコアを起動してローカルの入口を作る必要があります。デスクトップ版ではクライアントの状態欄で現在の設定が動作中か確認し、設定画面でHTTP、SOCKS、混合プロキシのポートを確認します。解説記事でよく使われる番号を推測せず、実際に画面へ表示されているポートを使ってください。別のプログラムが使用しているため、ポートの自動起動に失敗する場合もあります。Windowsでは次のコマンドでポートを確認できます。ポート番号はクライアント画面に表示された実際の値へ置き換えてください。

netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

一覧に該当ポートがない場合は、クライアントのログで「address already in use」「failed to listen」や設定読み込み失敗に関するメッセージを探します。ポートが使用中なら、そのプログラムを終了するか、クライアント設定で未使用のポートへ変更し、コアを完全に停止してから再起動します。設定を変更しただけでコアを再起動しないと、旧プロセスが元のポートを使い続ける一方、システムプロキシは新しいポートを向くことがあります。その結果、接続しているように見えて実際には通信が流れない状態になります。

システムプロキシの向き先とルーティングモードを確認

システムプロキシを有効にしたら、ローカルのループバックアドレスと現在の待ち受けポートを指定します。Windowsで一般的な宛先は 127.0.0.1 であり、LANアダプターのアドレスを誤って入力しないでください。クライアントに「自動構成スクリプト」「グローバルプロキシ」「システムプロキシを解除」などの項目がある場合は、現在どれを使っているかを明確にします。自動構成スクリプトはルールで宛先を判断し、グローバルプロキシはシステムプロキシに対応したリクエストをローカル入口へ送ります。障害の現れ方は異なるため、確認時は一時的にルールの少ないモードへ切り替えて基本経路を検証し、利用できることを確認してから元の分流設定へ戻します。

カスタムルーティングルールが通信を誤った出方向へ送っている可能性もあります。特にルールの順序を確認してください。コアは通常、最初に一致したルールを適用するため、範囲の広すぎるダイレクトルールを前に置くと、後続のプロキシルールが無視されます。反対に、LANアドレスをリモートへ送ると、プリンター、ルーター管理画面、内部サービスへ接続できなくなることがあります。新しく追加したルールを一時的に無効にし、クライアントのデフォルトルールだけで比較することを推奨します。元の設定を直接削除しないでください。テストに成功したら一つずつ戻すことで、影響したルールを特定できます。

ローカルプロキシへのリクエストで通信がコアに入っているか確認

デスクトップでは、システムプロキシを経由せず、クライアントのローカルポートを直接指定してリクエストを送れます。これにより、「システムプロキシが効いていない」場合と「ノード自体が使えない」場合を切り分けられます。以下はHTTPプロキシのポートを10809とした例です。実行時はクライアントの現在のポートを必ず指定してください。

curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/
curl.exe -v --proxy http://127.0.0.1:10809 https://example.com/

プロキシを直接指定するとHTTPレスポンスが返るのにブラウザーが失敗する場合は、ブラウザーのプロキシポリシー、拡張機能の競合、システムプロキシ設定を確認します。127.0.0.1 への接続自体にすぐ失敗するなら、ローカルポートが待ち受けていないか、ポート番号が間違っています。ローカルポートには接続できるものの待機後にタイムアウトする場合、リクエストはコアに入っているため、次にノードのハンドシェイク、DNS、ルーティングログを確認します。ログでは最後のエラーだけでなく、インバウンド、ルーティングの一致、アウトバウンドエラーを同時に確認するのが理想です。

確認が終わったら、システムプロキシを明確な状態へ戻します。しばらくクライアントを使わない場合は、終了前にクライアントの「システムプロキシを解除」を実行してください。接続を続ける場合は、システムプロキシのポートが現在のコアと一致していることを確認します。異常終了後に古いプロキシアドレスが残ると、次回起動時にシステムプロキシを読むアプリがすべて接続できなくなることがあります。クライアントを再び開いてシステムプロキシを解除する方が、複数のシステム画面で値を何度も変更するより簡単です。

02 / REMOTE HANDSHAKE

ノードのタイムアウトとハンドシェイク失敗：中断した層を特定

TCPタイムアウト、TLSエラー、プロトコル拒否を切り分ける

「ノードのタイムアウト」は一つの原因を指す言葉ではありません。TCP接続の確立前に中断する場合もあれば、サーバーには接続できてもTLSハンドシェイクに失敗する場合、TLS成功後にVMess、VLESS、Trojanなどのプロトコル層で拒否される場合もあります。ログに基づいて三つを区別してください。i/o timeout、context deadline exceeded、対象アドレスへの接続タイムアウトが出る場合は、まずネットワーク到達性を確認します。証明書のドメイン、ハンドシェイク、serverNameに関するエラーなら、システム時刻とTLSパラメータを確認します。認証失敗、無効なユーザー、プロトコル応答異常の場合は、ポート、ユーザー識別子、トランスポート設定を確認します。

クライアントの速度テスト一覧に表示される色だけで、ノードの状態を判断しないでください。テストがTCP接続だけの場合も、完全なリクエストまで行う場合もあり、クライアントやテスト方式が違えば単純比較できません。より確実なのは、一つのノードを選び、ネットワークとルーティングモードを固定して実際のリクエストを送り、対象アドレスの名前解決から接続確立、ハンドシェイク完了までのログを確認する方法です。ほかの条件を変えずに再テストすることで、エラーが安定して発生するか判断できます。

対象ホストとポートの到達性を先に確認

WindowsではPowerShellの Test-NetConnection を使って、ノードのドメインとポートを確認できます。このコマンドで検証できるのは基本的なネットワーク接続だけで、上位プロトコルの設定が正しいことまでは保証されません。ただし、ポートへまったく到達できないケースをすばやく除外できます。

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

ドメインを解決できない場合はDNSの章へ進みます。アドレスへ解決できてもTCPテストに失敗するなら、家庭のネットワークからモバイルネットワークへ切り替えるなど、別のネットワークで再テストします。一つのネットワークだけで失敗する場合、経路、ルーターのポリシー、ネットワーク出口の違いが考えられます。すべてのネットワークで失敗するなら、ノードのアドレス、ポート、サーバー側の状態を確認します。テストでは、通常のWebサイトのHTTPSポートをノードのポートと混同しないでください。同じ対象ホストと同じポートで確認する必要があります。

ノードがドメイン名を使用している場合、解決後のIPアドレスを設定へ戻して恒久的に使うのは避けてください。TLS接続では通常、証明書検証とSNIの一致にドメイン名が必要です。IPへ変更すると、元のTCP到達性の問題が新たな証明書エラーに変わる可能性があります。IPの一時使用は、DNSが障害に関係しているかを判断する場合に限り有効です。テスト後は元のドメイン名と対応する serverName に戻してください。

システム時刻、SNI、証明書のドメイン名を確認

TLS検証は端末の時刻に依存します。システムの日付、タイムゾーン、自動時刻設定に異常があると、証明書がまだ有効でない、または期限切れと判定されることがあります。システム設定で自動時刻と自動タイムゾーンを有効にし、手動でも一度同期してください。仮想マシン、デュアルブート、長時間スリープ後の端末では特に確認が必要です。時刻を合わせた後は、古い時刻条件を保持している可能性があるため、クライアントのコアを完全に再起動します。

serverName またはSNIは、接続アドレスの項目と必ずしも同じではなく、サーバー証明書が対象とするドメインに対応している必要があります。サブスクリプションをインポートした後にノードを手動編集した場合は、アドレス、ポート、トランスポート方式、TLS、SNI、パス、ホストヘッダーが一組の設定として一致しているか、元のノードパラメータと照合してください。アドレスとポートだけをコピーしてトランスポートパラメータを省略するのは、ハンドシェイク失敗の典型的な原因です。詳しくはTLSハンドシェイク失敗と証明書エラーの対処も参照してください。

プロトコルとトランスポートパラメータを項目ごとに照合

プロトコル層のパラメータは全体として一致している必要があります。VMessではユーザー識別子、暗号化方式、トランスポートの組み合わせを確認します。VLESSではユーザー識別子、フロー制御、安全層の設定を確認します。Trojanでは認証情報とTLS入口を確認し、Shadowsocksでは暗号化方式と認証情報が対応しているか確認します。WebSocket、gRPC、TCPなどのトランスポート方式にも、パス、サービス名、Host、安全層など固有の項目があります。空白、改行、手動置換によって一項目でも壊れると、接続直後に切断されることがあります。

最も有効な比較方法は、サブスクリプションを独立したグループへ再インポートし、既存の手動設定を上書きせずに新しいノードをテストすることです。新しいノードが使えるなら、古いノードは編集や移行の過程でパラメータがずれた可能性があります。新旧ノードが同じエラーになるなら、サブスクリプションの配信元、ネットワーク環境、リモート側の状態を確認します。意味を理解しないまま証明書検証をスキップする設定を常用しないでください。時刻、ドメイン、証明書の問題を一時的に隠すだけで、プロトコルパラメータの不一致は直りません。

ログの段階	よくある症状	優先して確認する項目
名前解決前	ホストが見つからない、名前解決に失敗する	DNS、ドメイン名の入力、ネットワーク接続
TCP接続の確立	タイムアウト、接続拒否	ノードのアドレス、ポート、基本的な到達性
TLSハンドシェイク	証明書のドメイン名または時刻のエラー	システム時刻、SNI、TLSの有効化
プロトコル認証	接続直後に切断される	ユーザーパラメータ、フロー制御、トランスポートの組み合わせ

同じノードで成功したりタイムアウトしたりする場合は、ローカルネットワークのパケットロス、無線信号の切り替え、端末のスリープからの復帰も確認します。少数回のテストを連続して実行し、発生時刻を記録してください。高頻度の並列テストで余計な負荷をかけないようにします。エラーが常に同じなら設定を、ネットワーク切り替えで変化するなら経路を調べると、特定までの時間を大幅に短縮できます。

03 / SUBSCRIPTION INPUT

サブスクリプション更新失敗：アドレス、応答、ノード解析を確認

サブスクリプションのアドレスが完全で、余計な文字がないことを確認

サブスクリプションの問題では、まず「応答を取得できていない」のか「応答は取得できたが解析に失敗した」のかを分けます。チャットツール、文書、QRコードからアドレスをコピーすると、末尾に句点、空白、改行、全角文字が混入することがあります。長いクエリパラメータを含むアドレスでは、途中で切れるとログインページ、エラーページ、空の内容が返ることもあります。クライアントのサブスクリプション設定へアドレスを完全に貼り直し、スキーム、ドメイン、パス、クエリパラメータが連続しているか確認してください。ノード共有リンクをサブスクリプション欄へ誤って貼り付けていないかも確認します。

v2rayNは通常、サブスクリプショングループで複数の配信元を管理します。v2rayNGとv2flyNGでは、サブスクリプション設定でアドレスを管理します。アドレスを変更したら設定を保存し、更新を手動で実行してください。名前を編集するだけでは取得は始まりません。古いキャッシュの影響を避けるため、一時グループを作成し、同じアドレスで更新して結果を確認する方法もあります。新しいグループだけ成功する場合は、古いグループの更新設定、フィルター、キャッシュ状態を確認します。

HTTPステータスとレスポンスタイプを確認

ログにHTTPステータスコードが出ている場合は、応答の意味に応じて対処します。認証失敗やアクセス禁止は、アドレスの認証パラメータ、アカウント状態、アクセス元の制限に関係することがあります。リソースが見つからない場合は、パスが不完全かアドレスが変更された可能性があります。サーバーエラーなら、時間を置いて再試行し、そのサブスクリプションだけが異常か確認します。成功ステータスでも、内容が必ず解析できるとは限りません。Webページ、ログイン案内、ゲートウェイの説明が返り、サブスクリプションデータではない場合があります。

デスクトップでは、アドレスの内容を表示せずにコマンドでリクエストの過程を確認できます。サブスクリプションアドレスには認証情報が含まれることがあるため、完全なアドレスを公開ログやスクリーンショットに載せないでください。以下のアドレスは例です。実際のテストでは、自分のサブスクリプションアドレスをローカル端末だけで使用してください。

curl.exe -I "https://subscription.example/subscription"
curl.exe -L --connect-timeout 15 "https://subscription.example/subscription" -o subscription.txt

-I はレスポンスヘッダーだけを取得するため、リダイレクトとステータスの確認に適しています。一部のサブスクリプションサービスはヘッダーのみの取得に対応していないため、その場合は2つ目のコマンドでレスポンスを保存し、ファイルが空でないか、コンテンツタイプが妥当か確認します。レスポンスファイルをそのまま公開しないでください。ノードアドレスや認証パラメータが含まれる可能性があります。リダイレクトが複数回発生する場合は、クライアントがその処理に対応していること、最終アドレスが想定したサブスクリプション入口に属していることを確認します。

更新リクエストを現在のプロキシ経由にする必要があるか確認

サブスクリプションの更新とノード接続は、関係はありますが別の経路です。クライアントによっては「プロキシ経由でサブスクリプションを更新」を選べますが、この設定には動作するノードがすでに必要です。唯一のノードが無効で、更新リクエストもそのノードへ強制的に送られると、更新できない循環が発生します。まずプロキシ経由の更新を無効にし、通常のネットワークからサブスクリプションを取得します。通常のネットワークから到達できず、利用可能なノードがある場合は、反対にプロキシ経由での更新をテストします。

システムプロキシの残留もサブスクリプションリクエストに影響します。クライアントを終了してもシステムが古いローカルポートを向いていると、再起動前の通信がすべて失敗することがあります。まずローカルポートが待ち受け中か確認するか、システムプロキシを解除してから更新します。企業ネットワークやログインが必要な公衆ネットワークでは、初回アクセス時に認証ページが返ることもあります。先にブラウザーでネットワークへ正常に接続してから、サブスクリプションを更新してください。

形式、文字コード、ノードフィルターの問題を確認

サブスクリプションのレスポンスには、エンコードされたノード集合が含まれる場合と、共有リンクが1行ずつ含まれる場合があります。ノード一覧を生成するには、クライアントがレスポンス形式を認識できなければなりません。「解析成功なのにノード数が0」の場合、すぐにサブスクリプションが空だと判断せず、キーワードフィルター、重複除去、特定プロトコルだけを残す設定、無効ノードの削除などを確認します。グループ名やノード名が変わった後に、厳しすぎるフィルターですべての項目が除外されることがあります。

ログで特定の行の形式エラーが明示されている場合は、他の有効なノードが更新時にインポートされているか確認します。異常な1件をスキップするクライアントもあれば、全体の処理を中止するクライアントもあります。レスポンスを再取得して通信中断を除外し、同じ位置で失敗し続けるなら、配信元に該当項目の修正を依頼します。手動でデコードしたサブスクリプションのコピーを長期運用しないでください。ノードパラメータの更新が反映されず、アドレス、証明書ドメイン、トランスポートパラメータが徐々に食い違います。

再現可能なサブスクリプション確認手順を作る

手順は、システム時刻と基本ネットワークの確認、サブスクリプションアドレスの照合、更新経路がプロキシ経由かどうかの確認、HTTPレスポンスの確認、解析ログとフィルター条件の確認、最後に新しくインポートしたノードで実際に接続する、という順番です。更新後にノード名が表示されただけでは利用可能とはいえません。ノードパラメータが完全で、実際にアクセスできることを確認してください。入口の操作についてはv2rayNとv2rayNGのサブスクリプションインポート手順も参照してください。

自動更新が頻繁に失敗する場合は、端末のスリープ、バックグラウンド制限、ネットワーク切り替えも確認します。デスクトップ端末はスリープ中に予定された更新を実行できず、復帰後にクライアントがネットワークを再確立する必要があることがあります。Androidではバックグラウンド動作が制限されると、定時タスクが遅延することがあります。自動更新はメンテナンス機能であり、接続成功の唯一の前提ではありません。直近に動作した設定を常に残し、更新後はログとノードの変化を確認してください。

04 / THROUGHPUT

接続速度が遅い：ノード、経路、端末側の負荷を切り分ける

接続確立が遅いのか、継続的な転送が遅いのかを先に分ける

Webページの表示開始まで時間がかかるものの、ダウンロード開始後は速度が正常なら、DNS、初回ハンドシェイク、接続再利用の問題が考えられます。ページはすぐ表示されるのに大容量ファイルの転送が遅い場合は、回線帯域、パケットロス、サーバー負荷、端末性能を疑います。動画、メッセージアプリ、特定のアプリだけが遅い場合は、そのアプリがTCPとUDPのどちらを使っているか、ルーティングルールが関連ドメインを別々の出方向へ送っていないかを確認します。すべてを「ノードが遅い」とまとめると、重要な違いを見落とします。

テスト前に環境を固定します。同じノード、同じネットワーク、同じ対象リソース、近い時間帯を選び、帯域を使う同期やダウンロードを停止してください。複数の速度テストツールを同時に使うと、リクエストが帯域を奪い合い、ノード負荷も変化します。まず通常のネットワークを測定し、次にクライアントを有効にして測定します。2つの結果から、ボトルネックがローカル接続にすでに存在するか判断できます。通常のネットワーク自体が不安定なら、無線信号、LANケーブル、ルーターの状態を先に改善します。

再現可能なリクエストで各段階の所要時間を確認

curl では、名前解決、接続、TLS、合計の所要時間を個別に出力できます。どの段階で遅くなっているかを判断するのに便利です。以下はローカルHTTPプロキシ経由で例示用ドメインへアクセスする例です。ポートはクライアントの実際の値へ変更してください。

curl.exe -o NUL -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n" --proxy http://127.0.0.1:10809 https://example.com/

名前解決に時間がかかるならDNSを確認します。接続に時間がかかるなら、リモートアドレスへの到達性と経路距離を確認します。TLSだけ遅い場合は、パケットロス、証明書チェーン処理、ネットワーク再送が関係している可能性があります。接続段階は正常なのに最初の1バイトが遅い場合は、対象サイトの応答やリモート出口の負荷を疑います。1回の結果で長期的な性能を判断せず、間隔を空けて数回実行し、安定しているかを確認してください。大量のサンプルを集める必要はありません。目的はランキング作成ではなく、時間が集中する区間の特定です。

ノードを比較するときはノードだけを変更

同じサブスクリプション内でも、ノードごとに地域、プロトコル、トランスポート方式、出口回線が異なることがあります。比較時はクライアントのモード、DNS、対象アドレスを固定し、同じリクエストをノードごとに実行します。すべてのノードが遅い場合は、ローカルネットワーク、クライアントモード、DNS、端末リソースを優先して確認します。特定のノードだけ遅いなら、そのノードの経路やリモート負荷に問題が集中しています。同じノードがネットワークによって大きく変わる場合は、各接続ネットワークからノードまでの経路品質を考慮します。

クライアントの遅延テストは、テスト方式が対象とする段階だけを反映します。低遅延でも大容量転送が速いとは限らず、高遅延でも継続的なスループットが低いとは限りません。TCPではパケットロスがあると送信ウィンドウが縮小し、速度が周期的に低下することがあります。無線干渉、モバイルネットワークの切り替え、地域をまたぐ経路もこの現象を引き起こします。実際の利用では接続の安定性、Webページの最初の1バイト、継続転送を同時に確認し、単一の遅延値だけでノードを選ばないでください。

同じ通信が異なる経路へ送られていないか確認

現在のWebページは、メインドメイン、静的リソースのドメイン、APIドメイン、コンテンツ配信先へ同時にリクエストします。メインドメインだけをルールで指定すると、関連リソースが直接接続や別の出方向へ送られ、本文はすぐ表示されるのに画像やスクリプトだけ長時間待たされることがあります。コアのアクセスログを開き、1回のページ読み込みで各ドメインがどの出方向ルールに一致したか確認します。経路が分散しているなら、単一ドメインをリストの末尾へ追加し続けるのではなく、関連するドメイン群に合わせてルールを調整します。

ルールの順序は性能にも影響します。正規表現、範囲の広いドメイン一致、重複ルールが多いと判定が複雑になり、保守も難しくなります。明確なドメイン、サフィックス、IP範囲、組み込みデータセットのルールを優先し、確実性の高いルールを前に、デフォルトルールを最後に置きます。変更後はDNSキャッシュを消去してコアを再起動し、古い名前解決や接続が以前の経路を使い続けないようにします。

トランスポート、接続再利用、端末リソースを確認

接続の再利用は、接続を頻繁に確立する負荷を減らせますが、すべてのネットワークとサーバーの組み合わせに適しているわけではありません。少数の接続は正常なのに並列接続で明らかに遅くなる場合は、再利用の有効・無効を比較します。並列数をむやみに増やさないでください。端末性能に余裕がないと、暗号化、コンテキスト切り替え、メモリ負荷が増加します。Android端末は省電力中や高温時にバックグラウンド処理性能が低下することがあり、デスクトップではCPU、メモリ、ディスクを他のタスクが長時間占有していないか確認します。

トランスポート方式ごとにカプセル化のオーバーヘッドは異なりますが、理論上の負荷より、正しい設定と安定した経路の方が重要です。速度を追求するためだけにトランスポート項目を単独で変更しないでください。クライアントとサーバーのパラメータは一致している必要があります。プロトコルの組み合わせを比較するなら、サブスクリプションに含まれ、利用できることを確認した完全なノードを使います。1つのノードからアドレスだけをコピーし、別のトランスポートパラメータを自分で組み合わせないでください。プロトコルの特徴と選び方についてはVMess、VLESS、Trojan、Shadowsocksの比較を参照してください。

05 / NAME RESOLUTION

DNSの名前解決異常：どこで名前解決しているか確認

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

DNSの問題は、ドメイン名へのアクセス失敗、IPアドレスへの直接アクセスだけ成功、サイトの初回表示が遅い、同じドメインがアプリによって異なる結果になる、クライアントモードを切り替えると一部サイトだけ使えなくなる、といった形で現れます。ノードのドメインを解決できないとコアはリモートへ接続できません。対象サイトのドメイン解決に失敗した場合は、特定のアクセスだけが影響を受けます。まず失敗しているのが「ノードアドレス」か「アクセス対象」かを確認してください。両者で名前解決の経路が異なる可能性があります。

ブラウザーが独自のセキュアDNSを有効にし、システムが別のサーバーを使い、コアもプロキシリクエスト内のドメインを設定に従って処理することがあります。そのため同じ端末上に複数のDNS経路が同時に存在する可能性があります。ブラウザーで成功してもシステムの名前解決が正常とは限らず、システムコマンドが成功してもコアが同じ結果を使っているとは限りません。ブラウザー設定、システムのネットワーク設定、コアのログを組み合わせ、実際にどの層が名前解決しているか判断します。

システムの名前解決結果から確認する

Windowsでは Resolve-DnsName または nslookup、macOSとLinuxでは dig または nslookup を使えます。まずノードのドメインをテストし、次に異常が起きている対象ドメインをテストして、レコードタイプとアドレスを記録します。

Resolve-DnsName node.example.com
nslookup node.example.com
nslookup example.com

# macOS または Linux
dig node.example.com
dig example.com A
dig example.com AAAA

コマンドがタイムアウトする場合、現在のDNSサーバーが時間内に応答していません。「存在しない」と返る場合は、ドメイン名の入力とレコードの状態を確認します。アドレスが返っても接続できないなら、問題は名前解決からルーティング、ポート、ハンドシェイクの段階へ進んでいます。IPv4とIPv6の両方が返り、現在のネットワークでIPv6接続が不完全だと、アプリが到達できないアドレスを先に試してフォールバックを待つことがあります。AとAAAAレコードの接続結果を一時的に比較することはできますが、システムのプロトコル対応を削除してネットワーク設定の問題を隠すのは避けてください。

キャッシュを消去し、古い結果の影響を避ける

システム、ブラウザー、クライアントのコアはいずれも名前解決結果をキャッシュすることがあります。DNS設定を変更しても、古い接続やキャッシュはすぐには消えません。関連するブラウザーのタブを閉じ、コアを停止し、システムキャッシュを消去してから、クライアントを再起動します。Windowsでは次を実行できます。

ipconfig /flushdns
Clear-DnsClientCache
Get-DnsClientServerAddress

キャッシュの消去は次のリクエストで再解決させるだけで、誤ったサーバーアドレス、ルーティングルール、ドメイン設定そのものは修正しません。消去後だけ一時的に正常になり、その後また異常になるなら、システムのネットワーク切り替え、ルーターが配布するDNS、ブラウザー独自の名前解決、クライアントルールが到達不能なサーバーへ送っていないかなど、どのコンポーネントが誤った結果を書き込んでいるかを確認します。

ローカル・リモートの名前解決とドメインルールを理解する

アプリがドメインをSOCKSまたはHTTPプロキシへ渡す場合、ローカルでIPへ解決することもあれば、ドメイン名のままコアへ入り、コアがDNSサーバーを選ぶこともあります。方式によってルーティングの一致結果が変わります。早い段階でIPへ変換すると、ドメインベースのルールが元のドメインを取得できないことがあります。ドメインを保持する場合は、コアに信頼できるDNSの出方向が必要です。どの層で名前解決するかを明確にし、互いに上書きする設定を重ねないでください。

コアのDNS設定には通常、サーバー一覧、対象ドメイン、問い合わせポリシーが含まれます。ルールは出方向と組み合わせて設計します。ノードのドメインを解決するサーバーは、ノード接続前からアクセスできなければなりません。プロキシ経由の出方向に依存するDNSを、そのプロキシ確立に必要な初回名前解決へ使うと、循環依存になります。最も安定する基本構成は、通常のネットワークでノードアドレスを解決できる経路を一つ残し、対象ドメインとルーティング要件に応じて他の問い合わせを割り当てる方法です。

hosts、フィルタールール、ブラウザー独自設定を確認

システムのhostsファイルにある静的レコードは、通常のDNS問い合わせより優先されることがあります。古いテスト用レコード、誤ったアドレス、重複項目があると、特定のドメインが長期間古い宛先を向きます。確認時は、自分が明確に追加したレコードだけを変更し、変更前にバックアップを取ってください。セキュリティソフト、ルーターのフィルタリング、ペアレンタルコントロール、企業ネットワークのポリシーが特定のアドレスを返したり、問い合わせを阻止したりすることもあります。別のネットワークへ切り替えて比較します。

ブラウザー独自のDNS設定は、システムの経路を迂回することがあります。一つのブラウザーだけが異常なら、まずクリーンな設定や別のブラウザーでテストし、そのブラウザーが独自解析、プロキシ拡張、キャッシュポリシーを有効にしていないか確認します。すべてのアプリが異常なら、システムとコアを優先して確認します。ブラウザー拡張、システムプロキシツール、V2Rayクライアントが同じ設定層を同時に変更すると、成功したリクエストがどの経路を通ったかも判断しにくくなります。

症状	考えられる場所	確認方法
ノードのドメインを解決できない	システムDNS、基本ネットワーク	クライアントを停止してノードのドメインを検索
ブラウザーだけ正常	ブラウザー独自のDNSまたはシステムプロキシの違い	コマンドラインとブラウザー設定を比較
ドメインは失敗するがIPには接続できる	対象ドメインの名前解決経路	AとAAAAレコードを確認し、コアのログを見る
ネットワークを切り替えると復旧する	現在のネットワークが配布するDNSまたはルート	2つのネットワークのサーバーと名前解決結果を記録

修正後は、ノードのドメイン解決、対象ドメインの解決、実際のアクセスを個別に確認します。検索コマンドが結果を返しただけでは不十分です。DNSがアドレスを返すのは名前解決が完了したことを示すだけで、その後にルーティング、接続、プロトコルのハンドシェイクが必要です。3段階の結果を分けて記録すると、ネットワーク切り替えやルール変更後にどの層が再び変化したか見つけやすくなります。

06 / APPLICATION ROUTING

システムプロキシが効かない：ブラウザーとターミナルを個別に確認

まずシステムプロキシの適用範囲を理解する

システムプロキシは、アプリが読み取る接続設定であり、すべてのネットワーク通信を自動的に引き受けるものではありません。ブラウザーや一部のデスクトップアプリは通常システムプロキシを読み取りますが、コマンドラインツール、ゲーム、バックグラウンドサービス、独自のネットワークスタックを実装したアプリは無視することがあります。そのため、ブラウザーはクライアント経由なのにターミナルは直接接続することがあります。これは必ずしもコアの障害を意味しません。対象アプリが対応するプロキシ方式を確認し、システムプロキシ、環境変数、アプリ内プロキシ、TUNモードから適切な方法を選びます。

詳しい場面別の比較はブラウザーとターミナルのシステムプロキシ対処を参照してください。本章では、ローカルポートを確認し、システムプロキシの値を確認し、アプリがその値を読み取っているか調べるという統一した判断方法を扱います。タスクトレイのアイコンやクライアントのメニュー表示だけで、通信がコアに入っていると判断しないでください。

プロキシのアドレス、種類、ポートを確認

HTTPプロキシ、SOCKSプロキシ、混合プロキシは同じものではありません。アプリへ入力するプロキシの種類は、クライアントの待ち受け入口と一致している必要があります。SOCKSポートをHTTP専用のシステムプロキシ欄へ入力すると接続に失敗し、HTTPポートをSOCKSとして使ってもハンドシェイクエラーになります。クライアント設定からアドレスとポートをコピーし、コア再起動後も待ち受けが続いていることを確認してください。

Windowsでは現在のユーザーのプロキシ設定を確認し、プロキシを直接指定して比較できます。

netsh winhttp show proxy
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/

WinHTTPと通常のデスクトップアプリでは、プロキシの参照元が異なることがあります。netsh winhttp show proxy の結果から、ブラウザーも同じ設定を使っているとは判断できません。具体的なプログラムごとに確認が必要です。プロキシを直接指定すると成功するのにアプリが直接接続する場合、ノードとローカルポートは基本的に利用可能で、アプリ設定を重点的に確認します。直接指定でも失敗する場合は、ローカルの待ち受けまたはノードの章へ戻ります。

ターミナルが環境変数を使う場合は大文字・小文字を確認

多くのコマンドラインプログラムは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を読み取りますが、変数の大文字・小文字や対応プロトコルはツールによって異なります。一時設定なら単発テストに適しており、現在のターミナルを閉じると自動的に無効になります。PowerShellの例：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe -I https://example.com/

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

macOSまたはLinuxのシェルでは次を使用します。

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
curl -I https://example.com/

unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy

SOCKS入口を使う場合は、ツールが対応する記法と、ドメインをローカルとプロキシ側のどちらで解決するかを確認します。クライアントが常駐する保証のない起動ファイルへ環境変数を長期的に残すと、クライアント停止中にターミナルの通信がすべて空のポートへ向かいます。恒久設定にする場合は解除方法も記録し、設定の切り替えでポートが変わらないようにしてください。

自動構成スクリプトとバイパスリストを確認

自動プロキシ構成は、URLまたはホスト名に応じて直接接続かプロキシ経由かを決定します。スクリプトの読み込み失敗、キャッシュ未更新、ルール不足があると、一部のサイトがクライアントを迂回することがあります。まず明示的な手動プロキシへ一時的に切り替え、ローカルポートとノードが利用できることを確認してから自動スクリプトへ戻します。戻した後はブラウザーを再起動し、システム設定とスクリプトを再読み込みさせます。

バイパスリストには通常、ローカルアドレス、LANホスト、指定ドメインが含まれます。範囲が広すぎると、多くの対象が直接接続されます。誤ったワイルドカードで全サブドメインに一致することもあります。反対に、LANアドレスをバイパスしないと内部機器へ接続できなくなる場合があります。まずループバックアドレスと明確な内部ネットワーク範囲だけを残し、カスタム項目を一つずつ戻します。システム設定、クライアントルール、ブラウザー拡張にもそれぞれバイパスリストがあるため、3か所で重複管理しないでください。

TUNモードでは確認するポイントが異なる

TUNモードは仮想ネットワークインターフェースを通じて、システムプロキシを読まない通信も処理します。その一方で、ルーティングテーブル、DNSの引き継ぎ、システム権限、他のネットワークソフトとの競合が新たな変数になります。有効化後に完全に通信できなくなった場合は、仮想インターフェースの作成、デフォルトルートの登録、DNSが有効な入口を向いているか、クライアントに必要な権限があるかを確認します。クライアント終了後は、ルートとDNSが復元されていることも確認してください。

システムプロキシが失敗したとき、最初からTUNモードを使わないでください。まずノードと通常のローカルプロキシポートが使えることを確認してからTUNを有効にすれば、新しい問題を仮想インターフェース層に限定できます。端末で仮想マシン、コンテナネットワーク、企業接続ソフト、その他のルーティング管理プログラムを同時に使っている場合は、一つずつ停止して比較します。競合は通常、ノードプロトコルではなく、ルートの優先順位やDNSの引き継ぎ順で発生します。

最終確認では、ブラウザーがシステムプロキシを読み取る通信、コマンドラインでプロキシを明示する通信、システムプロキシに対応しないアプリが独自設定またはTUNで行う通信の3種類を確認します。3経路がそれぞれ成功して、設定の適用範囲が明確になります。一つだけ失敗した場合は、その入口だけを処理し、動作している他の部分までリセットする必要はありません。

07 / CLIENT RUNTIME

クライアントのクラッシュやコア終了：証拠を残して段階的に復旧

画面の終了、コアの終了、設定読み込み失敗を切り分ける

クライアントのウィンドウが消える、画面は残るが接続だけ停止する、起動を押すとすぐ未実行状態へ戻る、という現象はそれぞれ異なる層に対応します。画面プロセスがクラッシュすると、システムトレイのアイコンも消えることがあります。コアが終了した場合は画面が残り、エラーログを確認できることが多いです。設定読み込み失敗は、ノード切り替えや設定変更後に、コアが待ち受けを開始する前に終了する形で起きます。まずどの層が終了したか記録し、アプリログ、コアログ、システムイベントのどれを見るか決めます。

異常発生後、すぐに何度も再インストールしないでください。まず発生時刻、操作手順、ログ末尾を保存し、クラッシュ直前にサブスクリプションをインポートしたか、ルーティングを編集したか、コア設定を切り替えたか、スリープから復帰したか、システムを更新したかを記録します。安定して再現できる手順は、「たまに落ちる」という説明より特定しやすいです。公開して相談する際は、ノードアドレス、サブスクリプションパラメータ、ユーザー識別子、その他の認証情報を削除し、エラーの種類と発生段階だけを残してください。

最後に変更した設定から戻す

新しいノードをインポートしてから問題が起きたなら、検証済みノードへ戻します。ルーティング変更後なら追加したルールを一時的に無効にします。ポート変更後なら新しいポートが使用中でないか確認します。TUN有効化後なら、まず通常のシステムプロキシモードへ戻します。一度に戻す設定は一種類だけにし、毎回クライアントを再起動してください。すべての設定を直接削除すれば一時的に復旧することはありますが、原因を特定する手がかりを失い、再インポート後に同じ問題が再発する可能性があります。

設定ファイルがJSONの場合、末尾の余分なカンマ、引用符の不足、フィールド階層の誤り、数値を認識できない文字列として記述することなどがよくある原因です。以下は配列、オブジェクト、カンマの位置を示す、構造的に完全な最小ルーティング断片の例です。実際の設定では、クライアントが生成した完全な構造と統合してください。

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

完全な設定構造に慣れていない場合は、クライアント画面から編集し、断片で設定ファイル全体を上書きしないでください。クライアントが生成するフィールドはインバウンドとアウトバウンドのタグも参照します。タグ名が一致しないと起動に失敗します。ログに具体的なフィールドや行番号が示されている場合は、エラー文字だけでなく、その位置の上位オブジェクトを確認してください。

ポート、権限、実行ディレクトリを確認

コア起動直後の終了原因として多いのが、待ち受けポートの競合です。ポート確認コマンドでプロセスIDを調べ、そのプロセスが旧コア、別のプロキシツール、通常のシステムサービスのどれかを確認します。不明なシステムプロセスを直接終了しないでください。関連アプリを閉じるか、クライアントに未使用のポートを選ぶ方が安全です。旧コアのプロセスが残っている場合は、クライアントから停止し、プロセス終了を待ってから起動します。

TUN、ルート登録、一部のシステム機能には適切な権限が必要です。通常のプロキシは使えるのにTUNだけ起動に失敗する場合は、権限の通知、仮想インターフェースの作成、システムのセキュリティポリシーを確認します。インストール先に書き込み権限がないと、設定、ログ、実行コンポーネントの保存や展開にも失敗することがあります。現在のユーザーが読み書きできる通常のディレクトリへ配置し、圧縮ファイル内から直接実行しないでください。同じ設定を複数のディレクトリから同時に起動するのも避けます。

サブスクリプションデータ、クライアント画面、コアを分離して確認

v2rayNはWindows、macOS、Linux向けのデスクトップクライアントです。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。画面、設定管理、コア実装は同じ層ではありません。ノードのインポートは成功したのにコアを読み込めない場合、ノードパラメータが現在のコアの機能と合っていない可能性があります。コア単体は動くのに画面がクラッシュするなら、クライアントの状態ファイル、画面の実行環境、システムログを重点的に確認します。

分離テストでは、新しい空の設定ディレクトリを作るか、クライアントのバックアップと復元機能を使います。唯一のデータを上書きしないでください。まずサブスクリプションとカスタムルーティングを含まない基本環境を起動し、既知の設定を一つずつ取り込みます。空の環境が安定し、取り込み後にクラッシュするなら、問題は設定またはデータにあります。空の環境でもクラッシュするなら、インストールファイル、実行環境、権限、システム互換性を確認します。クライアントを再取得する場合は、ダウンロードページからプラットフォームとアーキテクチャに合うパッケージを選んでください。

ログの増加、スリープ復帰、セキュリティソフトの遮断に対処

詳細ログを長期間有効にすると、ディスクへの書き込みとファイル容量が増えます。空き容量が不足すると、設定の保存、更新、ログの書き込みが失敗することがあります。確認が終わったらログレベルを通常の設定へ戻し、クライアントが提供する方法で古いログを整理します。コアの実行中に、書き込み中のログファイルを手動でロックしたり移動したりしないでください。新たな異常を引き起こす可能性があります。

端末がスリープから復帰すると、ネットワークアダプターのアドレス、DNS、デフォルトルートが変わり、コアが復帰前の接続を保持していることがあります。この場合は接続を停止し、システムネットワークが安定するのを待ってからコアを再起動する方が、端末全体を再起動するより早いことが多いです。毎回スリープ後に再発するなら、復帰時のアダプター、ルート、ログの変化を記録し、ネットワーク再構築の問題かクライアントプロセスの問題か確認します。

セキュリティソフトが、新しくダウンロードした実行ファイルのポート待ち受け、仮想インターフェース作成、ネットワークアクセスを阻止することがあります。システムのセキュリティ記録で、対象のクライアントやコアプロセスが明確に遮断されていないか確認し、実際のパスに基づいて対処します。長期対策としてシステム保護をすべて無効にしないでください。イベント記録で具体的な遮断対象を確認すれば、他のルールを変えずに復旧できます。

復旧後は、クライアントの起動、ポートの待ち受け、ノード接続、システムプロキシの切り替え、サブスクリプション更新、終了時の解除を順番に確認します。ウィンドウが開くだけでは、障害が解消したとはいえません。問題が安定して再現するなら、最小限の再現手順と処理済みのログを記録し、よくある質問の該当項目も確認してください。

08 / ANDROID RUNTIME

Android活用：権限、バックグラウンド切断、アプリ別プロキシ

初回接続ではシステム権限を確認

v2rayNGとv2flyNGはAndroid上で、通常システムのVpnServiceを通じてローカルの仮想ネットワークを構築します。初回接続時にはシステムの許可ダイアログが表示され、ユーザーが許可して初めてクライアントが対象の通信を処理できます。接続をタップしてもステータスアイコンが表示されない、ログがすぐ未許可に戻る、画面が未接続のままの場合は、許可を取り消していないか確認します。また、同じ種類のインターフェースを使う別のネットワークアプリが動作していないかも確認してください。

通常、システム上でこの種類の接続を同時にアクティブにできるのは一つだけです。クライアントを切り替える前に、元の接続を停止し、ステータスアイコンが消えるのを待ってからv2rayNGまたはv2flyNGを起動します。前のアプリを強制終了しただけで正常に切断していないと、システムが古いインターフェースを一時的に保持することがあります。その場合はシステムのネットワーク設定から古い接続を切断するか、ネットワークを再起動して試してください。複数のアプリが交互に自動再接続する状態にはしないでください。接続直後に別のアプリへ置き換えられることがあります。

バックグラウンド切断ではバッテリーとプロセス制限を優先確認

画面ロック後数分で切断する、別のアプリへ切り替えると通信が止まる、システムがバックグラウンドを整理すると自動復旧できない、といった症状は、バッテリー最適化、バックグラウンド活動の制限、端末メーカーのプロセス管理に関係することが多いです。使用中のクライアントを、システムでバックグラウンド実行を許可する一覧へ追加し、必要なバックグラウンド通信を許可してください。タスク整理画面でプロセスを手動終了するのも避けます。Androidの設定名は機種により異なりますが、基準は同じです。画面ロック後もクライアントプロセスとVpnServiceが動作している必要があります。

バッテリー最適化を一か所無効にするだけでは不十分な場合があります。アプリの電池使用量設定、自動起動管理、バックグラウンドデータ、休止アプリ、ロック時のタスク整理が別々に用意されている端末もあります。項目ごとに確認し、変更後はステータスバーのアイコンだけでなく、画面をロックしてしばらく実際のリクエストを行います。アイコンが残っているのにリクエストが失敗する場合は、無線からモバイルデータへの切り替えや、コアが接続を正常に再構築できたかも確認します。

Androidの省電力モードは、バックグラウンドタスクやネットワークアクセスを遅延させることがあります。サブスクリプションの自動更新、接続維持、ネットワーク復旧も影響を受けます。まずシステムの省電力モードを無効にして比較し、問題が解消するならクライアント単体の設定を調整します。端末全体の電池設定を恒久的に変更する必要はありません。詳しい操作はv2rayNGの権限・省電力・アプリ別プロキシ設定を参照してください。

無線ネットワークとモバイルネットワークの切り替えに対処

無線ネットワークからモバイルネットワークへ切り替えると、ローカルIP、デフォルトルート、DNSが変わり、既存のTCP接続は通常そのまま再利用できません。クライアントはネットワークの変化を検出して再接続するはずですが、システム制限、電波の弱さ、コアの状態によって復旧が遅れることがあります。切り替え後にアクセスできない場合は、まずシステムネットワーク自体が使えるようになるまで待ち、その後クライアントで停止して再接続します。スイッチを短時間に何度もタップしないでください。

無線ネットワークは使えるのにモバイルネットワークだけ失敗する場合は、同じノードで対象ポートの到達性とIPv4・IPv6の違いを確認します。逆の場合は、ルーターのDNS、LANフィルタリング、無線ネットワークのログイン状態を確認します。公衆無線LANでは先にWebログインが必要なことが多いため、仮想ネットワークを構築する前にクライアントを停止して認証を完了し、その後再接続してください。一方のネットワークだけが失敗する場合、別のネットワークで同じ設定が動作しているため、サブスクリプションやノードをリセットしないでください。

アプリ別プロキシの「含める」と「除外する」を明確にする

アプリ別プロキシには通常、選択したアプリだけをプロキシ経由にする方式と、選択したアプリを迂回させる方式があります。名前は似ていますが結果は逆です。有効化する前に現在のモードを確認し、対象アプリが一覧にあるか確認します。「プロキシのみ」では、選択していないブラウザーやテストツールはクライアントを経由しません。「迂回」では、一覧のアプリが通常のネットワークを直接使います。確認時は一時的にアプリ別ルールを無効にし、全体接続が使えることを確認してからアプリを一つずつ追加または除外します。

アプリを更新または再インストールすると、システム上の識別子が変わり、古いルールが一致しなくなることがあります。以前は使えたアプリが、更新後に突然直接接続したり通信できなくなったりした場合は、アプリ別一覧を開き直して保存します。システムコンポーネント、埋め込みWebページ、アプリが呼び出す外部ブラウザーは別プロセスの場合があります。メインアプリだけを選んでもログイン処理全体をカバーできるとは限りません。コアのアクセスログでリクエストが実際にクライアントへ入ったか確認します。

AndroidのDNSとプライベートDNSの重なり方

システムのプライベートDNS、クライアントのコアDNS、アプリ独自の名前解決が同時に存在することがあります。接続後にドメインだけ失敗し、IPへの直接リクエストは成功する場合は、まずシステムのプライベートDNSが自動、オフ、指定ホストのどれになっているか確認し、次にクライアントログのDNSエラーを確認します。指定したプライベートDNSホストが現在のネットワークから到達できないと、仮想ネットワークの構築前後で名前解決に影響します。一時的にシステムの自動モードへ切り替えて比較し、結果を見て恒久設定を決めてください。

ローカルDNSの引き継ぎを有効にする場合は、現在の出方向から問い合わせを完了でき、ノードのドメインにも初期解決経路があることを確認します。デスクトップと同様、ノードの解決に必要なDNSを、まだ確立していないノードへ完全に依存させないでください。ネットワーク切り替え後も古い結果が使われ続ける場合は、接続を停止し、機内モードを一度オンにしてからオフにしてネットワークを再構築し、クライアントへ再接続します。この操作では現在のネットワークタスクが中断されるため、作業を保存してから実行してください。

アプリは接続するのにアクセスできない場合の最短手順

まずアプリ別プロキシを無効にし、検証済みノードを一つ選び、システムの許可が有効か確認します。次に接続ログでノードのハンドシェイクが完了しているか確認し、ブラウザーでドメインへアクセスします。ハンドシェイクに失敗するならノードのタイムアウトの章に従います。ハンドシェイクは成功しているのにアクセスログがない場合、アプリの通信が仮想ネットワークへ入っていないため、許可とアプリ別設定を確認します。アクセスログがありDNSエラーが出るなら、システムのプライベートDNSとコアDNSを確認します。リクエストが出方向へ入った後にタイムアウトするなら、無線とモバイルネットワークを比較します。

特定のアプリだけが失敗する場合は、そのアプリが独自プロキシ、プライベートDNS、バックグラウンドデータ制限、無線LAN限定のダウンロード設定を使っていないか確認します。クライアントデータ全体を消去するとサブスクリプションとルーティング設定も削除されるため、最初の手段にしないでください。現在の設定をエクスポートまたは記録し、最小構成を新しく作って比較する方が安全です。v2rayNGはXrayコアの設定に、v2flyNGはv2flyコアの代替として利用できます。クライアントを切り替えてテストする場合は、同じ完全なパラメータのノードを使い、両者で対応するコア機能が異なる可能性にも注意してください。

Androidでの症状	優先して確認する項目	対処
接続をタップするとすぐ停止する	システムの許可、設定読み込みログ	再度許可し、ノードパラメータを確認
画面ロック後に切断する	バッテリー最適化、バックグラウンド動作	クライアントのバックグラウンド動作を許可
ネットワーク切り替え後に使えない	ルートの再構築、DNS、ノードの到達性	基本ネットワークを確認して再接続
一部のアプリだけ失敗する	アプリ別モード、アプリ独自設定	フィルターを無効にして確認し、一つずつ戻す

モバイル端末の問題は、システムのライフサイクルとネットワーク切り替えによって同時に発生することがあります。安定した設定の基準は、接続状態が点灯することだけではありません。画面ロック後も維持されること、無線とモバイルネットワークの切り替え後に復旧すること、対象アプリが実際に分流ルールへ一致することも確認します。調整するたびに該当する場面でテストし、前景で一時的に成功しただけで確認を終えないでください。