カスタムルーティングルール構文ガイド：domain・ip・geositeの書き方とマッチング優先順位

まずルーティングルールの役割を理解する

V2RayとXrayのルーティングモジュールはノード接続を確立するものではなく、コアに入った接続をどの出力先へ渡すかを処理します。代表的な出力先タグはproxy、direct、blockで、それぞれプロキシ、直結、ブロックに対応します。タグ名はプロトコルのキーワードではなく、設定内で定義されたoutboundTagです。クライアントが別のタグを生成する場合は、実際に生成された名前をルールで使用してください。

1つのリクエストには、ドメイン名、接続先ポート、入口、名前解決後のIPが同時に含まれることがあります。ルール配列は順番に確認され、通常は最初に完全一致したルールで出力先が決まります。そのため、「具体的なルールを前に、範囲の広いルールを後ろに置く」ことが最も重要です。対象範囲の広いgeosite:cnやgeoip:cnを先頭に置くと、後ろにある特定ドメインのプロキシルールが適用されなくなることがあります。

同じフィールド内の複数の値は「いずれか1つに一致すればよい」というOR条件で、異なるフィールド間は「すべて満たす必要がある」というAND条件です。たとえばdomainとportを同時に指定したルールは、ドメイン条件とポート条件の両方を満たした場合にだけ一致します。domain配列に3つのドメインを指定した場合は、そのうち1つに一致すれば十分です。この違いが、正しそうに見えるルールが想定した通信を捕捉できない原因になることがあります。

domainで使える5つの代表的な書式

domain:は、日常的なメンテナンスに最も適したドメイン指定です。domain:example.comはexample.comとそのサブドメイン（api.example.comなど）に一致しますが、notexample.comを同じドメインの末尾として扱うことはありません。サイト全体とすべてのサービス用サブドメインを対象にする場合は、まずこの形式を使います。

full:は完全なドメイン名だけに一致します。full:api.example.comはそのホスト名に一致しますが、www.example.comやv2.api.example.comには一致しません。特定のAPIだけをプロキシへ送り、同じルートドメインにある他のサービスは共通ルールに従わせたい場合に適しています。

接頭辞のない文字列は部分文字列マッチングになります。たとえばexampleは、ドメイン名のどこかにその文字列を含むものに一致する可能性があり、想定より広い範囲を対象にします。regexp:は正規表現に対応しており最も柔軟ですが、ルールが多いと原因を追いにくく、境界の指定が不十分な場合は誤一致も起きやすくなります。domain:やfull:で表現できるなら、最初から正規表現を使う必要はありません。

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:static.example.net",
    "regexp:^img-[0-9]+\\.example\\.org$"
  ],
  "outboundTag": "proxy"
}

上の3つのdomain項目はOR条件です。リクエストがいずれか1つに一致すると、そのルールにある他のフィールドが確認されます。例では追加フィールドがないため、そのままproxy出力先へ進みます。正規表現のドットはエスケープが必要で、さらにJSON文字列内でもバックスラッシュを保持するため、設定テキストでは\\.と表示されます。

ip、CIDR、domainStrategyの連携

IPルールには単一アドレスとCIDRネットワークのどちらも指定できます。IPv4の単一アドレスは192.0.2.10、ネットワークは192.0.2.0/24、IPv6は2001:db8::/32のように記述します。CIDRの後ろの数字はネットワークプレフィックス長を示し、/24は256個のIPv4アドレスをカバーします。ポート番号やアドレス数を表すものではありません。

geoip:privateは、プライベートアドレスを直結する際によく使われ、代表的なLANアドレス範囲を対象にできます。実際の設定では、ループバックアドレスやローカルサービスも処理できるようにして、ルーターの管理画面、NAS、127.0.0.1で動作するプログラムへのアクセスがリモートプロキシへ送られないようにします。v2rayNでよく使われるローカルSOCKS待受ポートは10808です。HTTPポートは同じ混合入口または隣接ポートで提供される場合があるため、具体的な値は「設定」→「パラメータ設定」のローカル待受設定を確認してください。

• AsIs：リクエストに含まれるドメイン名を優先してマッチングし、IPルールを試すためにドメイン名を自動的に解決することはありません。
• IPIfNonMatch：まずドメインルールを確認し、ドメインルールで結果が得られなかった場合に対象ドメインを解決してIPルールを試します。
• IPOnDemand：対象IPが必要になる可能性のあるルールを確認した時点で名前解決を開始できます。IPベースの振り分けを明確に必要とする設定に適していますが、DNSの結果を早い段階で取り込むことになります。
• 直接IPリクエスト：アプリ自体がIPアドレスへ接続する場合、ドメイン名をアドレスへ変換する必要はなく、IPルールやgeoipルールをそのままマッチングに利用できます。

{
  "domainStrategy": "IPIfNonMatch",
  "rules": [
    {
      "type": "field",
      "ip": [
        "geoip:private",
        "127.0.0.0/8",
        "192.0.2.0/24"
      ],
      "outboundTag": "direct"
    }
  ]
}

geosite分類の使い方

geositeはドメインの集合を分類したデータであり、リアルタイム検索サービスではありません。geosite:cnはデータファイル内で該当分類に登録されたドメインを示し、geosite:category-ads-allは通常、広告ドメインの集合に使われます。分類内容はクライアントに付属するデータのバージョンによって変わるため、geositeは広範囲の基本振り分けに使い、重要なカスタムドメインの例外は前方に個別指定してください。

geositeとgeoipは置き換えて使えるものではありません。あるドメインが特定のgeosite分類に属していても、現在解決されたIPが同名のgeoip分類に属するとは限りません。CDNを利用している場合、同じドメインでもネットワーク環境によって異なるアドレスが返されることがあります。まずgeositeでドメインの意味に基づいて処理し、未一致の接続をgeoipで補完するほうが、IPだけを見るより通常は管理しやすくなります。

ブロック分類では順序に特に注意が必要です。ある業務用APIが広告分類に登録されていて、ページの正常な読み込みにも必要だとします。この場合、共通のブロックルールによってAPIまで遮断されます。すべての広告分類を削除するのではなく、ブロックルールの前にfull:またはdomain:の例外を追加し、directまたはproxyへ振り分けてください。

[
  {
    "type": "field",
    "domain": [
      "full:required-api.example.com"
    ],
    "outboundTag": "proxy"
  },
  {
    "type": "field",
    "domain": [
      "geosite:category-ads-all"
    ],
    "outboundTag": "block"
  },
  {
    "type": "field",
    "domain": [
      "geosite:cn"
    ],
    "outboundTag": "direct"
  }
]

マッチング優先順位とルール編集の手順

ルールの優先順位は、domain、ip、geositeの種類によって自動的に決まるのではなく、主に配列内の位置で決まります。コアは1番目のルールから確認し、一致すると後続ルールで結果を上書きしません。そのため、単一ドメインの例外は分類ルールより前に、分類ルールは最終的なフォールバックより前に置きます。ブロックルールを業務上の例外より無条件に上へ置くことも避けてください。

v2rayN 7.xでは、画面の文言がマイナーバージョンによって変わることがありますが、確認の順序は変わりません。まず使用中のコアを確認し、次にルーティング設定を開き、最後に有効なルーティング方案とルール順を確認します。変更後はコアを再起動するか設定を再読み込みしてください。画面を保存しただけで古い実行設定を使い続けないようにします。

1. コアを確認する

   「設定」→「パラメータ設定」→「Core タイプ」を開き、現在の設定でXrayまたはv2flyの対応コアが使われていることを確認します。プロトコルとルーティングの項目は、選択したコアが対応している必要があります。

2. ルーティングを開く

   「設定」→「ルーティング設定」に進み、現在有効なルーティング設定を選択します。複数の方案がある場合は、まずメイン画面で実際に選択されている方案名を確認してください。

3. 例外を追加する

   必ずプロキシまたは直結にしたいfull:、domain:ルールを先に追加し、その後にgeosite、geoipなど範囲の広い分類ルールを追加します。

4. 出力先を確認する

   ルールの対象がプロキシ、直結、ブロックのどれになっているか確認します。元の設定を編集する場合は、outboundTagが既存の出力先タグと完全に一致していることも確認してください。

5. 再読み込みして検証する

   保存後にコアを再起動し、例外に一致するドメイン、分類に一致するドメイン、LANアドレスをそれぞれ1つずつテストして、コアのログで実際のルーティング結果を確認します。

直結・プロキシ・ブロックの3方向ルール例

以下は構造を理解するための完全なルーティング断片です。指定したAPIをまずプロキシへ送り、次に広告分類をブロックし、その後LANと指定ドメインを直結します。前のルールで処理されなかった接続は、最後にプロキシへ送ります。使用前に、設定内にproxy、direct、blockという3つの出力先が存在することを確認してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:api.example.com",
          "domain:services.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "domain:printer.example.lan",
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

最後のルールはnetworkだけを限定し、TCPとUDPを対象にするため、フォールバックとして機能します。必ず配列の末尾に置いてください。1番目に置くと、ほぼすべての一般的な接続が直ちにプロキシへ送られ、後続の直結・ブロックルールが確認されません。TCPだけをプロキシにしたい場合は、フォールバックにUDPも指定しないでください。DNSやリアルタイム通信のトラフィックまで出力先が変わる可能性があります。

ポート条件はドメインと組み合わせることもできます。たとえばdomainにdomain:example.com、portに443を指定すると、そのドメインの443番ポートへアクセスした場合だけ一致します。同じドメインの80番ポートへのアクセスは、後続ルールの確認へ進みます。ポート範囲はコアが対応する形式で指定できますが、日常の設定では明確な業務用ポートにできるだけ限定し、説明しにくい広範囲の適用を避けてください。

• プロキシ例外をテスト：1番目のルールに明示したドメインへアクセスし、ログにproxyと表示されることを確認します。
• ブロックルールをテスト：現在のgeosite分類に確実に属するドメインを選び、接続がblockへ送られることを確認します。
• LAN直結をテスト：ルーターまたはLANサービスのアドレスへアクセスし、geoip:privateまたは明示したCIDRに一致することを確認します。
• 最終フォールバックをテスト：前方の分類に属さない対象を選び、最後のルールが出力先を決めることを確認します。

ルールが適用されないときの確認項目

切り分けの要点は、「コアが実際にどの対象を受け取ったか」と「どのルールが先に一致したか」を確認することです。ブラウザーでドメインへアクセスした場合、コアがドメイン名を受け取ることもあれば、上流のアプリが解決したIPだけを受け取ることもあります。透過入口、システムプロキシ、アプリ内プロキシでは渡される情報が完全には同じではありません。ブラウザーのアドレスバーだけを見て、コアが必ずドメイン名を取得したと判断しないでください。

次に、クライアントが設定を再生成して読み込んだか確認します。v2rayNでルーティング方案を変更しても、現在選択されている方案が編集したものと異なれば、保存内容は実際の通信に反映されません。v2rayNGやv2flyNGでサブスクリプション設定を使っている場合も、サブスクリプションの更新とローカルルーティングの変更を区別し、更新によって以前の調整が上書きされないようにします。

ルールをメンテナンスするときは、一度に1つの対象だけを調整することをおすすめします。まず明確なドメインの出力先を解決し、次にgeosite分類へ広げ、最後にIPとgeoipのフォールバックを整えます。変更ごとに、プロキシ、直結、ブロックのテスト対象を1つずつ残してください。これにより、サブスクリプション、コア、地理データが更新された場合でも、どの層で変化したかをすばやく特定できます。