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

ステップ1：クライアント、コア、接続経路を理解する

プロキシ接続をいくつかの独立した段階に分けて考えます。アプリがリクエストを発行し、クライアントがローカルの入口を提供し、コアが設定を読み込んでルーティングを実行します。選択されたサーバーが、その先への転送を担います。GUIは設定を管理するものであり、接続そのものではありません。ウィンドウが開くのはGUIの起動に成功した証拠にすぎません。サブスクリプションを更新できても、設定を取得できたことしか分かりません。接続経路が機能しているかは、目的のページに正常にアクセスできるかで確認します。各段階の役割を切り分ければ、問題が起きたときに確認すべき場所を絞れます。

Project V、V2Fly、Xrayの違い

V2RayはProject Vのプロキシツール群に属します。V2Flyは関連するコアをコミュニティで継続的に開発しており、Xrayは別の発展を続けるコアの系統です。コアはプロトコル処理、トランスポート、暗号化接続、ルーティング、DNSなどを実行します。v2rayN、v2rayNG、v2flyNGは設定を管理してコアを起動するGUIクライアントです。名前が似ていても、コアや機能、設定項目がすべて同じとは限りません。機能の説明を確認する際は、使用中のクライアント、実際のコア、サーバー側の要件をあわせて確認してください。

プロトコル、トランスポート、接続パラメーターを区別する

VMess、VLESS、Trojanなどはプロトコル層、WebSocketやgRPCなどはトランスポート方式を表します。TLSは暗号化ハンドシェイクと証明書の検証に関わります。これらは互いに置き換えるボタンではなく、連携して動作する別々の層です。サーバーが要求する組み合わせに合わせて、クライアントにも正しく設定する必要があります。アドレスとポートが正しくてもパスが違う、またはプロトコルが合っていてもサーバー名が違うと、接続に失敗します。設定を手作業で組み立てるのではなく、完全な共有リンクやサブスクリプションを使いましょう。

ノードとは、クライアントが保存する接続パラメーターのまとまりです。通常、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式、関連するセキュリティ設定が含まれます。ノード名は識別のためのもので、名前に記載された地域や回線の説明だけでは、実際の出口や性能を確認できません。サブスクリプションはノード設定をまとめて取得する方法です。サブスクリプションを追加してもサービスが提供されるわけではなく、含まれるすべてのノードが現在使える保証もありません。クライアント、サブスクリプションの提供元、リモートサービスは、それぞれ別のものとして理解しましょう。

通信経路をたどって設定の役割を確認する

アプリがリクエストをクライアントに渡すかどうかは、システムプロキシ、アプリ独自のプロキシ設定、またはTUNによる取り込み方法で決まります。リクエストがコアに届いて初めて、ルーティングルールによって直結、プロキシ、ブロックのいずれかが選ばれます。そのため、システムプロキシの「自動設定」とルーティングの「グローバル」は別の設定です。前者はクライアントへの入口、後者は受け取った通信の出口を決めます。システムプロキシを使わないアプリでは、ルーティングルールだけを変えても通信経路が変わらないことがあります。

学習の際は、1台の端末、1つのクライアント、動作確認済みのノード1つで最小限の接続経路を作ります。複数のプロキシツールを同時に動かすのは避けましょう。テスト内容も固定します。まず通常のネットワークが使えることを確認し、次にプロキシが必要な宛先へアクセスし、最後にログと出口を確認します。各段階で期待する結果を把握していれば、DNS、ルーティング、仮想ネットワークインターフェースを変更した際に、問題が解決したのか、新たな問題が加わったのかを判断できます。

ステップ2：プラットフォームと設定に合ったクライアントを選ぶ

デスクトップではv2rayNが第一候補です。インストーラーを選ぶ際は、まずOS、次にプロセッサーアーキテクチャ、最後にGUIの系統とパッケージ形式を確認します。「クライアントがそのプラットフォームに対応している」ことは、「どのインストーラーでも動作する」という意味ではありません。同じ製品でも、ビルドによって依存関係、権限要件、画面構成が異なる場合があります。クライアントのダウンロードページでプラットフォームに合った項目を確認し、別のガイドのスクリーンショットにあるファイル名から、ダウンロードするパッケージを推測しないでください。

デスクトップ版とクラシックWPF版の選び方

Windows版には、v2rayNデスクトップ版とクラシックWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来の画面構成を引き継いでいます。初めて設定する場合はデスクトップ版から始めるとよいでしょう。WPF版で確立した操作手順がある場合は、従来のメニュー構成のまま使い続けることもできます。画面によって設定項目の場所やローカルデータの構成が異なる場合があります。旧版を起動したまま新版で同じデータを変更しないでください。切り替える前にクライアントを終了し、既存の設定を保存します。

macOSではチップに合わせてApple Silicon版またはIntel版を選び、「このMacについて」でプロセッサーを確認します。Linuxではディストリビューションのパッケージ形式を確認し、x64かarm64かも確かめてください。debとrpmはパッケージ管理の形式であり、性能の違いを表すものではありません。外見からアーキテクチャを判断することもできません。互換レイヤーで起動できても、その端末に最適なビルドとは限りません。インストールに失敗したら、まずパッケージ形式とアーキテクチャの不一致を確認し、その後で依存関係を調べます。

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

AndroidではXrayコアを採用したv2rayNGが第一候補です。V2Flyコアを使う設定が必要な場合は、v2flyNGも検討してください。2つのクライアントは、ノード数や画面の色ではなく、コアとの互換性や使い方で選びます。新しい一般的なスマートフォンでは、通常arm64を選択します。アーキテクチャを確認できない場合や、該当パッケージのインストールで互換性の問題が起きた場合は、ユニバーサル版の説明を確認してください。ユニバーサル版は対応範囲が広いものの、OSの最低要件を回避できるわけではありません。

コアを選ぶ際は、サーバー設定が必要とする機能を優先します。別のコアに切り替えても、すべてのプロトコルパラメーターがそのまま使えるとは限りません。セキュリティ設定やトランスポート項目、新機能の一部は、特定のコアやビルドでのみ利用できます。インポート時に未対応の項目が表示される、ノードが読み飛ばされる、設定チェックに失敗する場合は、サブスクリプションの提供元に対応範囲を確認してください。手当たり次第にオプションを変えるのは避けましょう。クライアントを更新しても、サーバー側にない機能は使えるようになりません。

複数の端末で使う場合は、ノードの提供元と命名方法をできるだけ統一します。ただし、アプリのデータフォルダー全体をそのままコピーするのは避けてください。デスクトップのシステムプロキシとAndroidのVPNインターフェースでは、通信を取り込む方法が異なり、使えるルーティングやDNSの設定も異なる場合があります。安全に移行するには、サブスクリプションを改めて追加し、使用するノードを選び直してから、端末ごとにプロキシの入口を設定します。プラットフォーム、アーキテクチャ、コアの要件など、選択理由を記録しておけば、次回の更新時に迷わずに済みます。

ステップ3：インストールと起動前の確認

インストール前に通常のネットワークが使えること、システムの日付・時刻・タイムゾーンが正しいこと、設定やログに必要な空き容量があることを確認します。証明書の検証にはシステム時刻が使われます。時刻が大きくずれていると、ノードの設定が正しくてもTLSハンドシェイクに失敗することがあります。ダウンロードと起動はローカル環境の準備段階です。この時点ではTUNを有効にしたり、DNSを変更したりする必要はありません。インストール、コアの起動、ネットワークの取り込みを分けて進めると、初回設定で問題が起きた際の原因を絞りやすくなります。

Windows：プログラムの配置場所と実行時の依存関係を確認する

ダウンロードページの説明に従ってインストーラーを実行するか、アーカイブをすべて書き込み可能な固定フォルダーに展開します。アーカイブのプレビューからメインプログラムを起動したり、実行ファイルだけを取り出したりしないでください。関連ファイルが不足すると、GUIやコアが起動しないことがあります。初回起動時に実行コンポーネントが必要と表示された場合は、そのビルドの案内に従って対応するアーキテクチャの依存関係を追加します。依存関係の不足をノードの不具合と混同しないでください。発生する段階が異なります。

起動後はメイン画面と通知領域を確認し、同じクライアントが複数起動していないか確認します。ログにローカルポートが使用中と表示されたら、ほかのプロキシクライアントを終了してから再起動してください。複数のインスタンスを同時に動かす必要がある場合は、それぞれに別の待ち受けポートを設定し、どのインスタンスがシステムプロキシを管理するのか明確にします。初めて使う場合は、複数のクライアントを重ねて動かすことはおすすめしません。ファイアウォールの警告は、プログラムの場所と用途を確認して判断してください。トラブル対処のためにシステム全体の保護機能を一度に無効にしないでください。

macOS・Linux：インストール権限と通信を取り込む権限を区別する

macOSではインストール後、アプリを安定した場所に移動してから起動します。システムに制限された場合は、まずダウンロード元、パッケージの種類、システムが表示した具体的な内容を確認し、OSが認める方法で対処してください。現在のシステムに関係のない回避コマンドを流用しないでください。通常のプロキシとTUNでは必要な権限が異なります。画面が開けても、仮想ネットワークインターフェースを作成できるとは限りません。まず通常のプロキシで接続を確認し、より多くのアプリの通信を取り込む必要がある場合に限り、クライアントの案内に従って適切な権限を許可します。

Linuxではディストリビューションに合った方法でパッケージをインストールし、パッケージ管理ツールに表示される依存関係のエラーを確認します。デスクトップクライアントは通常のユーザーセッションで実行してください。TUNに権限が必要だからといって、デスクトップアプリ全体を常に高い権限で実行しないでください。起動に失敗した場合は、プログラムのログ、フォルダーの書き込み権限、デスクトップ環境を確認します。システムプロキシの設定はデスクトップ環境に依存することが多く、コマンドラインプログラムには別のプロキシ設定があります。一方の結果だけで、もう一方を判断しないでください。

Android：権限を許可してからバックグラウンド動作を確認する

Androidではシステムの手順に従ってインストールし、クライアントを開いて設定を追加します。初めて接続するときは、システムからVPN接続の許可を求められます。これはクライアントが通信を取り込むためのシステムインターフェースであり、リモートノードへの接続成功を示すものではありません。同じ種類のインターフェースを使うアプリが端末上で動作している場合は、先に停止してからクライアントを起動してください。起動直後に切断される場合は、システムの許可状態とアプリのログを確認します。サブスクリプションを削除したり、すべてのノード設定を変更したりする必要はありません。

まずアプリを前面に表示した状態で接続し、その後、画面をロックしたときや別のアプリに切り替えたときに切断されないか確認します。一部のシステムではバックグラウンド動作が制限されます。必要に応じて端末の設定から、クライアントのバッテリー使用やバックグラウンド権限を調整してください。すべてのアプリの制限を解除する必要はありません。インストール後の確認項目は、画面が正常に表示されること、設定を保存できること、コアが起動すること、ローカル起動エラーがログに繰り返し出ていないことです。確認できたらサブスクリプションを追加してサーバーを選びます。権限を許可する具体的な手順は、クイックスタートガイドも参考にしてください。

ステップ4：サブスクリプションを追加して使用するサーバーを管理する

サブスクリプションURLは設定を取得するための入口で、通常はアカウントに紐づくアクセス情報を含みます。クライアントのサブスクリプション設定だけで使用し、公開の掲示板、スクリーンショット、オンライン変換ツールには貼り付けないでください。まず、受け取ったものがサブスクリプションURLか、単一ノードの共有リンクかを確認します。前者はサブスクリプショングループに使い、後者は通常クリップボードからインポートします。WebサイトのアカウントURLをサブスクリプション欄に入力したり、設定テキストをサブスクリプションURLとして扱ったりすると、解析に失敗します。

4つの手順でサブスクリプショングループを追加する

1. v2rayNのサブスクリプショングループ設定を開き、グループを追加します。識別しやすい名前と、サブスクリプションURL全体を入力してください。
2. グループを保存し、サブスクリプションを更新します。初回は、現在利用できるネットワーク経路で取得してください。
3. サーバー一覧に戻り、ノードが該当グループに登録されていることと、更新ログに解析エラーがないことを確認します。
4. ノードを選んで使用するサーバーに設定してから、システムプロキシを設定するか、モバイル端末で接続を開始します。

URLの例はhttps://example.com/sub?token=xxxxです。ドメインとパラメーターは形式の説明用であり、実際のノード情報ではありません。実際のURLを貼り付けるときは、前後の空白や改行がなく、文字列がすべて含まれていることを確認してください。特に疑問符以降のパラメーターを省略しないようにします。グループ名はローカルでの識別に使われ、接続パラメーターには影響しません。「有効化」は通常、そのグループを該当する操作の対象にするかどうかを決めます。具体的な動作は、現在の画面の説明に従ってください。

更新間隔とリクエスト方法を理解する

自動更新の間隔は最新の設定を定期的に取得するためのものです。接続速度を上げるために短く設定する必要はありません。頻繁に更新すると、サブスクリプションサービスのリクエスト制限にかかったり、トラブル対処時のノイズが増えたりすることがあります。User-Agentによってサーバーが返す設定形式が変わる場合があるため、通常はクライアントの初期値を使います。提供元から明確な指定がある場合に限り変更してください。更新結果がWebページやログイン画面だったり、形式に対応していなかったりする場合は、URLとレスポンスの種類を確認します。正常に使えているグループを何度も上書きしないでください。

サブスクリプション更新を直結にするかプロキシ経由にするかは、そのとき使えるネットワークに応じて決めます。使えるノードがない状態で、利用できないプロキシ経由の取得を強制すると、復旧できないループに陥ることがあります。プロキシが正常に動作しているのにサブスクリプションURLへ直結できない場合に、取得経路の切り替えを検討してください。失敗が接続、認証、解析のどの段階で起きたかを記録します。更新に失敗しても、既存ノードが削除されたり、すぐに無効になったりするとは限りません。

設定の更新、速度測定、実際の接続を区別する

サブスクリプションの更新は接続パラメーターの取得、使用サーバーの設定は現在のアウトバウンドの選択を行います。どちらも個別に完了させる必要があります。ノードの速度測定で分かるのは、ある条件で実施したテスト結果に限られます。TCP遅延はTCP接続の確立状況を主に示し、プロトコル認証、TLS、トランスポート、接続先へのアクセスまで確認できるわけではありません。実接続テストは実際のリクエストに近いものの、テスト先やタイムアウト、時間帯の影響を受けます。一覧で最も小さい数値だけを見て、長期使用するノードを決めないでください。

Androidでも、グループまたはサブスクリプションの管理画面でURLを追加して更新した後、一覧に戻ってノードを選び、接続を開始します。クライアントによってメニュー名は多少異なりますが、設定の取得、選択、起動、確認という流れは同じです。初回接続についてはv2rayNGでのノード選択とプロキシ動作確認もご覧ください。共有リンクや設定ファイルを扱う場合は、サブスクリプション形式と設定の変換ガイドを参考にし、異なる入力形式を混同しないようにしてください。

ステップ5：プロキシの入口を設定して通信を確認する

デスクトップでは、まず通常のシステムプロキシで基本的な接続を確認します。使用サーバーを選んだら、クライアントのシステムプロキシメニューから「システムプロキシを自動設定」を必要に応じて選択します。これによりローカルのプロキシ入口がシステム設定に登録され、その設定を使うアプリがリクエストをクライアントに渡します。クライアントが起動していることが前提です。プログラムを終了してもシステムプロキシがローカルポートを指したままの場合、ブラウザーに接続エラーが出ることがありますが、通常のネットワーク自体が使えなくなったわけではありません。

システムプロキシの3つの操作を区別する

「システムプロキシを自動設定」はプロキシの入口を設定します。「システムプロキシを解除」は該当するシステム設定を削除します。「システムプロキシを変更しない」は、クライアントが現在のシステム設定を変更しないことを意味します。最後の項目を選んでも、強制的に直結になるわけでも、システムに別のプログラムが設定したプロキシが残っていないという意味でもありません。クライアントを切り替えるときや、終了後に通信できない場合は、OSのネットワーク設定で実際の状態を確認してください。通知領域のメニューだけを見て、OSで有効になっているアドレスやポートを見落とさないようにします。

システムプロキシを使わないアプリには個別に設定する

アプリによってはHTTPまたはSOCKSプロキシを個別に設定できます。クライアントに表示された待ち受け方式とポートを確認して入力してください。ローカルアドレスは通常127.0.0.1ですが、ポートは現在の設定に合わせます。別の端末の数値をそのまま使わないでください。ユーザー名とパスワードが必要な入口では、認証情報も対応するように設定します。アプリにプロキシURLの入力を求められた場合は、プロトコルの接頭辞も確認してください。ポート番号だけを入力しても、異なるプロキシ方式が自動的に相互変換されることはありません。

ローカルの待ち受けアドレスとリモートノードのアドレスを混同しないでください。アプリのプロキシ設定はローカルの入口を指し、リモートサーバーのパラメーターはクライアントのコアが使用します。自分の端末だけで使う場合は、ループバックアドレスでの待ち受けを維持します。LAN接続を許可するとアクセス可能な範囲が広がるため、認証とファイアウォールも考慮してください。LAN内の別端末から接続する場合は、クライアントを実行している端末のLANアドレスを指定します。各端末自身のループバックアドレスではありません。一般的な個人利用では、テストのために待ち受け範囲を広げる必要はありません。

3種類の情報で接続を確認する

まず通常アクセスできる宛先を開き、基本ネットワークが切断されていないことを確認します。次にプロキシが必要なテスト先へアクセスし、ページが実際に表示されることを確認します。最後に出口情報とクライアントのログから通信経路を判断します。出口アドレスで分かるのは、そのリクエストを送ったアプリとその時点のルーティングだけです。ほかのアプリの結論には使えません。ルーティングを有効にしている場合、直結対象でローカルネットワークの出口が表示されるのは想定どおりであり、プロキシの障害とは限りません。テスト前に、宛先ごとの想定経路を決めておきましょう。

ブラウザーは使えるのに特定のアプリだけ失敗する場合は、すぐにノードを変更せず、アプリのプロキシ対応、個別設定、接続の再利用を確認します。プロキシを切り替えても既存の長時間接続が元の経路を使い続けることがあります。該当する接続を閉じるか、テスト対象のアプリを再起動して試してください。すべてのアプリで失敗する場合は、使用サーバー、コアのログ、ローカルの待ち受けを確認します。初回の確認手順は接続とプロキシの動作確認をご覧ください。クライアントを終了した後にシステムプロキシが元に戻っているかも確認し、一連の動作を完了させます。

ステップ6：ルーティングとDNSのルールを設定する

通常のプロキシ接続を確認してから、ルーティングを調整します。ルーティングルールはコアに届いたリクエストをプロキシ、直結、ブロックのどれにするか決めます。通常はルールの順番に従って判定されますが、具体的な動作は使用中のコアとルールの種類によって異なります。最初はクライアントの標準的な分割ルーティングを使い、明確な要件に応じて少数のルールを追加すると、大規模なルールセットを最初から読み込むより管理しやすくなります。変更前に、現在のルーティング方式、デフォルトのアウトバウンド、ルールの順序を記録し、問題が起きたときに戻せるようにします。

個別ルールからデフォルトのアウトバウンドまで設定する

まずLANアドレスや内部ドメインなど、明確なローカル・内部リソースを処理します。次に特定のサービスのドメインを設定し、最後にデフォルトのアウトバウンドへ渡します。細かく制御するルールは、より広い範囲を対象とするルールより前に置くのが一般的です。ドメインルールとIPルールが参照する情報は異なります。リクエストに宛先ドメインが残っていればドメインで判定できますが、宛先IPしかない場合は、名前解決の結果や別の識別方法が必要になることがあります。すべてのリクエストにドメイン名とアドレスの両方がそろっているとは限りません。

以下はXrayのルーティング項目の構造例で、LANのプライベートアドレスを直結する方法だけを示しています。完全なクライアント設定ではなく、directというタグのアウトバウンドがすでに存在することが前提です。GUIで設定する場合は、クライアントに用意された該当ルールの入力欄を使ってください。この断片をサブスクリプションURLに貼り付けたり、実行中の設定全体を置き換えたりしないでください。クライアントが設定を再生成する場合があります。変更を保持するには、クライアントが対応する場所に保存してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

DNSの経路と接続先のアウトバウンドを組み合わせる

DNSはドメイン名をアドレスに変換しますが、誰が名前解決を行うか、DNSリクエストがどの経路を使うか、結果がルーティングにどう使われるかは、それぞれ別の問題です。アプリが自ら名前解決してIPアドレスをプロキシに渡す場合と、アプリがドメイン名をプロキシに渡してから名前解決する場合では、動作が異なります。OSのDNSだけを変更しても、コア内部の名前解決が変わるとは限りません。コアのDNSだけを変えても、アプリ内蔵の名前解決まで制御できるとは限りません。実際にどの層が使われているかを確認してから、変更箇所を決めてください。

内部ドメインは通常、その名前を認識できるローカルまたは組織内のDNSで解決する必要があります。プロキシ対象には、利用可能でアクセス経路に合った名前解決方法が必要です。暗号化DNSでは、DNSサービス自体への接続経路と、そのサービスのドメインを最初に解決する方法も考慮してください。依存関係のループを避ける必要があります。DNSアドレスを1つ変更すればすべてのアクセス問題が解決する、と考えないでください。変更後は該当アプリのキャッシュを消すか、接続を確立し直します。古い結果が残ると、テストで変化が分からないことがあります。

モード名だけでなく、ルールごとに動作を確認する

ルールを1つ追加するたびに、適用されるべき宛先と、適用されないべき宛先をそれぞれテストし、ログに表示される宛先とアウトバウンドを確認します。サイト本体は表示されても画像やログインが失敗する場合は、関連ドメインが別の経路に振り分けられていないか確認してください。IP地域データベースやドメイン分類データを必要とするルールは、該当リソースが利用できることも前提です。リソースの欠落、名前の不一致、更新タイミングの違いにより、想定と実際の結果が異なることがあります。

日常利用では、動作を説明でき、元に戻せる状態を目指します。カスタムルールごとに用途とテスト先を記録し、問題が起きたら追加したルールを一時的に無効にします。特定のアプリだけに異なる経路が必要な場合は、範囲を明確に限定できる方法を優先し、ネットワーク全体を複雑なポリシーに変更しないでください。

ステップ7：必要に応じてTUNと仮想ネットワークによる通信の取り込みを有効にする

TUNは仮想ネットワークインターフェースを通じて通信を取り込みます。プロキシを直接設定できず、システムプロキシにも従わないアプリで役立ちます。変わるのは通信をクライアントに取り込む方法であり、リモートノードの品質が自動的に向上したり、回線の混雑が解消されたりするわけではありません。有効にする前に、同じノードで通常のプロキシ接続ができることを確認してください。確認しないまま有効にして通信が止まると、ノードの状態を確かめにくくなり、仮想インターフェース、システムルート、DNSのどこに問題があるかも判断しづらくなります。

権限、競合、初期設定を先に確認する

デスクトップで仮想インターフェースを作成したり、システムルートを変更したりするには、追加の権限が必要になることがあります。クライアントの案内に従い、スイッチがオンになっただけで通信を取り込めたと判断しないでください。権限不足、インターフェースの作成失敗、ルートの書き込み失敗がログにないか確認します。端末上で組織のネットワークツール、別の仮想ネットワークインターフェース、別の通信取り込みソフトを同時に使っている場合は、それぞれの要件を確認してください。判断できない場合は、業務用の接続に影響するのを避けるため、TUNのテストを中止します。

初めて有効にするときは、クライアントの推奨するスタック、インターフェース、ルーティング設定を使い、MTU、DNSハイジャック、スニッフィングを同時に変更しないでください。ビルドによってTUNの実装や設定場所が異なる場合があるため、別のコアの設定項目を流用しないでください。システムプロキシとTUNを同時に有効にするかどうかも、現在のクライアントの動作に基づいて判断します。テストではどの入口が通信を取り込むのかを明確にし、1つの入口が動かない問題を複数の入口を有効にして覆い隠さないでください。

通信が取り込まれる範囲を段階的に確認する

1. 動作確認済みのノードを維持したままTUNを有効にし、コアが継続して動作し、同じエラーが繰り返されないことを確認します。
2. ブラウザーと、システムプロキシを使わないアプリを1つテストし、それぞれの実際のリクエストを確認します。
3. ローカルルーター、プリンター、内部サービスに接続し、LAN内のリソースへ想定どおりに到達できることを確認します。
4. スリープからの復帰、ネットワークの切り替え、TUNの無効化後に、ネットワークが正常に戻るか確認します。

外部の接続先にはアクセスできるのにLAN内のリソースが使えない場合は、プライベートアドレスの除外、内部ドメインの名前解決、ルーティングの優先順位を確認してください。すぐにノードを変更する必要はありません。ドメイン名でアクセスできない一方、既知の接続先への接続結果が異なる場合は、DNSの経路を調べます。ただし、特定のIPアドレスに接続できるだけで、すべての名前解決が正常とは限りません。特定のアプリだけ失敗する場合は、使用するトランスポート方式や接続方法、アプリ独自のネットワーク制限も確認します。TUNを使っても、リモート側にすべての通信を転送する能力が備わるわけではありません。

UDP、IPv6、MTUの設定は慎重に行う

UDPを使うアプリでは、入口、コア、選択したノード、リモートサービスが、対象の通信に対応している必要があります。IPv6についても、システムのアドレス、デフォルトルート、DNSの結果、クライアントが取り込む範囲を確認します。IPv4のテストに成功しても、別のアドレス経路が正常とは限りません。実際の接続先とログをそれぞれ確認し、取り込まれない経路が想定どおりか判断してください。問題が起きたからといって、システムのネットワーク機能を一律に無効化しないでください。

MTUはインターフェースで扱えるパケットサイズを表します。回線によっては、大きなパケットや追加のカプセル化で読み込みが停止することがありますが、似た現象はパケットロス、DNS、サーバーの問題でも起きます。比較できる根拠がある場合に限って値を変更し、元の値も記録してください。一度に変更するのは1項目だけにし、同じ接続先で再テストします。改善しなければ元に戻してください。根拠のない「万能値」を使うと、後から正しく保守できなくなります。

AndroidはシステムのVPNインターフェースで通信を取り込みます。デスクトップ版のTUNスイッチと設定項目が一つずつ対応するとは限りません。システムの許可、ルーティング範囲、DNS、バックグラウンドで動作し続けるかどうかを確認してください。明確な要件がなければ、動作確認済みのシンプルな設定を維持します。

ステップ8：更新、バックアップ、日常の保守手順を整える

接続できるようになったら、設定を次々に変えるのではなく、使える状態を維持することに重点を移します。クライアントの系統、使用中のノード、ルーティング方式、DNS方式、TUNの有効・無効を記録します。完全な認証情報や測定結果をすべて保存する必要はありません。次に問題が起きたとき、最近何を変更したか、最後に正常だったとき何を使っていたかを確認できるようにするのが目的です。日常の更新もこの基準に沿って行い、すべてのコンポーネントを同時に置き換えないでください。

4種類の更新を分けて管理する

クライアントの更新はGUIや設定管理に、コアの更新はプロトコルや接続動作に、サブスクリプションの更新はリモートノードのパラメーターに、ルールリソースの更新はルーティング結果に影響します。これらは別々の操作です。ビルドによっては一括更新の入口が用意されていますが、その場合も案内を読み、実際に更新される範囲を確認してください。互換性の問題がない場合は、クライアントの更新、コアの切り替え、すべてのルールの更新を同時に行い、アクセス結果だけで変更全体の成否を判断する必要はありません。

更新前に余分なインスタンスを終了し、設定を保存します。更新後は元のノードとルーティング設定で一度テストしてから、新しい機能を有効にしてください。設定の移行を求められた場合は、旧データを復元できるか確認します。新旧のプログラムを同じ設定フォルダーへ同時に書き込ませないでください。以前の環境に戻す場合は、その環境と互換性のあるバックアップを使います。ビルドによってデータ構造が変わることがあり、新しい設定を旧プログラムにコピーしても、以前の動作を復元できるとは限りません。

設定単位でバックアップし、機密情報を公開しない

クライアントが対応するエクスポートまたはバックアップ機能を使い、グループ、ルーティング、必要な設定を保存します。バックアップファイルにはサブスクリプションURL、ユーザー識別子、サービスのパラメーターが含まれる場合があるため、管理された場所に保管し、公開の添付ファイル置き場へアップロードしないでください。別の端末へ移行するときは、まずサブスクリプションとルールを復元し、対象端末に合わせて待ち受けポート、システムプロキシ、TUNの権限を再設定します。端末固有のネットワークインターフェース名やLANアドレスを、どの端末でも使える設定として扱わないでください。

問い合わせ用の情報とバックアップ全体は分けてください。問い合わせには、症状、プラットフォーム、使用モード、再現手順、機密情報を伏せたログがあれば十分です。アドレスに含まれるアクセスパラメーター、ノードの認証情報、アカウント情報を隠し、スクリーンショットのメモ、QRコード、クリップボード領域も確認してください。ログを削除するために、設定をすべて消す必要はありません。何度も試した大量の情報より、失敗の前後にある重要な箇所を残すほうが役立ちます。

日常の不具合を再現可能なチェック項目に分ける

サブスクリプションが突然更新できなくなったら、まずURLの有効性と取得経路を確認します。特定のノードだけ失敗する場合は、同じグループの動作確認済みノードと比較します。すべてのノードが遅い場合は、ローカルネットワークと端末の負荷を確認します。特定の接続先だけ問題がある場合は、接続先自体とルーティング結果を確認してください。速度の問題はノード、回線、ローカル設定に分けて調べます。詳しくはv2rayNが遅いときの段階的なトラブル対処をご覧ください。原因の切り分けを再インストールで代用しないでください。

長期間使った後は、無効になったグループ、重複した手動ノード、不要になったルールを整理できます。ただし、使用中の設定がそれらに依存していないことを先に確認してください。自動起動とシステムプロキシの自動設定も、あわせて確認する必要があります。クライアントが起動できないときにシステムプロキシが残るか、ネットワークがまだ利用できないときに自動更新が再試行されるかを確認します。スリープからの復帰、有線・無線の切り替え、モバイルホットスポットへの切り替えも、簡単な動作確認をしておくと安心です。

保守の目的は、ログからすべての警告をなくすことではなく、接続の動作を説明できるようにすることです。繰り返し発生するエラーは原因を特定し、正常な終了や一時的なネットワーク切り替えによる記録は、前後の状況を踏まえて判断します。検証していない最適化パラメーターを大量に集めるより、シンプルで再現可能な手順を維持するほうが役立ちます。

ステップ9：層ごとにトラブル対処し、次の学習に進む

応用的な設定は、追加のスイッチを探すことではなく、どの段階で失敗したかを理解することから始まります。ローカルネットワーク、クライアントの起動、設定の解析、ローカルの入口、リモート接続、接続先へのアクセス、ルーティングとDNSの順に確認しましょう。証拠を得た段階まで確認してから、次に進みます。ブラウザーのタイムアウトだけでは、証明書、名前解決、ルーティングのどこに問題があるか分かりません。同じ時刻のクライアントログも確認し、リクエストが取り込まれたか、どこへ接続したか、どの段階で止まったかを調べてください。

エラーが起きた段階から原因を絞る

起動直後に解析エラーが出る場合は、設定項目、形式、コアとの互換性を確認します。ローカルポートのバインドに失敗する場合は、重複起動とポートの使用状況を確認してください。リモート接続がタイムアウトする場合は、アドレス、ポート、ネットワーク経路、サービスの状態を調べます。ハンドシェイクまたは認証に失敗する場合は、プロトコル、ユーザー識別子、トランスポート、セキュリティ設定を確認してください。接続先からアプリケーション層の明確なエラーが返された場合は、接続先サービス側の制限も考慮します。成功以外の応答をすべてプロキシクライアントのせいにしないでください。

TLSの問題は、まず端末の時刻を確認し、次にサーバー名、証明書の対象範囲、証明書チェーンを調べます。サーバーアドレスとTLSで使う名前は別の役割を持つことがありますが、設定はサーバー側の要件に合っていなければなりません。エラー表示を消すために証明書検証を無効にしたまま使わないでください。検証条件を変えるだけで、名前や証明書の設定を修正したことにはなりません。詳しい手順はTLSハンドシェイクと証明書エラーの対処方法をご覧ください。変更前後を同じ接続先で比較します。

テスト条件と判断基準を固定する

性能をテストするときは、端末、ネットワーク、ノード、接続先を固定し、接続確立までの時間と継続的な転送速度を分けて確認します。小さなファイルの読み込みが遅い場合は、DNSやハンドシェイクが影響していることがあります。継続的なダウンロードが遅い場合は、回線帯域、混雑、リモートの負荷も考慮します。Muxの多重化が常に速いとは限りません。接続の構成を変える機能であり、効果はプロトコルとネットワーク環境に左右されます。有効にする前に元の値を記録し、安定した改善が見られなければ元に戻します。一度だけの偶然の結果を根拠に、複雑な設定を維持しないでください。

GUIの設定から設定ファイルの読み解きへ

次の段階では、インバウンド、アウトバウンド、ルーティング、DNSの設定構造を学びます。まずGUIの各項目が実際に何を意味するかを理解し、その後でコアが対応する設定項目を読みましょう。クライアントが生成する実行時設定は、永続的な編集場所とは限りません。手動で変更しても、再起動時に上書きされることがあります。カスタム設定機能を使う場合は、日常利用の設定を上書きせず、独立したテスト用設定を用意します。例に含まれるアウトバウンドのタグ、リソース名、依存関係も、すべて個別に確認してください。

ルーターやサブネットルーターに導入する場合は、システムの転送、ポリシールーティング、透過プロキシ、DNSループバックを学ぶ必要があります。ネットワーク機器側の新たなテーマであり、デスクトップクライアントのTUN設定をそのまま移せばよいわけではありません。まずXrayのルーター・サブネットルーター導入ガイドでメインルーターとサブネットルーターの役割を確認し、ローカルから復旧できる手段を用意してから試してください。デフォルトゲートウェイを変更した後に管理画面へ接続できなくなる事態を避けましょう。

最終的には、最小限の設定で接続し、通信ごとの経路を根拠に沿って説明し、問題が起きたときに動作確認済みの状態へ戻せることを目指します。新たな問題が起きたら、最初から再インストールするのではなく、このページの該当する段階を確認してください。初回設定を行う場合は、クイックガイドのサブスクリプション追加手順を確認できます。端末やクライアントを変更する場合は、ダウンロードページでプラットフォームとアーキテクチャを改めて確認してください。各段階の役割を理解することが、応用設定を支える基盤になります。