設定リファレンス / v2rayN · v2rayNG

V2Ray詳細設定ガイド

サブスクリプショングループ・ルーティング・DNS・TUN

まず接続できる状態を作り、その後ネットワークの動作を一つずつ調整します。デスクトップではv2rayN、Androidではv2rayNGを中心に説明します。v2flyNGはコアの機能や設定項目を個別に確認してください。

ルールの適用順 名前解決の経路 トラフィックの制御 アウトバウンドタグ

このページは設定を体系的に確認するためのガイドであり、初回接続の手順に代わるものではありません。インストール、設定のインポート、接続確認がまだの場合は、まず入門ガイドに沿って初期設定で接続し、該当する項目を確認してください。インストーラーとアーキテクチャの選び方はクライアントのダウンロードページをご覧ください。クライアントの画面は更新されることがあるため、コアの設定項目は原名で記載しています。メニューの場所は実際の画面で確認し、異なるコアの設定を混在させないでください。

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

サブスクリプション、サーバー項目、選択中の設定を区別する

サブスクリプショングループには設定の取得元と更新オプションが保存され、サーバー項目には接続パラメーターが保存されます。選択中の設定は、現在コアの起動に使われている項目です。この3つは別のものです。リストでグループを切り替えても通常は表示範囲が変わるだけで、使用中のサーバーが切り替わるとは限りません。項目を選択しても、使用中のサーバーに設定されたとは限りません。変更後はクライアントに表示された接続先を確認し、接続を停止してから再接続してください。以前の接続を新しい設定の結果と取り違えないようにしましょう。

最初に整理するときは、「メインのサブスクリプション」「予備のサブスクリプション」「手動設定」のように取得元ごとにグループを作成します。v2rayNのサブスクリプショングループ設定、またはv2rayNGのサブスクリプション設定で名前とURLを入力し、そのグループを更新してください。共有リンクは1つまたは複数の接続設定を含むもので、継続的な更新機能はありません。インポート方法の違いは共有リンクとサブスクリプションURLの違いを参照し、単一サーバーのリンクをサブスクリプションURL欄に入力しないでください。

備考で絞り込み、プロトコル設定は変更しない

サーバーの絞り込みはリスト表示に適用されるもので、ネットワークのルーティングとは別です。「予備」で検索しても表示項目が絞られるだけで、特定のサイトへの通信が自動的に予備サーバー経由になるわけではありません。まず通常のキーワードで検索範囲を確認してください。正規表現を使うのは、画面が対応している場合に限ります。たとえば^(办公|备用)-は、備考が指定した接頭辞で始まることを表しますが、すべての検索欄で使えるとは限りません。包含と除外の組み合わせも、リスト上で実際に確認し、利用可能な項目をすべて隠してしまわないようにしてください。

絞り込みには、一時的な遅延値や変動しやすい並び順ではなく、安定した備考の接頭辞を使うのがおすすめです。サブスクリプションの更新で備考、順番、項目数が変わることがあり、同じ名前でもアドレス、ポート、トランスポート設定が異なる場合があります。重複を確認するときは名前だけで判断せず、サーバーアドレス、プロトコル、ポート、トランスポート設定を照合してください。ユーザー名、ID、鍵などは機密性の高い接続情報です。スクリーンショットやログを共有する前に伏せ、サブスクリプションURLに含まれるアクセストークンも必ず隠してください。

操作変更される対象確認すること
サブスクリプショングループを切り替えるリストの表示範囲使用中のサーバーが元の項目のままか
サブスクリプションを更新するグループ内のサーバー設定手動変更が上書きされないか
備考で絞り込む表示されるサーバー項目検索欄が正規表現に対応しているか
使用するサーバーに設定する次回の接続で使う設定コアが再読み込みされたか

更新に失敗した場合は、既存項目を残す

サブスクリプションを更新する前に、古い項目が削除されてから新しい項目が読み込まれる動作か確認してください。項目の保持方法はクライアントや更新方法によって異なるため、未確認の動作を前提にしないでください。重要な手動設定は個別にエクスポートしてバックアップし、再生成されるグループに入れないようにします。更新後にリストが空になった場合は、取得した内容がクライアント対応のサブスクリプション形式か、URLの有効期限が切れていないか、ログインページが返されていないか、取得リクエストが接続可能なネットワークを通っているか確認してください。

「現在のプロキシが利用できないため、そのプロキシ経由ではサブスクリプションを更新できません」という循環状態が起きた場合は、サブスクリプションの取得経路とサーバーへの接続経路を分けて考えます。取得元の利用条件で認められ、ローカルネットワークからアクセスできる場合に限り、プロキシを経由しない更新方法に切り替えてください。全体設定を何度も切り替えて元の状態が分からなくならないようにしましょう。ドメイン解決、接続確立、内容の解析のどの段階で失敗したか記録し、元の設定に戻してから一つずつ試します。更新成功は設定を取得できたことを示すだけで、すべての項目が接続できることを意味しません。

最後に、繰り返し実行できる確認手順を決めておきます。グループ名を確認し、絞り込み条件をクリアし、更新前後のアドレスと重要な設定値を比較してから、使用するサーバーを手動で選択します。まず実際にWebページへアクセスし、その後に一括テストを行うか判断してください。テストでは接続と通信が発生し、短時間に大量の操作を行うとサーバー側の制限にかかることがあります。リストの並び順に頼るより、動作確認済みの予備設定を少数保存しておく方が、障害時に復旧しやすくなります。

ルーティングルールの実践：条件に合致したらアウトバウンドを選ぶ

ルールの順序とデフォルトのアウトバウンドを確認する

Xrayのルーティングルールは通常、上から順に評価され、条件に一致すると指定されたアウトバウンドへ渡されます。リストの見た目を整えることより、ルールの順序が重要です。完全一致のドメイン、特定アプリの接続先、特殊な宛先は、対象範囲の広い地域ルールより上に置きます。編集前に既存アウトバウンドのタグを一覧にし、direct、proxy、blockが実際に定義されているか確認してください。タグは大文字と小文字を区別する参照名で、予約語ではありません。存在しないタグを指定しても、接続設定が自動で作成されることはありません。

同じルール内の複数の条件フィールドは、通常すべて満たす必要があります。同じフィールドに複数の値がある場合は、通常いずれか一つに一致すれば条件を満たします。たとえばdomainとportを同時に指定すると、ドメイン条件とポート条件の両方を満たす必要があり、どちらか一方だけに一致すればよいわけではありません。「ドメインはプロキシ経由にし、別のポート群もプロキシ経由にする」場合は、ルールを2つに分けると分かりやすくなります。ルールが複雑になるほど、条件をまず一文で説明してから設定に反映してください。

完全一致のドメインルールから始める

以下はXrayのrouting部分設定の例です。proxyとdirectのアウトバウンドがすでに定義されていることを前提としています。例では、テスト用ドメインを先にプロキシへ振り分け、その後で中国本土のドメインとプライベートアドレスを処理します。full:は完全一致するドメインだけを対象にし、domain:はそのドメインとサブドメインを対象にします。例のドメインは構文の説明用です。実際の設定では対象のドメインを入力し、接続確認には使わないでください。

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

geositeとgeoipはルール用データの参照先であり、オンラインのリアルタイム検索ではありません。対応ファイルがない、カテゴリ名に対応していない、データが古いといった場合、設定の読み込みに失敗したり、意図しない判定になったりします。クライアントの更新とルールデータの更新は別の作業です。エラーが発生したら、まずfull:ルールを一つ使ってルーティングの基本構成を確認してから、リスト参照を戻してください。コア、データファイル、ルールを同時に変更しないようにしましょう。

domainStrategyで名前解決されるタイミングを理解する

AsIsはルーティング判定のために宛先ドメインを追加で解決しません。ドメインルールを中心に使う場合に適しています。IPIfNonMatchはドメインとしてルールに一致しなかった場合に名前解決し、取得したIPアドレスでもう一度判定します。IPOnDemandはIPアドレスを必要とするルールの評価中に名前解決する場合があります。これらはルーティング段階の動作を制御する設定であり、最終的に使用するDNSサーバーを直接決めるものではありません。また、アウトバウンド接続時のアドレス選択方針とも異なります。

アプリがクライアントにIPアドレスを直接渡す場合、ドメインルールの照合対象がないことがあります。トラフィックスニッフィングで一部のHTTPリクエストやTLS接続からドメインの手がかりを得られることはありますが、すべてのプロトコルで元のドメインを復元できるわけではありません。暗号化されたハンドシェイク、アプリのキャッシュ、IPアドレスへの直接接続も結果に影響します。トラブルシューティングでは、まず入口に届いた宛先がドメインかIPかを確認し、そのうえでドメインルール、IPアドレスルール、入口ごとの振り分けのいずれを使うか判断してください。ルール名が正しいだけで適用されたと決めつけないようにしましょう。

検証する際はアプリの既存接続を終了し、宛先が明確なリクエストを新たに送信して、アクセスログの宛先とアウトバウンドタグを確認します。ブラウザーが既存接続を再利用すると、変更したルールが反映されていないように見えることがあります。コアを再起動しても、ブラウザー側のキャッシュが消えるとは限りません。ログを有効にして記録が大量に出る場合は、テスト範囲を絞り、詳細ログをすみやかに無効にしてください。ルールは一つずつ追加して動作を確認し、適用順、名前解決、タグ参照のどこに問題があるのか特定してから対象を広げましょう。

DNS設定の最適化：名前解決と接続経路を分けて確認

名前解決が行われるレイヤーを見分ける

一つのリクエストでも、システムDNS、アプリ内蔵のリゾルバー、コア内蔵DNS、プロキシサーバー側の名前解決が関わることがあります。コアのdns.serversを設定しても、すべてのアプリがそのDNSを使うとは限りません。システムプロキシの影響を受けるのは、プロキシ設定に従うリクエストが中心です。ブラウザーで独自の暗号化DNSを有効にすると、別の経路で名前解決される場合もあります。まずドメインがどこでIPアドレスに変換されているか確認してください。現在のリクエストに関与していないレイヤーだけを変更しても、問題は解決しません。

接続先のWebサイトのドメインと、プロキシサーバーのドメインも区別する必要があります。プロキシ接続を確立する前に、通常はサーバー自身のドメインを利用可能なアドレスに解決しなければなりません。この段階で、まだ確立されていない同じ接続に依存することはできません。サーバーアドレスがドメインの場合は、まず起動時の名前解決経路を確保してから、接続先ドメインのDNS振り分けを設定してください。すべてのDNSリクエストをプロキシ経由にすると、起動に必要な接続が互いに依存する循環状態になり、コアは起動するのに最初の接続だけ確立できないことがあります。

対象ドメインを限定してDNSサーバーを使う

以下のXray部分設定例では、geosite:cnに該当するドメインを中国本土のDNSサーバーへ優先的に送り、汎用DNSサーバーも残しています。expectIPsは応答アドレスが想定範囲にあるか確認するもので、Webサイトの正当性や最適な経路を保証する機能ではありません。使用には対応するルールデータが必要です。また、例にあるDNSアドレスへローカルネットワークからアクセスできることを確認しないと、テストとして意味がありません。DNSリクエスト自体がどのアウトバウンドを通るかは、実際のコアとルーティング設定を合わせて確認してください。

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

ドメインの優先判定、想定アドレスのフィルタリング、フォールバック問い合わせが結果に影響します。DNSサーバーの配列を、単純に「1台目が失敗したら2台目へ進む」と考えないでください。DNSサーバーを追加する前に、使用中のコアがフォールバック関連の設定項目に対応しているか確認し、ログで実際の問い合わせ動作を調べます。1台のDNSサーバーで安定して解決できているなら、追加したサーバーによって待ち時間や不確実性が増えるだけかもしれません。特定のドメインに単一の経路を使う場合は、配列の順番に頼らず、対象範囲とフォールバック動作を個別に設定してください。

通常のDNS、DoH、アドレスファミリーの設定を選ぶ

従来のDNSは通常、指定ポートを使ったUDPまたはTCPで通信します。DoHはHTTPSでDNSリクエストを送信し、リゾルバーまでの通信を保護しますが、プロキシの代わりにはならず、ルーティングの誤りも自動では解決しません。DoHのURLがドメイン名を使う場合は、DoH自身の起動時の名前解決も考慮する必要があります。使用中のコアがそのアドレス形式に対応し、ネットワークから接続先にアクセスでき、証明書が正しく検証されることを確認してから有効にしてください。エラーを消す目的で証明書検証を無効にしないでください。接続のセキュリティが損なわれます。

UseIPは設定に応じて両方のアドレスファミリーを取得し、UseIPv4とUseIPv6は問い合わせるアドレスファミリーを限定します。IPv4に限定すると、問題がIPv6経路に関係するか切り分けられますが、あらゆるネットワークで使える恒久的な解決策ではありません。システムがIPv6アドレスを通知しても、TUNがIPv4しか制御していない場合、アプリが制御対象外の経路を優先することがあります。DNSの応答、システムルート、アウトバウンドの対応状況をまとめて確認し、DNSサーバーのアドレスだけを変更して終わらせないでください。

「接続はできるが一部のドメインを開けない」場合は、同じドメインについてシステムの名前解決結果とコアのログをそれぞれ記録し、想定したドメインルールに一致しているか確認してください。システムの名前解決ツールが示すのは、そのツールが使った経路だけであり、プロキシ接続内の結果を表すとは限りません。次にテスト対象のアプリを再起動し、DNSキャッシュを消去するか記録の有効期限が切れるのを待ってから、新しい接続を試します。クライアントのサーバーリストを再読み込みしても、すべてのレイヤーのキャッシュが消えるわけではありません。古いアドレスがしばらく使われることがあります。

まず、アクセス可能なDNSサーバーを一つだけ使う基準設定を保存してください。ドメインごとの振り分けを追加したら、通常のドメイン、指定したドメイン群、再起動後の初回接続の順にテストします。起動直後だけ失敗する場合は、起動時の名前解決依存を優先して確認します。長時間の稼働後にだけ失敗する場合は、キャッシュ、ネットワーク切り替え、DNSサーバーへの到達性を確認してください。DoH、FakeDNS、複雑なフォールバックルールを一度に有効にするより、原因を特定しやすくなります。

TUNモード：トラフィックの制御範囲とシステムルートを確認する

システムプロキシ、仮想ネットワークインターフェース、Android VPNを区別する

システムプロキシはアプリにプロキシアドレスを提供し、その設定に従うプログラムが利用します。TUNは仮想ネットワークインターフェースを使ってシステムから渡されたIPトラフィックを受け取り、対応するコンポーネントでプロキシリクエストに変換します。両者は動作するレイヤーが異なります。TUNを有効にしてもサーバーのプロトコルが変わるわけではなく、すべてのプログラムが制御対象になるとも限りません。デスクトップではv2rayNの画面にあるTUNオプションを使ってください。実際の処理コンポーネントと設定形式は、使用中のクライアントが生成した設定を確認します。

Android版v2rayNGは通常、システムのVPNサービスを利用してアプリのトラフィックを受け取ります。許可を求める画面や設定手順は、デスクトップの仮想ネットワークインターフェースとは異なります。デスクトップ用TUN設定ファイルをAndroidクライアントに直接読み込ませないでください。v2flyNGは異なるコアを使用するため、v2rayNGのメニューから機能を推測できません。クライアントを選んだら、まず通常の接続が動作することを確認し、その後にシステム側のトラフィック制御を個別に有効にします。サーバー設定と端末の通信経路、どちらが原因か切り分けやすくなります。

有効にする前にルーティングの競合を解消する

有効にする前に、デフォルトルートを制御している他のネットワークツールを終了し、既存のVPN、仮想マシン用ネットワークインターフェース、社内ネットワークの設定を記録してください。複数のコンポーネントがデフォルトルート、DNS、ファイアウォールを同時に変更すると、起動順によって症状が変わることがあります。デスクトップOSで管理者権限が必要な場合は、クライアントの指示に従ってください。エラーを回避するために複数のインスタンスを繰り返し起動しないでください。仮想インターフェースの作成に失敗した場合は、サブスクリプションやプロトコルを変更する前に、権限とドライバーのログを確認します。

プロキシサーバーへの接続自体が仮想インターフェースに戻されていないかも確認してください。TUNで大部分の通信を制御する場合は、基盤となるプロキシ接続に正しいバイパス経路が必要です。通常はクライアントが自動で処理します。手動でシステムルートを追加したり、ネットワークインターフェースのバインド先を変更したりすると、この除外設定が崩れて通信がループすることがあります。TUNを有効にするとすべて切断され、無効にするとすぐ復旧するのが典型的な症状です。まずインターフェースとデフォルトルートを自動設定に戻してから、カスタム設定を一つずつ戻してください。

方式主な通信経路優先して確認する項目
システムプロキシシステムプロキシ設定に従うアプリアプリの対応状況、アドレス、ポートが正しいか
デスクトップTUNシステムルートから仮想インターフェースへ転送インターフェース権限、ルート、DNS、接続のバイパス
Android VPNサービスシステムで許可されたアプリのトラフィックVPNの許可、アプリ別リスト、バックグラウンド動作

TCP、UDP、LANを個別にテストする

Webページを開けることは、一部の通信経路が動作している証拠にすぎません。UDP、リアルタイム音声・動画、LANへのアクセスも正常とは限りません。TUNがUDPを受け取れても、その後のアウトバウンドプロトコル、サーバー側、接続先のネットワークがすべて対応している必要があります。テストに失敗した場合は、まずリクエストがクライアントに届いているか確認し、その後でアウトバウンドが対象の通信方式に対応しているか調べます。問題を隠すためにすべてのUDPを破棄しないでください。他の通信方式に切り替わるだけの場合もあれば、一部機能が使えなくなる場合もあります。

LAN内の機器へのアクセスには、プライベートアドレスのルーティング、ファイアウォール、名前解決も関わります。LANのバイパスルールを有効にしても、接続経路が変わるだけで、プリンターの検出やマルチキャスト通信が自動で解決するわけではありません。まず機器の実際のプライベートアドレスで基本的な接続をテストし、検出プロトコルがトラフィック制御の影響を受けているか確認してください。LANからの接続を許可する設定は、端末上のプロキシの待ち受けをLANに公開するための別設定です。LAN内の機器へアクセスする問題を解決するために、安易に有効にしないでください。

Androidでアプリごとのプロキシを設定する際は、「選択したアプリのみをプロキシ経由にする」か「選択したアプリをプロキシから除外する」かを明確にしてください。同じアプリ一覧でもモードが反対なら、結果はまったく異なります。アプリの更新や再インストール、仕事用プロファイルの利用で、一覧に表示されるアプリが変わることがあります。対象を変更したらVPN接続を再確立してテストしてください。バックグラウンドプロセスがシステムの制限を受ける場合もあります。画面ロック後に接続が切れるなら、ルーティングルールのせいだと決めつけず、バッテリー設定とバックグラウンド動作の制限を確認してください。

安定性を確認するには、有効化、無効化、ネットワーク切り替え、スリープからの復帰をテストしてください。各操作の後、システムDNSとデフォルトルートがクライアントの終了時に正しく復元され、到達不能なDNSアドレスが残っていないか確認します。クライアントを終了してもインターネットに接続できない場合は、システムプロキシとDNSを自動設定に戻してから、仮想インターフェースの設定が残っていないか調べてください。制御を有効にする前後の変化を記録すると、端末側のネットワーク状態とリモート接続の問題を切り分けやすくなり、確認済みの通常のプロキシ設定にも戻しやすくなります。

FakeDNS：接続先の仮想アドレスではなくドメイン対応を管理する

仮想アドレスの役割を理解する

FakeDNSは問い合わせを受けたドメインに仮想IPアドレスを割り当て、コア内にドメインとアドレスの対応関係を保存します。その後、アプリがこのアドレスへ接続すると、プロキシコンポーネントが対応関係からドメインを復元し、ルーティングとアウトバウンドの処理を行います。仮想アドレスは接続先サーバーの実アドレスではなく、任意のネットワークから直接アクセスできるアドレスでもありません。名前解決と接続が連携する処理経路を通ることを条件に、IPアドレスだけを持つ後続の接続からドメイン情報を復元できる点が利点です。

そのため、DNS設定にfakednsを指定するだけでは不十分です。クライアント側で対象のDNS問い合わせをFakeDNSに渡し、仮想アドレス宛ての接続を制御して、入口で対応関係を復元できるようにする必要があります。システムプロキシを使う場合、アプリが独自に名前解決してプロキシを経由せず接続すると、外部ネットワークからルーティングできないアドレスが返ることがあります。FakeDNSを有効にする前に、トラフィックをどこまで制御するか確認してください。適切に設定されていないシステムルートの代わりにFakeDNSを使うことはできません。

アドレスプールとスニッフィング対応を確認する

以下はXrayのDNSとアドレスプールの部分設定例です。TUNによるトラフィック制御の設定は含みません。198.18.0.0/15はベンチマーク用の特殊なアドレス範囲で、仮想アドレスプールとして使われることがあります。実際の接続先サイトのネットワーク範囲ではありません。社内ネットワークや他のトラフィック制御ツールが同じ範囲を使っている場合もあります。競合時はアドレスプールを広げるだけで解決せず、全体を見直す必要があります。入口の設定は対象の通信を実際に受け取るインバウンドに統合してください。使用されていないインバウンドを新設しても代わりにはなりません。

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

実際にトラフィックを受け取るXrayインバウンドには、以下のようにスニッフィングを設定できます。destOverrideのfakednsは、関連するドメインを復元するための設定です。routeOnlyは、スニッフィング結果をルーティングに使う方法を制限します。クライアントがこれらの項目を自動生成しているかどうかは、使用中のコアと生成された設定ファイルで確認してください。クライアントのTUN経路を別のコンポーネントが処理する場合、このXrayインバウンドの設定を汎用的なTUN設定として使うことはできません。

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

キャッシュと対応関係の有効期間を管理する

対応関係がどれだけ保持されるかは、トラブルシューティングの重要なポイントです。アプリが仮想アドレスをキャッシュしていても、コアの再起動後に以前の対応関係が残っていない場合があります。その結果、古い接続には仮想IPしか残らず、実際のドメインを復元できません。FakeDNSを有効にした直後は正常でも、クライアントの再起動後に一部のアプリが失敗することがあります。まずアプリの既存接続を終了し、関連するDNSキャッシュを消去してから、新たに名前解決と接続を行ってください。仮想アドレスをサーバーの恒久的なアドレスとして保存したり、別の端末にコピーしてテストしたりしないでください。

アドレスプールの容量は、保持できる対応関係の規模を制御するものであり、同時接続数や性能評価を示すものではありません。多くの異なるドメインに長時間アクセスすると、対応関係の入れ替わりとアプリのキャッシュが重なり、問題が起きることがあります。容量をやみくもに増やしても、制御されていない接続は修復できません。まず小さな範囲で、問い合わせがFakeDNSに届き、接続も同じ処理経路へ戻っていることを確認し、動作の安定性を観察します。基本動作を確認してから、コアの説明と端末のリソースに応じて容量を変更する必要があるか判断してください。

アプリによってはDNS応答を検査したり、固定アドレスを使ったり、独自の暗号化DNS問い合わせを行ったりして、想定した対応関係の経路を通らないことがあります。特定のアプリで互換性に問題がある場合は、まず他のルーティング設定を維持したまま通常のDNSに戻し、結果を比較してください。FakeDNSを無効にしたときだけ復旧するなら、サブスクリプションをすぐ変更するのではなく、対応関係を通る経路を確認します。一部のドメインに通常の名前解決を使う場合は、その後のルーティングで実アドレスを正しく処理できることも確認し、二つの判定方法が競合しないようにしてください。

動作確認では、少なくとも初回の名前解決、アプリの再起動、コアの再起動、ネットワークの切り替えをテストしてください。ログに仮想宛先アドレスだけが繰り返し表示され、ドメインが復元されない場合は、対応関係が存在するか、インバウンドが正しいかを確認してください。仮想アドレスを直結ルールに追加してはいけません。仮想アドレスを外部ネットワークに直接送っても、通常は接続先にアクセスできません。対応関係の復元とトラフィック制御の一連の処理を修復するのが正しい対応です。

複数サブスクリプション管理：取得元と更新方針を分ける

すべてを一つのリストに混ぜず、取得元ごとに整理する

複数のサブスクリプションを管理するうえで難しいのは、インポート数ではなく、設定の取得元、更新結果、使用中のサーバーの関係を把握することです。取得元ごとにグループを分け、用途、取得方法、自動更新の可否を記録するのがおすすめです。備考には実際の用途を書き、変わりやすいサーバー名に頼らないでください。手動で管理する特殊な設定は別グループにし、更新による上書きを防ぎます。複数の取得元を比較する場合は、それぞれのグループでテストしてから、どれをメインにするか決めてください。

サブスクリプションにはアドレス、ポート、プロトコル、トランスポート設定が含まれる場合がありますが、クライアントのルーティング、DNS、トラフィック制御まですべて指定できるとは限りません。形式によって適用範囲は異なり、サーバーリストだけを提供するものもあります。インポート後は、特にコアの選択とトランスポート関連の項目を確認してください。別形式に変換すると、元の形式で使えた一部の機能が失われることもあります。解析は成功しても接続できない場合は、元の設定値がすべて保持されているか見直してください。

同名項目、重複削除、更新時の上書きを整理する

二つの取得元に「予備回線」という同じ名前の項目があっても、同じサーバーとは限りません。反対に、名前が違っていても同じアドレスを指す場合があります。重複を削除する前に、プロトコル、アドレス、ポート、認証情報、トランスポート設定など、何を基準に判定するか決めてください。アドレスとポートだけを見て項目を削除すると、認証情報やセキュリティ設定が異なる有効な設定を誤って消すことがあります。重複削除機能の判定方法が不明な場合は、まずバックアップをエクスポートし、複製した設定で操作してください。唯一の接続可能なリストを直接整理しないようにしましょう。

サブスクリプション項目を手動で変更する場合は、どこまでを変更対象とするか記録してください。サーバーの備考を一時的に変えるだけなら影響は小さいものの、SNI、トランスポート経路、公鍵などは次回更新で元の値に戻る可能性があります。変更を長期的に維持する場合は、独立した手動設定として複製し、元の取得元と変更理由を記録します。設定の競合を隠すためにサブスクリプション更新を無効にしないでください。アドレスやサーバー設定が変わっても古い情報を使い続けることになり、後のトラブルシューティングが難しくなります。

グループの用途更新方針保持する内容
メインの取得元動作確認後に定期更新現在の設定と前回動作したバックアップ
予備の取得元個別に更新して一部を検証独立した取得経路と利用可能な項目
手動設定手動変更取得元、変更理由、復元に必要な設定
テスト用グループ必要なときにインポートテスト条件と結果。メイン設定は置き換えない

更新、使用する設定の選択、障害時の切り替えを分けて考える

サブスクリプションの更新、遅延テスト、使用するサーバーの選択は、それぞれ別の操作です。更新に成功しても、接続先が切り替わったとは限りません。リストの並び順を見て自動的に最適なサーバーが選ばれると考えないでください。クライアントの自動選択機能を使う場合も、実行条件、テスト先、切り替え対象を確認します。テスト先への接続成功は、すべてのサービスへの接続を保証しません。TCP接続の確立も、リクエスト全体が成功したことを意味しません。各テストの違いは遅延テストとダウンロード速度測定の違いを参照してください。

自動更新を設定する場合は、安定した長時間接続が必要な作業中を避け、更新時にコアが再読み込みされるか事前に確認してください。モバイル端末はネットワークの切り替えや省電力状態によって、スケジュールされた更新が遅れる場合があります。厳密な時刻に更新されることを前提にしないでください。重要な用途の前には、設定と接続状態を手動で確認します。複数のサブスクリプションが同じ利用不可の接続経路で取得されている場合、予備の取得元も更新できなくなることがあります。動作確認済みのオフラインバックアップを残しておきましょう。

サブスクリプションURLにはアクセス権限が含まれる場合があり、一般公開のWebリンクのように扱えません。ブラウザーの履歴、スクリーンショット、クリップボードの同期、エクスポートファイルに完全なURLが残る可能性があります。設定を共有する際は、トラブルシューティングに必要な項目だけを提供し、サブスクリプションURLや接続用の認証情報は公開しないでください。URLの漏えいが疑われる場合は、取得元の管理画面などからアクセス情報を変更してから、クライアントを更新します。ローカルのグループ名を変えても、古いURLは無効にならず、他の端末からのアクセスも防げません。

障害時は手順を決めて切り替えます。現在のグループと使用中のサーバーを確認し、サブスクリプションが直前に更新されていないか調べてから、動作確認済みの予備項目へ切り替えてください。切り替え後も障害のあった設定を複製して残し、別途テストして原因を調べます。取得元全体をすぐ削除しないでください。独立した二つの取得元が同時に失敗した場合は、端末のDNS、システム時刻、ネットワーク権限、トラフィック制御の状態を優先して確認します。複数の取得元は一部の障害の影響を減らせますが、同じ端末で発生するネットワーク問題までは回避できません。

カスタムアウトバウンド：タグ、デフォルト経路、フォールバックを管理する

設定を生成しているコンポーネントを確認する

アウトバウンドはコアが接続先への通信を確立する方法を定義し、ルーティングは各リクエストで使用するアウトバウンドを決めます。クライアントのGUIは通常、使用中のサーバー、ルーティングモード、各種設定から実行時の設定を生成します。一時的に生成されたファイルを直接編集しても、次回起動時に上書きされることがあります。継続的にカスタマイズする前に、クライアントにカスタム設定やテンプレート用の入口があるか確認し、現在の生成結果をエクスポートして比較できるようにしてください。デスクトップでは通常の設定にv2rayNのGUIを優先して使い、画面上で表現できない場合に限り、完全な設定ファイルを管理します。

Xray、V2Fly、その他のネットワークコンポーネントでは、似た項目があっても設定形式をそのまま置き換えられるとは限りません。この節の例はXray形式のJSONを想定しており、すべてのクライアントに直接インポートできるわけではありません。完全なカスタム設定を使うと、クライアントによるサーバーリストの生成処理を迂回する場合もあります。その場合、リストの項目を切り替えても接続先が変わらないことがあります。保存後は実際に起動時に使用された設定ファイル、コアの種類、設定読み込み時のログを確認し、「使われていないファイルを変更しただけ」という問題を先に除外してください。

直結と通信遮断で基本構成を検証する

以下はアウトバウンド配列の部分例です。freedomは直接接続、blackholeは一致したトラフィックの破棄を意味します。他のルールで処理されない場合、通常は最初の項目がデフォルトのアウトバウンドになるため、この例では直接接続が選ばれます。プロキシ接続の完成例ではありません。実際のプロキシアウトバウンドを追加する場合は、動作確認済みのクライアント設定から正しい接続パラメーターを保持し、ルーティングから対応するタグを参照してください。サーバーの認証情報を推測で組み立てないでください。

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

タグは短く安定した名前にし、同じ設定内で重複させないでください。アウトバウンドタグをproxyからproxy-mainに変更した場合は、古いタグを参照するルーティングや関連設定もすべて更新します。画面に表示される備考をタグの代わりに使ったり、異なる二つのアウトバウンドに同じ名前を付けたりしないでください。管理の際は「インバウンドタグ、ルール条件、接続先のアウトバウンド」の対応表を作り、参照先がすべて定義されているか確認すると、JSONのインデントだけを見るより確実です。

チェーン接続、ルーティング、障害時の自動切り替えを区別する

アウトバウンドを複数設定しても、接続方式が複数用意されるだけで、自動的に障害時の切り替えが行われるわけではありません。宛先に応じて異なるアウトバウンドへ振り分けるのがルーティングです。一つのアウトバウンドを経由して別の接続を確立するのがチェーン接続です。状態を監視して接続先を選ぶには、別途選択機能が必要です。この3つを混同しないでください。ヘルスチェックや選択ロジックを明示的に設定していない場合、最初のプロキシが失敗しても、配列に2つ目があるだけでは自動的に切り替わりません。アウトバウンドを重複して追加しても可用性は向上しません。

チェーン接続では依存関係が増えます。前段のDNS、トランスポート対応状況、安定性が後段にも影響します。経路の一部が必要な通信方式に対応していなければ、最終的なリクエストは失敗します。チェーン接続を試す前に、各アウトバウンドが単独で使えることを確認し、使用中のコアが関連項目に対応しているか調べてください。多段のチェーン接続、複雑なルーティング、異なるDNS方針を同時に追加しないでください。問題が起きた際、どの区間で失敗したか判断しづらくなり、ログから原因を特定できなくなります。

元に戻せる変更で最終設定を検証する

カスタム設定は、構文と読み込みを検証してから実際の通信を確認します。JSONとして正しくても、現在のコアがその項目に対応しているとは限りません。読み込みに成功しても、ルーティングの参照先が正しいとは限りません。起動エラーが発生した場合は、ログに示された項目を調べ、ルーティング設定全体を削除しないでください。最後に正常動作したバージョンへ戻し、アウトバウンドまたはルールを一つだけ追加します。クライアントに設定テスト機能があれば優先して使ってください。機能がない場合も、再起動前に元のファイルと復元可能なGUI設定を保存しておきます。

実際の通信を検証するには、直結するべき宛先、プロキシ経由にするべき宛先、明確に遮断するテスト用宛先を少なくとも一つずつ選び、ログとアプリの結果を確認します。遮断ルールは明確なドメインやテスト範囲に限定し、更新やDNSのリクエストまで誤って遮断しないようにしてください。接続に失敗した場合は、最後のタイムアウトだけでサーバー障害と判断せず、入口にリクエストが届いたかから始め、適用されたルール、接続先のタグ、名前解決、リモート側のハンドシェイクの順に確認します。デスクトップ版のログ画面はv2rayNのメイン画面と機能の解説を参照してください。

設定が完了したら、動作する設定、変更理由、検証条件をまとめて保存します。トラフィック制御方式、DNS経路、アウトバウンドタグを記録しておくと、「接続できる」とだけ書くより再現性が高まります。エクスポート前に不要な機密情報を削除し、他の人と共有するときは別途、情報を伏せたコピーを作ってください。後からコアやクライアントを変更する場合は、まず以前の基準設定で動作を確認してからカスタム項目を移行します。通常の接続は入門ガイドの接続・確認手順に沿って行い、複雑な設定は用途を説明でき、本当に必要なものだけ残してください。