CLIENT DIAGNOSTICS / トラブル対処ガイド

V2Rayのトラブル対処ガイド

接続、サブスクリプション、DNS、システムプロキシの問題を症状から特定し、設定を一つずつ復旧します。

初期設定はクイックスタートガイドから始め、インポート、モード選択、接続、確認の順に進めてください。このページでは、すでに問題が起きている場合の調べ方を説明します。まず現状を記録し、アプリ、ローカルの待ち受け、カーネル、ネットワーク、接続先サービスの順に確認しましょう。複数の設定を同時に変更するのは避けてください。

デスクトップでは、まずv2rayNの手順に沿って確認します。Androidについてはv2rayNGとv2flyNGをそれぞれ説明します。画面やメニューの名称はバージョンによって異なる場合があるため、該当する設定機能を確認してください。アプリやアーキテクチャを選び直す場合はクライアントのダウンロードページへ。用語や基本事項はよくある質問をご覧ください。

変更は一度に一つ 関連する最初のエラーを確認 復元できる設定を残す
01 / CONNECTION CHAIN

ネットに接続できない：接続経路を切り分ける

クライアントが動作中と表示されても、ブラウザーの通信がノード経由で接続できているとは限りません。まず、すべてのアプリで失敗するのか、ブラウザーだけなのか、すべてのサイトが開けないのか、特定のドメインだけなのかを記録します。クライアント終了後に通常の直接接続が復旧するかも確認してください。この比較で、システムネットワーク、アプリの接続方式、接続先サービスを切り分けられます。テストには普段正常に開けるHTTPSページを一つ選び、接続先を頻繁に変えてサイト側の問題が混ざらないようにします。

最小構成でテストする

ほかのプロキシソフトを終了し、ブラウザーのプロキシ拡張機能を一時停止して、TUNを無効にします。v2rayNの通常のローカルプロキシだけを残してください。設定が一通りそろったノードを一つ選び、現在の接続先として有効になっていることを確認したうえで、メイン画面のログにカーネルの正常起動が表示されるか確認します。初期設定が済んでいない場合は、高度なルーティング設定から始めず、クイックスタートガイドに戻って基本接続を確認してください。他のソフトを終了するのは、ポート競合や複数のプロキシによる干渉を切り分けるためです。普段の使い方を変え続ける必要はありません。

設定画面で、SOCKSまたは混合プロキシの実際の待ち受けポートを確認します。このページのコマンドにある10808は、そのポートでSOCKSサービスが待ち受けている場合にのみ使えます。ポートを変更している場合は、コマンドも合わせて変更してください。待ち受けアドレスが127.0.0.1なら、接続を受け付けるのはこの端末からのリクエストだけです。ローカル利用では正常な設定です。端末内のブラウザーを直すためにLAN接続を有効にしたり、待ち受けアドレスをすべてのネットワークインターフェースに変更したりする必要はありません。不要な接続範囲を広げないでください。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com/

このコマンドはローカルのSOCKSプロキシを明示的に使い、接続先ドメインの名前解決をプロキシ側に任せます。ブラウザーのプロキシ設定を介さずに接続経路を比較できます。Windowsで同名のコマンドを使えない場合は、ターミナルでcurl.exeを実行してください。HTTPレスポンスが返れば、リクエストが何らかの応答元に届いたことは確認できます。ステータスコードが成功を示すページでなくても、すぐにプロキシの失敗と判断する必要はありません。証明書エラー、接続拒否、接続タイムアウトはそれぞれ異なる段階の問題です。「開けない」だけで済ませず、エラー全文を記録してください。

結果に応じて次の手順へ

確認結果次に確認すること
ローカルポートへの接続が拒否されるポート、カーネルの起動状況、ローカルの待ち受けを確認する。
プロキシを明示すると成功するが、ブラウザーでは失敗するシステムプロキシ、ブラウザー拡張機能、アプリ独自のプロキシ設定を確認する。
リクエスト後、接続先への接続がタイムアウトするノードのタイムアウトの項目へ進み、アドレスとネットワーク経路を確認する。
ドメインへのリクエストだけ失敗するDNSの項目へ進み、名前解決の場所と経路を切り分ける。

ログも確認します。コマンドを実行した時刻の前後に、該当する接続先へのリクエストが記録されていますか。ログがなければ、アクセスを記録できるログレベルか確認してから、コマンドの接続先が実行中のインスタンスを指しているか確かめてください。接続先が記録されているのに、想定と異なるアウトバウンドタグが表示される場合は、ルーティングの適用結果と最終的なデフォルトアウトバウンドを確認します。一時的に「すべてプロキシ経由」のルーティングにして比較すると、原因を絞り込めることがあります。テスト後は元のルールに戻してください。モードの切り替えを、すべての問題に効く恒久対策にしないでください。

特定のサイトだけ失敗する場合は、同じノードで別の接続先を試し、さらに同じサイトを別のノードでも確認します。単一サイトでアクセス拒否、CAPTCHA、地域に関する表示が出る場合、アプリケーション層の接続は確立していることが多く、ローカルの待ち受けポートを変更しても接続先の制限は解消されません。ブラウザーに証明書の日付エラーが表示されたら、まずシステム時刻とタイムゾーンを確認してください。エラーを隠すために証明書検証を無効にしないでください。ページが表示されたことだけをもって、安全で正常な接続と判断するのも避けましょう。

02 / REMOTE REACHABILITY

ノードのタイムアウト：疎通確認と実接続を切り分ける

ノード一覧でのタイムアウトは、原因が一つとは限りません。TCPポートへの到達性だけを調べるテストもあれば、ノード経由で指定URLにアクセスするテストもあります。さらに、測定先、ハンドシェイク、端末内のDNSによって結果が変わる場合もあります。まず実行したテストの種類を確認し、通常のWeb閲覧でも再現するか試してください。TCPで接続できても、そのアドレスにサービスが応答したことしか分かりません。プロトコルのパラメーター、認証情報、通信設定が正しいとは限りません。疎通テストのタイムアウトも、テスト先が利用できないだけの場合があります。ノード全体の障害と即断しないでください。

アドレス、ポート、ハンドシェイクの順に確認

現在のノードの編集画面を開き、まずサーバーアドレス、ポート、プロトコルを確認します。次に、通信方式、TLS、サーバー名、関連する通信フィールドを確認してください。サブスクリプションから追加した設定は、ノード名から推測せず、サービス提供元の元のパラメーターと照合します。ノード名は表示用で、自由に設定できます。実際のプロトコルや回線を示すものではありません。アドレスを貼り付ける際は、前後の空白、日本語の句読点、改行に注意してください。ポート欄には数字だけを入力し、プロトコルの接頭辞やURLのパスを含めないでください。

サーバーアドレスがドメイン名の場合、クライアントはリモート接続を確立する前に、まずそのドメインをIPアドレスに解決する必要があります。接続先サーバーへの接続前に名前解決エラーが記録される場合は、接続先サイトの分流ルールではなく、ノードのドメイン解決を確認してください。システムのターミナルからサーバーのドメインを検索し、現在のネットワークと信頼できる別のネットワークで結果を比較できます。取得したIPアドレスを汎用的な対処法として固定しないでください。接続先が複数のアドレスを使い分けている場合、固定すると後続の更新を回避してしまう可能性があります。

Test-NetConnection -ComputerName example.com -Port 443

上記はWindows PowerShellでTCP接続を確認する構文です。例のドメインは利用可能なノードではありません。実際のノードアドレスとサーバーポートを指定してください。このコマンドではプロキシプロトコルの認証もUDP通信の検証もできません。TCPテストに成功してもクライアントのハンドシェイクが失敗する場合は、TLSのサーバー名、通信パス、認証フィールド、端末の時刻を重点的に確認します。REALITYの設定は、サーバー名、公開鍵、short IDを提供元の情報と一つずつ照合してください。値を適当に変更して試すのは避けましょう。

別条件でテストして原因を絞り込む

もともと使えていたノードを二つ選び、現在のネットワークでそれぞれ接続します。次に、同じノードを別のネットワークでも試してください。一つのネットワークでどのノードも失敗するなら、ローカルネットワーク、ルーター、ネットワーク経路の問題が考えられます。同じノードが複数のネットワークで失敗する場合は、接続先サービスまたはノード設定の問題が疑われます。ネットワークを切り替える際は、接続先URLとクライアント設定を変えず、カーネル、プロトコル、ルーティングも同時に変更しないでください。テザリングのテストではモバイル通信量が発生する場合があります。小規模なリクエストで十分で、大きなファイルをダウンロードする必要はありません。

ログのconnection refusedは、接続先ポートでサービスが待ち受けていない場合や、明示的に拒否された場合によく見られます。timeoutは制限時間内に応答がなかったことを示すだけで、どちら側が通信を破棄したかまでは分かりません。EOFや接続リセットは、接続が途中で終了したことを示します。接続開始時、TLSハンドシェイク中、認証後のどの段階で起きたかも確認してください。エラーに表示された接続先と現在のノードを照合し、サブスクリプション更新やバックグラウンドの疎通確認によるログと取り違えないようにします。連続して再試行するとログが増えるだけです。同じリクエスト前後の数行を確認する方が有益です。

PCのスリープ復帰後や、有線からWi-Fiへの切り替え後にタイムアウトが起きる場合は、まず接続を停止してカーネルを再起動し、古い接続とルートを解放します。必要ならクライアントを終了して再起動してください。サーバー一覧をすべて削除する必要はありません。ネットワークの変更後、長時間接続が無効な経路を保持する場合があります。この種の問題は、接続を作り直すだけで解消することがあります。再起動後に一時的にしか復旧しない場合は、切断までの時間や画面消灯との関連を記録し、ネットワークの省電力設定やバックグラウンド制御を確認します。一時的な復旧を、接続先の問題が解決した証拠とみなさないでください。

03 / SUBSCRIPTION PIPELINE

サブスクリプションの更新失敗：取得と解析を分けて確認

サブスクリプションの更新には二つの段階があります。まずクライアントがURLにアクセスし、その後、レスポンスの内容をノードとして解析します。ダウンロード失敗、空のレスポンス、形式を認識できない場合、ノードの重複は、それぞれ分けて対処してください。更新ボタンを押してもノードが増えないからといって、必ずしもネットワーク障害とは限りません。内容に変更がない、グループの絞り込みで結果が隠れている、現在のカーネルに対応していない項目しか含まれていない可能性もあります。まず使える設定を保存し、現在のグループ名とノード数を記録してから更新してください。URLの有効性を確かめるために一覧を空にするのは避けましょう。

サブスクリプションのURLと種類を確認

v2rayNのサブスクリプショングループ設定で、該当グループのURLを確認します。ログインページや購入ページ、単一ノードの共有文字列ではなく、サブスクリプションURL全体をコピーしてください。v2rayNGではサブスクリプション設定を開き、該当するURLと有効状態を確認してから更新します。単一ノードの共有リンクと、複数ノードを返すサブスクリプションURLは用途が異なります。前者をサブスクリプションURL専用の欄に入力すると、未対応のアドレスや空の内容として扱われる場合があります。更新ボタンを繰り返し押しても、形式は変わりません。

URLのクエリパラメーターは、サブスクリプションの識別に使われることがあります。末尾が欠けると、ログインページやエラーメッセージが返る可能性があります。チャットやメモアプリで改行、句読点、自動リンク化によってURLが途中で切れることもあるため、元の画面からコピーし直してください。値全体は端末上で確認し、スクリーンショットを共有するときはパラメーターを隠します。ブラウザーでURLを開けても、ブラウザー独自の経路でレスポンスを取得できたことしか分かりません。クライアントが同じプロキシやリクエストヘッダーを使うとは限らず、レスポンスがノード情報である保証もありません。

まず更新ログに表示されたHTTPステータスを確認します。認証失敗の場合はURLの有効期限や権限の変更を確認してください。リクエスト過多の場合は連続操作をやめ、提供元の更新制限に従って時間を置きます。サーバーエラーは発生時刻を記録して、後で再試行してください。ステータスが成功でも解析に失敗する場合、レスポンスがWebページ、アクセス案内、別の設定形式である可能性があります。レスポンス全文を公開の変換サービスに貼り付けないでください。サブスクリプションURLやノードの認証情報が漏れるおそれがあります。出所が明確で、ローカルで処理できる方法を使って形式を変換してください。

更新リクエストの経路を確認

クライアントによっては、サブスクリプション更新時に直接接続するかプロキシ経由にするかを選べます。設定箇所や初期動作は画面によって異なるため、使用中のバージョンの設定とログを確認してください。有効なノードがなく、更新にもそのノードが必要な場合は、接続を復旧するための更新に接続が必要という循環が起きます。まず直接接続で更新を試してください。URLにプロキシ経由でしかアクセスできない場合は、使えることを確認済みの接続を一時的に使用します。更新経路だけを切り替え、原因を判断できるようサブスクリプションURLは同時に変更しないでください。

TLSや証明書のエラーが出た場合は、端末の時刻、システムの証明書環境、URLの入力ミスを確認します。職場や学校のネットワーク、ログインが必要な公衆Wi-Fiでは、認証ページが返されることがあります。まずブラウザーでネットワークのログインを済ませてから、サブスクリプションを更新してください。証明書エラーを無視して解決しようとしないでください。サブスクリプションの内容は、その後のリモート接続に影響します。ダウンロードできたかだけでなく、取得元が正しいかを重視してください。リダイレクトが発生する場合は、見知らぬ中継URLに置き換える前に、提供元へ最終的な接続先を確認します。

内容を取得できてもノードが表示されない場合は、グループの絞り込み、検索条件、重複排除の設定、ノードの種類を確認します。似た拡張子でも、別の設定方式向けの内容はそのままインポートできないことがあります。特定のカーネル機能が必要な項目が含まれていると、古いカーネルが解析時や起動時に拒否する場合もあります。まずシステムのアーキテクチャに合ったクライアントに更新し、元のサブスクリプションを再インポートしてください。内容が分からない項目をすべて手動で削除すると、保存はできても認証できない不完全なノードになるおそれがあります。

更新が成功したら、現在のノードが残っているか、ルーティング設定が古いグループを参照していないか、自動選択で接続先が切り替わっていないかを確認します。ノード名が同じでもアドレスが同じとは限らず、名前が変わってもサービス側が変更されたとは限りません。操作手順や形式の違いはサブスクリプションURLのインポート手順をご覧ください。問題を他の人に説明する場合は、レスポンスの状態、解析エラー、クライアント名を伝え、実際に使えるサブスクリプションURLは共有しないでください。

04 / PERFORMANCE SCOPE

速度が遅い：遅延、通信速度、揺らぎを切り分ける

「遅い」には、ページ表示まで時間がかかる、ダウンロード速度が低い、接続状況が不安定になる、といった異なる症状があります。ノード一覧の遅延値一つだけでは、実際の使い心地は分かりません。接続開始時とデータ転送中のどちらで遅くなるのかを確認し、同じ時間帯、接続先、ネットワークで比較してください。短時間に多数のノードを切り替えると、比較できるデータが得にくいうえ、接続先による速度制限を招く可能性もあります。大量の自動測定より、条件を絞った少数の比較が役立ちます。

まず直接接続の基準を確認

システム更新、クラウド同期など、大量の通信を使うタスクを一時停止し、Wi-Fiの電波とローカルネットワークが正常か確認します。クライアントを終了した状態で、普段直接接続できるサービスにアクセスし、同じように遅いかを調べてください。基準となる接続も遅い場合は、ローカルの帯域使用、電波干渉、ルーターの負荷から確認します。直接接続のテストで分かるのは、接続回線の状態までです。ノード経由の実速度を推定することはできません。ダウンロードテストは通信量を消費します。プランに上限がある場合は、短時間で中止できるテストを選び、料金体系を事前に確認してください。

次に、ノードを固定して同じページを繰り返し開き、初回と2回目以降の違いを確認します。初回だけ遅く、その後は正常なら、DNS、TLS接続、接続の再利用が関係している可能性があります。毎回遅い場合は、ログで再接続が繰り返されていないか、接続先アドレスが頻繁に変わっていないかを確認してください。ブラウザーの開発者ツールを使うと、最初の応答を待つ時間とコンテンツのダウンロード時間を切り分けられます。ただし、ページ内のスクリプトや広告のリクエストも読み込み時間に影響します。複雑なページの読み込み完了時間だけで、プロキシ経路の性能を判断しないでください。

余分な経路とリソース競合を一つずつ除外

ブラウザーのプロキシ拡張機能、システムプロキシ、TUNを同時に使っていないか、前段プロキシも設定していないかを確認します。複数の経路があるとハンドシェイクの負荷が増えたり、ループが発生したりすることがあります。まず接続方式を一つに絞り、同じリクエストでテストしてください。通常のシステムプロキシでは問題なく、TUNだけ遅い場合は、仮想ネットワークアダプターのルーティング、DNSの引き継ぎ、他のネットワークソフトとの競合を優先して確認します。すべてのノードをすぐに変更しないでください。端末からノードまでの経路と、ノードから接続先サービスまでの経路のどちらも性能に影響します。

カーネルプロセスのCPU、メモリ、ネットワーク使用量を確認します。小型端末、多数の同時接続、複雑なルーティングルールでは特に注意してください。リソース使用量が多い場合は、同時に実行するタスクと不要な詳細ログを減らしてから再測定します。多重化の有効化、暗号化検証の無効化、内容不明のパラメーター追加を、根拠のない高速化手段として使わないでください。多重化の効果はプロトコル、サーバー側の対応、接続状況によって異なります。設定が合わないと失敗が増える場合もあります。性能調整は、接続が安定し、互換性が確認できてから行ってください。

ダウンロード開始後の数秒は正常でも、その後速度が低下し続ける場合は、接続先や時間帯を変えて比較し、接続先の速度制限、サービスの通信量制限、共有回線の混雑を切り分けます。同じ時間帯にすべての接続先で遅くなる場合は、時刻を記録して別のノードでも確認してください。特定のダウンロード元だけ遅い場合は、ノードを変えても改善しないことがあります。測定サイトによって選択されるサーバーが異なるため、結果を日常の利用状況とそのまま同一視できません。同じ配信元の同じファイルで短時間の比較を行う方法はありますが、出所不明の大容量ファイルをダウンロードして調べる必要はありません。

UDPを使うアプリとWeb閲覧では、TCPの通信経路と異なる動作になることがあります。Webページは正常でもリアルタイム通信が不安定な場合は、該当するプロトコル、ノード、接続方式が必要なUDP通信に対応しているかを確認し、パケットロスやネットワーク切り替えの影響も調べます。一つの機能が遅いからといって、すべての通信を接続対象にしないでください。MTUが適切でないと一部の接続が停止する場合がありますが、根拠なく値を小さくするのは避けます。TUN使用時に大きなレスポンスだけが止まる場合は、元の値を記録し、一度に一項目だけ小幅に変更して確認してください。改善しなければすぐに元へ戻します。

しばらく使った後に速度が落ちる場合は、端末の温度、省電力モード、バックグラウンドタスク、ログファイルの増加も確認します。PCを長時間起動した後なら、接続を作り直して比較できますが、再起動は原因を切り分けるために使いましょう。問題が繰り返し発生する場合は、発生条件を記録し、毎回再起動するだけで済ませないでください。「どのカーネルが速いか」を比べる前に、同じノード設定、ルーティング、接続先でテストしていることを確認します。条件が異なればネットワーク状況の差にすぎず、カーネルの違いによるものとは判断できません。

05 / NAME RESOLUTION

DNSの問題：まず名前解決を行う側を確認

DNSのトラブル対処は、パブリックDNSへの変更から始めるのではなく、どのコンポーネントが名前解決しているかの確認から始めます。システムのリゾルバー、ブラウザーの暗号化DNS、クライアントカーネルのDNS、TUNによる制御が同時に使われている場合があります。ノードサーバーのドメインと最終的なWebサイトのドメインも、別々の名前解決です。前者はプロキシの接続先を探すため、後者は接続先にアクセスするために使います。ノードの名前を解決できない場合、接続先ドメインのDNS設定が正しくてもネットには接続できません。この二つを混同すると、問題が変わらないまま設定だけが増えていきます。

条件をそろえたリクエストで名前解決の場所を比較

まずエラーに表示されたドメインとリクエスト元のプロセスを記録し、サブスクリプションURL、ノードの接続先、Webサイトのどれに関する問題かを判断します。システムターミナルでの名前解決テストが確認できるのは、その時点でシステムが利用する経路だけです。ブラウザーやカーネルの結果を示すものではありません。ブラウザーだけ正常な場合は、独自の暗号化DNSが有効になっていないか確認します。プロキシを明示した接続は正常で、直接接続が失敗する場合は、システムの名前解決または直接接続のネットワークに問題がある可能性があります。比較には同じ接続先を使い、別ドメインの成功を現在の問題の診断に代用しないでください。

nslookup example.com

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

2つのプロキシコマンドの違いは、接続先ドメインをどこで解決するかです。通常、socks5ではローカル端末が先に名前解決し、socks5hではプロキシ側にドメインを渡します。後者で成功し、前者で失敗する場合は、まずローカルの名前解決を確認してください。両方とも失敗するなら、リモート接続とカーネルのログを調べます。コマンドで指定するローカルポートは、実際の設定に合わせてください。この比較だけですべてのアプリの動作を判断することはできません。アプリが独自に名前解決する場合や、キャッシュ済みのアドレスを使う場合もあります。

DNSの通信経路とルーティングの関係を確認

v2rayNのDNS設定とルーティング設定を開き、まず現在の値を確認します。そのうえで、DNSリクエスト自体を直接接続するか、プロキシ経由にするか判断してください。リモートの暗号化DNSを設定する場合も、そのサービスに接続できる経路が必要です。アドレスを書き込むだけで利用可能になるとは限りません。DNSサービスのドメイン解決が、まだ確立していない同じプロキシ接続に依存すると、起動時に依存関係のループが発生することがあります。接続先の名前解決、DNSサービスへの到達性、対象ドメインの検索結果を個別に確認し、すべてのDNS設定を一度に置き換えないでください。

以下は、V2Ray互換設定でよく使われるDNSフィールドの構造です。サーバーや検索ポリシーの役割を理解するためのもので、そのままインポートできる完全なノード設定ではありません。GUIクライアントは起動時に設定を再生成する場合があるため、該当する設定画面から変更してください。実行中の一時ファイルを直接編集するのは避けましょう。カーネルやクライアントによって拡張フィールドの対応状況は異なります。ログに未対応フィールドや無効なポリシーが表示される場合は、使用中のカーネルが対応する設定に戻し、別の設定方式の構成をそのまま流用しないでください。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

アドレスを解決できても、そのアドレスに接続できるとは限りません。結果にIPv4とIPv6の両方が含まれているか確認し、現在のネットワークが該当するアドレスファミリーで実際に接続できるかを確かめてください。IPv6が返される場合にだけ失敗するなら、IPv4のみを使う検索ポリシーで一時的に比較し、必要に応じてローカルのIPv6経路を修正します。IPv6を恒久的に無効化することを標準の対策として勧めないでください。特定のWebサイトだけの問題で、システム全体の設定を変更するのも避けましょう。ルーティングでは、ドメイン名による判定と解決後のアドレスによる判定が異なる場合があります。最終的なアウトバウンドも確認してください。

キャッシュの削除は、名前解決経路を直した後に行います。先に消しても、誤った結果がすぐに再びキャッシュされる可能性があります。Windowsではipconfig /flushdnsでシステムのDNSキャッシュを消せますが、ブラウザー、カーネル、各アプリ独自のキャッシュまでは削除されません。設定変更後は関連する接続やアプリを再起動し、同じテストをもう一度行ってください。TUNの仮想アドレスマッピングでは、古い接続が以前のマッピングを保持していることがあります。切り替え前後のログを混ぜて判断しないでください。まず接続を停止し、条件をそろえた状態で確認します。

06 / APPLICATION INGRESS

システムプロキシが効かない：アプリの接続方式を確認

システムプロキシは、アプリにプロキシ設定を知らせる仕組みであり、すべての通信を強制的に経由させるものではありません。システム設定を読み込むアプリもあれば、アプリ独自の設定を使うもの、環境変数だけを参照するターミナルプログラムもあります。TUNは仮想ネットワークアダプターとルーティングを使って通信を取り込む仕組みです。システムプロキシとは別の設定です。まず対象アプリがどの方式を使うかを確認し、対応する設定を選んでください。一つのアプリがシステムプロキシに反応しないだけで、ノードやカーネルが停止したと判断しないでください。

まずポートを確認し、次にシステム設定を確認

まずTUNを無効にし、このページの第1章にあるプロキシを明示したコマンドでローカル接続口を確認します。そのリクエストも失敗する場合は、カーネルとノードの問題に戻り、システム設定を変更し続けないでください。プロキシを明示した接続に成功したら、v2rayNのシステムプロキシメニューでシステムプロキシの自動設定を選び、OSのネットワークプロキシ設定を開きます。アドレスとポートがクライアントの設定と一致するか確認してください。HTTPとSOCKSの両方に対応する接続口もあれば、別々に待ち受けるものもあります。SOCKS専用ポートを、HTTPプロキシ専用の欄に設定しないでください。

設定を適用したら、テスト対象のアプリを終了して再起動し、プロキシ設定を読み込み直します。ブラウザー拡張機能、アプリ独自の固定プロキシ、組織の管理ポリシーがシステム設定を上書きする場合があります。まずこれらを一時停止して比較してください。システムの設定値が古いポートに戻る場合は、別のネットワークソフトがバックグラウンドで動作していないか確認します。管理対象端末では、ポリシーによって設定が定期的に戻されることもあります。レジストリを繰り返し変更したり、設定を強制的に取り合ったりしないでください。設定の出所を特定すれば、クライアント終了後に無効なプロキシ設定が残るのを防げます。

プラットフォームまず確認する場所よくある注意点
Windows設定の「ネットワークとインターネット」→「プロキシ」アプリ、ターミナル、システムサービスでは、参照するプロキシ設定が異なる場合があります。
macOS現在のネットワークサービスの詳細情報とプロキシ設定ネットワークサービスごとに異なる設定を保存できます。
Linuxデスクトップのネットワークプロキシ設定とアプリ独自の設定デスクトップの設定がターミナルやバックグラウンドサービスに引き継がれるとは限りません。

ルールの問題とアプリが接続されていない問題を切り分ける

ログに接続先へのリクエストがない場合は、アプリがプロキシに接続されていない可能性があります。リクエストが記録されているのに直接接続と表示される場合は、ルーティングルール、バイパスリスト、デフォルトのアウトバウンドを確認してください。システムプロキシの例外リストによって、ローカルアドレスや一部のドメインがプロキシを迂回することもあります。これはクライアント内部のルーティングとは別の判定です。テストでは該当する独自の例外を一時的に外せますが、システム標準の項目をすべて削除しないでください。LAN機器、プリンター、社内ドメインなどは、想定する接続経路を先に確認しましょう。Web接続を直した結果、ローカルサービスが使えなくなるのを避けられます。

システムプロキシを使わないターミナルツールは、まずコマンド単位でプロキシを指定して確認します。動作を確認してから、プロキシ用の環境変数を設定するか判断してください。環境変数は現在のターミナルと、そこから起動する子プロセスだけに適用される場合があります。すでに起動中のアプリには反映されないこともあります。ツールによっては大文字と小文字や、プロトコルごとに異なる変数を使います。確認後は一時的な変数を削除し、クライアント終了後もターミナルが待ち受けのないローカルポートを参照し続けないようにします。アカウント情報を含むプロキシURLを公開スクリプトやコマンド履歴の説明に載せないでください。

TUNは単独で有効にし、個別に動作確認

プロキシ設定を読み込まないアプリを接続する必要がある場合に限り、TUNをテストしてください。まず現在のルーティングを保存し、クライアントの案内に従って必要な権限を付与し、仮想ネットワークアダプターが正常に作成されたか確認します。権限不足、残った仮想アダプター、他のトンネルソフト、ネットワークフィルターソフトが接続を妨げる場合があります。クライアントからノードへのアウトバウンドは、仮想ネットワークアダプターを正しく迂回する必要があります。自動ルーティングを誤ると、通信が再び仮想入口に送られてループする可能性があります。広範囲の静的ルートを追加せず、クライアントが対応する標準設定で確認してください。

TUNを有効にした後、ローカルネットワークにも接続できなくなった場合は、ただちにTUNを無効にし、デフォルトルート、DNS、LANのバイパス設定を確認します。ネットワーク切り替えやスリープ復帰後は、古いネットワークアダプターのインデックスやルートが無効になっていることがあります。接続を作り直して比較してください。接続制御を解除する前に、仮想アダプターをすべて手動で削除しないでください。まずクライアントを正常に停止し、残っている項目を確認します。システムネットワークの復旧が必要な場合は元の設定を記録し、今回変更した項目だけを元に戻してください。復旧コマンドが他の正常なネットワークサービスに影響しないよう注意します。

07 / PROCESS AND CORE

クライアントのクラッシュ：画面とカーネルを切り分ける

画面が開かない、画面が突然終了する、画面は正常でもカーネルが停止する、という症状はそれぞれ別の問題です。GUIクライアントは設定を管理してプロセスを起動し、カーネルは接続を処理します。一方が正常でも、もう一方が正常とは限りません。プログラムの起動、ノード選択、サブスクリプション更新、TUN有効化のどの時点で問題が起きるかを観察し、毎回再現するか記録してください。ユーザーディレクトリ全体を最初に削除しないでください。ログ、サブスクリプション、設定が含まれている可能性があり、削除すると原因を調べる証拠を失い、復元も難しくなります。

まずインストールと実行環境を確認

ダウンロードページで、OSとプロセッサーのアーキテクチャを改めて確認します。macOSではApple SiliconとIntel、Linuxではアーキテクチャとパッケージ形式を区別してください。Windowsでは、v2rayNのデスクトップ版と従来のWPF版も、現在のシステム要件に合わせて選びます。別のプラットフォーム向けのプログラムフォルダーをコピーして使わないでください。圧縮形式で配布されている場合は、書き込み可能な場所に完全に展開してから実行します。圧縮ファイルの閲覧画面から直接起動すると、依存ファイルや作業ディレクトリが正しく認識されないことがあります。

インストーラーとポータブル版では、実行環境の要件が異なる場合があります。インストール時の案内と配布パッケージの説明に従い、出所不明のサイトから依存ファイルをダウンロードしないでください。セキュリティソフトがファイルを隔離した場合は、検出履歴、ファイルの入手元、隔離理由を確認します。すべてのセキュリティ保護を無効にすることを一般的な対処法にしないでください。保護されたフォルダー、読み取り専用のメディア、同期ツールが管理するフォルダーでは、設定を書き込めないことがあります。元のフォルダーはそのまま残し、ユーザーが書き込める場所に独立したテスト環境を作成できます。

カーネルの起動失敗は、最初に関係するエラーを確認

v2rayNのメイン画面でカーネルログを開き、起動時刻に沿って最初のエラーを探します。最後の「プロセスが終了しました」という行だけを見て判断しないでください。よくある原因は、ポートの競合、設定形式の誤り、カーネルファイルの不足、引数の非対応、権限不足です。アクセスログと起動ログは用途が異なります。前者はリクエストを記録し、後者はプロセスがなぜ動作状態にならなかったかを示します。詳しい確認方法はカーネル起動失敗のログ診断をご覧ください。実際の調査では、今回のログに表示された項目を基準にします。

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

上記のコマンドは、Windows PowerShellで指定したTCPポートを待ち受けているプロセスを確認するものです。ポートは実際の値に置き換えてください。環境によっては必要な権限が異なります。プロセスIDが分かったら、タスクマネージャーでどのプログラムか確認してから操作してください。正体が分からないシステムプロセスを直接終了しないでください。別のクライアントが重複して起動している場合は、不要な方を通常の方法で終了します。別のサービスがそのポートを必要としている場合は、クライアントの待ち受けポートを変更し、システムプロキシやアプリの設定も更新してください。待ち受けだけ変えて接続先の設定を変えないと、新たに接続できなくなります。

設定エラーは、ログに示されたフィールドのパスに沿って修正します。カスタムJSONでは、余分なカンマ、引用符の誤り、フィールドの型、未対応パラメーターが原因でカーネルが起動を拒否することがあります。GUIが生成した設定は、該当する設定画面から修正するのが基本です。一時設定は次回起動時に上書きされることがあるため、実行中の一時ファイルを長期的な設定として編集しないでください。フィールドの関係は設定ファイルの構造解説を参照できますが、記事中の例で既存の設定全体を置き換えないでください。

一度にすべてを戻さず、段階的に復旧

画面が繰り返しクラッシュする場合は、まず設定とログをバックアップし、別のユーザーディレクトリまたはクライアントが対応する新しい設定環境で起動します。空の環境で起動できるなら、既存の設定、ウィンドウの状態、インポート内容が原因の可能性があります。それでも失敗する場合は、インストール、依存関係、システムイベントを確認してください。復元時は、まずノードを一つだけ追加して接続を確認します。その後、サブスクリプション、ルーティング、その他の設定を戻し、その都度テストしてください。バックアップを一度にすべて読み込むと、問題を引き起こした設定まで戻る可能性があります。

プログラムを更新する前に、画面とカーネルを正常に終了します。プロセスが動作中のままファイルを上書きしないでください。更新後に問題が起きた場合は、旧フォルダーをロールバック用に残せます。ただし、異なるビルド間で設定の互換性が保証されるわけではありません。まずコピーを作成してから読み込みを試してください。一つの起動エラーを直すために、XrayとV2Flyを頻繁に切り替えないでください。ノードが必要とする機能と、使用中のカーネルの互換性を先に確認します。問い合わせにはOS、アーキテクチャ、操作手順、機密情報を除いたエラーを添えてください。ノードの認証情報、サブスクリプションURL、個人のディレクトリ名は隠します。

08 / ANDROID NETWORK LIFECYCLE

モバイル端末のトラブル：権限、バックグラウンド動作、ネットワーク切り替え

Androidでは、まずv2rayNGを使用してください。V2Flyカーネルとの互換性が必要な場合は、v2flyNGを代替として検討できます。画面構成や利用できるパラメーターが完全に同じとは限らないため、使用中のクライアントを確認してください。モバイル端末は、バッテリー制御、アプリの対象範囲、ネットワーク切り替えの影響を受けやすい傾向があります。まったく接続できない、画面点灯中は正常でもロック後に切断する、Wi-Fiでは使えるがモバイルデータ通信では失敗する、という三つの症状を切り分けてから該当する手順に進みます。すべてノードの不安定さが原因と決めつけないでください。

接続権限と現在の有効な設定

初回接続時には、通常、システムからVPN接続の許可を求められます。許可を拒否した場合や端末のポリシーで制限されている場合、画面上では接続操作が進んでいるように見えても、実際には通信が取り込まれていないことがあります。もう一度接続を開始し、システムの案内を読んでアプリに権限が付与されているか確認してください。システムのVPNアイコンが示すのは接続サービスが何らかの状態で動作していることだけで、接続先に到達できる証拠ではありません。使用中のサーバーが選択されているか、カーネルが起動完了を報告しているかを確認します。内蔵の接続テストまたはブラウザーで固定ページを開いて検証し、通知の文言だけで判断しないでください。

AndroidのVPNサービスでは、通常、同種のアプリを複数同時に独立して通信の取り込みに使うことはできません。別のネットワークフィルター、トンネル、プロキシアプリがその接続口を使用している場合は、正常に停止してから現在のクライアントを起動してください。旧アプリで「常時接続VPN」や「VPNを経由しない通信をブロック」が有効になっていると、切り替え後のネットワークに問題が出ることもあります。システムのVPN設定で現在の接続対象を確認し、ほかのアプリのデータをむやみに削除しないでください。テスト終了後は、端末のネットワークポリシーを意図せず変更しないよう、関連設定を元の用途に戻します。

一部のアプリだけ失敗する場合は対象範囲を確認

クライアントのアプリプロキシまたはアプリ別設定で、「選択したアプリのみプロキシを使用」と「選択したアプリを除外」のどちらが有効か確認してください。二つのリストは意味が逆です。アイコンを選択したからといって、そのアプリの通信が必ずプロキシに入るとは限りません。まず確認用のアプリを一つ選び、接続を停止してから再開し、アプリの対象範囲を反映させます。必要に応じて、テスト対象のアプリも完全に終了して再起動してください。そのアプリが独自のDNS、固定アドレス、ネットワークコンポーネントを使用している場合は、ログでリクエストがクライアントに入っているかも確認します。ブラウザーが成功しただけで、すべてのアプリが接続できているとは判断できません。

ロック後に切断する場合は、システムのバッテリー管理、バックグラウンド実行、自動起動の権限を確認します。設定画面の名称は端末によって異なるため、クライアントがバックグラウンドでも接続を維持できるようにしてください。システム全体の省電力機能を無効にする必要はありません。クライアントの動作通知を表示したまま、サービスがシステムによって停止されていないか確認します。通知が消えた、プロセスが再起動した、リモート接続がタイムアウトした、という状況はそれぞれ異なる証拠です。同じネットワークとノードで画面点灯時とロック時を比較し、失敗までの時間を記録してから、必要に応じてバッテリー最適化の対象外にします。

ネットワーク切り替えとモバイルデータ通信を個別に確認

Wi-Fiからモバイルデータ通信へ切り替えると、既存の接続が無効になり、DNSや接続先アドレスが変わることがあります。まず接続を停止し、スマートフォン自体がネットワークに接続できていることを確認してから、接続し直します。公衆Wi-Fiでログインが必要な場合は、先にネットワークの認証を済ませてください。未認証のネットワークでは、リクエストがログインページへリダイレクトされ、サブスクリプション更新と接続の両方に失敗する場合があります。モバイルデータ通信だけで問題が起きる場合は、現在のSIMのデータ通信権限、通信量制限、クライアントのモバイル通信許可を確認します。ノードのプロトコルは、最初に変更しないでください。

モバイルネットワークによっては、主にIPv6を提供したり、アドレス変換を使用したりします。デスクトップのIPv4テスト結果だけで、スマートフォンの接続経路を判断しないでください。クライアントログに記録されたアドレスファミリーと名前解決エラーを確認し、同じノードをWi-Fiとモバイルデータ通信で比較します。システムのプライベートDNS設定が、ノードの接続先の名前解決に影響する場合もあります。一時的にシステムの自動設定へ戻して比較できますが、テスト後は元の設定に戻してください。接続方法、DNS、ノード設定を同時に変更しないでください。復旧しても原因が分からなくなり、正常だったデータ通信に影響するおそれがあります。

インストールに失敗した場合は、まずパッケージのアーキテクチャとシステムのインストール案内を確認します。比較的新しい一般的な端末ではarm64を選べますが、判断できない場合はAndroidのダウンロード案内に従って適切な方法を選んでください。汎用パッケージはサイズが大きいことがありますが、接続性能が高いという意味ではありません。更新時は同じクライアントの設定をバックアップしてください。v2rayNGとv2flyNGのバックアップ全体を相互に上書きしないでください。端末間の移行には、互換性のあるサブスクリプションまたはノード共有方法を使います。詳しくはPCとAndroid間の設定移行をご覧ください。

最後に「アプリが通信の取り込み対象か」「カーネルがリクエストを受け取るか」「ノードとの接続が確立するか」「接続先から応答が返るか」の順に確認します。同じWi-Fiとノードを使っているのにデスクトップとスマートフォンで結果が異なる場合は、権限、アプリ別の対象範囲、DNSを比較します。両方で失敗する場合は、ノードとネットワーク経路を確認してください。相談する際は、OSのバージョン、クライアント名、ネットワークの種類、画面ロックとの関連、機密情報を除いたエラーを伝えます。複数のクライアントを次々に試すより、再現可能な最小構成を保つ方が、問題の発生箇所を特定しやすくなります。