GeoIP・GeoSiteの更新方法とルーティング設定

GeoIPとGeoSite：IPとドメインをそれぞれ判定

geoip.datにはタグ別に整理されたIPアドレス範囲が、geosite.datにはタグ別のドメインルールが保存されています。どちらもコアが読み込むデータファイルであり、ノードのサブスクリプションやプロキシプロトコルではありません。更新してもVMessやVLESSノードのサーバーアドレス、ユーザーID、通信パラメーターは変更されません。

geosite:cnは、現在使用中のドメインデータベースにあるcnの集合を参照します。「.cn」で終わるすべてのドメインを指すわけではありません。同様に、geoip:cnもWebサイトの登録地を調べるものではありません。CDNを利用するWebサイトは複数地域のIPアドレスを返すことがあり、ドメインによる振り分けと、名前解決後のIPアドレスによる振り分けでは結果が異なります。

更新前に確認すること：提供元・コア・読み込み先

更新に失敗する原因は主に3つあります。クライアントが更新した場所とコアが読み込む場所が異なる、新しいデータソースに既存ルールが参照するタグがない、ダウンロードした内容が有効なデータファイルではない、のいずれかです。作業前に、現在使えている2つのファイルとルーティングルール、またはクライアント設定のエクスポートファイルをバックアップしてください。

• まずコアを確認します。クライアントのノード設定と起動ログでコア名を確認してください。デスクトップのショートカット名だけで判断しないでください。
• 次にデータの提供元を確認します。まずは現在のクライアントで標準設定されているデータソースを使いましょう。独自の提供元を使う場合は、既存ルールで必要なcnやprivateなどの集合が含まれているか確認してください。
• 実際の読み込み先を確認します。クライアントが管理するリソースディレクトリと、起動エラーに表示されるパスを基準にしてください。ポータブル版のフォルダー、独立したデータディレクトリ、複数のインストール先は、それぞれ別の場所である場合があります。
• 元に戻せるようにしておきます。元の提供元、更新日時、ルーティング設定を記録してください。ルールのテキストだけをバックアップしても、新しいファイルに必要なタグがない問題は解決できません。

クライアントでルールファイルを更新する：ダウンロード後にコアを再読み込み

メニュー名はバージョンや表示言語によって異なります。デスクトップ版v2rayNでは、「更新を確認」メニュー内にGeoファイルの更新項目があるのが一般的です。バージョンによってはGeoIPとGeoSiteが別々に表示されます。機能を目印に探し、該当項目が見つからない場合は、現在のバージョンのメニューとログを確認してください。「サブスクリプションの更新」はルールデータベースの更新とは異なります。

1. まず接続できる状態にします。ノードが利用できることを確認してください。現在のネットワークからルールの提供元にアクセスできない場合は、クライアントの更新用プロキシ設定を有効にしてダウンロードできます。システムプロキシが有効かどうかだけで判断せず、更新ログも確認してください。
2. Geoファイルを更新します。v2rayNで「更新を確認」を開き、Geoファイルの更新項目を選択します。2つの項目に分かれている場合は、GeoIPとGeoSiteをそれぞれ更新してください。各項目の完了を確認してから、ルーティングを変更します。
3. エラー内容を確認します。タイムアウトは通常、接続の問題を示します。解析・展開・書き込みの失敗では、ダウンロード内容、フォルダーのアクセス権、ファイルの使用中状態を確認してください。ファイルの更新日時が変わったかどうかは、あくまで補助的な確認材料です。
4. コアを再読み込みします。クライアントに再起動やコアの再読み込み機能があれば実行してください。専用ボタンがない場合は接続を停止してから再起動します。その後、起動ログにデータファイルや分類の読み込みエラーがないか確認してください。
5. 振り分けを検証します。更新前と同じルーティングモードとテスト対象を使い、実際の出力先を比較してください。この段階でノード、DNS、ルーティングテンプレート全体を同時に変更しないでください。

Android版では、v2rayNGのGeoリソース更新項目はサイドメニューやリソース関連の画面から開けることが一般的です。画面の案内に従って更新してください。v2flyNGのメニュー構成や利用可能な更新項目は、インストールされているバージョンで確認してください。別のクライアントのメニュー名をそのまま当てはめないでください。モバイル端末でも、更新後は接続を停止して再起動する必要があります。

ルーティングルールの書き方：ドメインを優先し、IPで補完して最後にフォールバック

ルーティングはルールの記述順に照合され、一致すると対応するアウトバウンドが使われます。ここでは「中国本土のドメインは直接接続、プライベートIPと中国本土のIPも直接接続、それ以外のTCP／UDPはプロキシ経由」という基本構成を紹介します。directとproxyはどちらもアウトバウンドのタグです。既存設定のoutbounds[].tagと完全に一致させてください。

これは設定の一部であり、クライアント設定全体ではありません。V2Ray／XrayのJSONを直接編集する場合に使えます。クライアントのGUIでルーティングを管理する場合は、ルーティングエディターで同じ順序のルールを作成し、現在有効なルールセットとして保存してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

• 1つ目のルールではドメイン集合を判定します。リクエストにドメインが含まれ、geosite:cnに一致した場合はdirectを選択します。同じ振り分け判定でGeoIPに頼る必要はありません。
• 2つ目のルールではIP集合を判定します。同じip配列にある2つの集合は、どちらか一方に一致すれば対象になります。両方に同時に属することが条件ではありません。プライベートIP集合の範囲は、使用するデータファイルによって異なります。
• 3つ目のルールで明示的にフォールバックします。それまでのルールに一致しないTCPとUDPのリクエストはproxyに送られます。このような広範囲に一致するルールは末尾に置いてください。先に置くと、後続のルールが照合されない場合があります。
• 項目を安易にまとめないでください。1つのルールにdomainとipを両方指定しても、「ドメインまたはIPのどちらかに一致」という意味にはなりません。異なる条件項目は通常、すべて満たす必要があります。ルールを分けるほうが確認しやすくなります。

IPIfNonMatchは、ドメインリクエストのルーティング先がドメイン条件で決まらなかった場合に、対象のIPアドレスを名前解決し、IP条件でもう一度照合する設定です。最後のnetworkフォールバックはドメイン分類ではなく、この名前解決の代わりにもなりません。AsIsに設定すると、ルーティングモジュールはIPルールのためにドメインを自動で名前解決しません。ドメイン情報しかないリクエストは、フォールバック先に送られる可能性があります。

DNSとルールの順序：更新に成功しても振り分けが意図どおりとは限らない

GeoSiteはDNSサーバーを自動で指定しません。GeoIPも名前解決の誤りを修正しません。どのアウトバウンドで接続するかはルーティングモジュールが決め、アドレスをどう取得するかはDNS設定が決めます。両者には関係がありますが、「中国本土のドメインは直接接続する」ことが「DNS問い合わせも中国本土のDNSに送る」ことを意味するわけではありません。DNSサーバーの選択と問い合わせの送信先は、別途確認してください。

IPIfNonMatchを設定していても、先行するドメインルールに一致したリクエストが、後続のGeoIPルールで判定し直されることはありません。反対に、アプリがプロキシに渡す前にドメインをIPアドレスへ変換している場合、GeoSiteで照合できるドメイン情報がない可能性があります。スニッフィングでドメインを取得できるかは、プロトコル、トラフィックの種類、設定によって異なります。確実な解決策とは限りません。

更新失敗・分類が見つからない場合の対処

常に最新の状態にするために、データソースを毎日変更する必要はありません。一般的な利用であれば週に一度確認し、分類に明確な変更があった場合やログにエラーが出た場合に、その都度対応すれば十分です。ルールデータベースを更新してもノード自体の帯域は増えず、サーバー側のプロトコル対応状況も変わりません。更新によって改善されるのは、ルーティング判定の基準となるデータです。

適用結果を検証する：3つの接続先を固定し、復元手段を残す

検証には、直接接続される想定のドメイン、プロキシ経由になる想定のドメイン、アクセス権のあるLAN内サービスを1つずつ選びます。速度測定ではなく、3種類の接続がそれぞれ想定したアウトバウンドに進むか確認するのが目的です。LAN内サービスは実在するアドレスを使用し、ランダムなアドレスへテストリクエストを繰り返し送らないでください。

1. 接続先の設定を統一します。たとえばアプリで127.0.0.1:10808を使用する場合は、そのポートが現在のクライアントの待ち受けポートであることと、対応するプロキシプロトコルを確認します。10808は一例であり、実際の設定を確認してください。
2. 設定が読み込まれているか確認します。ルーティング設定を保存してコアを再読み込みし、ファイルの読み込み、タグの不足、設定の解析に関するエラーがないか確認してください。起動に失敗している場合、ブラウザーの表示からルーティングの動作を推測しないでください。
3. 接続先ごとに新しい接続を作成します。対象、時刻、ログに表示されたアウトバウンドタグを記録してください。クライアントの表示がdirect／proxyだけの場合、接続先の確認はできますが、どのルールに一致したかまでは分からないことがあります。
4. 問題の範囲を絞り込みます。必要に応じて一時的に最小限のルールだけを残すか、ログの詳細度を上げて短時間だけ再現してください。調査後は通常のログレベルに戻します。ログを共有する前に、ノードのアドレス、ユーザーID、アクセス履歴を削除してください。
5. 動作する状態を保存します。3つの接続先がすべて想定どおりに動作したことを確認してから、古いバックアップを整理してください。問題が起きた場合は、元のファイルとルールに戻してから、更新と設定変更を個別にやり直します。

最後に、ルールファイルの提供元、ルーティングの順序、実際に使用しているコアの3点を記録しておきましょう。別の端末への移行やクライアントの再インストール後も、同じ振り分けを復元してから分類やDNSを調整できます。初期設定は設定ガイド、各項目の意味はプロトコルリファレンスをご覧ください。