この記事は、ノード経由で通信できており、v2rayNのルーティングを調整したい方向けです。ドメインリストとIPリストの違いを確認し、ルーティングの名前解決方式、出力タグ、ルールの順序を設定します。最後にログで国内直結、プライベートIPへの接続、広告ブロックを確認します。掲載するJSONはコア設定の一部であり、そのままインポートできる完全なノード設定ではありません。
1. 振り分け設定の前に通信経路と出力先を確認
ルーティングによる振り分けは、通信がコアに届いた後に行われます。アプリがシステムプロキシを使っていない場合や、現在のプロキシモードで処理されない接続には、ルールを変更しても反映されません。まず利用可能なノードを選び、ブラウザーがv2rayNのローカルプロキシを使っていることを確認してから設定を始めてください。システムプロキシが対象にするのは、その設定に従うアプリです。端末上のすべての通信を自動的に捕捉するものではありません。
ルール内のoutboundTagは出力先を示すタグで、プロトコル名ではありません。この記事では、proxyを設定済みのノード、directをfreedomの直接接続、blockをblackholeの遮断先として扱います。タグは大文字と小文字を区別するため、実際の設定と一致させてください。
2. geositeとgeoipが照合する対象
geosite:cnはドメインのリストで、分類済みの中国国内サイトの判定に適しています。geoip:cnはIPアドレス範囲のリストで、IPアドレスへの直接接続や、名前解決結果に基づく追加の振り分けに利用できます。どちらもルール用のデータであり、サイトの運営地域、実際のサーバー所在地、通信品質をリアルタイムで判定するものではありません。中国国内のドメインが海外のインフラを使うことも、海外サービスの名前解決結果が中国国内のIPになることもあります。
ドメインリストのルール
- 項目
domain- 中国国内のリスト
geosite:cn- 広告リスト
geosite:category-ads-all- データファイル
geosite.dat
ルーティングの判定時に対象ドメインを取得でき、データファイルに該当カテゴリが含まれている必要があります。
IPリストのルール
- 項目
ip- 中国国内のリスト
geoip:cn- プライベートIPのリスト
geoip:private- データファイル
geoip.dat
宛先がIPアドレスなら直接照合できます。宛先がドメイン名の場合、名前解決を行うかどうかはルーティング設定によって異なります。
1つのルールにdomainとipの両方を指定しても、「ドメインかIPのどちらかが一致すればよい」という意味にはなりません。通常、異なる条件フィールドはすべて満たす必要があります。同じ配列内の複数の項目は照合候補になります。誤解を避けるため、中国国内ドメインと中国国内IPは別々のルールに分けてください。
domain:example.comは、指定したドメインとそのサブドメインに一致します。ドメイン全体との完全一致を指定するfull:example.comとは用途が異なります。192.168.1.1のようなプライベートIP宛ての通信は、直接接続を優先するのが基本です。ただし、アプリからの接続が実際にコアへ渡されている必要があります。- 使用前に、現在の地理データに
cn、private、広告カテゴリが含まれていることを確認してください。カテゴリがないと設定の読み込みに失敗する場合があり、ルール順の変更だけでは解決できません。
3. domainStrategyが中国国内IPの追加判定に与える影響
domainStrategyはroutingオブジェクト内でrulesと並べて指定します。ルーティング判定でドメインをIPアドレスに名前解決するかどうかを制御しますが、アプリがプロキシを使うかどうかを決める設定ではなく、DNS設定全体を表すものでもありません。名前が似た出力側の名前解決設定は別のスコープに属し、相互に置き換えることはできません。
AsIs
受け取った宛先の形式のままルーティングし、IPルールのためにドメインを積極的に名前解決しません。宛先が最初からIPアドレスの場合は、IPルールの照合対象になります。
向いているケース：主にドメインリストを使い、ルーティング段階での名前解決を抑えたい場合。
IPIfNonMatch
推奨最初のルール判定でドメインが一致しなかった場合に、名前解決してIPルールとの照合を試みます。この記事では、ドメインルールを優先しつつ、中国国内IPの判定を補うために使用します。
向いているケース：中国国内ドメインを直接接続し、国内IPの判定も補う一般的な振り分け。
IPOnDemand
IPを必要とするルールに到達した時点で、ドメインの名前解決を試みます。IPルールの配置場所が、名前解決のタイミングと最終的な接続先により直接影響します。
向いているケース：IP判定を早い段階で行う必要があり、DNSとルール順を考慮して設定している場合。
4. 広告、中国国内ドメイン、プライベートIP、中国国内IPの順に設定
ルールは上から順に判定され、最初に一致したルールで出力先が決まります。中国国内リストに含まれる広告ドメインが先に許可されないよう、広告カテゴリを中国国内ドメインより前に置きます。続けて中国国内ドメイン、プライベートIP、中国国内IPを処理し、それ以外の通信はプロキシに送ります。以下はrouting部分のみの例です。既存の完全な設定に統合してください。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
}上記のルールを使うには、対応する出力先があらかじめ設定されている必要があります。既存ノードの認証、トランスポート、安全性に関する設定はそのまま保ち、出力タグをproxyにしてください。例に合わせるためにノードのパラメーターを書き直す必要はありません。次の2つのオブジェクトは直接接続先と遮断先の定義例です。既存のoutbounds配列に追加し、プロキシの出力先より後ろに置いてください。
[
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]- 誤って遮断されたドメインを許可する場合は、対象を絞った直接接続の例外ルールを広告ルールより前に追加してください。広告カテゴリ全体を削除するのは避けましょう。
- 広告ドメインのブロックですべてのページ広告を消せるわけではありません。同一ドメインから配信されるコンテンツ、アプリ内蔵のリソース、データに登録されていないアドレスは区別できない場合があります。
- 海外サービスの名前解決結果が中国国内IPになると、最後の中国国内IPルールによって直接接続されることがあります。プロキシ経由にしたい場合は、そのサービスのドメインを対象とするプロキシルールを中国国内向けルールより前に追加してください。
5. v2rayNに設定し、生成された設定を確認する
v2rayNのルーティング編集画面はコア設定を生成します。一方、サブスクリプションは主にノード情報を提供するものであり、両者は別の役割です。デスクトップ版はリリースによってメニュー名が多少異なる場合があります。ここでは「設定」→「ルーティング設定」から開く画面を例に説明します。画面が異なる場合は、生成後のroutingとoutboundsを基準に確認してください。
-
現在のルールをバックアップ
「設定」→「ルーティング設定」を開き、既存ルールを保存するか現在の設定をエクスポートします。使用中のルーティング方式も記録し、すでに使っている例外ルールを上書きしないようにしてください。
-
独立したプロファイルを作成
「ルーティング設定」で新しいプロファイルを作成するか、既存のものを複製します。ドメインの判定方式を
IPIfNonMatchに設定し、広告、中国国内ドメイン、プライベートIP、中国国内IPのルールを1つずつ追加します。完全なコア設定JSONを単一ルールのドメイン入力欄に貼り付けないでください。 -
出力先との対応を確認
各ルールで使用するプロキシ、直接接続、遮断の出力先を確認します。画面上では日本語などの表示名になっていても、生成される設定の
outboundTagが実際の出力先定義に対応している必要があります。また、デフォルトの出力先が選択中のノードになっていることも確認してください。 -
有効化して再読み込み
保存後、新しいプロファイルを有効なルーティングとして選び、サービスを再起動するかコアを再起動してください。プロファイルを保存しただけで有効化していない場合、以前の振り分け設定が引き続き使われることがあります。
-
プロキシの入口を確認
「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。この記事ではテスト用に
127.0.0.1:10808を例として使いますが、実際のポートとインバウンドプロトコルは現在の設定に従ってください。そのうえで、タスクトレイのメニューからシステムプロキシの状態を確認します。
6. ログでルールの問題とDNSの問題を切り分ける
テストでは、一度に変更する条件を1つに絞ります。まず中国国内リストに含まれることを確認したドメインにアクセスし、次にリストに含まれないドメイン、最後にアクセスしたいプライベートIPを試します。一時的にアクセスログを有効にし、必要に応じてエラーログの詳細度を上げて、宛先と最終的な出力タグを確認してください。検証が終わったら、普段使うログレベルに戻します。
確認の手順：まずルールの一致を確認し、次に名前解決を調べる
ドメインルールの確認
- 中国国内リストに含まれるドメインでは、出力先に
directが表示されるはずです。 - 広告リストに含まれるテスト用ドメインでは、
blockが表示されるはずです。 - ログにIPアドレスしか表示されない場合は、アプリ側でドメインがすでに名前解決されていないか確認してください。
- 既存の接続が再利用されないよう、接続を閉じてからリクエストをやり直してください。
IPルールとデフォルト出力先の確認
- プライベートIP宛ての通信が
directで処理されることを確認します。 - ドメインリストに一致しない場合の名前解決結果を確認します。
- 中国国内IPの追加ルールに一致した通信は、
directへ送られるはずです。 - それ以外の通信が、誤って直接接続されず、先頭のプロキシ出力先を使うことを確認します。
ルールが適用されたかどうかは、ウェブページを開けるかよりログに表示される出力先のほうが確実に分かります。実際の接続可否はDNS、ノード、接続先サービスにも左右されます。
アプリがドメインを先にIPアドレスへ名前解決し、そのIPをローカルプロキシに渡すと、geositeでは元のドメインを直接取得できません。インバウンドのスニッフィングで一部のHTTPやTLS通信から判別可能なドメイン情報を復元できる場合がありますが、すべてのプロトコルや暗号化方式に対応するとは限りません。有効にする前に、現在のコアのスニッフィング設定を確認してください。DNS設定の代わりとして使うものではありません。
- コアの起動時にエラーが出る：まずJSONの構文、出力タグ、地理データに必要なカテゴリがあるかを確認してください。この段階では通信速度の問題ではありません。
- 中国国内のサイトがプロキシ経由になる：ドメインがリストに含まれているか、インバウンドでドメイン名が保持されているか、より前にプロキシルールがないかを確認してください。
- 海外サイトが意図せず直接接続される：
geoip:cnに一致していないか確認し、必要に応じて優先度の高いドメイン指定のプロキシ例外を追加してください。 - 変更しても何も変わらない：有効なルーティングプロファイル、コアの再読み込み状態、アプリのプロキシ入口を確認してから、既存の接続やアプリのキャッシュを調べてください。
DNS設定も別途設計する必要があります。ルーティング判定用の名前解決リクエストが、自動的にプロキシ経由になるとは限りません。名前解決結果に問題がある場合は、まずコアが使用するDNSサーバーと接続経路を確認し、そのうえで中国国内IPの追加ルールを残すか判断してください。トラブルシューティング用のログを共有する際は、サブスクリプションURL、認証情報、個人のアクセス履歴を削除してください。