V2Ray 高度な設定

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

グループ分けはサブスクリプションの配信元と更新範囲を管理し、サーバーの絞り込みは表示中の一覧を整理するためのものです。どちらもサーバー側のプロトコルを自動で変更する機能ではなく、ルーティングによる振り分けとも異なります。まず配信元ごとにグループを作り、その後、用途に応じて絞り込むのがおすすめです。すべての項目を一つにまとめ、名前から配信元を推測する運用は避けましょう。問題の切り分けでは、項目の配信元アドレス、直近の更新結果、選択中の項目が現在もそのグループに属しているか、の3点を確認します。

配信元を追跡できるグループを作る

v2rayNのサブスクリプショングループ設定で新しいグループを作り、短い別名とサブスクリプションURLを入力して保存します。まずは新しいグループだけを更新し、すぐにすべての配信元を更新するのは避けてください。サーバー一覧に項目が表示されたら、項目の編集画面を開き、アドレス、ポート、通信方式を確認します。バージョンによって画面上の表記が異なる場合は、「サブスクリプション」「グループ」「更新」に相当する機能を探してください。特定のボタン配置を前提にしないようにしましょう。

v2rayNGとv2flyNGでも、まずサブスクリプションを登録してから対象を選んで更新します。クリップボードから共有リンクを1件インポートしても、通常はサーバー項目が追加されるだけで、継続的に更新できるサブスクリプションとしては登録されません。配信元の変更を今後の更新に反映したい場合は、返された内容を項目ごとに貼り付けるのではなく、サブスクリプションURLから登録してください。詳しくはサブスクリプションURLの追加手順と形式をご覧ください。

グループ名には「普段使い」「設定テスト」「予備の配信元」など、管理上の用途を付けます。名前はプロトコルの機能を示すものではなく、同じグループ内でもプロトコルや通信方式が異なる場合があります。サブスクリプションURLにアクセス用の認証情報が含まれることがあるため、スクリーンショットや公開資料、共有ログに載せないでください。配信元を記録する場合は、識別できる別名と必要なメモだけを残し、完全なURLはクライアント内で管理します。移行時は、アクセス制限された方法で取り扱ってください。

一覧全体を確認してから、段階的に絞り込む

絞り込む前に、検索欄、地域、プロトコルの各条件をクリアし、一覧全体が表示されることを確認します。その後は、名前のキーワード、プロトコルの種類など、一度に一つずつ条件を追加してください。名前検索で分かるのは文字列の一致だけであり、サーバーの所在地や実際の接続元を証明するものではありません。一覧が突然空になった場合は、まず絞り込み条件を戻してからサブスクリプションの更新状況を確認します。非表示になっただけの項目を配信元の無効化と決めつけて、グループごと削除しないでください。

一部のクライアントや派生版では正規表現による絞り込みに対応していますが、通常の検索欄が正規表現を扱うとは限りません。画面に正規表現モードが明示されている場合のみ使用してください。以下の式は、独立した3種類の用途ラベルを照合する例であり、コア用のJSONではありません。使用前に既存の名前を少数選び、大文字・小文字、区切り文字、空白の扱いを確認します。該当モードがない場合は、無理に貼り付けず、キーワードを一つずつ使って絞り込んでください。

(^|[\s_-])(work|daily|backup)([\s_-]|$)

並べ替えと絞り込みは別の機能です。テスト結果順の並べ替えは表示順を変えるだけで、現在の接続先が切り替わるとは限りません。テストに成功しても、必要な接続先すべてにアクセスできるとは限りません。項目を選んだら、接続中の表示を確認してから実際にWebページを開いてください。リストの先頭にある項目を見ただけで、切り替わったと判断しないようにしましょう。テスト用の項目は専用グループに分け、並べ替え後に不適切な設定を普段使いに選ばないようにします。

更新による上書きと手動変更を管理する

サブスクリプションの更新では、クライアントの仕様により配信元の項目が再生成または置き換えられることがあります。名前、ポート、通信パラメーターを手動で変更しても、次回の更新で元に戻る可能性があります。長く使う手動設定は専用の手動管理領域に複製し、変更理由を記録してください。サブスクリプションの項目を直接変更しただけで、次回も保持されると考えないようにしましょう。複製時には表示名だけでなく、認証情報や通信設定を含む接続パラメーター全体を確認します。

更新後に項目が減った場合は、まず絞り込みをすべて解除してグループの更新結果を確認し、配信元による削除、形式の非互換、リクエスト失敗のいずれかを判断します。現在使える接続は残し、証拠が失われるような削除と再インポートの繰り返しは避けてください。返された内容が空、または解析に失敗する場合は、サブスクリプション更新失敗時の確認手順に沿って調べます。問題を修正したら該当グループだけを更新し、成功を確認してから全体の管理に戻ります。

ルーティングルールの実践

ルーティングの役割は、コアに届いた接続を指定したアウトバウンドに振り分けることです。アプリの通信を自動でクライアントに取り込む機能ではありません。システムプロキシが機能していない状態でドメインルールを増やしても、そのアプリの直接接続経路は変わりません。ルーティングを調べる前に、ローカルの待ち受け、アプリのプロキシ設定、コアの稼働状態を確認し、接続ログの接続先とアウトバウンドのタグを確認します。通信がコアに届いて初めて、ルールの適用結果を検討できます。

具体的なルールを広範なルールより先に置く

一般的なフィールド形式のルールは上から順に評価され、最初に一致したルールで処理先が決まります。通常、ルール内の異なる条件はすべて満たす必要があり、同じドメイン一覧に複数の項目がある場合は、いずれかへの一致を表します。明確な例外を先に、広い範囲のドメイン集合を後に配置してください。すべての通信を対象にする条件を先に書いて、後続の例外が適用されると期待しないようにしましょう。順序を変えた後は、同じ接続先に新しい接続を行って差を確認します。

ドメイン条件のfull:は完全一致、domain:はドメインとサブドメイン、regexp:は正規表現による照合に使います。前の2つで要件を満たせる場合は、正規表現を使う必要はありません。通常の文字列は想定より広く一致し、関係のないドメインまでルールに含めてしまうことがあります。IP条件にはアドレスやネットワーク範囲を指定し、プロトコル部分を含むWeb URLは入力しないでください。ポートとネットワーク種別も、それぞれ指定欄の形式に合わせます。

以下はルーティング設定の一部であり、完全な設定ではありません。特定のテスト用ドメインをblockというタグのアウトバウンドに、ループバックと一般的なプライベートIPv4範囲をdirectに振り分けます。これらのタグは、実際のoutboundsに定義されている必要があります。既存のルールを残す場合は、ルーティング設定全体を置き換えず、必要なルールだけを配列に追加してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメイン、IPアドレス、名前解決のタイミングを理解する

AsIsは、ルーティング時にドメイン名を追加で名前解決しないことを示します。アプリがIPアドレスだけを送る場合、ドメインルールの照合に必要な情報がないことがあります。アプリがドメイン名を送る場合も、この設定ではIPルールに必要なアドレスが得られるとは限りません。IPIfNonMatchはドメイン照合で一致しなかった場合に名前解決して再判定し、IPOnDemandは関連するIP条件に遭遇した際に名前解決を行う場合があります。有効にした後はDNSの経路も確認してください。

スニッフィングで一部のプロトコルのハンドシェイクからドメイン名を取得できますが、すべての接続から取得できるわけではありません。暗号化ハンドシェイクの特性、独自プロトコル、IPアドレスへの直接アクセスなどが結果に影響します。スニッフィングを正しいDNS設定の代わりになる万能機能として扱わないでください。「ルーティングのみ」などのオプションがある場合は、一致判定に情報を追加するだけなのか、その後の接続先も変更するのかを確認します。具体的な動作は、使用するコアの設定項目に従ってください。

Webページの表示だけでなく、ログで確認する

ルールを検証するときは、既存の接続を切断してから特定の接続先にアクセスし、ログに表示されるインバウンドのタグ、接続先のドメイン名またはIPアドレス、選択されたアウトバウンドを確認します。ブラウザーの接続再利用により、再読み込みしても古い経路が使われることがあります。ルールを変更した後は、該当アプリを再起動するか、新しい接続を確立してください。ルールに一致しない場合は、通信がプロキシを経由しているか、ドメイン名の形式が一致しているか、タグの綴りが正しいかを確認してから、順序と名前解決の設定を調べます。

「ルールには一致したがアウトバウンド接続に失敗した」場合と、「ルールに一致しなかった」場合を区別します。前者では該当サーバーとプロトコルを確認し、後者では照合条件を見直します。ルールに一致しない場合、一般的な設定では最初のアウトバウンドが使われることがあります。必ずプロキシまたは直接接続になると決めつけないでください。クライアントが設定を生成する際にアウトバウンドの順序を変更する場合もあるため、画面上のサーバー順ではなく、実際に動作している設定を確認します。

地理情報を使ったドメインやIPの集合を利用する場合は、リソースファイルが存在するか、現在のコアと互換性のある形式か、更新方法はどうなっているかも確認してください。リソースが見つからないと、ルールが単に無視されるのではなく、コアの起動に失敗することがあります。まず特定ドメインだけの最小ルールで動作を確認してから、大きな集合を追加します。問題が起きたら直前の動作する設定に戻し、接続済みなのにWebページを開けない場合の確認手順に沿って原因を調べてください。

DNS設定の最適化

DNS設定では、単に名前解決先を選ぶのではなく、「誰が問い合わせるか」「問い合わせをどこに送るか」「結果をどの段階で使うか」を明確にします。一度のアクセスでも、システムリゾルバー、ブラウザーのセキュアDNS、コア内蔵DNS、リモートサーバー側の名前解決が関わる場合があります。一か所を変更しても、他の経路が自動的に切り替わるわけではありません。まずアプリからリゾルバーまでの実際の経路を整理し、コアでの名前解決、特定ドメイン用のDNSサーバー、暗号化されたDNS通信が必要か判断してください。

3種類のドメインを分けて確認する

1つ目はプロキシサーバー自体のドメインです。接続を確立する前に、利用できるIPアドレスを取得する必要があります。2つ目はユーザーがアクセスする接続先のドメインで、ローカルまたはリモートで名前解決される場合があります。3つ目はDNSサービス自体のドメインで、暗号化DNSのURLを使う場合は、接続に先立つ名前解決も必要です。この3種類すべてを、まだ確立していないプロキシ経路に依存させると、循環依存が発生するおそれがあります。接続の最初の段階で利用できる、明確な名前解決経路を確保してください。

以下の設定例はシステムリゾルバーを使い、IPv4とIPv6の両方のアドレスを問い合わせる、フィールドの理解に適した簡易的な基本形です。localhostはシステムの名前解決機能を呼び出すことを意味し、コアがローカルでDNSサーバーのポートを開くという意味ではありません。また、この設定だけでブラウザー独自のセキュアDNSが無効になるわけではありません。あらゆるネットワークに最適な設定ではなく、まず名前解決の経路を明確にし、その後、必要に応じて調整するためのものです。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

UseIPv4とUseIPv6で使用するアドレスファミリーを制限できますが、一度アクセスが遅かっただけで、どちらかを恒久的に無効にしないでください。まずシステムが該当するアドレスを取得できるか、ルーティング可能か、アウトバウンドが対応しているかを個別に検証してから方針を決めます。IPv6アドレスが返されたからといって、必ずIPv6で接続するとは限りません。最終的な選択にはアプリ、コア、アウトバウンド設定、システムのネットワークスタックが関わります。

失敗した段階から原因を絞り込む

DNSのタイムアウトと接続のタイムアウトは異なる問題です。前者ではアドレスを取得できず、後者ではアドレス取得後に接続が完了しません。Webページが表示されないという症状だけでは区別できません。コアのログで名前解決結果と、その後の接続エラーを見比べ、必要であれば一時的に情報レベルのログを有効にしてください。詳細を長期間記録したり、接続先ドメインやサブスクリプションURLを含むログ全体を公開したりしないでください。

システム上ではnslookup example.comを実行して、システムの名前解決状況を確認できます。ただし、この問い合わせがコア内蔵DNSを経由するとは限りません。結果を比較する際は、ネットワーク、時刻、アプリの名前解決設定を記録し、異なる経路の差を設定の破損と誤認しないようにします。システムの名前解決が正常でもクライアントが失敗する場合は、コアの名前解決経路、関連するルーティング条件、プロキシサーバーのドメインが同じ故障経路に依存していないかを確認してください。

必要に応じてドメイン別の名前解決とキャッシュを確認する

内部ネットワークのドメインは、そのネットワークが提供するリゾルバーに依存することが多く、すべてをパブリックDNSに切り替えると内部名を解決できなくなる場合があります。特定ドメインにDNSサーバーを指定する際は、使用するコアが対応しているドメイン照合方式を使い、フォールバック時に別のサーバーへ問い合わせが送られないか確認してください。コアによってフォールバック用の項目や優先順位の対応は異なります。v2rayNGとv2flyNGの間で高度な設定項目をそのままコピーしないでください。

暗号化DNSは問い合わせの通信方式を変えますが、DNSサービスへの到達性、証明書の検証、システム時刻の正確さも必要です。ホスト名形式のサービスURLを使う場合は、まずブートストラップ名前解決を解決してください。IPアドレス形式を使う場合も、必要な証明書とサーバー名の条件を確認します。DNSサーバー、ルーティングモード、TUN設定を同時に変更すると、成功・失敗の原因を特定しにくくなります。変更のたびに、元に戻せる設定のコピーを残してください。

キャッシュが残っていると、設定変更後も古い値が一時的に使われることがあります。検証時は対象のアプリとクライアントを再起動し、必要に応じてシステムの方法で名前解決キャッシュを消去してください。更新のためにDNSサーバーのアドレスを何度も変更する必要はありません。自宅から職場など別のネットワークに切り替えた後は、内部ドメインとネットワークインターフェースの設定も確認します。この章の完了基準は、特定のWebサイトが偶然開けることではなく、各問い合わせの送信元と送信先を説明できることです。

TUNモードとトラフィックの取り込み

TUNモードは仮想ネットワークインターフェースを介してネットワーク層の通信を受け取り、システムプロキシを参照しないアプリにも対応します。これは取り込み対象を広げる機能であり、誤ったサーバー設定を自動で修正するものでも、すべてのプロトコルを同じ経路で処理する保証でもありません。有効にする前に通常のプロキシモードで接続できることを確認し、権限、ルーティング、DNSを確認してください。そうしないと、元からある接続の問題とトラフィック取り込みの問題が重なり、システム全体がネットワークに接続できないように見えることがあります。

まず元に戻せる基本状態を作る

デスクトップでは、まずv2rayNのシステムプロキシで接続できることを確認し、接続中のサーバー、ルーティングモード、DNS設定を記録します。トラフィックを取り込んでいる他の仮想ネットワークインターフェースやトンネルツールを停止してから、クライアントのTUN機能を有効にしてください。実装によっては管理者権限や補助サービスが必要だったり、独立したコンポーネントが取り込みを担ったりします。現在のクライアントが提供する機能を確認し、画面上のTUNスイッチがコアの特定のトップレベル項目と同じだと決めつけないでください。

Androidのv2rayNGとv2flyNGは通常、システムのVPNインターフェースを使ってアプリの通信を取り込みます。初回起動時はシステムの権限確認を読み、許可対象が現在使っているクライアントであることを確認してください。通常、この種の通信取り込みサービスを複数同時に動作させることはできません。クライアントを切り替える際は、先に前のサービスを停止します。ここでいうシステムインターフェースは通信を取り込む仕組みの名称であり、接続可能なリモートサーバーが用意されているという意味ではありません。サーバー設定は別途必要です。

権限、デフォルトルート、ループを確認する

有効にしたら、仮想インターフェースが作成されているか、コアが動作し続けているか、デフォルト通信の経路が想定どおりかを確認します。クライアント起動直後から再接続を繰り返す場合、プロキシサーバー自身への通信が仮想インターフェースに再び取り込まれ、ループしている可能性があります。適切に動作させるには、クライアント自身のアウトバウンドを除外するか、実際のネットワークインターフェースにバインドする必要があります。広範な直接接続ルールを大量に追加して隠そうとせず、インターフェースの選択、自動ルーティング、プロセスの除外機能を確認してください。

LANへのアクセスは個別に検証します。プリンター、共有フォルダー、内部サービスは、プライベートアドレス、リンクローカルアドレス、専用ドメインを使う場合があります。一般的なプライベートアドレスを直接接続にするだけでは不十分で、仮想インターフェースのルーティング、名前解決、ファイアウォールも確認が必要です。IPアドレスではアクセスできても名前では失敗する場合は、DNSの章に戻ってください。IPアドレスでもアクセスできない場合は、インターフェースのルーティングとネットワーク範囲の競合を調べ、すぐにサーバープロトコルを変更する必要はありません。

通信の取り込み範囲とプロトコル対応を分けて考える

通信がTUNに入った後、UDPを正常に処理できるかどうかは、取り込みコンポーネント、使用するプロトコル、サーバー側の対応、ルーティングルールによって異なります。ブラウザーでWebページを開けても、リアルタイム通信やその他のUDPアプリが使えるとは限りません。実際に必要なアプリを選んで個別にテストし、使用するネットワーク種別とエラー記録を確認してください。互換性に問題がある場合は、取り込み範囲を狭めるか、アプリが対応するプロキシ設定を使います。すべての設定をむやみに切り替えないでください。

MTUの調整は、基本的な接続経路を確認した後に行います。大きなデータの通信だけが止まる場合に、ネットワーク環境に応じてパケット分割やパスMTUの問題を検討してください。すべてのネットワークに共通する固定値はありません。一度に一段階だけ変更し、同じ接続先で再検証するとともに、元の値を記録して失敗したらすぐに戻します。ドメインの名前解決や短い接続さえ失敗する場合は、MTUを試す前に権限、ルーティング、DNSを確認してください。

スリープからの復帰、Wi-Fiの切り替え、有線ネットワークへの接続後は、実際のインターフェース名やゲートウェイが変わることがあります。起動直後は動くのにネットワーク切り替え後に失敗する場合は、通信の取り込みを停止して再確立し、自動インターフェース選択が更新されたか確認します。長期的な利用では、発生条件を記録する方がサブスクリプションを何度も追加し直すより有用です。サブスクリプション管理はシステムルートを維持する機能ではないため、サーバー一覧を更新しても、無効になったインターフェースの問題は解決しません。

この章を終えたら、通常のWebページ、もともとシステムプロキシを参照しないアプリ、実際に必要なLANサービスの3種類を個別に検証します。結果を比較すれば、通信の取り込み範囲、リモートへの通信、内部ネットワークの例外を切り分けられます。システム上でサービスが起動中と表示されるだけでは、正しく通信を取り込めている証拠になりません。クライアントを終了した後にネットワークが復旧することも確認し、古いルートが残った状態で一時的に動いているだけではないことを確かめてください。

FakeDNSによるアドレスマッピング

FakeDNSはドメイン名を管理されたアドレスプール内の合成アドレスに置き換え、通信がコアに入った時点で元のドメイン名に戻します。ドメイン情報を保持してルーティングを補助する機能であり、あらゆる名前解決を置き換えるパブリックDNSではありません。実際の接続には、最終的に有効な接続先とアウトバウンドが必要です。有効にする前にDNSの問い合わせ経路とTUNの取り込み範囲を把握してください。アプリが合成アドレスを取得しても、マッピングを復元できるコアに通信が届かなければ接続できません。

問い合わせから接続までの経路をつなげる

完全な経路は3段階です。アプリの問い合わせがFakeDNSを提供する名前解決経路に届き、合成アドレスを受け取った後、そのアドレスへの接続が対応するコアに取り込まれてドメイン名に復元されます。どれか一つが欠けても失敗します。設定にアドレスプールを追加しただけでは、システムの問い合わせが自動的にそこへ送られるわけではありません。TUNを有効にしただけで、すべてのDNS問い合わせがFakeDNSに渡されるとも限りません。問い合わせ元、返されたアドレス、接続時のインバウンドをそれぞれ確認してください。

以下はXray形式のコア設定例です。アドレスプール、DNSサーバー、SOCKSインバウンドのスニッフィングの関係を示すもので、クライアントの完全な設定でも、すべてのコアで使える共通テンプレートでもありません。ここでは待ち受けをローカルに限定しています。SOCKSインバウンドのスニッフィングが対象にするのは受信した接続だけで、システムのDNSを自動で取り込むわけではありません。同様の設定をTUNで使う場合は、クライアントが提供する実際の通信取り込み機能と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": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

アドレスプールはサーバー一覧ではない

ipPoolは合成アドレスの割り当て範囲、poolSizeはマッピングプールの容量を表します。アドレス数はサーバー数でも、接続可能な数でもありません。プール内のアドレスを、実際のリモートサーバーのアドレスとしてサブスクリプションや手動設定に保存しないでください。ネットワークで同じ範囲が使われていると競合する可能性があります。設定ファイルの構文が正しいかだけでなく、有効にする前に既存のルーティングと内部ネットワークの設計も確認してください。

上の範囲は基準テストなど特定の用途向けで、インターネット上の接続先として利用できるものではありません。アプリがこのアドレスを受け取った後、正しいマッピング復元経路を通る必要があります。ログにこの範囲を実際のネットワークへ直接送ろうとした記録がある場合、マッピングが使われていないか、通信が取り込み経路を迂回しています。この場合、通常のプロキシルールを追加しても根本的な解決にはなりません。スニッフィング機能、インバウンドの位置、DNS応答が同じ実行インスタンスから返されているかを確認してください。

コアの違いとアプリの動作に注意する

v2rayNGとv2flyNGでは使用するコアが異なるため、FakeDNSの項目、設定形式、連携方法がそれぞれ対応しているか確認します。画面が似ているというだけで、カスタムJSON全体をコピーしないでください。v2rayNも異なるコンポーネントで通信を取り込む場合があるため、実際に動作しているコアと設定の生成方法を確認する必要があります。各派生版の背景については、XrayとV2Flyのコアの関係をご覧ください。

アプリが独自の暗号化DNSを使うと、想定していたシステムの問い合わせ経路を迂回し、合成アドレスではなく実際のアドレスを取得することがあります。アプリによってはキャッシュ済みのアドレスや固定IPを直接使うため、復元するドメインマッピングが存在しない場合もあります。あるブラウザーで成功しただけで、すべてのアプリがFakeDNSを経由すると判断しないでください。新しいドメインを一つ選んでテストし、問い合わせログと接続ログを照合します。必要であれば、テスト対象アプリの名前解決設定を一時的に統一してください。

マッピングは通常、現在動作しているコアの状態に属します。再起動後、キャッシュに残る古い合成アドレスが元のドメインと対応し続けるとは限りません。クライアントの再起動後に一部のアプリだけが失敗する場合は、サブスクリプションを更新し直すのではなく、該当アプリの名前解決キャッシュを消去するか、アプリを再起動してください。FakeDNSを無効にする場合もキャッシュの扱いに注意し、クライアント停止後に合成アドレスが実際の接続先として使われないようにします。ネットワークの切り替えやスリープからの復帰後も確認してください。

ドメイン名が復元されて初めて、ルーティングでドメイン条件に基づく振り分けができます。ルーティングが正しくても、リモート側の名前解決が正常とは限りません。ログに元のドメイン名と想定どおりのアウトバウンドが表示されている場合は、実際の名前解決と接続の段階をさらに調べます。まずテスト環境だけでFakeDNSを有効にし、無効にした後も通常の名前解決に戻ることを確認してから対象を広げてください。ドメイン情報を保持する明確な必要がなければ、正常に動作している現在の名前解決を維持する方が管理しやすくなります。

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

複数サブスクリプションを管理する目的は、更新時の影響を分離し、切り替えの判断基準を明確にすることであり、一覧をできるだけ長くすることではありません。各配信元にはそれぞれのURL、形式、有効期間、接続条件があります。一つの配信元の更新に失敗しても、正常に動作している他のグループに影響させないようにします。配信元、用途、現在の接続項目を分けて記録し、同じ名前を同一サーバーと誤認したり、更新後に失効済みの項目を使い続けたりしないようにしてください。

配信元ごとに分け、用途に応じて選ぶ

サブスクリプションURLごとに独立したグループを作り、普段使い、テスト、予備などの別名で区別します。異なる配信元のURLをつなげて一つのURLにしたり、複数のサブスクリプションの返却内容を一つの入力欄に貼り付けて、クライアントが配信元との関連を自動管理すると期待したりしないでください。統合後の静的な項目は更新との関連付けが失われることがあります。その時点で接続できても、後の追加、削除、パラメーター変更を追跡しにくくなります。クライアント本来のサブスクリプション管理を維持してください。

同じ名前でも接続パラメーターが同じとは限りません。重複を判断するときは、少なくともプロトコル、サーバーアドレス、ポート、通信設定を比較し、認証情報はローカルで確認してください。異なる配信元が同じ別名を使っていても、別のサービスを指している場合があります。同じアドレスでも認証情報や通信方式が異なれば、別の項目になります。削除する前に現在の接続がどのグループに属するか確認し、正常に動作する基準設定を残してください。一覧を整理するために、唯一動作する設定を誤って削除しないようにしましょう。

グループ分けは自動フェイルオーバー機能ではありません。グループを「予備」と名付けても、現在の接続が失敗したときにクライアントが自動で切り替えるわけではありません。自動選択、負荷分散、接続テストは別の機能であり、対応状況や動作はクライアントとコアによって異なります。これらの機能が明確に設定されていない場合、予備グループは手動切り替え用の接続として扱い、選択場所と検証方法を記録してください。グループ名から動作を推測しないようにしましょう。

更新の手順を決めておく

配信元を追加したら、まず一度だけ個別に更新し、結果と代表的な項目を確認してから定期更新を設定します。定期更新を使う前に、予定時刻にクライアントが起動しているか、ネットワークが利用できるか、更新リクエストがどの経路を通るかを確認してください。更新リクエストに現在のプロキシを使うかどうかはクライアントによって異なるため、該当する設定を確認して実際に試します。サブスクリプションの更新成功とサーバーへの接続可否は別の指標です。

更新に失敗したら、リクエスト経路を切り替える前にエラーの種類を確認します。接続タイムアウトは現在のネットワークが原因の場合があります。認証エラーやURLの期限切れでは配信元の状態を確認し、結果が空の場合は形式の非互換も疑います。短時間にすべての配信元を繰り返し更新するのは避けてください。原因調査の妨げになるだけでなく、配信元側のリクエスト制限に触れるおそれもあります。問題のあるグループだけを対象にし、他のグループは変更せず、直近で成功した更新結果と比較します。

サーバー一覧の更新後は、現在の接続項目が残っているか、再生成されたか、デフォルト項目に切り替わっていないかを確認します。選択状態を維持するクライアントもあれば、操作によって現在の項目が変わる場合もあります。どのクライアントでも同じ動作だとは限りません。接続中の表示を確認し、新たに接続し直してから、よく使う接続先と必要なLANアクセスをテストしてください。表示名だけが変わり、実際の接続パラメーターに変更がない場合も、不要なルーティング再設定は避けましょう。

移行時は管理データと接続データを分ける

デバイス間で移行する場合は、サブスクリプション登録、手動項目、ルーティングルール、DNS設定、システムの通信取り込み設定を個別に確認します。サーバーの共有リンクを一つエクスポートしただけでは、グループの更新スケジュールは含まれず、システムプロキシやTUNの状態も引き継がれません。移行先では通常のプロキシモードで接続を確認してから、高度な設定を一つずつ戻してください。旧デバイスのインターフェース名、ネットワーク範囲の前提、権限状態までそのまま移行しないようにしましょう。

バックアップにはサブスクリプションのアクセス情報、サーバーの認証情報、個人の利用設定が含まれる場合があります。管理された保存先に保管し、公開のトラブル資料には使わないでください。調査情報を共有する必要がある場合は、エラーの種類、項目名、機密情報を取り除いた部分だけを抜粋します。バックアップがテキスト形式でも、そのままアップロードしてよいとは限りません。復元前に対象のクライアントとコアを確認し、現在動作している管理設定が自動的に上書きされないようにしてください。

配信元を削除する際は、まず検証済みの別の接続に切り替え、そのグループの更新スケジュールを停止してからサブスクリプション登録と不要な項目を削除します。最後に、クライアントのルールやカスタムアウトバウンドが削除対象の項目を参照していないか確認してください。一覧の整理後は、切断されていない古いセッションをそのまま使っていないことを確かめるため、接続を再テストします。こうすることで、過去のキャッシュに頼らず、配信元を追跡できる状態を維持できます。

カスタムアウトバウンドと設定の検証

アウトバウンドは、接続をコアの外へどのように送るかを定義し、ルーティングはタグを使ってアウトバウンドを選択します。サーバー項目、アウトバウンドオブジェクト、ルーティングルールは関連する要素ですが、同じものではありません。通常、クライアントは選択中のサーバーをもとにアウトバウンドを生成します。完全なカスタム設定を使う場合は、画面上でサーバーを切り替えても設定が自動で変わらないことがあります。作業前に、現在の設定欄が完全なJSON、アウトバウンドの断片、クライアント専用のルール形式のどれを受け付けるのか確認してください。

リモート認証を使わない最小構成で形式を確認する

以下はローカルで機能をテストするための、完全な基本設定例です。V2FlyとXrayで一般的なSOCKS、直接接続、ブロックの構成を使います。リモートプロキシには接続せず、ローカルの待ち受け、タグの参照、ルーティング動作だけを確認します。ポートが使用中の場合は、競合するサービスを停止するか待ち受けポートを変更してください。サブスクリプションのノード設定としてインポートせず、コアの完全な設定を受け付ける画面で使用し、事前に元の設定を保存してください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

設定内のdirectとblockは任意に付けたタグであり、名前だけで特別な動作をする予約語ではありません。実際の動作はprotocolで決まります。タグを変更する場合は、参照している箇所もすべて更新してください。この例では、どのルールにも一致しない接続は最初の直接接続アウトバウンドを使い、特定のテスト用ドメインはブロックアウトバウンドに送ります。テスト用ドメインでは実際のサイト内容を表示できません。

構文、意味、実行結果の順に確認する

まず構文を確認し、二重引用符、カンマ、配列、オブジェクトが正しく閉じているかを確認します。標準JSONではコメントと末尾の余分なカンマは使えません。次に意味を確認し、各項目が現在のコアに対応しているか、タグの参照先が存在するか、ポートとアドレスの形式が正しいかを調べます。その後に起動して実行結果を確認してください。JSONツールでファイルを読み取れることが証明するのは構文だけです。プロトコルの対応、サーバーへの到達性、ルーティングの動作までは保証されません。

実行時は、まず待ち受けが正常に開始されたことを確認し、テスト用アプリからローカルのSOCKSアドレスと指定ポートに接続します。ドメインルールを使う場合、アプリはドメイン名をプロキシ側で処理できる形で渡す必要があります。アプリがローカルで名前解決してIPアドレスだけを渡すと、特定ドメインのルールに一致しないことがあります。通常のアクセスが成功したら、テスト用ドメインにアクセスしてブロック動作を確認し、アプリがプロキシを迂回した結果の失敗ではなく、現在のコアによる処理であることを確かめてください。

設定例ではループバックアドレスで待ち受けるため、ローカルのテストに適しています。すべてのインターフェースで待ち受けるとアクセス範囲が広がります。特に認証のないSOCKSサービスは、同じネットワーク上の別の端末から利用される可能性があります。共有が必要な場合は、待ち受けアドレスを任意の値に変えるだけでなく、認証、ファイアウォール、許可する接続元を別途設計してください。クライアントの「LAN接続を許可」も公開範囲を理解して使います。トラブル対応のため一時的に有効にした後、そのまま使い続けないようにしましょう。

実際のアウトバウンドを追加する際は、切り戻し手段を残す

実際のリモートアウトバウンドは、検証済みのサーバーパラメーターから生成し、現在のコアが対応するプロトコル項目に合わせて調整します。V2FlyとXray固有の項目を混在させたり、プロトコル名だけをコピーして通信方式、セキュリティ層、サーバー名などの関連設定を省略したりしないでください。パラメーターが足りない場合は、クライアント標準のサーバー編集画面に戻って確認します。コアを選ぶ必要がある場合は、クライアント選びを参考にしてください。設定の不足を隠すために、クライアントを次々に切り替えないようにしましょう。

複数のアウトバウンドを設定する場合は、用途が分かる一意のタグを付け、各ルールでそのアウトバウンドを選ぶ理由を記録してください。チェーン接続を使う場合は、コアが実際に対応している接続方式と項目を確認し、「アウトバウンドを選択する」ことと「別のアウトバウンド経由で接続する」ことを区別します。項目を2つ追加しただけで自動的にチェーンになるわけではありません。最初の検証では、実際のアウトバウンドを一つと特定のルールを一つだけ追加し、動作を確認してから拡張します。循環参照や追跡しにくいデフォルト経路を避けてください。

起動時、サーバー切り替え時、サブスクリプション更新時に、クライアントが実行用の設定を再生成することがあります。一時生成ファイルを直接編集しても、変更が失われる可能性があります。長期的に使う設定は、クライアントが明示的に対応しているカスタム設定欄に保存し、再起動後も反映されることを確認してください。切り戻す際は直前の設定に戻してコアを再起動し、システムプロキシとTUNの状態を確認します。プロセスを古いまま動かして設定ファイルだけ置き換え、画面表示と実際の動作が食い違わないようにしてください。