ノードには正常に接続できるのに、本来は直接接続するはずのサイトが突然プロキシ経由になったり、特定のドメインが想定したルールに一致しなかったりする場合があります。こうした問題は、必ずしもサブスクリプション、VMess、VLESS、ノード自体が原因とは限りません。ルーティングルールで geoip: や geosite: を参照している場合、実際の一致結果はローカルに読み込まれたデータファイルに左右されます。
この記事は、v2rayN、v2rayNG、v2flyNGを使用し、ドメインやIPのルーティングルールを有効にしている方を対象としています。2つのデータベースの役割を整理し、クライアント内で更新するか手動で置き換えたうえで、ログ、ルールの順序、テスト用ドメインから新しいデータが現在のコアに読み込まれたことを確認します。
まずgeoip.datとgeosite.datの照合対象を区別する
geosite.datにはドメインの分類リストが保存されています。geosite:cnやgeosite:category-ads-allなどの記述は、ネットワーク上のリアルタイムサービスに問い合わせるものではなく、コアがローカルファイル内の分類項目を読み込む指定です。ドメインが追加・移転されたり用途が変わったりしても、ローカルデータを長期間更新していなければ、古い分類のままになる可能性があります。
geoip.datにはIPアドレス帯の分類が保存されています。geoip:cnは、対象IPをデータベース内のアドレス範囲と照合します。サイトの名前解決先が変わったり、クラウドサービスでアドレス帯が再割り当てされたり、新しいアドレス帯が古いデータベースに未収録だったりすると、IPルールで一致しないことがあります。
GeoSiteドメイン分類
- ファイル
- geosite.dat
- 照合対象
- 完全修飾ドメインとドメイン集合
- 代表的な記述
- geosite:cn
- 主な用途
- ドメインの直接接続とカテゴリによるブロック
ドメイン情報が残っている場合、通常はまずGeoSiteルールで判定されます。
GeoIPアドレス分類
- ファイル
- geoip.dat
- 照合対象
- IPv4およびIPv6のアドレス帯
- 代表的な記述
- geoip:cn
- 主な用途
- 宛先アドレスの直接接続またはプロキシ接続
IPルールが適用されるかどうかは、domainStrategyの設定にも左右されます。
ルーティング異常が古いデータベースによるものか判断する
一度ルーティングを誤っただけで、すぐにファイルを置き換えるのは避けてください。まずコアが正常に動作していることを確認し、ルールの順序、DNSの結果、アウトバウンドタグの誤りを切り分けます。ルーティングシステムは通常、ルールの上から順に照合するため、前方の広範なルールが先にトラフィックを受けると、後続の geosite:cn や geoip:cn が実行されないことがあります。
10808と10809はv2rayNでよく使われる初期値であり、すべての環境で固定されているわけではありません。実際のポートは「設定」→「パラメータ設定」で確認してください。ブラウザーのプロキシをテストする場合、ポートは現在のローカルインバウンドと一致している必要があります。ポートを間違えると完全にアクセスできなくなりますが、これはGeoデータの誤判定ではありません。
- ノードを確認：使用可能なノードを2つ切り替えて、それぞれでテストします。すべてのノードに接続できるのに、同じドメイン群が常に誤ったアウトバウンドへ送られるなら、ルーティングデータまたはルール設定に問題がある可能性が高くなります。
- ルールの順序を確認：ドメインの完全一致、GeoSite、GeoIP、最後のフォールバックルールを上から順に確認します。最終フォールバックは分類ルールの後ろに置く必要があります。
- ログを確認：v2rayNで実行ログを開き、テスト用ドメインに再度アクセスして、適用されたoutboundTagを確認します。ログレベルが低い場合は、「設定」→「パラメータ設定」で一時的に変更してからコアを再起動してください。
- ファイルの日付を確認：現在のコアが実際に使用しているリソースディレクトリを特定し、geoip.datとgeosite.datの更新日時を確認します。ダウンロードフォルダーにあるコピーだけを確認しないでください。
- 比較基準を作る：更新前に少なくとも3つのテスト対象を記録します。明らかに直接接続すべきドメイン、プロキシ経由が想定されるドメイン、IPを直接指定するリクエストを1つずつ含めてください。
結論：まずルールが実行されたことを確認し、その後でデータベースの古さを判断する
ログでGeoルールより前に、より広範なルールへ一致していることが分かるなら、ファイルを更新しても結果は変わりません。ルールの順序が正しく、対象がまだ分類されていない場合に限り、データベースの更新が有効です。
v2rayNでGeoIPとGeoSiteを更新する
新しいv2rayNでは、通常、上部メニューにGeoファイルの更新項目があります。まず更新元へ安定してアクセスできるノードに接続し、「更新を確認」→「Geo files」を開きます。バージョンによってはGeoIP/GeoSite更新と表示されるなど名称が異なりますが、対象は現在のコアディレクトリにある2つのデータファイルです。
更新中はクライアントを終了したり、同名ファイルを手動で上書きしたりしないでください。メニューで完了が表示されたら、「サービスを再起動」を実行するか、v2rayNを終了して再起動し、XrayまたはV2Rayコアが古いファイルを解放して再読み込みできるようにします。メインウィンドウだけを閉じてクライアントを常駐させると、完全な再読み込みが行われない場合があります。
クライアント内で更新
- 事前条件
- 使用可能なノードが1つ以上あること
- メニューの場所
- 更新を確認 → Geo files
- 更新対象
- geoip.dat、geosite.dat
- 完了後の操作
- 現在のコアを再起動
誤ったディレクトリを上書きする可能性を減らせるため、まずはクライアントの更新機能を使うのがおすすめです。
手動で置き換える
- 手順1
- クライアントを完全に終了
- 手順2
- 元の2つのファイルをバックアップ
- 手順3
- コアのリソースディレクトリを上書き
- 手順4
- 起動してログを確認
ファイル名は変更せず、2つのファイルを同じ更新世代のデータでそろえてください。
クライアント内での更新に失敗した場合は、手動で置き換えることもできます。ただし重要なのは、ファイルをv2rayNのルートディレクトリに入れることではなく、現在選択しているコアのリソースディレクトリを見つけることです。v2rayNのバージョンやデスクトップ版、WPF版によってディレクトリ構成は異なります。一般的なインストールでは、コア名ごとに分かれた bin サブディレクトリがあります。最も確実なのは、実行ログでコア実行ファイルのパスを確認し、その近くのリソースディレクトリで同名の2つのファイルを探す方法です。
Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。現在のバージョンに「Geoファイルを更新」項目がある場合は、ネットワーク接続が利用できる状態で実行し、コアを再起動してください。その項目がない場合は、クライアントのバージョン更新に合わせてリソースも更新します。ルーティングのテストでは、「設定」→「ルーティング設定」を開いて現在有効なルールセットを確認してください。サブスクリプションが更新されたかどうかだけで判断してはいけません。
routingの記述とdomainStrategyを確認する
データベースを更新しても結果が変わらない場合は、次に設定の参照先が正しいか確認します。GeoSite項目はルールの domain 配列に、GeoIP項目は ip 配列に記述します。両者を入れ替えることはできません。ルールは実在する outboundTag を参照する必要もあり、存在しない場合、コアがエラーを出したり、想定どおりにアウトバウンドを選択できなかったりします。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:cn",
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}上記の順序では、まずドメイン、次にIPを確認し、最後に残りのTCPおよびUDPトラフィックを proxy へ送ります。direct と proxy は、outbounds 内のtagと大文字・小文字を含めて完全に一致していなければなりません。設定で実際に direct-out を使用しているなら、ルーティングにも同じ名前を記述します。
- AsIs：リクエストに含まれる元のドメインを優先して照合し、IPルールのためにドメインを自動解析しません。宛先がドメイン形式の場合、後続のGeoIPルールは適用されない可能性があります。
- IPIfNonMatch：ドメインルールに一致しなかった場合に宛先アドレスを解析し、その後IPルールを試します。GeoSiteとGeoIPを併用する一般的なルーティング構成に適しています。
- IPOnDemand：IPが必要なルールに遭遇すると、より早い段階で名前解決を行うことがあります。DNS問い合わせのタイミングが変わるため、有効にする前にDNS設定が想定どおりか確認してください。
プログラムがIPアドレスへ直接接続する場合、GeoSiteはそのアドレスから元のドメインを逆算できないため、主にGeoIPに依存します。反対に、宛先がリモートDNS、内蔵DNS、特殊な転送を経由すると、コアから見える情報が変わることもあります。そのため、同じサイトでもブラウザーとコマンドラインツールでルーティング結果が異なるからといって、必ずしもデータベースが壊れているとは限りません。
ログと比較用リクエストで更新結果を確認する
確認では、Webページを開けるかどうかだけを見てはいけません。直接接続でもプロキシ経由でも成功する可能性があるためです。確認すべきなのは、更新後の対象が想定したルールに一致したか、想定したアウトバウンドが選ばれたか、再起動後も結果を安定して再現できるかです。各テストの前にブラウザーの接続を閉じるか、古い接続が終了するまで待ち、接続の再利用が判断に影響しないようにします。
- 現在のバージョン状態を記録：2つのデータファイルの更新日時、現在のコアの種類、現在のルーティング設定名を控えます。
- コアを再起動：v2rayNでサービスの再起動を実行します。Androidクライアントでは現在の接続を停止してから再起動してください。
- リクエストを1つずつ送信：まずGeoSiteに一致するはずのドメイン、次に直接入力できるIP、最後にフォールバックプロキシの対象をテストします。
- ログを読む：宛先アドレス、ルールの一致結果、最終的なアウトバウンドタグを確認します。接続が確立したかどうかだけを見ないでください。
- 3回繰り返す：間隔を空けて接続を再確立し、DNSキャッシュや長時間接続による一時的な現象ではないことを確認します。
Geoファイルを更新したのに、なぜルーティングが変わらない？
まずコアを完全に再起動し、ログのoutboundTagを確認します。リクエストが前方にあるdomain、ip、networkの広範なルールに先に一致しているなら、ファイルのダウンロードを繰り返すのではなく、ルールの順序を見直してください。
サブスクリプションを更新したばかりでも、GeoIPは別途更新が必要？
それぞれ別に判断する必要があります。サブスクリプションには通常、ノードとグループの情報が含まれますが、Geoデータはコアのルーティングリソースです。「更新を確認」→「Geo files」を開いて個別に更新し、完了後にサービスを再起動してください。
手動で置き換えた後、「geosite分類が見つからない」と表示された場合は？
ファイル名がgeosite.datのままか、現在のコアが実際に読み込むディレクトリを上書きしたかを確認し、次にルール内の分類名が存在するか確認します。バックアップファイルに戻すと、問題がファイルにあるのかルール名にあるのかをすばやく切り分けられます。
ドメインルールには一致するのに、GeoIPルールにはまったく一致しない？
routing.domainStrategyを確認してください。AsIsでは、後続のIPルールのためにドメイン宛先を自動解析しません。設定目的に応じてIPIfNonMatchへの変更を検討し、DNS設定も合わせて確認します。
更新中にネットワークタイムアウトが表示された場合は？
まず現在のノードが利用可能か確認し、クライアントの更新機能から再試行します。それでも失敗する場合は元のファイルを残して時間を置いて再試行してください。使用中のデータファイルを削除してからコアを起動するのは避けます。
結論：更新完了の判断基準は一致結果が変わること
ファイルの日時が新しくなっただけでは、確認の第一段階にすぎません。コアが再読み込みを完了し、ログで対象が想定したGeoルールに一致し、3回連続で同じ正しいアウトバウンドが選択されて初めて、今回の更新が実際に反映されたと判断できます。
元に戻せる更新手順を習慣にする
GeoIPとGeoSiteは起動のたびに更新する必要はありませんが、長期間更新しないと分類のずれが徐々に大きくなります。安定して再現する誤判定が見つかったとき、クライアントのコアを更新したとき、大規模なルーティングルールセットを変更したときに確認するのが適切です。ネットワークが不安定になるたびに、すぐファイルを置き換える必要はありません。
- 前のバージョンのgeoip.datとgeosite.datを残し、コアが自動スキャンしない独立したディレクトリにバックアップを保存します。
- 2つのファイルは同じ更新世代のものとして扱い、置き換え日と現在のコアの種類を記録します。
- 固定した3つのテスト対象を残し、ドメインの直接接続、IPの直接接続、プロキシのフォールバックをそれぞれ確認します。
- ルールの変更とデータの更新は分けて行い、どの操作で結果が変わったのか分からなくなるのを防ぎます。
- 更新に失敗した場合は、まず完全なバックアップを復元してから、ネットワークやディレクトリ権限の問題に対処します。
特定のドメインをすぐに修正する必要があるのに、データベースがまだ対応していない場合は、GeoSiteルールより前に完全一致のドメインルールを追加できます。たとえば full:example.com で単一の完全なドメインに一致させたり、domain:example.com でそのドメインとサブドメインに一致させたりします。完全一致ルールは数を増やしすぎず、データベースが後から対応した時点で見直して、暫定ルールが恒久化しないようにしてください。
完全なトラブル対処の順序は、ノードとローカルポートの確認、ルールの順序の確認、Geoファイルの日付の確認、更新の実行、コアの再起動、ログの確認、比較用リクエストの反復に固定できます。この順序はXrayとv2flyコアの両方に適用できます。違いはリソースディレクトリとクライアントのメニュー位置だけで、GeoIPとGeoSiteの基本的な照合の役割は変わりません。