設定ガイド · v2rayN / v2rayNG / v2flyNG

V2Ray 応用設定ガイド

サブスクリプション、ルーティング、名前解決、アウトバウンドを項目別に解説。

初回接続が完了している方向けのページです。サブスクリプションの追加やシステムプロキシの設定がまだの場合は、先にクイックスタートをご覧ください。クライアントを変更する場合は、クライアントをダウンロードからプラットフォームに合ったインストーラーを選べます。ここではデスクトップ版 v2rayNを中心に、Android版との違いも補足します。インストール手順は扱いません。

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

サブスクリプショングループはサーバーの提供元や更新範囲を管理するもの、サーバーの絞り込みは一覧に表示する項目を選ぶものです。どちらも通信の振り分けとは異なります。1つのグループに複数のサーバーを登録できますが、通常の接続に使われるのは現在選択中のサーバーです。グループのタブを切り替えても、接続中のサーバーが切り替わるとは限りません。この違いを理解しておけば、「別のグループが表示されたから接続先も変わった」と誤認せずに済みます。

管理しやすいグループを作成する

v2rayNの「サブスクリプショングループ」からグループを追加し、提供元がわかるメモを入力してから、サブスクリプションURLをすべて貼り付けます。URLには通常、アクセス用の認証情報が含まれるため、メモには提供元や用途だけを記載し、URLのパラメーターは書き写さないでください。前後の空白や改行を確認して保存し、そのグループだけを更新します。初回更新ではログの完了を確認してから一覧に項目があるか確認しましょう。自動更新、絞り込み、一括削除を同時に有効にしないでください。

グループ名は「提供元＋用途」の形式が便利です。たとえば「仕事用」「モバイル回線の予備」のように付けます。サーバー名はサブスクリプション側から取得されるため、次回更新で変更されることがあります。手動で名前を変えても、長期的な分類には使えません。個別のメモを残す場合は、クライアントに独立したメモ欄があれば利用し、なければ別途記録してください。手動追加したサーバーは別に分類すると、更新結果と混同しにくくなります。

更新時は、直接取得する場合とプロキシ経由で取得する場合を区別してください。接続は正常なのに直接更新できない場合は、メニューにある「プロキシ経由でサブスクリプションを更新」を試せます。一方、初期設定中で接続先がまだ使えない場合、プロキシ経由の更新が必ず解決策になるとは限りません。まず、名前解決の失敗、接続タイムアウト、サーバーからの拒否のどれかを確認しましょう。何度も更新しても期限切れのURLは直りません。提供元でリクエストが制限されるおそれもあります。

一覧を確認してから絞り込む

メインウィンドウの検索やフィルターは、通常、現在表示中の一覧を絞り込む機能です。一方、グループ編集画面にあるサーバーフィルターは、更新後にどの項目を残すかに影響する場合があります。実際の動作は各設定項目の説明で確認してください。絞り込む前に「すべて」を選び、検索条件を消して、対象の項目が存在することを確かめます。その後、対象グループで簡単なキーワードを1つ使って確認してください。複数の条件を重ねると、どの条件でサーバーが除外されたのか判断しにくくなります。

入力欄が正規表現に対応している場合、縦棒は候補の区切り、括弧はグループ化に使い、ピリオドは既定で任意の1文字に一致します。次の式は、別名に2つの用途語のどちらかが含まれる項目を探す例です。あくまでフィルター構文の例であり、入力欄が通常のキーワード検索のみ対応している場合は、正規表現の記号を入力せず、語句ごとに検索してください。大文字と小文字を区別するかどうかも、既知の項目で確認しましょう。

(仕事用|予備)

サブスクリプション更新後に一覧が空になった場合、まず表示フィルターを解除し、次にグループのフィルター、最後に提供元から返された内容を確認してください。画面上で空に見えても、リモートのサブスクリプションが空とは限りません。サーバー一覧では、種類、アドレス、ポート、通信設定をセットで確認してください。別名だけで重複と判断するのは禁物です。同じ名前でも、通信方式が異なることがあります。削除前に現在の接続先を記録し、唯一使える検証用サーバーを消さないようにしてください。

更新後の確認と復元

サーバーフィルターは説明情報をもとに一覧を絞り込むだけで、接続可能かどうかを検証したり、最速の経路を自動選択したりするものではありません。更新後、残った項目から「サーバーへの実接続遅延をテスト」または同等の速度測定メニューを実行し、接続先を手動で選択してください。結果は現在のネットワーク、測定先、サーバーの状態に左右されます。同じネットワークで複数回測定した結果と、実際のサービスへのアクセスをもとに判断しましょう。

更新によって以前の項目が置き換わると、クライアントが古い接続先の選択状態を維持できない場合があります。その場合はサーバーを選び直して設定を再読み込みし、ログでコアが正常に起動したか確認してください。新しい項目を古い測定結果とそのまま比較しないでください。別名が同じでも接続パラメーターが変わっている可能性があります。測定に失敗したら、既知の接続可能なグループに戻して基本接続を確認してから、更新後の一覧を調べましょう。ルーティングとDNSを同時に変更するのは避けてください。

Android版のv2rayNGとv2flyNGでは、サブスクリプションの追加画面、グループ表示、絞り込み機能がデスクトップ版と完全には一致しません。デスクトップ版の正規表現操作をそのまま適用しないでください。提供元ごとにサブスクリプションを管理し、一覧から設定を選ぶ方法が基本です。設定をエクスポートしたりスクリーンショットを共有したりする前に、サブスクリプションURL、サーバー認証情報、アカウントを特定できるメモを削除してください。サブスクリプションURLはアカウント情報として扱い、公開メモや質問用の画像に載せないようにしましょう。

ルーティングルールの実践

ルーティングルールは、コアに届いた接続をどのアウトバウンドに送るかを決めます。すべてのアプリの通信を自動的にコアへ取り込む機能ではありません。システムプロキシの影響を受けるのはプロキシ設定に従うアプリです。TUNはネットワーク層からより多くの通信を取り込みます。そのため、ブラウザーではルールどおりに振り分けられるのに別のプログラムでは変化がない場合、まずそのプログラムがプロキシ経路に入っているか確認してからルールを調べてください。そうしないと、通信の取り込み範囲の問題をドメイン判定の誤りと取り違えます。

プリセットを基準に設定する

v2rayNのルーティング設定で、まず現在のプリセットを記録し、「中国本土をバイパス（Whitelist）」「ブラックリスト（Blacklist）」「全般（Global）」のいずれかを起点にします。プリセット名は設定の入口にすぎず、実際の動作はルール、デフォルトのアウトバウンド、ルールセットによって決まります。「全般」でもローカルアドレスなどの例外が必ずすべて対象になるとは限りません。厳密に判断する場合は、モード名から推測せず、生成されたルーティング設定を確認してください。

ルールは通常、上から順に照合され、一致すると指定されたアウトバウンドが使われます。まずLANや必要な明示的な例外を置き、次に広い範囲を対象とするルールを配置し、最後にどのルールにも一致しない通信の行き先を確認します。1つのルールにドメイン、ポート、ネットワーク種別を同時に指定した場合、通常はすべての条件を満たす必要があり、どれか1つでよいという意味ではありません。ドメインだけで振り分けるなら、関係のないポート制限を追加しないでください。

以下はXray形式のルーティング設定例です。完全な設定内にdirectとproxyというアウトバウンドが定義されていることを前提とします。1つ目のルールではプライベートアドレスを直接接続し、2つ目では指定したドメインとそのサブドメインをプロキシ経由にします。ドメインは構文の説明用なので、実際に使う際は対象の業務ドメインに置き換えてください。この抜粋にはデフォルトのアウトバウンドも接続認証情報も含まれていないため、単独では起動できません。

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

ドメイン、アドレス、ルールセット

full:は完全一致するドメイン、domain:は指定したドメインとそのサブドメイン、geosite:はドメインのルールセット、geoip:はIPアドレスのルールセットを参照します。通常の文字列をそのまま入力すると、キーワードとして判定され、想定以上に広い範囲に一致することがあります。特定の業務上の例外には完全なドメインを指定し、サブドメインも対象にする必要がある場合に限ってドメイン指定を使うと、関係のないサイトへの誤適用を減らせます。

ドメインルールの判定には、コアが接続先のドメインを把握できる必要があります。アプリがドメイン名をプロキシに送る場合は、そのまま照合できることが一般的です。一方、アプリが先に名前解決し、IPアドレスだけを送る場合は、スニッフィングなどのドメイン対応付けが必要になることがあります。ただし、すべてのプロトコルでドメインを復元できるわけではありません。同じサイトでもアプリによってルールの適用が異なる場合は、まずログに記録された接続先を比べてください。一方はドメイン名、もう一方はIPアドレスだけかもしれません。すぐにルールセットを広げるのは避けましょう。

AsIsは、ルーティング判定のために接続先ドメインを積極的に名前解決しません。ほかのドメイン判定方式では、ルールに一致しない場合やIPアドレスのルールが必要な場合に名前解決することがあります。詳細な動作はコアのドキュメントで確認してください。名前解決で得られるIPアドレスはキャッシュやネットワーク上の位置にも影響されるため、IPアドレスによる判定に変えれば安定するとは限りません。ドメインがわかっているサービスにはドメインルールを使い、対象ネットワークの範囲で処理する必要がある場合に限り、IPアドレスの条件を追加しましょう。

ルールセットのファイルとルール構文は、対応する組み合わせで使う必要があります。クライアントの更新機能で必要なリソースを更新できますが、更新後もログで読み込みが成功したか確認してください。存在しないセット名、読み取れないファイル、選択したコアの誤りは、設定の起動失敗につながることがあります。別のコア向けのルールファイルを、名前だけ変えて使わないでください。ルールセットの更新と基本的な書き方については、GeoIP・GeoSiteルールセットの解説をご覧ください。

確認できる結果で検証する

変更後は設定を再読み込みし、対象サイトを1つ選んで検証します。アクセスログに記録された接続先、適用されたルール、アウトバウンドのタグを確認してください。ブラウザーですでに確立している長時間接続は、以前の経路を使い続けることがあります。対象のタブを閉じるかアプリを再起動してから試してください。1回の検証で変更するルールは1つだけにします。ルールセットの更新、サーバーの切り替え、DNSの変更を同時に行うと、復旧してもどの変更が効いたのか判断できません。

ローカルプリンター、ファイル共有、社内管理画面に接続できない場合は、まず広範囲のプロキシルールより前にプライベートアドレスが直接接続されているか確認し、次に別のプロキシ設定がアプリに適用されていないか調べてください。内部DNSを使う環境では、DNSが社内アドレスを返していることも確認が必要です。ルーティングが正しくても名前解決を誤れば、接続先を間違えます。ルーティングと次章のDNSをあわせて確認しつつ、変更は別々の段階で行う理由もここにあります。

DNS設定の最適化

DNS設定では、誰が問い合わせを行い、どの経路を通り、誰が結果をキャッシュするのかを確認します。システムのリゾルバー、ブラウザーのセキュアDNS、プロキシコア内蔵のリゾルバーが同時に使われることがあります。クライアントのDNSアドレスを変更しても、すべてのアプリがそのアドレスを使うとは限りません。タイムアウト、結果の不一致、社内ドメインの名前解決失敗を調べる際は、DNSサーバーを手当たり次第に追加せず、まず問い合わせ経路を整理しましょう。

名前解決が行われる場所を確認する

ドメイン名をプロキシに送るアプリでは、名前解決をプロキシ経由にできます。先にローカルで名前解決してからIPアドレスへ接続するアプリは、コアに入る前にすでに1回問い合わせを行っています。TUNモードではDNSの取り込みにより、システムの問い合わせがコアに渡されることもあります。ブラウザー独自の暗号化DNSは、さらに別の経路になる場合があります。ブラウザーとコマンドラインで結果が異なるときは、どちらかのDNSサーバーが間違っていると決めつけず、それぞれの設定を確認してください。

まずクライアントの既定のDNS設定を維持し、接続可能なサーバーを使って基準となる状態を確認してから、必要に応じて変更を1つずつ加えてください。たとえば、社内ドメインを組織内のDNSでしか解決できない場合は、その問い合わせ経路を維持する必要があります。一般的なインターネット上の問い合わせには、到達可能なDNSサービスを利用できます。パブリックDNSへの接続条件はネットワークによって異なり、どこでも使える単一のアドレスはありません。目指すのは正しい結果と安定した経路であり、DNS設定の数を増やすことではありません。

以下はXray内蔵DNSの最小限の項目例です。サーバー一覧と結果の種類のみを示しており、DNSの取り込みルールは含みません。また、システムのDNS問い合わせがこのリゾルバーに届くことを保証するものではありません。数値のIPアドレスを使うと、DNSサーバー自身のドメインを解決するための初期問い合わせを避けられますが、問い合わせが直接接続されるかプロキシ経由かは、ルーティングとコアの動作もあわせて確認してください。現在のネットワークで到達可能か検証してから使いましょう。

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

ドメイン別の名前解決と初期名前解決

社内ドメイン、インターネット上のサービス、プロキシサーバーのアドレスには、それぞれ異なる名前解決方法が必要な場合があります。社内ドメインをパブリックDNSに問い合わせても期待した結果が得られないことがあります。また、まだ確立していないプロキシ経由でプロキシサーバーのアドレスを解決しようとすると、起動時に依存関係が発生します。まずサーバーアドレスを解決するための初期経路を確保してから、通常の通信のDNS振り分けを設定してください。ネットワークを切り替えた後は、この起動経路も再確認しましょう。

ドメイン名を使う暗号化DNSサービスでは、サービスのドメイン名に対応するIPアドレスを先に知る必要があります。これが初期名前解決です。初期名前解決にも、まだ利用できない同じサービスを指定すると、処理が循環して待ち続ける可能性があります。クライアントによっては専用の初期設定項目があり、コアやシステムに処理を任せるものもあります。すべてのクライアントに同じ設定項目を適用できるわけではありません。保存後はログを確認し、「DNSサーバーのドメインを解決できない」場合と「対象サービスのドメインを解決できない」場合を見分けてください。対処する場所が異なります。

DNSのルールと通信ルーティングは整合させる必要があります。直接接続するサービスに対して、出口から遠く離れた場所のDNSを使うと、適切でないコンテンツ配信サーバーのアドレスが返ることがあります。プロキシ経由でアクセスするサービスも、名前解決の場所によってサービス側の地域判定が変わる場合があります。必ず速くなるといった決まりはありません。同じサービスで接続の確立、ページ内リソースの読み込み、継続的なアクセスを比較し、1回の問い合わせ時間だけで判断しないでください。

IPv6の設定は実際のネットワーク経路に合わせて判断してください。システムにIPv6アドレスがあるからといって、接続先までのIPv6経路が使えるとは限りません。同様に、IPv6をすべて無効にする方法も万能ではありません。ログに到達不能なアドレスファミリーへの接続が繰り返し記録される場合は、DNS結果の選択方法やアウトバウンドの設定を個別に調整します。システムのルートとネットワークの対応状況を確認し、DNS結果を隠しただけでアプリが別途名前解決して別のアドレスファミリーを選ぶ状態を避けましょう。

キャッシュと原因の切り分け

DNSの結果は、システム、ブラウザー、コアにキャッシュされることがあります。設定を変更したら、対象のアプリとコアを再起動して同じ接続先で再テストしてください。必要であれば、システムのキャッシュ削除機能を使います。コマンドによる名前解決の結果は、そのコマンドが使う経路を示すだけです。ブラウザーやプロキシ経由のリクエストと同じ経路とは限りません。ログと比較する際は、対象ドメインとテスト時刻を記録し、異なる階層のキャッシュ結果を混同しないようにしましょう。

「ドメイン名ではアクセスできないが、IPアドレスなら成功する」という結果はDNSを調べる手がかりにはなりますが、それだけでDNS障害とは断定できません。IPアドレスでHTTPSにアクセスすると、証明書の名前、リクエストのホスト名、サーバー側のルーティングが変わることがあります。こうしたテストを受け付けないサイトも少なくありません。まず名前解決が成功しているか、返された結果が妥当か、接続先ポートに到達できるかを確認し、最後にアプリケーション層のエラーを調べて、エラーの種類も記録しましょう。

ルーティングをIPアドレスで判定する設定に変えると、ローカルの名前解決に依存するようになり、これまで目立たなかったDNSの問題が表面化することがあります。その場合はまず元のドメイン判定に戻し、基本接続を確認してからDNSを個別に修正してください。現象を隠すためにFakeDNSを同時に有効にしないでください。FakeDNSには別途、名前解決の取り込みやマッピングなどの条件が必要です。適用範囲は後の説明をご覧ください。起動や接続に関するその他の問題は、FAQの分類から確認できます。

TUNモードの設定

TUNモードは仮想ネットワークインターフェースとルーティングを使い、より多くのアプリの通信をプロキシに渡します。システムプロキシを参照しないプログラムにも使えます。変わるのは通信を取り込む範囲であり、接続品質が自動的に上がるわけでも、すべての通信が同じ出口を通るわけでもありません。取り込み後の直接接続、プロキシ経由、遮断はルーティングで決まります。有効にする前に通常のプロキシ接続が使えることを確認し、サーバーの障害と通信取り込みの障害を同時に調べる状況を避けてください。

権限、コア、通信の取り込み範囲

v2rayNのメイン画面で「TUNモードを有効にする」をオンにする前に、必要な権限があるか確認してください。Windowsでは管理者権限への昇格、またはクライアントが対応するサービス経由の実行が必要な場合があります。ほかのデスクトップOSでも、ネットワークインターフェースの作成やルーティングの変更に許可が必要なことがあります。現在のインストール方法に合った権限を設定し、毎回高い権限で起動する方法を恒久的な対処にしないでください。ログでインターフェースとルートの作成結果を確認しましょう。

デスクトップクライアントによっては、TUNで通常のプロキシコアとは異なる実行コンポーネントを使うため、設定項目や構造が一致しないことがあります。有効にした後の実行ログと生成された設定を確認し、どのコンポーネントが通信の取り込みとアウトバウンドを担うかを把握してください。XrayのJSON設定を別形式のTUN設定に貼り付けないでください。画面上で切り替えられてもログに未知の項目が表示される場合は、既定のテンプレートに戻し、設定と実行コンポーネントの組み合わせを確認しましょう。

環境通信の取り込み方法優先して確認する項目
v2rayN デスクトップ版クライアントのTUN機能権限、仮想インターフェース、システムルート、DNS
v2rayNG Android版システムVPNサービス接続許可、アプリごとの設定、バックグラウンド制限
v2flyNG Android版システムVPNサービス接続許可、コアの互換性、アプリの選択

Androidクライアントは通常、システムVPNサービスを使ってアプリの通信を取り込みます。初回接続時はシステムの許可を確認してください。アプリごとの設定で対象アプリを含めるか除外するかを決めます。「選択したアプリをプロキシ経由にする」のか「選択したアプリを除外する」のかを確認しましょう。デスクトップ版の「TUNモードを有効にする」を項目ごとに置き換えたものではありません。システムVPNサービスを使う別のツールと同時に動かすと、競合したり接続先が置き換わったりすることもあります。

ループを防いでから振り分けを確認する

TUNを確立した後、プロキシプロセスからサーバーへの通信は、自身の取り込みを迂回できなければなりません。迂回できないと通信がループします。通常、クライアントが関連するルートやプロセスの除外を自動処理しますが、カスタムテンプレート、追加のネットワークアダプター、別のトンネルによって前提が崩れる場合があります。有効にした後にサーバーへ接続できない、ログに同じ試行が繰り返し記録される、すべてのリクエストがタイムアウトする場合は、まずTUNを無効にして基本接続に戻し、出口のルーティングを確認してください。プロキシの対象範囲をむやみに広げないでください。

LANへのアクセスではルーティングと名前解決の両方を確認します。インターネットには接続できるのにプリンターや社内サービスに接続できない場合は、プライベートアドレスが直接接続されているか、社内ドメインに正しいDNSが使われているか、LANのルートがより広い取り込みルールに上書きされていないか確認してください。試しにローカルネットワーク全体をリモートプロキシに送るのは避けましょう。リモートのプライベートネットワークに接続する必要がある場合は、ローカルの同じアドレス範囲と区別し、範囲の重複による接続先の混乱を防いでください。

初回の検証は3段階で行います。まず正常に動作することがわかっているWebページにアクセスし、次にシステムプロキシに従わないアプリを試し、最後にLANと社内ドメインを確認します。同時に、タスクバーのアイコンが変わったかだけで判断せず、実際に通信がクライアントに入っているか確認してください。システムプロキシも有効なままだと、ブラウザーの接続が以前の経路を使っている可能性があります。元の状態を記録したうえで一時的にシステムプロキシを無効にし、TUNだけで通信を取り込めるか確認できます。

UDP、パスMTU、終了後の復元

アプリの通信がTUNに入っても、すべてのプロトコルが現在のサーバーを経由できるとは限りません。音声通話、ゲーム、一部の通信方式ではUDPを使うため、クライアント、コア、サーバー、ネットワーク経路のすべてが対応している必要があります。Webページは表示できるのにリアルタイム通信が失敗する場合は、UDP対応状況とログを確認してください。Webページの結果だけから判断することはできません。アプリによって通信方式が異なるため、検証時は設定をそろえ、プロトコルの違いをルーティングの問題と取り違えないようにしましょう。

一部のサイトで接続は確立するものの、大きなデータの転送中に止まる場合は、パスMTUのほか、パケットロス、プロトコル、サーバー側の問題も考えられます。決まったMTU値をそのまま適用しないでください。まず接続可能とわかっている別のサーバーに切り替え、TUNを無効にした場合と比較して、ログやネットワーク診断で原因を絞り込みます。断片化や経路の問題を示す根拠がある場合に限り、関連パラメーターを調整して元の値も記録しましょう。根拠がなければ、変更によって追跡しにくい変数が増えるだけです。

終了時は先にTUNを無効にし、次にクライアントを終了して、通常のネットワーク接続とシステムDNSが復旧したか確認してください。スリープからの復帰後やネットワーク切り替え後に問題が起きた場合は、すぐに設定を変更するより、通信の取り込みをいったん確立し直すほうが適切なことがあります。復旧しない場合は、残存したインターフェースやルート、別のネットワーク取り込みサービスがないか確認してください。用途がわからない状態でシステムルートをまとめて削除しないでください。組織のネットワークでは、管理ポリシーによってルートが設定されていることがあります。

Androidでバックグラウンド接続が切れる場合は、デスクトップ向けのネットワーク修復コマンドを使うのではなく、バッテリー最適化、バックグラウンド実行制限、アプリごとのプロキシ設定を確認してください。接続の維持と省電力のどちらを優先するかは、利用状況に合わせて選びます。詳しくはv2rayNGのバックグラウンド動作とバッテリー消費の対処法をご覧ください。検証が済んだら安定して使えるモードを1つ選び、複数の通信取り込みツールが起動時に同時実行されないようにしましょう。

FakeDNSのマッピングの仕組み

FakeDNSは、ドメイン名を一時的な合成アドレスに対応付け、接続がコアに届いた後でドメイン名を復元します。ルールで振り分けるために必要なドメイン情報を維持する仕組みです。合成アドレスはリモートサーバーの実アドレスではなく、追加の暗号化プロトコルでもありません。アプリが先にDNSを問い合わせ、その後IPアドレスだけで接続する一方、プロキシ側ではドメイン名によるルール判定が必要な場合に適しています。通常の名前解決とルーティングで問題がなければ、設定項目を増やすためだけに有効にする必要はありません。

DNS問い合わせと接続を一連の流れにする

必要な流れは、アプリがドメイン名を問い合わせる、問い合わせがFakeDNSに渡される、アプリが合成アドレスを受け取る、そのアドレスへ接続する、接続がマッピング情報を保持するコアに戻る、という順序です。どれか1つでも欠けると、「名前解決できたのに接続できない」ことがあります。特に、アプリのDNS問い合わせが取り込みを迂回していないこと、合成アドレスの範囲が直接接続ルールによって先に許可されていないことを確認してください。アドレスプールだけを設定しても、問い合わせ経路がなければ自動的には機能しません。

以下はXray形式の設定項目の抜粋です。合成アドレスプール、DNSサーバーの選択、インバウンドのスニッフィングの関係を示しています。198.18.0.0/15はベンチマーク用に予約されたアドレス範囲であり、インターネット上のサーバーアドレスではありません。この例はIPv4のマッピングのみを示し、インバウンド、アウトバウンド、DNS転送の設定全体は含みません。実際に設定を統合する場所は、現在のクライアントが生成する構造に従ってください。

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

マッピングを復元する対象のインバウンドにも、FakeDNSを認識できるスニッフィング設定が必要です。次のオブジェクトはインバウンド内のsniffing項目の例であり、トップレベルの設定ではありません。これらの項目に対応していない実行コンポーネントや、別の設定形式ではそのまま使えません。まずコアの対応状況を確認し、クライアントが同等の設定をすでに自動生成していないか調べて、手動で重複追加しないようにしてください。

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

アドレスプール、キャッシュ、互換性

ipPoolは割り当て可能な合成アドレスの範囲を定義し、poolSizeはマッピングの容量を設定します。アドレスプールは実際のネットワークやほかのトンネルと重ならないようにしてください。使用中のLANアドレス範囲を安易に代用するのは避けましょう。既定の予約範囲も、必ず競合しないとは限りません。テスト環境やほかのネットワーク製品が同じ範囲を使用する場合があります。競合したら、アドレスの用途とルーティングを確認してください。1つの項目を変えただけで通信経路全体が切り替わったと判断しないでください。

マッピングが有効なのは、対応するコアの動作中に限られます。コアを再起動してもアプリには古い合成アドレスがキャッシュされている一方、新しいコアには対応するドメイン情報が残っていない場合があります。その結果、名前解決は正常に見えても後続の接続に失敗します。モードを切り替えたら、影響を受けるアプリを再起動し、必要に応じてDNSキャッシュを消去してから、新しいドメイン問い合わせでテストしてください。長時間動作するバックグラウンドアプリでは、古いマッピングが残りやすいため注意が必要です。

すべてのアプリが合成アドレスに対応しているわけではありません。アドレスがインターネット上でルーティング可能か独自に確認するプログラム、結果を別のプロセスやデバイスに渡すプログラム、数値アドレスを固定して使うプログラムがあります。前の2種類ではマッピングの一連の流れが崩れることがあり、最後の種類では復元するドメイン名自体がありません。特定のアプリだけで問題が起きる場合は、アドレスプールをむやみに広げるのではなく、そのアプリに通常のDNSを使うか通信の取り込み方法を変更してください。容量を増やしても互換性の問題は解決しません。

ブラウザーが独自に暗号化DNSを使うと、問い合わせがローカルのFakeDNSを通らず、接続に対応するマッピングが適用されない場合があります。反対に、同じ通信の取り込み経路を使っていない別のデバイスに合成結果を共有しても、そのデバイスでは通常利用できません。FakeDNSを有効にした端末の名前解決結果を、一般的なLAN向けDNSサービスとして配布しないでください。合成アドレスを静的なサーバー設定にコピーするのも避けましょう。

ルール、名前解決、復元方法との連携

FakeDNSでドメイン名を復元した後も、ルーティングルールで適切なアウトバウンドを選ぶ必要があります。実際の接続時には、さらに実アドレスを名前解決するか、ドメイン名をリモート側に渡す場合があります。FakeDNSですべての実DNSが不要になるわけではありません。特にプロキシサーバー自身のアドレスには、利用可能な初期名前解決を確保してください。すでに動作中のトンネルでしか解決できない合成結果がサーバーに割り当てられると、起動時に依存関係が発生します。

検証する際はアプリを終了し、マッピングに対応した設定を起動してから、アプリを開いて明確なドメインにアクセスします。問い合わせがFakeDNSに届いているか、接続先がプール内のアドレスになっているか、コアがドメイン名を復元して想定したルールに一致させているかを確認してください。最初の問い合わせが届かなければDNSの取り込みを調べます。合成アドレスが返されても接続が届かなければルーティングを確認します。接続は届くのにドメイン名を復元できない場合は、スニッフィングとマッピングの状態を調べましょう。

元に戻すときは、通常のDNSを復元し、専用の通信取り込み設定を取り消したうえで、合成アドレスを使ったアプリのキャッシュも消去してください。アドレスプールだけを無効にすると、古い合成アドレスへの接続を試し続けるプロセスが残ることがあります。復元後は通常のDNSで基本接続を確認してから、FakeDNSを再度導入するか判断しましょう。有効化前のDNSとルーティングの記録を残しておけば、設定全体を作り直さずにこの2つの層だけを復元できます。

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

複数サブスクリプションを管理する際に重要なのは、提供元を分け、更新を制御し、切り替えを確認できるようにすることです。すべてのサーバーを1つの一覧にまとめることではありません。メイン用、予備用、一時的なテスト用は別々のグループにし、各項目の提供元を追跡できるようにします。購読先が増えたら、まず設定の関係を整理しましょう。日常的に使うグループ、障害時だけ使うグループ、更新で置き換えてよい項目、手動で残す項目を明確にします。

提供元ごとに更新し、用途に合わせて選ぶ

まず提供元ごとに独立したグループを作り、用途と更新方法がわかるメモを付けてください。用途別の分類の代わりに、同じサブスクリプションURLを複数のグループへコピーするのは避けましょう。更新リクエストが増え、重複項目も発生します。同じ提供元を異なる見せ方で管理する必要がある場合は、まずクライアントの絞り込み機能を確認してください。提供元のグループは維持し、用途に応じて検索や対応するフィルターを使うほうが、同じURLを繰り返し登録するより管理しやすくなります。

予備のサブスクリプションを追加したら、まずそのグループだけを更新します。ログで成功を確認し、一覧の内容が妥当か確かめてから実接続をテストしてください。すぐにメインのサーバーを置き換えたり、ほかの提供元もまとめて更新したりしないでください。サブスクリプションの内容が空だったり、新しい設定で起動できなかったりしても、影響範囲を特定しやすくなります。更新失敗や空の結果への対処はクライアントによって異なります。重要な手動設定は別途バックアップし、更新後に必ず保持されると考えないでください。

自動更新の間隔は、提供元が実際に更新される頻度に合わせて設定してください。頻繁にリクエストしても、内容を常に最新に保てるとは限りません。デバイスのスリープ、ネットワークの切り替え、プロキシの未起動によって自動更新に失敗することがあります。問題を調べる際は、自動更新が有効かどうかだけでなく、最後に成功したログを確認してください。プロキシ経由で取得するサブスクリプションでは、どの既存接続に依存するのかも明確にしておきましょう。メインの接続が失敗すると、予備の一覧も更新できない場合があります。

重複の整理と接続先の管理

重複を判断するときは別名だけでなく、接続パラメーターを比較してください。同じアドレスとポートでも、ユーザー識別子、通信経路、サービス名、TLSパラメーターが異なる場合があり、安易に統合できません。クライアントの重複削除機能を使う前に、どの項目を比較するか確認し、復元手段も確保してください。名前が似ているだけのサーバーは、まず提供元ごとに残します。完全に同一だと確認してから整理し、使える予備の設定を誤って削除しないようにしましょう。

サブスクリプションの更新で項目の順序が変わったり、以前の内部識別子が置き換わったりすることがあります。一覧上の位置だけを頼りにサーバーを選ぶと誤操作につながるため、接続前に別名と提供元を確認してください。実接続の測定結果も更新後の項目に対応しなくなる場合があるため、新しい項目を古い結果で並べ替えないでください。メインのサブスクリプションのパラメーターが変更されたら、再テストして接続先に設定し直し、設定を再読み込みしてから実際のアプリで確認しましょう。

予備のサブスクリプションがあっても、自動で障害時に切り替わるわけではありません。通常の接続先選択で使用するアウトバウンドは1つです。対応するヘルスチェック、選択、負荷分散の設定が明示されている場合に限り、ルールに従った切り替えが可能なことがあります。提供元が複数あるから自動で代替されると思い込まないでください。日常利用では、動作確認済みの予備経路を1つ用意し、手動で切り替える手順を明記しておくほうが、複雑な自動化より復旧しやすくなります。

バックアップ、移行、機密情報

バックアップには、サブスクリプショングループ、必要な手動サーバー、ルーティングのカスタム設定、DNS設定を含めてください。クライアントのエクスポート機能に何が含まれるかは、実際に確認が必要です。サーバーの共有リンクだけでは、ルーティングやアプリの設定が含まれない場合があります。バックアップファイルにはサブスクリプションの認証情報やサーバーの鍵が含まれることがあるため、安全に管理してください。別のデバイスへ移行する前に、移行先のクライアントが元のプロトコルと通信方式に対応しているか確認します。ファイルを読み込めたことだけでは互換性を検証したことになりません。

デスクトップ版のv2rayNとAndroid版のv2rayNG、v2flyNGでは、プログラム全体の設定をそのまま上書きして移行しないでください。サーバーの共有形式は交換できる場合がありますが、アプリごとのプロキシ設定、システムプロキシ、TUNによる通信の取り込み、ローカルディレクトリは各環境に依存します。移行時はまずサーバーを読み込み、接続方法とルーティングを移行先のプラットフォームに合わせて設定し直してください。Androidではバックグラウンド動作の設定も再確認し、移行元で安定していた設定をそのまま適用しないようにしましょう。

サブスクリプションURLが使えなくなった場合は、認証期限切れ、URLの変更、一時的なネットワークエラーを区別してください。認証の問題なら提供元から有効なURLを取得し、元のグループ内で置き換えます。ネットワークがタイムアウトする場合は、現在の接続と更新経路を確認してください。無効なURLを自動更新の対象に残し続けるのは避けましょう。URLを変更したら古い記録や認証情報を含むスクリーンショットを削除し、同期メモ、クリップボード履歴、公開された質問記録などに旧URLが残らないようにしてください。

ネットワークを切り替えた後は、すぐにクライアントを再インストールするのではなく、まずメインのサーバー、次に予備の提供元をテストしてください。両方が同じ段階で失敗するなら、ローカルポート、DNS、通信の取り込みに原因がある可能性があります。一方の提供元だけ失敗するなら、その設定を優先して確認します。起動ログに待ち受けアドレスの競合が出た場合は、ローカルポートの競合を特定する方法をご覧ください。関係のない問題を解決するために、すべてのサブスクリプションを削除するのは避けましょう。

カスタムアウトバウンドと設定の検証

アウトバウンドは、コアが接続を次のホップへどう送るかを定義し、ルーティングはタグを使ってアウトバウンドを選択します。直接接続、ブロック、プロキシはそれぞれ異なる出口の動作であり、サブスクリプショングループの違いではありません。通常、クライアントは選択したサーバー用のプロキシアウトバウンドと、補助用のアウトバウンドを生成します。画面上で必要な構成を表現できない場合に限り、カスタム設定を検討してください。日常的なサーバーの切り替えやドメイン例外の追加には、既存のサーバー設定やルーティング画面を優先しましょう。

タグとルーティングからの参照

tagは設定内部で使う参照用の識別子で、ルール内のoutboundTagと一致している必要があります。タグ名自体に特別な意味はありません。directと書いても自動的に直接接続にはならず、実際の動作はプロトコルとパラメーターで決まります。トラブル時はタグの存在と重複の有無、プロトコルが正しいかをあわせて確認してください。名前の不一致でルールが接続先を見つけられない場合、クライアントのログに手がかりが記録されることがあります。

以下はXray用のローカルSOCKS直接接続テスト設定です。インバウンド、ルール、アウトバウンドの対応を理解するための例であり、リモートプロキシへの接続は含みません。起動前に同じ待ち受けポートを使うほかのプロセスを停止し、ローカル端末専用になっていることを確認してください。受け取った通信はすべて直接接続のアウトバウンドに送られます。そのため、リモートサーバーの検証には使えず、既存のサブスクリプションの代わりでもありません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

例では待ち受けアドレスをループバックアドレスに限定し、認証のないローカルプロキシがほかのデバイスから使われないようにしています。すべてのインターフェースで待ち受ける設定に変更すると、アクセス範囲が変わり、同じネットワーク上のデバイスからもポートを利用できる可能性があります。LANで共有する必要がある場合は、アクセス制御、認証、ファイアウォールのルールを個別に設計してください。待ち受けアドレスを変更するだけでは不十分です。ポートが使用可能かどうかも、実際の端末で確認してください。

クライアント生成設定とカスタムファイル

グラフィカル画面で管理するサーバーの実行設定は、通常クライアントによって生成されます。生成された一時ファイルを直接編集しても、再読み込みやサーバー切り替えの際に上書きされることがあります。ルールを長期的に維持するには、クライアントが対応するカスタム設定の項目を使ってください。設定全体をカスタマイズする場合は、通常のサーバー設定から引き継がれなくなる機能を明確にしておきましょう。生成結果と画面上の項目を同時に編集し、両方がずっと同期することを期待しないでください。

プロキシアウトバウンドを作成する場合は、アドレス、ポート、ユーザー認証情報、通信方式、安全性に関するパラメーターを、有効な設定から取得する必要があります。推測で補ってはいけません。同じプロトコル名でも、通信経路、サービス名、証明書に関する設定が同じとは限りません。まず通常のサーバー設定で接続できることを確認してから、カスタム構成への移行を検討しましょう。接続パラメーターの問題と複数アウトバウンド間の参照の問題を分けられるため、原因を絞り込みやすくなります。

アウトバウンドを複数設定しても、自動的に連結されるわけではありません。ルールで予備のアウトバウンドを選択するのは、条件に応じて出口を選ぶ動作です。あるプロキシアウトバウンドから別のアウトバウンドへ接続するのはチェーン接続で、特定のコアが対応する機能と設定項目を必要とします。アウトバウンドの配列を並べ替えるだけでは、両者を置き換えられません。チェーン接続は起動時の依存関係、遅延、障害点を増やします。まず各ホップを個別に検証し、その後に循環参照がないか確認してください。

デフォルトの出口も確認が必要です。ルールに一致しない通信を最初のアウトバウンドに送る設定構造もあれば、実行コンポーネントによっては最終出口を明示するフィールドがあります。新しいアウトバウンドを一覧の前方に追加する前に、ルールに一致しない通信の行き先を確認してください。例でインバウンドのタグに出口を明示しているのは、一覧の位置から推測しないためです。実際に移行する際は、クライアントが生成するルールとカスタムルールの順序を確認し、後方のルールが決して適用されない状態を避けましょう。

段階的なテストと復元用の基準設定

検証は、設定を読み込めるか、ローカルのインバウンドが待ち受けるか、アウトバウンドが接続できるか、最後に通信が正しいルールに一致するかの順で進めます。構文が正しいことは最初の段階の一部をクリアしたにすぎません。未知のフィールド、ルールセットの不足、存在しないタグは起動時にエラーになることがあります。ログにエラーが出たら、元のエラー文と設定内の該当箇所を記録し、曖昧なメッセージだけを頼りに複数のパラメーターを同時に変更しないでください。

ローカルポートには接続できるのにアプリが動作しない場合は、現在のアウトバウンドが実際に選択されているかを確認し、次にDNS、リモート接続、アプリのプロトコルを調べてください。プロキシ経由でテストする場合、テストツール側でも正しいローカルプロトコルとポートを明示する必要があります。HTTPプロキシのポートをSOCKSポートとして使わないでください。クライアントのバージョンや実行モードによって待ち受け構成が変わる場合があるため、古いガイドのポートの組み合わせではなく、ステータスバーと現在の設定を確認しましょう。

一時的にログの詳細度を上げると、アウトバウンドの選択状況を調べやすくなります。ただし、ログには対象ドメイン、サーバーアドレス、利用状況が記録されることがあります。原因を特定したら通常のログレベルに戻し、共有する前に機密情報を削除してください。設定が安定して動作しない場合は、検証済みの標準サーバー、既定のルーティング、基本のDNS設定に戻して接続を確認してから、カスタム設定を1つずつ追加しましょう。バックアップには、最後に編集した結果だけでなく、起動できる基準設定を保存してください。