V2Ray設定完全ガイド：v2rayN・v2rayNGのインストールからルーティングまで

基本概念：画面、コア、接続の流れ

GUIクライアントとプロキシコアの役割

V2RayはProject Vのプロキシエコシステムを構成する中核プロジェクトです。普段操作するv2rayN、v2rayNG、v2flyNGはGUIクライアントで、サーバー、サブスクリプション、ルーティング、起動オプションなどを管理します。実際の接続処理を担うのはコアです。V2FlyとXrayは関連するコアの系統ですが、機能の進化や設定の対応状況は同じではありません。画面にプロトコルの選択肢が表示されても、どのコアでもその設定を使えるとは限りません。互換性を判断する際は、クライアント、コア、サーバー側の要件をあわせて確認しましょう。

一般的な接続の流れは、アプリがリクエストを送信し、通信がローカルのプロキシ入口に入り、コアがルールに基づいて直結・プロキシ・遮断を選び、その後の接続を確立する、というものです。GUIで「起動」と表示されるのは、クライアントがコアの起動を試みたことを示すにすぎません。サーバーを選択しても、既定のプロキシ出口が指定されただけです。実際に目的のサービスへアクセスできるかは、アプリがその入口を使うか、ドメインを名前解決できるか、サーバー設定が正しいか、接続先が応答するかにも左右されます。問題を調べるときは、この流れに沿って段階ごとに確認しましょう。

プロトコル、安全レイヤー、トランスポートを混同しない

VMess、VLESS、Trojan、Shadowsocksはそれぞれ異なるプロキシプロトコルです。TCP、WebSocket、gRPCなどはトランスポート方式を表し、TLSやREALITYは接続のセキュリティ機構に関わります。共有リンクには各レイヤーの設定が組み合わされているため、プロトコル名だけを頼りにノードを手動で再作成することはできません。同じVLESSでも、トランスポート方式やセキュリティ設定、サービス名が異なれば接続できないことがあります。サーバー側が指定する組み合わせをそのままインポートし、よく見かける項目を手当たり次第に試すのは避けてください。

サーバーアドレス、TLSのサーバー名、HTTP Hostは特に区別が必要です。サーバーアドレスは接続先の入口を指定し、サーバー名は通常TLSハンドシェイクや証明書の検証に使われます。Hostはアプリケーション層の転送に使われる場合があります。これらの値は同じこともあれば、サーバー側の設計によって異なることもあります。REALITYでは公開鍵やshort IDなどのパラメーターも必要になる場合があり、それぞれ対応関係が決まっています。別の設定から値を流用してはいけません。項目が不足している場合は設定の入手元に確認し、エラーを回避するために検証を無効にするのは避けましょう。

サブスクリプション、共有リンク、ローカル設定の違い

共有リンクは通常、1つのサーバー設定を表します。一方、サブスクリプションURLはクライアントが定期的に取得できる設定の一覧です。サブスクリプションはプロキシ接続そのものでも、アカウントそのものでもありません。インポートに成功したということは、クライアントが内容を読み取れたというだけで、すべての接続が使えるとは限りません。特定のクライアントや設定形式向けのサブスクリプションもあり、ブラウザーで開けるからといって、そのままインポートできるとは限りません。完全な設定ファイルには入口、DNS、ルーティングなどが含まれ、共有リンク1件より広い範囲を設定することもあります。操作対象を確認してからインポートしてください。

以降の各章では、設定内容、コアの起動、アプリの接続、ルーティング先の順に確認します。一度に変更するのは1つのレイヤーだけにし、変更前の動作する状態を残しておきましょう。接続できないときに、インポート形式、接続パラメーター、ローカルでの通信の取り込み方のどこに問題があるかを切り分けやすくなります。プロトコル名、サブスクリプション名、クライアント名はそれぞれ別の要素を表すラベルであり、速度、安定性、サービス品質を直接判断する材料にはなりません。

クライアント選び：デスクトップとAndroidの使い分け

デスクトップにはv2rayN、Androidにはコア要件に合うクライアント

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを検討しましょう。サーバー管理、サブスクリプションの更新、ルーティングの選択、コアの設定をGUIから操作でき、接続状態を確認したい場合や、複数の設定を管理したい場合、ルーティングを調整したい場合に便利です。Windowsのダウンロードページでは、デスクトップ版と従来のWPF版を提供しています。前者はクロスプラットフォームのUI、後者は従来型のUIを採用しています。速度の違いを示すものではなく、画面の新旧だけでプロトコルへの対応状況を判断することもできません。実際の対応状況は、付属するコアとリリース情報を確認してください。

AndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアを採用するv2flyNGは別の選択肢です。選ぶ際は既存の設定要件、端末との互換性、必要なコア機能を基準にし、同じ端末で2つのクライアントを同時に起動するのは避けましょう。Androidでは通常、VPNによる通信の取り込みを同時に担えるのは1つのサービスです。別のVPN、仕事用プロファイル、セキュリティツールと競合することがあります。比較する場合は、先に使用中のサービスを停止し、同じネットワークとサーバー設定で検証してください。

OS	クライアントの選択肢	まず確認すること
Windows	v2rayN デスクトップ版、WPF版	対応OSとx64アーキテクチャ
macOS	v2rayN	Apple SiliconまたはIntel
Android	v2rayNG、v2flyNG	CPUアーキテクチャとプロトコル要件
Linux	v2rayN	ディストリビューションのパッケージ形式とCPUアーキテクチャ

アーキテクチャとインストール形式がパッケージの動作を左右する

インストールパッケージはCPUアーキテクチャに合わせて選びます。macOSでは「このMacについて」でチップを確認し、Apple Siliconならarm64、Intelならx64を選択してください。Linuxではパッケージ形式も確認します。一般にDebian、Ubuntu系はdeb、Fedoraなどはrpmを使います。拡張子が同じでも、依存関係まで完全に互換とは限りません。このサイトで案内しているWindows版はx64です。すべてのCPUで使えるパッケージではありません。アーキテクチャが合わない場合は、起動を何度も試すのではなく、適切なパッケージを選び直しましょう。

比較的新しいAndroid端末では、まずarm64版を検討できます。実際のシステムが別のABIで動作している場合は、互換パッケージを選ぶ必要があります。複数のアーキテクチャに対応するユニバーサル版は、アーキテクチャが分からない場合に便利ですが、パッケージのサイズが大きいからといって接続性能が向上するわけではありません。端末の製造時期はあくまで目安です。正確な情報はシステムや端末が示すアーキテクチャを確認してください。インストーラーで非対応と表示された場合は、システム要件、ABI、空き容量を確認してから、古い署名との競合を検討しましょう。

実際の使い方に合わせて選ぶ

パソコンとスマートフォンで同じサブスクリプションを使いたい場合は、両方のクライアントがその形式とサーバーのプロトコルに対応しているかを確認します。クライアント名をそろえる必要はありません。共有リンクで接続パラメーターを渡せても、デスクトップのシステムプロキシやAndroidのアプリ別ルーティングはローカル設定なので、通常はそれぞれ設定が必要です。サーバーがREALITYを要求する場合は、使用するコアとクライアントが必要な項目に対応しているか確認してください。「VLESS対応」だけで、あらゆるVLESSの組み合わせが使えるとは限りません。プロトコルの詳しい違いはプロトコル比較記事をご覧ください。

インストール前にクライアントのダウンロードページでOSと配布パッケージを確認し、クライアント比較で用途に合うものを選びましょう。メインで使うクライアントは1つにし、もう一方は必要なときの検証用として残しておく方法がおすすめです。使い勝手を比較するときは、同じサーバー、ネットワーク、接続先を使用してください。プロトコル設定が異なる場合、差はクライアントではなく接続先の環境に起因することもあります。インストールパッケージの種類を記録しておけば、同じ系統で更新を続けやすく、設定フォルダーや実行方法、移行手順もそろえられます。

インストールと初期設定：まずローカル環境を整える

インストール前に権限、保存先、既存設定を確認

インストール前に同種のクライアントを終了し、ダウンロードしたパッケージがOSとアーキテクチャに合っているか確認してください。以前にポータブル版や別の配布形式を使っていた場合は、設定をバックアップし、新旧のファイルを同じフォルダーに混在させないようにしましょう。インストール先とユーザー設定の保存先は異なる場合があり、プログラムを削除しても設定が消えるとは限りません。「再インストールしても以前の設定が残る」のは異常ではありません。クライアントに表示される設定の保存先やOSのアプリ用フォルダーを確認し、他のソフトのデータを誤って削除しないようにしてください。

Windowsでは、初回起動時にメイン画面が正常に表示されるか確認してから、実行ログを見ます。ポータブル版は、ユーザーが読み書きできる安定した場所に置き、圧縮ファイルのプレビューから直接起動したり、自動削除される一時フォルダーに保存したりしないでください。通常のシステムプロキシ操作で、常に管理者として実行する必要はありません。TUNや関連サービスには、追加の権限が必要な場合があります。セキュリティソフトがファイルを隔離した場合は、配布元と検出内容を確認し、システム全体の保護を安易に無効にしないでください。

OSごとの手順で初回起動を確認する

macOSではダウンロードページの案内に従い、チップに合ったパッケージを選びます。アプリを安定した場所に置いてから起動してください。システムに起動を阻止された場合は、「プライバシーとセキュリティ」に表示される理由を確認し、OSが案内する手順で許可します。すべてのアプリに対するセキュリティチェックを無効にするような汎用コマンドは避けてください。ネットワークや補助機能の権限を初めて求められたときは、許可を要求しているのが使用中のクライアントであることを確認しましょう。起動後にウィンドウが見つからない場合は、メニューバーやDockの状態も確認し、バックグラウンド動作、ウィンドウの非表示、アプリの終了を切り分けます。

Linuxでは、ディストリビューションが対応するパッケージ管理方法でdebまたはrpmをインストールします。パッケージマネージャーが依存関係の問題を報告した場合は、先に解消してからGUIを起動してください。システムプロキシへの対応はデスクトップ環境によって異なります。クライアント側で設定できたからといって、すべてのアプリが接続されたとは限りません。Androidではインストール後にアプリを起動してから設定をインポートします。初めてプロキシを起動するときは、通常VPNの使用許可が求められます。これはシステムがローカルの通信取り込みサービスを許可するもので、サブスクリプションやサーバーへの接続を検証した証明ではありません。

入口を確認してからサーバーを調べる

初回起動時はTUNをオフにし、ほかのプロキシツールも一時的に終了してください。設定画面でローカルの待ち受けアドレス、ポート、入口の種類を確認し、HTTP、SOCKS、混合のどれかを把握します。ローカルポートに共通の必須値はありません。説明に出てくる例のポートを、実際の設定にそのまま当てはめないでください。ログにアドレスの使用中と表示された場合は、残っているプロセスを終了するか、待ち受けポートを変更しましょう。ポートを変更した場合、手動でプロキシを設定しているアプリも更新しないと、古い入口にリクエストを送信し続けます。

待ち受けアドレスは、まずローカルループバックの範囲に設定し、この端末からのみ使えるようにします。「LAN接続を許可」を有効にすると入口にアクセスできる範囲が広がります。ファイル共有とは別の設定です。必要な場合はファイアウォールの接続元を制限し、適切なアクセス制御も設定してください。初回テストでLANを開放したり、すべての詳細オプションを有効にしたりする必要はありません。この時点ではサーバーがなくても、画面表示、設定の保存、ログ表示が正常に動作することを確認できます。コアを起動できない場合はパス、権限、依存関係を確認してください。サブスクリプションを更新しても、ローカルの実行環境の問題は解決しません。

簡単な環境メモを残しておくと便利です。OS、クライアントの種類、設定の保存先、待ち受け入口、現在の権限設定を記録しましょう。アカウント、サブスクリプションURL、サーバーの認証情報は記録しないでください。更新や移行の際、プログラムが起動しないのか、プロキシの接続経路に問題があるのかを切り分けやすくなります。インストールだけでは設定は完了しません。環境を安定させておけば、以降の変更を比較する基準になります。具体的なボタンの順序はクイックスタートガイドをご確認ください。

サブスクリプションの追加：グループ、更新、設定確認

追加するのがサブスクリプションURLか共有リンクか確認

サブスクリプションURLは、ネットワーク経由で設定を取得するためのリンクです。共有リンクは通常、vmess://、vless://、trojan://、ss://などで始まります。コピーする前に、提供元がどちらを案内しているか確認してください。サブスクリプション管理ページのURLをサブスクリプションURLと取り違えたり、ログインページの内容をサーバー一覧として扱ったりしないようにしましょう。アカウント識別子やアクセス用の情報を含むURLは機密情報として扱い、公開コメント、スクリーンショット、チャットグループに貼り付けないでください。

v2rayNでは、まずサブスクリプショングループの管理画面を開き、見分けやすい名前でグループを作成して、サブスクリプションURLを入力し保存します。その後、そのグループを更新し、結果とサーバー一覧を確認してください。インポートを何度も繰り返す必要はありません。v2rayNGでは、サブスクリプション設定にURLを追加し、該当するメニューから更新します。画面やバージョンによってメニュー名は異なりますが、基本の順序は「取得元を保存してから内容を取得」です。共有リンク1件の場合はクリップボードからインポートすればよく、サーバー1台のためにネットワークサブスクリプションを作る必要はありません。

接続に影響する設定項目を確認

サーバー一覧に項目が表示されたら、まず1つ選んで編集画面を確認します。アドレス、ポート、ユーザー識別子またはパスワード、プロトコル、トランスポート方式、セキュリティ設定を重点的にチェックしてください。WebSocketではパスとHost、gRPCではサービス名を確認します。TLSではサーバー名と証明書の検証設定、REALITYでは公開鍵、short ID、必要なフィンガープリントなどを確認してください。入力が必要かどうかはサーバー側の設定によります。空欄を見つけても、よくある値を適当に入力しないでください。

インポート時に「未対応の形式」と表示された場合は、コピーした内容に説明文や前後の空白が含まれていないか、チャットツールで途中が切れていないか確認してください。サブスクリプションがログインページやエラーメッセージ、ほかのクライアント専用の形式を返す場合も、解析に失敗することがあります。ページが開けることと、設定を解析できることは分けて考えましょう。形式変換が必要な場合は、対応範囲が明示された信頼できる方法を優先してください。変換サービスがサブスクリプションの全内容を取得する可能性があるため、機密情報を不明なサイトに送信しないでください。

サブスクリプションの更新失敗は、サーバーすべての停止を意味しない

サブスクリプションの更新は独立したHTTPリクエストなので、DNS、証明書、ネットワーク状態、アクセス権の影響を受けることがあります。現在のサーバーに接続できる場合は、それらを残したまま更新ログを確認してください。クライアントによってはプロキシ経由で更新できます。サブスクリプション提供元に直接アクセスできず、既存のプロキシが使える場合に便利です。ただし、インストール直後で利用できる出口がなければ、この設定だけですべての問題を解決することはできません。端末の時刻も確認してください。時刻のずれは安全な接続に影響する場合があります。

更新前に、そのグループの更新時の置き換え方法を確認しましょう。サブスクリプションから作られた項目は、次回更新時に再生成される場合があります。手動で変更した名前、設定、並び順が保持されるとは限りません。一時的な変更が必要なら、独立した手動グループに複製して用途を明記し、試験用の項目をメインの一覧に混在させないようにしてください。サブスクリプション元の削除と、インポート済みサーバーの削除は別の操作である場合があります。削除前に確認メッセージをよく読みましょう。サーバー名の記号に頼るより、取得元や用途ごとにグループを整理すると管理しやすくなります。

インポート後は設定項目が明確なサーバーを1つだけ選び、すぐに一括切り替えを行わず、基準として使える状態を確認します。グループ、選択中のサーバー、更新元を確認したら、次章でアプリの接続を検証しましょう。パソコンとAndroidで互換性のあるサブスクリプションを共有しても、ローカルのルーティング、アプリ一覧、権限は個別に確認が必要です。移行方法は複数端末での設定同期の記事をご覧ください。「サブスクリプションの更新に成功」と「プロキシ接続全体を検証済み」は同じではありません。

プロキシモード：アプリの接続方法と出口を分けて設定

システムプロキシで接続できるのは一部のアプリ

デスクトップのシステムプロキシを設定すると、その設定に従うアプリがリクエストをどのローカルプロキシ入口へ送るか指定できます。ブラウザーは通常システム設定を参照しますが、コマンドラインツール、ゲーム、一部のデスクトップアプリは独自の接続方法を使うことがあります。そのため、システムプロキシを有効にした後もアプリが直接接続するからといって、ノードが無効とは限りません。アプリがシステムプロキシに対応しているか、独自のプロキシや除外リストが設定されていないかを確認し、アプリ内設定を使うか、後の章で説明するTUNで通信を取り込むか判断してください。

v2rayNのシステムプロキシ設定には、一般に「クリア」「自動設定」「システムプロキシを変更しない」があります。「クリア」は関連するシステムプロキシ設定を削除し、「自動設定」は対応するシステムプロキシをローカル入口に向けます。「変更しない」はクライアントが現在のシステム設定を変更しないという意味で、システムにプロキシ設定がないことを保証するものではありません。別のプログラムが設定したアドレスが残っている場合もあります。クライアントの終了後にWebページが開けなくなった場合は、停止中のローカルポートをシステムが参照していないか確認してください。

グローバル設定とバイパスルールで接続後の出口が決まる

ルーティングモードは別の設定です。一般的なグローバルプロキシでは、コアに入った通信をプロキシ出口へ送ります。「中国本土をバイパス」などのプリセットは、ドメインやIPアドレスの分類に基づいて直結とプロキシを選択します。ここでいう「グローバル」は、OS上のすべてのプロセスを対象にするという意味ではありません。コアに入っていない通信をルールが自動的に取り込むことはありません。システムプロキシは「通信を取り込むか」、ルーティングは「取り込んだ後どこへ送るか」を決めます。両者の組み合わせで最終的な動作が決まります。プリセットの具体的なルールは、クライアントが提供する一覧で確認してください。

直結はクライアントの終了を意味しません。あるルールで直結が選ばれる場合、通信はいったんコアに入った後、出力段階で端末から接続先へ直接送られていることがあります。ブロックは条件に一致したリクエストを明示的に拒否する動作で、接続タイムアウトとは異なります。切り分けでは、一時的に単純なルーティングモードにして動作を比較しても構いませんが、テスト後は元の設定に戻してください。一時的なグローバルモードを恒久的な解決策とみなさないようにしましょう。グローバルでは接続できるのにルーティングで失敗する場合は、同じサブスクリプションを再インポートするより、ルールとDNSを確認してください。

再現できるテストで通信の取り込みを確認する

検証時はTUNをオフにしたまま、コアを起動し、システムプロキシを有効にします。システム設定に従うことが分かっているブラウザーで、アクセス先を指定してテストしてください。その後、ログや接続情報に該当する通信が表示されているか確認します。ブラウザーの既存接続、キャッシュ、独自のセキュアDNS設定が結果に影響することがあるため、新しい接続を作るか、アプリを再起動して比較しましょう。ローカルのHTTP入口を指定してテストする場合は、次のコマンドを使えます。ポート番号を実際の待ち受けポートに変更し、入口がHTTPプロキシに対応していることを確認してください。

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

このコマンドで確認できるのは、指定した入口を通じた接続先へのリクエストです。システムプロキシは変更しません。例のポート番号はクライアント共通の初期値ではありません。プロキシへの接続が拒否された場合は、まずローカルの待ち受け状態を確認してください。プロキシには接続できても、その後タイムアウトする場合はサーバー、DNS、接続先へのアクセスを調べます。接続先によってはHEADリクエストに特殊な応答を返すため、HTTPエラーが表示されてもプロキシ障害とは限りません。接続の過程もあわせて判断してください。コマンドラインツールがない場合は、アプリ独自のプロキシ設定でも同様の比較ができます。

Androidでは通常、システムVPNインターフェースを通して通信を取り込みます。アプリごとのプロキシ設定やLANのバイパスなど、対象範囲に影響するオプションもあります。デスクトップのシステムプロキシ設定をAndroidにそのまま当てはめないでください。一部のアプリだけに問題がある場合は、そのアプリがプロキシの対象か、バックグラウンド動作をシステムに制限されていないか、別のVPNサービスと競合していないかを確認します。詳しくはシステムプロキシとルーティングモードの違いをご覧ください。まず再現可能な結果を確認してから、細かなルーティングを調整しましょう。

ルーティング：ルールの順序、DNS、出口タグ

一致する順序を把握してからルールを追加

ルーティングルールは通常、上から順に評価され、最初に一致したルールが出口を決めます。どのルールにも一致しなければ、既定のポリシーが適用されます。実際の項目や条件の組み合わせはコアの仕様に従うため、単なるラベルの一覧として扱わないでください。広い範囲に適用されるプロキシルールを先に置くと、後続の細かな直結ルールに到達しないことがあります。最初は、必要なLAN設定、明示的なドメイン例外、地域別ルール、既定の出口に絞り、1つずつ検証してから拡張しましょう。

ドメインルールとIPルールは、それぞれ異なる情報を使います。クライアントが元のドメインを把握していれば、ドメインに基づく照合が可能です。接続先のIPだけが渡された場合、ドメインルールの照合に必要な情報が不足することがあります。DNSの名前解決結果はIPの分類にも影響するため、DNSとルーティングは一連の設定として確認してください。Webサイトの表示言語が日本語だからといって、そのサイトを直結対象に分類するのは適切ではありません。ドメイン、コンテンツ配信ネットワーク、サーバーの所在地に固定の対応関係はありません。地域別ルールは管理されたデータセットであり、リアルタイムの測定結果ではありません。

設定の断片は正しい階層に配置する

以下はXrayのルーティングオブジェクトを説明するための例で、単体で起動できる完全な設定ではありません。プライベートアドレスの直結、指定ドメインの直結、地域別ルールの順序を示しています。使用前に、現在の設定にdirectという名前のアウトバウンドがあり、対応するgeosite、geoipデータファイルがインストールされていることを確認してください。GUIクライアントにルール編集画面がある場合は、実行時に自動生成される設定を直接編集せず、画面から追加する方法を優先しましょう。既定のアウトバウンドを含む全体の設定がない場合、この断片だけを見ても、すべての通信の行き先は判断できません。

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

geosite:cn → directは、該当するドメインのリストを直結アウトバウンドに送る設定です。geoip:cnはアドレスのリストを対象にします。domain:example.comはドメインのサフィックスによる照合で、通常はそのドメインとサブドメインに一致します。任意の位置にある文字列を検索する設定ではありません。AsIsはルーティングの照合用にドメインをIPへ積極的に解決しません。そのため、ドメインで接続されたリクエストが地域別IPルールだけで別の出口に切り替わるとは限りません。ほかの名前解決方式を選ぶ前に、適用条件と問い合わせの負荷を確認してください。

スニッフィング、DNS、例外ルールの範囲

トラフィックスニッフィングは、特定のプロトコルでドメイン情報を復元する助けになりますが、すべてのリクエストを識別できるわけではなく、アプリの暗号化を回避する汎用手段でもありません。アプリ独自のDNS、暗号化DNS、IPアドレスへの直接接続を使う場合、ルーティング側から見える情報は異なることがあります。スニッフィングやDNSを変更した後は、同じ接続先でどのルールが一致するかを確認してください。Webページが開くかどうかだけでは判断できません。クライアントに接続の詳細表示がある場合は、実際の接続先、一致したルール、出口を優先して確認しましょう。通常のログレベルではすべての情報が記録されないことがあります。

例外を追加する場合は、対象をドメインまたはアドレスの最小範囲に絞り、適切な位置に配置します。アドレス範囲全体を直結すると無関係なサービスまで対象になることがあり、広いドメイン範囲をプロキシにするとLANリソースへのアクセスが変わる場合があります。設定を変更したら保存して適用し、接続を作り直してください。既存の接続には、変更後のルールがすぐ適用されないことがあります。ルーティングに失敗した場合は最後に追加したルールを戻し、データファイルの有無、タグの正確さ、ドメインにプロトコルやパスが含まれていないか確認してください。ルールには通常、完全なWebページのURLではなくドメインだけを指定します。

TUNモード：通信の取り込み範囲を広げ、ループを防ぐ

TUNが必要になる場面

TUNは仮想ネットワークインターフェースを使ってIP通信を取り込み、システムプロキシを参照しないアプリや、個別にプロキシを設定しにくいアプリに適しています。変わるのは通信がクライアントに入る方法であり、誤ったサーバーパラメーターが自動で直るわけでも、サーバー側が新しいプロトコルに対応するわけでもありません。通常のブラウザーやプロキシ対応の開発ツールが問題なく使えているなら、システムプロキシの設定をそのまま使えます。アプリの通信を取り込めない問題が明確な場合にTUNを追加すれば、確認する範囲を絞れます。

デスクトップのTUNでは、仮想インターフェース、ルーティングテーブル、DNSの取り込み、より高い権限が必要になることがあります。実際の仕組みはクライアントと選択したコアによって異なります。v2rayNのGUIが複数のコアや補助コンポーネントを制御する場合もあり、TUN設定をすべてのXray設定に共通する単一の項目と考えることはできません。コアを切り替える前に、現在使用しているサーバー、セキュリティ機構、ルーティング、DNSが新しいコアで使えるか確認してください。設定をインポートできることと、実行時の動作が同じであることは別です。特に異なる系統のコアで、未加工の設定ファイルをそのまま入れ替えないでください。

すべてを一度に有効にせず、段階的に設定する

TUNを有効にする前に、システムプロキシまたはアプリの明示的なプロキシ設定で、同じサーバーに接続できることを確認します。設定をバックアップし、ほかのVPNや通信を取り込むツールを終了してください。クライアントの案内に従って必要なサービスのインストールや権限の許可を済ませてからTUNを有効にします。初回は推奨されるスタックと自動ルーティングを維持し、MTU、DNSアドレス、アプリの除外設定を同時に変更しないでください。インターフェースの作成に失敗した場合は、サブスクリプションを変更したりサーバーを一括テストしたりする前に、権限、残存プロセス、ドライバーの状態を確認しましょう。

構成によってはTUNとシステムプロキシを併用できますが、問題を切り分ける際は経路の重複を減らし、リクエストがどの入口を通ったか分かるようにしましょう。有効にしたら、まず通常のWebページを確認し、次にプロキシを参照しないアプリを試し、最後にLAN上の機器や内部サービスへの接続を確認します。あるアプリで使えるからといって、UDP、IPv6、すべてのDNSリクエストが想定どおり処理されているとは限りません。これらの機能はクライアント、コア、サーバー、ネットワーク経路のすべてが対応している必要があります。音声通話やゲームで使う場合は、実際の機能を個別に検証してください。

DNS、ループバック、LANの例外

DNSを取り込む場合は、名前解決リクエストが上流のDNSサーバーに届き、上流への通信が繰り返し自分自身に取り込まれないようにする必要があります。プロキシクライアントからサーバーへ接続する通信も、適切に除外するか、出力インターフェースにバインドしないと、ループが発生することがあります。起動後に接続がたまる、CPU使用率が異常に上がる、ネットワーク全体が使えないといった症状が出たら、まずTUNを無効にして基準の状態に戻し、自動ルーティングと出口の除外設定を確認しましょう。適当な直結ルールを追加し続けて問題を隠すのは避けてください。

LANプリンター、共有フォルダー、ルーターの管理画面、社内アドレスへの通信は、明示的にバイパスする必要がある場合があります。ただし、プライベートアドレスを直結する設定が適切かどうかは利用環境に応じて判断してください。社内ネットワークでは、専用VPNによって内部ルートを提供している場合があり、単純にバイパスしてもアクセスできるとは限りません。IPv6が取り込まれているかどうかも個別に確認してください。IPv4で成功しても、もう一方のアドレスファミリーの経路が正常とは限りません。一部のWebサイトだけに問題がある場合は、DNSの結果とアドレスファミリーを比較してから、MTUや経路を調べます。すべての問題をDNSのせいにしないでください。

TUNを無効にした後は、通常の直結、LANへの接続、スリープからの復帰後のネットワーク状態を確認します。クライアントが異常終了するとサービスやシステム設定が残ることがあります。まずクライアントの正規の停止手順で復元し、必要な場合のみOSのネットワーク管理機能を使って対処してください。Androidの通常のVPN接続とデスクトップのTUNでは、権限やルーティングの仕組みが異なります。デスクトップのドライバー、サービス、インターフェースの手順をそのまま適用しないでください。「対象アプリの通信を取り込める」「内部リソースに接続できる」「停止後にネットワークが復旧する」の3点を確認できたら、TUNを日常利用に組み込めます。

日常のメンテナンス：ログ、速度測定、更新、バックアップ

問題のあるレイヤーを切り分ける

ネットワークに問題が起きたら、発生時刻、ネットワーク環境、対象アプリ、最後に変更した設定を記録します。クライアントが動作中か、コアが終了していないか、ローカルの入口が競合していないかを確認してから、選択中のサーバーとルーティングを調べましょう。ログのconnection refusedは、接続先が接続を拒否したことを示すのが一般的です。ただし、接続先はローカル入口のこともリモートサーバーのこともあるため、アドレスとあわせて判断してください。i/o timeoutは応答を待っている間にタイムアウトしたことを示しますが、それだけでアカウントの無効、サーバーの停止、DNS障害を証明するものではありません。

ハンドシェイクに失敗した場合は、プロトコルのパラメーター、セキュリティ設定、端末の時刻、サーバー側の要件を確認してください。ログのエラーはバックグラウンドの接続確認や、すでに終了した古い接続に関するものかもしれません。対象を特定せずに解釈しないでください。問題の調査中だけログレベルを一時的に上げ、再現を1回確認したら通常のレベルに戻すと、ログの増えすぎを防げます。ログを共有する前に、サーバーアドレス、ユーザー識別子、サブスクリプションの情報、リクエストに含まれる個人情報を削除しましょう。詳しくは実行ログの読み解き方をご覧ください。

速度測定の結果は実際の目的に合わせて読む

TCPingで分かるのは、主に接続先のポートへ接続できるかどうかであり、プロキシ認証や接続先へのアクセスまで完了したことを示すものではありません。実接続の遅延測定は、より実際のプロキシ接続に近い経路を使いますが、測定先、DNS、ハンドシェイク、その時点のネットワーク負荷にも左右されます。ダウンロード速度測定では転送量が多く、実際の通信量を消費します。また、すべての接続先やアプリの性能を示すものでもありません。測定方法が異なる結果を同じ基準で並べて評価するのは避けましょう。一度の失敗だけで設定を削除せず、まず測定条件がそろっているか確認してください。

比較では端末、ネットワーク、測定先、プロキシモードをそろえ、サブスクリプションの更新と一括測定を同時に行わないようにします。まず実際の接続が安定して確立できるかを確認し、その後にアプリで必要な速度と応答性を見ます。バックグラウンド同期、Wi-Fiの電波状況、サーバー側の速度制限も結果に影響します。クライアントの一覧に表示される順位は、その時点での測定結果にすぎません。測定指標の違いは遅延測定とダウンロード速度測定の違いをご覧ください。普段から頻繁に全サーバーを測る必要はありません。現在の問題に絞って再測定する方が有効です。

更新とバックアップは元に戻せる状態で行う

更新前にクライアント設定をエクスポートし、現在使えるルーティング、DNS、カスタムグループを保存してください。バックアップには有効な認証情報が含まれる場合があるため、安全な場所に保管し、通常のスクリーンショットや文書と同じように同期しないでください。まずクライアントのエクスポートやバックアップ機能を使いましょう。ファイルを手動でコピーする場合は、書き込み中のデータが含まれないよう、先にクライアントを終了してください。プログラム本体、ユーザー設定、実行時に自動生成される設定は別のものです。インストール先だけを保存しても、環境を完全には復元できないことがあります。

ダウンロードページで、以前と同じOS、アーキテクチャ、UIの系統を選んで更新します。既存のバックアップは残したまま、コアの起動、サブスクリプションの更新、ルーティング、TUNを確認してください。新しいバージョンで設定形式が移行される場合があります。問題が起きても、移行後の設定を古いプログラムで直接読み込まず、更新前のバックアップに戻してください。クライアントとコアの更新も分けて検証すると、問題の原因を特定しやすくなります。明確な理由がない限り、漠然とした「高速化」を期待してコアを頻繁に切り替える必要はありません。

日常のメンテナンスは、サブスクリプション元が利用できるか確認し、不要になった試験用項目を整理し、バックアップを開けるか確かめ、ログが異常に増えていないか確認する、という短い手順にまとめられます。自動起動やサブスクリプションの定期更新は、設定が安定してから有効にしてください。スリープ、ネットワークの切り替え、OSの更新後の動作にも注意しましょう。設定を復元したら、実際の接続をあらためて検証します。項目数を見るだけでは不十分です。再現でき、原因を説明でき、元に戻せることは、検証していない設定を数多く残すことより重要です。

応用編：再現可能な設定と複数端末への移行

使える状態を基準に整えてから、性能やプロトコルを試す

最初の8段階を終えたら、認証情報を含めずに設定の概要をまとめます。クライアントの種類、使用するコア、サーバーのプロトコルとトランスポートの組み合わせ、アプリの接続方法、ルーティングのプリセット、DNSの設定、TUNの状態を記録してください。すべての項目を複製するのではなく、時間がたってから問題を調べる際に状況を把握できるようにするためです。動作確認済みの設定を基準として残し、試すたびに変更する変数は1つだけにします。期待した結果、実際の結果、元に戻す方法を記録すれば、記憶を頼りに複数の設定を連続で切り替えることを防げます。

プロトコルを詳しく検討する際は、まず設定項目間の依存関係を確認します。VLESSには一部のプロトコルと同じ仕組みの独自暗号化がないため、実際の安全性は選択したセキュリティレイヤーと設定全体に左右されます。Trojanは通常TLSと組み合わせ、Shadowsocksではクライアントとサーバーの暗号化方式およびパスワードを一致させる必要があります。VMessの動作も実装やパラメーターによって異なります。プロトコル名だけで性能やセキュリティレベルを保証することはできません。端末の性能、ネットワーク経路、サーバーの実装、運用方法も含め、構成全体を評価してください。

REALITYとトランスポートを調整する前に互換性を確認

REALITYを使うには、クライアントとサーバーのセキュリティパラメーターを一致させる必要があります。サーバー名、公開鍵、short ID、フィンガープリント、その他の必須項目を信頼できる情報源で確認し、コアが対応しているかも調べてください。ハンドシェイクに失敗した場合は、トランスポートの組み合わせを調整する前に、設定の漏れ、時刻のずれ、入口への接続可否を確認します。証明書検証のスキップは、設定ミスを直すための一般的な手段ではありません。別のサーバーの項目をコピーして試すのも避けてください。コアを変更した後は、これらの項目が正しく引き継がれているか再確認しましょう。

トランスポートの調整は、実際の問題に基づいて行います。接続の再利用、並列処理、MTU、DNSキャッシュは、状況によって改善につながる一方、リソース消費を増やしたり、問題の現れ方を変えたりすることもあります。まず、ハンドシェイクの繰り返しを減らしたいのか、特定アプリの応答を改善したいのか、経路の問題を解決したいのかを明確にしてから、対応する項目を選びます。同じ接続先と負荷で試し、最良だった一度の結果だけでなく、実際の利用状況をしばらく確認してください。再現性のある改善がない変更は、よりシンプルで管理しやすい設定に戻しましょう。

複数端末への移行では共有に適した情報だけを同期する

デスクトップとAndroidで互換性のあるサブスクリプションを共有することはできますが、アプリ別のルーティング一覧、ローカルの待ち受け設定、システムプロキシ、TUNの権限、設定フォルダーは端末ごとの情報です。デスクトップの実行設定全体をスマートフォンに上書きしたり、同じサブスクリプションならルーティングも自動的に同じになると考えたりしないでください。新しい端末にはクライアントを個別にインストールし、同じ信頼できる取得元から設定を追加して、まず1つのサーバーで接続を確認します。その後、ルーティングとDNSを一つずつ再設定しましょう。新しい端末で実際のアプリをテストできるまでは、古い端末の設定を使える状態に保ってください。

共有リンクは少数のサーバーを渡すのに適し、QRコードは近くの端末へのインポートに便利です。完全なバックアップは同種のクライアントを復元するのに向いていますが、いずれも同じ水準で保護してください。受け取り手、送信経路、保存先を確認し、移行後は一時ファイルやスクリーンショットを削除しましょう。ルーティングルールは別の文書として管理し、対応するコア、アウトバウンドタグ、必要なデータファイルを記録できます。機密性の高い設定は別に保管してください。形式に違いがある場合は、各項目の意味を比較し、理解していないセキュリティ設定を削除してまでインポートを優先しないでください。

設定変更の最後に結果を検証する

変更のたびに同じ項目を確認します。コアが正常に起動すること、指定したアプリが接続できること、通信先がルールどおりであること、LANリソースを使えること、クライアント停止後にネットワークが復旧することです。UDP、IPv6、TUNを使う場合は、必要な個別テストも追加してください。結果の理由を説明できない場合は、ログと環境の概要を保存し、動作確認済みの設定に戻してから、再現範囲を絞り込みます。Webページを一度開けただけで全項目を検証したことにしたり、一時的に動作しただけですべてのアプリが正しく設定されたと判断したりしないでください。