V2Ray全プラットフォーム
導入・設定ガイド

共通の準備：デバイス、サブスクリプション、設定の確認

クライアント、カーネル、サーバーの役割を確認

クライアントはサーバー一覧の表示、サブスクリプションの保存、システムプロキシの設定を行います。カーネルはプロトコル接続、ルーティング、ローカル待ち受けを処理します。v2rayNはデスクトップ向けGUIクライアント、v2rayNGとv2flyNGはAndroid向けです。クライアントをインストールしただけでは、接続先サーバーは使えません。有効なサブスクリプションURLまたは接続情報一式が必要です。Project Vは関連技術エコシステムの開発元で、V2FlyとXrayはカーネルの系統です。これらの名称をサブスクリプションサービス名として扱わないでください。

設定を始める前に、サーバー情報の入手元が信頼できることと、利用条件を確認してください。サブスクリプションURLには認証情報が含まれることがあるため、アカウント情報と同様に管理し、公開の掲示板やスクリーンショット、オンライン変換サイトに貼り付けないでください。問い合わせ時は、プロトコルの種類、通信方式、エラーの分類だけを残し、サーバーアドレス、ユーザー識別情報、URLのクエリパラメーターは伏せます。クライアントのログに接続先ドメインが記録される場合もあるため、共有前に一行ずつ確認してください。

CPUアーキテクチャとインストーラーの種類を確認

同じOSでも、CPUアーキテクチャが異なる場合があります。Windowsでは「設定 → システム → 詳細情報」でシステムの種類を確認します。macOSでは「このMacについて」でチップまたはプロセッサを確認してください。Androidでは端末情報を確認し、判断できない場合はユニバーサル版を選びます。Linuxでは下記のコマンドでアーキテクチャを確認できます。外観や購入時期だけで判断したり、ディストリビューション名とCPUの種類を混同したりしないでください。

uname -m

最低動作要件と必要な実行環境は、ダウンロードページおよびインストーラーの案内を確認してください。デスクトップクライアントは画面やカーネルなど複数の要素で構成されているため、メインプログラムだけを移動すると必要なファイルが不足することがあります。インストール先は、現在のユーザーが書き込めるディレクトリを選びましょう。設定を引き継ぐ場合は、クライアントのバックアップ機能を使い、旧ディレクトリから一部のファイルだけを選んで上書きするのは避けてください。

再現できる状態から始める

ほかのプロキシクライアント、通信高速化ツール、重複起動したプロセスを終了し、通信を制御するプログラムを1つに絞ります。既存のシステムプロキシ、DNS、VPNの状態を記録してください。業務用デバイスでは、組織の設定にも注意が必要です。初回のテストでは、システムプロキシ、TUN、独自DNS、多数のルーティングルールを同時に有効にしないでください。まず標準設定で単一の接続が使えることを確認し、その後に機能を一つずつ追加します。問題が起きたときに戻す設定が明確になります。

テスト用に2種類のサイトを用意します。1つは通常どおり直接接続できるサイト、もう1つはプロキシ経由の通信を確認するHTTPSサイトです。ブラウザーでページが開いても、そのブラウザーの通信が使えることしか確認できず、すべてのアプリがプロキシ経由になったとは限りません。クライアントのログに該当するリクエストが記録されるか確認し、プロキシを無効にしたときの挙動とも比較します。拡張機能、キャッシュ、アプリごとの差を減らすため、テスト中は同じブラウザーウィンドウを使いましょう。

最後に、システム時刻、ネットワークでのWeb認証の要否、管理対象ネットワークかどうかを確認します。証明書の検証には正確な時刻が必要です。ポータル認証が済んでいないと、サブスクリプションの更新がタイムアウトすることもあります。まずプロキシを無効にした通常のブラウザーで、基本的なネットワーク接続を確認してから各プラットフォームの章に進んでください。初回接続を手早く済ませたい場合は、使い方ガイドを参照してください。すべての詳細設定を一度に変更する必要はありません。

Windows：v2rayNのインストールと通信の振り分け

デスクトップ版と従来のWPF版を選ぶ

Windowsのダウンロードページでv2rayNを選びます。デスクトップ版はクロスプラットフォームの画面を採用し、従来のWPF版はWindowsの画面体系を維持しています。これは画面の実装方法の違いであり、特定のサーバーがどちらか一方でしか動かないという意味ではありません。ダウンロードページでx64パッケージが端末に適合することを確認し、インストーラーの案内に従ってインストールしてください。実行環境が不足していると明示された場合は、指定されたコンポーネントを導入します。不明なサイトからDLLだけをダウンロードするのは避けてください。

初回起動時にウィンドウが表示されない場合は、通知領域にすでに起動中のインスタンスがないか確認し、OSによる実行ブロックも調べます。通常のシステムプロキシを試すために、管理者として常時実行する必要はありません。保護されたディレクトリにインストールすると、一般的なディレクトリとは設定の書き込み権限が異なる場合があります。再起動のたびに設定が消える場合は、サブスクリプションを何度も登録し直すのではなく、まずディレクトリの権限とセキュリティソフトのブロック履歴を確認してください。

サブスクリプションを追加してサーバーを選択

「サブスクリプショングループ → サブスクリプショングループ設定」を開き、グループを追加します。識別しやすいメモを入力し、サブスクリプションURLをすべて貼り付けて保存したら、「すべてのサブスクリプションを更新（プロキシを使用しない）」を実行します。初回設定では、まだ使えるプロキシがないため、プロキシを経由しない方法で更新してください。更新後に対象のグループを選び、メインの一覧にサーバーが表示されたことを確認してから、使用するサーバーを選択します。

一覧に変化がない場合は、まず検索条件を解除して「すべて」に切り替え、更新ログを確認します。Webのログインページが返された、サブスクリプションが無効になった、URLが途中で切れているなどの理由で、設定を解析できないことがあります。単体の共有リンクは「クリップボードからURLを一括インポート」などの機能を使って取り込み、サブスクリプションURLとして登録しないでください。設定を保存できても、サーバー情報がすべて揃っているとは限りません。プロトコル、ポート、通信パラメーターを確認してください。

まずシステムプロキシを使い、必要に応じてTUNを検討

サーバーを選択したら、「システムプロキシ」で「システムプロキシを自動設定」を選び、ルーティングはまず「中国本土を迂回」を設定します。システムプロキシが適用されるのは、Windowsのプロキシ設定に従うアプリです。一部のコマンドラインツールやアプリは独自のネットワーク設定を使うため、ブラウザーでアクセスできても自動的にプロキシ経由になるわけではありません。クライアント下部に表示されるローカル待ち受け情報を確認してください。ポートは現在の設定に従い、一般的な例はSOCKS 10808とHTTP 10809ですが、確認せずにほかのアプリへ転記しないでください。

システムプロキシに従わない通信もクライアントに通したい場合は、TUNを検討します。TUNは仮想ネットワークインターフェース、ルーティング、必要な権限に依存し、有効化時に権限の確認が表示されることがあります。ほかのVPNや仮想ネットワークアダプターによる通信制御を無効にしてから、クライアントのTUNを有効にしてください。初期化に失敗した場合は、ログに権限、ネットワークアダプター、ルーティングのエラーがないか確認します。TUNとシステムプロキシを必ず同時に使う必要はありません。トラブル対処では、まずどちらか一方だけで確認してください。

ポート競合、終了方法、スタートアップ

ポートが使用中というログが出たら、まず重複起動したクライアントを終了します。さらに確認する場合は、コマンドプロンプトで下記のコマンドを実行できます。接続とプロセス番号を表示するだけで、ネットワーク設定は変更しません。表示されたプロセス番号をタスクマネージャーの「詳細」と照合し、見知らぬシステムプロセスを安易に終了しないでください。ポートを変更する場合は、そのポートを手動設定しているブラウザー、ターミナル、ほかのアプリも合わせて変更します。

netstat -ano | findstr ":10808"
netstat -ano | findstr ":10809"

ウィンドウを閉じても、通知領域に最小化されただけで終了していないことがあります。終了動作を試す前に、システムプロキシのメニューで「システムプロキシを解除」を選び、トレイメニューから終了します。その後、「設定 → ネットワークとインターネット → プロキシ」に手動プロキシのアドレスが残っていないか確認してください。手動起動と正常終了の両方を確認してから、スタートアップを有効にします。起動時にクライアントが動いていないのに、ほかのアプリがローカルのプロキシアドレスを使い続けると、ブラウザーが突然接続できなくなることがあります。

macOS：アーキテクチャ、システム権限、プロキシサービス

チップに合ったDMGを選ぶ

Appleメニューから「このMacについて」を開き、Appleのチップが表示される場合はApple Silicon版、Intelプロセッサが表示される場合はIntel版を選びます。次にmacOSのダウンロードページから対応するv2rayN DMGを入手します。ディスクイメージを開き、アプリを「アプリケーション」にコピーしてから起動してください。ディスクイメージ上で長期間直接実行すると、アップデート、権限の記録、アプリの場所が一致しなくなることがあります。イメージを取り外した後は起動できなくなります。

初回起動時にセキュリティ警告が表示されたら、ダウンロード元とアプリ名を確認してから、「システム設定 → プライバシーとセキュリティ」でOSが提示する対応方法を確認してください。アプリを起動するためだけに、システム全体のセキュリティ保護を無効にしないでください。アーキテクチャの互換性がないと表示された場合は、ダウンロードページでパッケージを選び直します。OSのバージョン要件を満たさない場合は、対応する実行環境またはOSに更新し、アプリ内ファイルを変更して起動チェックを回避しないでください。

サブスクリプションと使用するサーバーを設定

v2rayNの「サブスクリプショングループ」関連の設定でグループを追加し、サブスクリプションURLを保存した後、プロキシを経由しない更新を実行します。クロスプラットフォーム版のデスクトップ画面では、ボタンの位置がWindows従来版と異なることがありますが、グループの保存、サブスクリプションの取得、使用するサーバーの選択という流れは同じです。更新後に一覧が空の場合は、現在のグループとフィルターを確認してから結果を確認します。メニューの位置の違いを、サブスクリプションの非互換と誤解しないでください。

初回接続では、サブスクリプションに含まれるTLS、サーバー名、通信パラメーターを変更しないでください。サーバーアドレスは接続先を指定し、TLSのサーバー名は証明書とハンドシェイクで使われます。両者が異なることもあるため、項目を一致させる目的で同じ値に変更しないでください。インポート後にサーバーを選択し、システムプロキシを有効にしてテスト先へアクセスします。失敗した場合は、複数の通信方式を同時に切り替えず、まずカーネルのログを確認してください。

システムプロキシとネットワークサービスの関係

macOSのプロキシ設定はネットワークサービスごとに管理されます。「システム設定 → ネットワーク」で、現在のWi-FiまたはEthernetサービスの「詳細 → プロキシ」を開き、実際の状態を確認できます。クライアントがシステムプロキシを設定する際に、権限の許可が求められる場合があります。拒否すると、画面上の設定とOSの実際の状態が異なることがあるため、改めて確認してください。手動で変更する前に元の値を記録します。組織管理のプロキシや自動設定URLは、端末の管理要件を確認せずに削除しないでください。

Wi-Fiから有線LANに切り替えたときや、ドッキングステーションの接続後にネットワークサービスが増えたときは、どのサービスが有効か確認します。ブラウザーは新しいサービスのプロキシ設定に従う一方で、クライアントが引き続き動作することがあります。その結果、「アプリは正常なのにリクエストがログに出ない」ように見える場合があります。クライアントの終了後にWebサイトへアクセスできなくなったら、ネットワークサービスにローカルポートを参照するプロキシが残っていないか確認してください。復元するのは今回変更した設定だけにし、ネットワーク設定をすべて消去しないでください。

TUNの権限、スリープ、ネットワーク切り替え

TUNは仮想ネットワークインターフェースの作成とルーティングの変更を行います。必要な権限はクライアントの実装やシステム環境によって異なります。有効化する前に、ほかのVPNによる通信制御を無効にし、クライアントの案内に従って必要な権限を許可してください。許可を取り消した場合、バックグラウンドの補助プロセスが動いていない場合、ルーティングの作成に失敗した場合は、まず初期化エラーを解消します。権限の確認をすべて通常の通知許可とみなしたり、一度の許可ですべてのインストール先変更に対応できると思い込んだりしないでください。

スリープからの復帰後やネットワーク切り替え後は、既存の接続が切れたり、DNSやデフォルトルートが変わったりすることがあります。現在の通信制御をいったん無効にしてから再度有効にし、新しいリクエストが確立されるか確認します。画面やカーネルに明確な異常がある場合に限り、アプリを再起動してください。インストール先、システムアカウント、バックアップの復元後に権限の問題が生じた場合は、アプリの保存場所とシステムの許可状態を確認します。一度に変更する要素を一つにすれば、何度も再インストールするより原因を特定しやすくなります。

別のMacに移行する場合は、サブスクリプションの情報と必要なルーティング設定を引き継いだ後、新しい端末のチップ、待ち受けポート、権限を改めて確認します。旧端末から書き出した設定一式には、ローカルパスや特定のネットワークサービスの情報が含まれることがあるため、確認せずに上書きしないでください。移行後は、まずシステムプロキシをテストし、次にTUNを個別に確認します。正常終了後にネットワーク状態が復元されることも確認すれば、問題を通信制御方式ごとに切り分けられます。

Linux：パッケージ、デスクトッププロキシ、権限

アーキテクチャとパッケージ形式の両方を確認

Linuxでは、CPUアーキテクチャとディストリビューションのパッケージ形式を確認します。DebianやUbuntu系ではdeb、Fedoraなどではrpmが一般的です。x86_64は通常x64、aarch64は通常arm64に対応します。システム情報または下記のコマンドで確認してから、Linuxのダウンロードページでv2rayNを選んでください。ファイルの拡張子だけを見て判断したり、コンテナー内のアーキテクチャ情報をホストのデスクトップ環境の情報と混同したりしないでください。

uname -m
cat /etc/os-release

ダウンロード後は、ディストリビューションのソフトウェアインストーラーでパッケージを開き、パッケージ管理ツールに依存関係とアプリの登録を任せるのがおすすめです。依存関係の解決に失敗した場合は、不足しているコンポーネントとシステムの対応範囲を確認し、ほかのディストリビューションのライブラリをシステムディレクトリにコピーしないでください。GUIクライアントには利用可能なデスクトップセッションが必要です。リモートのCLI環境では、インストールに成功しただけでGUI、トレイ、システムプロキシ連携が使えるとは限りません。

一般ユーザーで設定して動作を確認

アプリケーションメニューからv2rayNを起動し、まず現在の一般ユーザーでサブスクリプションを保存します。「サブスクリプショングループ」でURLを追加し、プロキシを経由しない方法で更新します。サーバー一覧が表示されたら、使用する項目を選択してください。権限の確認を避けるために、GUIアプリ全体をスーパーユーザーで実行しないでください。設定ファイルの所有者が変わり、一般ユーザーでは保存できなくなることがあります。保存に失敗した場合は、まずユーザーディレクトリに書き込めるか確認します。

更新前に、サブスクリプションの配信元サイトへ基本ネットワークからアクセスできることを確認してください。デスクトップ環境のブラウザーはプロキシを使っていても、クライアントのサブスクリプション取得は同じ経路を通るとは限りません。そのため、「ブラウザーでサブスクリプションのページが開ける」だけでは、プロキシを経由しない更新が可能とは言えません。初回のインポートには直接アクセスできる配信元を使いましょう。使用可能なサーバーがある場合は、配信元の要件に応じてプロキシ経由の更新を試し、2つの方法のエラーを別々に記録してください。

デスクトップのシステムプロキシは、すべてのプロセスに共通する設定ではない

Linuxのデスクトップ環境によって、プロキシの対応状況は異なります。GNOMEやKDEのネットワーク設定と、ターミナルの環境変数は別の経路です。デスクトップの設定を読むアプリもあれば、独自設定や環境変数を使うアプリもあります。クライアントでシステムプロキシを設定した後は、デスクトップのネットワーク設定で実際の状態を確認し、アプリからの接続もテストしてください。ターミナルから直接接続される場合、すぐにクライアントの不具合と判断せず、まずツールが対応するプロキシ設定を確認します。

ローカルのHTTP待ち受けポートが10809であることを確認した後、下記のコマンドでHTTPSリクエストを処理できるか個別に検証できます。このコマンドは今回のcurlリクエストだけにプロキシを指定し、ターミナルやシステム全体の設定は変更しません。例ではドキュメント用に予約されたドメインを使用しています。実際の業務で試す場合は、アクセス許可のある接続先に置き換えてください。クライアントのポートが異なる場合は、先にコマンドを修正します。curlがインストールされていなければ、ブラウザー個別のプロキシ設定でも同様に検証できます。

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

通常のHTTPプロキシはCONNECTでHTTPSリクエストを中継できます。そのため、プロキシアドレスがHTTPでも、接続先サイトのTLSがなくなるわけではありません。SOCKSが必要なアプリでは、クライアントが実際に提供するSOCKSポートを指定してください。プロトコル名だけを変更し、HTTP用ポートをそのまま使ってはいけません。ツールごとに接続先ドメインの名前解決方法も異なるため、比較テストではプロキシの種類と名前解決を行う場所を記録します。

TUN、ルーティング、デスクトップセッション

TUNはデバイスへのアクセス、ネットワーク管理権限、システムルートに関係するため、一般ユーザーで起動したクライアントに追加の許可が必要な場合があります。クライアントとディストリビューションの案内に沿って許可を設定し、出所不明の特権コマンドを流用したり、過剰な権限を常時与えたりしないでください。起動に失敗した場合は、まず権限が拒否されたのか、仮想インターフェースの作成に失敗したのか、既存VPNのルートと競合したのかを確認します。すべての失敗をサーバーの問題とみなさないでください。

トレイアイコンが表示されないのは、デスクトップ環境で対応機能が有効になっていないだけかもしれません。カーネルが動作していないとは限りません。スタートアップ設定では、デスクトップセッションへの自動起動とシステムサービスを区別してください。実行ユーザー、環境変数、権限が異なります。手動起動、ネットワーク切り替え、通信制御の解除、終了後の復元が正常に行えることを確認してから、自動起動を設定します。アプリを更新した後は、許可設定と起動項目を見直し、削除済みのパスを参照する古い項目が残っていないか確認してください。

Android：v2rayNGとv2flyNG

インストールパッケージとクライアントを選ぶ

Androidのダウンロードページでは、まずv2rayNGを選びます。v2rayNGはXrayカーネルを使用します。V2Flyカーネル環境が必要な場合は、v2flyNGを検討してください。2つのクライアントでVPN接続を同時に確立しないでください。比較的新しい一般的な端末ではarm64が使われています。アーキテクチャがわからない場合はユニバーサル版を選べます。ユニバーサル版は対応アーキテクチャが広いことを意味し、通信品質が高いという意味ではありません。端末のブランドだけでインストールするアプリを決めないでください。

ダウンロードしたパッケージをインストールする際、Androidから現在のブラウザーやファイル管理アプリに「不明なアプリのインストール」を許可するよう求められることがあります。実際にインストールに使うアプリだけに許可し、完了後は無効にできます。インストールに失敗した場合は、同名の旧アプリが残っていないか、空き容量が足りているか、OSの互換性を確認してください。設定済みの端末では、アップグレードの問題を解決するためにアンインストールする前に、クライアントのエクスポート機能でバックアップしてください。サブスクリプションや独自ルールも一緒に失われるおそれがあります。

サブスクリプションと単体設定のインポート

v2rayNGのメニューから「サブスクリプショングループ設定」を開き、グループのメモとサブスクリプションURLを追加して保存し、更新を実行します。ビルドによっては、更新メニューがメイン画面またはグループのメニューにあります。機能名を目印に探してください。更新に成功したら一覧に戻り、使用するサーバーを選択して、現在の接続先になっていることを確認してから接続を開始します。グループを保存しただけでは、サーバーは自動的に表示されません。

単体の共有リンクは、メイン画面の追加メニューからクリップボード経由でインポートできます。QRコードの読み取りにはカメラ権限が必要です。クリップボードの内容はほかのアプリに書き換えられる可能性があるため、インポート後に種類、アドレス、ポートが想定どおりか確認してください。OSがバックグラウンドからのクリップボード読み取りを制限している場合は、クライアントを前面に表示してインポートし直します。関係のない権限を何度も許可しないでください。v2flyNGも操作の流れは似ていますが、対応するプロトコルの詳細は個別に確認が必要です。

システムVPNの許可とアプリの対象範囲

接続ボタンを初めて押すと、OSからVPN接続の要求が表示されます。インストールしたクライアントからの要求であることを確認して許可してください。この許可は端末内のVPN通信制御に使われるもので、リモートサーバーが自動的に提供されるわけではありません。接続後は、システムのVPN状態とクライアントの実行ログを確認します。Androidでは通常、VPNサービスを同時に1つしか有効にできません。業務用設定、ほかのVPNアプリ、ローカル通信をフィルタリングするアプリが、接続先を切り替えてしまうことがあります。

Androidクライアントは通常、VPNサービスでアプリの通信を制御します。デスクトップの「システムプロキシを自動設定」の手順をそのまま使わないでください。対象アプリを指定する場合は、クライアントのアプリ別プロキシ設定を確認し、「選択したアプリだけをプロキシ経由にする」のか「選択したアプリを除外する」のかを把握します。この2つは対象が逆です。設定後に再接続し、対象リスト内外のアプリをそれぞれテストしてください。チェックマークの状態だけで対象範囲を判断しないでください。

バックグラウンド動作、プライベートDNS、ネットワーク切り替え

画面ロック後に切断され、ロック解除後に復帰する場合は、クライアントのバッテリー最適化、バックグラウンド動作、自動起動に関する制限を確認します。設定名はメーカーによって異なるため、対象のクライアントについて一つずつ確認してください。端末全体の省電力機能を無効にする必要はありません。プロセスが終了したりVPN状態が消えたりする場合は、バックグラウンド制限が原因かもしれません。プロセスが動いているのにログに接続タイムアウトが記録される場合は、バッテリー設定の調整を続けるのではなく、ネットワーク切り替え、サーバーへの到達性、DNSを確認してください。

Wi-Fiからモバイルネットワークに切り替えると、ローカルアドレスとデフォルトルートが変わり、既存の接続が切れることがあります。接続をいったん停止して再開し、新しいハンドシェイクが成功するか確認してください。特定のネットワークだけで失敗する場合は、ネットワークの種類と時刻を記録し、同じサーバーでの結果を比較します。システムの「プライベートDNS」とクライアントのDNSは別の設定です。両方を同時に変更すると、原因を特定しにくくなります。名前解決に問題がある場合は、まずプライベートDNSの現在の状態を記録し、一度に一つずつテストしてください。

クライアントの遅延テストは、アプリからの接続全体を検証するものではありません。テスト方法によっては、接続の一部しか確認できないことがあります。サーバーのテストは成功してもアプリが失敗する場合は、アプリ別の対象範囲、ルーティング、ドメインの名前解決を確認します。テストに失敗してもWebサイトが開く場合は、テスト先やテスト方法自体を確認してください。別の端末へ移行する場合は、まずサブスクリプション情報を引き継ぎます。AndroidのVPN権限やバッテリー設定は新しい端末で再設定が必要で、設定のバックアップから引き継ぐことはできません。

サブスクリプション管理：更新、パラメーター、設定の移行

サブスクリプションURLとサーバーリンクの違い

サブスクリプションURLは、更新可能な設定一式を取得するためのものです。単体の共有リンクは1つのサーバー情報を表し、インポート先が異なります。文字列の長さだけで判断せず、配布元が説明する用途を確認してください。Webページの共有URLをサブスクリプションとして登録すると、HTMLページを取得して解析できないことがあります。単体リンクをサブスクリプション欄に入力した場合も、更新に失敗する可能性があります。情報の種類を確認してから、グループ設定またはクリップボードからのインポートを使ってください。

配布元や用途ごとにグループを作り、見分けやすいメモを付けるのがおすすめです。グループ数を増やしすぎたり同じサブスクリプションを重複登録したりすると、似た項目が並び、接続先とテスト結果を照合しにくくなります。更新後にサーバーの数が減った場合、すぐにクライアントが設定を削除したと考えず、配布元の内容が変わっていないか、アカウントの期限が切れていないか、グループが非表示になっていないか確認してください。一覧のフィルターとサブスクリプションの実際の内容は分けて調べます。

プロキシ経由の更新と直接接続での更新

「すべてのサブスクリプションを更新（プロキシを使用しない）」は、現在のプロキシ接続に依存せずサブスクリプションを取得します。初回設定に適していますが、配布元へ必ず直接接続できるとは限りません。「プロキシを使用して更新」する場合は、使用するサーバーが選択済みで、正常に動作している必要があります。現在のサーバー自体が期限切れのサブスクリプションから取得したものなら、そのサーバー経由で同じサブスクリプションを更新しようとしても循環するおそれがあります。元の配布元情報を保管し、基本ネットワークから接続できる場合は直接更新を使いましょう。

更新に失敗した場合は、接続できるか、返された内容が想定した形式か、解析後の項目が使えるかの3段階で確認します。接続タイムアウトとログインページの表示は別の問題です。解析に成功しても、サーバーとのハンドシェイクができるとは限りません。サブスクリプションURLの特殊文字、末尾のパラメーター、大文字と小文字には意味がある場合があります。URLを短くするために手作業で削らないでください。コピーの際は、改行、全角記号、チャットアプリが付加した文字にも注意します。

プロトコルのパラメーターを安易に変更しない

一般的なパラメーターは、接続先、認証、トランスポート、TLSの4つに分類できます。アドレスとポートは接続先を指定し、ユーザーIDやパスワードは認証に使います。トランスポートの種類とパスはデータの転送方法を指定し、TLSのサーバー名やALPNなどのセキュリティパラメーターはハンドシェイクに関係します。省略可能な項目はプロトコルとサーバー側の設定によって異なります。別のサーバーで使える値をそのまま流用したり、項目名からデフォルト値を推測したりしないでください。

サーバーアドレス、Host、TLSのサーバー名は異なることがあり、それぞれ別の階層で使われます。証明書の名前が一致しない場合は、配布元のパラメーターとシステム時刻を確認してください。エラーを隠すために証明書検証を無効にしないでください。プロトコルを認識できても、カーネルがすべての拡張機能に対応しているとは限りません。v2rayNGとv2flyNGを切り替えた場合は、画面上のサーバー名だけでなく、対象プロトコルと通信オプションを確認します。

バックアップとプラットフォーム間の移行

移行では、まずサブスクリプション情報、グループのメモ、必要なカスタムルールを保存し、必要に応じてクライアントのバックアップ機能を使います。OSごとにローカルパス、待ち受けポート、TUNの権限、画面設定が異なり、そのまま再利用できないことがあります。新しい端末では、アーキテクチャに合ったクライアントをインストールし、サブスクリプションを追加して基本接続を確認してから、ルーティングとDNSを一つずつ復元してください。移行時の問題と元の設定の問題を区別しやすくなります。

サブスクリプションの更新によって、サブスクリプション管理下のサーバー項目が作り直されることがあります。項目を直接編集しても、変更が維持されるとは限りません。パラメーターを試す場合は、可能であればクライアントで独立したテスト設定を複製し、用途がわかる名前を付けてください。移行後は旧端末に権限を残す必要があるか確認します。サブスクリプション情報が漏えいした場合は、配布元でアクセス情報を変更してください。クライアント上のグループを削除するだけでは、漏えいしたURLは無効になりません。

プロキシ、ルーティング、DNS：段階ごとに検証

通信を取り込む方法と最終的な出口は別

システムプロキシ、アプリ独自のプロキシ、TUNはリクエストをクライアントに渡します。ルーティングルールはその後、直接接続、プロキシ経由、ブロックのどれにするか決めます。TUNを有効にしても、すべての接続先がリモートサーバーを経由するとは限りません。「グローバル」ルーティングを選んでも、すべてのアプリがクライアントに取り込まれるわけではありません。この2つは別々に検証します。まずリクエストがカーネルのログに届いていることを確認し、次にどのアウトバウンドが選ばれたかを確認してください。スイッチの色だけで実際の通信経路を判断しないでください。

初回のテストでは、システムプロキシとプリセットのルーティングを使うのがおすすめです。v2rayNの「ルーティング → 中国本土を迂回」は、一般的な直接接続とプロキシ接続の振り分けを確認するのに使えます。「グローバル」は、同じ接続先への通信を出口ごとに一時比較するときに利用できます。プリセットルールの内容は設定によって変わることがあるため、名前だけでなく現在のルールを確認してください。アプリのリクエストがログにまったく記録されない場合は、ドメインルールを変更する前に通信の取り込み範囲を確認します。

ルールの順序と一致する範囲

カーネルのルーティングは通常、ルールの順番に照合され、最初に一致したルールが適用されます。特定ドメイン向けのルールは、広い範囲を対象とするルールより前に配置します。プライベートアドレスを直接接続するルールは、ローカルサービスへの通信をリモートに送らないために使います。ドメインとの照合とIPアドレスとの照合は別の経路です。カーネルがIPアドレスしか取得できないと、ドメインルールが適用されない場合があります。ドメインを取得した場合に、名前解決後もIPルールを適用するかどうかは、ドメインの処理方針と具体的な設定によります。

下記はXrayのルーティング項目の例です。「ローカルのプライベートアドレスとドキュメント用ドメインは直接接続し、それ以外のTCPとUDPはプロキシを使う」順序を示しています。単独で実行できる完全な設定ではなく、既存の設定にdirectとproxyという名前のアウトバウンドが必要です。GUIクライアントは通常、カーネル設定を生成します。実行ディレクトリ内の一時ファイルを直接編集すると次回起動時に上書きされることがあるため、クライアントのルーティング編集機能を使ってください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

full:example.comは完全一致、domain:example.orgはそのドメインとサブドメインに一致します。ルールで指定するタグは実際のアウトバウンド名と一致させてください。例の名前をそのまま使えるとは限りません。geositeやgeoipのデータを使う場合は、対応するリソースを読み込めることも確認します。構文が正しくても、ルールの順序が目的に合うとは限りません。カスタムルーティングの構文と優先順位を確認しながら、一つずつ検証してください。

DNSの名前解決場所が結果を左右

DNSはドメイン名をIPアドレスに変換するだけでなく、ルーティング判定に使える情報にも影響します。システムDNS、ブラウザーのセキュアDNS、アプリ内の名前解決、クライアントDNSが同時に使われることがあります。Webサイトで名前解決エラーが出た場合は、まずどのコンポーネントが名前解決を行ったか確認してください。ブラウザーが独自の暗号化DNSを使っていると、システムDNSを変更しても影響しないことがあります。DNSサーバーの変更は、証明書、認証、ポートの問題に対する万能な解決策ではありません。

FakeDNSは仮想アドレスとドメインの対応を使い、ドメイン情報を維持する仕組みです。TUNや透過的な通信制御で利用されることがありますが、初回接続に必須ではありません。有効にした後、アプリが仮想アドレスをキャッシュすると、機能を無効にしてから接続を作り直したり、アプリのキャッシュを消したりする必要が生じることがあります。アドレスの対応関係が保持される期間を把握していない場合は、まず通常のDNS設定を使ってください。仕組みの詳細はFakeDNSの仕組みを参照し、システムとクライアントのDNS設定を同時にすべて変更しないでください。

パラメーターを次々に変えず、条件を比較して検証

カスタムルールを検証する場合は、接続先を一つ決め、現在の通信制御方式、ルーティングモード、ログに記録されたアウトバウンドを記録します。まずプリセットのモードで基本接続を確認し、ルールを一つ追加してから同じリクエストを再度実行してください。ブラウザーが古い接続を再利用すると、以前の経路が使われることがあります。その場合は、対象サイトの接続を閉じてから再試行します。ルールが1つ有効だと確認できたら、同種の接続先に適用範囲を広げます。一度に大量のルールを読み込むと、挙動を変えたルールを特定できません。

設定のトラブル対処：問題が起きた段階を切り分ける

まず問題が起きている段階を特定

トラブル対処は、基本ネットワーク、クライアントの起動、ローカルの待ち受け、通信の取り込み、リモート接続、ルーティング、アプリの順に進めます。まず通信制御を無効にして通常のネットワークが使えることを確認します。次にクライアントを起動してカーネルが正常に動作するかを確認し、ローカルポートを調べます。ここまで問題がなければ、サーバーとのハンドシェイクや接続先サイトを確認してください。この順序なら、ポート競合をサブスクリプションの問題と取り違えたり、システムプロキシが有効になっていないのにサーバーを何度も変更したりせずに済みます。

短い記録を作成します。端末のOS、クライアントの種類、通信制御の方式、エラーが起きた時刻、起動から最初の失敗までのログを記録してください。テスト中はクライアントを1つ、使用するサーバーを1つに絞ります。次々に切り替えてから、状況を特定できないログを撮影するのは避けてください。記録を共有する前に、サブスクリプションURL、認証情報、機微な接続先を隠します。エラーが起きた段階を判別できる情報だけを残し、設定ファイル全体を公開する必要はありません。

サーバー一覧が空、起動できない、ポートが使用中

サーバー一覧が空の場合は、まずすべてのグループに切り替えてフィルターを解除し、サブスクリプションの更新が成功したか確認します。更新ログに解析エラーがある場合は、取得した内容、情報の形式、URLが完全かどうかを確認します。ネットワークエラーの場合は、基本接続と更新リクエストがプロキシを経由しているかを確認してください。サーバーがすでに表示されているのにカーネルを起動できない場合は、設定の生成エラー、リソースのパス、ポート競合を調べます。サブスクリプション更新を繰り返しても解決しません。

ログにaddress already in useが出る場合、指定したアドレスまたはポートがすでに使われていることが多いです。ほかのクライアントや重複したインスタンスを終了してから、サービスを再起動します。待ち受けポートの変更で解決することもありますが、そのポートを手動で参照しているアプリもすべて変更が必要です。TUNインターフェースやルーティングの競合の場合、SOCKSポートの変更では解決しないことがあります。仮想ネットワークと権限を確認してください。この2種類のリソースを混同しないでください。

ハンドシェイクの失敗、タイムアウト、証明書エラー

接続タイムアウトは、所定の時間内に特定の処理が完了しなかったことを示します。サーバーが無効とは限りません。タイムアウトがサブスクリプションの取得、リモート接続、接続先へのアクセスのどこで起きたかを特定し、同じ設定を別の使用可能なネットワークで試した結果と比較します。特定のネットワークですべてのサーバーがタイムアウトする場合は、まずネットワーク環境を確認してください。1つのサーバーだけが失敗する場合は、そのサーバー情報と提供元の状態を調べます。テスト結果を出すために、プロトコル、ポート、通信方式を一度に変更しないでください。

TLSや証明書のエラーが出た場合は、端末の日付、時刻、タイムゾーンを確認し、サーバー名、接続アドレス、配布元の情報と照合します。認証に失敗した場合は、ユーザーID、パスワード、サブスクリプションの有効期限を確認してください。WebSocketのパス、Host、サービス名などの通信項目が一致しないと、接続後すぐに切断されることがあります。ログのwarningが必ずしも致命的なエラーとは限りません。その後に正常起動しているか確認し、実際に失敗したリクエストと関連付けてください。

Webサイトは開けるのにアプリは失敗する、または終了後にネットワークへ接続できない

Webサイトは開けるのにアプリが失敗する場合は、そのアプリがシステムプロキシに従うか、アプリ別ルールで除外されていないか、UDPが必要かを確認してください。HTTPプロキシ、SOCKS、TUNでは対象範囲が異なります。ブラウザーで一度テストしただけでは、すべてのプロトコルが使えるとは言えません。アプリのリクエストがログに記録されている場合は、ルーティング先のアウトバウンドとリモートからの応答を確認します。ログにない場合は、まず通信の取り込みを確認してください。グローバルルーティングでも、通信が取り込まれていないアプリは制御できません。

終了後にネットワークへ接続できない場合は、システムにローカルプロキシの設定が残っていないか、「VPNを使わない接続をブロック」が有効になっていないかを確認します。今回変更したプロキシや通信制御の設定を元に戻してから、クライアントが実際に終了したことを確認してください。ネットワーク全体をすぐにリセットしないでください。業務ネットワーク、固定アドレス、ほかの必要な設定まで消えるおそれがあります。端末の再起動が必要な場合は、先にエラーの記録を保存してください。再起動で一時的な状態が解消することはありますが、原因は特定できません。

正常に動作する基本設定に戻し、一つずつ追加

原因を特定できない場合は、必要な設定をエクスポートし、サブスクリプション情報を保存してから、サーバー1つ、プリセットのルーティング、通信制御方式1つの状態に戻します。独自DNSと追加ルールはいったん外し、復旧したら一つずつ戻し、毎回同じテストを行ってください。再インストールする場合は、ユーザー設定が原因かどうかを先に確認します。アプリだけを入れ直して同じ問題のある設定を復元しても、症状が変わらないことがあります。別の端末で動作しても、情報が別環境で使えたことしかわからず、端末固有のネットワーク差は否定できません。

細かな疑問はよくある質問を参照してください。ログの各項目を詳しく知りたい場合は、v2rayNの実行ログから原因を特定する方法を確認できます。トラブル対処後は、使用する待ち受けポート、プロキシ方式、ルーティング設定を記録します。テスト用に作成した一時ルールを削除し、正常終了と再起動ももう一度確認してください。説明できない設定を増やすより、基本設定を小さくまとめておくほうが、その後の管理に役立ちます。