v2rayNのトラブル対処ガイド

診断の順序 › アプリの入口 › ローカル待ち受け › 外部への接続

インターネットに接続できない：「接続済み」の状態を切り分ける

メイン画面でサーバーを選択していること、コアが実行中であること、システムプロキシが有効であることは、それぞれ別の状態です。ノードが選択中でも、リモートとのハンドシェイクが成功したとは限りません。「すべてのアプリで開けない」「ブラウザーだけ失敗する」「一部のドメインだけ失敗する」のどれに当たるかをまず確認しましょう。使用中のクライアント、OS、プロキシモード、問題が発生し始めた日時も記録しておくと、後から比較できます。

直接接続とプロキシ接続を切り分ける

まずv2rayNのトレイメニューから「システムプロキシ → システムプロキシを解除」を選び、TUNモードも一時的にオフにします。通常、直接接続できるWebサイトにアクセスし、端末自体がインターネットに接続できているか確認してください。ホテル、学校、公共のWi-Fiでは、先に認証が必要な場合があります。プロキシを解除しても何も開けない場合は、ネットワークへの接続、ゲートウェイ、システムDNSを先に確認し、ノードの設定は変更しないでください。テスト後は「システムプロキシを自動設定」に戻します。

続いて、ほかのプロキシアプリやブラウザー拡張機能を終了し、v2rayNだけで試します。複数のアプリがシステムプロキシの設定を書き換えると、画面の表示と実際の設定が食い違うことがあります。特定のブラウザーだけで問題が起きる場合は、一時的な新規プロファイルで再確認し、既存の拡張機能、キャッシュ、セキュリティ設定の影響を除外しましょう。元の設定は削除せず、問題を再現できる環境を残しておくと原因の特定に役立ちます。

ローカルの混合待ち受けポートを確認する

「設定 → パラメーター設定 → Core: 基本設定」を開き、「ローカル混合ポート」を確認します。以下のコマンドはポート番号を10808として記載しています。実際の値が異なる場合は、コマンド内の番号も変更してください。プロキシを明示して接続すると、システムプロキシを介さずに、クライアントのローカル待ち受けと外部接続を確認できます。Windows PowerShellでは、同名の別コマンドとの混同を避けるため、curl.exeを使用します。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

HTTPレスポンスヘッダーが返れば、そのリクエストではプロキシ経由の接続が完了しています。ただし、すべてのWebサイトにアクセスできることを示すものではありません。ローカルアドレスにすぐ接続できない場合は、コアが起動しているか、ポートが使用中でないか確認します。応答を待ってタイムアウトする場合は、リモート接続とDNSを調べてください。証明書エラーが出た場合は、システム時刻と接続先の証明書を確認し、証明書検証を安易に無効化しないでください。接続先のサイト自体に問題がないか、別の既知のテスト先でも確認しましょう。

ログから入口・ルーティング・ハンドシェイクを切り分ける

メイン画面のログ欄を開き、古い表示を消してからリクエストを1回だけ送信し、同じ時刻のログを確認します。該当する記録がまったくない場合、リクエストがクライアントに届いていない可能性や、アクセスログが無効になっている可能性があります。明示的にプロキシを指定したテストも行い、「ログがない」ことだけで原因を決めつけないでください。ローカル接続の記録があれば、宛先ドメイン、アウトバウンドタグ、エラーの種類を確認し、想定した出口にルールが振り分けているか調べます。

「ログレベル」を一時的にinfoにすると、起動時の状態やエラーの前後関係を確認しやすくなります。アクセスログが出力されるかどうかは、使用中のコアやログ設定にも左右されます。再現後はwarningに戻し、ログが大量に増え続けないようにしてください。ログを共有する前に、サブスクリプションURL、サーバーアドレス、ユーザー識別情報、認証情報を削除し、エラー文、宛先の種類、発生順だけを残しましょう。

確認結果に応じて対処し、同時に再インストールしない

明示的なプロキシ接続は成功するのにブラウザーで失敗する場合は、システムプロキシが効かないを確認します。ローカルポートは正常でもすべての外部接続がタイムアウトする場合は、ノードのタイムアウトへ進みます。ドメイン名でのアクセスだけ失敗する場合は、DNSとルーティングの名前解決を調べてください。特定のWebサイトだけで失敗する場合は、ノードと直接接続の両方で結果を比べ、サイト側のアクセス制限をクライアント全体の障害と誤認しないようにしましょう。

修復後は、元のブラウザーとネットワーク環境に戻して再確認し、一時的な環境でしか成功していない状態を避けましょう。手順を簡潔に確認するには、接続済みなのにWebページを開けないときの確認メモも参考になります。最終的に有効だった変更だけを残し、調査中に追加したルールは元に戻してください。一時設定が次回のトラブルを見えにくくするのを防げます。

診断の順序 › サーバーアドレス › 通信ポート › プロトコルのハンドシェイク

ノードがタイムアウトする：TCP接続とプロトコルの利用可否を分けて確認

V2Rayの遅延テストには複数の種類があります。Tcpingは主にサーバーの指定ポートへの接続状況を示します。実接続テストでは通常、選択中のプロキシ設定を使ってテスト先にリクエストを送ります。Tcpingに成功しても、認証やTLS、通信方式が正しいとは限りません。実接続テストに失敗しても、テスト先にアクセスできない可能性があります。測定方法とエラー全文を記録し、異なる指標を同じ基準で比べないようにしましょう。

まずアドレスの名前解決とポートへの接続を確認する

ノードの編集画面を開き、サーバーアドレスに不要な空白がないか、ポートがサーバー情報と一致しているか確認します。アドレス欄には通常、ホスト名またはIPアドレスを入力します。パスを含むWebページのURL全体を貼り付けないでください。ドメイン名を解決できない場合は、現在のネットワークの名前解決を先に確認します。接続拒否と接続タイムアウトは別の状態です。前者は接続先に到達できてもポートで接続を受け付けていない場合が多く、後者は通信経路、ファイアウォール、リモート側の応答に関わります。

WindowsではTest-NetConnectionでサーバーポートへの接続を確認できます。コマンド内のアドレスは実際のサーバーアドレスに置き換えてください。この結果で分かるのは接続性だけです。Webサイトのポートをノードのポートの代わりに使わないでください。同じノードがモバイルホットスポットでは使えて自宅のネットワークでは使えない場合は、プロトコル設定をすぐに変更せず、両方のネットワークのDNS、IPv6、外部接続の制限、セキュリティソフトのルールを比較します。

TLS・通信方式・認証の設定を確認する

TCP接続は成功するのにハンドシェイクに失敗する場合は、提供元の元の設定を参照し、ユーザーID、パスワード、通信方式、TLSの有効・無効、サーバー名、パスを確認します。WebSocketのパスやHostはサーバーアドレスとは異なります。gRPCのサービス名も任意のメモではありません。項目を空欄にしてよいかはサーバー側の設定によるため、別のノードと同じ値を入れないでください。1項目だけ変更して再確認し、失敗する場合は元の値に戻します。

REALITYを使うノードでは、サーバーから指定された公開鍵、Short ID、サーバー名も一致させる必要があります。サブスクリプションの値を独自に生成した値へ置き換えないでください。サーバー名がWebサイトのように見えても、サーバーのIPアドレスに変更しないでください。プロトコルの各パラメーターは相互に関係しており、1項目だけを「最適化」すると設定全体が機能しなくなることがあります。インポート後に項目が欠けている場合は、クライアントと選択中のコアがその設定に対応しているか確認し、提供元に問い合わせてください。

証明書の有効期間切れ、ホスト名の不一致、ハンドシェイク検証エラーが出る場合は、まずシステムの日付、時刻、タイムゾーンを合わせ、証明書の名前がサーバー名と一致しているか確認します。社内ネットワークのHTTPS検査が接続に影響することもあります。「安全でない接続を許可する」を一般的な解決策として使わないでください。証明書の検証条件が変わるうえ、ポートへの接続不可、パスワードの誤り、通信パスの不一致は解決できません。

複数の条件で比較して原因を絞り込む

テスト先を固定し、まず同じサブスクリプション内の2つのノードを比較し、次に同じノードを異なるネットワークで試します。1つのノードだけ失敗するなら、ノードの設定またはサーバー側の問題が考えられます。すべてのノードが同時に失敗する場合は、ローカルネットワーク、コアの起動状態、サブスクリプションの有効期限を確認してください。特定のプロトコルだけ失敗する場合は、選択中のコアが対応しているか、その通信方式で共通する項目に誤りがないか調べます。サブスクリプション全体を削除する必要はありません。

テスト方法ごとの限界を理解する

実接続テストの宛先は固定し、テスト先を変更した場合は以前の結果とそのまま比較しないでください。サイトによっては自動リクエストやリダイレクトを制限したり、特定の出口からのアクセスを拒否したりするため、テスト失敗がプロキシ全体の利用不可を意味するとは限りません。ブラウザーで実際にWebページを開き、同じ時刻のログも確認すると、自動テストでは検証できない部分を補えます。

それでもタイムアウトする場合は、問い合わせ時にプロトコルの種類、通信方式、TLSの有無、同じノードを別のネットワークで試した結果、個人情報を伏せたエラーを伝えてください。共有リンク全体を公開しないでください。初回のノード選択と確認手順は初回接続・実接続速度テスト・プロキシの確認方法を参照してください。クライアントのダウンロードとプラットフォームの選択はダウンロードページで行えます。

診断の順序 › サブスクリプションへのリクエスト › レスポンス内容 › ノードの解析

サブスクリプションを更新できない：ダウンロードと解析を分けて確認

サブスクリプションの更新は、内容の取得と、取得した内容をクライアントが認識できるノードに解析する処理に分かれます。ネットワークのタイムアウト、認証エラー、内容形式の非対応では、対処方法が異なります。まず「サブスクリプショングループ設定」を開き、どのグループを更新したか確認してから、今回の更新ログを見てください。同じURLを何度もインポートして重複グループを増やすと、以前のノードと今回の更新結果を区別しにくくなります。

URLが完全か、アクセス権が有効か確認する

サブスクリプショングループを編集し、URLの先頭、末尾、クエリパラメーターを確認します。チャットアプリが長いURLを途中で切ることがあり、コピー時に改行や全角の句読点が混入する場合もあります。認証情報を含むサブスクリプションURLはアクセス用の資格情報です。公開Webページやオンライン変換サービス、スクリーンショットに載せないでください。提供元がURLを再発行した場合、古いURLを開けても有効なノードが返るとは限りません。

サブスクリプションの期限切れ、データ通信量の上限、アカウント権限の変更により、ノード一覧ではなく案内ページが返されることがあります。HTTP認証エラーやアクセス拒否が発生した場合は、まず提供元のアカウントページで状態を確認してください。認証エラーをクライアントの設定不足と決めつけたり、URL内の識別情報を変更して権限を回避しようとしたりしないでください。URLとアカウントの状態が有効だと確認してから、次のネットワーク診断へ進みます。

直接接続での更新とプロキシ経由の更新を分ける

v2rayNの「サブスクリプショングループ」メニューには、通常、サブスクリプションの更新とプロキシ経由での更新があります。具体的な表示名はバージョンによって異なります。直接接続での更新に失敗しても、既存のノードが使える場合は、利用可能なプロキシ経由で更新を試せます。逆に現在のノードが使えない場合は、プロキシ経由の更新も失敗します。使える別のノードに切り替えるか、直接接続で更新できるか試し、問題のある出口に更新リクエストを固定して何度も再試行しないでください。

直接接続とプロキシ経由の両方で失敗する場合は、エラーが発生した段階を確認します。ドメインの名前解決エラーならDNS、接続タイムアウトならネットワーク経路、TLSエラーなら時刻と証明書の環境を調べてください。ブラウザーでサブスクリプションURLを開けても、クライアントが内容を取得できるとは限りません。ブラウザーとクライアントではプロキシ、ログイン状態、セキュリティ確認の手順が異なる場合があります。比較する際は、両方が同じネットワークの入口を使っているか確認しましょう。

ダウンロードできてもノードが表示されない場合の確認手順

更新ログでリクエストが成功しているのにノード数が変わらない場合は、返された内容がWebページ、エラー案内、非対応形式のどれかを確認します。サーバーが成功のステータスコードを返していても、ログインページだけが返されることがあります。標準の共有リンク、エンコードされたノード一覧、他のクライアント専用の設定は、それぞれ異なる形式です。拡張子やURLに「サブスクリプション」と書かれているだけで、v2rayNに対応していると判断しないでください。

一部のノードだけインポートに失敗する場合は、失敗したノードのプロトコル、通信方式、共通項目を比較します。古いクライアントでは新しいパラメーターを認識できないことがあります。その場合は設定をバックアップしてから、v2rayNのダウンロードページでシステムに合ったインストーラーを選び、更新してください。内容を理解せずに項目を手動で削除してインポートを試みないでください。認証や通信に必要な項目が欠けたノードは、一覧に表示されても接続できません。

ノードが「更新されない」原因が、フィルターの場合もあります。現在のグループ、キーワードフィルター、一覧の並び順を確認し、新しいノードが隠れていないか調べてください。サブスクリプショングループにフィルター条件が設定されていないか確認し、更新前後の備考とサーバーアドレスを比較します。備考が変わってもサーバーが追加されたとは限りません。重複ノードがあるからといって更新失敗とも限らないため、ログと実際の内容を基準に判断しましょう。

旧設定を残し、元に戻せる更新手順にする

更新前に現在使える設定をエクスポートし、グループ設定を記録しておきます。バックアップファイルには機密性の高いノード情報が含まれるため、安全な場所に保管してください。特定のサブスクリプション形式に問題がある場合は、一時的なグループを作って個別にテストします。成功したら元のグループを置き換えるか検討し、失敗した場合は一時グループだけを削除すればよく、すべてのサーバーを消去する必要はありません。一括削除、重複削除、上書きの前には、対象範囲を確認してください。

トラブル対処が終わってから、自動更新を有効にするか検討します。起動のたびに更新が始まって止まる場合は、まず自動タスクを一時的に無効化し、手動更新が安定して完了するか確認してください。自動再試行では、無効なURLや非対応形式は解決しません。最初のエラーを確認しにくくなることもあります。「どの更新方法を、どのネットワークで、どのグループに使ったか」を記録すると、「再起動したら直った」という記録より再現に役立ちます。

診断の順序 › 基準となる速度の比較 › 出口の負荷 › 通信経路

速度が遅い：遅延・スループット・アプリの応答を分けて確認

Webページの表示が遅い、ダウンロード速度が低い、動画が頻繁に止まるといった症状は、必ずしも同じ原因ではありません。接続遅延はリクエスト開始時の待ち時間に影響し、スループットは継続的なデータ転送能力を示します。パケットロスや再送があると、速度が不安定になることもあります。遅延の小さいノードが大容量の転送に向いているとは限りません。最初の表示だけが遅いのか、ダウンロード中ずっと遅いのか、しばらく使ってから遅くなるのかを整理し、症状に合った方法で比較しましょう。

条件をそろえて速度の基準を取る

まずクラウドストレージの同期、システム更新、ほかのダウンロードを一時停止します。テストする端末、Wi-Fiの場所、接続先、時間帯もできるだけそろえてください。複数ノードの速度テストを並行して実行しながらブラウザーの速度を評価しないでください。複数のリクエストが帯域を取り合います。同じ実作業を2つのノードで何度か行い、差が継続しているか確認します。単発のピーク値はキャッシュや一時的な空き時間の影響かもしれず、普段の性能を示すとは限りません。

次に、システムプロキシを解除してTUNをオフにし、通常のネットワーク速度を確認します。直接接続でも明らかに遅い場合は、Wi-Fiの電波、ルーターの負荷、回線の使用状況を調べます。有線LANを使える場合は、有線でも比較してください。モバイルホットスポットは別のネットワークとの比較には使えますが、元のネットワークと同じ帯域幅があるとは限りません。基準となる接続が不安定なままプロキシの設定を調整すると、結果が矛盾しやすくなります。

ノードの負荷と接続先の制限を比較する

同じ時間帯に特定のノードだけ遅い場合、出口の負荷、回線品質、その出口から接続先までの経路が原因かもしれません。同じ接続先へのアクセスをノード間で比較し、改善が繰り返し確認できるか調べます。ダウンロードサイト1つだけが遅く、ほかのサイトは正常な場合は、接続先の速度制限、ログインプラン、同時接続数、コンテンツ配信の設定も考慮してください。出口を変えると接続経路は変わりますが、サーバー側の制限が解除されるとは限りません。

ノードの所在地名だけで、実際の回線品質を判断しないでください。備考は目印にすぎず、実際の経路は提供元の設備やネットワーク間の接続にも左右されます。ピーク時間帯に遅く、時間をずらすと改善する場合は、ローカルの待ち受けポートを変更するより、混雑状況に注目しましょう。時間帯ごとの実作業の結果と接続エラーを記録して提供元に伝えると、単独の遅延値を送るより状況を共有しやすくなります。

ルーティング、UDP、TUNの影響を確認する

まず、遅いリクエストがどのアウトバウンドを通ったか確認します。ダウンロードがドメインルールによって直接接続されている場合や、ブラウザーが独自のプロキシ拡張機能を使って別の出口を通っている場合があります。「ルーティング設定」の現在のプリセットとカスタムルールを確認し、必要であれば範囲を限定した一時ルールで比較します。確認後は必ず元に戻してください。速度テストのためにプライベートネットワーク宛ての通信をすべてプロキシに通すと、LANのサービスやローカル機器へのアクセスに影響するため避けましょう。

アプリによってはUDPやQUICを使います。ノードが必要な通信に対応していないと、待機後に別の方式へ切り替わり、最初は遅いのにその後は正常に見えることがあります。「UDPを有効にする」はローカル側の処理を許可する設定であり、リモート側にUDP対応を追加するものではありません。まず通常のHTTPSリクエストを基準にし、その後アプリ固有の通信方式を比較します。ブラウザーのプロトコル設定を変更する場合は、元の値を記録し、テスト後に戻してください。

TUNモードでは、仮想ネットワークアダプター、ルーティングの引き継ぎ、システム権限も関係します。TUN使用時だけ遅い場合は、まずTUNをオフにし、明示的なプロキシで同じ作業を試します。明示的なプロキシで正常なら、TUNのルート、DNSの引き継ぎ、ほかの仮想ネットワークアダプターとの競合を調べましょう。MTUの不一致は特定の経路に影響することがありますが、ネット上の数値をそのまま適用しないでください。大きなパケットで異常があり、小さなリクエストは正常といった証拠を確認してから、1項目ずつ調整します。

効果のない最適化を避け、長期的な速度を確認する

接続の再利用、通信パラメーター、コアの選択は、設定を増やすほど速くなるわけではありません。サーバー側が対応していない機能を有効にすると、互換性の問題が増えることがあります。サブスクリプションの既定の通信設定は維持し、まず確認できるパケットロス、出口の負荷、ルーティングの誤りに対処してください。コアを変更して速くなった場合も、同じノードとルールを使っているか確認し、異なる経路の差をコア自体の効果と混同しないようにしましょう。

最後は速度テストのページだけでなく、普段使うアプリを続けて使い、状況を確認します。応答が遅くなる段階、接続エラーの有無、ノードやネットワークの変更で復旧するかを記録しましょう。ルールの一致が関係する場合は、geosite・geoipを使ったルーティング設定も参照してください。速度の調査では安定したボトルネックを見つけることが大切です。設定を何度も切り替えて、たまたま速くなった結果を探すのが目的ではありません。

診断の順序 › システムの名前解決 › コアのDNS › ルーティングでの名前解決

DNSの問題：どの層でドメインを解決しているか確認する

同じドメインでも、システムの名前解決、ブラウザーのセキュアDNS、コアのDNS、プロキシサーバー側での名前解決など、経路が異なる場合があります。システムDNSを変更しても結果が変わらないからといって、設定が保存されていないとは限りません。リクエストがそのDNSを使っていない可能性があります。使用中のアプリ、プロキシの入口、ノードの種類を記録し、ログに名前解決エラーが出ているか確認してください。名前解決が行われる場所を特定してから、システム設定とコア設定のどちらを変更するか判断します。

ドメインのエラーと接続エラーを区別する

ログに出る「ドメインが存在しない」「名前解決のタイムアウト」「接続先へのタイムアウト」は、別々に対処する必要があります。名前解決に成功しても、得られたIPアドレスが正しいことや、接続できることまでは保証されません。また、「IPアドレスには接続できるが、ドメイン名では接続できない」ことだけでDNSの問題と断定しないでください。HTTPSでIPアドレスに直接アクセスすると、証明書の名前、SNI、仮想ホストの影響で失敗することがあります。DNS自体の異常とは限りません。

システムの名前解決結果は、ターミナルでnslookup example.comを実行して確認できます。ただし、このツールは通常、ブラウザーのセキュアDNSを使わず、v2rayNのコアDNS設定も自動では利用しません。システム層の確認には便利ですが、プロキシ経由のリクエストにおける名前解決経路を単独で証明することはできません。比較する際は使用したDNSリゾルバーを記録し、異なる経路の結果をそのまま比較しないようにしましょう。

domainStrategyが適用される範囲を理解する

routing.domainStrategyは、ルーティングルールとの照合でドメイン名と解決済みIPアドレスをどう使うかを制御します。AsIsは、ルールの判定にドメイン名をそのまま使います。IPIfNonMatchは、ドメイン名のルールに一致しない場合、名前解決を試みてIPアドレスのルールと照合します。この設定は「すべてのDNSリクエストをプロキシ経由にする」ためのスイッチではなく、アプリやシステムのDNS設定を置き換えるものでもありません。

以下はXray/V2Ray形式の一部設定例で、項目間の関係を説明するためのものです。クライアントで使える完全な設定ではありません。使用するコアの設定体系に合わせて統合し、直接接続用のアウトバウンドタグがdirectであることを確認してください。v2rayNのGUIによるルーティング設定から構成を生成できるため、実行時の一時ファイルを直接変更するのは避けましょう。次回起動時に上書きされることがあります。ルールが参照するデータも必要です。

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

DNSサーバー自体に到達できるか確認する

DoHを設定する場合は、DNSサーバーのアドレス、証明書の検証、サーバーまでの通信経路も考慮する必要があります。DoHは通信を暗号化しますが、リクエストが直接接続とプロキシのどちらを通るかを自動で決めるものではありません。DNSサーバーのドメイン名を解決する必要があり、その接続経路がまだ確立していないプロキシに依存すると、起動時の依存関係が循環することがあります。使用中のコアが対応するブートストラップDNSやルーティング方法を考慮し、URLを変えるだけで済ませないでください。

まず既知の動作するDNS設定に戻し、基本的な名前解決ができることを確認してから、ルーティングを1項目ずつ追加します。コアによってDNS関連の項目は異なるため、あるコア用の設定を別のコアに貼り付けないでください。画面上の「DNS設定」と「TUNモード設定」は別々の処理を管理している場合があります。実際に使っているコアと通信を引き継ぐ範囲を確認してから、設定する場所を決めましょう。

IPv6を有効にしたときだけ一部のサイトがタイムアウトする場合は、ネットワークアダプターにIPv6アドレスが表示されているかだけでなく、利用可能なIPv6ルートがあるか確認します。IPv6のレコードを取得できても接続が完了しないネットワークがあります。管理された設定でIPv4のみの結果と一時的に比較する方法はありますが、すべてのDNS障害に対する既定の対処としてIPv6を無効にしないでください。修復後は、元のIPv6利用要件も改めて確認しましょう。

キャッシュを整理して名前解決の経路を確認する

設定を変更した後は関連アプリを終了して再起動し、必要に応じてWindowsでipconfig /flushdnsを実行し、システムのDNSキャッシュを消去します。このコマンドでは、ブラウザー、コア、サーバーのキャッシュは消去されません。再テストでは同じドメインを使い、名前解決エラーが接続エラーに変わったか確認します。エラーの段階が変わったなら調査は進んでいます。「まだ直っていない」とだけ判断しないでください。

オンラインDNSテストで分かるのは、そのテスト方法から観測できる名前解決の出口であり、すべての通信経路の証明ではありません。ブラウザーのセキュアDNS、キャッシュ、プロキシモードも結果に影響します。ルーティングの詳細はDNSとDoHの設定メモを、通信経路の確認はDNSリークテストと防止設定を参照してください。まず想定する名前解決の出口を決めてから、テスト結果が想定と異なるか判断しましょう。

診断の順序 › アプリのプロキシ › システムの入口 › TUNによる通信の引き継ぎ

システムプロキシが効かない：アプリが設定を利用しているか確認する

「システムプロキシを自動設定」は、主にローカルのプロキシ入口をOSの設定に登録する機能です。すべてのアプリがその入口を利用するわけではありません。独自のプロキシを使うアプリ、環境変数だけを参照するアプリ、ソケットを直接開くアプリもあります。何度もオンにするのではなく、対象アプリがどの入口を使うか、その入口が現在待ち受け中のアドレスとポートを指しているかを確認しましょう。

システム設定と実際の待ち受けを照合する

v2rayNのメイン画面下部またはトレイメニューで「システムプロキシ → システムプロキシを自動設定」を選び、Windowsの「設定 → ネットワークとインターネット → プロキシ」を開いてアドレスとポートを確認します。アドレスは通常、ローカルのループバックアドレスを指します。ポートは「ローカル混合ポート」と一致している必要があります。設定がすぐに書き戻される場合は、ほかのプロキシアプリ、管理ツール、組織のポリシーが設定を管理していないか確認してください。

以下のコマンドで、よく使われるポートの待ち受け状態を確認できます。出力がない場合は、実際のポート番号が異なっていないか確認してから、コアのプロセスを調べます。出力があっても、待ち受けているのがv2rayNとは限りません。プロセスIDからアプリを特定してください。調査のためにシステムプロセスをむやみに終了しないでください。ほかのアプリがポートを使用中の場合は空いているポートに変更できますが、システム設定とアプリに手動で設定したポートも合わせて変更する必要があります。

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

ローカル端末のアプリで使うために「LANからの接続を許可」を有効にする必要はありません。この設定は待ち受けの到達範囲を広げるものであり、システムプロキシを無視するアプリに設定を読み込ませるものではありません。ほかの端末からこのPCへ接続する必要がある場合に限り、待ち受けアドレス、ファイアウォール、アクセス範囲をあわせて検討してください。調査が終わったら、元の最小限の待ち受け範囲に戻し、一時的な設定をそのまま残さないようにしましょう。

ブラウザーとコマンドラインの独自設定を除外する

ブラウザーのプロキシ拡張機能、企業ポリシー、ブラウザー独自の設定がシステムプロキシより優先されることがあります。まず拡張機能を無効にしてブラウザーを再起動し、プロキシを明示したリクエストの結果と比較します。コマンドラインツールは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を参照する場合があります。古いターミナルには起動時の環境変数が残るため、変更後は新しいターミナルを開いてください。元のウィンドウで同じリクエストを繰り返すだけでは不十分です。

WindowsのユーザープロキシとWinHTTPプロキシは、設定の参照元が完全には同じではありません。netsh winhttp show proxyでは後者を確認できますが、直接接続と表示されても、通常のブラウザーがユーザープロキシを使っていない証明にはなりません。すべてのアプリに影響する全体リセットコマンドを安易に実行しないでください。まず対象プログラムがどの設定を参照するかを特定し、公式のプロキシ設定を確認しましょう。システムサービスや組織の設定に影響するのを避けられます。

PAC・ルーティングルール・アプリのプロキシ回避を区別する

PACを使っている場合、スクリプトによってどのリクエストをプロキシの入口に送るかが決まります。コアのルーティングは、リクエストがクライアントに入った後に使用するアウトバウンドを決めます。これは別々の2段階です。Webサイトへのアクセスがプロキシログに出ない場合、PACで直接接続になったか、アプリがシステムプロキシを使っていない可能性があります。原因を絞るには、明示した手動のローカルプロキシ入口に一時的に切り替えてテストし、その後コアのルールを確認します。両方を同時に変更しないでください。

リクエストがコアに届いているのに誤った出口へ送られる場合は、「ルーティング設定」のルール順を確認します。詳細なルールが広範なルールより先に判定されるようにし、LANへのアクセス要件も維持してください。ドメインの判定は、通信の識別方法やDNSの設定にも左右されます。最終IPだけを見て、どのルールに一致したかを推測しないでください。リダイレクト先の別ドメインが判定に混ざらないよう、同じURLと同じブラウザーで再確認しましょう。

必要な場合にのみTUNの引き継ぎ条件を確認する

対象アプリがプロキシの入口に対応していない場合は、TUNモードの利用を検討できます。有効にする前に、通常のシステムプロキシ経由の接続が動作することを確認し、OSの要件に従って仮想ネットワークアダプターとルート管理の権限を付与してください。TUNはリモートノードの障害を直すスイッチではありません。明示的なプロキシでも失敗する場合は、まずノード接続を解決します。有効にした後は、ほかの仮想プライベートネットワーク、仮想マシンのアダプター、セキュリティソフトもルートを変更していないか確認し、二重の引き継ぎを避けましょう。

macOSとLinuxでは、デスクトップのプロキシ設定方法が異なります。また、アプリがデスクトップの設定に従うかどうかにも差があります。Windowsの設定パスをそのまま使わないでください。基本設定をやり直す場合は、チュートリアルのシステムプロキシ設定に戻ります。調査後は不要なプロキシツールを終了し、アプリとクライアントを再起動しても設定が一致していることを確認してください。

診断の順序 › GUI › コアのプロセス › 実行環境

クライアントがクラッシュする：GUIの終了とコアの終了を切り分ける

ウィンドウが開かない、起動直後に閉じる、コアが繰り返し再起動する、接続後に終了するのは、それぞれ異なる問題です。最後に正常に動作したときと最近の変更を記録します。クライアントの更新、ディレクトリの移動、カスタム設定のインポート、TUNの有効化などを確認してください。すぐにディレクトリ全体を削除しないでください。設定、ログ、実行ファイルを一緒に消去すると、原因を再現する手がかりが失われることがあります。

OS・アーキテクチャ・インストール先を確認する

ダウンロードページでプラットフォームとプロセッサーに合ったインストーラーを選びます。Windowsのデスクトップ版と従来のWPF版ではUIの構成が異なりますが、設定ディレクトリを自由に上書きできるわけではありません。macOSではApple SiliconとIntelを区別します。Linuxではディストリビューションに合ったパッケージ形式とプロセッサーアーキテクチャを選んでください。パッケージを間違えた場合は選び直し、ファイル名の変更や別アーキテクチャのファイルの混在で起動を試みないでください。

展開したディレクトリから実行する場合は、圧縮ファイルのプレビューから直接開かず、まずすべてのファイルを展開します。ディレクトリに書き込み可能で、ディスク容量があり、権限の制限された一時フォルダーではないことを確認してください。ポータブル版とインストール版では設定の保存場所が異なる場合があります。思い込みでバックアップをプログラムのディレクトリに上書きしないでください。移行や更新の前に、クライアントのエクスポート機能または実際のデータディレクトリからバックアップを作成します。

最小限の設定でデータの問題を切り分ける

バックアップを作成した後、別のディレクトリまたは独立したユーザーデータ環境で、同じプラットフォームのクライアントを起動します。古い設定は読み込まず、空の設定で安定して起動するか確認してください。同じポートを2つのインスタンスで同時に使わないでください。新しい環境で正常に動作する場合は、サブスクリプション、ルーティング、DNSの設定を種類ごとにインポートし、そのたびに再起動して確認します。データの破損か、特定のカスタム機能が原因かを絞り込めます。

空の設定でも起動直後に終了する場合は、システムのエラーログと実行環境のメッセージを確認します。Windowsではイベントビューアーのアプリケーションログから障害モジュールを確認できます。macOSではシステムが作成するクラッシュレポートを、LinuxではターミナルからGUIアプリを起動して起動時のエラーを確認します。最後の画面だけを撮影するのではなく、エラー文を記録してください。必要なランタイムは使用するインストーラーの説明を確認し、出所不明のページから任意のコンポーネントを追加しないでください。

コアが終了する場合は最初のエラーを確認する

GUIは正常でもコアが動作を続けられない場合は、起動ログに最初に出た明確なエラーを確認します。待ち受けポートの競合、無効な設定項目、ルール用データの不足、権限不足などが、その後に連続する接続エラーの原因になっていることがあります。最初のエラーに対処してから再起動し、残りの問題を確認してください。最後に表示された「接続が拒否されました」を根本原因と決めつけないでください。コアがすでに終了した結果として表示されている可能性があります。

カスタム設定を使用している場合は、構文が正しいこと、アウトバウンドタグが存在すること、ルールが参照するデータを利用できることを確認します。コアごとに設定項目は異なります。コアを切り替えた場合は、関連するカスタム設定も確認してください。自動生成された実行用設定は次回起動時に再生成されることがあります。修正はGUIの設定またはカスタム設定の元データに反映してください。新しいルーティングを追加したときだけエラーが発生するなら、クライアントとノードを同時に変更せず、まずその設定だけを元に戻します。

更新・ロールバック・セキュリティソフトの確認

更新後に問題が発生した場合は、エラーと旧設定を保存してから、隔離した環境で更新前後の動作を比較します。古いプログラムファイルをすべて新しいディレクトリに上書きしないでください。実行ファイルが混在し、新たな互換性の問題が生じる可能性があります。ロールバックが必要な場合は、以前保存した出所の明確な完全なインストーラーを使い、現在のデータも別途保存してください。新旧の設定形式が互いに上書きされるのを防げます。

セキュリティソフトがブロックしている場合は、具体的な記録、ファイルパス、発生時刻を確認し、起動失敗と関係しているか判断します。すべての保護機能を無効にしたり、ディスク全体を除外対象にしたりしないでください。職場や学校の管理端末では、管理者に許可範囲を確認します。修復後は残っているシステムプロキシ設定を解除し、クライアントを再起動して実際に接続します。GUIとコアの両方が安定して動作することを確認してください。

診断の順序 › VPNの許可 › アプリごとの振り分け › バックグラウンド・ネットワーク切り替え

Androidのトラブル：接続許可・アプリ別設定・バックグラウンド切断

Androidではv2rayNGを推奨します。v2flyNGはV2Flyコアを採用した代替クライアントです。デスクトップの「システムプロキシ」の考え方をAndroidにそのまま当てはめることはできません。通常、クライアントはシステムのVPNインターフェースで通信を引き継ぎ、設定に基づいて外部への接続を決めます。VPNのアイコンが表示されても、確立しているのはシステムとの通信経路だけです。リモートノードで認証に失敗したり、タイムアウトしたりすることはあるため、実際のアクセス結果とログを確認してください。

初回起動とVPNの許可

ノードをインポートして接続先を選び、接続を開始したときに表示されるシステムのVPN許可ダイアログを確認します。許可画面が表示されない、または別の画面の背後に隠れている場合は、クライアントを前面に戻して再試行し、ほかのVPNアプリが動作中でないか確認してください。Androidでは通常、現在のユーザーのVPN接続を使用できるアプリは1つだけです。2つのクライアントを交互に起動すると接続が入れ替わり、原因不明の切断に見えることがあります。

Androidのダウンロードページで、端末のアーキテクチャに合ったインストーラーを選んでください。比較的新しい端末の多くはarm64を使用します。アーキテクチャが分からない場合は、システム情報を確認するか汎用版を選びます。インストールに失敗した場合は、OSのバージョン制限、インストール権限、署名の競合、ストレージ容量を切り分け、同じファイルを何度もダウンロードしないでください。署名の不一致で上書きできない場合は、まず設定をエクスポートし、アンインストールと再インストールがデータに与える影響を確認します。

アプリ別プロキシ設定とルーティングモードを確認する

ブラウザーは使えるのに特定のアプリだけ接続できない場合は、クライアントのアプリ別プロキシ設定を確認します。「選択したアプリだけをプロキシする」と「選択したアプリをプロキシから除外する」のどちらを使っているか確認してください。両者の動作は逆です。システムアプリ、仕事用プロファイル内のアプリ、通常のユーザープロファイルのアプリは、異なる環境で動作する場合があります。リストに似た名前があるだけで、対象アプリが含まれていると判断しないでください。設定を変更した後は、接続を再起動して確認します。

すべてのアプリで失敗する場合は、追加のアプリ別フィルターを一時的に解除し、動作確認済みのノードと基本的なルーティングだけでテストします。リモートDNS、通信の識別、IPv6、振り分けリストを同時に変更しないでください。アプリがUDPを使用する場合は、ノードとコアが実際に対応しているかも確認します。VPN接続が通信を引き継げても、リモート側ですべての必要なプロトコルを転送できるとは限りません。

アプリによっては接続や名前解決の結果をキャッシュするため、振り分けを変更しても以前の接続が残る場合があります。対象アプリを終了してから開き直し、必要であればクライアントを切断して再接続します。アプリのデータを消去するとログイン情報やローカルのデータに影響するため、最初の手段にしないでください。まずブラウザーと別の一般的なアプリで比較し、問題が1つのアプリ内だけに限られるか確認します。

画面消灯後の切断とネットワーク切り替え

画面が点灯している間は使えても、ロック後しばらくすると接続が切れる場合は、システムのバッテリー最適化、バックグラウンド実行の制限、端末メーカーのタスク管理設定を確認します。端末が提供する設定手順に従ってクライアントの継続動作を許可し、接続通知も表示されるようにしてください。すべてのアプリのバックグラウンド権限を一度に変更せず、通信を維持する必要があるクライアントだけに設定します。OSの更新後に権限が変わる場合があるため、問題が再発したら設定を確認し直しましょう。

システムの「VPNを常時接続」と「VPN未接続時の通信をブロック」は、切断時のインターネット接続に影響します。後者が有効だと、クライアントの終了中や再接続中に通信が一時的に完全に遮断されます。これは設定どおりの動作です。まず、この動作が必要かを確認してください。基本ネットワークの調査中に該当する制限を一時的に無効化する場合は、元の設定を記録し、テスト後に必要に応じて戻します。

Wi-Fiからモバイルネットワークへ切り替えた後に接続できない場合は、いったん切断してから再接続し、復旧するか確認します。ネットワークが変わるとアドレス、DNS、既存の接続状態も変わり、切り替え前の接続をそのまま使えないことがあります。特定のネットワークだけで失敗する場合は、同じノードで比較し、そのネットワークにWeb認証が必要か、IPv6の経路に問題がないか調べてください。ネットワークを切り替えたときの失敗を、すべてバックグラウンドでのアプリ終了のせいにしないでください。

モバイルのDNSとトラブルの記録

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNS設定が、名前解決に同時に影響する場合があります。ドメインに問題がある場合は、すべての設定を一度にオフにするのではなく、まず現在の状態を記録してください。ログに名前解決のタイムアウトが出ている場合は、現在のネットワークとクライアントのリモートDNS経路をあわせて確認します。特定のブラウザーだけで異常があるなら、まずブラウザー独自の名前解決動作と比較してください。詳しい仕組みはDNSの項目に戻り、層ごとに確認できます。

Androidの問題を他の人に伝えるときは、端末のOS、クライアント名、ネットワークの種類、画面ロックとネットワーク切り替えの条件、VPN接続が維持されていたかを記録します。個人情報を伏せた最初のエラーも添え、同じノードがデスクトップのv2rayNで使えるかを伝えてください。端末間の比較は原因を絞るためのもので、設定が完全に同じだと保証するものではありません。復旧後は、画面をロックしてから復帰し、ネットワークも切り替えて、実際に問題が起きた条件で直ったことを確認しましょう。