v2rayN · v2rayNG · v2flyNG

V2Rayの応用設定
サブスクリプション・ルーティング・DNS

本ページは設定テーマごとに整理した総合ガイドです。設定項目どうしの依存関係、ルールの適用順、トラブルの切り分け方を解説します。初回インストール、サブスクリプションの追加、接続の確立は、まず入門ガイドを最後まで進めてください。接続できる状態になったら、以下の章を参考に項目ごとに調整します。入門ガイドでは基本的な使い方を、本ページでは同じ設定が異なる通信経路でどう働くかを説明します。

デスクトップではv2rayNを、Androidでは主にv2rayNGを使用します。V2Flyの設定環境が必要な場合はv2flyNGを使います。メニュー名は画面の更新により変わる場合があります。以下では設定の意味とコアのフィールドをあわせて説明します。特定のコアの設定を、すべてのクライアントで共通して使えるものと考えないでください。

設定レイヤーと復旧用の基準

まず画面・コア・OSを区別する

アクセスできるかどうかは、サーバーの設定だけで決まるわけではありません。GUIクライアントはサブスクリプション、選択中のサーバー、画面上の設定を保存し、コアが読み込める設定を生成します。コアは受信待ち受け、ルーティング判定、名前解決、アウトバウンド接続を処理します。OSはアプリの通信がクライアントに届くかどうかを制御します。トラブルの際は、まず問題がどのレイヤーで起きているかを確認してください。たとえば、ブラウザーがシステムプロキシを使っていない場合は通信の入口の問題です。一方、コアにアウトバウンドタグが見つからないと表示される場合は設定の参照先の問題です。両者を同じスイッチで解決しようとしてはいけません。

v2rayNの「パラメーター設定」「ルーティング設定」と、メイン画面のシステムプロキシ設定は、それぞれ異なる処理に影響します。「システムプロキシを自動設定」は通常、アプリに提供するプロキシの入口を変更するもので、仮想NICを有効にする設定ではありません。「Tunを有効にする」と、通信を取り込む別の経路が追加されます。Android版v2rayNGはシステムVPNインターフェースで通信を受け取り、「ルーティング設定」でコアに入った後の振り分けを行います。画面上の「中国本土を迂回」は複数のルールテンプレートを指す場合があるため、同じ名称だからといって最終的に生成される内容まで同じとは限りません。

繰り返し確認できる基準を作る

作業を始める前に、現在使える設定を記録します。クライアント名、使用中のコア、選択中のサーバー、ルーティングモード、システムプロキシの状態、DNS関連の設定を控えてください。クライアントのバックアップまたはエクスポート機能で設定を保存する場合、ファイルにサブスクリプションURL、接続識別情報、認証情報が含まれることがあります。アクセスを管理できるフォルダーに保管してください。問い合わせ用のスクリーンショットを撮る場合は、これらの情報を隠します。認証情報を含む設定全体を公開の場に貼り付けたり、問題発生前の操作状況を省いてエラーの最終行だけを共有したりしないでください。

基準の確認には、代表的な操作を3つ選びます。プロキシを明示的に使うアプリで通常のWebページを開く、LAN内の自分のサービスにアクセスする、日常的に使う業務アプリを試す、の3つです。記録するのは成功・失敗、エラーの種類、発生条件であり、単一の遅延値ではありません。ブラウザーでページが開けても、ほかのアプリの通信が取り込まれているとは限りません。LANにアクセスできても、DNSの問い合わせが想定どおりの経路を通っているとは限りません。同じ操作を設定変更の前後で繰り返して、初めて比較できます。

設定レイヤー主な確認箇所よくある誤認
アプリの通信入口アプリのプロキシ、システムプロキシ、VPNまたはTUNの状態コアに届いていない通信をサーバー障害と誤認する
クライアントによる設定生成現在のグループ、サーバー、ルーティング、パラメーター設定有効化されていない設定を変更してしまう
コアの処理起動ログ、DNSログ、アウトバウンドエラー名前解決の失敗をTLSエラーと誤認する
OSのネットワークルーティングテーブル、NIC、ほかのVPN、ファイアウォールほかのソフトが通信を取り込んでいる可能性を見落とす

一度に変更する項目は1つだけ

サブスクリプションの整理、ルーティング、DNSの順に調整し、最後にTUNとFakeDNSを有効にするのがおすすめです。各項目を変更するたびに再接続し、基準にしたテストを繰り返します。クライアントからコアの再起動を求められた場合は、設定画面を閉じただけではなく、新しい起動処理がログに記録されたことを確認してください。コアを切り替える前に、プロトコルやセキュリティ設定がサポートされているか確認しましょう。特にREALITYなどの設定には注意が必要です。詳しい違いはXrayとV2Flyコアの違いを参照し、名称が似ているからと互換性があると判断しないでください。

問題が起きたら、変更した順序を逆にたどって設定を戻します。まず新たに追加した通信の取り込み機能や名前解決機能を無効にし、次にルーティングテンプレートを元に戻し、最後に以前のサーバー設定に戻します。戻しても解決しない場合に限り、システムプロキシの設定残り、ネットワークの切り替え、ほかのVPNを確認してください。クライアントを更新する場合はインストーラーのダウンロードから該当プラットフォーム用を選べますが、同じ問題の調査中にクライアント、コア、サブスクリプションを一度に変更しないでください。原因をたどれなくなり、再現できていた問題まで偶発的で説明できないものになってしまいます。

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

まず取得元、次に用途でグループ分け

サブスクリプションをグループ分けする主な目的は、取得元ごとに管理することです。v2rayNでは「サブスクリプショングループ」からグループ管理を開き、サブスクリプションURLごとに項目を作成して、見分けやすいメモを入力します。メモには取得元や用途を記載し、パスワードやURL全体は書かないでください。同じ取得元のサブスクリプションに異なる絞り込み条件を適用する場合は、グループを分けられます。ただし、更新後に見分けのつかない重複項目ができないよう確認してください。手動で追加した接続も別のグループに分けると、サブスクリプション更新で再生成されたサーバーと混ざりません。

v2rayNGでは通常、サイドバーの「サブスクリプショングループ設定」でURLを管理し、メイン画面に戻ってサブスクリプションを更新します。v2flyNGの設定入口や使用できるフィールドは、実際の画面で確認してください。URLを保存しただけではサーバー一覧に取り込まれていません。更新が成功しても、使えるサーバーが選択されているとは限りません。操作後は現在のグループ、一覧の内容、現在選択中の項目を確認します。更新後に一覧が空の場合は、サーバー側から内容が返されていないのか、形式を解析できないのか、クライアントの絞り込みですべての項目が除外されたのかを切り分けてください。

絞り込みは一覧に作用する機能で、アクセス制御の代わりにはならない

サーバーの絞り込みでは、通常、メモの文字列、プロトコルの種類、またはクライアントが提供する条件に基づいて項目を残します。変わるのはインポートまたは表示される結果であり、アプリがアクセスできる接続先を制限したり、通信の振り分けルールを自動作成したりする機能ではありません。サーバー名に地域名が含まれていても、実際の接続元や機能が想定どおりとは限りません。絞り込みは一覧を見やすくするために使い、セキュリティ境界として扱わないでください。最初は絞り込みを無効にしてサブスクリプション全体が解析できることを確認し、その後、結果を検証しやすい条件を1つ加えてください。

クライアントによって、絞り込みフィールドでは通常のキーワード、正規表現、または個別の包含・除外ルールを使います。まずフィールド横の説明を読み、通常の文字列だけを受け付ける入力欄に正規表現を書かないでください。正規表現に対応している場合、パイプ記号は「または」、括弧はグループ化を表し、ピリオドは既定で任意の1文字に一致します。ピリオドそのものに一致させるにはエスケープが必要です。大文字と小文字を区別するか、包含と除外のどちらを先に適用するかは、使用中のクライアントで実際に確認してください。別のソフトの仕様を当てはめないでください。

(?i)(テスト|予備)

上の例は、該当する正規表現構文に対応したフィールドで使うもので、「テスト」または「予備」に大文字・小文字を区別せず一致します。項目を残すか削除するかは固定されておらず、包含条件と除外条件のどちらに入力するかで変わります。まずテスト用のグループで確認し、唯一使える本番グループにいきなり適用しないでください。サーバーのメモはサブスクリプション提供元が付けるため、後から変更されることがあり、それに依存する絞り込み結果も変わります。重要な項目が消えた場合は、すぐに再購入したり取得元を変えたりせず、条件を一時的に消して更新してください。

更新経路と通常の通信経路を区別する

サブスクリプションの更新もネットワーク通信です。クライアントに「プロキシ経由で更新」と通常の更新がある場合は、サブスクリプションURLへの到達性に合わせて使い分けてください。現在のプロキシが使えないのに、そのプロキシ経由で復旧用の一覧を取得しようとすると、依存のループに陥りやすくなります。反対に、URLへのアクセスに現在の接続が必要な場合、直接更新は失敗することがあります。調査時は更新リクエストと通常の接続をそれぞれ確認し、「Webページが開ける」ことだけを根拠にサブスクリプションのAPIにも接続できると判断しないでください。

更新後は、現在選択中のサーバーが元のサブスクリプションに属しているか確認してください。更新時に項目が再生成されると、以前の選択記録が新しい一覧に対応しないことがあります。プロトコル、通信方式、セキュリティ設定が保持されていることを確認してから、アクティブな項目に設定します。特定の接続形式に対応していないとクライアントに表示された場合、ファイルの拡張子を変えたり、一部のフィールドだけ残したりして無理にインポートしないでください。クライアントとコアがその形式に対応しているか確認し、必要に応じてサブスクリプション提供元に出力形式を問い合わせます。

一覧が空になる、インポート時に形式エラーが表示される、更新中にネットワークエラーが発生する場合は、サブスクリプションの解析失敗チェックリストに沿って原因を切り分けてください。まず絞り込みを無効にし、取得元と更新経路を確認してから、文字コードと応答内容を調べます。グループ管理で解決できるのは設定の取得元を追跡しやすくすることです。接続品質やプロトコルの互換性は、サーバーを選んだ後に別途確認してください。

ルーティングルールの設定例

ルールの数より適用順が重要

ルーティングは、コアが受け取った接続情報を基にアウトバウンドを選択します。v2rayNでは「ルーティング設定」で現在のルールセットを確認し、編集前にメイン画面でそのセットが選択されていることを確かめてください。XrayとV2Flyの一般的なルーティング動作では、ルールを上から順に確認し、最初に一致したものが適用されます。1つのルール内では通常、異なるフィールドの条件をすべて満たす必要があります。一方、同じドメインやIPのリスト内では、いずれか1つに一致すればよい場合があります。1つのルールにドメインとポートを指定すると、どちらか一方ではなく両方を満たす必要があります。

実用上は、必要なLAN向けの直接接続ルール、特定の業務向けルール、一般的な分類ルールの順に並べ、最後にデフォルトアウトバウンドでどのルールにも一致しない通信を処理します。広すぎる条件のルールを先頭に置くと、後続の細かい条件が適用されません。「中国本土を迂回」などのプリセットは出発点として利用できますが、含まれるドメインやIPの分類、名前解決の方針は、現在のルールセットまたは生成された設定で確認してください。画面上の名前だけではルール全体を把握できません。

ドメインルールとIPルールの適用範囲

full:は完全一致するドメイン名に、domain:はドメイン名とそのサブドメインに一致します。geosite:はドメイン分類リソースを、geoip:はIP分類リソースを参照します。以下の例では、ドメインを明示し、プライベートアドレスへの通信を直接接続する方法を示します。完全な設定にdirectというアウトバウンドが存在することが前提です。クライアントのルールエディターを使う場合は、条件を対応するフィールドに入力してください。ルーティングオブジェクト全体を1つのドメイン入力欄に貼り付けないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

例にあるドメイン名はマッチング構文を説明するためのものです。実際に管理するドメイン名に置き換えてください。IPルールだけでドメインルールを置き換えることはできません。ドメイン名は複数のアドレスに解決されたり、ネットワークによって異なるアドレスを返したりする場合があります。逆に、ドメインルールだけではIPアドレスを直接指定するアプリを判定できない場合があります。LAN内のサービスでは、アクセス方法、DNSが返すアドレス、仮想NICのルーティングをあわせて検討してください。サービス名によってはローカル探索プロトコルが必要なため、ドメインルールを1つ追加するだけでは解決しません。

ルーティングの名前解決ポリシーとDNSのアウトバウンドポリシーは別

AsIsは、可能な限り既存の接続先情報を使ってマッチングします。IPIfNonMatchは、ドメインルールに一致しない場合に名前解決し、IP条件でのマッチングを試みます。IPOnDemandは、IPが必要なルールとの照合時に名前解決する場合があります。これらはルーティングの段階でアドレス情報が必要になるタイミングを決めるもので、DNSの問い合わせがどのアウトバウンドを通るかを直接指定するものではありません。名前解決ポリシーとDNSサーバーを同時に変更すると、問題の原因を区別しにくくなります。まずDNSサーバーを固定し、次にポリシーの変更でルールの一致結果がどう変わるかを比較してください。

スニッフィングは、対応する通信からドメイン情報を取得する補助手段ですが、すべてのプロトコルを確実に識別できるわけではありません。暗号化された通信、アプリがIPアドレスを直接使用するケース、接続の再利用、メタデータ不足などが判定に影響します。有効にした後は、接続先アドレスが書き換えられるかどうかも確認してください。ルーティング情報の補完だけが目的なら、現在のコアにルーティング専用のオプションがあるか確認します。スニッフィングをドメインルールに必ず一致させる仕組みと考えたり、DNS設定の不足をすべて補う手段とみなしたりしないでください。

ログで実際のルール適用を確認する

ルールを保存したらコアを再読み込みし、新しい接続を作成して、ログで使用されたアウトバウンドタグを確認します。既存の長時間接続は以前の経路を使い続けることがあります。ブラウザーのキャッシュやバックグラウンド接続も確認の妨げになるため、必要ならテストアプリを終了してから再起動してください。ルールが適用されない場合は、まず有効なルールセットを確認し、次に前方のルールを調べます。その後、コアがドメイン名とIPアドレスのどちらを受け取っているか、分類リソースが存在するかを確認してください。リソースファイルがない場合は起動時にエラーが記録されることが多く、再接続を繰り返しても解決しません。

デフォルトの動作も明確にしておく必要があります。この種のコアでは、どのルールにも一致しない通信は通常、完全な設定にある先頭のアウトバウンドに渡されます。GUIクライアントはこの動作を前提に、デフォルトのプロキシまたは直接接続を設定していることがあります。ルール一覧だけを見て、未一致時の接続先を判断しないでください。動作を固定する場合は、クライアントのデフォルトルール設定を使うか、カスタム設定の末尾に明示的なルールを設け、管理用通信に特別な要件がないか確認します。用語は用語集、よくある接続の問題はトラブルシューティングを参照してください。

DNS設定の最適化

通常の通信経路とDNSの問い合わせ経路を分けて考える

DNS設定では、まず次の3点を確認します。誰が問い合わせるのか、誰が応答するのか、どのネットワーク経路でDNSサーバーに届くのか。アプリはOSの名前解決を使う場合も、独自の暗号化DNSを使う場合もあります。コアもルーティング判定、接続先の特定、DNSサーバーのアドレス解決のために問い合わせることがあります。したがって、クライアントに外部DNSのアドレスを入力しても、OS上のすべての問い合わせがそこを経由するとは限りません。まずアプリの通信がクライアントに入っているかを確認し、その後で名前解決リクエストがコアで処理されているかを調べてください。

v2rayNでは「パラメーター設定」からDNS関連の項目を確認できます。v2rayNGでは「設定」で「ローカルDNSを有効にする」、リモートDNS、ドメインポリシーなどを確認してください。画面上の「ローカル」は多くの場合クライアント側のDNS処理モジュールを指し、問い合わせ先がLAN内に限られるという意味ではありません。クライアントごとに設定の生成方法も異なります。スイッチを有効にした後は、ログまたは生成された設定を確認し、実際に使用されるサーバーとポリシーを確かめてください。スイッチの表示色だけで、設定が完全に反映されたと判断しないでください。

混同しやすい3つのポリシーを区別する

設定項目解決する問題代わりにはならない設定
ルーティングのdomainStrategyルーティングのマッチング時にドメインをいつ名前解決するかすべての問い合わせが使うネットワーク出口は指定できない
DNS queryStrategy問い合わせでIPv4、IPv6、または両方を使うかOSのIPv6ルート不足は解決できない
アウトバウンドのドメインポリシーアウトバウンド接続時に接続先ドメインをどう扱うか通信を取り込んでいないアプリをプロキシ経由にすることはできない

以下はコアのDNSオブジェクトの一部を示す例で、問い合わせをIPv4アドレスに限定し、DNSサーバーを指定しています。DNS通信のルーティング設計は含まず、問い合わせが自動的にプロキシを通るという意味でもありません。暗号化DNSを設定する場合は、現在のコアが対応するアドレス構文、証明書の検証、名前解決の入口も確認してください。DNSサーバーのアドレスがドメイン名の場合、最初の名前解決にどのDNSを使うか確認し、「接続には名前解決が必要だが、その名前解決には接続が必要」という循環を避けてください。

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

通信の用途に応じて名前解決方法を選ぶ

LAN内のドメイン名は、通常ルーター、社内DNS、検索ドメインに依存するため、該当するローカルの名前解決経路を維持してください。すべての問い合わせを公共DNSに送ると、内部サービスのアドレスを取得できなくなる場合があります。外部サービスでは、DNSの結果と使用するアウトバウンドの整合性も考慮します。接続先が地域に応じた配信を行う場合、DNSサーバーのネットワークと実際の出口が異なると、適切でないアドレスが返ることがあります。重要なのはDNSサーバーを増やすことではなく、ドメインの種類ごとに説明できる名前解決と接続の経路を設計することです。

DNSサーバーを複数設定しても、一覧の順に1つずつ試すとは限りません。コアによってはドメイン条件に応じて並行問い合わせを行ったり、結果を統合したりします。フォールバック用フィールドの対応状況も実装によって異なります。まず安定したDNS経路を1つ使って動作を確認し、その後、ドメインごとにDNSサーバーを選べるようにして、デフォルトのフォールバックで残りの接続先を処理できるか確認してください。外部DNSに送信できない内部ドメインがある場合は、リストの先頭に社内DNSを加えるだけでなく、公共DNSへのフォールバックを明示的に除外します。

キャッシュ、デュアルスタック、ログの確認順

DNS設定を変更しても、アプリ、OS、コアのキャッシュに古い結果が残っている場合があります。テストアプリを終了して再起動し、OSで用意されている方法で名前解決キャッシュを更新し、必要に応じてクライアントのコアも再起動してください。失敗するたびにDNSサーバーを切り替えると、キャッシュの影響で変更前後を比較しにくくなります。ログにタイムアウトが記録された場合は、まず問い合わせ経路に到達できるか確認します。アドレス取得後に接続が失敗する場合は、接続先のアドレスファミリー、ルーティング、リモート接続を調べ、DNSのスイッチだけを繰り返し変更しないでください。

IPv6の問題では、「アドレスを取得できる」ことと「接続を確立できる」ことを区別します。ネットワークからIPv6アドレスが返されても、IPv6の出口が安定していなかったり、仮想NICのルーティングが正しくなかったりする場合があります。原因の切り分けとして一時的にアドレスファミリーを制限することはできますが、すべての環境で使う恒久的な最適化として扱わないでください。逆に、IPv6が必要なネットワークでIPv4だけを問い合わせると、接続できなくなる場合があります。診断後は現在のネットワーク環境に合ったポリシーに戻し、新しい接続で検証します。1回のページ表示速度だけでDNS全体の設定を評価しないでください。

TUNモード

通信の取り込み範囲が変わっても、ルールが無効になったわけではない

TUNは仮想NICとOSのルーティングを使って、条件に合うIP通信をクライアントに転送します。システムプロキシに従わないアプリに適しています。変わるのは通信がクライアントに入る方法であり、すべての接続先が自動的にリモートプロキシを通るわけではありません。クライアントに入った後は、ルーティングルールに従って直接接続、プロキシ、ブロックを選択します。つまり「Tunを有効にする」と「グローバルプロキシ」は同じではありません。通信の取り込み範囲を広げた場合も、LANへの直接接続、内部DNS、業務上の例外が必要かを個別に確認してください。

デスクトップ版v2rayNで使う場合は、まずシステムルートを変更する可能性のあるほかのVPNや仮想NICツールを終了し、プラットフォームの指示に従ってインターフェースの作成やルートの変更に必要な権限を付与します。権限が不足すると、画面上では切り替わったように見えても、NICやルートが作成されていない場合があります。起動の問題を解決するためにファイアウォールを常時無効にしないでください。まずクライアントとOSのログを確認し、権限の取得、インターフェースの作成、ルールの適用のどこで失敗したかを特定してから、必要最小限の範囲で設定を変更します。

システムプロキシからTUNへ段階的に切り替える

有効にする前に、通常のプロキシ設定で現在のサーバーが使えることを確認し、元のルーティングモードを記録してください。その後、v2rayNのメイン画面で「Tunを有効にする」に切り替え、コアの起動ログと仮想NICの状態を確認します。初回のテストでは、システムプロキシを明確に切り戻せる状態にしておきます。アプリ独自のプロキシ、システムプロキシ、TUNを同時に重ねると、原因を判断しにくくなるためです。併用する場合は、それぞれの入口で使う待ち受けアドレスと通信経路を理解してください。入口を増やせば設定が完全になるわけではありません。

3つの方向から確認します。システムプロキシを使わないアプリが想定した接続先にアクセスできるか、LAN内の機器に引き続き接続できるか、DNSが設計どおりに名前解決するかをテストしてください。ブラウザーがシステムプロキシを使用していると、TUNで通信を取り込めていなくても正常に見える場合があるため、それだけでは検証できません。内部サービスを確認する場合は、ドメイン名と既知の内部アドレスの両方を試します。ドメイン名で失敗して内部アドレスで成功するなら、リモートサーバーではなくDNSや検索ドメインを確認してください。

ルーティングループと仮想NICの競合

TUNでは、リモートサーバーに向かうクライアントの通信が再び自身に転送され、ループするのを防ぐ必要があります。クライアントは通常、インターフェースのバインド、ルートの除外、プロセスの処理などで回避しますが、カスタムルール、複数VPNの同時使用、ネットワークインターフェースの変更で条件が崩れる場合があります。有効化後にすべての接続がタイムアウトしたり、ログに同じ接続先への接続が繰り返し記録されたりする場合は、まず新たに有効にした通信の取り込み機能を停止し、デフォルトのNICとサーバーへの通信経路を確認してください。範囲の広いプロキシルールを追加して解決しようとしないでください。

有線から無線への切り替え、スリープからの復帰、企業VPNへの接続は、インターフェースの順序やルートの優先順位を変える場合があります。ネットワーク切り替え後だけTUNが失敗する場合は、クライアントを再接続し、新しいネットワーク状態に合わせて再構成してください。毎回失敗する場合は、使えなくなったインターフェースに固定でバインドされていないか確認します。LinuxとmacOSでは、OSの認証方式、NIC名、ルート管理が異なるため、Windowsの手順をそのまま適用できません。使用中のクライアントが表示する権限の説明と、OSのネットワーク管理方法に従ってください。

UDP、MTU、ネットワークの復旧

TUNで特定の通信を受信できても、リモートのプロトコル、トランスポート、サーバーが同じ転送機能に対応しているとは限りません。UDPを使う通信が失敗したら、まず接続経路全体がUDPに対応しているか確認し、次に該当する通信が正しいアウトバウンドへ送られているか調べてください。大きな応答、ファイル転送、特定アプリだけが止まり、通常の短いリクエストは成功する場合に限り、MTU、パスMTU検出、フラグメントの問題を検討します。根拠なくMTUを下げ続けないでください。元の値を記録し、変更のたびに同じ通信で確認します。

クライアントを終了する前に、画面からTUNを無効にし、正常に終了させてルートとインターフェースの状態を解除してください。異常終了後にネットワークが復旧しない場合は、システムプロキシが停止済みのローカルポートを参照したままになっていないか確認し、次にほかのVPNや残存するNICの状態を調べます。必要ならOSのネットワーク設定から接続を復旧できますが、用途を把握していない状態で使用中の企業ネットワーク設定を削除しないでください。通常のネットワーク接続に戻ったら、この章の最小限のテストをやり直し、すべての機能をすぐに再度有効にしないでください。

FakeDNS

合成アドレスでドメインとの対応を保持する

FakeDNSは、接続先の実アドレスを返す通常のDNSではありません。専用のアドレスプールから合成アドレスを割り当て、ドメイン名との対応関係をコアに保存します。その後、アプリがそのアドレスに接続すると、コアは対応関係からドメイン名を復元し、ルーティングとアウトバウンドの処理を続けます。これにより、一部の通信取り込み環境ではドメイン情報を保持しやすくなり、振り分けを決める前に実アドレスを取得する必要を減らせます。ただし、DNS、通信の取り込み、ドメイン名の復元まで一連の経路が正しく機能する必要があります。スイッチを有効にするだけでは設定は完了しません。

v2rayNGでは「設定」で「Fake DNS」関連の項目を確認し、「ローカルDNSを有効にする」と現在のルーティング設定もあわせて確認してください。必要な設定が自動生成される範囲は、コアやクライアントによって異なります。実際に生成された設定と起動ログで確認してください。v2flyNGは画面が似ているという理由だけで、同じパラメーターを流用しないでください。まず通常のDNSとルーティングの基準を整えてからFakeDNSをテストします。通常のネットワーク接続が確立できていない段階で合成アドレスを加えると、調査するレイヤーが増えるだけです。

アドレスプール、問い合わせの入口、復元の仕組み

以下は一般的なコア構文の一部を示す例で、合成アドレスプール、DNSサービスの入口、インバウンドのスニッフィングに関するフィールドを含みます。適切な場所に統合して使うものであり、オブジェクト全体をクライアントのスイッチ横にある入力欄へ貼り付けるものではありません。例にあるスニッフィングのオブジェクトはインバウンド設定の一部です。完全な設定には、対象の通信を処理するインバウンド、ルーティング、アウトバウンドも必要です。アドレスプールは実際の業務用ネットワークと重複しないようにし、任意の公共IPアドレス帯を指定しないでください。

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

上の例に示すアドレス帯はテスト用ネットワーク向けで、ここでは合成アドレスプールの例として掲載しています。実際のサーバーアドレスではありません。アドレスプールのサイズは保存できる対応関係の容量に影響しますが、容量を増やせば常に性能が向上するわけではありません。重要なのは、アプリが受け取った合成アドレスを、対応関係を保持する同じコアに必ず戻すことです。あるクライアントがDNSに応答した後で別のVPNが接続を取り込んだ場合や、コアの再起動後までアプリがアドレスを保持した場合、対応関係を復元できないことがあります。

アプリの動作から適用可否を判断する

テストに適したのは、アプリが主にドメイン名で接続し、DNS問い合わせとその後の接続を同じクライアントが取り込み、ルーティング段階でドメイン名を安定して取得したい場合です。一方、実アドレスに基づいて処理するアプリ、名前解決の結果をほかの機器に渡すサービス、社内ネットワークとテスト用アドレス帯が重複する環境には適さない場合があります。アプリによってはDNS応答の属性を確認したり、結果をキャッシュしたり、OSのDNSを使わずに名前解決したりします。そのため、FakeDNSの挙動は通常のブラウザーテストと異なることがあります。

アプリ独自の暗号化DNSを使う場合、問い合わせがFakeDNSの処理モジュールを通らないことがあります。スイッチが有効でも実アドレスが返されたからといって、必ずしもコアの障害とは限りません。逆に、アプリが合成アドレスを取得しても、クライアントを経由せず直接接続しようとすれば失敗します。調査では、問い合わせが合成アドレスで応答されたか、接続がクライアントに取り込まれたか、コアがドメイン名を復元できたかをそれぞれ確認してください。「特殊なアドレスが見えた」ことだけで経路全体が正しいと判断しないでください。

有効化時も無効化時もキャッシュを扱う

有効にした後はテストアプリを再起動し、新しいDNS問い合わせを発生させてから、通常のWebページ、LAN内のサービス、日常的に使う業務アプリを試してください。LAN内のドメイン名が誤って合成される場合は、現在のクライアントで可能であれば内部ドメインに実際の名前解決を使い、該当する接続が直接接続されることも確認します。DNSルールでの除外、ルーティングルールでの直接接続、OSのルートでの迂回はそれぞれ異なる段階に作用します。1つだけ設定しても不十分な場合があります。

FakeDNSを無効にしても、アプリやOSに合成アドレスがキャッシュされている一方、コアでは対応関係が保持されなくなっている場合があります。そのため「無効にしたら一時的に接続できなくなった」という状態が起きることがあります。まずテストアプリを終了して関連するキャッシュを消し、接続をやり直してから設定の切り戻しができたか判断してください。クライアントの再起動でも対応関係の状態が変わるため、長時間動作するアプリもテスト対象に含めます。仕組みや適用範囲の詳細はFakeDNSの仕組みと適用例を参照してください。

複数サブスクリプションの管理

取得元・用途・更新の対応関係を整理する

複数のサブスクリプションを管理する場合は、まず取得元ごとにグループを作り、日常の接続に使う項目と互換性テストだけに使う項目を分けます。すべての接続を1つの大きな一覧にまとめ、メモから取得元を推測する方法は避けてください。グループ名には「日常」「テスト」「手動設定」などの用途を付けられますが、取得元との対応関係はローカルの記録にも残しておきます。アカウントのリセットでサブスクリプションURLが変わることがあります。名称が変わっていなくても、以前と同じ設定群を参照しているとは限りません。

v2rayNの「サブスクリプショングループ」で、各グループのURL、絞り込み条件、更新方法を確認し、クライアントで選べる更新間隔を設定します。Androidでは「サブスクリプショングループ設定」で取得元を管理し、グループごとに更新してください。まず個別に更新し、それぞれの取得元から正常に読み込めることを確認してから、「すべてのサブスクリプションを更新」のような一括操作を使います。こうしておけば、一部だけ失敗した場合に取得元を特定しやすくなり、すべてのネットワークエラーをクライアントの障害と誤認せずに済みます。

更新頻度とアクティブ項目は別々に管理する

更新回数を増やしても、接続が安定するとは限りません。更新リクエストにはネットワークとサーバー側の処理が必要で、取得元によってはアクセス制限の対象になる場合もあります。提供元の利用案内と実際の更新頻度に応じて設定し、極端に短い間隔で繰り返し更新しないでください。モバイル機器ではバックグラウンド実行の制限も考慮します。OSの省電力機能により更新が遅れることがあり、画面上の間隔どおりに毎回実行されるとは限りません。必要なときは対象のグループを手動で更新し、結果を確認してください。バックグラウンドの状態だけに頼らないでください。

更新後は現在アクティブなサーバーを確認します。サブスクリプション更新で古い項目が削除されたり、メモやセキュリティ設定が変わったり、クライアント内部の識別子が再生成されたりする場合があります。お気に入り、並び順、ルーティングとの関連付けが維持されているか、現在の画面で確認してください。表示名が同じでも設定が変わっていないとは限りません。カスタムアウトバウンドやタグを使って参照する設定では、参照先が想定どおりの項目であることも調べます。日常的に使う項目には用途を明記し、更新後に確認しやすくしてください。

重複項目とデバイス間の移行

複数のサブスクリプションに同じ接続が含まれていたり、手動インポートした項目と更新で取得した項目が併存したりすると、重複が発生する場合があります。メモだけで判断せず、アドレス、ポート、プロトコル、セキュリティ設定、通信方式を比較してください。表示名が同じという理由だけで片方を削除すると、用途の異なる設定を誤って消す可能性があります。クライアントに重複排除機能がある場合は比較基準を確認し、バックアップを取ってからテスト用グループで実行してください。取得元が異なる項目は、接続設定が同じでも更新や削除の管理単位が別になる場合があります。

デバイス間の移行では「サブスクリプションの取得元」と「デバイス固有の環境設定」を分けて扱います。権限のあるデバイス間で必要に応じてサブスクリプションURLを再入力できますが、ローカルの待ち受けポート、TUNの権限、システムプロキシ、アプリごとのプロキシ、LAN内DNS設定は通常そのまま移せません。v2rayNの設定ファイル全体をv2rayNGやv2flyNGのバックアップとして使うこともできません。移行先で基本設定を完了してから、ルーティングとDNSの方針を1つずつ再現してください。元のデバイスにしか存在しない経路やインターフェース名をコピーしないよう注意します。

管理対象移行方法確認事項
サブスクリプションの取得元移行先のクライアントでグループを作り直す利用権限、URLの有効性、出力形式
絞り込み条件移行先クライアントの構文で再テストする通常の文字列と正規表現の意味が同じか
ルーティング方針ドメイン、IP、アウトバウンドを個別に再設定する適用順、分類リソース、デフォルトの動作
デバイス固有のネットワーク設定移行先のOSに合わせて再設定するNICの権限、待ち受けの入口、LAN内の名前解決

使えなくなったサブスクリプションと認証情報の無効化

取得元の1つで更新に失敗した場合は、ほかの使用可能なグループを残し、再試行のためにサーバー一覧をすべて消さないでください。失敗がそのサブスクリプションだけに限られることを確認し、URLの期限切れ、ログイン後の再取得の必要性、使えなくなった接続経由で更新していないかを調べます。URLが漏えいした場合は、提供元のリセット手順で古いURLを無効にしてから、端末のグループを更新してください。グループのメモを変えても古いURLは無効になりません。ほかのデバイスも確認し、バックグラウンドで古いURLへのリクエストが続かないようにします。

長期間使っていない取得元は削除し、関連するお気に入り、ショートカット、自作アウトバウンドからの参照も確認してください。エクスポートしたバックアップに無効化済みのURLが残っている場合があります。バックアップを復元した後も、改めて確認が必要です。複数サブスクリプションの管理では、各設定の取得元と用途を把握し、個別に元へ戻せる状態を保ちます。一覧を増やし続けることが目的ではありません。管理が日常操作の妨げになってきた場合は、複雑な自動選択ルールを加える前に、重複する取得元や用途を失った項目を整理してください。

カスタムアウトバウンド

タグは参照に使うもので、接続名ではない

アウトバウンドは接続先への通信方法をコアに定義し、ルーティングはタグを使ってアウトバウンドを選択します。outboundTagは完全な設定内に存在するtagを参照する必要があり、大文字・小文字を含めて正確に一致させてください。クライアントの一覧に表示されるサーバーのメモが、コアのタグとは限りません。サブスクリプショングループ名も、自動的に参照可能なアウトバウンドにはなりません。ルールを書く前に、生成された設定のタグ構造を確認してください。特に、画面上で読みやすい名称をルーティングに入力すれば、コアが対応するサーバーを自動で探すと思い込まないようにします。

以下は直接接続とブロックのアウトバウンドを定義する一部の例で、これらのプロトコルオブジェクトに対応するXrayまたはV2Flyの設定環境で使えます。定義するのは2つのアウトバウンドだけで、プロキシサーバー、インバウンド、ルーティング全体は含みません。既存のアウトバウンド一覧をそのまま置き換えると、元のプロキシ接続が失われます。GUIクライアントが同じタグをすでに生成していることもあるため、統合前に重複を確認してください。同じタグが複数あると参照先が曖昧になります。表示順を変えても解決しません。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

ブロックルールとデフォルトアウトバウンドを明確にする

ブロックはアクセス不要と確認できた接続先に使い、未知の通信をすべて処理する近道として使わないでください。まず日常の業務に影響しないテスト用ドメインでルールが適用されることを確認してから、対象を広げます。業務アプリは認証、コンテンツの読み込み、更新に複数のドメインを使う場合があります。そのうち1つだけをブロックしても、ページの一部が表示されなくなることがあります。問題が起きたらログで対象の接続先を特定し、広いドメイン分類を次々に試さないでください。

{
  "type": "field",
  "domain": ["full:example.invalid"],
  "outboundTag": "block"
}

上の例はrouting.rules配列に追加するルールオブジェクトで、構文を示すために予約済みの無効なドメインを使用しています。このルールは、前述のblockアウトバウンドが存在する場合にのみ意味があります。実際の業務ルールでは、接続先を確認してから必要に応じて完全一致またはサブドメイン一致を使ってください。同時に、ルールに一致しない通信のデフォルトの接続先も確認します。カスタム設定でdirectが先頭にあり、フォールバックルールがない場合、既存のクライアント設定とはデフォルトの動作が異なることがあります。明示したルールの確認だけで終わらせないでください。

チェーン接続とアウトバウンドの選択は別の仕組み

アウトバウンドが複数並んでいても、ルーティングで異なる経路を選べるだけで、自動的にチェーン接続になるわけではありません。チェーン接続には、コアが対応するアウトバウンド間の転送機能、正しい参照方向、到達性を考慮した設計が必要です。具体的なフィールドや制限はコアによって異なります。この機能が必要な場合は、まずクライアントが対応する前段プロキシやチェーン接続の入口を提供しているか確認し、使用中のコアのドキュメントに従って設定してください。サーバーを配列に順番に並べただけで、その順に接続が通ると思い込まないでください。

負荷分散、フェイルオーバー、手動切り替えもそれぞれ異なる機能です。セレクターは一定の条件で候補アウトバウンドを選びますが、確立済みの接続が自動的に切り替わるわけではありません。接続先の疎通確認に成功しても、すべての業務通信が使えるとは限りません。自動化を追加する前に、各アウトバウンドが単独で使えることを確認し、プロトコル、セキュリティ設定、DNSの経路が正しいか検証してから選択条件を設計します。サブスクリプション更新でアウトバウンドタグが再生成される場合は、セレクターの参照先も更新してください。参照が合わないと設定を起動できなかったり、候補が空になったりすることがあります。

対応する設定入口を使い、復旧用のコピーを残す

v2rayNでカスタム設定を使う場合は、現在の設定が画面から生成されているのか、外部ファイルから読み込まれているのかを確認してください。設定の管理範囲が異なります。画面から生成するモードでは、再起動時に手動変更が上書きされる場合があります。カスタムファイルを使うモードでは、自動生成される設定を一部利用できない場合があります。Androidでもクライアントが提供する設定入口からインポートしてください。ファイルの管理方法がわからないまま、内部ディレクトリを編集しないでください。保存後は起動ログを確認し、未対応フィールド、タグの不足、リソースパスの誤りがないことを確かめます。

完全な設定を検証するときは、インバウンドの待ち受け、DNS問い合わせ、ルールの適用、アウトバウンド接続の順に確認します。コアが起動しない場合は、まず構文と参照先を修正してください。起動するのに接続できない場合は、通信の入口とネットワーク経路を調べます。問題の確認中は一時的にログレベルを上げられますが、原因がわかったら通常のレベルに戻し、接続先の情報が含まれる可能性のあるログを適切に管理してください。管理できない共有フォルダーにログを書き込んだり、機密性の高い通信情報を含むログを長期間残したりしないでください。

追加したアウトバウンドが明確な目的を解決しない場合は、クライアント内蔵のルーティングに戻し、自分で管理する設定を減らしてください。プロトコルとコアの互換性についてはコアの違いに関する記事を参照できます。基本的な接続の確認は入門ガイドに沿ってやり直してください。応用設定の完了とは、通信経路を一つずつ説明でき、変更を個別に戻せる状態です。できるだけ多くのスイッチを有効にすることではありません。