ノードに接続できても、プロキシのアウトバウンドが基本的に使えると分かるだけです。中国本土のサイトへの接続が遠回りになる、LANアドレスまでプロキシに送られる、特定のドメインが指定した経路を通らないといった場合は、ルーティング層を確認する必要があります。GeoIPとGeoSiteは、ルーティング層でよく使われる2種類のマッチングデータです。VMessやVLESSなどのプロトコル設定を置き換えるものでも、サブスクリプションを更新するものでもありません。XrayやV2FlyカーネルがIPアドレスとドメインの集合を検索できるようにするデータです。
サブスクリプションを読み込み、ノードには接続できるものの、v2rayNやv2rayNGでルールが一致しない、中国本土向け通信が誤ってプロキシ経由になる、起動時にデータファイルエラーが出る方に適しています。ファイルの場所と更新時刻を確認し、2つのデータベースを更新して、ルールのプレフィックスと順序を照合したうえで、ログと実際の接続を順番に検証します。
GeoIPとGeoSiteの役割の違い
geoip.datには、国、地域、用途ごとに整理されたIPアドレス帯の集合が保存されています。ルールのgeoip:cnは宛先IPを該当する集合と照合し、geoip:privateは通常、LANやループバックアドレスなどのプライベートアドレスに使用します。宛先IPがすでに判明している通信に適しており、ドメインルールの後段で補助的に判定することもできます。
geosite.datにはドメインの集合が保存されています。geosite:cnやgeosite:category-ads-allなどのタグは通常のドメイン名ではなく、データファイルから読み込む複数のドメイン項目です。カーネルは完全一致、サブドメイン、正規表現の項目に基づいて照合するため、実際に対象サーバーへ接続する前にドメインごとの振り分けを行えます。
2種類のデータの役割は入れ替えられません。ドメインへのリクエストは、まずGeoSiteに一致する場合があります。アプリがIPアドレスへ直接接続する場合、GeoSiteには照合するドメインがないため、GeoIPやポートなどの条件に頼ることになります。TUNを有効にした場合は、スニッフィングとDNSの設定も確認してください。スニッフィングでドメインを復元できれば、ドメインルールが再び照合対象になることがあります。ドメインを復元できなければ、IPルールまたは最終ルールに処理されます。
v2rayNでGeoファイルを更新する
ここではv2rayN 7.15.0の日本語インターフェースを例に説明します。細かなバージョンによって更新メニューがメインメニューやトレイメニューに移動している場合がありますが、通常は「更新を確認」と「Geo files」を含む項目です。更新前に現在の接続が安定していることを確認してください。データソースへのアクセスにプロキシが必要な場合は、システムプロキシまたはTUNが正常に動作していることを先に確認します。
-
カーネルの種類を確認する
「設定」→「パラメーター設定」→「Core タイプ」を開き、現在の構成で実際にXrayカーネルとV2Flyカーネルのどちらを使用しているか確認します。サブスクリプション名にVLESSやVMessと表示されていても、実行中のカーネルが確定したことにはなりません。
-
更新メニューを開く
メインウィンドウに戻り、「更新を確認」→「Geo files」を選択します。現在のバージョンで「Geo ファイルを更新」と表示される場合は、その項目を選んでください。「サブスクリプションを更新」と間違えないようにします。
-
書き込み完了を待つ
メッセージ欄を確認し、geoip.datとgeosite.datの両方がダウンロードされ、書き込まれたことを確認します。あるテストでは2つのファイルの合計が約11.9 MBでした。ネットワークが安定していれば、通常5〜30秒で完了します。
-
実行中のカーネルを再起動する
「サービスを再起動」を使うか、いったん停止してから現在の構成を起動します。設定ウィンドウを閉じるだけでは、実行中のカーネルはデータファイルを再読み込みしません。
-
起動ログを確認する
「ログ」ウィンドウを開き、load geosite、load geoip、failed to startなどのメッセージがないことを確認してから、対象ドメインのアウトバウンド結果をテストします。
ポータブル版のv2rayNでは、書き込み権限を特に確認する必要があります。プログラムがシステム保護対象のフォルダーにある場合、画面上はダウンロード完了と表示されても、古いファイルが置き換わっていないことがあります。クライアントを終了してからプログラムフォルダー内の2つのファイルを確認し、更新日時が先ほどの更新時刻に近いことを確認してください。インストーラーを展開した時刻のままではいけません。
更新後すぐにDNS、ルーティング、ノード設定を同時に変更することはおすすめしません。まず元のルールを残したままカーネルだけを再起動して再テストすれば、変化が本当にデータファイルによるものか判断できます。3か所の設定を同時に変更すると、誤振り分けが起きた際に原因を特定しにくくなります。
結論:まずファイルが再読み込みされたか確認する
「ダウンロード成功」はファイル転送が終わったことを示すだけです。更新日時が変わり、カーネルの再起動が完了し、起動ログに読み込みエラーがないという3条件がそろって初めて、新しいデータが有効になったと判断できます。
v2rayNGでGeoファイルを更新する
ここではv2rayNG 1.10.31の日本語インターフェースを例に説明します。Android版は画面幅によってメニューの配置が少し変わり、該当する項目が右上のメニューにある場合があります。作業中は、更新先へのアクセスにプロキシが必要になっても対応できるよう、利用可能な構成を1つ選択した状態にしておきます。
-
ファイルのURLを確認する
右上メニューから「設定」→「Geo files 設定」に進み、GeoIPとGeoSiteのダウンロード先がそれぞれ対応するdatファイルを指していることを確認します。2つの入力欄に同じファイルURLを設定しないでください。
-
データを更新する
メイン画面に戻り、右上メニューを開いて「Geo filesを更新」を選択します。2つのファイルの処理が完了したという表示が出るまで待ち、途中でクライアントのプロセスを強制終了しないでください。
-
接続サービスを再起動する
現在の接続を切断し、約2秒待ってから再接続します。これによりXrayカーネルがルーティングモジュールを再初期化し、新しいファイルを読み込みます。
-
実行ログを開く
メイン画面から「ログ」を開き、
geoip、geosite、routingなどのキーワードを検索して、起動時にファイル読み込みエラーがないことを確認します。 -
対象接続を再テストする
まず、直接接続されるはずの中国本土のドメインをテストし、次にプロキシ経由になるはずのドメインをテストします。それぞれ出口アドレスと接続時間を記録し、ページが開くかどうかだけでルールの一致を判断しないでください。
現在のバージョンに独立したGeo更新メニューがない場合は、クライアントのバージョンと使用中のカーネルを先に確認してください。「サブスクリプションを更新」をデータベース更新と取り違えないようにします。サブスクリプション更新はサーバー設定の一覧を処理し、Geo更新はルーティング集合を処理するため、保存場所も読み込みのタイミングも異なります。v2flyNGもGeoデータの考え方を使用しますが、V2Flyカーネルとルールタグに対応したデータファイルを使う必要があります。
ルールの記述と照合順序を確認する
データベースが新しくても、ルールの記述ミスが原因でまったく機能しないことがあります。よくある問題は、プレフィックスの付け忘れ、ドメインタグをIP条件に入力すること、データファイルに存在しないタグを使うこと、範囲の広いルールを先に置くことです。ルーティングは通常、上から順に判定します。通信が最初の有効なルールに一致すると、後続のルールで上書きされることはありません。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
この例では、まずプライベートIPを直接接続し、次に中国本土のドメインを直接接続し、その後中国本土のIPを直接接続します。最後に、残りのTCPとUDP通信をプロキシのアウトバウンドへ送ります。実際の設定ではdirectとproxyを既存のアウトバウンドタグに合わせる必要があります。クライアントが生成したタグがfreedom、blockなど別の名前の場合は、現在の完全な設定を基準にしてください。
geosite:cnはドメイン条件に記述し、IP条件には記述しないでください。geoip:cnとgeoip:privateはIP条件に記述してください。domain:example.comは、そのドメインと一般的なサブドメインの範囲に一致させるために使います。完全一致が必要な場合は、カーネルが対応するルール形式で設定してください。- カスタムデータタグは、使用するdatファイルに実際に存在している必要があります。ファイル名からタグを推測してはいけません。
- ブロック、直接接続、プロキシのルールは、対象範囲の狭いものから広いものへ並べ、最後にフォールバックルールを置きます。
domainStrategyも結果に影響します。AsIsは主に元のドメイン情報で照合し、IPIfNonMatchはドメインルールに一致しない場合にIPを解決してからIPルールを試します。IPOnDemandはより早い段階で名前解決を行うことがあります。この項目を変更するとDNS経路にも関係するため、単純な「振り分け強化」スイッチとして扱わないでください。
結論:最初に一致したルールを確認する
ルールの結果が想定と逆の場合は、より範囲の広いドメイン、IP、ポート、または全ネットワーク向けのルールが上にないかを優先して確認します。対象ルールをリストの末尾へ移動するだけでは、通常、優先度は上がりません。
起動エラーとデータベース異常を確認する
ファイルが存在しない、内容が壊れている、タグが不足しているといった場合、カーネルは通常「接続失敗」より具体的な情報を起動ログに残します。調査時はエラー全体を保存し、特にファイル名、タグ名、下位層の読み込み原因を確認してください。最後の1行だけを抜き出すのは避けます。
エラー:failed to load geosite: geosite.dat: no such file or directory
原因と対処:カーネルの作業ディレクトリにgeosite.datがないか、クライアントが誤ったパスを参照しています。Geo filesの更新を再実行し、現在のカーネルディレクトリにファイルが書き込まれたことを確認してからサービスを再起動してください。
エラー:failed to load GeoIP: geoip.dat: no such file or directory
原因と対処:GeoIPファイルがない、移動された、または更新が完了していません。クライアントを終了し、geoip.datが存在してサイズが0バイトではないことを確認してから、もう一度ダウンロードしてください。
エラー:failed to decode geosite.dat: invalid wire-format data
原因と対処:ダウンロードした内容が有効なデータファイルではありません。転送の中断や、URLからWebページが返された場合によく起こります。異常なファイルを削除し、クライアントの更新メニューから再取得してカーネルを再起動してください。
エラー:failed to load geosite: list not found
原因と対処:ルールが参照するタグが現在のgeosite.datにありません。タグのつづりとデータソースを確認し、そのルールを一時的に削除してカーネルが正常に起動できるか確認してください。
更新後にクライアントを起動できなくなった場合は、まずルーティング設定をバックアップし、Geoタグを参照するカスタムルールをすべて一時的に無効にします。カーネルが起動できれば、ノードのプロトコルと基本的なアウトバウンドはおそらく正常で、問題はデータファイルまたはルールタグに絞れます。それでも起動できない場合は、ポートの競合、設定構文、カーネルのパスを引き続き確認してください。
ファイルが重複して配置されていないかも確認してください。クライアントのフォルダー、カーネルのサブフォルダー、カスタムリソースフォルダーに同名ファイルがそれぞれ存在し、実際に読み込まれているのが更新直後のファイルとは限りません。最も確実なのは、起動ログに表示されたリソースパスを確認し、そのパスにあるファイルの更新日時とサイズを照合することです。
ルールに一致するのに振り分けが誤る
ログにエラーがなくても、振り分け結果が期待どおりとは限りません。Geoデータは集合として管理され、ドメインの所属やサーバーIPは変わる可能性があります。大規模サイトでは複数地域の名前解決やコンテンツ配信も使われるため、同じドメインでもネットワークによって異なるアドレスが返ることがあります。「ルールが一致しなかった」のか、「一致後に選ばれたアウトバウンドが期待と違った」のかを切り分けてください。
| 現象 | 優先して確認する項目 | 検証方法 |
|---|---|---|
| 中国本土のドメインがプロキシ経由になる | GeoSiteタグとルールの順序 | 対象ドメインを直接接続ルールに単独で追加し、範囲の広いプロキシルールより前に置く |
| IPアドレスへ直接接続したときに一致しない | GeoIP条件と対象IPの所属 | 対象IPを記録し、geoip:cnまたはプライベートアドレス集合に一致するか確認する |
| TUN使用時の結果がシステムプロキシと異なる | スニッフィング、DNS、domainStrategy | ノードを変更せず、2つのモードでログに記録された対象ドメインとIPをそれぞれ確認する |
| 更新後、一部のルールだけ機能しない | カスタムタグが存在するか | 拡張タグを1つずつ無効にし、geosite:cnとgeoip:cnを残して基準テストを行う |
| LAN内のデバイスにアクセスできない | geoip:privateの位置 | プライベートIPの直接接続ルールをプロキシのフォールバックルールより前に置いて再接続する |
最小構成のテスト設定を作ることをおすすめします。利用可能なノード1つ、プライベートアドレスの直接接続1つ、中国本土のドメインの直接接続1つ、中国本土のIPの直接接続1つ、プロキシのフォールバック1つだけを残します。このルール群が正常に動作することを確認してから、広告ドメイン、カスタムドメイン、プロセス、ポートのルールをグループごとに戻します。1グループ戻すたびにテストするほうが、数十個のルールを一度に読み込むより競合を特定しやすくなります。
検証時は少なくとも3つの結果を記録します。対象ドメインから解決されたIP、カーネルが選択したアウトバウンドタグ、最終的な出口アドレスです。Webページの表示速度はキャッシュ、サーバー負荷、ネットワークの揺らぎに左右されるため、振り分けの正しさを単独で証明できません。ローカルSOCKSの待ち受けポートを10808にしている場合は、テストツールが実際にそのポートへ接続しており、クライアントを迂回してシステムの直接接続を使っていないことも確認してください。
結論:最小ルールでデータの問題と順序の問題を切り分ける
基本のgeosite:cnとgeoip:cnが正常に動作し、拡張ルールを段階的に戻した後にだけ誤振り分けが発生するなら、問題は通常、2つのデータベース自体ではなく追加ルールの範囲または順序にあります。
更新後に行う完全な確認リスト
確実な更新では、ファイル、カーネル、ルール、接続の4つの層を確認します。メニューに「完了」と表示されただけでは、新しいデータでルーティングが実行されている証明にはなりません。以下の確認を終えてから、自動起動や定期的なサブスクリプション更新などの日常設定を戻してください。
- geoip.datとgeosite.datが両方存在し、サイズが0バイトより大きく、更新日時が今回の更新時刻に近いことを確認する。
- 想定したカーネルが実行されていることを確認する。v2rayNでは「設定」→「パラメーター設定」→「Core タイプ」から確認できる。
- 切断して再接続し、古いカーネルプロセスが終了して新しいプロセスがリソースファイルを再読み込みしたことを確認する。
- 起動ログを確認し、file not found、decode、list not foundなどの読み込みエラーがないことを確認する。
- GeoSiteタグがドメイン条件、GeoIPタグがIP条件に設定され、アウトバウンドタグが既存の構成と一致していることを確認する。
- プライベートアドレスや完全一致ドメインなどの狭いルールを、範囲の広いプロキシのフォールバックより前に置き、先に一致しないようにする。
- ドメイン接続とIPアドレスへの直接接続をそれぞれテストし、ページが開くかどうかだけでなく、実際に選択されたアウトバウンドを記録する。
- システムプロキシまたはTUNモードのアプリ通信が実際にクライアントへ入り、テストツールがローカルプロキシポートを迂回していないことを確認する。
Geoデータはサブスクリプションを更新するたびに再ダウンロードする必要はありません。サブスクリプションの変更は主にノード一覧に影響し、Geoファイルの変更は主にルーティング集合に影響します。必要に応じて定期更新するか、新しいドメインを分類できない、古いIPの所属が明らかに変わった、拡張タグが不足しているといった場合に手動で更新してください。ファイルを頻繁に上書きしてもカーネルを再起動しなければ、ディスク上のバージョンと実行中のバージョンが食い違いやすくなります。
特定のドメインが集合によって長期的に誤分類されると確認できた場合は、対象範囲の狭いカスタムドメインルールを追加し、該当する集合ルールより前に置くのが最も安全な一時対処です。これなら現在の接続を修正しつつ、GeoSiteやGeoIPのルール群全体を削除せずに済みます。次回のデータ更新後に、そのドメインで例外設定を残す必要があるか再テストしてください。