ネットに接続できない：まず原因の範囲を特定
クライアントが起動中と表示されても、画面やコアが動作状態にあることしか分からず、ブラウザーのリクエストがリモートまで届いた証拠にはなりません。まずTUNモードを一時的にオフにし、システムプロキシを無効にして、普段なら直接アクセスできるサイトを開いてみてください。ここでも失敗する場合は、Wi-Fi、ゲートウェイ、ログイン認証、OSのネットワーク設定を先に確認します。サーバー設定を続けて変更する必要はありません。クライアントを終了してもネットにつながらない場合は、システムにローカルアドレスを指すプロキシ設定が残っていないか確認し、元の設定に戻してから再テストしてください。
再現できる基準テストを行う
使用中のクライアント、選択中のサーバー、ルーティングモード、システムプロキシの状態、ローカルの待ち受けポートを記録します。ログ画面を開いて古い記録を消してから、決めたHTTPSページにアクセスしてください。ブラウザーのキャッシュで実際の結果が分かりにくくなる場合は、新しいプライベートウィンドウを使います。ただし、拡張機能が独自にプロキシを管理していないかも確認してください。一度にテストするページは一つに絞り、時刻も記録します。サーバーの切り替え、TUNの有効化、DNSの変更を同時に行うと、接続が回復してもどの変更が有効だったのか分からなくなります。
v2rayNでは、まずサーバー一覧で使用する項目が選択されていることと、コアの起動直後にエラーが出ていないことを確認します。デスクトップ版では通常、画面下部のステータス欄またはタスクトレイのメニューでシステムプロキシのモードを確認できます。ローカルポートとアプリに入力したポートを一文字ずつ照合してください。リモートサーバーのポートをローカルプロキシのポートと取り違えないようにします。混合待ち受けを有効にすると複数のプロキシプロトコルを受け付けられる場合がありますが、実際の対応状況は使用中のコアと設定によって異なります。ポート番号だけで判断しないでください。
アプリがプロキシを使っていない場合と、リモートに接続できない場合を区別する
今回のアクセスがログにまったく記録されていない場合は、ブラウザーがシステムプロキシに従っているか、独自のプロキシ設定があるか、ルーティングで接続先が直接接続になっていないかを確認します。リクエストが記録され、その直後にリモート接続エラーが出る場合は、次の章を確認してください。ログに直接接続が記録されていても、サーバーが使えないとは限りません。LANや独自ルールを迂回するための正常な動作である可能性もあります。テストには明らかにプロキシ経由となる接続先を選び、もともと除外されるアドレスだけで結論を出さないようにしてください。
次のコマンドを使うと、ローカルのHTTPプロキシを明示してシステムプロキシの検出を回避できます。例の10808は、対応する待ち受けが実際に有効な場合に限り使用してください。設定と異なる場合は、クライアントの値に合わせて変更します。Windowsではターミナルでcurl.exeを、macOSとLinuxではcurlを使います。接続先には公開されているサンプルサイトを使用していますが、実際のトラブル対処では、アクセス権のあるHTTPSアドレスに置き換えてもかまいません。
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
コマンドでローカルポートに接続できない場合は、待ち受け、ポートの競合、またはコアの起動に問題があります。ローカル接続が確立した後にリモートがタイムアウトする場合は、サーバーの設定値と通信経路を確認してください。HTTPレスポンスを受け取れたことは、そのリクエストがプロキシを経由して応答を得たことを示しますが、すべてのアプリや接続先が正常とは限りません。ブラウザーで引き続き失敗する場合は、拡張機能、独自プロキシ、ブラウザーのセキュアDNS、証明書の警告を順に確認してください。
最小限の設定で復旧する
まずは設定値が正しいと確認できているサーバーを一つだけ使い、基本的なルーティングを保ち、追加の通信制御ツールは無効にします。原因を調べずに設定フォルダー全体を削除しないでください。サブスクリプショングループ、ルーティング、個人設定まで失われる可能性があります。先にバックアップし、項目ごとに戻すほうが競合の特定に役立ちます。証明書の警告が出ても、証明書の検証をすぐに無効にしないでください。端末の日付、接続先ドメイン、証明書の対応関係を確認し、ネットワーク上に許可が必要な検査プロキシがないか調べます。
サーバーがタイムアウトする：ポートとハンドシェイクを分けて確認
「タイムアウト」は一種類の障害を指す言葉ではありません。サーバーのドメイン名解決、トランスポート接続の確立、暗号化ハンドシェイク、プロキシ接続後の接続先へのリクエストなど、さまざまな段階で発生します。まずテスト結果とログを開き、どのアドレスへの接続がどの段階でタイムアウトしたのかを確認してから、サーバーを切り替えるか判断してください。一つの項目だけ失敗する場合は、その項目の設定を優先して確認します。同じネットワークで全項目が失敗する場合は、ローカルネットワーク、システム時刻、ほかのプロキシソフトによる通信制御を先に調べてください。
TCPingだけで接続全体を確認しない
TCPingで確認できるのは、主にTCPポートへの接続状況です。接続に成功しても、認証、TLS、トランスポート経路、接続先へのアクセスまで成功するとは限りません。異なる基盤トランスポートを使う設定に、TCPの結果をそのまま当てはめることもできません。v2rayNの真接続速度テストはプロキシ経由でテスト先にアクセスするため、実際のリクエストにより近いものの、結果はテスト先に接続できるかどうかにも左右されます。テストに失敗しても普段の接続先が使える場合は、テスト先とタイムアウト設定を先に確認してください。一度の結果だけでサーバーを削除しないようにします。
TCPサービスの場合は、Windowsのターミナルで次のシステムコマンドを使ってポートを確認できます。ドメイン名とポートは書式の例です。実行前にサーバー設定の値へ置き換えてください。この結果で分かるのはポートの状態までで、プロトコル設定が正しいとは判断できません。また、第三者サイトによるポートチェックはローカルのテストの代わりになりません。検査元のネットワークと自分の通信経路は異なるためです。
Test-NetConnection -ComputerName example.com -Port 443
関連する接続設定を照合する
サーバーの編集画面を開き、アドレス、ポート、プロトコル、認証情報の順に確認します。次にトランスポートの種類と、そのトランスポートに必要なパス、ホスト名、サービス名を照合してください。WebSocketのパスとリクエストホスト、gRPCのサービス名、TLSのサーバー名はハンドシェイクに影響する場合があり、相互に置き換えられるものではありません。完全な共有リンクからインポートするほうが手入力より確実ですが、リンクがチャットアプリで途中まで切られていないか、パラメーターが二重にエスケープされていないかも確認してください。
TLSエラーが出た場合は、まずシステムの日付とタイムゾーンを確認し、次にサーバー名がサーバー側の設定と一致しているか確認します。REALITYを使う項目では、公開鍵、shortId、サーバー名、クライアントの対応状況も照合してください。別のサーバーの値を混ぜてはいけません。サービス提供元が設定を変更した場合は、該当するサブスクリプショングループを更新して項目を選び直します。古い画面に残った手入力の設定だけを使い続けると、期限切れの接続情報で接続し続けることがあります。
比較テストでネットワークの範囲を絞る
端末と設定はそのままにして、ネットワークだけを現在のWi-Fiからスマートフォンのテザリングに切り替えます。テザリングでは接続できる場合、元のネットワークの名前解決、外部への接続経路、アクセス制限を重点的に確認します。どちらでも失敗する場合は、同じネットワークで動作確認済みの別設定をテストしてください。比較では条件を一つずつ変えます。端末、サーバー、コアを同時に変えてはいけません。サーバー側の一時的なタイムアウトは、リモートのレート制限やサービス停止が原因の場合もあります。クライアント設定で、リモートの待ち受け停止を直すことはできません。
リスト全体を高頻度で連続テストするのは避けてください。多数のハンドシェイクを同時に行うと、サーバーの接続制限にかかったり、ローカルの帯域を消費して正常な項目まで失敗したりする可能性があります。まず一つを個別にテストし、その後少数ずつ比較します。初回のより詳しい確認方法は真接続速度テストとプロキシの動作確認を参照してください。記録には「どの段階で失敗したか」を残し、「サーバーが壊れた」のような曖昧な表現は避けましょう。
サブスクリプションを更新できない：取得と解析を切り分ける
サブスクリプションの更新には、クライアントがURLへリクエストを送る処理と、返された内容をサーバー項目として解析する処理の二段階があります。リクエストの失敗、空のレスポンス、対応していない形式は、いずれもリストが更新されない原因になります。まず更新時のメッセージとログを確認し、有効なレスポンスを取得できたか判断してください。既存のサーバーがまだ使える場合は、グループをすぐに削除しないでください。古い項目を残しておけば、一時的な更新失敗で利用可能な設定をすべて失わずに済みます。
インポート画面とリンクの種類を確認する
v2rayNでは「サブスクリプショングループ」でサブスクリプションURLを管理します。通常はグループ設定を開き、名前とURLを追加してから、サブスクリプショングループのメニューで更新します。v2rayNGではサイドメニューの「サブスクリプション設定」にURLを追加し、メイン画面に戻ってサブスクリプションを更新します。画面のバージョンによって表示位置や文言は多少異なりますが、URLの入力と更新の実行は別の操作です。URLを保存しただけではダウンロードは完了しません。項目が見つからない場合は、まずクライアント名を確認してください。
サブスクリプションURLは通常HTTPSリンクですが、サーバー一つ分の共有リンクにはプロトコルのプレフィックスが付いていることがよくあります。用途は異なります。共有リンクをサブスクリプション欄に入力すると、クライアントがネットワーク上のURLとして取得しようとして更新できない場合があります。コピー時には、前後の空白、改行、日本語の句読点、リンクの欠けがないか確認してください。QRコードはテキストを伝える手段にすぎず、読み取りに成功しても、内容が現在のインポート画面に適しているとは限りません。
リクエストに失敗した場合はアクセス経路を確認する
まず端末の時刻が正しく、通常のWebページにアクセスできることを確認します。次にサブスクリプションが期限切れになっていないか、提供元で停止されていないか確認してください。認証エラーやアクセス拒否が表示された場合は、リンクの提供元に権限を確認します。ローカルポートを繰り返し変更しても、権限の問題は解決しません。ブラウザーでURLを開けても、ブラウザーのアクセス経路が使えることを示すだけで、クライアントの更新時も同じ経路を使うとは限りません。ブラウザー拡張機能やシステムプロキシの違いで結果が異なることがあります。
v2rayNのサブスクリプション更新メニューでは、プロキシ経由とプロキシを使わない更新を選べる場合があります。実際の項目名は現在の画面で確認してください。サブスクリプションの取得に既存のプロキシが必要な場合は、利用可能なサーバーを選択して接続してから、該当する方法で更新します。使えるプロキシがないときは、停止中の接続を使って更新しないでください。直接接続に切り替えるか、提供元が許可する別のネットワークを使用します。テストのために個人用のサブスクリプションURLを不明な変換サービスに渡さないでください。
取得成功でもノードが表示されない場合の確認手順
ネットワークリクエストが成功したのにリストが空の場合は、サーバーがログインページ、エラー説明ページ、リダイレクトページを返していないか確認します。HTTPの成功ステータスでも、内容がサブスクリプションデータとは限りません。複数の共有リンク、エンコードされたリンクの集合、特定のクライアント向けの構造化設定など、形式はさまざまです。すべての形式を相互にインポートできるわけではありません。拡張子だけで互換性を判断せず、対象クライアント向けの形式を提供元で選んでください。
続いてグループの絞り込みと検索欄を確認します。サーバーがインポートされていても、別のサブスクリプショングループに表示されていたり、現在のキーワードで絞り込まれていたりする可能性があります。更新後は検索欄を空にし、該当グループに切り替えて、項目数の変化とエラーメッセージを確認してください。一部の項目だけインポートに失敗する場合は、その項目のプロトコル、トランスポート、コアの対応状況を調べます。ほかの項目が成功していても、形式や設定の問題がないとは限りません。まず一つの項目を修正してから一括更新してください。
サブスクリプションを更新すると、グループ内で手動変更した内容が上書きされることがあります。長期的に残したい個別設定は、クライアントの更新動作を確認して記録したうえで、独立した項目にするか判断してください。端末を移行するときは、サブスクリプションURL、サーバーリスト、クライアント全体のバックアップを区別してください。それぞれに含まれる情報は異なります。インポート画面と形式の詳しい説明はV2RayのサブスクリプションURLのインポートと形式を参照してください。初回のインポートは入門ガイドに沿って進めてください。
速度が遅い：スループット、遅延、負荷を切り分ける
Webページの表示が遅い、ダウンロード速度が遅い、動画がバッファリングする、といった症状は、必ずしも同じ原因とは限りません。ページの初回表示は名前解決やハンドシェイクの影響を受けやすく、大容量ファイルの転送は継続的なスループット、対話型アプリは往復遅延やパケットロスに左右されます。まず「どのアプリで、どこに、いつアクセスすると遅いのか」を記録し、症状に合った方法でテストします。あるページの読み込み時間と別の経路での大容量ダウンロード速度を直接比較したり、接続速度テストの結果を帯域幅の上限とみなしたりしないでください。
まずローカルネットワークと同時通信の影響を除外する
OSの更新、クラウド同期、ほかの大容量通信を一時停止し、バックグラウンドのダウンロードが回線を使い切っていないか確認してください。Wi-Fiの電波が弱い場合は、アクセスポイントに近づくか、有線接続と比較します。クライアント設定を変えず、通常の直接接続先も同じように遅いかテストしてください。すべての通信に影響する場合は、ローカルの通信経路を優先して確認します。端末の充電時の温度制限、CPU負荷、電源管理によって継続的な通信速度が低下する場合もあります。特に長時間使用したモバイル端末では注意してください。
速度を測るときは同時に実行するタスクを一つにし、同じ接続先とファイルを使って、テスト時間もおおむね揃えます。サーバー速度テストは小さなリクエストを使うことが多く、応答特性の一部しか確認できません。リスト全体を並行してテストすると通信量を消費し、テスト自体で帯域を使い切る場合もあります。候補を少数ずつテストし、実際の用途で結果を確認してください。アプリの表示単位が毎秒バイトか毎秒ビットかにも注意します。単位が異なる値はそのまま比較できず、短時間のピーク速度も安定した速度を示すものではありません。
サーバーの負荷と接続先の制限を区別する
ネットワークと接続先はそのままにして、サーバーだけを入れ替えて比較します。一つのサーバーだけが明らかに遅く、複数の接続先で同じ問題が起きる場合は、そのサーバーの負荷、帯域幅、上流回線が原因かもしれません。すべてのサーバーで特定の接続先だけ遅い場合は、接続先サービスの速度制限、キャッシュ、接続ポリシーを確認してください。リモート側のリソース不足は、ローカルのスレッド数を増やしても解決しません。混雑する時間帯と空いている時間帯を比較する場合も、同じ条件で記録し、異なるネットワークの結果から混雑を推測しないようにします。
真接続速度テストが速くてもダウンロードが遅いことは矛盾しません。短いリクエストはすぐ完了しても、継続的な通信は混雑や速度制限の影響を受けることがあります。逆に、ハンドシェイクがやや遅い接続でも、継続的なスループットが高い場合があります。リスト上の数字を小さくすることではなく、実際の用途が改善したかどうかを確認してください。段階別の詳しい確認方法はサーバー、通信経路、ローカル設定の段階別チェックを参照してください。比較結果を記録してから、経路を変えるか判断しましょう。
トランスポート、Mux、ルーティングの変更は慎重に
Muxは複数の論理リクエストを少数の基盤接続にまとめるため、接続を繰り返す負荷を減らせる場合があります。一方、経路やサーバーの組み合わせによっては、同じ接続を共有することで混雑の影響を受けやすくなります。並列数を増やせば速くなるとは限らず、すべてのプロトコルに同じ多重化方式が適しているわけでもありません。最近Muxだけを変更した場合は、元の値に戻して比較してください。サーバー側でトランスポートが指定されている場合、速度向上を狙ってWebSocketを別の方式に変更することはできません。
ルーティングによって「一部だけ遅い」状態になることもあります。ページ本体、画像、ログインAPIが別々のドメインを使い、異なるアウトバウンドルールに一致すると、ページの枠だけ表示されて画像などが読み込まれないことがあります。遅いリクエストのログとルールを確認し、想定した経路を通っているか調べてください。DNSキャッシュや接続の再利用は再テストに影響します。ルールを変更した後は影響する接続を再確立し、必要に応じてアプリを終了してから開き直してください。古い接続が動作しているだけなのに、新しいルールが適用されていないと誤解しないようにします。
速度が回復したら、実際に効果があった変更を記録し、関係のない試行は元に戻します。必要最小限の調整にとどめるほうが、「最適化パラメーター」をいくつも重ねるより安定します。ローカルの問題を除外しても長期的に速度が遅い場合は、「ネットが遅い」とだけ伝えるより、発生時刻、接続先の種類、比較条件をサービス提供元に共有すると原因を調べやすくなります。
DNSの問題：名前解決が行われる場所を確認する
DNSはドメイン名をIPアドレスに変換しますが、プロキシ環境では名前解決が行われる場所は一つとは限りません。OSが名前解決する場合もあれば、ブラウザーが独自のセキュアDNSを使う場合、クライアントのコアが設定に従って名前解決する場合もあります。SOCKSでは、アプリがドメイン名をプロキシ側に渡すこともあります。まず失敗しているのがサーバーのドメイン名か接続先のドメイン名か、リクエストがどの経路を通っているかを確認してください。すべてのリゾルバーを一度に変更すると手がかりを失い、新たな依存関係のループを招く可能性があります。
OSの名前解決とクライアントログから確認する
サーバーのドメイン名を解決できないというログが出ている場合、接続がリモートに到達していない可能性があり、接続先サイトのルーティングを変更しても解決しないことがあります。まずOSのターミナルで、そのドメイン名を解決できるか確認します。Windowsではnslookupを使用できます。macOSとLinuxでも、利用できるシステムの名前解決ツールを使ってください。以下はコマンドの書式例です。OS側では正常に解決できるのにクライアントで失敗する場合は、コアのDNS設定と実際に使われる上流を確認します。両者が同じキャッシュを使うとは限りません。
nslookup example.com
複数のアドレスが返るのはよくあることで、別の端末と異なるという理由だけで異常とはいえません。コンテンツ配信サービスは、ネットワーク上の位置やポリシーに応じて異なる結果を返します。名前解決の成功はアドレスを取得できたことを示すだけで、そのアドレスに接続できるとは限りません。タイムアウトの場合は、上流から応答がないのか、リクエスト経路が間違っているのか、ローカルネットワークで制限されているのかを切り分けます。ネットワークを切り替えた後だけエラーが起きる場合は、まずクライアントの接続を再確立し、以前のインターフェースのDNS設定が残っていないか確認してください。
SOCKSリクエストでローカルとリモートの名前解決を比較する
SOCKSの待ち受けが実際に有効な場合は、次の二つのコマンドを比較できます。一つ目は通常、接続先のドメイン名をローカルで解決し、二つ目はドメイン名をプロキシ側に渡します。ポートはローカル設定の値に置き換えてください。リモートで名前解決する方法だけ成功する場合は、ローカル側で接続先ドメイン名を解決する処理を重点的に確認します。ただし、ログと照らし合わせ、アドレス選択の違いが原因でないかも調べてください。このテストだけで、すべてのDNS通信が同じ経路を通ると証明できるわけではありません。
curl --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/
curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/
ブラウザーのセキュアDNSはOSのリゾルバーを迂回する場合があります。そのため、ターミナルでは正常なのにブラウザーで異常が起きる場合は、ブラウザー独自の設定を確認してください。テストでは一時的にOSの名前解決を使う設定に戻して比較し、結果を確認してから最終的な設定を決めます。ブラウザーのキャッシュを消去しても、OSやコアのキャッシュまで消えるとは限りません。その逆も同様です。まず古い接続を終了し、問題が起きている段階に応じてキャッシュを処理してください。キャッシュの影響をルーティングルールが反映されない問題と混同しないようにします。
名前解決のループやルールの設定ミスを避ける
暗号化DNSの上流にドメイン名を使う場合、その上流への接続を確立するために、まずドメイン名を解決する必要があることがあります。その名前解決がまだ確立していないプロキシに依存すると、ループが発生する可能性があります。同じ到達不能な上流を何度も追加するのではなく、コアの対応状況に沿ってブートストラップDNSを設定するか、上流への接続経路を明確にしてください。社内ネットワークのドメイン名は、ローカルネットワークのリゾルバーでしか解決できない場合があります。こうしたドメインをすべてパブリックDNSに送ると、社内サービスにアクセスできなくなることがあります。
ドメインルールとIPルールでは照合のタイミングも異なります。以下はXray標準ルーティングでLANアドレスを直接接続にするルールの一部で、フィールドの関係を示すための例です。完全な設定ではなく、クライアントの任意の編集欄にそのまま貼り付けるものではありません。directは実際に存在するアウトバウンドのタグである必要があります。通常、ルールは記述順に照合され、地理データファイルも利用可能でなければなりません。GUIのルーティングエディターを使う場合は、対応するフィールドで同じ意味を設定してください。
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
IPv6ネットワークまたはデュアルスタックネットワークでのみ失敗する場合は、返されたアドレスファミリーとリモートへの実際の到達性も比較します。IPv6を無効にすることを恒久的な解決策にしないでください。まずアドレスの選択、ルーティング、上流の対応状況のどれが原因かを確認します。TUNの仮想アドレス変換を使っている場合、通信の取り込みを終了した後にアプリの接続を再確立する必要があることがあります。最後に通常のドメイン名、社内ドメイン名、実際の用途をすべてテストし、一つのテストサイトを直した結果ほかへのアクセスが壊れていないか確認してください。
システムプロキシが機能しない：通信の入口を確認する
システムプロキシはアプリが参照するネットワーク設定の一つであり、すべての通信を強制的に取り込むスイッチではありません。システムプロキシに従うアプリもあれば、独自設定を使うアプリ、設定をまったく参照しないアプリもあります。そのため、ブラウザーでは接続できてもほかのアプリで失敗することだけを理由に、v2rayNが起動していないとは判断できません。まずローカルプロキシを明示したリクエストで待ち受けを確認し、次に対象アプリがプロキシ設定をどう取得するか調べます。TUNが必要かどうかを検討するのはその後です。
システム設定が実際に反映されているか確認する
v2rayNのシステムプロキシメニューで自動設定を選んだ後、OSのネットワーク設定を開き、アドレスとポートが一致しているか確認します。Windowsでは、現在のユーザーのプロキシ、自動構成スクリプト、一部のシステムコンポーネントが使う設定が完全には共通していない点に注意してください。macOSのプロキシ設定はネットワークサービスごとなので、Wi-Fiと有線接続を切り替えた後は現在のサービスを確認します。Linuxでは、デスクトップ環境とターミナルアプリでプロキシの参照先が異なることがあります。クライアントのメニューにチェックがあるかどうかだけで判断しないでください。
設定を書き込んだ直後に元に戻る場合は、ほかのプロキシソフト、ブラウザー拡張機能、端末の管理ポリシー、ネットワークセキュリティツールを確認します。トラブル対処中は、システムプロキシを変更するツールを一つだけにしてください。複数のツールが設定を上書きし合うのを防げます。スイッチを繰り返し操作して競合を隠さないようにします。クライアントを終了する前にシステムプロキシを解除し、ネットワークが復旧したことを確認してください。異常終了後に設定が残った場合は、停止したローカル待ち受けに頼らず、OS側で手動で元に戻します。
アプリとターミナルの環境を個別に確認する
独自のプロキシに対応するアプリでは、ローカルのループバックアドレスと実際の待ち受けポートを指定し、対応するプロトコルを選択してください。HTTPとSOCKSは自由に入れ替えられる項目ではありません。同じポート番号で両方を受け付けられるのは、待ち受け設定が対応している場合に限られます。ターミナルのツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYや除外用の環境変数を参照する場合もあります。古い値が残っていると、停止済みのポートにリクエストを送ることがあります。変数の値に個人情報が含まれる可能性にも注意してください。
アプリ独自の直接接続除外リストが有効な場合、LANや特定ドメインへのアクセスがプロキシを経由しないことがあります。これはアプリ側の動作であり、クライアントでどのサーバーを選んでいるかとは関係ありません。同じ接続先に対して、プロキシを明示したリクエストとアプリからのリクエストをそれぞれ実行し、ログに接続が記録されるか比較してください。アプリからのリクエストがまったく記録されない場合は入口を、記録されているのに直接接続される場合はルーティングを、プロキシに入った後で失敗する場合はリモートを確認します。こうすれば三つの問題を混同せずに済みます。
TUNモードではまず通信の取り込みを確認し、その後で振り分けを確認する
TUNは仮想ネットワークインターフェースで通信を受け取るため、より広い範囲の通信を取り込む用途に向いています。一方で、権限、システムルーティング、DNSなどの追加要因が発生します。まずほかのVPNや重複する仮想ネットワークツールを停止し、クライアントの案内に従って必要な権限を付与してください。Windowsでは管理者権限が必要な操作があります。ほかのデスクトップOSでも画面の案内に従って許可します。すべての障害に対する標準的な対策として、クライアントを常に高い権限で実行しないでください。
TUNを有効にしてから直接接続先も開けなくなった場合は、まずTUNをオフにして、通常のローカルプロキシが使えることを確認します。その後、仮想インターフェースが作成されているか、デフォルトルートに異常がないか、DNSが取り込まれているかを調べてください。通信を取り込めても、ルールが正しいとは限りません。プリンターや社内ネットワークにアクセスできない場合は、プライベートアドレスと社内ドメイン名の除外ルールを確認します。システムルートをむやみに削除したり、他人のネットワーク設定一式をそのまま使ったりしないでください。ネットワークインターフェース名やアドレス範囲は環境によって異なります。
トラブル対処後は、どの取り込み方法を使うか決め、設定を把握しやすい状態に戻します。設定によってはシステムプロキシとTUNを併用できますが、原因を特定する段階では個別にテストするのがおすすめです。「システムプロキシ」「ルーティング」「コア」の意味は用語集で確認できます。初回接続では入門ガイドに沿ってシステムプロキシの経路を確認してから、TUNを使う構成に進んでください。
起動しない・クラッシュする：画面とコアを切り分ける
起動の失敗には、メイン画面がまったく開かない、画面は正常だがコアがすぐ終了する、使用中にクライアント全体が閉じるなど、少なくとも三つの異なる状態があります。まずどの状態か確認し、それに合った手がかりを探してください。画面が開いてもコアの実行ファイルが動くとは限らず、コアが終了しても画面まで閉じるとは限りません。できるだけGUIのログ、システムイベントの記録、起動時に表示されたエラーメッセージ全文を確認してください。「開かない」という説明だけのスクリーンショットで済ませたり、状況を確認せずに何度も上書き再インストールしたりしないでください。
インストールパッケージと実行環境の適合を確認する
デスクトップではv2rayNを推奨します。ダウンロードページでOSとCPUアーキテクチャに合ったパッケージを選んでください。WindowsのDesktop版とWPF版は異なるUI構成で、必要な実行環境や障害の症状も異なる場合があります。一方のファイルをもう一方のフォルダーに混ぜないでください。macOSではApple SiliconとIntelを区別し、LinuxではCPUアーキテクチャとパッケージ形式の両方を確認します。インストーラーと圧縮ファイルでは使い方が異なります。圧縮ファイルの閲覧画面から直接プログラムを実行しないでください。
初回起動時に実行環境について案内が表示された場合は、現在のパッケージの説明に沿って必要なコンポーネントを追加します。記憶だけを頼りに、名前が似ている別のランタイムをインストールしないでください。OSのバージョンが現在のソフトウェア要件を満たしていない場合は、コンポーネントを追加しても解決しないことがあります。Windowsのフォルダー権限、macOSのセキュリティ警告、Linuxのグラフィカルセッションや依存ライブラリもメイン画面に影響する場合があります。表示された原因を確認し、システム保護を一括で無効にしたり、すべてのファイルに書き込み権限を付けたりしないでください。
メイン画面は正常だがコアが終了する
コアのログに最初に記録されたエラーを確認してください。その後に大量の接続エラーが続いても、連鎖的に起きているだけの場合があります。設定の構文エラー、未対応の項目、データファイルの不足、ローカルポートの競合、実行権限の不足では、対処方法が異なります。最近コアを変更した場合は、現在の設定で必要なプロトコルとトランスポートがサポートされているか確認してください。v2rayNは複数のコアを管理できますが、あるコアがサポートする項目を別のコアもサポートするとは限りません。設定との互換性を確認せずに、コア名だけ変更しないでください。
ローカルポートが競合している場合は、別のクライアントや古いコアが起動したままになっていないか確認します。システムのプロセス一覧やポートの使用状況を確認してから、重複したインスタンスを通常の手順で終了してください。プロセス名だけを見て強制終了しないでください。ほかのアプリが使用している可能性があります。ポートを変更して競合を避けることはできますが、システムプロキシ、ブラウザー、独自プロキシを使うアプリのアドレスもすべて更新する必要があります。更新しないと、コアが復旧しているのにアプリが古いポートへ接続する状態になります。
バックアップと最小限の設定で破損箇所を切り分ける
設定のインポート、サブスクリプションの更新、ルーティングの変更の直後にクラッシュした場合は、まず現在のデータをバックアップし、独立したテスト設定で動作を確認します。インストール形式が対応している場合は、ソフトウェアの説明に沿って新しいユーザー設定の保存先を使ってください。バックアップなしに元のフォルダーを削除しないでください。テスト設定には、完全なサーバー項目を一つと基本設定だけを残します。新しい設定で正常に動作すれば、サブスクリプション、ルーティング、画面の設定を一つずつ戻すことで、データ項目の破損か実行環境全体の問題かを判断できます。
更新中にセキュリティソフトがファイルを隔離した場合は、隔離の記録を確認し、ダウンロード元とパッケージの内容を照合してください。ダウンロードフォルダー全体を広範な除外対象にしないでください。ディスク容量の不足、設定フォルダーの読み取り専用状態、同期サービスによるファイルロックも、設定の保存失敗や古い値への復元を引き起こす場合があります。クライアントの要件を満たし、現在のユーザーにアクセス権があるローカルフォルダーへデータを移し、書き込みをテストしてください。移行前にはクライアントを完全に終了し、複数のインスタンスが同時にデータを変更しないようにします。
断続的なクラッシュでは、スリープ復帰後、ネットワーク切り替え後、TUN有効化後のいずれで発生したかを記録します。リソース不足によってOSがプロセスを終了していないかも確認してください。再現する間だけログの詳細度を上げ、原因が分かったら元に戻します。詳細なログを長期間取り続ける必要はありません。初回起動の準備についてはWindows・macOSの初期設定ガイドを参照してください。再インストールで直るのは一部のファイルの問題だけで、古い設定や権限の競合は自動で解消されません。
Androidのトラブル：権限、バックグラウンド動作、アプリ別設定
Androidではv2rayNGを優先して使用し、V2Flyコアを使う場合の選択肢としてv2flyNGを利用できます。デスクトップのシステムプロキシとは接続方法が異なり、一般的なVPNモードではシステムのVpnServiceを使ってローカルの通信経路を確立します。ステータスバーにVPNアイコンが表示されても、システムの通信経路が存在することを示すだけで、リモートサーバーとのハンドシェイクが完了したとは限りません。サーバーを選択し、接続ログを確認したうえで、実際のアプリのリクエストをテストしてください。通知領域のアイコンだけで接続成功と判断しないでください。
接続の許可とVPNの競合を確認する
VPNモードを初めて起動すると、システムが接続許可を求めます。接続元を確認してから許可してください。許可画面が表示されない、またはボタンを操作できない場合は、フローティングウィンドウ、画面フィルター、システムの制限が操作を妨げていないか確認します。仕事用プロファイル、管理対象端末、保護者による使用制限でVPN権限が制限されることもあります。端末の管理ポリシーに従い、クライアント設定の変更で回避しないでください。許可が取り消された場合は、サブスクリプションを更新するだけではなく、再接続してシステムの確認を完了する必要があります。
通常、同じユーザー環境で複数のVPNサービスを同時に維持することはできません。ほかのVPN、VPNインターフェースを使うファイアウォール、ネットワークフィルターツールが、起動時に現在の接続を置き換える場合があります。確認するときは、ほかの接続を使用するアプリを通常の手順で終了してから、クライアントに接続してください。システムで常時接続VPNや「VPNを使用しない接続をブロック」が有効な場合は、どのアプリに設定されているか確認します。古いアプリを削除または無効にした後もこのポリシーが残り、端末がネットにつながらないことがあります。
ロック画面で切断する場合は電源管理を確認する
画面を表示している間は正常なのに、ロック後に切断する場合は、バックグラウンド動作の制限が原因かもしれません。すぐにサーバーの問題と決めつけないでください。クライアントのバッテリー使用設定を確認し、必要なバックグラウンド動作を許可して、OSの設定から過度な省電力制限を解除します。端末によっては自動起動を許可したり、最近使ったアプリの一覧に残したりする必要がありますが、設定の場所はOSによって異なります。特定のスイッチ一つですべての端末の問題が解決すると断言せず、しばらく画面をロックした後にログと通知が残っているか確認してください。
サービスが動作中でも、画面復帰後の最初のリクエストがタイムアウトする場合は、Wi-Fiとモバイルネットワークの切り替え後に古い接続が使えなくなった可能性があります。まず接続を停止して再確立し、すぐに復旧するか比較します。その後、待機中にOSがWi-Fiを切断していないか確認してください。データセーバー、バックグラウンドのモバイルデータ制限、バッテリーセーバーも個別に確認します。一度に変更する項目は一つにし、すべての省電力機能をまとめて無効にしないでください。必要な動作条件だけを確保し、端末を常に高消費電力の状態にしないことが目的です。
アプリ別プロキシ設定の選択範囲を確認する
v2rayNGでアプリ別プロキシを有効にしたら、現在のリストが「選択したアプリだけをプロキシ経由にする」のか、「選択したアプリを除外する」のかを確認してください。チェックマークだけでは意味を取り違えやすいため注意が必要です。リストを変更した後は、通常VPN接続を再確立して新しいセッションに反映させます。システムコンポーネント、ダウンロードサービス、アプリ内ブラウザーのリクエストは、画面上で見えているアプリとは別のプロセスから送信されることもあります。実際にテストし、多数のシステム項目をむやみに選択しないでください。
ブラウザーは使えるのにチャットやメディアアプリで失敗する場合は、まずアプリ別の制限をオフにして比較し、対象アプリが除外されていないか確認してください。アプリによっては異なるトランスポートや長時間接続を使うため、ブラウザーで成功してもすべてのプロトコルが正常とは限りません。仕事用プロファイルのアプリでは、ユーザー領域の境界にも注意してください。個人用プロファイルのクライアントでは、別プロファイルの通信を取り込めない場合があります。システムがサポートする方法で設定し、権限の範囲をサーバーの問題と混同しないようにしてください。
インストール、更新、端末の移行
インストールに失敗した場合は、まずアーキテクチャ、空き容量、システムの案内を確認します。対応するアーキテクチャの一般的な端末ではarm64を選べますが、判断できない場合はダウンロードページの説明に従って共通のパッケージを選んでください。提供元が不明なパッケージや署名の異なるパッケージを、現在のアプリに重ねてインストールしないでください。署名の競合が起きた場合は、現在のインストール元を確認し、サブスクリプションと設定をバックアップしてから移行方法を決めます。アプリを直接アンインストールするとローカル設定を失うことがあります。再インストールしても個人用のサブスクリプションURLは自動で復元されません。
v2rayNGやv2flyNGを更新・変更した後は、VPNの許可、バッテリー設定、選択中のサーバー、アプリ別リストをそれぞれ確認してください。名前が似ていてもアプリ間でデータが自動共有されるわけではなく、コアの対応範囲も別途確認が必要です。システム設定の詳しい説明はVpnServiceの許可、省電力の対象外設定、アプリ別プロキシを参照してください。この章の条件に問題がない場合は、前のタイムアウトとDNSの章に戻り、同じ接続段階に沿って原因を調べます。再インストールを繰り返す必要はありません。