V2Ray 詳細設定ガイド

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

サブスクリプションURLと接続設定を分けて管理する

v2rayN の「サブスクリプショングループ設定」を開き、まず専用のグループを作成してからサブスクリプションURLを登録します。グループには更新元、メモ、絞り込み条件を設定し、サーバー項目にはインポート後のプロトコル設定が保存されます。グループのメモを変更しても、リモートの接続情報は変わりません。サブスクリプションを更新しても、現在のサーバーが切り替わるわけではありません。更新後は、メイン画面で選択されている項目を確認してください。

グループ名には「普段使い」「互換性テスト」など、用途や提供元が分かる名前を付けましょう。サブスクリプションURLをメモやスクリーンショット、共有ドキュメントに記載しないでください。URLのパスやクエリパラメーターがアクセス権限を担っている場合があります。問題を調べるときは、URLの種類、応答ステータス、エラー文だけを記録し、URLの詳細は伏せてください。URLをコピーする際は元のエンコードを維持し、重複して見えるパラメーターも削除しないでください。

初回の更新では絞り込み条件を無効にし、サーバー一覧を取得できることを確認してから、条件を一つずつ追加します。「URLの応答が空」と「応答はあるが絞り込みで除外された」を分けて判断してください。前者ではサブスクリプションの有効性、ネットワーク到達性、応答形式を確認します。後者では絞り込み条件を確認します。何度も更新しても条件の誤りは直りません。かえって実際の応答内容を見落とすおそれがあります。

対象フィールドと一致方法を確認する

サーバーを絞り込む前に、設定項目の説明を確認してください。サーバーのメモ、プロトコルの種類、その他のどのフィールドを対象にするのか、また条件が通常の文字列、部分一致、正規表現のどれなのかを確認します。画面によって仕様が異なるため、同じルールだと決めつけないでください。正規表現に対応していることが明確な場合は、以下の式でメモに含まれる「テスト」または「予備」の目印に一致させられます。該当項目の仕様に応じて、一致した項目を残すか除外するかが決まります。

(テスト|予備)

最初から複雑な除外条件を組み合わせないでください。まず一致することが分かっているメモで試し、次に一致しないはずのメモを試し、最後に空のメモを確認します。正規表現の丸括弧、縦棒、ピリオドには特殊な意味があります。文字としてのピリオドに一致させるには、バックスラッシュを付けてください。大文字と小文字を区別するかどうかは、対象フィールドの実装に従います。画面に表示された文字の形だけで判断しないでください。

サブスクリプションごとに名前の付け方が異なる場合は、すべての名前を一つの式に詰め込まず、グループごとに絞り込み条件を設定しましょう。提供元がメモを変更すると、以前の条件ですべての項目が除外されることがあります。更新前に残るはずの名前の特徴を記録し、更新後もその特徴があるか確認してください。一覧の件数が変わっただけで、サービスの異常と判断しないでください。提供元側で内容が変更された可能性もあります。

更新による上書きと接続パラメーターの違いに注意する

サブスクリプションの項目は通常、リモートのデータから再生成されます。転送パラメーターを長期的に変更する場合は、クライアントに個別保存や手動項目へのコピー機能があるか確認してください。コピーした項目は別のグループに入れ、サブスクリプション更新が自動で反映されなくなることを明確にしておきます。サブスクリプションの項目を直接変更して、次回の更新後も変更が残ると思い込まないでください。まず更新を一度実行し、どの項目が上書きされるか確認しましょう。

「インポートには成功したが接続できない」場合は、プロトコル、サーバーアドレス、ポート、転送方式、TLS関連の設定を確認してください。インポートに成功したということは、クライアントが形式を認識できたというだけで、現在のコアがすべての機能に対応しているとは限りません。v2rayNG と v2flyNG は異なるコア系統を使用するため、見た目が似ているという理由だけで設定を使い回せません。必要なプロトコルを確認してから、クライアントを選びましょう。

サブスクリプションの更新に失敗した場合は、現在使える設定を保存し、すべてのグループをすぐに消去しないでください。URLの完全性、システム時刻、証明書エラー、更新時にプロキシを経由するかを順に確認します。詳しい手順はv2rayNのサブスクリプション更新失敗の対処法をご覧ください。提供元の問題を解決してから絞り込み条件を戻し、URLと絞り込みロジックを同時に変更しないようにしましょう。

最後に最小限の検証を行います。グループを一つ更新し、用途が分かっている項目を選んでコアを起動し、設定の解析エラーがログにないことを確認してください。検証に成功してから自動更新を有効にします。これにより、サブスクリプションの形式、絞り込み条件、接続パラメーターを切り分けられ、一度の一括操作で使える状態を失わずに済みます。

DNS設定の最適化

実際の名前解決経路を把握する

アプリ、OS、クライアント、リモート側の出口に分けてDNSを確認します。ブラウザーが独自のセキュアDNSを有効にしている場合や、OSがLAN内のリゾルバーを使う場合があります。コアが独自のキャッシュを保持したり、プロキシサーバーが最終的な宛先を名前解決したりすることもあります。「DNS設定」を変更しても、その設定が処理するクエリにしか影響しません。すべてのアプリがすぐに新しいサーバーを使うと思い込まないでください。

まず、アプリがプロキシに渡すのがドメイン名かIPアドレスかを確認します。リモート側で名前解決できるプロキシ方式なら、アプリはドメイン名をプロキシに渡せます。アプリが先に自分で名前解決し、アドレスをクライアントに渡す場合、ドメインベースの振り分けに必要な元の情報が失われることがあります。その場合はアプリのプロキシ設定や通信の取り込み方法を確認してください。ドメインのDNSルールを追加するだけでは、失われた情報をすべて復元できません。

重要なクエリを二種類に分けて考えます。プロキシサーバー自身のアドレスを解決するクエリと、接続先の名前を解決するクエリです。前者はプロキシ接続の確立前に発生するため、単独で動作する経路が必要です。唯一の起動用リゾルバーを「プロキシの確立後にしかアクセスできない」設定にすると、起動時に循環が発生します。ドメイン名で指定する暗号化DNSサービスを使う場合も、そのサービス名の初回名前解決方法を考慮してください。

用途に応じてリゾルバーを使い分ける

以下は、これらの項目に対応する V2Fly または Xray の設定で使える、内蔵DNSの簡易例です。通常のクエリにはパブリックDNSを使い、ローカルドメインはシステムのリゾルバーに渡します。これはドメイン条件とクエリポリシーの説明用であり、パブリックDNSがあらゆるネットワークから利用できることを示すものではありません。実際に使う前にネットワーク要件に合わせて変更し、クライアントによって上書きされないかも確認してください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      "1.1.1.1",
      {
        "address": "localhost",
        "domains": ["domain:localhost"]
      }
    ]
  }
}

社内サービスは通常、LAN内DNSに登録されたプライベートレコードを利用します。すべてのクエリをパブリックDNSに送ると、必要なレコードが見つからなかったり、現在のネットワークに適さないアドレスが返されたりすることがあります。社内ドメイン、ルーターの管理用ホスト名、自前のサービスには、明確なローカル名前解決経路を用意してください。単一ラベルの名前をすべてパブリックドメインと見なさず、内部名を一つ解決するためにDNSの振り分け全体を無効にしないでください。

リゾルバーの通信方式と、クエリが実際に通る経路は別の問題です。暗号化DNSはその通信経路を保護しますが、プロキシを経由するかどうかはコアの実装、アウトバウンドルール、クライアントの設定生成方法によって異なります。ローカルDNSの一部の方式では、通常のルーティング処理を通らないことがあります。動作を確認する際は実行時設定と接続ログを調べ、アドレス文字列に暗号化方式の記載があるかどうかだけで経路を判断しないでください。

「期待するアドレス」などの条件は、応答がルールの想定に合うかを判断するためのもので、速度を上げる汎用スイッチではありません。有効にした結果、正当な応答が拒否されると、フォールバックのクエリが発生して問題の特定が難しくなることがあります。まず基本的な名前解決が成功することを確認し、その後で応答に条件を加えてください。条件を追加するたびに、比較用のドメインと想定されるアドレス範囲を記録しましょう。

アドレスファミリーとキャッシュを個別に検証する

IPv4とIPv6の両方に対応するネットワークでは、名前解決と接続をそれぞれ確認します。IPv6アドレスを取得できても、現在の出口でIPv6通信が利用できるとは限りません。アドレス選択後に接続が失敗する場合は、システムルートと出口の対応状況を確認してから、クエリポリシーを調整してください。IPv6の設定をすべて削除すると症状が一時的に変わるだけで、DNS自体に問題があった証拠にはなりません。

リゾルバーを変更しても、ブラウザー、OS、コアにそれぞれキャッシュが残る場合があります。テスト時は既存の接続を閉じ、テスト用アプリを再起動し、必要に応じて該当するキャッシュを消去してください。サーバーとクエリポリシーを同時に変更すると、結果の原因を特定できません。OSの名前解決ツールで確認できるのはシステムの名前解決経路です。コア内蔵DNSを通らない場合もあるため、ブラウザーの結果と異なっていても設定が反映されていないとは限りません。

切り分けでは、比較用に単純な名前解決経路を一つ残してください。まず複雑なフォールバックと応答フィルターを無効にし、基本的なクエリが完了することを確認してから、ドメイン分類、アドレスファミリーの優先設定、暗号化通信を戻します。ローカル名は解決できて外部名が失敗する場合は、外部リゾルバーへの到達性を確認してください。クエリが完了しているのに宛先へ接続できない場合は、ルーティングの章に戻ってアウトバウンドを確認し、リゾルバーをむやみに増やさないでください。

最後に、DNSログがプライバシーに与える影響を確認します。デバッグログにはアクセスした完全なドメイン名が含まれる場合があり、長期間保存すると詳細な通信履歴になります。検証後は通常のログレベルに戻し、エラー情報を共有するときは内部名やサブスクリプションとの関連情報を伏せてください。DNS設定の目的は経路を明確にし、結果を説明できるようにすることであり、上流のリゾルバーをできるだけ多く設定することではありません。

FakeDNS

仮想アドレスとドメインの対応関係を理解する

FakeDNS は宛先の実アドレスを直接返すのではなく、専用のアドレスプールから仮想アドレスを割り当て、ドメイン名との対応関係を保存します。アプリがそのアドレスに接続すると、通信を取り込むコンポーネントが対応関係から元のドメイン名を復元し、ルーティングとアウトバウンドの処理を行います。アドレス形式で届く通信からドメインを識別するための仕組みであり、DNSの一連の処理を置き換える単独のパブリックDNSではありません。

設定が機能するには、一連の処理がつながっている必要があります。クエリがFakeDNSに届き、返された仮想アドレスが同じ通信取り込み経路に届き、対応関係が維持され、インバウンドで正しくドメイン名が復元されなければなりません。どれか一つでも欠けると、「名前解決はできるのにまったく開けない」という状態になります。まず通常のDNSとTUNを検証してからFakeDNSを追加し、安定していない通信取り込み経路に仮想アドレスの仕組みを重ねないようにしてください。

仮想アドレスをそのまま実ネットワークへ送らないでください。仮想アドレスは接続先サーバーの場所を示すものではなく、通常のネットワークからアクセスできないことがほとんどです。ログでアドレスプール内のアドレスへの接続が繰り返されている場合は、そのアドレスに接続できるプロキシを探すのではなく、対応関係の復元と通信の取り込み範囲を確認してください。元のドメイン名を復元して初めて、後続のドメインルールとリモートでの名前解決に正しい情報が渡ります。

コアの対応状況とインバウンド設定をそろえる

以下はFakeDNSに対応する Xray 設定の要素を示しています。アドレスプール、DNSサーバー、対象インバウンドのスニッフィング設定にそれぞれ対応します。これらは実際に実行する一つの設定内の正しい位置に統合する必要があり、自由に追加できる三つのトップレベルオブジェクトではありません。クライアントがすでに該当部分を生成している場合は、その設定を使い、項目の重複宣言や他の必須オプションの上書きを避けてください。

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

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

2つ目の例はインバウンド内部の sniffing オブジェクトです。既存のインバウンド設定全体と置き換えないでください。現在のインバウンドでHTTPやTLSのスニッフィングも必要な場合は、コアのドキュメントに従ってリストを統合します。元の内容を機械的に削除しないでください。仮想アドレスとスニッフィングの実装はコアによって異なる場合があります。v2flyNG で設定する前に、使用中のコアとクライアントが該当機能に対応していることを確認してください。

例のアドレスプールは仮想用途のネットワーク範囲ですが、ローカル環境やネットワークですでに使用されていないか確認してください。テスト環境、他のプロキシコンポーネント、ネットワーク診断ツールが同じ用途で使っている場合があります。アドレスが重複すると、ルートの意味が曖昧になります。空いているように見えるパブリックアドレス範囲を適当に選ばないでください。クライアントで変更できる場合は、その実装のアドレスプール要件に従い、ルートの除外設定もあわせて確認してください。

アドレスプールの容量が左右するのは、保持できる対応関係の数です。接続できるサーバー数や通信速度ではありません。容量が小さすぎるとドメイン数が多い場合に古い対応関係が早く破棄されることがありますが、むやみに大きくするとリソースを余計に使う場合があります。まず実装で用意されている妥当な既定値を使い、ログと再現条件から対応関係の破棄が原因だと判断できる場合にのみ調整してください。アプリの起動が遅いという理由だけで容量不足と決めつけないでください。

キャッシュとFakeDNSを経由しないアプリへの対処

FakeDNSを有効または無効にした後も、アプリやシステムに古いキャッシュが残ることがあります。アプリが仮想アドレスを保持したまま、再起動によって対応関係が消えると、断続的な接続失敗が起こります。切り替えをテストする際は、該当アプリの接続を閉じ、名前解決キャッシュを消去してからリクエストをやり直してください。コアだけを再起動してブラウザーに古いアドレスや接続を使い続けさせないでください。新旧の状態が混在してしまいます。

アプリ独自の暗号化DNSは想定したクエリの入口を通らないことがあります。また、固定アドレスへのアクセスにはドメイン名のクエリ自体がありません。これらの通信ではFakeDNSの対応関係を自動的に利用できません。アプリの実際の動作を確認してから、アプリのDNS設定、プロキシ方式、通信の取り込み範囲を調整するか判断してください。他のアプリが正常だからといって、問題のアプリも同じ名前解決経路を使っているとは限りません。

LAN内の名前や実アドレスを必要とするアプリには、通常のDNS経路を残してください。名前解決の結果を通信の取り込み対象外の別プロセスに渡すサービスもあります。そのプロセスでは仮想アドレスを使えない場合があります。このような場合は、仮想アドレスをシステムから広く参照できるようにするのではなく、対象名に明確な名前解決の例外を設定してください。アドレスをプロセス間で渡す動作は、アプリの構造に応じて判断する必要があります。

元に戻すときは、通常の名前解決を復元し、仮想アドレスのマッピングを無効にしてから、古いキャッシュを消去して接続を確立し直します。切り戻し後も仮想アドレスにアクセスしようとする場合は、サーバー設定をさらに変更せず、まずキャッシュの残存に対処してください。FakeDNSの利点は、ルーティング可能なドメイン情報を保持できることです。通常のドメイン名を使うインバウンドで要件を満たせる場合は、設定を複雑にするためだけに有効にする必要はありません。

カスタムアウトバウンド

タグでルーティングと出口を結び付ける

アウトバウンドはコアから外部への接続方法を定義し、ルーティングはタグを使ってアウトバウンドを選択します。タグは設定内で参照するための名前であり、特別な機能はありません。アウトバウンドに direct という名前を付けても、自動的に直接接続になるわけではありません。動作を決めるのはプロトコルとその設定です。まずアウトバウンドの定義を確認し、次にルーティングからの参照を確認してください。タグ名が一致することは正しい設定に必要ですが、それだけで十分ではありません。

GUIクライアントは通常、現在のサーバーに対応するプロキシアウトバウンドと、直接接続およびブロック用のアウトバウンドを生成します。カスタム項目を追加する場合は、クライアントの入力欄が「設定の一部を追加」「設定全体を置換」「専用のカスタム設定」のどれに当たるのか確認してください。部分的な設定を設定全体の入力欄に読み込むと、インバウンドなど必須の項目が不足します。逆に、設定全体を追加用の欄に入れると定義が重複する場合があります。

以下は、ネイティブな V2Ray または Xray の設定でよく使われる、直接接続とブロックのアウトバウンド例です。タグの構造を確認するために使ってください。統合する前に、同じタグがすでに存在しないか確認します。この例にはプロキシサーバーの認証情報は含まれておらず、クライアント設定全体でもありません。プロキシアウトバウンドは検証済みのサーバー項目から生成し、手作業で転送やセキュリティのパラメーターを漏らさないようにしてください。

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

まず単一ルールで試し、その後に組み合わせる

アウトバウンドを追加したら、まず範囲を絞った明確なルールを一つ使って参照します。管理できるテスト対象を選び、コアが起動すること、タグが存在すること、ルールが適用されることを確認してから、対象範囲を広げましょう。デフォルトの通信をすべて置き換えないでください。設定を誤るとすべてのアプリが同時に失敗し、比較できる情報が減るだけでなく、サブスクリプションの更新や問い合わせページへの接続もできなくなるおそれがあります。

直接接続アウトバウンドでも、名前解決とシステムネットワークの確認が必要です。ファイアウォールを迂回するわけでも、特定の物理インターフェースを使う保証があるわけでもありません。インターフェースのバインドや送信元アドレスを指定する場合は、現在のコアに対応するオプションがあり、OSの権限も満たしているか確認してください。また、指定するアドレスがローカル端末に割り当てられていることも確認します。他の端末のインターフェース名やアドレスをコピーしても、同じ経路にはなりません。接続に失敗することがあります。

プロキシチェーンとは、複数のプロキシアウトバウンドを並べることではありません。明示的な転送関係を設定して初めて、接続が複数の段階を経由します。通常のルーティングでは、複数の出口から一つを選ぶだけです。チェーンを組む前に各段階が単独で使えることを確認し、名前解決、転送プロトコル、認証の要件も段階ごとに確認してください。一つでも失敗するとチェーン全体に影響します。ログは段階ごとに読み取り、最後のタイムアウトだけで判断しないでください。

特にUDPと多重化の動作を確認してください。あるアウトバウンドでWeb通信ができても、すべてのデータグラム通信に適しているとは限りません。また、プロトコルが多重化に対応していても、有効にすることであらゆるアプリにメリットがあるわけではありません。まず既定値を維持し、接続確立のオーバーヘッドや互換性の問題を実際に確認できた場合に限って比較テストを行います。Muxを無条件に速度を上げる機能として扱ったり、異なるコアの多重化項目を混用したりしないでください。

デフォルトアウトバウンド、ループ、互換性に対処する

明示的なフォールバックルールがない場合、デフォルトアウトバウンドがオブジェクトの順序に左右されることがあります。新しいオブジェクトを挿入すると、既存のルールが変わっていなくても、どのルールにも一致しない通信の経路が変わる場合があります。変更前にデフォルトの動作を記録し、変更後は先行ルールに一致しない対象を一つテストしてください。デフォルトの動作を安定して指定するには、現在のコアが対応するフォールバック方式を使い、偶然の並び順に依存しないようにします。

アウトバウンド同士が互いを参照するループや、アウトバウンドの接続がローカルのプロキシ入口に再び取り込まれる状態を避けてください。前者はコア設定内の転送関係で発生し、後者はシステムプロキシ、TUN、アプリのプロキシ設定が原因になる場合があります。いずれも接続が繰り返されてタイムアウトすることがあります。切り分けでは、各段階の次の接続先を実際のネットワーク出口まで書き出します。出発点に戻る矢印があれば、その理由を説明できる必要があります。

コアを切り替える前に設定を保存し、プロトコル、転送方式、セキュリティのオプション、リソース形式を一つずつ確認してください。V2Fly と Xray は一部の設定概念を共有していますが、すべての拡張機能に互換性があるわけではありません。v2rayNG と v2flyNG も、名前が似ているだけで同じ実行環境だとは限りません。コアが未対応の項目を報告した場合は、実際の対応範囲に合わせて修正してください。エラー行を単に削除し、その行が担っていた機能を無視しないでください。

カスタム設定を保守する際は、厳密なJSONにコメントを追加して解析エラーを起こさないよう、各タグの用途を別の場所に記録してください。保存前に括弧、カンマ、文字列の引用符、キーの重複を確認します。一度に変更するのは一つの論理単位だけにし、起動に成功したらネットワークを検証してください。構文が正しくても、出口に到達できるとは限りません。クライアントを変更する場合はダウンロードページに戻り、プラットフォームとコアの用途を確認してください。

カスタムアウトバウンドを元に戻す際は、まずそれを参照するルールを削除または変更し、その後でアウトバウンドを削除して、最後にデフォルト経路を確認します。アウトバウンドだけを削除してタグ参照を残すと、起動時やルール適用時に失敗します。切り戻し後はテスト接続を確立し直し、クライアントが想定した設定生成方法に戻っていることを確認してください。画面上の設定だけが戻り、実行ファイルが古い状態のまま残るのを防げます。