V2Rayの詳細設定ガイド

01 · サブスクリプションとサーバー

サブスクリプションのグループ分けとサーバーの絞り込み

サブスクリプションURLはサーバー設定を取得するための入口、グループ分けはクライアント上で項目を整理する方法です。この2つは同じものではありません。通常、1つのグループには1つの配信元を登録しますが、手動で追加したサーバーを保存することもできます。詳細設定に進む前に、「配信元」「表示名」「用途」を分けて整理しましょう。配信元は更新に、表示名は識別に、用途は絞り込みに使います。グループ名を「仕事用」にしても、仕事用アプリが自動でそのグループのサーバーを使うわけではありません。実際の通信経路は、選択中のサーバー、ルーティング、プロキシの適用方法によって決まります。

変更元を追跡できるグループを作る

v2rayNのサブスクリプショングループ設定でグループを追加し、短く変更しにくいメモを入力してから、サブスクリプションURLを省略せずに貼り付けます。URLにクエリパラメーターが含まれる場合は、全体をそのまま保持してください。コピー時に改行や空白、ページ上の句読点が混入すると、リクエスト結果が変わることがあります。保存後はそのグループだけを更新し、更新通知と項目数の変化を確認してから、サーバーのプロトコル、アドレス、ポートが正しく登録されているかを確認します。複数の配信元を一度に追加してまとめて更新すると、一覧が空になった際にURLの誤り、リクエスト失敗、配信元の空データのどれが原因か判断しにくくなります。

サブスクリプションURLにはアカウントのアクセス情報が含まれることがあります。スクリーンショットやログを共有したり、設定をエクスポートしたりする前に、URL全体を必ず隠してください。通常の管理に、サブスクリプションを見知らぬ変換ツールへ送る必要はありません。配信元がクライアント専用の形式を提供している場合は、使用中のクライアントに対応した入口を優先してください。ブラウザーに内容が表示されても、クライアントが解析できるとは限りません。Webサイトのログイン画面や期限切れの通知、エラーページでも、通信自体は成功扱いになることがあります。有効なサーバー一覧かどうかは、ページが開くかどうかだけでなく、クライアントの更新ログも確認して判断してください。

表示時の絞り込みと更新時の絞り込み

一覧の検索は、一致しない項目を一時的に隠すだけの場合が多く、検索を解除すればすべてのサーバーが再表示されます。一方、サブスクリプショングループの絞り込み設定によっては、インポート結果そのものに影響し、更新後に対象外のサーバーがローカル一覧へ追加されないことがあります。操作前に項目の説明を読み、表示だけを絞り込むのか、更新内容を絞り込むのか確認しましょう。まずはメモに含まれる地域名など、一般的なキーワードで検索して動作を確かめます。正規表現は、入力欄が対応していると明記されている場合にだけ使ってください。すべての入力欄が同じ検索方式とは限りません。

正規表現に対応したメモ欄での絞り込み例として、办公|备用はどちらかの語句を含む項目、^办公はメモの先頭が「办公」の項目に一致します。大文字と小文字の扱い、空のメモの処理、除外構文は、その項目の仕様に従ってください。他のツールの書き方をそのまま流用するのは避けましょう。複雑な絞り込みを保存する前に、現在の一覧で条件に合う項目が少なくとも1つあることを確認し、そのグループだけを更新します。結果が突然空になった場合は、まず絞り込みを解除して再更新してください。グループをすぐに削除すると、ローカルのメモや手動で追加した項目まで失うおそれがあります。

更新や切り替えに備えて戻せる状態を残す

サブスクリプションの更新によって、サーバー設定が上書きされたり、識別情報が置き換わったり、配信元で削除された項目が消えたりすることがあります。長く使う手動設定は、ローカルの別グループにコピーし、変更理由も記録しておきましょう。サブスクリプション内の項目に、カスタム設定を長期的に持たせるのは避けてください。更新後は選択中のサーバーが引き続き一覧にあることを確認し、実際にWebサイトへアクセスして動作を確かめます。遅延テストで分かるのは特定の方法による測定結果であり、あらゆる通信が正常に使えることを保証するものではありません。サーバー選びについては遅延、倍率、地域、プロトコルの選び方も参照してください。

02 · マッチングと通信経路

V2Rayルーティングルールの設定と確認

ルーティングが決めるのは「コアに届いた接続を、どのアウトバウンドへ渡すか」です。すべてのアプリの通信を自動でクライアントに取り込む機能ではなく、システムプロキシの設定とも異なります。アプリがローカルプロキシを経由しなければ、コアのルールは適用されません。通信の振り分けを調べる際は、まずリクエストがクライアントに届いていることを確認し、次に対象のドメインまたはアドレス、適用されたルール、最終的なアウトバウンドを確認します。通信の取り込み、ルールのマッチング、転送の3段階に分けると、ルーティング設定一式を入れ替えるより原因を見つけやすくなります。

ルールの順序とマッチ条件を理解する

多くのコアはルールを上から順に照合するため、上位の大まかなルールが下位の詳細なルールより先に適用されることがあります。まず対象が明確なローカルサービスやドメインを置き、次に広いアドレス範囲、最後にデフォルトの振り分けを設定しましょう。1つのルールに異なる種類の条件を複数設定した場合、通常はすべての条件に一致する必要があります。同じドメイン一覧に含まれる複数の値は、いずれかの候補への一致を表します。無関係なドメイン条件とアドレス条件を1つのルールに入れ、それぞれ個別に一致することを期待しないでください。設定を確認するときは、ルール単位で条件全体を見て判断します。

ドメインの指定方法にも違いがあります。full:example.comは指定したドメインそのものにのみ一致し、domain:example.comはそのドメインとサブドメインに一致します。通常の文字列は、より広いキーワード検索として処理されることがあります。特定のサービスだけを対象にするなら、完全一致のドメインか、明示的なドメインサフィックスを優先してください。IPアドレスを直接指定する場合、接続先が複数のアドレスを使ったり、ネットワークによって異なるアドレスを返したりすることがあります。1つのIPルールだけでは、Webサイト全体を確実に表せません。地理データベースに依存するルールでは、必要なデータファイルが存在し、現在のコアから読み込めることも確認してください。

最小限のルールで動作を確認する

以下はXray形式のルーティング設定例であり、設定ファイル全体ではありません。テスト用ドメインとプライベートネットワークのアドレスを直接接続のアウトバウンドに渡し、それ以外は既存のデフォルト動作を維持します。この例では、directというタグのアウトバウンドがすでにあることを前提としています。実際のタグ名が異なる場合は、例の内容も合わせて変更してください。カスタム設定に組み込むときは、既存のインバウンドとプロキシ用アウトバウンドを残し、例の断片でファイル全体を置き換えないでください。GUIのルーティング編集画面がこれらの項目を自動生成する場合は、画面上で変更してください。そうすれば次回起動時に上書きされるのを防げます。

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

ドメイン解決の方式とルーティングのプリセットは別の設定

AsIsは、ルーティングの段階で既存の宛先情報を使って判定し、IPルールのために積極的にドメインを解決しない方式です。IPIfNonMatchはドメインに一致しない場合に名前解決を試み、その後でアドレスを照合します。IPOnDemandはアドレス条件に遭遇した時点で、先に名前解決することがあります。解決方式によって問い合わせ回数やマッチ結果は変わりますが、DNSリクエストが正しいサーバーへ自動的に送られるわけではありません。アドレスの集合を使う前にDNSの設定と解決経路を確認し、ルーティング時に名前解決が必要か判断しましょう。ドメインで表現できるルールに、余計な依存関係を持ち込まないようにしてください。

確認する際は対象を1つ選び、新しいリクエストを1回だけ送って、アクセスログに記録された宛先とアウトバウンドのタグを確認します。ブラウザーの既存接続が古い経路を使い続けることがあるため、ルール変更後は関連する接続を閉じるか、アプリを再起動してテストしてください。ドメインルールに一致しない場合は、アプリからコアへIPアドレスしか渡されていないか、スニッフィングでドメイン情報を取得できるかを確認します。必要な情報が不足しているときは、ルールの順序を何度も変更しても解決しません。システムプロキシの基本的な違いはプロキシモードの説明を参照してください。接続後も通信できない場合は項目別のトラブル対処チェックリストで確認できます。

03 · DNS問い合わせと名前解決

DNS設定の調整

DNS設定は、単に「DNSサーバーのアドレスを変える」ことではありません。アクセス時には、アプリ内蔵のリゾルバー、OSのリゾルバー、クライアント内蔵DNS、リモートプロキシが接続先ドメインを解決する経路などが関係することがあります。ブラウザーで暗号化DNSが有効なら、OSの通常のDNSリクエストを使わない場合もあります。まず、どの機能が問い合わせるのか、どこへ送るのか、結果をどの機能が使うのかを整理しましょう。実際にリクエストを処理している機能の設定を変更して初めて、動作に反映されます。

接続先の名前解決と通信先の名前解決を区別する

プロキシサーバーのアドレスがドメイン名の場合、プロキシに接続する前に実際のアドレスを取得する必要があります。これは接続先の名前解決です。すべての問い合わせを、まだ確立していないプロキシへ送ろうとすると、「プロキシに接続するには、先にプロキシのアドレスを解決しなければならない」という循環が発生することがあります。サーバーのドメインには直接利用できる名前解決経路を残すか、配信元が明示しているサーバーアドレスを使用してください。ドメインを解決して得たアドレスを固定して使い続けるのは避けましょう。配信元がアドレスを変更したり、接続先を振り分けたりする可能性があります。Webサイトなど通信先の名前解決は、実際のアウトバウンドに合わせて別に設計します。

v2rayNのDNSを変更する前に、現在のルーティングプリセット、コアの種類、DNSの編集方法を記録しておきましょう。通常のプロキシ用とTUN用で異なるDNSテンプレートを使う画面もあれば、詳細設定からコアの設定を直接編集できる場合もあります。現在のモードで使われていないテンプレートを変更しても、実行結果は変わりません。保存後は該当するコアを再起動し、設定が正常に読み込まれたことをログで確認してください。設定項目が認識されない場合は、まず元の設定に戻して現在のコアが対応する構文を確認します。別のコアにある同名設定を参考に、推測で置き換えないでください。

よく使う設定項目の影響を知る

以下は、Xray内蔵DNSでよく使われる項目を最小限にした例です。構成を説明するためのものであり、特定のネットワークに最適なDNSサーバーを示すものではありません。まず現在のネットワークから到達できることを確認してください。UseIPv4はIPv4だけを問い合わせるテスト条件を明示するもので、あらゆる環境で恒久的に使う設定ではありません。IPv6が必要な場合は、OS、ネットワーク、プロキシ経路がすべて対応していることを確認してから、必要な問い合わせ方式に戻してください。この設定例だけで、システムのすべてのDNSリクエストを受け取れるわけではなく、TUNでのDNS通信の取り込みも自動的には行われません。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

症状に応じて段階的に確認する

すべてのドメインで名前解決に失敗し、数値のIPアドレスには接続できる場合は、まずリゾルバーへの疎通とDNS問い合わせの送信経路を確認します。特定のドメインだけ失敗する場合は、ドメインごとの設定ルール、キャッシュ、上位DNSからの応答を調べましょう。名前解決は成功するのに接続がタイムアウトする場合は、取得したアドレスへの実際の到達性を確認します。暗号化DNSの証明書検証には正確なシステム時刻が必要です。また、ドメイン名で指定したDNSサービスでは、接続前の名前解決が別途必要になることがあります。テストでは一度に1つの条件だけを変更し、問い合わせにかかった時間やエラーの種類を記録してください。リゾルバー、ルーティング方式、プロキシサーバーを同時に切り替えるのは避けましょう。

IPv6の問題はDNSの不具合と混同されやすいため、注意が必要です。IPv6アドレスを取得できても、ローカルネットワークやプロキシのアウトバウンドからそのアドレスへ接続できるとは限りません。一方で、IPv6を全面的に無効にすると、正常に利用できていたサービスに影響する場合があります。まず制御できるテスト環境で問い合わせるアドレスの種類を制限し、アドレスファミリーによって症状が変わるか確認してから、ネットワークを修正するか設定を調整するか判断しましょう。Wi-Fi、有線、モバイルネットワークを切り替えた後は、必要に応じて接続を作り直し、関連するキャッシュを消去します。ブラウザーとOSにはそれぞれキャッシュがあるため、クライアントを再起動しただけでは古い結果がすべて消えるとは限りません。

04 · 通信の取り込み

TUNモードの有効化と元に戻す方法

TUNは仮想ネットワークインターフェースを通じてIPパケットを受け取る方式です。システムプロキシの設定に従わないアプリの通信も取り込めますが、プロキシプロトコルの一種ではありません。TUNに入った通信も、ルーティング、DNS処理、アウトバウンド接続を経由します。最終的に利用できる機能は、実際に動作するバックエンドによって異なります。v2rayNでは専用のTUNバックエンドが通信を取り込む場合があるため、画面上のTUNスイッチをXrayコア設定の特定の項目と同一視しないでください。まずクライアントの説明と実行ログを確認し、どのバックエンドを使用しているか把握してから、スタック、ルーティング、DNSの設定を検討しましょう。

有効にする前に基本の接続を確認する

まず通常のシステムプロキシ方式で、サーバー経由で目的のサービスにアクセスできることを確認します。次に、OSが仮想インターフェースの作成やルート変更を許可しているかを確認してください。Windowsでは適切な権限でクライアントを起動するか、クライアントサービスを有効にする必要がある場合があります。macOSやLinuxでは、権限の付与や対応サービスが必要になることがあります。権限不足、インターフェースの作成失敗、サーバー接続失敗はそれぞれ異なる問題です。ログを見て分けて対処してください。デスクトップ版の入手先はダウンロードセンターです。原因が分からないエラーを解消するために、出所の不明な追加コンポーネントをインストールしないでください。

有効にする前に、デフォルトルートやDNS、仮想インターフェースを変更する他のソフトを一時終了し、通常のネットワークが動作している状態を記録します。別の端末へリモート接続して設定している場合は、特に注意してください。ルートが切り替わると、管理用の接続がすぐに切断されることがあります。あらかじめローカルで復旧できる手段を用意しましょう。初回のテストでは、厳格なルーティング、カスタム除外ネットワーク、FakeDNSを同時に有効にしないでください。まず初期設定のままインターフェースの作成、プロキシサーバーへの接続、一般的なWebサイトへのアクセスを確認し、その後で必要な機能を1つずつ追加します。

スタック、自動ルーティング、除外設定を理解する

ネットワークスタックは、受信したパケットを処理可能な接続へ変換します。実装によって、OSとの互換性、UDP、リソース使用量に違いがあります。あるOSで使えたスタックが、すべての端末で最適とは限りません。自動ルーティングは対象の通信を仮想インターフェースへ送り、除外設定はローカルサービスやLAN、特定の接続に元の経路を使わせるためのものです。プロキシサーバー自身の接続が正しく除外されているか、まず確認してください。除外されていないと、アウトバウンドの通信が再びTUNへ入り、二重に取り込まれることがあります。

MTUはインターフェースが扱えるパケットの最大サイズを示す値で、大きくすれば速くなるものではありません。小さなページは開けるのに、大きなファイルや特定のアプリ、接続が頻繁に停止する場合は、サーバーやDNSに加えて、経路上のMTUやフラグメントの問題も確認してください。変更する場合はバックエンドの対応範囲内で少しずつ調整し、毎回テスト接続を作り直して、元の値も記録しておきます。Webページを一度開けたというだけで、インターネット上にある数値へMTUを固定すると、本当の原因を見落としやすくなります。ネットワークを切り替えた後に再発することもあります。

OSごとの違いと確認手順

Androidのv2rayNGとv2flyNGは、通常、OSのVPNインターフェースを使ってアプリの通信を取り込みます。権限の確認画面や通信の管理方法は、デスクトップOSの仮想インターフェースとは異なります。アプリごとのプロキシ設定、LANの除外、バックグラウンド実行の制限は、通信が取り込まれる範囲に影響します。クライアントを切り替える際は、同じ種類のインターフェースを使用している他の接続を先に停止してください。OSのバッテリー最適化でバックグラウンドプロセスが終了すると、画面をロックしたときに接続が切れることもあります。デスクトップ版クライアントのサービス設定方法をAndroidにそのまま適用しないでください。

動作確認では、一般的なWebサイト、ローカルゲートウェイまたはLAN上のサービス、UDPが必要なアプリの順にテストし、その後ネットワークの切り替えと端末のスリープ解除を確認します。有効にした後で全く通信できなくなった場合は、まずTUNを無効にして通常のネットワークが戻るか確認し、インターフェース、ルート、DNSのログを調べてください。無効にしても直らない場合はクライアントを終了し、システムプロキシの設定が残っていないか確認してから、ネットワークへ再接続します。通信の取り込みが安定してから、厳格なルーティングや除外ネットワークを調整してください。高度な設定を追加するより、まずネットワークを復旧させることが優先です。

05 · ドメインとアドレスの対応

FakeDNSとDNS通信の取り込み

FakeDNSはドメインに合成アドレスを割り当て、後続の接続時にその対応関係から元のドメインを復元します。合成アドレスはクライアント内部で識別に使うもので、Webサイトの実サーバーアドレスではありません。アプリが自分で名前解決を行った後、IPアドレスだけで接続する場合でも、プロキシ側でドメインを復元し、ドメインベースのルーティングを適用したり、リモート側に名前解決を任せたりできる点が利点です。サーバーの品質を自動で改善するものではなく、DNSや通信の取り込みと切り離して単独で使える機能でもありません。

ドメインとアドレスの対応が最後まで維持されるか確認する

正常に動作するには、4段階の経路が必要です。アプリのDNS問い合わせが指定された機能に届く、合成アドレスが返される、アプリがそのアドレスへ接続する、クライアントが接続を受けてドメインを復元する、という流れです。どこかの段階でクライアントを経由しなくなると、処理に失敗することがあります。たとえば、ブラウザーが独自の暗号化DNSを使って問い合わせがマッピング機能に届かない場合、OSが合成アドレスを取得しても除外ルートによって物理ネットワークへ直接接続してしまう場合、マッピングを作成する機能と接続を受け取る機能が別の実装である場合などです。こうしたケースでは、スニッフィングを有効にするだけでは解決しないことがあります。

まず通常のTUNと実際のDNS名前解決が安定して動作することを確認してから、FakeDNSを使うか判断してください。v2rayNのTUNバックエンドが独自の合成アドレス機能を提供する場合がありますが、名称が似ているからといって、Xrayの設定にあるFakeDNSと置き換えられるわけではありません。項目名、アドレスプール、キャッシュ方法、ルーティングの要件は、実際に使うバックエンドの説明を確認してください。明確な互換設計がないまま両方を有効にし、同じアドレス範囲を共有するのは避けましょう。異なる機能が別々の対応表を保持していると、同じ合成アドレスが異なるドメインを示す可能性があります。

アドレスプールとマッピング容量

以下はXray形式の設定例です。アドレスプール、DNSサーバーの選択、インバウンドのスニッフィングの関係を示しています。クライアント設定全体と置き換えて使用できるファイルではありません。インバウンドのスニッフィング設定は、該当する通信を実際に受け取るインバウンドに追加してください。ルートオブジェクトに任意で追加するものではありません。198.18.0.0/15は合成アドレスプールとしてよく使われますが、有効にする前に、ローカルネットワークでこの範囲が使われていないか、特別なルーティングが設定されていないか確認してください。関連する接続がプロキシによる通信の取り込み経路から直接外れないことも必要です。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

poolSizeはマッピング容量を決める項目で、同時にサポートできるサーバー数ではありません。多くの異なるドメインへアクセスすると、容量や古い項目の破棄方法によって、アドレスから元のドメインを復元できるかが変わります。アプリが名前解決結果を長時間保持している一方で、コアの再起動後にマッピングが失われることがあります。その状態でアプリが古い合成アドレスへ接続すると、通信に失敗する可能性があります。クライアントの再起動後に一部のアプリだけ異常が出る場合は、プロキシのプロトコルをすぐに変更せず、まずアプリを終了し、関連するDNSキャッシュを消去してから接続し直してください。

例外にするドメインと主な症状

LAN上の名前、デバイス検出、実アドレスを必要とするアプリ、特殊なDNSレコードを必要とするサービスは、合成アドレスに対応できるか個別に確認してください。アプリによっては、名前解決結果が特定のネットワーク内にあるか検査したり、クライアントが通信を取り込まない別のプロセスに結果を渡したりするため、バックエンドの対応方法に応じた例外設定が必要です。例外に指定したドメインには実アドレスを返し、対応する直接接続またはプロキシのルールと整合させます。合成アドレスを返す一方で、そのアドレス範囲をクライアントを完全に迂回する対象に含めないでください。

トラブル対処では、まずOSやアプリが合成アドレスを取得しているかを確認し、次に接続が通信の取り込みインターフェースへ届いているか、その後ログで元のドメインに復元されているかを見ます。物理ネットワークへの接続に合成アドレスが現れる場合は、DNSサーバーを変更するのではなく、通信の取り込みとルーティングを優先して修正してください。FakeDNSを無効にするときは、キャッシュも処理します。実際の名前解決に戻してから影響を受けたアプリを再起動し、必要ならOSのキャッシュを更新したうえで、古いマッピングに依存する接続が残っていないことを確認しましょう。スイッチを切るだけで古いアドレスを残すと、設定を元に戻した後も問題が続くことがあります。

06 · 配信元とメンテナンス

複数サブスクリプションの管理と更新方法

複数サブスクリプションの管理では、配信元を分け、更新の影響を抑え、復旧できる状態を維持することが重要です。すべてのサーバーを1つの長い一覧にまとめることが目的ではありません。配信元ごとに別のグループを作り、「配信元の略称と用途」を組み合わせた変更しにくいメモを付けましょう。一時的なテスト用の配信元は別に保存します。配信元が増えたら、まとめて更新する前に管理方法を決めてください。同じ名前の項目、異なるプロトコル、サブスクリプションの変更が混在すると、サーバーの選択を誤りやすくなり、設定がどの配信元に由来するのかも分かりにくくなります。

グループ、サーバー項目、接続中のサーバーの関係を確認する

グループを選ぶ操作は、現在の一覧表示を切り替えるだけで、接続中のサーバーは変わらないことがあります。一方、グループ内のサーバーを選び直すとすぐに切り替わる画面もあります。画面上部のグループ名だけで判断せず、実際に接続中であることを示す表示を確認してください。サーバーのメモは一意で固定された識別子ではありません。異なる配信元に同じ名前の項目があることも、同じ配信元の項目名が更新時に変わることもあります。更新の影響を調べる際は、表示名だけでなくプロトコル、接続先アドレス、ポート、通信パラメーターを比較しましょう。

自動重複削除も慎重に行ってください。2つのサーバーでアドレスとポートが同じでも、同じ設定とは限りません。認証情報、TLSのサーバー名、パス、フロー制御パラメーターが異なれば、接続方法も変わることがあります。クライアントがどの項目を基準に重複と判断するのか分からない場合は、一覧を短くする目的で一括削除しないでください。整理が必要なら、まずグループごとに絞り込み、必要なローカル情報を保存してから削除します。操作後にグループを更新し、配信元から同じ項目が再登録されて繰り返し表示されないことを確認してください。

自動更新の頻度と範囲を適切に設定する

更新頻度は、配信元の実際の変更頻度とクライアントの使い方に合わせて決めましょう。頻繁に更新しても、リクエストやトラブル対処時のノイズが増えるだけで、すでに使えない配信元が復旧するわけではありません。追加した直後は手動更新を使い、内容が安定していることを確認してから、クライアントが対応するスケジュール設定を有効にします。端末のスリープ、ネットワークの準備が整う前の起動、バックグラウンドプロセスの停止などにより、予定した更新が実行されないことがあります。重要な利用の前には、更新タスクが設定済みかどうかだけでなく、直近の更新結果も確認してください。

「プロキシ経由で更新」と「直接更新」のどちらが必要かも確認しましょう。特定の経路でしかアクセスできない配信元では、更新リクエストに使う経路を明示します。ただし、唯一利用できるサブスクリプションの更新が、これから置き換える予定の接続中サーバーだけに依存しないようにしてください。更新方法を変更したら、まず1つのグループだけでテストし、失敗した場合はネットワークエラーの種類をログに残します。その際、サブスクリプションURL全体は必ず隠してください。複数のグループが同時に失敗した場合は、各配信元を作り直すのではなく、共通して利用するネットワークやプロキシの状態を先に確認しましょう。

バックアップ、移行、配信元の停止

クライアントを移行する前に、画面に用意されたエクスポートまたはバックアップ機能を使い、サブスクリプションURL、手動追加したサーバー、ルーティング、DNSの設定が含まれるか確認してください。バックアップの対象範囲は一律ではなく、共有リンク1つだけでは使用環境全体を復元できないことがあります。バックアップには識別情報が含まれる場合があるため、安全な場所に保存しましょう。別の端末へ復元した後は、ローカルポート、ファイルパス、サービスの権限、仮想インターフェースの設定が使えるかを確認してください。古い端末のネットワーク設定がそのまま流用できるとは限りません。

配信元が停止した場合は、まず動作確認済みのサーバーに切り替え、そのグループの自動更新を無効にしてから、ローカルの記録を削除するか残すか決めます。現在接続中の項目を直接削除すると、通信が切断されることがあります。また、アプリが古い接続を使い続けることで、「一覧は切り替わったのにリクエストは古い経路を通る」という状態に見える場合もあります。削除後は新しい接続を作ってテストし、ルーティングやカスタムアウトバウンドに該当項目への参照が残っていないか確認してください。長期間使わないサブスクリプションは自動更新の対象から外し、不要な失敗通知を減らしましょう。

管理対象が増えたら、短い変更記録を残すと便利です。どのグループを変更したか、どの種類の設定を更新したか、どの動作を確認したか、元に戻すにはどうするかを記録します。サブスクリプションURL全体や認証情報は含めないでください。変更記録の目的は、トラブルと直近の操作を結び付けることで、複雑な設定管理システムを新たに作ることではありません。配信元の更新とローカル設定のどちらが問題か判断できない場合は、元の安定したグループを変更せず、同じ配信元を別のグループへインポートして、項目と接続結果だけを比較しましょう。

07 · タグと転送

カスタムアウトバウンドと設定の統合

アウトバウンドはコアがどのように接続するかを定義し、ルーティングはタグを使ってリクエストを対応するアウトバウンドへ渡します。ルールにoutboundTagを書いただけでは、クライアントにそのアウトバウンドが作成されたことにはなりません。最終的な実行設定にタグが存在し、つづりと大文字・小文字も一致している必要があります。カスタムアウトバウンドは、明確に必要な転送処理に使い、GUIの設定をすべて置き換える用途には向きません。通常利用では、標準的なサーバー設定はv2rayNに管理させ、カスタム設定には本当に必要な部分だけを追加すると、更新や移行の負担を抑えられます。

最終的な設定をどこで管理するか確認する

GUIクライアントは通常、選択中のサーバー、ルーティングのプリセット、DNSテンプレートから実行設定を生成します。一時生成されたファイルを直接編集しても、次回のサーバー切り替えやコア起動時に上書きされることがあります。現在の編集画面が「サーバー設定」「ルーティング設定」「完全なカスタム設定」のどれに当たるか確認してください。それぞれ編集できる範囲が異なります。完全なカスタム設定を使う場合は、クライアントがローカルのインバウンド、ログ、管理用インターフェースを追加するかも確認しましょう。画面上のすべての設定項目が引き続き反映されるとは限りません。

変更を始める前に、現在正常に使える設定をエクスポートし、ログで実際に動作しているコアを確認します。XrayとV2FlyはいずれもJSON形式の設定を使いますが、対応する項目やプロトコルは完全に同じではありません。他のTUNバックエンドの設定構造は、なおさらそのまま流用できません。既存ファイルへ設定を統合する際は、ルートオブジェクト、配列、カンマを正しく保ってください。同じオブジェクトにキーを重複して書くと、明確なエラーが出ないまま設定が上書きされることがあります。構文解析に成功しても、書式が正しいと分かるだけです。コアが各項目を受け入れ、接続を確立できることも確認してください。

直接接続とローカル転送でタグを理解する

以下のXray形式のアウトバウンド設定例には2つのタグがあります。directは直接接続を表し、local-socksはリクエストをlocalhostのループバックアドレスで待ち受けているSOCKSサービスへ渡します。2つ目のアウトバウンドを使えるのは、指定したローカルポートで実際にサービスが待ち受けている場合だけです。例にあるポート番号は、すべてのクライアントでの既定値を示すものではありません。現在の設定のインバウンドポートを指定すると、転送ループが発生するおそれがあります。すでにアウトバウンドの配列がある場合は、既存のプロキシ用アウトバウンドを置き換えず、必要なオブジェクトを追加してください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1080
          }
        ]
      }
    }
  ]
}

この形式の設定では、どのルーティングルールにも一致しない通信は、通常、アウトバウンド配列の先頭にある項目を使います。そのため、この例のデフォルトは直接接続であり、日常利用向けのプロキシ設定一式ではありません。実際に統合する際は既存のデフォルトアウトバウンドを維持し、追加したタグは対象を絞ったルールから参照してください。まずテスト用のドメインを1つ選び、local-socksに渡してローカルサービスが使えることを確認してから、対象範囲を広げます。アウトバウンドを追加した直後に全通信を対象とするルールを設定すると、問題が通信経路全体に影響します。

多段転送と出口の選択を区別する

アウトバウンドを複数登録しても、リクエストが順番にすべてを経由するわけではありません。通常、1つの接続で選択されるアウトバウンドは1つです。コアが対応する多段接続の仕組みを明示的に設定した場合にのみ、前後の接続関係が作られます。多段接続では、どの段階でサーバーのドメインを解決するか、どこでUDPを処理するか、前段が停止したときどうなるか、どちら側のログを確認するかも考慮する必要があります。明確な目的がない場合は、見た目だけを理由に転送を重ねないでください。接続時間が延び、トラブルの原因も特定しにくくなります。

カスタムアウトバウンドを確認する際は、まず下流サービスの待ち受けアドレスとポートを確認し、次にタグの存在、最後にルールの適用状況と接続エラーを調べます。ログに接続拒否が記録されている場合は、待ち受けサービスを確認してください。アウトバウンドが見つからない場合は、タグと設定の統合状態を調べます。ループや大量の重複接続が発生した場合は、すぐに該当するコアを停止して、正常に動作していた設定に戻しましょう。その後で変更を1つずつ追加します。コアとGUIクライアントの役割についてはProject Vのオープンソースエコシステム解説を参照してください。クライアント名をアウトバウンドのプロトコル名と同一視しないでください。

08 · 互換性と動作確認

プロトコル、コア、設定の動作確認

詳細設定を終える前に、互換性を4段階で確認しましょう。クライアントが該当する項目を設定できるか、選択したコアがその項目を解釈できるか、サーバーが対応する機能を備えているか、現在のネットワークから接続できるか、のすべてが必要です。どれか1つでも欠けると接続に失敗します。クライアントに設定項目があっても、すべてのサーバーで使えるとは限りません。インポート後にメモが表示されても、設定が完全に取り込まれたとは限りません。デスクトップではv2rayNでの設定管理を優先し、Androidでは用途に応じてv2rayNGまたはv2flyNGを選びます。具体的な対応範囲は、実際に使用するコアとインポート結果で確認してください。

プロトコル、トランスポート、暗号化レイヤーを分けて確認する

VLESS、VMess、Trojan、Shadowsocksは、それぞれ認証や接続の仕組みが異なります。プロトコル名だけを変更して、別のプロトコルへ切り替えることはできません。トランスポート方式は接続を運ぶ方法を定め、TLSやREALITYなどの設定はハンドシェイクや接続先の識別情報に関係します。トラブル対処では、まずプロトコルと認証情報、次にアドレスとポート、その後でトランスポート経路やサービス名などの項目、最後にTLSのサーバー名またはREALITYに必要な設定を確認します。配信元から提供されていない値を、別のサーバーの設定を参考に補わないでください。

VLESS自体にはTLSと同等の通信暗号化機能がないため、サーバーの要件に合わせて適切なセキュリティレイヤーを設定する必要があります。REALITYとXTLS Visionも、互換性のあるプロトコル名として自由に置き換えられるものではありません。セキュリティレイヤー、フロー制御、コアの対応状況を合わせて確認してください。ハンドシェイクに失敗する場合、ルーティングルールではなく、サーバー名、キー関連の項目、ショートID、システム時刻の不一致が原因のことがあります。仕組みと各設定項目の関係はREALITYとXTLS Visionの仕組みで解説しています。テストでは配信元から提供された設定をすべて正確に使ってください。

コアの切り替えはあらゆる障害に効く解決策ではない

XrayとV2Flyは、Project Vに関連するエコシステムのコアです。GUIクライアントは画面上の設定をコアが実行する設定へ変換します。v2rayNGは主にXrayを採用し、v2flyNGはV2Flyを対象としています。特定の拡張機能を含む設定を、両者の間でそのまま移行できるとは限りません。v2rayNでコアを選ぶ場合も、使用するプロトコルと設定テンプレートを踏まえて判断してください。切り替える前に現在のコアと有効な詳細機能を記録し、既存の接続を停止してから、新しいコアが正常に起動するか確認します。画面上の実行アイコンだけで判断しないでください。

インポート後に項目が欠落した場合は、まず共有形式でその設定項目を表現できるか、現在のクライアントがその形式に対応しているかを確認します。必要に応じてGUI上で項目を1つずつ照合してください。ただし、実際の認証情報を公開の質問や相談に貼り付けてはいけません。コアが起動しない場合は、まず設定の構文、未対応の項目、ポートの競合、依存ファイルを確認します。起動するのにハンドシェイクが失敗する場合は、サーバー設定、システム時刻、ネットワーク接続を調べてください。この2種類の障害では対処方法が異なります。原因を確認せずにコアを切り替えると、手掛かりが分かりにくくなります。

再現可能な動作確認の手順を作る

設定を変更するたびに、同じ順序で動作を確認します。まずコアが設定を正常に読み込んだこと、次にローカルの接続入口が使えることを確認します。続いて一般的なドメイン、直接接続することが明確な宛先、プロキシが必要な宛先を1つずつテストします。TUN、UDP、IPv6、合成アドレスなどの追加機能は最後に確認してください。ブラウザーでページが1つ開いても、そのときの特定の経路が使えたことしか分かりません。長時間接続、バックグラウンドアプリ、ネットワーク切り替えも、接続を作り直して別途テストし、古い接続が新しい設定の問題を隠さないようにします。

ログは時刻、宛先、インバウンド、適用ルール、アウトバウンドのタグを中心に整理します。エラーの種類は原文のまま残しつつ、サブスクリプションURL、認証情報、不要な個人の閲覧履歴は隠してください。トラブル対処のため一時的にログレベルを上げた場合は、解決後に適切なレベルへ戻し、記録を必要以上に残さないようにします。複数の章にまたがる変更が原因で問題が起きた場合は、最後に正常動作した状態へ戻し、サブスクリプション、ルーティング、DNS、通信の取り込み、追加機能の順に復元します。異常な状態のまま微調整を続けるより、再現性のある方法です。

このページは設定同士の依存関係を理解するためのもので、すべての機能を有効にする必要はありません。最終的には、内容を説明でき、動作を確認でき、元に戻せる設定を維持しましょう。一般的なアプリの通信が想定どおりに取り込まれ、ローカルサービスに接続でき、DNSの経路とルーティングが一致し、サブスクリプションを更新しても手動設定が失われない状態が目安です。初回接続をやり直す場合はクイックスタートに戻ってください。症状から解決方法を探す場合はよくある質問をご覧ください。確認結果と直近の変更を結び付けて記録すれば、詳細設定を一時的な試行ではなく、継続して管理できる環境にできます。