V2Ray詳細設定ガイド

個別に更新できるサブスクリプショングループを作成する

サブスクリプションURLは設定一覧を取得するためのもので、クライアントが接続サービスを提供するものではありません。インポートする前に、URLの提供元が信頼でき、有効期限内であること、アカウント管理ページのURLと取り違えていないことを確認してください。v2rayNで「サブスクリプション」から「サブスクリプショングループの設定」を開き、グループを新規作成して、見分けやすい名前とサブスクリプションURLを入力して保存します。メニューの配置は画面の更新で変わる場合がありますが、「グループ設定」と「サブスクリプションの更新」は別の操作です。URLを保存すると取得元が登録され、更新を実行するとサーバー設定が取得・解析されます。

グループ名には「メイン」「予備」「手動設定」など、取得元や用途が分かる名前を付けましょう。日付だけの名前や、アカウントのパスワードを含む名前は避けてください。グループを作成したらメイン画面に戻り、更新するグループを選択して「サブスクリプション」メニューから更新します。初回は一つのグループだけを更新し、新しいサーバーが表示されること、プロトコル・アドレス・トランスポート設定が正しく認識されることを確認してから、次の取得元を追加してください。問題が起きても、どのインポートで変化したか特定しやすくなります。

表示の絞り込みと設定の変更を分ける

メイン画面のグループ切り替え、検索欄、フィルターは通常、現在の一覧表示にだけ影響し、通信の振り分けルールを自動で追加するものではありません。名前で検索する場合は、まず変わりにくい短い語句を入力し、グループによる絞り込みも有効になっていないか確認してください。一覧が突然空になっても、「選択中のグループ」と「検索条件」の組み合わせで表示範囲が狭まっただけで、サブスクリプションの内容が削除されたとは限りません。検索を解除してすべてのグループに戻し、再インポートが必要か判断しましょう。絞り込みの状態を確認せずに同じサブスクリプションを何度も追加すると、重複が発生しやすくなります。

クライアントにサブスクリプション単位のフィルター式がある場合は、入力欄が含める条件、除外条件、名前の書き換えのどれに使うものかを確認し、用途を混同しないでください。正規表現に対応すると明記された欄でのみ、正規表現を使用します。たとえば^(仕事|予備)-は、指定した接頭辞で始まる名前に一致します。サーバーの稼働状況を確認したり、地域名を認識したりするものではありません。まず通常の検索で対象範囲を確かめてから、条件をサブスクリプション設定に移してください。式を保存した後、インポート結果に反映させるには、サブスクリプションの再更新が必要な場合があります。

更新に失敗したら取得経路を確認する

サブスクリプションURLをブラウザーで開けても、クライアントが同じネットワーク経路でアクセスできるとは限りません。まずURLが完全か確認し、コピー時に改行や空白、末尾の句読点が混入していないかチェックします。次に、通常の更新とプロキシ経由の更新を区別してください。後者は、利用可能なプロキシのアウトバウンドが必要です。使えるサーバーがない状態では、「接続するには更新が必要だが、更新するには接続が必要」という循環に陥ることがあります。その場合は、直接アクセスできるサブスクリプションURLを使うか、以前に動作を確認した設定に戻してください。ネットワーク関連のスイッチを次々に切り替えるのは避けましょう。

取得した応答の内容も確認してください。ログイン画面、エラーメッセージ、空の応答は有効なサブスクリプション一覧ではありません。共有リンクとサブスクリプションURLも別の種類の入口です。サーバー単体の共有リンクは、クライアントの対応するクリップボードインポート機能で取り込んでください。コピーできるからといって、サブスクリプションURL欄に入力してはいけません。インポート方法の違いはサブスクリプションURLのインポート方法をご覧ください。トラブルシューティングで記録するのは、エラーの種類、グループ名、操作手順までにしてください。URLにはアカウント情報が含まれる場合があるため、公開のスクリーンショットに完全なURLを載せないでください。

整理後は、各サブスクリプションの取得元が個別のグループに分かれ、手動設定とサブスクリプション由来のサーバーが別々に保存され、フィルターを解除すれば一覧全体を確認できる状態にします。そのうえで、動作確認済みのサーバーを一つ選んで接続をテストしてください。サーバーが表示されること、選択されていること、実際のアウトバウンドに使われることは、それぞれ別の状態です。以降のルーティング設定は、これらを確認してから進めてください。

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

ルーティングが処理するのは、コアに入った接続です。アプリがシステムプロキシを使わず、TUNにも取り込まれていない場合、ルーティングを変更してもアクセス経路は変わりません。v2rayNの「ルーティング」または関連設定を開き、まず現在どのルールセットが使われているか確認してから、ルールの順序を調べてください。Xrayで一般的なフィールドルーティングでは、通常ルールを上から順に照合し、最初に一致したルールのアウトバウンドが選ばれます。そのため、特定ドメインの例外は広い範囲に一致するドメインのルールより上に置き、広範囲に一致する最終ルールは末尾に置きます。名前やメモから優先順位を推測しないでください。

一つのフィールドルールに異なる条件フィールドを指定した場合、通常はすべての条件を満たす必要があります。同じフィールドに複数の値を指定した場合は、そのうち一つに一致すればよいのが一般的です。たとえばドメインとポートを同時に指定すると、対象はドメイン条件とポート条件の両方を満たさなければなりません。「このドメイン群またはこのポート群」という条件にしたい場合は、ルールを分けてください。ルールに一致しない場合、Xrayの標準設定では通常、最初のアウトバウンドがデフォルトとして使われます。GUIクライアントがフォールバック用ルールを自動生成する場合もあるため、カスタム設定だけでなく、実際に生成された設定を確認してください。

ドメインリスト、IPアドレスリスト、名前解決方針

geosite:cnはドメインリストの参照、geoip:privateはプライベートIPアドレスリストの参照です。前者はドメインルールのデータ、後者はIPアドレスルールのデータに依存します。オンラインサービスの名前ではなく、不足したデータファイルを自動で補うものでもありません。ドメインルールが一致するのは、コアが対象のドメイン名を把握できている場合に限られます。入口からIPアドレスしか渡されず、ドメイン名を復元する手段やスニッフィング情報も信頼できない場合、ドメインルールが必ず適用されるとは限りません。逆に、ドメイン宛ての通信にIPルールが有効かどうかは、ルーティングのドメイン解決方針にも左右されます。

以下のJSONは、Xrayのトップレベル設定に統合するための例です。プライベートアドレスへの直接接続、指定ドメインへの直接接続、広告ドメインのブロックを示しています。直接接続を最初のアウトバウンドにしているため、どのルールにも一致しない接続も直接接続されます。プロキシ設定全体を含むものではありません。既存の設定に同じ名前のアウトバウンドがある場合は、重複して定義せず再利用してください。GUIクライアントでは、まずルールエディターで同等のルールを作成し、クライアントが生成するタグを確認してください。ルール配列だけを受け付ける入力欄にJSON全体を貼り付けないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

大量のルールを一度に追加せず、対象を一つずつ検証する

ルーティングを検証する際は、再現しやすい対象を一つ選び、想定するアウトバウンドを記録してから、ログに表示される実際のアウトバウンドタグを確認してください。新しいルールを保存したら、クライアントの指示に従って設定を再読み込みするかコアを再起動し、アプリの既存接続を閉じてから再試行します。長時間の接続は以前の経路を使い続ける場合があり、ブラウザーのキャッシュによってページが変わらないように見えることもあります。ページを再読み込みするだけでは、新しいルールが使われた証明になりません。ルールに一致しない場合は、現在のルールセット、ルールの位置、ドメインの形式、データファイルの有無、入口から渡される情報の順に確認してください。

LAN機器、共有プリンター、内部サービスへの接続に問題がある場合は、まず個別のアドレス範囲を確認してください。LANの問題を一つ直すために、すべての通信を直接接続へ変更するのは避けましょう。社内ネットワークのDNSでしか解決できない内部ドメインもあり、名前解決とルーティングの両方を設定する必要があります。直接接続ルールに一致してもDNSが正しいとは限らず、ドメイン名を解決できても適切なアウトバウンドで接続されるとは限りません。ログに対象、マッチした条件、アウトバウンドタグを併せて記録すると、ルールの問題と名前解決の問題を切り分けられます。

最後に、小さく明確なルールセットを復旧用の基準として残してください。ルールの種類を追加するたびに、一般的なWebサイト、LAN上のリソース、特別な振り分けが必要な対象を確認します。特定ドメインだけに問題があるなら、個別の例外を追加するかルールの順序を修正し、ルールセット全体を消去しないでください。ルールが増えるほど、用途を明記することが重要です。適用範囲を説明できない広範囲のルールは、ルールが足りない状態よりもトラブルシューティングを難しくすることがあります。

ドメイン名の問い合わせ経路を整理する

DNSはドメイン名をIPアドレスに変換しますが、一台の端末に複数の名前解決経路が存在する場合があります。システムのリゾルバーは一般的なアプリに使われ、ブラウザーが独自のセキュアDNSを使うこともあります。プロキシコアも、ルーティングの判定、直接接続のアウトバウンド、上流への接続のために名前解決を行う場合があります。クライアントに「リモートDNS」を設定しても、すべてのアプリがそのDNSを使うとは限りません。設定を変更する前に、対象アプリがドメイン名をプロキシに渡しているのか、ローカルでIPアドレスに解決してからプロキシに渡しているのかを確認してください。二つの入口ではルーティングに渡される情報が異なるため、調査方法も変わります。

システムプロキシモードでは、プロキシ対応アプリはドメイン名もローカルプロキシに渡すことが多いものの、具体的な動作はアプリとプロトコルによって異なります。TUNで通信を取り込む場合、システムのDNSリクエストがクライアントに入るかどうかは、仮想NIC、DNSの取り込み設定、除外設定にも左右されます。ブラウザー内蔵の暗号化DNSは、システムのDNS経路を迂回する場合があります。比較可能なテスト環境を作るには、まずブラウザーを一時的にシステムの名前解決に切り替えて基本経路を確認し、その後でセキュアDNSの設定を個別に検証してください。複数のリゾルバーを同時に変更しないようにします。

DNSサーバー、問い合わせタイプ、ルーティングは別の設定

DNSサーバーを選ぶ際は、現在のネットワークから接続できるか、内部ドメインを解決できるか、問い合わせをどの経路に通すかを考慮してください。1.1.1.1を入力するのは、パブリックDNSリゾルバーのアドレスを指定するだけで、問い合わせをプロキシ経由にする設定ではありません。暗号化DNSは端末からリゾルバーまでの問い合わせを保護できますが、利用するにはネットワーク接続が必要です。リゾルバーがドメイン名で指定されている場合は、その名前を解決するための事前の問い合わせが問題になることもあります。起動直後から名前解決できない場合は、予備のアドレスを追加し続けるのではなく、まずリゾルバー自体に到達できるか確認してください。

以下はXrayのDNSトップレベル設定例です。DNSサーバー一つとIPv4の問い合わせ方針のみを示しています。通信の入口を作る設定ではなく、システムDNSを自動で変更するものでもありません。現在のコアが該当フィールドに対応していることを確認してから統合してください。クライアントが設定を生成する場合は、クライアントに用意されたDNS設定を優先します。UseIPv4はIPv6経路の問題を切り分けるのに役立ちますが、あらゆるネットワークで長期的に推奨される値ではありません。IPv6を必要とするサービスで利用可能なアドレスを取得できなくなる場合があります。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

振り分けDNSとキャッシュの注意点

内部ドメインにアクセスする場合は、そのドメインを解決できる内部リゾルバーを残し、コアが対応するドメイン条件に従って問い合わせ先を設定してください。一般向けDNSは通常、組織内のホスト名を解決できません。DNSの振り分けは、すべてのドメインを全サーバーに問い合わせることではありません。特定のドメインを適切なリゾルバーに問い合わせ、優先先が失敗したときにフォールバックを許可するかどうかを把握することが重要です。サーバー選択、フォールバック、キャッシュに関するフィールドはコアごとに異なるため、別の設定形式から同名のフィールドをコピーしてそのまま使わないでください。

リゾルバーを変更した後も、古いアドレスがシステム、ブラウザー、アプリの接続プールに残る場合があります。まず対象アプリを再起動し、必要に応じてシステムの方法でDNSキャッシュを消去してから、クライアントのコアを再読み込みしてください。キャッシュが期限切れになる前に設定が無効だと判断したり、一度アドレスが変わっただけで名前解決の品質を判断したりしないでください。検証では、名前解決の成否、取得したアドレスの種類、最終的な接続の成否を併せて記録します。名前解決に成功しても接続先に接続できない場合は、DNSを次々に変更するのではなく、ルーティングやネットワーク経路を調べてください。

DNSの失敗と証明書エラーも区別してください。システム時刻のずれ、ドメイン名と証明書の不一致、アプリが内部のブロック画面に接続している場合なども、Webページが開けない原因になります。DNSサーバーを変更しても解決しないことがあります。特定ドメインの固定設定を追加する場合は、その理由と解除条件を記録し、一時的なIPアドレスを長期間固定しないでください。DNS設定は、アドレスを返せるだけでなく、ルーティング、入口、ネットワーク環境と整合している必要があります。

利用可能なアウトバウンドを確認してから仮想NICを有効にする

TUNは仮想ネットワークインターフェースを通じて、システムのルーティング条件に合うパケットを受け取ります。システムプロキシ設定を参照しないアプリの通信を扱うのに適しています。HTTPやSOCKSのローカル待ち受けとは異なる入口方式ですが、取り込んだ通信のアウトバウンドはルーティングルールで選択する必要があります。有効にする前に、通常のシステムプロキシモードでサーバーへの接続とDNSの動作を確認してください。基本的な接続ができない状態でTUNを有効にすると、仮想NIC、権限、名前解決、ルーティングが同時に問題に関わり、最初の故障箇所を特定しにくくなります。

v2rayNで「TUNを有効にする」スイッチを探す前に、クライアントのインストール先が安定していること、必要なコアと補助コンポーネントがそろっていること、現在のプラットフォームに必要な権限を付与していることを確認してください。Windowsではインターフェースの作成やルート設定に管理者権限が必要な場合があります。macOSやLinuxの権限の扱いは、クライアントの実装によって異なります。他のプラットフォームの権限コマンドをそのまま使わないでください。各プラットフォームのインストール方法はクライアントのダウンロードページ、初回起動時の基本手順ははじめにをご覧ください。

入口を一つに絞ってテストする

TUNを初めてテストする際は、システムプロキシを解除し、対象アプリの通信をTUNだけで取り込むと、入口の重複による影響を減らせます。二つのモードを併用できないという意味ではありません。トラブルシューティングの段階では、経路をできるだけ単純にすることが重要です。有効にした後、インターフェースの初期化失敗、権限不足、ルート設定失敗がログに出ていないか確認します。システムに仮想NICが表示されても、DNSの取り込みやアウトバウンドまで成功しているとは限りません。ドメインへのアクセス、通常の接続、LAN上のリソースをそれぞれ検証してください。

ほかのVPN、仮想NICツール、コンテナネットワーク、企業向けセキュリティソフトも、システムのルートを変更する場合があります。ネットワーク全体が使えなくなったら、まずTUNを無効にして復旧するか確認し、その後、並行して動作する各コンポーネントを一つずつ調べてください。複数の通信取り込みツールを同時に動かした状態で、デフォルトゲートウェイを何度も切り替えないでください。社内ネットワークや特定のネットワーク範囲を直接接続する必要がある場合は、クライアントが対応する除外ルートやルールを使い、それがシステムの取り込みレイヤーとコアの振り分けレイヤーのどちらに作用するか確認します。名前が似ていても、適用される場所は異なります。

DNS、LAN、UDPを確認する

TUNでよくある問題の一つは、DNSリクエストが想定した名前解決経路に入っていないことです。IPアドレスへの直接アクセスはできてもドメイン名で失敗する場合は、仮想NICのDNS、クライアントのDNS取り込み方式、アプリ独自の名前解決設定を確認してください。最初からFakeDNSを有効にしないでください。実際のIPアドレスを使った名前解決を、挙動を把握しやすい基準にできます。LANへのアクセスに問題がある場合は、プライベートアドレスが適切に除外または直接接続されているか確認してください。特に、組織内で一般的でないネットワーク範囲や、特定のインターフェースからしか到達できない内部サービスに注意が必要です。

アプリによってはUDPを使いますが、入口がUDPを受け取れるからといって、リモートサーバー、トランスポート設定、ネットワーク経路全体が同じ通信に対応しているとは限りません。Webページは表示できるのに音声通話やほかのUDP機能が動かない場合は、プロトコルの対応状況、アウトバウンド設定、ファイアウォールルールを個別に確認してください。TUNが有効というだけで、すべてのアプリに対応できたと判断しないでください。MTUもむやみに変更せず、特定のネットワークで大容量転送が停止する、接続は確立するもののデータを送れないといった現象を再現できる場合に限り、元の値を記録して一つの変数として検証します。

無効化と復旧の手順を明確にしておく

TUNを無効にしたら、通常のネットワークが復旧したことを確認し、システムプロキシが引き続きローカルポートを参照していないか調べてください。クライアントを終了してもシステムプロキシが停止済みの待ち受けポートを使っていると、アプリから接続できないことがあります。インターフェースやルートが復旧しない場合は、まずクライアントを正常に再起動して、通信の取り込みを再度無効にしてください。必要に応じてシステムのネットワーク管理機能で残存状態を調べます。正体の分からないルートをまとめて削除したり、システムの仮想アダプターをむやみに削除したりしないでください。他のソフトウェアが正常に使っているインターフェースかもしれません。

設定後は決まった順序で再テストします。一般的なWebページ、ドメイン名が必要な対象、LAN上のリソース、UDPを使うアプリ、最後にスリープ復帰とネットワーク切り替えを確認してください。モバイル環境では有線から無線へ切り替えると、インターフェースやルートが変わり、正常だった通信の取り込みを再初期化する必要が生じる場合があります。これらの状況をすべて説明できるようになってから、TUNを日常的な入口として利用してください。接続の問題が起きたら何でも有効にするスイッチではありません。

接続経路における合成アドレスの役割

通常のDNS問い合わせは接続先の実アドレスを返し、アプリはそのアドレスに接続します。FakeDNSは、プール内の合成アドレスをドメイン名に割り当て、コアに両者の対応関係を保存します。アプリがそのアドレスに接続すると、通信を取り込む経路からマッピングを保持するコアへリクエストを戻し、コアがドメイン名を復元してルーティングやアウトバウンド処理を続けます。主な目的はドメイン名の情報を保持することであり、接続先のサーバーを高速化したり、すべてのDNS問い合わせを自動でリモート解決したりするものではありません。

この仕組みが機能するには、名前解決の経路と接続の経路が一つにつながっている必要があります。システムが合成アドレスを受け取った後、接続がクライアントを迂回すると、インターネット上に存在しない宛先へ接続しようとします。一方のインスタンスがアドレスを割り当て、別のマッピングを持たないインスタンスが接続を受け取る場合も、ドメイン名を復元できないことがあります。アドレスプールの設定をコピーしただけでFakeDNSが有効になったと判断しないでください。DNS問い合わせがどのようにコアへ届くか、アプリのパケットがどのように取り込まれるか、対応するインバウンドに必要なドメイン復元機能があるかを併せて確認してください。

アドレスプール、リゾルバー、スニッフィングを組み合わせる

以下は、Xrayのトップレベル設定にあるFakeDNSのアドレスプールとDNSサーバーの例です。合成アドレスプールには198.18.0.0/15内のアドレスを使っています。この範囲は、接続先サーバーへ直接接続するためのインターネット上のアドレスではありません。この設定には、実際のインバウンドにおけるFakeDNSの復元設定も必要であり、クライアントが生成するTUN設定の代わりにはなりません。クライアントに「FakeDNSを有効にする」設定がある場合は、異なる設定レイヤーでアドレスプールを重複して宣言せず、クライアントの一元的な設定手順を優先してください。

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

該当フィールドに対応するXrayのインバウンドでは、スニッフィング設定のdestOverrideにfakednsを含められます。これは合成アドレスから接続先のドメイン名を復元する機能であり、通常のHTTPやTLSスニッフィングとは異なります。通常のスニッフィングは接続データからホスト名の識別を試みますが、FakeDNSによる復元は事前に作られたマッピングに依存します。スニッフィングを追加するために、プロトコル、待ち受けアドレス、ポートなどのインバウンド設定を上書きしないでください。コアや通信取り込みの実装によって設定方法が異なるため、実際に生成された設定を確認してください。

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

切り替え前後のキャッシュと迂回経路に注意する

FakeDNSを有効にしても、アプリが以前取得した実アドレスをキャッシュしている場合があります。無効にした後も古い合成アドレスが残ることがあります。テストする際は、まず対象アプリの接続を終了してアプリを再起動してください。必要に応じてシステムのDNSキャッシュを消去し、コアを再読み込みします。そうしないと、同じドメインへのアクセスが異なる経路を通り、ルールが不定期に適用されているように見えることがあります。特にクライアントの再起動でマッピングテーブルが消えた後に、アプリが以前の合成アドレスを使い続けないようにしてください。この種の失敗は、サブスクリプションやサーバーに変更があったことを意味するとは限りません。

通信の取り込みを迂回させるアプリの設定には注意が必要です。FakeDNSの合成アドレスを取得したアプリをプロセス除外やシステムルートの除外対象にすると、通常のネットワーク経由ではそのアドレスに接続できません。内部ネットワークで合成アドレスプールと重複する範囲を使っている場合も、設定の見直しが必要です。解決結果を直接検査するアプリ、実アドレスを要求するアプリ、独自の接続検証を行うアプリでは、合成DNSが適さない場合があります。広範囲の取り込みルールを追加し続けるのではなく、対象について実DNSの経路を残す方法を検討してください。

通常のドメインを一つ選んで検証します。まず問い合わせにFakeDNSが応答していることを確認し、次に接続が想定したインバウンドに入ること、ログでドメイン名が復元され、対応するルーティングルールに一致することを確認してください。実DNSモードでは正常でFakeDNSモードだけ失敗する場合は、サーバーとルーティングを変更せず、マッピングの経路だけを調べます。そうすれば、サブスクリプションを再インポートせずに、名前解決と入口の間に問題を絞り込めます。必要なのが一般的なWeb閲覧だけなら、実DNSを使い、管理する設定項目を減らす方法もあります。

一時的な表示結果ではなく、取得元ごとにグループを作る

複数サブスクリプションの管理では、最初からURLを大量に追加するのではなく、各設定の取得元を追跡できる状態にすることが重要です。各サブスクリプションURLを個別のグループに登録し、手動設定のサーバーは別のグループに保存して、メモやフィルターで普段の表示を整理しましょう。名前が似ているサーバーが二つのサブスクリプションに含まれていても、一つの取得元としてまとめないでください。更新、フィルター、提供元側の変更は取得元ごとに適用されます。グループが混在していると、項目が消えたときに、提供元で削除されたのか、フィルターが変わったのか、別のサブスクリプションによって表示が置き換わったのかを判断しにくくなります。

グループの用途、自動更新の可否、更新時に直接接続とプロキシ接続のどちらを使うか、復旧にはどの動作確認済み設定を使うかを、簡単に記録しておきましょう。記録はローカルの文書に保存できますが、サブスクリプションURLは機密情報として別途保護してください。クライアントから設定をエクスポートまたはバックアップする場合は、サブスクリプションの認証情報、サーバーの認証情報、カスタムルールが含まれる範囲を事前に確認します。トラブルシューティングの情報を共有するときは、フィールド名とエラーの種類だけを残し、ユーザーデータのフォルダー全体を送らないでください。

更新の順序と現在選択中のサーバー

更新によって項目が追加・削除されたり、ローカル識別子が再生成されたりする場合があります。上流で削除または置き換えられたサーバーが現在選択されている場合、その後の選択動作はクライアントの実装によって異なります。同じサーバーが常に選択され続けるとは限りません。重要な時間帯の前に、一つのグループを更新し、現在の選択がまだ存在することを確認してから新しい接続を確立してください。サーバー名が同じでも、設定が同一とは限りません。プロトコル、アドレス、ポート、トランスポート、セキュリティ設定が想定どおりか確認します。

動作の安定を確認できた取得元では、自動更新が便利ですが、端末のスリープ、ネットワークの切り替え、更新経路を考慮してください。すべてのサブスクリプションを同じ時刻に、現在のプロキシ経由で更新する設定にすると、そのプロキシが使えない場合に一斉に失敗する可能性があります。トラブルシューティング中は一時的に手動更新にして、一度に一つのグループだけを処理します。復旧後、必要に応じて自動更新を有効にしてください。明確な理由がなければ、非常に短い間隔で更新する必要はありません。更新に失敗しても、ローカル設定が直ちに使えなくなるとは限りません。まず、現在のアウトバウンドが引き続き使えるか確認してください。

重複、フィルター、手動変更

同じサーバーが複数の取得元に含まれる場合もありますが、「名前が同じ」は信頼できる重複判定の条件ではありません。認証、トランスポート方式、TLSパラメーターが異なる設定は、同じアドレスを指していても用途が異なる場合があります。反対に、名前の異なる項目が同じ設定のこともあります。クライアントの重複削除機能を使う前に、どのフィールドを比較するのか確認し、復元用のコピーを残してください。日常の一覧を見やすくしたいだけなら、内容を理解していない設定を削除するのではなく、グループや検索で表示を絞り込みましょう。

サブスクリプションの内容は提供元が管理するデータです。サーバーのトランスポートパラメーターをローカルで一時変更しても、次回の更新で上書きされる場合があります。長期的に使う派生設定は、手動グループにコピーし、元の取得元と変更理由を記録してください。提供元から生成された設定ファイルを唯一の作業ファイルとして直接編集し続けないでください。クライアントの再読み込み時に再生成されることがあります。ルーティングとDNSは、クライアントが対応する独立した設定レイヤーに置き、サブスクリプションにはサーバーのパラメーターだけを管理させると、更新時に上書きされる範囲を減らせます。

予備グループを追加しても自動フェイルオーバーにはならない

メイン画面に予備のサブスクリプションを追加するのは、選択できる設定の取得元を増やすだけです。ヘルスチェック、負荷分散、フェイルオーバーが自動で設定されるわけではありません。関連機能を明示的に設定していない場合、現在のサーバーに障害が起きても、通常は手動で切り替える必要があります。速度測定や自動選択に対応する画面があっても、測定対象、実際の接続を検査するか、切り替えによって既存セッションに影響するかを確認してください。一度のテストが成功しても、すべてのアプリが利用できる証明にはなりません。プロトコルとネットワーク経路の互換性確認の代わりにもなりません。

複数の取得元を管理するときに役立つのは、繰り返し実行できる切り替え手順です。現在のグループとサーバーを記録し、予備の設定を選択して接続を確立し直し、同じ対象でテストします。予備が使える場合は、元の取得元は変更せず、その更新経路とサーバーパラメーターを個別に調べてください。すべての取得元で失敗する場合は、ローカルの入口、DNS、権限、システムネットワークを優先して確認します。取得元の問題と端末の環境の問題を分ければ、サブスクリプションを次々に増やして本当の設定ミスを隠すことを防げます。

GUIクライアント、コア、設定形式の違い

v2rayNはGUIクライアントとして、サーバーの管理、設定の生成、コアの起動を行います。プロトコルやルーティングを実際に処理するのは、選択したコアと関連コンポーネントです。画面上のフィールド名が似ていても、内部の設定形式まで同じとは限りません。編集を始める前に、クライアントの設定や起動ログで現在のコアの種類を確認し、各機能を担当するコンポーネントを特定してください。特に、TUNでの通信取り込みと通常のプロキシ接続は、同じ処理段階で行われるとは限りません。サーバーのプロトコル名だけから、接続経路全体の仕組みを推測しないでください。

Androidでは、v2rayNGはXrayコアを中心とした構成で、v2flyNGはV2Fly系統の代替クライアントです。選ぶ際は名前の比較だけでなく、必要なプロトコルや機能を確認してください。プロトコル、セキュリティ拡張、設定フィールドの対応状況はコアごとに異なります。複雑なXrayのカスタム設定を別のコアにそのまま渡して実行できるとは限りません。エコシステムの違いや機能の選び方については、XrayとV2Flyコアの違いをご覧ください。

アウトバウンドタグはルーティングから参照する値であり、表示用のメモではない

カスタムアウトバウンドには、少なくとも識別しやすいタグ、コアが対応するプロトコル、それに必要なパラメーターが必要です。ルーティングのoutboundTagは、実際のアウトバウンドのtagと完全に一致させてください。大文字と小文字も区別されます。メイン画面のサーバー名が、生成された設定のタグになるとは限りません。保存前に、クライアントがそのアウトバウンドを保持するか、同じタグがすでに使われていないか、カスタムルールがどこに統合されるかを確認します。重複タグや存在しないタグを参照するルールは、起動時に優先して修正してください。

以下のXrayアウトバウンドオブジェクトは、接続を別のローカルSOCKSサービスへ渡す例です。待ち受けアドレスは127.0.0.1:10810です。そのサービスが起動していて、ローカル接続を受け付ける環境でのみ使用できます。二つ目のプロキシを自動で作成するものではありません。このオブジェクトを対応するアウトバウンド配列に追加し、該当するルーティングからlocal-socksを参照してください。通常のサブスクリプションサーバーを使うだけなら、接続のためにこの階層を追加する必要は通常ありません。

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

転送ループとパラメーターの上書きを防ぐ

ローカル転送では、ポートの対応関係を特に確認してください。現在のコアのSOCKSインバウンドと同じポートを待ち受けに設定し、アウトバウンドも同じポートへ向けると、接続が自分自身に戻るループが発生する可能性があります。別のサービスが現在のクライアントのアウトバウンドを使う場合も、プロセス間の循環が起きることがあります。設定前に各段階の待ち受けアドレス、ポート、次の接続先を書き出し、経路が最終的に実際のネットワーク出口へ到達することを確認してください。ポートを使うプロセスがあるかだけでなく、どのプロセスが待ち受けているかも確認します。

クライアントが管理するカスタム設定では、クライアントに用意されたカスタムサーバー、設定のインポート、ルール編集の入口を優先して使ってください。実行時に生成されたファイルを直接編集すると、次回のサーバー切り替えやコアの再起動で上書きされる場合があります。完全な設定を自分で管理する必要がある場合は、メイン画面から制御される設定と、設定ファイルでのみ変更できる項目を明確にしてください。たとえば完全なカスタム設定では、メイン画面のルーティング選択が反映されない場合があります。見た目は同じでも相互に上書きし合う設定を二か所で管理しないでください。

互換性の問題を最小限に絞り込む

コアが起動できない場合は、まずログで最初に出た明確なエラーを確認し、JSONの構文、未対応フィールド、ファイル不足、タグ参照、ポート使用中のどれに該当するかを判断します。コアが起動していない状態でDNSやサーバーを変更しないでください。コアを切り替える場合は、現在使える設定を残し、互換性のある最も単純な接続で基本機能を確認してから、ルーティング、名前解決、カスタムアウトバウンドを一つずつ戻します。クライアントが設定をインポートできても、現在のコアがすべてのフィールドを実行できるとは限りません。

カスタムアウトバウンドを日常的に使う前に、対象のルーティングが一致すること、次の接続先に到達できること、アプリを再接続できること、無効化後に復旧できることをテストしてください。別のローカルサービスに依存する経路では、そのサービスが停止したときのエラーも確認します。明確なローカル依存先の障害を、リモート側の障害と誤認しないようにしましょう。アウトバウンド設計で重要なのは、挙動を説明でき、復旧できることです。各タグの用途、各ポートの管理者を明確にし、切り替え後も確認済みの基本設定に戻れるようにしてください。

障害が発生した段階を特定する

「接続できない」という状態は、コアが起動していない、アプリがプロキシを使っていない、ドメイン名を解決できない、ルールが誤ったアウトバウンドを選んでいる、リモートへの接続を確立できないなど、さまざまな原因を含みます。まず、クライアント、コアの種類、入口モード、選択したサーバー、対象アプリ、エラーが発生する操作を記録し、最小限の手順で再現できるようにします。次に別の対象を試し、特定ドメインだけの問題か、すべての接続の問題かを切り分けます。プロキシを使わない通常のネットワークも利用できない場合は、まずシステムネットワークを復旧してからプロキシ設定を確認してください。基盤のネットワーク障害をサブスクリプションの問題と混同しないためです。

コアの起動に失敗したら、まずログ冒頭のエラーを確認します。ポートの競合、設定の構文エラー、権限不足は、起動時に手がかりが記録されることが多くあります。ポート番号は現在の設定に従って確認してください。一般的なSOCKSポートが10808、HTTPポートが10809だからといって、端末でも同じ値が使われているとは限りません。ポートを変更する場合は、プロキシを手動設定しているアプリも合わせて更新してください。システムプロキシによる自動設定と、アプリ内部の手動プロキシ設定は別々に保存されている場合があります。

リモート接続の前に入口を検証する

システムプロキシを有効にしても、自動で利用するのはシステム設定を参照するアプリだけです。システムプロキシに対応していないプログラムでは、Webページの表示に成功しても、そのプログラムの通信がクライアントに入った証拠にはなりません。まず、プロキシに対応していることが明確なアプリでローカルの入口を検証し、TUNが必要か判断してください。TUNを使う場合は、インターフェース、権限、通信の取り込み範囲を確認します。対象の接続記録がクライアントのログにまったくない場合は、リモートのプロトコル設定ではなく入口を優先して調べてください。入口に通信が届かなければ、後段のルーティングが一致することもありません。

通信が入っていることを確認したら、名前解決のエラーと接続のエラーを切り分けます。ドメイン名では失敗しても、既知のIPアドレスを使ったテスト経路が正常なら、DNSを確認できます。ただし、HTTPSサイトにIPアドレスで直接アクセスすると、証明書やホスト名に関する問題が発生する場合があります。そのエラーだけでDNSの問題と判断しないでください。ログで解決結果と実際の接続先を確認するのがより確実です。アドレスを取得できても接続がタイムアウトする場合は、アウトバウンドとネットワークを調べます。ルールやタグのエラーがすぐに表示される場合は、設定の参照関係を先に修正してください。

スイッチを次々と切り替えるのではなく、症状から原因を絞り込む

FakeDNSを有効にしたときだけ問題が発生する場合は、サーバーとルーティングを変えずに実DNSへ戻して確認します。TUNだけで発生する場合は、通常のプロキシ入口を比較対象として残してください。サブスクリプション更新後に発生した場合は、現在のサーバーが置き換わっていないか、提供元のパラメーターが変わっていないか確認します。コア切り替え後に発生した場合は、フィールドの互換性と生成された設定から調べてください。各切り分けには明確な比較条件が必要です。サーバー、DNS、ルーティングを同時に変更してから、どの変更が効いたのか推測しないでください。

ログでは、エラーの種類と発生順序に注目してください。接続拒否は、接続先のポートで接続を受け付けていないか、明示的に拒否されたことを示す場合が多くあります。タイムアウトは、経路、フィルタリング、リモートから応答がないことなどが原因で発生します。どちらのエラーも、それだけでサーバー設定の全項目が正しい証明にはなりません。TLSエラーでは、システム時刻、サーバー名、証明書の検証設定も確認してください。エラー表示を消すためにセキュリティ検証をむやみに緩めないでください。ドメイン名、トランスポート、サーバー側の設定を整合させてから再接続します。

再利用できる復旧用の基準設定を用意する

復旧用の基準設定には、起動できるコア、動作確認済みのサーバー、明確なローカル入口、シンプルなルーティング、到達可能なDNSを含めます。変更する前に元の値と期待する結果を記録し、失敗したら誤った状態にさらに設定を重ねず、元の値へ戻してください。TUNやFakeDNSに関する変更を戻すときは、アプリのキャッシュとシステムの通信取り込み状態も復旧します。復旧後は接続を確立し直してください。スイッチが無効になっただけで、以前の経路が消去されたと判断しないでください。

トラブルシューティングが終わったら、最終的に有効な変更を必要最小限に絞り、一時的なテストルールを削除してください。基本的な接続を再確認するには、はじめにに戻って基本手順を確認します。インストール先のプラットフォームやクライアントを変更する場合は、該当するダウンロードページを利用してください。日常の確認も同じ順序で進めます。まずコアの稼働状況、次に通信が入口に届いているかを確認し、その後に名前解決、ルーティング、アウトバウンドを調べてください。設定のレイヤーを順番に追えば、新たな問題が起きてもすべての設定を最初から作り直さずに原因を特定できます。