V2Ray 高度な設定ガイド

サブスクリプションのグループ分けとサーバーフィルター

サブスクリプションをグループ分けする主な目的は、取得元を分けて管理することです。接続プロトコルを変える機能ではありません。取得元ごとにグループを作ると、更新対象、項目の所属、無効化する範囲を明確にできます。v2rayNでは通常、「サブスクリプショングループ」に関連する画面で名前とURLを登録します。v2rayNGとv2flyNGでは、サブスクリプション設定から取得元を管理します。メニュー名はクライアントによって異なりますが、取得元を登録し、対象を更新して、取り込み結果を確認する流れは共通です。

取得元ごとにグループを作り、表示範囲を決める

グループ名には「普段使い」「予備」「手動設定」など、用途が分かる名前を付けてください。認証情報、サブスクリプションURL、請求情報を名前に含めないでください。似た項目が複数の取得元にあっても、グループは分けておきます。取得元の更新が止まったとき、混在した一覧を調べずに該当グループだけを無効化できます。手動で追加した項目は専用のグループに分け、サブスクリプションから取得した項目と混在させないのがおすすめです。

サブスクリプションURLを入力するときは、クエリパラメーターを含むURL全体をそのまま使ってください。URL内のトークンでアカウントを識別するサブスクリプションもあり、疑問符以降を削除すると更新に失敗することがあります。QRコードやクリップボードから取り込む場合は、前後の空白や改行、全角の記号にも注意してください。認証情報を含むURLを公開の変換サービスに送信しないでください。形式の変換には、信頼できるローカル環境を優先してください。具体的な形式はサブスクリプションURLの形式解説をご覧ください。

フィルターが適用される段階を確認する

「検索」「表示フィルター」「取り込みフィルター」は、それぞれ異なる機能です。検索は通常、一覧の表示を絞り込むだけで、サーバーを削除しません。取り込みフィルターは条件に合わない項目を現在のグループに取り込まない場合があります。削除はローカルの項目一覧そのものを変更します。設定前に説明を読み、次回のサブスクリプション更新にも影響するか確認してください。判断できない場合は、取り込み設定に複雑な条件を書くのではなく、まず一覧検索を使ってください。

現在のクライアントが正規表現に対応している場合は、シンプルで範囲の明確なルールで名前を絞り込めます。まず少数の項目で試し、その後に取得元全体へ適用してください。サブスクリプションの項目名は提供元が決めるため、接頭辞や空白、異なる言語が含まれることがあります。名前の一致は、地理的な位置の判定とは異なります。フィルター結果が空になった場合は、フィルターを解除して再更新し、元のサブスクリプションに項目があるか確認してください。そのうえで、大文字・小文字、区切り文字、正規表現の構文を確認します。

^(日常|予備)-
^(?!.*テスト).*$

上の2行は、互いに独立した正規表現の例です。1行目は「日常-」または「予備-」で始まる名前に一致します。2行目は「テスト」を含む項目を除外します。正規表現に対応していると明記された欄だけで使用してください。通常の検索欄では、これらの記号が正規表現として解釈されない場合があります。名前のフィルターは一覧管理用であり、プロトコルの互換性、サーバーの稼働状況、想定どおりの通信経路を保証するものではありません。

更新後に項目の変化を確認する

指定したグループを更新したら、まずプロトコル、アドレス、ポート、転送方式が正しく読み込まれたか確認してください。項目数の変化は、取得元の変更、フィルター設定、形式の認識結果による可能性があり、クライアントが設定を失ったとは限りません。グループ全体が消えた、または空になった場合は、更新結果と解析エラーを確認してから、以前のフィルター条件に戻してください。形式の非互換性は、更新ボタンを何度押しても解決しません。取得元側のリクエスト制限にかかるおそれもあります。

長期的な修正のために、サブスクリプションから取り込んだ項目の名前や転送パラメーターを手動で変更するのは避けてください。次回更新で変更が上書きされたり、項目が再生成されたりする場合があります。一時的な修正が必要なら、項目を手動管理のグループにコピーし、用途を明記して、元の項目との差分を記録してください。サブスクリプションから取得した元の項目はそのままにしておくと、原因が取得元データかローカルの変更かを判断しやすくなります。

グループを切り替えても、使用中のサーバーが切り替わるとは限りません。更新後は、現在選択されている項目を確認してください。元の項目が削除または再生成された場合は特に注意が必要です。モバイル端末では、変更を読み込むためにサービスの再起動が必要なこともあります。一覧のハイライト表示だけで判断せず、起動ログに記録された接続先とアウトバウンドを確認してください。一覧の整理が済んでからルーティングを設定すると、取得元の管理上の問題を通信経路の不具合と誤認しにくくなります。

DNS 設定と名前解決の経路

DNSの問題は、誰がクエリを送るのか、誰が処理するのか、どの経路で上流DNSへ届くのかの3点に分けて考えます。ブラウザー、OS、プロキシコア、TUNの通信取り込みコンポーネントが名前解決を処理する場合があります。クライアントのDNSアドレスを変更しても、すべてのアプリがすぐにそのアドレスを使うとは限りません。アプリ独自の暗号化DNS、システムキャッシュ、既存の接続も、確認結果に影響します。

内蔵DNSの役割を確認する

プロキシコアの内蔵DNSは通常、内部の名前解決、ルーティング判定、特定のアウトバウンド処理に使われます。システムの既定リゾルバーに自動的に切り替わるとは限りません。システムプロキシモードでは、アプリによってOSが先に名前解決してIPをプロキシへ渡す場合と、ドメイン名をプロキシの入口へ渡す場合があります。DNSの処理経路はこの2つで異なります。システムのDNSクエリを取り込むには、通常、TUN側でのDNSリダイレクトや対応するシステム設定も必要です。

v2rayNのDNS画面は、使用するコアによって設定方法が異なる場合があります。v2rayNGのリモートDNS、ローカルDNS、関連するルーティング設定も、現在のモードに合わせて解釈してください。「リモート」という名称だけで、通信が必ずプロキシ経由になると判断しないでください。まずクライアントの既定設定を保ち、通常の接続が動作することを確認してから、上流DNSのアドレスやドメイン別の振り分けを調整します。DNS設定を全面的に置き換える前に、既存ルールと予備リゾルバーの役割を記録してください。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

これはXray形式のDNS設定を既存構成にマージする例です。ドメイン分類に応じた問い合わせ先とフォールバック用リゾルバーを示していますが、すべてのネットワークに適しているとは限りません。domainsは該当するドメインの問い合わせ先を選び、skipFallbackはそのサーバーをほかのドメインの通常のフォールバックに使わないようにします。選択されたドメインがほかのサーバーを一切試さないという意味ではありません。実際のフォールバック動作は、ほかの設定項目にも左右されます。上流DNSへの接続可否と接続経路は、実際の設定で確認してください。

暗号化DNSとブートストラップ名前解決

ドメイン名で指定する暗号化DNSを使う場合、クライアントは暗号化接続を確立する前にDNSサーバーのアドレスを知る必要があります。これがブートストラップ名前解決の問題です。ブートストラップの名前解決まで、まだ接続できていない同じDNSサービスに依存すると、循環が発生します。到達可能な経路を明示するか、現在のコアが対応する静的マッピングを使用してください。通常のDNSアドレスを暗号化DNSに置き換えただけで、名前解決の経路全体が完成したと考えないでください。

リモートプロキシサーバーのドメイン名も、この経路に含まれます。サーバーの名前解決にプロキシが必要なのに、そのプロキシもサーバーへの接続を必要とする場合、起動時の名前解決で停止します。トラブル時は、サービスの起動前にサーバーのドメイン名を解決できるか確認し、上流への接続が自分自身に戻っていないかを調べてください。暗号化DNSはクエリの転送を保護しますが、ルーティング、サーバー証明書、システム時刻の誤りを自動で修正するものではありません。

IPv4・IPv6とキャッシュの影響

UseIPは、2種類のアドレス結果を利用可能にしますが、システムでIPv6が正常に通信できることを保証しません。ネットワークからIPv6アドレスが返っても、外向きの通信ができない場合、接続に失敗してからIPv4へ切り替わるため、初回アクセスが遅くなることがあります。まずIPv4とIPv6の実際の経路を比較し、IPv4だけを使う名前解決方式にするか判断してください。特定のクエリ種別を無効にしても、アプリ独自の名前解決やIPアドレスへの直接接続まで制御できるわけではありません。

DNSの検証でシステムの問い合わせツールを使っても、分かるのはOSが使用したリゾルバーの結果だけです。プロキシコアの内蔵DNSが正常に動作している証拠とは限りません。クライアントのログとアプリの接続記録も確認してください。変更後はOS、ブラウザー、コアのキャッシュを考慮する必要があります。上流DNSを何度も変えるより、テスト対象ごとにキャッシュを消去するか再起動するほうが、原因を判断しやすくなります。キャッシュが残っている間は、一度アクセスに成功しても新しいリゾルバーが使われたとは限りません。

ドメインを名前解決できてもアクセスできない場合は、返されたIPアドレスとルーティング先のアウトバウンドが一致しているか確認してください。DNSの確認だけで終わらせないでください。LAN内の短いホスト名だけが使えない場合は、検索ドメインとローカルDNSサービスが通信取り込みの対象になっているか確認します。社内ドメイン、プリンター名、家庭内ネットワーク機器はローカルDNSに依存する場合があります。すべてをパブリックDNSに渡すのではなく、ローカルDNSを使う対象を明示的に設定してください。

FakeDNSとドメインのマッピング

FakeDNSは問い合わせたドメインに合成IPアドレスを割り当て、ドメインとアドレスの対応を内部で管理します。アプリがそのアドレスに接続すると、通信取り込みコンポーネントが元のドメインを復元し、ドメイン別ルーティングやプロキシ経由の名前解決に利用できます。合成アドレスは接続先サーバーの実IPアドレスでも、新しいリモートサーバーでもありません。アプリが先に実IPアドレスを取得し、ドメイン情報が失われる状況を減らし、ドメインの情報を保つことが目的です。

有効化にはマッピング経路全体の連携が必要

FakeDNSを使うには、少なくとも3つの処理が連携する必要があります。問い合わせが指定のリゾルバーへ届くこと、合成アドレスへの接続が同じ通信取り込み経路に捕捉されること、接続処理時にドメインを復元できることです。DNSサーバー一覧に名前を追加しただけで対応する通信を取り込まない場合、アプリは合成IPを通常のゲートウェイへ直接送る可能性があります。逆に、スニッフィングを設定しただけでは、システムのDNSクエリが自動的にFakeDNSへ送られるわけではありません。

まず、合成アドレスの処理をどのコンポーネントが担うか決めてください。v2rayNのTUN通信取り込みコンポーネントに独自のFake IP機能がある場合、XrayのFakeDNSをむやみに重ねて有効にしないでください。2つのコンポーネントが別々にアドレスを割り当ててキャッシュを管理すると、ドメインの復元時に対応するマッピングが見つからないことがあります。v2rayNGとv2flyNGでは設定画面や対応範囲も異なります。現在のコアとクライアントの機能を確認し、設定名が似ているだけで同じ実装だと判断しないでください。

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

これはXray形式の機能設定例で、DNSの通信取り込みを含む完全な設定ではありません。アドレスプールにはテスト専用の範囲を使用していますが、現在の環境で競合しないという意味ではありません。LAN、社内ネットワーク、ほかの仮想インターフェースがすでにその範囲を使っている場合は、先に設定を変更してください。アドレスプールのサイズはマッピングの容量を決めるもので、同時接続数の上限とは異なります。容量を増やしても、問い合わせの取り込みやマッピング復元ができない問題は解決しません。

インバウンドでの復元とスニッフィングの適用範囲

Xrayが対象の通信を直接処理する構成では、関連するインバウンドでもFakeDNSに対応する復元機能を有効にする必要があります。設定するのは、合成アドレスへの接続を受け取るインバウンドです。任意の待ち受け入口を選ぶのではありません。以下は一般的なスニッフィング設定例です。実際のインバウンド構成に合わせて使用してください。上流の通信取り込みコンポーネントがすでにドメインを復元する場合は、そのコンポーネントの設定方法に従ってください。

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

通常のHTTPやTLSのスニッフィングと、FakeDNSのマッピング情報は別の情報源です。前者はアプリのプロトコルからドメインを取得しようとし、後者は事前のDNS問い合わせ記録に依存します。一部のプロトコル、暗号化ハンドシェイク、IPアドレスへの直接接続では、利用可能なドメイン情報を取得できません。スニッフィングですべての接続先名を必ず復元できるとは限りません。ルーティングだけに適用するのか、接続先アドレスも置き換えるのかは、現在使用しているコアの設定項目を確認してください。

キャッシュ、切り替え、互換性への対処

有効化後は、キャッシュされていないドメインを1つ問い合わせ、アプリが合成アドレスを受け取ることと、接続時にそのドメインが復元されることを確認してください。サービスの停止後や通信取り込みコンポーネントの変更後も、アプリが古い合成IPをキャッシュしている場合があります。新しいサービスに対応するマッピングがないと、一部のサイトに突然接続できなくなることがあります。その場合は、DNSキャッシュを消去してアプリを再起動してください。アドレスプールを広げたり、リモートサーバーを繰り返し変更したりしないでください。

LAN内のサービス検出、名前解決結果のアドレスを検査するプログラム、実IPアドレスが必要な診断ツールは、合成アドレスに適さない場合があります。こうした対象には、実アドレスを返す明示的な例外を優先し、DNSと接続経路の両方に例外が適用されることを確認してください。ブラウザー内蔵の暗号化DNSが通信取り込み用リゾルバーを迂回すると、同じアプリのリクエストでも経路が分かれることがあります。トラブルの切り分けでは、その設定状態も記録してください。

有効化による効果がはっきりしない場合は、通常の名前解決を使うほうが管理しやすくなります。元に戻すときは、通信の取り込みを停止し、DNS設定を復元し、キャッシュを消去してアプリを再起動した後、直接接続とプロキシ接続の対象を確認してください。FakeDNSの項目だけを削除し、システムに古い合成アドレスを残さないでください。信頼できる比較結果を得るには、設定とキャッシュの両方を復元する必要があります。

カスタムアウトバウンドと設定の切り戻し

アウトバウンドは、通信がプロキシコアから最終的にどのように送信されるかを定義し、ルーティングはタグを使ってアウトバウンドを指定します。直接接続、プロキシ、遮断のほか、ローカルで動作中の別のプロキシ入口へ接続する用途もあります。カスタムアウトバウンドは明確な経路要件がある場合に使うもので、通常のサーバー項目をインポートする代わりにはなりません。作業前に、各タグがどのサービスに対応し、どこで待ち受けているか、そのサービスを停止したらどうなるかを確認してください。

タグは設定内の参照関係を表す

tagは手動で指定する識別子であり、プロトコル機能を自動的に作るものではありません。ルーティングでproxyを指定するなら、設定にも同じ名前のアウトバウンドが必要です。名前が似ているだけでは一致したことになりません。ネイティブのXray設定では、最初のアウトバウンドがルールに一致しない通信の既定経路になることが多く、アウトバウンドの順序にも意味があります。クライアントが設定を生成する場合は、既定ルールが追加されることがあります。確認時は、編集欄の一部だけでなく、実際に動作している設定全体を見てください。

以下は、ローカルの通信経路をテストするための完全なXray形式の設定例です。ローカルのアプリがSOCKSインバウンドに接続し、通常の接続先はローカルの別のSOCKSサービスへ転送し、プライベートアドレスは直接接続します。リモートサーバーの認証情報は含みません。参照先のサービスが指定されたポートで実際に動作していることが前提です。上流サービスから現在のインバウンドへ戻す設定にすると、転送ループが発生します。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10810,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10809
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールの確認前にプロトコルとポートを確認する

使用前に、10810が未使用であることと、10809がSOCKSサービスを提供していることを確認してください。HTTPプロキシのポートを「プロキシ用のポート」という理由だけでSOCKSアウトバウンドに指定してはいけません。ここで使用するポートはテスト用の値で、クライアントの既定値ではありません。認証なしの入口を誤ってLANに公開しないよう、待ち受けアドレスはローカルのループバックに限定しています。リモートからアクセスする場合は、認証、ファイアウォール、アクセス範囲を別途設計してください。

この例ではインバウンドのUDPを無効にしており、TCP経路の確認だけを目的としています。同じ設定ですべてのUDPアプリを利用できるとは限りません。UDPを有効にする場合は、インバウンド、上流のSOCKSサービス、その先の経路が対応しているかを確認してください。直接接続用や遮断用のアウトバウンドは、定義しただけでは使われません。ルールに一致するか、既定経路に設定された場合にのみ適用されます。blockという名前のアウトバウンドを追加しても、自動的に通信が遮断されるわけではありません。

カスタム設定を取り込む際の注意点

v2rayNでカスタム設定を読み込む場合は、ファイルの構文に合ったコアを選択し、クライアントがローカルの待ち受けポートをどのように認識するか確認してください。管理画面の一部の設定はこのファイルに反映されず、システムプロキシが古いポートを参照し続けることもあります。モバイル版の設定取り込み機能はデスクトップ版と異なります。現在のクライアントが対応している形式を使用してください。ファイルを保存できることと、サービスが想定どおりに起動することは別です。

複数のプロキシを連結すると、依存関係とトラブル対応の負担が増えます。まず上流と下流をそれぞれ単独で検証してから接続し、どの段階でもう一方の出口通信が再び取り込まれていないか確認してください。一部のドメインだけ別の経路に振り分けたい場合は、分かりやすいルーティングと専用アウトバウンドを優先し、分類のためだけに不要なプロキシ層を増やさないでください。プロトコルの選択については主なプロトコルの違いも参考になりますが、実際に使える機能は通信経路によって決まります。

追加した順序と逆の順に切り戻す

起動に失敗したら、最初に記録された明確なエラーを確認してください。JSON構文エラー、未対応の項目、ポートの競合、アウトバウンド参照の不足は、それぞれ別に対処する必要があります。起動しても接続できない場合は、上流サービスの待ち受け状態、プロトコルの一致、既定のアウトバウンドを確認します。ログの詳細度を一時的に上げた後は、必要なリクエストだけを再現し、調査が終わったら通常の設定に戻してください。アクセス先が記録されたログを保存し続けないようにします。

切り戻すときは、追加した通信取り込み設定とカスタム項目を停止し、元のルーティングとDNSを復元してから、接続確認済みのサーバーを選び直して接続してください。システムプロキシのポートを変更した場合は、こちらも元に戻します。今回の変更を「目的、変更内容、検証、切り戻し」の4点で記録すると、出所が不明な大きな設定を保存するより管理しやすくなります。初回設定はクイックスタートガイドを参照し、具体的な症状はトラブルシューティングで引き続き確認してください。