V2Ray設定ガイド
基礎からTUNまで

ステップ1 · 基礎を理解する

基礎知識と通信の流れ

画面、コア、サーバーを区別する

設定を始める前に、クライアントを画面とプロキシコアの2つに分けて考えましょう。画面ではサーバー、サブスクリプション、ルールを管理し、コアは設定を読み込んでローカルポートを待ち受け、接続を処理して通信先を選びます。ウィンドウが開いても、画面が正常なだけでコアが起動しているとは限りません。接続できるか判断するには、トレイアイコンやスイッチの色だけでなく、実行ログ、ローカルの待ち受け、実際のアクセス結果を確認してください。

V2RayはProject Vのプロキシエコシステムに属する技術体系です。V2Flyは関連するコアの開発を引き継ぎ、Xrayは別の系統で発展しています。v2rayNは複数のコアをバージョンに応じて利用できるデスクトップ向けGUIクライアントです。v2rayNGは主にXrayコアを、v2flyNGはV2Flyコアを使用します。クライアント名とプロトコル名は別のものです。同じ画面から設定しても、すべてのコアで動作するとは限りません。

リクエストの流れから設定箇所を理解する

一般的な通信経路は、アプリがリクエストを送り、システムプロキシまたは仮想ネットワークインターフェースがローカルの入口へ通信を渡し、コアがルーティングに従って直結、プロキシ、または遮断を選び、対応するアウトバウンドから接続する流れです。リモートサーバーはプロキシ接続のサーバー側を担います。クライアントをインストールしても、リモートサービスは自動で提供されません。サブスクリプションURLやサーバー情報、利用権限は、利用者自身が正当な方法で取得してください。当サイトのダウンロードページではクライアントを案内しています。

「ノード」は一般に、GUIクライアントでサーバー接続に必要なパラメーター一式を指します。アドレス、ポート、プロトコル、認証情報、トランスポートのセキュリティ設定などが含まれます。VMess、VLESS、Trojan、Shadowsocksはプロトコル名、WebSocketやgRPCなどはトランスポート方式です。TLSとREALITYはトランスポートのセキュリティに関係します。各パラメーターはサーバー側の設定と一式で一致させる必要があります。VLESSと表示されているからといって、セキュリティ項目を自由に入れ替えないでください。

最小構成で動作確認する

初めて操作するときは、目的を1つに絞りましょう。選択したサーバーを使って、1つのアプリから1回リクエストを送ることを目指します。他のプロキシツールを終了し、端末の時刻が正確であることを確認してサーバーを選び、システムプロキシを有効にします。DNS、ルーティングテンプレート、TUNは同時に変更しないでください。最小限の経路で動作確認してから設定を追加すれば、変更前後を比較できます。複数の設定を一度に変えると、問題の原因を特定しにくくなります。

確認時は、次の3つの状況を区別してください。コアが起動しない場合は、ローカル設定、権限、ポートを確認します。コアは起動するもののプロキシ接続に失敗する場合は、サーバーパラメーター、サブスクリプションの状態、ネットワーク到達性を確認します。一部のアプリだけ失敗する場合は、システムプロキシに従うアプリか、ルールがどう適用されたかを調べます。画面上の遅延テストで分かるのは、特定のテスト経路が成功したかどうかです。実際のサービスへのアクセスやダウンロード速度の代わりにはなりません。

ステップ2 · ツールを選ぶ

クライアントとインストールパッケージの選び方

デスクトップではv2rayNを選ぶ

Windows、macOS、Linuxでは、まずv2rayNを検討してください。サブスクリプション、サーバー、ルーティングを共通した操作感で管理できます。選ぶときは、OS、プロセッサーアーキテクチャ、パッケージ形式の順に確認します。ファイル名の短さや容量の小ささだけで判断しないでください。アーキテクチャや実行時の依存関係が合わない場合、インストール、起動、コアの実行時に問題が表面化します。

Windows向けのダウンロードには、デスクトップ版と従来型のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用しており、異なるデスクトップOSでも似た操作感を求める方に適しています。WPF版は従来のWindowsデスクトップUIを引き継いでおり、これまでの操作手順に慣れている方に向いています。画面の配置や依存関係は版によって異なる場合があります。あるバージョンのスクリーンショットを、すべてのバージョンで使えるメニュー案内として扱わないでください。

引き継ぐ設定がなければ、まずデスクトップ版を選び、インストールパッケージの案内に従って必要な実行環境を整えましょう。WPF版を安定して使っている場合、画面が変わるという理由だけで急いで移行する必要はありません。切り替える前に必要な情報をエクスポートし、現在の設定を記録してください。2つのバージョンは別々のディレクトリで使い、同じ設定ディレクトリを交互に書き換えないようにします。また、両方のコアで同じ待ち受けポートを同時に使用しないでください。

Androidではコアとアーキテクチャで選ぶ

AndroidではXrayコアを使うv2rayNGが第一候補です。V2Flyの動作を確認したい場合や、対応する設定をすでに持っている場合は、v2flyNGも検討できます。2つのクライアントは別々のテスト環境として使えますが、接続を同時に開始しないでください。通常、ユーザー領域のVPN接続を占有できるアプリは1つです。後から起動したアプリが先の接続を置き換え、「スイッチはオンのままなのに通信経路が変わった」と誤認することがあります。

比較的新しいAndroid端末の多くはARM64です。端末の対応を確認してからarm64パッケージを選びましょう。アーキテクチャが分からない場合は、汎用版を検討し、インストール結果と端末情報で確認してください。アプリのインストールに成功しても、サブスクリプション内のプロトコルやパラメーターすべてに対応しているとは限りません。クライアント、コア、サーバーの機能が一致している必要があります。未対応の項目が表示されたら、汎用インストーラーを何度も変えるのではなく、必要な機能がサポートされているか確認してください。

OSへの対応と設定の互換性を分けて考える

macOSでは、Apple Silicon搭載MacはARM64、Intelプロセッサー搭載Macはx64に対応します。Linuxでは、debはDebian系のパッケージ管理環境、rpmは対応するRPM系の環境で使用します。LinuxのARM64パッケージにはARM64のシステムが必要です。ディストリビューション名が同じというだけでx64パッケージを選ばないでください。システムライブラリ、デスクトップ環境、権限管理の違いも起動に影響します。パッケージ形式が正しいことは、最初の確認にすぎません。

クライアントを選んだら、OS、アーキテクチャ、選んだUIの種類、コアの種類を記録しておきましょう。これらの情報はトラブル対処で何度も必要になります。ダウンロード先はダウンロードセンターに統一し、複数の配布元の説明を混ぜないでください。サブスクリプションの要件が分からない場合は、提供元にプロトコルとトランスポートのパラメーターを確認してください。この章では互換性と使い慣れた操作方法を基準に選びます。クライアント名からサーバーの品質を判断するものではありません。

ステップ3 · 実行環境を整える

インストール、権限、ローカルの待ち受け

アプリとコアを安定して起動する

Windowsでは、インストーラーまたは展開後のファイルを決まった場所に置いてからクライアントを起動します。圧縮ファイルで配布されている場合は、すべて展開してから実行してください。圧縮ファイルのプレビュー画面からメインプログラムを直接起動しないでください。設定、ログ、コアのファイルで相対パスを使う場合があり、一時的な展開先では設定が失われたり、必要なファイルが見つからなくなったりするおそれがあります。フォルダー構成は簡潔にし、特別な書き込み権限が必要な場所は避けましょう。

初回起動時に実行環境が不足していると表示された場合は、選択したインストーラーの要件に従ってください。別のUI版向けの依存関係の案内をそのまま適用しないでください。必要な環境を整えたら再起動し、ログでコアの起動失敗、設定の解析エラー、待ち受けの失敗がないか確認します。通常のシステムプロキシ接続では、クライアントを常に管理者として実行する必要はありません。仮想ネットワークインターフェースやサービスのインストールなど、実際に権限が必要な操作に限り、案内に従って許可してください。

macOSでは、アプリを決まったアプリケーションフォルダーに置き、初回起動時の警告にはシステムのセキュリティ確認手順に従って対処します。アプリを起動するために、システムのセキュリティ機能全体を無効にしないでください。Linuxで画面が開かない場合は、まずターミナルから該当プログラムを起動するか、デスクトップの起動ログを確認し、GUI依存関係の不足とプロキシコアのエラーを切り分けます。解決方法はそれぞれ異なります。サブスクリプションを再インポートしても、システムライブラリは補えません。

待ち受けアドレスとポートを確認する

設定からローカルの混合待ち受けポートを探し、現在の値を控えます。このガイドでは例として10808を使用します。実際の設定はクライアントの表示を確認してください。混合入口では通常、HTTPとSOCKSのリクエストを判別できますが、具体的な機能はクライアントとコアの設定によります。まずはローカル端末だけで使い、ループバックアドレスで待ち受けるようにします。LAN内で共有する明確な理由がない限り、LANからの接続を許可したり、すべてのネットワークインターフェースで待ち受けたりしないでください。

ログにポートの競合が表示されたら、権限を変えて何度も試すのではなく、まず誰が待ち受けているか調べます。以下のコマンドは接続と待ち受けの情報を表示するだけで、プロセスを終了させることはありません。Windowsでは待ち受け項目と対応するPID、Linuxではローカルの待ち受け行を確認します。macOSではシステム標準のポート確認ツールを使います。何も表示されない場合も、コマンドの実行権限と、確認しているポートが実際の設定と一致するかを確かめてください。

# Windows PowerShell
netstat -ano | findstr :10808

# Linux
ss -lntp 'sport = :10808'

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

競合しているプロセスが以前のクライアントだと分かったら、まず旧プログラムを正常に終了します。必要な別サービスの場合は、現在のクライアントで空いているポートに変更してください。設定を保存してコアを再起動した後、新しいポートで待ち受けていることを確認します。プロキシを手動設定しているアプリのポートも変更してください。詳しい手順はローカル待ち受けポートの競合を解消する手順をご覧ください。プロセス番号だけを見て、システムサービスを安易に終了しないでください。

Androidで初回の権限を許可する

Androidでは、インストール後に初めて接続するとき、VPN接続の許可を求められます。これはローカルの通信を取り込むためのシステム機能であり、リモートサーバーへの接続が確立したという意味ではありません。許可した後も、クライアントのログと実際のアクセス結果を確認してください。インストールに失敗したら、アーキテクチャの不一致、OSバージョンの制限、署名の競合、ファイルのダウンロード未完了を切り分けます。旧アプリを先にアンインストールすると、既存の設定やサブスクリプションも消える場合があるため注意してください。

ステップ4 · 接続情報を管理する

サブスクリプションの追加、更新、ノードの確認

サブスクリプションURLをグループに追加する

サブスクリプションURLは、サーバー設定をクライアントで取得するための入口で、通常はアクセス用の認証情報を含みます。コピーするときはURL全体を保持し、クエリパラメーターを削除したり、公開の場に貼り付けたりしないでください。インポート前に提供元と利用権限を確認し、コピーした内容に空白、改行、引用符、チャットアプリが追加した説明文が混ざっていないか確認します。必要なのは設定内容を取得できるサブスクリプションURLです。説明用のWebページや、対話型ログインが必要な管理画面のURLではありません。

v2rayNでサブスクリプショングループの管理画面を開き、新しいグループを作成します。判別しやすい名前を付けてURLを貼り付け、保存してください。メイン画面に戻り、そのグループのサブスクリプションを更新してサーバー一覧に項目が追加されたか確認します。画面のバージョンによってメニュー名は多少異なる場合がありますが、順序は同じです。提供元を登録し、内容を取得してから、サーバーを選びます。サブスクリプションURLを手動サーバーの「アドレス」欄に入力しないでください。

v2rayNGとv2flyNGでは、サブスクリプショングループの設定でURLを追加し、メイン画面に戻って更新します。QRコードやクリップボードからのインポートでは、更新が続くサブスクリプションではなく、静的なサーバー項目だけが追加される場合があります。インポート後にグループ情報を確認し、今後の管理がサブスクリプション更新によるものか、手動置換によるものかを把握してください。グループ名は管理用であり、サーバーのプロトコルやコアの動作は変わりません。

更新に失敗したら、まず応答内容を確認する

サブスクリプションの更新には、通常、ネットワークリクエストと内容の解析という2つの段階があります。リクエストがタイムアウトする場合は、URLにアクセスできるか、更新に直結とプロキシのどちらを使っているかを確認します。解析に失敗した場合は、返された形式がサポートされているかを重点的に調べます。サーバーからログインページ、エラーページ、利用枠の説明などが返された場合、リクエスト自体が成功してもサーバー設定としてインポートできません。更新完了の表示だけで判断せず、項目数の変化やエラーも確認してください。

まだ利用可能なプロキシ接続がない場合、初回は通常の直結で更新を試します。そのネットワークからサブスクリプションURLにアクセスできず、利用可能なサーバーがすでにある場合は、プロキシ経由での更新を試してください。まだインポートしていないサーバーを経由しないとアクセスできないように設定すると、起動時に依存関係が生じます。更新前に、引き続き使える旧項目を残してください。すべて削除してから更新すると、提供元が無効になった場合に、接続手段と比較用の情報を同時に失います。

サーバーを選んでから実際の接続を確認する

インポートに成功したら、現在のコアと互換性のあるサーバーを1つ選び、使用中の項目に設定します。まず実接続による遅延テストを行い、明らかに失敗する設定を除外できます。その後、ブラウザーやコマンドラインで実際のリクエストを確認してください。結果はテスト先、DNS、経路、実施時刻によって変わるため、固定的な性能評価ではありません。一覧で最小の数値だけを選んだり、1回の失敗でサブスクリプション全体が無効だと判断したりしないでください。

同じグループの大半の項目が失敗する場合は、端末の時刻、サブスクリプションの有効性、プロトコルの対応状況を確認します。1つだけ失敗する場合は、その項目のアドレス、ポート、セキュリティ設定、トランスポートのパラメーターを比較してください。サブスクリプションが自動生成した重要な項目を、試しに変更しないでください。次回の更新で上書きされることがあります。検証用の設定を残す場合は、独立した手動項目として複製し、用途を明記してサブスクリプションの内容と区別してください。

更新後は、使用中のサーバーが引き続き存在するか確認します。提供元の名前変更や項目の削除により、選択が無効になることがあります。グループのフィルター条件によって一覧が空に見える場合もあります。詳しくはサブスクリプションの解析失敗と一覧が空の場合の確認リストをご覧ください。この章の完了条件は、サブスクリプションを管理でき、使用するサーバーが明確で、少なくとも1つのサーバーで実際のリクエストを確認できていることです。

ステップ5 · アプリの通信を接続する

システムプロキシ、手動プロキシ、グローバルモード

システムプロキシでブラウザーを確認する

使用するサーバーを選んだら、v2rayNで「システムプロキシを自動設定」または同等の機能を有効にします。これはOSがアプリに提供するプロキシ設定を変更するもので、設定に従うかどうかはアプリ側で決まります。一般的なブラウザーの多くはこの設定を使いますが、ターミナルツール、ダウンロードアプリ、ゲームなどは独自の通信処理を行う場合があります。ブラウザーでは接続できるのに別のアプリで失敗する場合は、サーバーを変える前に接続方法を確認してください。

「システムプロキシを解除」は、通常、クライアントが設定したシステムの入口を元に戻す操作です。コアも必ず終了するという意味ではありません。「システムプロキシを変更しない」場合は、OSに以前から設定されていた内容が残ることがあります。メニューの詳細は各クライアントの画面で確認してください。通常の終了時には、不要なシステムプロキシ設定を先に元に戻します。特にプロセスを強制終了する場合は注意が必要です。待ち受けるプログラムが終了した後もシステムプロキシがローカルポートを指したままだと、その設定に従うアプリは通信できません。

接続範囲とアウトバウンドの経路を分けて考える

「グローバルプロキシ」は誤解を招きやすい表現です。クライアントのルーティングでは通常、コアに入った通信を優先的にプロキシのアウトバウンドへ送ることを意味しますが、すべてのアプリの通信がコアに入るとは限りません。システムプロキシは一部のアプリをどう接続するか、ルーティングモードは接続済みの通信をどこへ送るか、TUNは通信を取り込む範囲を扱います。それぞれ異なる層にあるため、1つの「グローバル」ボタンで全体の動作を説明することはできません。

個別アプリがHTTPまたはSOCKSプロキシに対応している場合は、ループバックアドレスとローカルの待ち受けポートを手動で入力できます。アプリの接続先を明確に指定できるため、すぐに広い範囲の通信を取り込む必要はありません。まずアプリが要求するプロトコルを確認してからアドレスを入力してください。混合待ち受けに対応していても、画面に表示されるすべてのポートを相互に置き換えられるわけではありません。通常のアプリのローカルHTTPプロキシとして、リモートサーバーのアドレスを入力しないでください。

手動プロキシを使って比較する

以下の2つのコマンドは、HTTPとSOCKSをそれぞれ使って同じサンプルサイトにアクセスします。ポートは現在の待ち受け設定に合わせてください。Windowsではcurl.exeを使うと、一部のターミナル環境で同名コマンドと区別できます。socks5hでは接続先ドメインの処理をプロキシ側に委ねますが、最終的な名前解決の経路はコアの設定によります。コマンドが成功すれば、このリクエスト経路が使えることを確認できます。すべてのアプリが通信を取り込めたという意味ではありません。

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

macOSとLinuxでは、コマンド名をcurlに置き換えられます。まず手動プロキシのテスト結果を記録し、ブラウザーと比較してください。コマンドが成功してブラウザーが失敗する場合は、ブラウザーの拡張機能、個別のプロキシ設定、古い接続を確認します。両方とも失敗する場合は、ローカルの待ち受けとプロキシのアウトバウンドに戻って確認します。ブラウザーのキャッシュにあるページで接続成功と判断しないでください。必要に応じて新しいウィンドウを開き、未訪問のページにアクセスします。

AndroidのVPNモードはシステムのインターフェースを通じて通信を接続します。アプリごとのプロキシ設定も、実際に通信を取り込む範囲に影響します。初回の確認ではテスト用ブラウザーを除外せず、接続を確認してから必要に応じて対象アプリを絞りましょう。この章の完了時には、「アプリがプロキシに接続されていない」場合と「接続された後にアウトバウンドで失敗する」場合を区別できる状態を目指します。基本操作は使い方ガイド、エラーの確認にはよくある質問とトラブル対処をご覧ください。

ステップ6 · アウトバウンドの経路を制御する

ルール、DNS、ルーティングの確認

空のルールではなく、組み込みモードから始める

システムプロキシの動作を確認してから、クライアントが提供するルーティングモードを選びます。まずは組み込みテンプレートを使い、「直結」「プロキシ」「遮断」の意味を理解してから例外を追加してください。直結はローカルネットワークから接続先へ直接接続することを指し、通信がコアをまったく通らないとは限りません。遮断は一致した接続を明示的に拒否する設定で、接続障害とは別です。グローバルモードは比較用に使えますが、すべての細かなルールを常に置き換える必要はありません。

ルールは通常、上から順に確認され、最初に一致したルールで経路が決まります。上位の広いルールがドメインに一致すると、下位のより具体的なルールが適用されない場合があります。ルールを追加する前に、対象、希望するアウトバウンド、配置場所を明確にし、ログで確認してください。ドメイン、IPアドレス範囲、プロセスの例外を一度に重ねて追加すると、アクセスが復旧しても、どのルールが効いたのか分からなくなります。

設定例が適用される範囲を把握する

以下はV2Ray / Xray形式のルーティング設定例で、単独で起動できる完全な設定ではありません。完全な設定内に、directという名前の直結アウトバウンドと、proxyという名前のプロキシアウトバウンドが定義されていることを前提に、サンプルドメインとプライベートアドレスを直結する例を示します。別のアウトバウンド名を使う場合は、該当箇所も変更してください。GUIクライアントが自動生成する設定を直接上書きすると、保存時に再生成されることがあります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメインルールのdomain:example.comは、そのドメインとサブドメインに一致させるための指定です。任意のパス条件には使えません。プロキシのルーティングでは通常、暗号化されたWebページの具体的なパスは見えないため、完全なURLをドメインルールとして入力することはできません。プライベートアドレスのルールはLAN内のサービスを直結するのに便利ですが、特殊用途のアドレスをすべてカバーするわけではありません。まずクライアントが管理する完全なテンプレートを使い、実際の要件に応じて例外を追加してください。

DNSがルールの判定情報を左右する

DNSはドメイン名をアドレスに変換し、IPアドレスのルールで使える判定材料にも影響します。例のAsIsは、IPルールとの照合だけを目的にドメインを積極的に名前解決する設定ではありません。接続全体でDNSを一切使わないという意味ではありません。アプリが解決後のアドレスだけをコアに渡す場合、ドメインルールに一致しないことがあります。逆に、ドメイン情報しかなく解決結果がない場合、一部のIPアドレス判定には追加の処理が必要です。

対応する通信では、ドメインスニッフィングによって接続先の情報を補えることがありますが、どのプロトコルでもドメインを復元できるわけではありません。また、アプリの内容を復号する機能でもありません。ブラウザーのセキュアDNS、アプリ独自の名前解決、システムのキャッシュによって、実際の経路が想定と異なる場合があります。トラブル時はまず、名前解決と接続のどちらで失敗しているか確認し、それからDNSの方針を見直してください。公共DNSに無闇に変更しても、認証パラメーターの誤りやコアの停止は解決できません。

ルーティングを確認するには、直結すべき接続先とプロキシ経由にすべき接続先を1つずつ選び、新しいリクエストを送ってログの宛先とアウトバウンド名を確認します。Webページに表示される最終的なアドレスだけでは不十分です。ページが複数のドメインを使う場合があります。ルール変更後は接続を新しく確立してください。既存の接続は、変更前の経路を引き続き使うことがあります。一度に変更するのは1項目だけにして、変更前後の設定の概要を残しておけば、失敗時に元へ戻せます。

ステップ7 · 通信を取り込む範囲を広げる

TUNモード、権限、元に戻す方法

本当にTUNが必要か確認する

アプリがシステムプロキシに従わず、使える手動プロキシ設定もない場合に限り、TUNを検討してください。TUNは仮想ネットワークインターフェースを通じて広い範囲の通信をプロキシ処理に取り込み、一般的なプロキシ設定では接続しにくいアプリも対象にできます。変更されるのは通信の入口の範囲であり、サーバーの障害、認証情報の誤り、プロトコルの非互換性が直るわけではありません。通常のシステムプロキシをまだ確認できていない場合は、まず基本の接続を解決してからTUNを追加してください。

v2rayNのTUN機能は、バージョン、実行コンポーネント、OSによって異なります。設定スイッチの場所やサービス要件も同じとは限りません。有効にする前に、使用中のコア、ローカルポート、ルーティングモード、DNS設定を記録し、TUNを無効にした後の復旧方法も確保します。古いガイドにボタンがないからといって、正体の分からないコアを組み合わせたり、プログラムファイルを置き換えたりしないでください。現在のインストーラーが対応する機能と画面の案内を確認してください。

入口を1つにして初回確認する

初めて有効にする前に、他のプロキシソフトと不要な仮想ネットワークツールを終了します。不要なシステムプロキシを解除してから、クライアントの案内に従ってTUNを有効にし、必要な権限やサービスを許可してください。どの入口を経由して接続したか判断しやすくなります。環境によっては2種類の入口を併用できますが、初回の確認では重ねないようにしましょう。複数の入口、仮想ネットワークインターフェース、自動ルーティングを同時に変えると、問題の切り分けが難しくなります。

有効にしたら、仮想インターフェースの作成失敗、権限不足、ルート追加の失敗、DNSのバインド競合がログに出ていないか確認します。インターフェースを正常に作成できていない場合、サーバーを何度も切り替えても意味がありません。インターフェースは作成できたのにすべてのアクセスが失敗する場合は、TUNを無効にして、以前のシステムプロキシが動作するか確認します。復旧するなら、基本的なアウトバウンドは正常である可能性が高く、調査すべきなのは通信の取り込み経路です。サブスクリプションをすべて再インポートする必要はありません。

DNS、UDP、ローカルサービスも確認する

TUNを使う環境では、DNSリクエストはシステムによる名前解決、コアによる名前解決、仮想アドレスのマッピングなど、異なる経路を通る場合があります。実際の設定に基づいて確認してください。他のコア向けのDNS項目をそのままコピーしないでください。Webページは表示できるのに音声通話やゲームなどに問題がある場合は、UDPが入口からプロキシのアウトバウンドまで対応しているか確認します。仮想インターフェースを有効にしただけで、リモートサーバーがUDP転送に完全対応するわけではありません。

LANプリンター、ネットワークストレージ、社内ネットワークには、正しい直結経路を確保する必要があります。TUNを有効にした後、ローカル機器とプロキシ接続先をそれぞれ確認し、互いに影響していないか調べてください。企業ネットワークでは独自のDNSやルートが配布されることがあります。これらを無断で上書きすると、社内サービスに影響する場合があります。そのような環境では、まず組織のネットワークルールを確認してください。IPv6にも明確な方針が必要です。IPv4での確認が成功したからといって、すべてのアドレスファミリーが正しく処理されるとは限りません。

AndroidのVPNモードもシステム通信を取り込みますが、デスクトップの仮想ネットワークインターフェース向けドライバーや管理者操作をそのまま適用しないでください。Androidでは、VPNの許可、アプリの除外リスト、バックグラウンド制限、他のVPNツールとの競合がよくある問題です。この章の完了時には、TUNを有効にする具体的な理由を説明でき、ブラウザー、対象アプリ、LAN内のサービスを確認できていることを目指します。無効にしたときに元のネットワークへ戻せることも確認し、状態が分からないままスイッチをオンにしておかないでください。

ステップ8 · 安定して使い続ける

サブスクリプションの管理、ログ、段階的なトラブル対処

繰り返し使える日常点検を行う

日常的に使うとき、設定を頻繁に変える必要はありません。接続に問題が起きたら、発生時刻、ネットワーク、クライアントとコアの種類、使用中のサーバー、接続方式、ルーティングモードを記録し、同じアクセスをもう一度試してください。記録があれば、一時的なネットワーク変化と継続的な設定ミスを区別できます。モバイルホットスポットと固定回線で結果が違うことも、切り分けの手がかりです。ただし、比較時にサーバーとDNSを同時に変えると、違いの原因を判断できません。

サブスクリプションは、提供元の案内や実際の変更に応じて更新します。短い間隔で何度もリクエストする必要はありません。更新後は使用中のサーバーが有効か、ローカルの例外ルールが残っているか確認します。クライアントをアップグレードする前に必要な設定をバックアップし、画面に表示される移行案内を読んでください。バックアップに認証情報が含まれる場合があるため、安全な場所に保管します。完全な設定を一般の共有スペースに同期したり、サブスクリプションURLをトラブル対処メモに書いたりしないでください。

ローカル、サブスクリプション、ノード、システムの4層で調べる

第1層はローカル環境です。コアが起動しているか、ポートで待ち受けているか、端末の時刻は正確か、ディスクに書き込めるか確認します。第2層はサブスクリプションです。更新結果、使用中の項目の期限や削除状況、プロトコルの対応状況を確認します。第3層はサーバーです。アドレスとポートへの接続、認証、トランスポートのパラメーターを確認します。第4層はシステムです。アプリの接続方法、システムプロキシ、ファイアウォール、仮想ネットワークインターフェース、DNSの設定が一致しているか調べます。

ログの内容が明確なら調査範囲を早めに絞れますが、根拠を飛ばさないでください。待ち受けの失敗がログに出ているなら、まずポートを確認します。認証失敗と表示されたら、認証情報と時刻を調べます。特定のアプリだけ通信できない場合は、そのアプリの接続方法を優先して確認してください。ノードのタイムアウトについては、4つの層に沿って接続タイムアウトを調べる方法もご覧ください。タイムアウトは結果を示すものであり、リモートノードで必ず障害が起きているとは限りません。

ログは必要な範囲だけ残す

一時的にログの詳細度を上げると、宛先やアウトバウンドの経路を確認しやすくなります。ただし、デバッグログを長期間大量に残すとディスク容量を消費し、アクセス先が記録される場合もあります。まず失敗したリクエストの時間帯を特定し、必要な部分を保存したら通常のログレベルに戻してください。共有前にサブスクリプション、認証情報、個人のアクセス先を削除し、エラーの前後関係は残します。「失敗」と書かれた最後の1行だけでは、入口の問題かリモート接続の問題か判断できません。

ネットワークの切り替え、システムのスリープ、バックグラウンド処理によって、以前の接続が使えなくなることがあります。デスクトップではシステムプロキシが現在の待ち受けポートを指しているか確認してから、コアを再起動して接続を作り直します。Androidではバックグラウンド制限とVPNの状態を確認してください。異常が起きるたびにアプリのデータを消去すると、比較に役立つ設定を失います。再起動で一時的に復旧した場合は、再起動を原因解決とみなさず、発生条件を記録してください。

ステップ9 · 応用と振り返り

応用設定と継続して学ぶための手順

理由を説明できるルールから広げる

最初の8章を終えた後、応用で大切なのは設定項目を増やすことではなく、各設定の理由を説明し、動作を確認し、元に戻せることです。特定のドメインを直結させる、1つのアプリに手動プロキシを使う、ネットワーク切り替え後も安定して接続するなど、具体的な要件を1つ選びます。期待する経路を書き出し、現在の設定との違いを探してください。要件を絞るほどテストしやすくなり、正常な他の通信に影響する可能性も下がります。

設定構造を学ぶときは、インバウンド、アウトバウンド、ルーティング、DNS、ログの参照関係を理解するところから始めます。タグは設定内の名前にすぎず、参照先と一致させる必要があります。同じ名前の項目でも、コアによって意味が異なる場合があります。GUIクライアントの高度な設定は、まず画面から保存してください。設定の生成方法と上書き規則を理解してからカスタム設定を検討します。次回の保存操作で手動変更が失われるのを防げます。

コアを切り替えるときは条件をそろえて比較する

v2rayNのマルチコア機能は互換性の確認に便利ですが、コアの切り替えを手当たり次第に試す修復ボタンとして使わないでください。まず対象のプロトコル、トランスポート、セキュリティ項目を新しいコアがサポートしているか確認します。ネットワーク、サーバー、テスト先は変えず、コアだけを切り替えて、起動結果と実際のリクエスト結果を記録してください。必要な機能がサポートされていない場合は、適切なコアや設定に戻します。設定を無理に解析させるために、重要なセキュリティ項目を削除しないでください。

別の端末へ移行するときも、手順を分けて進めます。まずOSとアーキテクチャに合うクライアントをインストールし、サブスクリプションを再登録して使用するサーバーを確認します。その後、ルーティングの例外と接続設定を移します。プログラムのフォルダー全体を別のOSへそのままコピーできるとは限りません。ファイルパス、権限、インターフェース名、システムプロキシの仕組みが異なる場合があります。移行後は、直結先、プロキシ先、ローカルサービスをそれぞれ確認し、以前のルールに誤った前提が残っていないか確かめてください。

設定の検証は小さな変更単位で行う

応用設定を試すときは、目的、変更した項目、確認結果、元に戻す方法を短く記録してください。実際の認証情報は記録しません。以下のリストは、変更の前後にそのまま確認手順として使えます。複雑なネットワーク図より実用的です。予想と異なる結果が出たとき、すぐに元に戻すべきか、次にどの層だけを変更すべきか判断でき、設定項目をさらに重ねずに済みます。

1. 今回の目的を1つに絞り、現在の動作する基準設定を記録する。
2. 対象のコアが必要な項目に対応しているか確認し、変更前の設定を保存する。
3. 1項目だけ変更し、接続を再確立してログ上の実際の経路を確認する。
4. プロキシ先、直結先、LAN内のサービスを確認し、影響範囲を記録する。
5. 失敗したら元に戻して再確認する。成功したら通常のログ設定に戻し、通常利用を再開する。

リモートDNS、ドメインスニッフィング、IPv6、UDPは次に学ぶテーマになりますが、1つずつ確認してください。DNSを調べるときは接続方式とサーバーを固定します。UDPではサーバー側の対応を確認します。IPv6ではアドレスファミリー、名前解決、ルーティングを合わせて調べます。これらを一度にすべて有効にしても、動作を説明しにくい環境になるだけです。設定項目が増えるほど、観察できるログと明確なテスト先が必要になります。

性能も条件をそろえて比較してください。遅延、接続確立時間、スループット、安定性はそれぞれ異なる指標です。1回の遅延テストで使い心地全体を判断することはできません。ダウンロードが遅い原因は、接続先のサイト、回線の混雑、接続の再利用、端末の負荷などさまざまです。条件を固定し、繰り返し確認して初めて比較できます。初回確認の詳しい手順は実接続テストとプロキシの動作確認をご覧ください。リストの並び順だけで判断しないようにしましょう。