この記事は、サブスクリプションを追加してノードに接続できたものの、日本国内のサイトやLAN内の通信をどのように直接接続するか迷っている方向けです。v2rayNで管理するXrayコアを例に、ルールの順序、ドメインとIPの照合、デフォルトのアウトバウンド、動作確認の方法を解説します。読み終えると、元に戻せる中国本土向け通信の直通ルールを設定し、「ルールに一致しない」場合と「リクエストがクライアントに届いていない」場合を見分けられます。
1. 通信の入口・ルーティングルール・アウトバウンドを区別する
システムプロキシ、TUN、ルーティング設定は、それぞれ別の機能です。システムプロキシは、その設定に従うアプリにローカルプロキシへリクエストを渡すよう指示します。TUNはシステムルートの範囲内の通信を取り込みます。コアのルーティングルールは、受け取ったリクエストをどのアウトバウンドに渡すかを決定します。リクエストがコアに届いていない場合、geositeのリストを変更しても効果はありません。
この記事では、proxyをプロキシ用アウトバウンドのタグ、directを直接接続用タグ、blockを遮断用タグとして扱います。タグは設定内で付ける名前であり、記述するだけで対応する機能が追加されるわけではありません。生成される設定に同じ名前のoutbounds[].tagが必要です。存在しない場合、設定の読み込みやアウトバウンドの参照に失敗することがあります。
直接接続とプロキシ
- direct
- 通常はfreedomアウトバウンドに対応
- proxy
- 現在選択中のプロキシノードまたはプロキシ出口に対応
- 対象
- LAN内や中国本土向けの通信は直接接続し、それ以外はデフォルトの出口へ
VMessとVLESSはノード接続用のプロトコルであり、geositeの分類名ではありません。
遮断とデフォルトの出口
- block
- 通常はblackholeアウトバウンドに対応
- どのルールにも一致しない場合
- Xrayはoutbounds配列の先頭にあるアウトバウンドを使用
- 確認する箇所
- 実際に動作している設定のroutingとoutbounds
デフォルトの出口はタグ名では決まりません。アウトバウンドの並び順を確認してください。
2. geositeとgeoipの記述場所
geosite:cnはルールのdomain配列に記述し、ドメインデータベースのcn分類に一致するものを指定します。geoip:cnはip配列に記述し、IPデータベースのcnアドレス範囲に一致するものを指定します。どちらもオンライン検索サービスではなく、中国本土向けのすべての通信を自動で正確に振り分けられるわけではありません。
| 記述例 | 設定するフィールド | 照合対象 |
|---|---|---|
geosite:cn | domain | ドメイン一覧のcn分類 |
geoip:cn | ip | IPアドレス一覧のcn分類 |
domain:example.com | domain | example.comとそのサブドメイン |
full:example.com | domain | example.comとの完全一致のみ |
192.168.0.0/16 | ip | 指定したIPv4ネットワーク |
Xrayのドメインルールでexample.comとだけ記述した場合、キーワード照合となり、「そのドメインとサブドメイン」を指定することにはなりません。特定のサービスに例外を設定する場合は、意図しない部分一致を避けるため、domain:またはfull:を明示してください。
3. ルールは上から順に照合。個別の例外を先に設定
Xrayはルーティングルールを順番に確認し、最初に条件を満たしたルールでアウトバウンドを決定します。ルールの精度を比較して自動的に優先順位を付ける仕組みではありません。広範囲に一致するルールを先に置くと、後ろにある細かなルールは適用されないことがあります。
- サービスごとの例外：プロキシまたは直接接続を強制する特定のドメインは、一般的な分類ルールより前に置きます。
- 任意のブロック設定：サービスに影響しないと確認できた広告ドメイン分類は、blockに振り分けられます。誤ってブロックされた場合は、まずこのルールを削除して確認してください。
- LAN内の直接接続：プライベートドメインとプライベートアドレスに一致させ、ルーターやプリンターなどへのリクエストが外部に送信されないようにします。
- 中国本土向け通信の直接接続：まずgeositeでドメインを照合し、次にgeoipでIP宛ての通信を補います。
- その他の通信：確認済みのデフォルトプロキシに渡すか、選択したポリシーに従って処理します。
1つのルールで複数の異なるフィールドを指定すると、通常はすべての条件を満たす必要があります。たとえばdomainとipを同時に指定しても、「ドメインが中国本土のもの、またはIPが中国本土のもの」という意味にはなりません。このような「または」の条件で振り分けるには、ドメイン用とIP用にルールを分け、どちらも同じdirectに指定してください。
{
"type": "field",
"domain": ["full:example.com"],
"outboundTag": "proxy"
}これは記述方法を示すための特定ドメインの例外であり、例に挙げたドメインにプロキシが必要という意味ではありません。実際に使う際は、対象のサービスで必要なドメインに置き換え、該当する可能性のある汎用ルールより前に配置してください。ログイン、静的ファイル、APIなどのドメインが別にある場合は、ログを見ながら個別に確認します。ブラウザーのアドレスバーに表示されるホスト名だけを設定しても不十分です。
4. 中国本土向け通信を直接接続するXrayルーティング設定
以下はroutingオブジェクトのみの例であり、単独で起動できる完全なクライアント設定ではありません。proxy、direct、blockの3つのアウトバウンドがすでに存在し、outboundsの先頭がproxyであることを前提としています。IPIfNonMatchによる追加の名前解決を可能にするため、ここでは全通信に一致するフォールバックルールを追加していません。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["geosite:private"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
}IPIfNonMatchは、接続先がドメイン名で、最初のルール照合で一致しなかった場合にドメイン名を解決し、そのIPアドレスでもう一度照合する設定です。IPアドレスを直接指定した接続は、最初からIPルールの照合対象になります。ドメイン名がgeositeルールに一致した場合は、後続のgeoipルールのために追加で名前解決することはありません。
この設定は「中国本土向けのドメインは必ず直接接続できる」と保証するものではありません。ドメイン分類に不足がある場合や、CDNの振り分けによって解決結果が変わる場合があります。安定性が重要なサービスは、まず明示的なドメインルールを追加し、geoipは補助として利用してください。広告分類は任意です。初めて設定する際は最初のルールを外し、基本の振り分けが正常に動作することを確認してから有効にしてください。
5. v2rayNで保存・有効化し、動作を確認する
現在のノードでXrayが使用されていることを確認してください。この記事のroutingフィールドは、ほかのコアの設定形式としてそのまま使うことはできません。v2rayNはデスクトップ版によって画面の項目名が多少異なります。以下では日本語UIの「設定」→「ルーティング設定」に相当する項目を探してください。ルール画面では、ルーティング設定の一覧と、各設定内にあるルール一覧を区別します。
- 復元用の設定を残す：「設定」→「ルーティング設定」で、現在有効な設定を記録します。複製できる場合は、先に複製してから編集してください。使用可能な唯一のルールセットを直接上書きしないようにしましょう。
- 設定を新規作成または編集：上記の順序でドメインルールとIPルールを追加し、アウトバウンドにdirect、proxy、blockのいずれかを指定します。画面上の各入力欄では、そのウィンドウの案内に従ってください。routingオブジェクト全体を「ドメイン」欄に貼り付けないでください。
- ドメインの名前解決方針を設定：ルーティング設定のドメイン解決方針でIPIfNonMatchを選択します。保存後、メイン画面に戻り、編集した設定に切り替えてください。保存しただけで有効化していない場合、動作は変わりません。
- 通信の入口を確認：「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。以下では10808を例にしますが、実際の値は画面で確認してください。システムプロキシをテストする場合は、メイン画面のシステムプロキシメニューから「システムプロキシを自動設定」を選択します。
- 実行結果を確認：設定を適用してコアを再起動し、リソースの読み込み、ルールの解析、アウトバウンドタグに関するエラーがログにないか確認します。クライアントの設定表示機能または実行中の設定ファイルで、実際に生成されたroutingとoutboundsを確認してください。
クライアントが自動生成する一時設定を直接編集し、恒久的な設定として使わないでください。ノードの切り替え、サブスクリプションの更新、再起動でファイルが再生成される場合があります。ルールはルーティング設定に保存してください。カスタム設定を使う場合は、通信の入口、DNS、アウトバウンド、ルーティングをまとめて管理します。
curl --proxy socks5h://127.0.0.1:10808 --head https://example.com
curl --proxy socks5://127.0.0.1:10808 --head https://example.com以下のコマンドは、「ドメイン名をプロキシ側で処理する場合」と「ローカルで先に名前解決する場合」の違いを確認するためのもので、速度測定ではありません。socks5hでは接続先のドメイン名をプロキシ側に渡します。socks5では通常、ローカルで先に名前解決してから、IPアドレスをプロキシに渡します。指定したポートがSOCKSリクエストを受け付けることと、コマンドライン環境でcurlを利用できることを確認してください。接続問題を隠すために-kで証明書検証をスキップしないでください。
| 確認対象 | 期待される結果 | 記録する内容 |
|---|---|---|
| cn分類に含まれることを確認済みのドメイン | direct | 接続先ドメイン、時刻、アウトバウンドタグ |
| 192.168.1.1などのLAN内アドレス | direct | 接続先アドレスの実在性、サービスポート |
| 直接接続ルールにもブロックルールにも一致しない接続先 | デフォルトのproxy | 先頭のアウトバウンドとログ上の実際の出口 |
| 広告分類に含まれることを確認済みのドメイン | block | 分類が存在するか、サービスに影響するか |
ログの表示内容はコアやログレベルによって異なり、「何番目のルールに一致したか」が直接表示されるとは限りません。接続ログの接続先とアウトバウンドタグを照合してください。必要に応じて一時的にログレベルを上げ、1回再現したら元に戻します。テスト結果には接続先の種類とアウトバウンドのみを記録し、サブスクリプションのURL、ノードの認証情報、個人的なアクセス履歴の全体は公開しないでください。
6. DNS・通信の識別・TUNによる振り分けの範囲
domainStrategyは、ルーティング判定時に接続先のドメイン名を解決するかどうかを決めるもので、DNS全般の設定を済ませるものではありません。クライアントのDNS設定、システムDNS、ブラウザーのセキュアDNS、アプリがIPアドレスを直接送信するかどうかによって、コアが受け取る接続先情報は変わります。geositeを追加しただけで、すべての接続でドメイン名を照合できるとは限りません。
- IPアドレスだけのリクエスト：geositeではIPアドレスを直接照合できません。geoipを使うか、必要性を確認したうえで通信の識別を設定し、コアがプロトコルデータからドメイン名を特定できるか試してください。
- 通信の識別：すべてのプロトコルからドメイン名を特定できるわけではありません。識別した情報をルーティングに使いながら接続先は変更しない場合は、Xrayの
routeOnly設定を検討し、クライアントが生成する設定も確認してください。 - DNSのタイムアウト：IPIfNonMatchによる追加の判定では、名前解決を待つ場合があります。初回の接続に時間がかかる場合は、DNSの問い合わせ時間とノードのハンドシェイクにかかる時間を分けて確認してください。
- TUNによる通信の取り込み：TUNは取り込む通信の範囲を広げますが、誤ったルール順を修正したり、geositeデータベースにない分類を自動で補ったりすることはありません。
- LAN内通信の除外：システムプロキシの除外リスト、TUNのルート除外、コアのdirectルールは、それぞれ異なる層で動作します。リクエストがコアに届く前に除外されている場合、ログに表示されないのは正常です。
振り分け設定を変更する際は、一度に変更する箇所を1つにします。まず明示的なプロキシコマンドでルーティングを確認し、次にシステムプロキシをテストし、必要に応じて最後にTUNを確認します。DNS、ルール、通信の取り込み方法を同時に変更すると、何が問題を解決したのか判断できなくなるためです。TUNの設定手順は入門ガイドのTUN設定を参照してください。
7. ルーティングが機能しないときによくある4つの質問
中国本土向け通信を直接接続する設定なのに、なぜ中国本土のサイトがプロキシ経由になる？
保存済みの設定を見るだけでなく、現在有効なルーティング設定を確認してください。次に、対象のドメインがgeosite:cnに含まれるか、先に強制プロキシのルールがないかを調べます。一時的に修正する場合は、そのサービスのdomain:ルールを汎用ルールより前に置き、接続ログでアウトバウンドがdirectに変わったことを確認してください。
geoip:cnを設定したのに、なぜ一致しない？
domain配列ではなくip配列に記述されていることを確認してください。接続先がドメイン名で指定されている場合は、domainStrategyを確認します。IPIfNonMatchを使う場合は、すべてのリクエストに先に一致するフォールバックルールを削除するか、名前解決方針を見直してください。最後に、実際に解決されたIPアドレスが現在のデータベースのcn範囲に含まれているか確認します。
広告ブロックを追加したら、ログインや決済ページが開かなくなった場合は？
まずcategory-ads-allのルールを無効にして再試行し、誤ってブロックされているか確認してください。ブロックを残す必要がある場合は、失敗したリクエストの実際のドメインを調べ、より前にdirectまたはproxyの例外を追加します。サービスに関連するすべてのアドレスを、広範囲に一致するキーワードの許可リストへ安易に追加しないでください。
サブスクリプションを更新すると、以前設定したルールも変更される？
通常、サーバーのサブスクリプション更新で変更されるのはノード情報であり、ローカルのルーティングルールや地理データが更新されるわけではありません。まず現在のルーティング設定と、使用中のコアが切り替わっていないか確認してください。カスタム設定や別の設定インポート手順を使っている場合は、上書きされる範囲を個別に確認します。分類データの不足を解消しようとして、サブスクリプションを何度も更新しないでください。
ルーティングの安定性はルールの数ではなく、テストした各リクエストの出口を説明できるかで判断します。使用できる設定を1つ保存し、変更箇所と確認対象を記録してください。問題が発生したら直近の変更を戻し、通信の入口、接続先情報、ルールの順序、アウトバウンドを確認します。基本操作はルーティング設定ガイドを、接続エラーはトラブル診断を参照してください。