V2Ray 応用設定ガイド

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

サブスクリプションURL、サブスクリプショングループ、サーバー項目は、それぞれ別のものとして理解しましょう。サブスクリプションURLは設定を取得するための入口、グループはURLと更新方法をクライアントに保存するための単位、サーバー項目は更新後に取得される接続設定です。この3つは同じものではありません。サーバー項目を削除しても、サブスクリプション自体は削除されず、次回の更新で再び追加されることがあります。設定をまとめて無効にする場合は、まず該当グループの自動更新を止めてから、グループや項目を削除するか判断してください。

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

v2rayNで「サブスクリプショングループ」の設定を開き、新しいグループを作成します。見分けやすいメモとサブスクリプションURLを入力して保存してください。メモには「仕事用」「一時テスト」など、取得元や用途を記録すると便利です。アクセス用パスワードは書かないでください。URLにアクセストークンが含まれる場合があるため、コピー時はクエリ部分も含めますが、完全なURLをスクリーンショットや公開ログに載せないようにしましょう。入力欄の前後に空白が入っていたら、保存前に取り除いてください。入力ミスをネットワーク障害と誤認するのを防げます。

保存後は、まずこのグループだけを更新します。更新できたかどうかは、通知が消えたかではなく、ログでリクエストの完了を確認し、項目数が妥当な範囲で変化したか、一覧にそのグループのサーバーが表示されるかで判断してください。次に、利用できることが分かっている設定を選んで現在のサーバーに指定し、クイックスタートの手順で接続を確認します。複数の取得元を同時に更新すると、ほかのグループの成功に紛れて失敗を見落とすことがあります。グループを初めて作成するときは、全件更新を避けましょう。

自動更新の間隔は、取得元の更新頻度に合わせて設定します。間隔が短すぎるとリクエストが増え、取得元でアクセス制限がかかることもあります。PCのスリープ、ネットワークの切り替え、アプリの終了中は定期更新が実行されないため、サーバー側からのプッシュ通知とは異なります。更新前に、サブスクリプションURLへ直接アクセスできるかも確認してください。現在のプロキシ経由でしか取得できない場合は、クライアントのプロキシ経由更新機能を使い、動作中の設定を少なくとも1つ残しておきます。更新経路と接続中の設定が同時に使えなくなる事態を避けられます。

表示の絞り込みと設定の削除は別

サーバーの絞り込みは通常、一覧に表示する項目を変えるだけで、サーバー自体は変更しません。まずグループを選び、名前のキーワードで絞り込むと誤操作を減らせます。名前やプロトコルによるフィルター、特定グループのみ表示する設定が有効になっていないか確認してから、項目が本当に消えたか判断してください。正規表現に対応する画面もあれば、通常の文字列検索だけの画面もあります。入力欄の説明に従い、通常のキーワードを正規表現として使ったり、その逆をしたりしないようにしましょう。

フィルターが正規表現に対応している場合は、仕事|予備でどちらかのキーワードを含む項目を、^テストで名前が「テスト」から始まる項目を検索できます。入力後は結果を確認し、すぐに一括削除しないでください。括弧、プラス記号、角括弧は正規表現で特別な意味を持ちます。取得元の名前にこれらの文字が含まれる場合は、画面の正規表現ルールに従ってエスケープしてください。マッチ方法が分からないときは、複雑な式を重ねるより、単純なキーワードに戻すほうが確認しやすくなります。

更新に失敗したときは状況を記録

一覧が空になったら、まずフィルターを解除して該当グループに切り替え、更新ログを確認します。接続タイムアウトならネットワーク経路を、解析エラーなら応答内容を重点的に確認してください。サブスクリプションの接続先がログイン画面、期限切れの通知、通常のWebページを返す場合、ネットワークリクエスト自体は成功しても、クライアントはサーバー設定として認識できません。プロトコルを何度も切り替えても解決しないため、URLが無効になっていないか、取得元でサブスクリプションURLの再発行が必要かを確認しましょう。

サブスクリプションから取得した項目を手動編集する前に、独立したローカルグループへコピーしてください。取得元を更新すると項目が再作成され、手元の変更が上書きされることがあります。元のグループは同期用、コピーしたグループは検証用と役割を分けておけば、トラブル時に取得元の設定へ戻って確認できます。Android版の v2rayNG と v2flyNG はメニューの位置が異なる場合がありますが、サブスクリプションの更新と現在のサーバー選択を分けて考える点は同じです。よくある接続トラブルはヘルプセンターも参照してください。サブスクリプションのインポートが完了する前に、DNSやルーティングも同時に変更するのは避けましょう。

ルーティングの設定例とマッチ順序

ルーティングは、コアに届いたリクエストをアウトバウンドへ振り分ける仕組みであり、アプリに接続を作らせる機能ではありません。まずリクエストがローカルプロキシに届いているか確認し、その後で振り分け結果を調べます。システムプロキシを参照しないアプリでは、ルールをどれだけ整えても通信経路は変わりません。トラブル時は、アプリの接続方法、リクエストに含まれる情報、ルールのマッチ結果、アウトバウンドへの接続の順に確認してください。この4段階を混同すると、入口の問題をルールの誤りと取り違えやすくなります。

まずルールを設定するレイヤーを確認

v2rayNのルーティング編集画面では、domain:example.comやgeosite:privateのような簡略表記を使う場合があります。ドメインとIPを別々の欄に入力する画面もあります。これはクライアント側の入力方法であり、コアのJSONにあるすべてのフィールドと同じではありません。コア設定では、ドメインをdomain配列に、ネットワーク範囲をip配列に記述します。画面の行全体を任意のフィールドに貼り付けないでください。特にip:192.168.0.0/16のような画面向けの簡略表記は、コアのIP配列要素としてそのまま使えません。

以下は、V2Flyまたは互換性のあるXrayの設定に組み込めるルーティング例です。directとproxyという名前のアウトバウンドがすでに存在することを前提としています。最初のルールはローカルアドレスを直接接続し、2つ目は例示したドメインをプロキシ経由にします。最後のルールで、それ以外のTCPとUDPのリクエストを処理します。この例はマッチ条件を示すもので、リモートサーバーの設定は含まず、単体で完全な接続設定にはなりません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

例外ルールはデフォルトルールより前に置く

ルールは通常、上から順に評価され、最初に条件を満たしたルールのアウトバウンドが使われます。すべての通信を対象にするデフォルトルールは最後に置いてください。先に置くと、後続の例外ルールが適用されません。1つのルールにドメイン、ポート、ネットワーク種別を指定した場合、通常はそれらすべての条件を満たす必要があります。同じ配列内に複数のドメインを指定すると、いずれかに一致する候補として扱われます。関係のない条件を1つのルールにまとめず、別々にすると確認しやすくなります。

domain:example.comは、指定ドメインとそのサブドメインに一致します。full:example.comは完全一致に使います。正規表現は名前に一定のパターンがある場合に有効ですが、標準の選択肢にする必要はありません。ドメインルールは、ユーザーが直接入力したIPアドレスには自動で一致しません。同じ経路で対象ネットワークも処理したい場合は、IP条件を別に追加し、ルーティング時にアドレスを参照できるDNS設定になっているか確認してください。

AsIsはIPルールのためにドメインを積極的に名前解決しません。IPIfNonMatchはドメイン条件に一致しなかった場合に名前解決を試み、IP条件とのマッチングを続けます。IPOnDemandは、IP条件が必要な場面でより早く名前解決することがあります。これらの設定はDNSの問い合わせ回数やルールのマッチに影響し、単純な速度設定ではありません。選ぶ前に、宛先IPによる振り分けが必要か、DNS問い合わせ自体が適切なアウトバウンド経由で行えるかを確認しましょう。

1つのリクエストでルールを検証

検証には、マッチすることが確実なドメインを1つ選び、開いているページを閉じるか対象アプリを再起動してから、新しい接続を開始します。既存の長時間接続は、ルールを保存しても自動的に経路が変わりません。一時的にログの詳細度を上げ、宛先、インバウンドのタグ、アウトバウンドのタグが想定どおりか確認し、完了後は通常のログレベルに戻してください。IPしか記録されずドメインが見えない場合は、アプリがホスト名を渡しているか、そのプロトコルでトラフィックのスニッフィングが使えるかを確認します。

ルールで参照する地理データは、利用中のクライアントとコアが提供している必要があります。データファイルや分類名が見つからないエラーが出た場合は、読み込みに失敗した状態をルール順の変更で隠そうとせず、まずデータの取得元を修復してください。GUIのルーティング設定はコアの再起動時に再生成される場合があります。長期的に使うルールはクライアントで保存し、一時生成されたファイルを直接編集しないでください。項目間の関係は設定ファイルのJSON構造を詳しく解説も参照し、書式エラーとマッチ条件の問題を分けて対処しましょう。

DNS設定の最適化と名前解決の経路

DNSのトラブルシューティングでは、アプリやOSのリゾルバー、プロキシコアのリゾルバー、プロキシ経由でアクセスするリモートサービスの3つを分けて考えます。ブラウザーでセキュアDNSを有効にすると、システムのリゾルバーを経由しないことがあります。アプリがドメインをSOCKSの入口に渡す場合は、プロキシ側で名前解決が続けて処理されることもあります。クライアントのDNSアドレスを変更しても、端末上のすべてのプログラムがそのアドレスを使うとは限りません。どのレイヤーでリクエストがIPアドレスに変わるかを整理してから、変更する設定を決めましょう。

サーバーのドメインと宛先のドメインを分けて考える

プロキシサーバーをドメイン名で指定している場合、プロキシ接続の確立前に名前解決が必要です。この処理を、まだ確立していないプロキシ経路に任せると循環依存が起きます。一方、接続先Webサイトのドメインは、振り分けの要件に応じて直接名前解決するか、プロキシ経由で問い合わせるか選べます。役割の異なる2種類のドメインを、曖昧な「すべてリモートDNS」の設定でまとめないようにしてください。起動後にまったく接続できない場合は、まずサーバーのドメインを独立した経路で名前解決できるか確認します。

v2rayNのDNS設定を開いたら、まずどのコア向けの設定を編集しているか確認してください。コアのバックエンドによって項目、既定の動作、利用できる通信方式が異なる場合があります。あるバックエンド向けのJSONを別のバックエンドに貼り付けてはいけません。以下はV2Fly形式の内蔵DNS設定の例です。例示用ドメインに静的アドレスを割り当て、指定したリゾルバーにIPv4アドレスを問い合わせます。この設定の対象は内蔵リゾルバーを使うリクエストのみで、システムDNSを自動的にすべて取り込むものではありません。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

例に記載した静的アドレスは説明用であり、実在するWebサイトへの接続確認には使えません。実際に設定する際は例示用のマッピングを削除するか、自分が管理するドメインと正しいアドレスに置き換えてください。静的マッピングは、明確で安定した内部サービスに向いています。一方、コンテンツ配信サービスのアドレスを長期間固定する用途には適しません。地域、ネットワーク、時間帯で異なるアドレスが返されることがあり、無理に固定すると接続エラーにつながります。

最適化の前に比較基準を作る

一度に変更するのは1項目だけにします。同じ接続中サーバー、同じルーティング設定、同じテスト用ドメインを使い、名前解決の経路だけを変えて新しい接続を試してください。サーバーとDNSを同時に変更すると、改善しても原因を特定できません。システムのDNS確認ツールで分かるのは、そのツール自身が使用した名前解決経路です。コアのDNSが正常に動作している証明にはなりません。コアのログと実際のアプリのリクエストを併せて確認し、問い合わせ先、応答の種類、その後の接続に使われたアドレスを見ましょう。

IPv4とIPv6は、実際に利用できる出口に合わせて設定します。IPv6アドレスを取得できても出口にIPv6経路がなければ、アプリが失敗を待ってからIPv4へフォールバックし、DNSが遅いように見えることがあります。切り分けのために一時的にIPv4に限定する方法はありますが、あらゆるネットワークで使う固定設定にはしないでください。IPv6が必要な場合は、ローカルネットワーク、プロキシサーバー、コアのアウトバウンド、ルーティング対象のネットワーク範囲を併せて確認しましょう。AAAAレコードへの応答だけを残し、その後の接続性を見落とさないようにしてください。

暗号化DNSとキャッシュの範囲

暗号化DNSを使う場合は、リゾルバーへの接続経路、証明書の名前、初回の名前解決も考慮する必要があります。リゾルバーをドメイン名で指定すると、その名前自体の初回解決が必要です。特定の記述形式では、通常のアウトバウンドルーティングに従わず、ローカルから直接問い合わせることがあります。具体的な動作は、利用中のコアが対応するDNS形式に基づいて確認してください。アドレスが暗号化プロトコルで始まるという理由だけで、問い合わせが必ず現在のプロキシを通ると判断しないでください。

設定を保存しても、クライアント、OS、ブラウザーのキャッシュやアプリの長時間接続には、以前の状態が残る場合があります。まず新しい接続でテストし、必要なキャッシュだけを消去してください。毎回ネットワーク全体をリセットする必要はありません。コアのログに正しいアドレスが記録されているのにアプリが古い接続先へアクセスする場合は、アプリのキャッシュを確認しましょう。TUNでは、DNSの取り込みが対象リクエストを実際に処理しているかも確認します。取り込まれていない問い合わせは、内蔵DNSの設定を変えても経路が自動で変わるわけではありません。

TUNモードと仮想ネットワークインターフェースによる通信の取り込み

システムプロキシは、アプリにローカルプロキシの入口を知らせる仕組みです。アプリがその設定を使うかどうかは、アプリの実装によります。TUNは仮想ネットワークインターフェースとシステムルートを使い、条件に合うIP通信を処理経路へ送ります。入口が異なるため、同じスイッチの強弱として単純に捉えることはできません。通常のシステムプロキシが動作していても、プロキシ設定を参照しないアプリがある場合にTUNを検討してください。基本設定の誤りを、複雑な通信取り込み設定に持ち込まないようにしましょう。

有効にする前に権限と既存ルートを確認

まず現在のルーティング設定、接続中のサーバー、DNS設定を記録し、TUNを無効にしても通常の接続に戻せることを確認します。ほかのVPN、仮想ネットワークインターフェース、通信取り込みソフトが起動していないかも確認してください。複数のツールがデフォルトルートを取り合うと、どれも有効に見えても通信が別の経路へ流れることがあります。テスト中は通信取り込みの仕組みを1つだけにし、それぞれの動作範囲を確認してから併用を検討しましょう。

Windowsで仮想ネットワークインターフェースを作成したりルートを変更したりするには、通常、管理者権限が必要です。macOSやLinuxでは、システムの許可や対応するサービスコンポーネントが必要になる場合があります。v2rayNの画面に表示される権限の案内に従い、通常権限で起動し直してスイッチの色だけを見ることは避けてください。権限不足、コンポーネントの欠落、設定構文の誤りはそれぞれ別の問題です。起動ログで原因を確認しましょう。インストーラーを選ぶ際はクライアントのダウンロードページに戻り、OSとCPUアーキテクチャを確認してください。

v2rayNのTUN機能は、V2FlyやXrayのJSONに共通フィールドを1つ追加するのではなく、独立した通信取り込みバックエンドが処理する場合があります。そのため、ネット上の任意のTUN設定をすべてのコアで使える構文として扱わないでください。まずクライアントのスイッチや設定項目を使い、対応するバックエンドの設定をクライアントに生成させます。高度な項目を編集するのは、バックエンドの種類と設定入口を確認してからにしてください。

段階的に有効にして接続を確認

有効にした後は、仮想ネットワークインターフェースが作成されたか、ルートが追加されたか、DNSが想定どおり取り込まれたか、対象アプリの新しい接続がログに記録されたかを順番に確認します。スイッチがオンになっただけでは、各処理の完了を意味しません。まず一般的なWebページをテストし、次にシステムプロキシを使わないアプリを試してください。Webページも開かない場合は、いったん無効にして基本の接続が復元するかを確認します。MTU、ルーティングテーブル、サーバー設定を同時に変更しないでください。

プロキシサーバーへの接続には、正しい出口が必要です。同じプロキシ経路に再度取り込まれてはいけません。クライアントが通常は除外や保護の設定を生成しますが、複数のネットワークインターフェース、モバイルホットスポット、ネットワーク切り替えによって出口の選択が変わることがあります。接続の繰り返し、接続数の異常な増加、サーバーアドレスが取り込み経路に何度も入る状態がログに見られたら、TUNを無効にしてください。再試行回数を増やすのではなく、サーバーアドレスの除外設定とデフォルトの出口インターフェースを確認しましょう。

LANの除外ルールは、よく使われるプライベートアドレス範囲をそのままコピーするのではなく、実際のネットワークを対象に設定してください。社内ネットワーク、仮想マシン、コンテナでは、別のアドレス範囲や特定のインターフェースを使うことがあります。社内ネットワークに接続したときだけ失敗する場合は、接続前後のルートを比較しましょう。LAN機器からこのPCのプロキシを使えるようにする機能は、待ち受けアドレスやファイアウォールにも関係する別の設定です。TUNのスイッチでは代用できません。詳しくはLAN向けプロキシ共有の設定を参照してください。

通信方式への対応とネットワークインターフェースによる取り込みを分けて考える

TUNが特定のパケットを受信できても、リモート側のアウトバウンドがそのパケットを正しく転送できるとは限りません。UDPアプリの動作は、サーバー設定、通信方式、ネットワーク環境にも左右されます。ネットワーク診断ツールの制御用パケットは、プロキシの実用性を判断する基準として適さない場合があります。単一の診断結果だけで通信状態を判断せず、対象アプリが実際に使うプロトコルで検証し、ログで転送経路を確認しましょう。

一部のページの読み込みが止まる場合は、DNS、ルーティング、UDP経路を確認してからMTUを調べます。大きなパケットは、一部の経路でフラグメント化や経路MTU探索の問題を起こすことがありますが、MTUをむやみに小さくすると根本原因を見落とします。元の値を記録し、一度に1項目だけ変えて同じ通信を再テストしてください。改善しなければ元に戻します。有効化と元に戻す手順はv2rayN TUNモードの設定も参照してください。高度な設定を一度にすべて有効にするより、いつでも戻せる状態を保つことが大切です。

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

FakeDNSが返すのは接続先サービスの実アドレスではなく、プロキシが対応関係を管理する合成アドレスです。アプリがそのアドレスに接続すると、処理経路で元のドメインをマッピングから復元し、ルーティングやリモート接続を行います。これは、一部の入口ではIPしか取得できず、その後の処理でドメインを使いにくい問題を解決する仕組みです。通常のDNSにキャッシュを追加する機能の別名ではありません。まずこの仕組みを理解してから、現在の入口に必要か判断しましょう。

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

最低限、4つの段階が必要です。問い合わせがFakeDNSに届くこと、アプリが合成アドレスを受け取ること、接続がマッピングを保持する処理系に戻ること、処理系がドメインを復元してアウトバウンドを選ぶことです。どれかが欠けると、合成アドレスが通常の宛先としてネットワークへ送られてしまう可能性があります。アドレスプールを設定しただけで、問い合わせと後続の接続を取り込まなければ機能しません。まず現在のクライアントとバックエンドがこの機能に対応しているか確認してください。

V2Fly形式のFakeDNS設定と、一部のTUNバックエンドが提供する合成アドレス機能は、同じ構文ではありません。名前が似ていても、アドレスプール、キャッシュ、永続化、ドメインの除外方法が異なる場合があります。一方のバックエンドのスイッチと、別のバックエンドのアドレスプールを組み合わせないでください。以下の例は、この構文に対応するV2Fly設定で、アドレスプール、DNS、インバウンドのスニッフィングがどう関係するかを示します。組み込む際は既存のアウトバウンドとルーティング設定も残してください。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

この設定例だけでは、OSのDNS問い合わせを自動的にコアへ転送できません。アプリが別のリゾルバーから実アドレスを取得した場合、その問い合わせではFakeDNSのプールは使われません。合成アドレスを取得しても、プロキシを通さず直接接続すれば同様に失敗します。テストでは、問い合わせと接続の両方が同じ処理経路を通っていることを確認しましょう。現在のXrayやほかのバックエンドが同じ項目に対応しているかは、クライアントの設定画面で確認してください。この例だけで互換性を判断しないでください。

アドレスプールは接続先のネットワーク範囲ではない

合成アドレスのプールは、実際に使用しているネットワーク設計と分けて確認する必要があります。例で使われるアドレス範囲が、テスト環境や内部ネットワークで実際に使われていることもあります。範囲が重複すると、宛先IPだけでは接続が実サービス向けなのか、合成マッピングなのかを判別できません。ルーティングテーブルと内部ネットワークの用途を先に確認し、バックエンドが許可するアドレスプールを使ってください。衝突を避けるために、任意のパブリックアドレス範囲へ変更するのはやめましょう。

プールの容量は、管理できるマッピングの規模を制限するもので、同時接続数とは異なります。多数のドメイン、頻繁なネットワーク切り替え、アプリ内に長期間残るキャッシュによって、以前のアドレスと現在のマッピングが一致しなくなることがあります。コアを再起動した後も、アプリが古い合成アドレスを保持している場合は、古い接続を繰り返し試すのではなく、アプリに再び名前解決させてください。ブラウザーのページを閉じるだけではシステムキャッシュが消えるとは限りません。実際にキャッシュされているレイヤーに応じて対処しましょう。

宛先アドレスが特定のアドレス範囲に属するか確認したり、名前解決結果を長期間保存したりするアプリもあります。そのようなアプリは合成アドレスに適さないことがあります。除外が必要な場合は、対応するDNSルールで対象ドメインに実アドレスを返し、その実アドレスへの接続も必要な経路で処理されるように設定してください。DNS合成からの除外と直接接続は別の設定です。実アドレスを返した後でも、プロキシのアウトバウンドを使えます。

ドメインルーティングと併せて確認

有効にした後は、まずドメインを1つ選んでテストしてください。ログで合成アドレスからドメインが復元され、その後に想定したルールへ一致することを確認します。合成アドレスが汎用IPルールに直接一致する場合は、アドレスプール全体を特定のアウトバウンドへ無理に割り当てず、まず復元処理を確認しましょう。プール全体を転送すれば一時的に症状が変わることはありますが、失われたドメインは復元されず、意味のない宛先アドレスがリモート側へ送られる可能性があります。

SOCKSのドメイン入口がすでに安定して動作し、ドメインで振り分けられる場合、FakeDNSを追加しても効果がないことがあります。FakeDNSは、IPの入口からドメインを復元する必要があり、問い合わせと接続をまとめて制御できる場合に適しています。テスト後は、有効にした理由、対象となる入口、除外ドメイン、元に戻す方法を記録してください。コアや通信取り込みバックエンドを変更した際は再検証し、以前のアドレスプールをそのままコピーしただけで移行が完了したと考えないようにしましょう。

複数サブスクリプションの管理と更新範囲

複数サブスクリプションの管理でまず整理するのは取得元と用途です。サーバーを1つの一覧に詰め込むことが目的ではありません。取得元ごとに基本のグループを作り、手動で試す設定は独立したローカルグループに保存する方法がおすすめです。同じ取得元に用途の異なる接続先がある場合は、メモに用途を記録し、似た名前のグループを何度も更新するのを防ぎましょう。グループ構成が明確なら、各項目の取得元や変更理由、日常接続に使う設定も把握しやすくなります。

同期するデータとローカルの変更を分ける

サブスクリプションから取得したサーバー設定は取得元が管理するデータです。ローカルのメモ、並び順、手動変更はクライアント側の状態です。これらが更新後も保持されるかは、クライアントが項目を識別する方法によります。名前が同じなら同一項目として扱われるとは限りません。取得元で名前、ポート、識別子が変更されると、クライアントが別の項目として再作成することがあります。大事なローカル変更は手動グループにコピーして目的を記録し、元のグループは同期用として使いましょう。

重複項目を表示名だけで削除しないでください。同じ名前でもポート、プロトコル、通信方式、セキュリティ設定が異なる場合があります。名前が違っても接続先が同じこともあります。整理するときは、取得元を確認し、接続設定と実際の用途を比較しましょう。クライアントに重複削除機能がある場合は、どの項目で重複を判断するかを確認し、設定をエクスポートしてから実行してください。判断に迷う項目は一括削除せず、テスト用の範囲に移して様子を見るほうが復元しやすくなります。

ローカルグループとサブスクリプショングループでは、更新方法も分けてください。手動グループにサブスクリプションURLを入力する必要はありません。URLを保存すれば、中の変更もすべて自動管理されると誤解しないようにしましょう。サブスクリプションの更新でプロトコル設定が変わった場合は、まず元のグループで新しいサーバーを確認し、その後でローカルのテスト項目を移行するか判断します。取得元の項目に古い設定を上書きすると、次回の更新でも競合します。

更新順序と障害時の代替手段を決める

まず、少なくとも1つの取得元へ現在のネットワークから直接アクセスできるか、すべての取得元がプロキシ経由かを確認します。プロキシ経由で更新する場合は、接続中のサーバー選択が更新の成否に影響します。日常の更新はグループごとに行い、まず接続中ではない取得元を更新して接続を確認してから、現在の接続先に使っている取得元を更新しましょう。接続と設定同期が同時に変わる状況を減らし、あるグループの応答がおかしい場合も比較用の設定を残せます。

サブスクリプションを複数登録しても、自動フェイルオーバーが行われるとは限りません。通常のグループは設定の整理に使うもので、接続中のサーバーの切り替えはユーザーが行う場合があります。クライアントが対応する選択機能やスケジューリング機能を明示的に設定した場合に限り、別のアウトバウンドへ自動で切り替わることを期待できます。スケジューリングで使う接続テストの条件も別途確認してください。サーバーが複数登録されているだけで、接続に失敗するとコアが次のサーバーを自動選択すると考えないようにしましょう。

速度テストの結果だけで、長期的な優先順位を決めることもできません。接続の確立、Webページの表示、継続的なデータ転送では、測定する指標が異なります。テスト先によって結果が変わることもあります。まず用途に合ったテスト方法を選び、条件をそろえて比較してください。テスト中はネットワーク、ルーティング、DNSを同じ状態に保ち、ネットワーク切り替えの影響を取得元の違いと取り違えないようにしましょう。設定がテストに失敗した場合は、必要なプロトコルや通信方式が有効になっているかも確認します。

設定を移行し、サブスクリプションURLを保護

PCを移行する前に、クライアント設定、サブスクリプションURL、ローカルで手動追加したサーバーがすべてエクスポート対象に含まれるか確認してください。サーバーだけがエクスポートされ、ルーティング、DNS、通信取り込み設定は含まれない場合があります。インポート後は項目を1つずつ確認し、サーバーがそろっているというだけでTUNを有効にしないでください。まず通常のプロキシ接続、次に振り分け、最後に高度な通信取り込みを復元すると、移行時の問題を段階ごとに特定できます。

サブスクリプションURLはアクセス権を持つ場合があるため、機密情報として保存してください。トラブル対応の情報を共有するときは、エラーの種類や状態を残しつつ、完全なURL、認証情報、サーバーの認証設定は隠します。URLが漏えいした疑いがある場合は、取得元で新しいURLを発行してクライアントを更新してください。グループのメモを変更するだけでは対処になりません。使わなくなった取得元を削除した後も、その項目をローカルグループにコピーしていないか確認し、誤って選択するのを防ぎましょう。

複数の取得元が同時に更新に失敗した場合は、システム時刻、DNS、現在のネットワーク、プロキシ経由の更新経路、ローカルファイアウォールなど、共通の依存要素から確認します。1つの取得元だけが失敗する場合に限り、そのURLと応答を重点的に調べましょう。この順序なら、全体的な障害を個々のサブスクリプションの問題と誤認しにくくなります。ブラウザーではアクセスできるのにクライアントの更新が失敗する場合は、両者のプロキシ経路と名前解決経路を比較してください。ブラウザーが正常だからといって、PC側の設定に問題がないとは限りません。

カスタムアウトバウンドと設定全体の動作確認

アウトバウンドは、コアがリクエストを次の接続先へ送る方法を定義し、ルーティングは使用するアウトバウンドを選びます。カスタムアウトバウンドは、特殊な上流サーバー、固定のローカル転送経路、明確なプロキシチェーンが必要な場合に使います。通常のサブスクリプションをインポートするために必要な設定ではありません。作業前に、動作確認済みの通常設定をv2rayNに残しておきます。現在使っているのが、クライアント管理のサーバー、完全なカスタム設定、既存設定に追加できる断片のどれかも確認してください。3つの入口では、項目の上書き方法や保存動作が異なります。

タグでインバウンド、ルール、アウトバウンドをつなぐ

tagは設定内で使う名前です。ルーティングのoutboundTagは、既存アウトバウンドのタグと完全に一致させる必要があります。大文字・小文字や綴りを変更しないでください。用途が分かる短い名前を付け、サーバーのパスワードや完全なアドレスはタグに含めないようにしましょう。タグがない、重複している、存在しない項目を参照している場合、起動に失敗したり、想定と異なる経路が選ばれたりすることがあります。

以下は、単体で起動できるローカル転送の例です。V2Flyと互換性のあるXrayでよく使われる構造を用い、ループバックアドレスでSOCKSインバウンドを待ち受け、すべての通信をローカルの別のSOCKSサービスへ転送します。ローカルのポート20808で独立した上流サービスが動作している必要があります。上流がなければ、設定の構造確認には使えても実際の接続は失敗します。リモートサーバーの認証情報は含まれていないため、サブスクリプションから取得した実際の設定の代わりにはなりません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 20808
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "network": "tcp",
        "outboundTag": "upstream-socks"
      }
    ]
  }
}

この例では、確認対象をTCPに絞り、上流のUDP対応を前提としないためUDPを無効にしています。待ち受けアドレスはループバックインターフェースに限定されており、このPC内だけで使う設定です。テストを簡単にするために、すべてのネットワークインターフェースで待ち受ける設定に変更しないでください。共有が必要な場合は、接続元の制限、認証、ファイアウォールを別途設定します。ポートが既存クライアントの待ち受けと重なると起動に失敗しますが、これはリモート接続の問題ではありません。

プロキシチェーンのループを防ぐ

転送チェーンでよくある問題は、入口が自分自身を指していること、または上流がシステムプロキシ経由で現在の入口に戻ってしまうことです。設定前に「アプリ、ローカルインバウンド、選択したアウトバウンド、独立した上流、最終的な宛先」の順に経路を書き出してください。各段階の待ち受けアドレスとポートを記録し、「プロキシを通す」のような曖昧な表現だけで済ませないようにしましょう。上流でもTUNを有効にしている場合は、上流サーバーへの接続が下流のTUNに再び取り込まれないことも確認します。

どの段階でドメインを名前解決するかも明確にします。アプリがドメインを渡す場合、上流のSOCKSサービスがそのドメインを処理できることがあります。アプリが事前にIPアドレスを渡した場合、信頼できる復元機能がない限り、その後の経路では通常そのIPが使われます。アウトバウンドのチェーンが誤った名前解決を自動で修正したり、非対応の通信方式を上流に追加したりすることはありません。チェーンをテストするときは、まず上流が単独で動作することを確認してから、下流の転送を追加しましょう。

完全なカスタム設定を使うと、クライアントが自動生成する一部のルーティングやDNS設定が適用されない場合があります。保存前に画面の説明を確認し、システムプロキシの入口が実際の待ち受けポートを指しているか確認してください。GUIでルーティングを変更しても、カスタム設定に自動で反映されるとは限りません。反対に、一時生成ファイルは次回起動時に上書きされる場合があります。長期的に使う設定は、クライアントが正式に対応する設定入口で管理し、元のファイルも復元用に保存しておきましょう。

構造、入口、経路選択、出口の順に確認

まずJSONの構文を確認し、次にコアが各項目に対応しているか確認します。JSONとして正しいのは、括弧、カンマ、文字列の構造が正しいという意味にすぎず、設定の意味まで正しいとは限りません。起動ログに未対応のプロトコル、見つからないタグ、ポートの使用中などが表示されたら、まずローカルのエラーを解消します。コアが安定して起動したら、1つのアプリからリクエストを送り、インバウンドが接続を受け取ったか、ルーティングが想定したアウトバウンドを選んだか、上流が接続を受け付けたかを確認してください。

ブラウザーでは接続できるのにターミナルで失敗する場合は、アウトバウンドを変更する前に、ターミナルがローカルの入口を実際に使っているか確認します。ターミナルのプログラムによっては、プロキシ環境変数や起動オプションを個別に設定する必要があります。システムプロキシがすべてのプログラムに適用されるわけではありません。詳しくはシステムプロキシが機能しない場合：ブラウザーとターミナルを個別に確認を参照してください。毎回新しい接続を使って確認しましょう。既存のセッションでは以前の出口が使われ続けることがあります。

最後に、設定を読み込めるか、対象のリクエストがどのルールに一致するか、どのアウトバウンドを使うか、高度な機能を無効にしたとき元に戻せるかを記録してください。さらに、サブスクリプションの更新、LANアクセス、必要なUDP通信を個別に確認し、Webページを1つ開いただけで判断しないようにしましょう。確認後は通常のログレベルに戻し、一時的なルールや不要な入口を削除します。クライアントやコアを変更した後も同じ手順で再テストしてください。設定ファイルをインポートできても、すべての動作が以前と同じとは限りません。