V2Rayの詳細設定
ルーティング・DNS・TUN

01 / 設定の取得元

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

グループ分けの役割

サブスクリプションのグループ分けは、まず取得元を管理するための機能であり、通信を振り分けるルールではありません。グループには通常、サブスクリプションURL、更新設定、その取得元から生成されたサーバー情報が保存されます。サーバーをグループに移動しても、特定のサイトが自動的にそのサーバーを使うわけではありません。どのアウトバウンドを使うかは、現在の接続設定とルーティングで決まります。この違いを理解しておけば、一覧の整理をネットワークポリシーの設定と取り違えずに済みます。

v2rayNでは、まずサブスクリプショングループの管理画面を開き、用途や取得元が分かる名前を付けてグループを作成し、提供元のサブスクリプションURLを登録します。「普段使い」「予備接続」のように、区別しやすい名前がおすすめです。分かりにくいアルファベットだけの名前は避けましょう。保存したら対象グループを更新し、サーバー一覧に正しく取り込まれたか確認します。メニューの位置は画面によって異なるため、項目名や機能説明を手がかりにしてください。

サブスクリプションURLにはアクセス情報が含まれることが多いため、アカウント情報と同様に扱ってください。スクリーンショットを共有するときはURLやQRコードを隠し、公開ログに完全なURLを貼り付けないようにしましょう。ブラウザーでURLを開けても、返される内容が現在のクライアントに適した形式とは限りません。ログイン画面や案内ページ、形式変換の結果が通常のテキストとしてダウンロードされ、更新完了と表示されても利用可能なサーバーが追加されない場合があります。

サーバーの絞り込み

絞り込み機能は一覧を見やすくしたり、更新後に残す項目を制御したりするために使います。ただし、適用範囲はクライアントによって異なります。表示だけを絞るものもあれば、サブスクリプションの解析時に項目を除外するものもあります。最初はサーバー名の簡単なキーワードで動作を確認しましょう。設定前の一覧を記録し、条件を保存して対象グループを更新した後、絞り込みを解除して結果を見ます。実際の作用を把握してから複雑な条件を組み合わせてください。

入力欄が正規表現に対応している場合は、次のパターンで用途を示す2つの語を含む名前に一致させられます。縦棒は「または」、括弧はグループ化を表します。通常の文字列入力にしか対応していない欄に正規表現を貼り付けても、同じ結果にはなりません。サーバー名は提供元が付けるため、更新によって変わる可能性があります。地域名の略称、倍率表記、プロトコル名にも統一ルールがない場合があるので、条件は広めに設定しましょう。

(普段使い|予備)

入力欄が「一致する項目を残す」設定か「一致する項目を除外する」設定かを、まず確認してください。同じ正規表現でも、モードによって結果は正反対になります。一覧が空になっても、すぐにクライアントを再インストールする必要はありません。絞り込み条件を消し、すべてのグループを選択して検索を解除し、単一の取得元を更新してください。項目が再表示された場合、問題はサーバー接続設定ではなく、表示または絞り込みの段階にあります。

更新と手動編集

サブスクリプションの情報は通常、取得元のデータから再生成されます。アドレス、ポート、通信方式などを直接変更しても、次回の更新で元に戻ることがあります。変更を長期間保持したい場合は、別名を付けて独立した手動設定として複製し、複製した日付と用途も記録してください。こうすれば取得元からの更新を続けながら、サブスクリプション管理の対象外になった設定を判別でき、古い情報で新しい設定を上書きする事態も防げます。

Androidのv2rayNGとv2flyNGでも、取得元ごとにサブスクリプションを管理しましょう。QRコードのインポートは単一の設定に、サブスクリプションのインポートは以後の一括更新に適しています。両者は同じ種類のデータではありません。別の端末から移行する場合は、エクスポートしたものが単一の接続設定、サブスクリプションURL、アプリ設定全体のどれなのか確認してから、対応するインポート機能を選んでください。無関係な形式を何度も試すのは避けましょう。

更新に失敗した場合は、現在使える設定を残したうえで、システム時刻、サブスクリプションの有効期限、更新リクエストに既存のプロキシが必要かを確認します。現在のプロキシ経由で更新できるクライアントもあれば、直接接続で更新するものもあります。まず現在のネットワークで到達できる方法を使って1つのグループを更新し、成功を確認してから自動更新を検討しましょう。未確認の接続1つに、すべての取得元を依存させないでください。

整理が終わったら、サーバーを1つ選んでテスト用の基準にし、自動切り替えや複雑な絞り込みは一旦無効にします。まず通常のシステムプロキシで接続できることを確認してから、ルーティングとDNSの設定に進みましょう。「設定をどこから取得するか」を管理する作業と、「接続設定が使えるか」を確認する作業は別々に記録してください。後のトラブルの範囲を絞りやすくなります。

03 / ドメイン名の解決

DNS設定の最適化

名前解決の経路

DNS設定では、まず経路の一貫性を整え、その後に応答速度を検討します。アクセス時には、システムのリゾルバー、ブラウザー内蔵の暗号化DNS、クライアントのDNS、リモートサーバーでの名前解決などが関わることがあります。どこから問い合わせが送られ、どの経路を通り、結果を誰が使うのかを把握して初めて、設定変更の効果を判断できます。DNSサーバーのアドレスを1つ変更するだけでは、名前解決の経路全体は制御できません。

システムプロキシが主に転送するのは、プロキシ設定に従うアプリの通信であり、システムDNSまで必ず取り込むわけではありません。ブラウザーがドメイン名をプロキシへ直接渡す場合もあれば、先に自身で名前解決する場合もあります。他のプログラムが固定のDNSアドレスへ直接アクセスすることもあります。そのため、クライアントにDNSを設定しても、端末上のすべての問い合わせがそのDNSを使うとは限りません。ブラウザー、システムのネットワーク設定、クライアントの通信取り込み範囲を個別に確認してください。

リモートでの名前解決と直接接続での名前解決は、ルーティングの目的に合わせて使い分けます。直接接続するリソースには現在のネットワークから到達できるリゾルバーが適しています。プロキシを使うリソースでは、問い合わせが想定した経路で届くことを確認してください。暗号化DNSサーバーをドメイン名で指定する場合は、そのサーバー自体の名前解決も必要です。これをブートストラップDNSと呼びます。ブートストラップの経路を誤ると、「リゾルバー自身の名前解決を、そのリゾルバーに依存する」という問題が起こります。

コアのDNS設定例

以下はメイン設定の一部にあたるdnsオブジェクトです。中国本土のドメインは指定したサーバーを優先し、それ以外の問い合わせにはDoHアドレスを使用します。これはドメインごとにリゾルバーを割り当てる構成を示す例であり、すべてのネットワークに適するとは限りません。DoHリクエストがどのアウトバウンドを使うかは、実際のコアと設定によって異なります。アドレスの接頭辞だけでプロキシ経由と決めつけず、ルーティングとログを確認してください。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

domainsでは、そのサーバーが優先的に処理するドメインの範囲を指定します。ただし、問い合わせに失敗した後の動作は、フォールバック設定やコアの実装にも左右されます。厳密なネットワーク分離のルールと捉えないでください。特定の問い合わせが他のリゾルバーへ絶対に送られないようにするには、使用中のコアが対応するフォールバック項目、失敗時の動作、実際のネットワーク経路を確認してから設計します。この例だけを残しても実現できません。

queryStrategyはここではコアのDNS問い合わせ方式を指定します。OSのIPv6を無効にしたり、すべてのアプリが別のレコードを個別に問い合わせるのを防いだりするものではありません。IPv4を選ぶとデュアルスタックの問題を切り分けやすくなりますが、一般的な高速化スイッチではありません。現在のネットワークとサーバーがIPv6を正しく処理できる場合は、個別に検証してから設定を残すか判断してください。関連する問題を恒久的に隠すのは避けましょう。

キャッシュと段階的な検証

DNS設定を変更しても、以前の結果がシステム、ブラウザー、アプリ、コアのキャッシュに残っていることがあります。まず対象アプリを終了してクライアントを再起動し、OSの手順に従ってキャッシュを更新してください。同じドメインを使って結果と実際の接続先アドレスを比較します。ページを一度再読み込みしただけで新しい設定が有効になったと判断しないでください。ページのリソースがローカルキャッシュから読み込まれたり、古い接続が再利用されたりすることがあります。

「IPアドレスではアクセスできるが、ドメイン名では開けない」場合は、まずDNSを確認します。「ドメイン名は解決できるが、接続できない」場合は、ルーティングとリモート接続を調べてください。名前解決が成功しても、得られた結果が現在のネットワーク経路に適しているとは限りません。リゾルバーの場所に応じて接続先アドレスを変えるサービスもあります。直接接続で得た結果をリモートアウトバウンドに渡すと、遠回りになったり接続に失敗したりすることがあります。

ブラウザーだけで問題が起きる場合は、一時的にブラウザー独自のセキュアDNSを無効にし、システム設定に従う状態に戻して比較します。特定のアプリだけで問題が起きる場合は、独自の名前解決を使っていないか、固定アドレスに接続していないかを確認してください。テスト後に最終的な設定を決めましょう。一時的に無効にするのは問題の範囲を絞るためであり、すべてのネットワークに同じ名前解決方式を推奨するものではありません。

クライアントの「リモートDNS」「直接接続DNS」などのフォーム項目は、設定生成時に複数のコアオブジェクトへ変換されることがあります。まず同じフォームを使って設定し、カスタムJSONに反対の設定を重ねて記述しないでください。手動で拡張する場合は、最終的に生成されたファイルを確認し、オブジェクトの重複や上書きの関係を把握してから、有効だった変更を独立した変更記録に残しましょう。

05 / ドメイン名のマッピング

FakeDNS

仮想アドレスと元のドメイン名

FakeDNSは、ドメイン名に対してアドレスプール内の仮想アドレスを返し、アドレスとドメイン名の対応を内部に保存します。その後、アプリが仮想アドレスへ接続すると、連携する通信の入口が元のドメイン名を復元し、ルーティングとアウトバウンドに渡します。これは公開リゾルバーではなく、接続先のWebサイトに新しいアドレスを割り当てる仕組みでもありません。ドメイン名の情報を保ち、ローカルでの実際の名前解決が後続の振り分け判定に与える影響を抑えることが利点です。

この仕組みを機能させるには、名前解決と接続が同じ管理下の経路を通る必要があります。DNS問い合わせだけがFakeDNSに届き、その後の接続がクライアントを迂回すると、アプリは実際のサーバーではないアドレスへ直接接続しようとします。反対に、接続が通信の入口に届いても、問い合わせをブラウザー独自の暗号化DNSが処理していると、クライアント側にマッピングが作られず、ドメイン名を想定どおりに復元できないことがあります。

そのため、FakeDNSを通常のDNSアドレスとしてシステムに設定しないでください。まずクライアントと通信の入口コンポーネントが対象のモードに明示的に対応していることを確認し、同じ実装に合わせてDNSの取り込み、アドレスプールのルーティング、マッピングの復元を設定します。v2rayNが制御するTUNコンポーネントは独自の仮想アドレス機能を使う場合があります。機能名が似ているからといって、コアのFakeDNSを併用しないでください。

Xrayの部分設定

以下はXrayで関連する3つの階層を示した例です。トップレベルのアドレスプール、DNSサーバー一覧、対象の通信入口に統合するスニッフィング設定を含みます。アドレスプールには予約済みのベンチマーク用アドレス帯を使用しており、インターネット上の接続先アドレスではありません。この例だけでは透過型の通信入口もシステムルートも作成されません。必要な関連設定がない状態でコピーしても、端末全体が自動的にFakeDNSを利用することはありません。

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

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

ipPoolは仮想アドレスの範囲を定義し、poolSizeはマッピングプールの容量を指定します。プール内のアドレスは識別用であり、実際の接続先として直接接続のアウトバウンドに渡してはいけません。設定前に、既存のLAN、他のトンネル、テスト用ネットワークが同じ範囲を使用していないか確認してください。アドレス範囲が競合すると、一部の接続が物理インターフェースや別の仮想インターフェースへ誤って送られることがあります。

destOverrideのfakednsは、マッピングを使って宛先を復元するための設定です。この例ではrouteOnly: falseを明示しています。ルーティング判定だけに使い、実際の接続先として仮想アドレスを残す設定では、例の目的を満たせません。通常のHTTPやTLSのスニッフィングとFakeDNSのマッピングは別の仕組みです。項目名が似ているからといって置き換えないでください。

互換性とトラブルシューティング

有効にした後、まず通常のドメイン1つを名前解決し、結果が設定したプールの範囲内にあるか確認します。次に接続時にドメイン名へ正しく復元されるか確認してください。結果が実際のパブリックアドレスのままなら、問い合わせが対象のDNS経路に取り込まれているか調べます。仮想アドレスが返されても接続に失敗する場合は、そのアドレス宛ての通信が連携する通信の入口に戻るか、入口が同じマッピング状態を使っているかを優先して確認します。

ローカルでアドレスの種類を検査して予約済みアドレスを拒否するプログラムや、名前解決結果を別の端末へ渡すプログラムでは、FakeDNSが適さない場合があります。LAN内のデバイス検出、実際のアドレスを必要とするサービス、特定のネットワーク診断ツールでは、クライアントが対応する方法で通常のDNSを使う例外を設定してください。例外は名前解決とルーティングの両方に反映する必要があります。仮想アドレスの範囲を直接接続に指定するだけでは解決しません。

再起動後も、システムやアプリに古い仮想アドレスがキャッシュされている一方、新しいプロセスのマッピングテーブルは更新されていることがあります。その結果、「有効にした直後は使えたが、再起動後に一部だけ失敗する」という状態になることがあります。まず関連するキャッシュを消去して対象アプリを再起動し、その後に設定の誤りを判断してください。古い仮想アドレスを長期間使うhosts設定に登録したり、サービスの固定接続先として保存したりしないでください。

通常のDNSとドメイン名のスニッフィングで振り分けの要件を満たせるなら、設定項目を増やすためだけにFakeDNSを有効にする必要はありません。FakeDNSはドメイン名を保持する必要がある場合に役立つ機能であり、すべてのネットワークで使う標準的な最適化ではありません。まず1つのアプリで効果と互換性を確認し、すぐに復旧できる設定のコピーを残してから、少しずつ適用範囲を広げましょう。

07 / アウトバウンドの構成

カスタムアウトバウンド

タグとプロトコルオブジェクト

アウトバウンドは、受け取った通信の次の接続をどのように確立するかを定義します。ルーティング内のoutboundTagは参照先を示すだけであり、実際のアウトバウンドオブジェクトに対応するtagが必要です。タグは大文字と小文字を区別するため、用途が分かる短い名前を付けましょう。存在しないタグを指定するルールを作っても、クライアントが接続を自動生成することはありません。起動時の検査や実際の転送時にエラーが発生する可能性があります。

クライアントが生成するアウトバウンドと、手動で追加するアウトバウンドを区別してください。v2rayNは通常、選択中のサーバーに応じてリモート接続オブジェクトを生成するため、サーバーを切り替えるとオブジェクトが再作成される場合があります。一時ファイルを直接編集すると、再起動時に変更が失われることがあります。クライアントが明示的に提供するカスタム設定の入力欄を使い、その設定がメイン設定に統合されるのか、置き換えるのか、完全に引き継ぐのか確認してください。

以下は独立した部分例です。直接接続、通信の破棄、ローカルの別のSOCKSサービスへの転送を示します。リモートサーバーの認証情報は含みません。指定したアドレスでローカルサービスが実際に待ち受けており、現在の通信の入口と同一ではないことが前提です。コピーする前に待ち受けポートを確認してください。同じ処理チェーンへ通信を戻すとループが発生する可能性があります。

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

freedomは、コアが置かれているネットワークから直接接続することを示します。この端末上の他のすべてのネットワークツールを迂回するという意味ではありません。システムのデフォルトルートが別のトンネルを指していれば、直接接続のアウトバウンドもそのトンネルを経由することがあります。実際の出口を判断するには、OSのルーティングとクライアントのログをあわせて確認してください。タグがdirectだからといって、物理ネットワークを使うとは限りません。

blackholeは、一致した通信を破棄します。接続が不要な宛先を明確に遮断するのに適していますが、設定ミスがあった場合の既定の対処として使うべきではありません。特定のサービスに問題があるときは、まず遮断ルールに誤って一致していないか確認してから、条件の範囲を調整します。リクエストが応答なしで破棄されると長時間待たされることがあるため、トラブルシューティングでは遮断ルールを個別に確認してください。

ルールへの組み込みとデフォルトの出口

次のルールは、ドキュメント用の例示ドメインをローカルのSOCKSアウトバウンドへ転送します。広範囲のフォールバックルールより前に追加してください。例示ドメインは構文の説明用なので、実際に使うときは対象のサービスに合わせて変更します。対象サービスの範囲を広げる場合も、実際のリクエストを確認して必要なドメインを指定してください。すべてのポートをローカルサービスに渡すと、関係のないアプリの出口まで変わってしまいます。

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

どのルールにも一致しない場合、コアは通常デフォルトのアウトバウンドを使用します。一般的な設定では、アウトバウンド配列の先頭項目が関係します。上の例では先頭が直接接続なので、既存の設定にそのまま置き換えても、未一致の通信がプロキシを使うとは限りません。既存のリモート接続オブジェクトを残してフォールバック方針を明示するか、配列の順序を確認し、最終的な動作が想定どおりになるようにしてください。

連鎖接続の注意点

ローカルサービスへの転送と、コア内部の連鎖接続は異なる設定方法です。前者は別の待ち受けポートに接続し、そのサービスに後続の処理を任せます。後者は使用するコアが対応するアウトバウンドの組み合わせ項目に依存します。コアによって項目と作用する階層が異なるため、ある実装の通信設定を別の実装へコピーしないでください。クライアントが明示的に対応し、動作を確認しやすい方法を選びましょう。

転送を1段追加したら、それぞれの区間を個別に確認します。まずローカルのSOCKSサービスが単独で動作することを確認し、次にコアからそのポートへ接続できるか、最後にルールが一致するかをテストします。最初の区間は正常でも連鎖全体が失敗する場合は、名前解決の位置、UDP対応、追加のカプセル化が必要かを確認してください。両端の設定を同時に変更すると、どの変更が結果に影響したか分からなくなります。

カスタムアウトバウンドが安定したら、用途、タグの対応関係、復旧方法を記録します。機密性の高い接続情報は、保護されたクライアント設定に保存し、通常のメンテナンス文書にはコピーしないでください。日常的な調整は必要なルールだけにとどめ、サブスクリプションを切り替えるたびにアウトバウンド全体を書き直さないようにしましょう。取得元の管理と出口の構成を分ければ、更新と復旧を制御しやすくなります。