V2Ray初心者向け10問10答：サブスクリプション、コア、プロトコル、クライアントの選び方

Xray APIを使うと、ノードの通信量や接続状態を外部スクリプトから取得し、遅延や失敗回数に応じて利用する経路を切り替えられます。ただし、Xray APIは一般的なHTTP REST APIではなく、主にローカルで待ち受けるgRPCインターフェースです。本記事では、Xrayの統計情報、observatory、balancerの役割を分けて整理し、設定ファイルを編集できるユーザー向けに、監視・判定・切替・バックアップ経路を一つの運用手順として紹介します。

Xray APIでできることと、できないこと

XrayのAPIは、実行中のコアに対して状態を問い合わせたり、一部の管理操作を送ったりするための管理用インターフェースです。通常のプロキシ通信をAPI経由で送るものではありません。クライアントから入った通信はインバウンド、ルーティング規則、アウトバウンドを通りますが、APIクライアントは管理用の別ポートへ接続して、統計情報やハンドラーの状態を取得します。

ノードの自動選択では、少なくとも三つの処理を分けて考える必要があります。第一は「現在の状態を測る」処理、第二は「利用可能と判断する」処理、第三は「実際に使うアウトバウンドを変更する」処理です。StatsServiceは通信量などのカウンターを返しますが、それだけでノードを自動的に切り替えるわけではありません。遅延測定にはobservatoryまたは外部のプローブを使い、選択にはbalancer、設定再生成、あるいは管理APIを組み合わせます。

また、APIポートをLANやインターネットへ公開する設計は避けてください。Xray APIは管理機能であり、認証やアクセス制御を別途設計しないまま外部公開すると、設定変更や情報取得の入口を第三者へ与える可能性があります。最初は127.0.0.1:10085のようにローカルホストだけで待ち受けさせ、監視スクリプトも同じ端末で実行する構成が安全です。

API・StatsService・Observatoryの基本設定

まず、Xrayの設定にapiセクションを追加し、API用のインバウンドと、APIへ処理を渡すルーティング規則を用意します。Xrayのバージョンや配布パッケージによって利用できるサービス名が異なる場合があるため、使用中のコアが対応するAPIサービスを確認してください。統計情報を取得したい場合は、APIインバウンドにStatsServiceを登録し、管理用通信が通常のプロキシアウトバウンドへ流れないようにします。

{
  "log": {
    "loglevel": "warning"
  },
  "api": {
    "tag": "api",
    "services": [
      "StatsService",
      "HandlerService"
    ]
  },
  "inbounds": [
    {
      "tag": "api-in",
      "listen": "127.0.0.1",
      "port": 10085,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "api-in"
        ],
        "outboundTag": "api"
      }
    ]
  }
}

この断片だけではノードへ接続できません。既存のoutboundsへ、API用のblackholeまたは管理通信専用の出方向を追加し、実際のノード設定と統合する必要があります。API用タグとインバウンドタグを通常の通信ルールより先に評価させることも重要です。ルールの順番が逆になっていると、APIリクエストがプロキシ用アウトバウンドへ送られ、統計取得がタイムアウトすることがあります。

遅延をXray自身に測定させる場合は、候補アウトバウンドをobservatoryの対象として指定します。観測先は、候補ノードを通してアクセスできる安定したURLにします。特定のサイトだけを基準にすると、サイト側の混雑や地域制限をノード障害と誤認する可能性があります。短いタイムアウトを設定しすぎると正常な高遅延ノードまで除外されるため、通常の応答時間が150ミリ秒前後なら、初期値として300〜500ミリ秒程度から調整すると扱いやすいでしょう。

Balancerによる標準の自動ノード選択

複数のノードを一つの論理的な経路として扱うなら、Xrayのbalancersを先に検討してください。ルーティング規則のbalancerTagからバランサーを指定し、バランサーの対象となるアウトバウンドをselectorでまとめます。observatoryと組み合わせれば、候補ノードの状態を確認し、利用可能なノードから選択する構成を作れます。外部スクリプトで設定ファイルを書き換えて再起動するより、接続中のコアへ与える影響を小さくできる点が利点です。

{
  "routing": {
    "balancers": [
      {
        "tag": "auto-proxy",
        "selector": [
          "node-jp-",
          "node-sg-"
        ],
        "strategy": {
          "type": "leastPing"
        }
      }
    ],
    "rules": [
      {
        "type": "field",
        "network": "tcp,udp",
        "balancerTag": "auto-proxy"
      }
    ]
  },
  "observatory": {
    "subjectSelector": [
      "node-jp-",
      "node-sg-"
    ],
    "probeUrl": "https://www.example.com/generate_204",
    "probeInterval": "1m"
  }
}

実際のプロパティ名や利用可能な選択戦略は、導入しているXray-coreのリリースで確認してください。特にGUIが生成した設定では、ノードのタグが画面上の表示名と一致しないことがあります。日本語の表示名ではなく、完全なJSONに記録されたtagを選択対象に使います。また、対象ノードに同じ接頭辞を付けておくと、サブスクリプション更新後もセレクターを維持しやすくなります。

定期実行スクリプトを組み立てる手順

標準のleastPingだけでは、通信量、時間帯、連続失敗回数、特定ノードの優先順位まで考慮できないことがあります。その場合は、APIを読む監視スクリプトを別プロセスとして動かします。スクリプトは「測定」「判定」「変更」「記録」の四段階に分け、いきなり設定ファイルを上書きしないことが重要です。最初はドライランで候補だけを表示し、判定が妥当だと確認してから切替処理を有効にします。

1. 管理ポートを確認

   Xray設定のAPIインバウンドが127.0.0.1:10085で待ち受けていることを確認します。ポート番号が別の場合、監視側の接続先も同じ値に合わせます。

2. 統計を取得

   grpcurlまたは利用言語のgRPCクライアントでStatsServiceへ問い合わせます。ノードごとの送受信カウンターを使う場合は、統計名とタグの対応を先にログへ出します。

3. 候補を判定

   遅延300ms超過、3回連続失敗、または直近5分の通信量上限など、明確な条件を組み合わせます。1回の失敗だけで主経路を変更しないでください。

4. 経路を切替

   Balancerで選択可能な構成ならAPIや標準機能を優先します。設定を書き換える場合は一時ファイルへ保存し、JSON検証後にバックアップを作ってから反映します。

5. 結果を記録

   切替時刻、旧タグ、新タグ、遅延、失敗回数、API応答を1行のログへ保存します。15分以内に同じノードへ戻る場合は、切替が頻発していると判断できます。

通信量の取得では、累積値そのものより差分を見る必要があります。たとえば前回の受信カウンターが1,240,000,000バイト、今回が1,310,000,000バイトなら、測定間隔中の増加は70,000,000バイトです。カウンターが再起動でゼロに戻った場合や、32ビット値のように桁あふれが起きた場合は、単純な減算で負の値にならないようリセットを検出します。統計値が取得できないことと、通信量がゼロであることも別扱いにしてください。

# 擬似コード
stats = query_stats("127.0.0.1:10085")
for node in candidates:
    delay = measure_proxy_request(node)
    usage = delta(stats[node].uplink, previous[node].uplink)
    failed = consecutive_failures(node)

    if failed < 2 and delay < 300 and usage < usage_limit:
        healthy.append(node)

selected = choose_by_priority_and_delay(healthy)

if selected != current and stable_for_two_checks(selected):
    write_candidate_config(selected)
    validate_json()
    backup_current_config()
    apply_config_or_restart()

自動再起動を使う場合は、Xrayのプロセス管理方法を先に固定します。Windowsではサービスやタスクスケジューラ、Linuxではsystemdなど、クライアントが管理するコアを外部スクリプトから強制終了すると、v2rayNや別のGUIが状態を誤認することがあります。v2rayNで生成された設定を直接上書きする運用も、サブスクリプション更新で変更が失われる可能性があります。自作の統合設定を別ファイルとして管理し、更新後にノード情報だけを取り込む方式のほうが復旧しやすいでしょう。

遅延しきい値とバックアップ経路の設計

しきい値は回線環境によって変わります。国内の同一地域へ接続する用途で平均60〜120msなら、切替開始を250〜300ms、明確な障害を示す連続タイムアウトを2〜3回に設定できます。遠距離経路で通常から220ms前後ある場合、200msを境にすると常に切替が発生するため、通常値の1.5倍または絶対値350〜450msのように基準を調整します。重要なのは、普段の中央値、最大値、失敗率を7日程度記録してから決めることです。

バックアップ経路は、単に一覧の次のノードを選ぶだけでは不十分です。主経路と同じサーバー、同じ地域、同じポート、同じトランスポートに依存する候補を選ぶと、共通障害で同時に停止する可能性があります。たとえば主経路がVLESS＋REALITYの特定地域ノードなら、予備は別地域または別事業者のVMess＋WebSocket＋TLSなど、障害の相関が低い候補を一つ用意します。ただし、プロトコルを変更する場合はサーバー側で提供される完全なパラメータを使い、スクリプトでUUIDやTLS設定を推測して生成してはいけません。

復旧時の切り戻しにも待機時間を設けます。主ノードが一度成功しただけでバックアップから戻すと、回線が不安定な時間帯に往復切替が起こります。主ノードが5分間に4回以上成功し、平均遅延がバックアップより少なくとも20％低い、といった復帰条件を別に設定してください。切替と復帰の条件を同じにしないことが、フラッピング防止の基本です。

テストとトラブルシューティング

設定を反映する前に、JSONの構文、タグの重複、APIポートの競合を確認します。Xrayの実行ファイルで利用できる設定検証オプションがある場合は、現在と同じリソースディレクトリを指定して検証してください。構文が正しくても、存在しないアウトバウンドタグをselectorやoutboundTagに書けば、起動後のルーティングが期待どおりになりません。検証は「JSONとして正しいか」と「Xrayの設定として意味があるか」の二段階で行います。

最後に、監視スクリプトは接続を改善する補助機能であり、サーバー障害や契約側の通信量制限を解決するものではありません。APIのログ、Xrayの実行ログ、実際のプロキシ接続結果を同じ時刻で照合し、切替前後の遅延と失敗率を記録してください。最初は一つのAPIポート、二つの候補ノード、300msの仮しきい値、5分の復帰待機という小さな構成から始め、安定してから候補数や条件を増やすのが安全です。