この記事の概要

ノードのインポートが済み、プロキシ経由でWebページを表示できるものの、直結とプロキシを使い分けたい方に向けた内容です。中国本土向けルールを基準に、サイトごとの例外設定と広告ブロックを追加し、最後に出力先タグを確認します。コード例はXrayのルーティング構文です。クライアント画面ではルールを項目ごとに入力してください。JSON全体をドメイン入力欄に貼り付けることはできません。

1. システムプロキシとルーティングの違い

システムプロキシは「アプリの通信をv2rayNに渡すか」を制御し、ルーティングは「コアが受け取った通信をどの出力先に送るか」を決めます。「システムプロキシを自動設定」を有効にしても、すべての通信がリモートノード経由になるわけではありません。directに一致した通信は、引き続き端末から直接送信されます。反対に、システムプロキシを参照しないアプリは、ルーティングモードを切り替えただけでは自動的にコアを経由しません。

アプリからのリクエスト ローカルの受信 ルール照合 出力先の選択 接続先

まず「設定」→「パラメーター設定」でローカルの待ち受けポートを確認し、メイン画面下部でシステムプロキシとルーティングの設定を確認します。以下のポート番号は説明用の例で、各バージョンの初期値とは限りません。実際の端末で別のポートが表示されている場合は、コマンド内の番号も合わせて変更してください。テスト中はTUNを無効にし、接続経路が二重になって判定を誤らないようにします。

10808
SOCKS受信ポートの例
10809
HTTP受信ポートの例
3種類
直結・プロキシ・ブロックの出力先

2. 中国本土向けルールを基準に設定する

メイン画面のルーティング選択で、「中国本土を迂回」などの名称が含まれるプリセットを有効にします。バージョンやインポートしたルールによって表示名は異なる場合があります。名前だけで判断せず、「設定」→「ルーティング設定」を開いて実際の内容を確認してください。現在のルーティング設定をバックアップしてからテスト用のコピーを作成し、元のプリセットは切り戻し用に残しておきます。

  1. 接続できることを確認済みのノードを選び、テスト中は変更しないでください。
  2. 「設定」→「ルーティング設定」を開き、中国本土のドメイン、中国本土のIPアドレス、LAN向けの直結ルールが含まれているか確認します。
  3. プロキシへのフォールバックを確認します。先行ルールに一致しないTCP・UDP通信は、プロキシ出力先に送られる必要があります。
  4. 設定を保存してテスト用のルーティングに切り替え、コアを再読み込みします。ログに設定の読み込みエラーがないことを確認してからテストしてください。

直結ルールの基本構成

ドメインの集合
geosite:cn
IPアドレスの集合
geoip:cn
LAN内のIPアドレス
geoip:private
出力先タグ
direct

各集合が使えるかどうかは、現在読み込まれているgeosite.datとgeoip.datに依存します。

プロキシのフォールバック設定

ネットワークの種類
tcp,udp
出力先タグ
proxy
ルールの位置
すべての例外ルールの後
プロキシノード
現在選択中のサーバー

タグは実際の出力先と一致させてください。タグを入力しただけでは、プロキシサーバーは作成されません。

direct、proxy、blockはこの記事で使うタグ名であり、コアが自動認識する予約語ではありません。一般的な設定では、それぞれ直結、ノード経由、通信のブロックに対応します。実際に生成される設定で別のタグが使われている場合は、ルール側も合わせて変更してください。特にブロックルールでは、対応するblackhole出力先が必要です。blockという名前のルールを追加するだけでは機能しません。

3. direct・proxy・blockのルール順

Xrayはルールを上から順に照合し、最初に一致したルールの出力先を選びます。より精密な次のルールを探し続けることはありません。特定サイトをプロキシ経由にするルールを中国本土のIP直結ルールより後に置くと、名前解決後にIPルールが先に一致して機能しない場合があります。明示的なドメイン例外を広範な集合より前に置き、フォールバックルールは常に最後に配置するのが確実です。

順序照合対象出力先目的
1指定したサービスのドメイン例外directまたはproxy後続の共通ルールより優先
2広告ドメインの集合block一致した広告通信をブロック
3中国本土のドメイン集合directドメインを優先して直結判定
4LAN内・中国本土のIPアドレスdirectIPアドレス宛ての通信と名前解決結果を処理
5その他のTCP・UDP通信proxy海外・不明な接続先のフォールバック先

以下はネイティブなXray設定におけるrouting部分の例で、単独で起動できる完全な設定ではありません。3つの出力先タグがすでに設定され、参照する集合がデータファイルに含まれていることを前提としています。v2rayNのGUIでは、各要素を対応するルール項目に変換して入力してください。完全なカスタム設定を使う場合に限り、トップレベルの設定へ統合します。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

4. サイトの直結例外と広告ブロックの設定

ルールを追加する前に、完全一致のドメインとサブドメインを含むドメイン指定を使い分けましょう。トップページのホスト名だけを直結させる場合はfull:を使います。同じドメインとサブドメインをまとめて処理する場合はdomain:を指定します。ページはログイン、画像、APIなど複数のホストに接続することがあります。「トップページは開くがログインできない」場合は、通信全体を直結に変える前に、リクエスト先のドメインを確認してください。

たとえば、Tencent関連のドメインを明示的に直結させる場合は、共通の集合より前に次のルールを追加します。このルールは照合範囲の例であり、すべてのユーザーに追加が必要なわけではありません。既存の集合でカバーできている場合、ルールを重複させるとメンテナンスの手間が増えるだけです。

{
  "type": "field",
  "domain": ["domain:qq.com"],
  "outboundTag": "direct"
}

広告のブロックにはgeosite:category-ads-allを使用できます。ただし、コアを経由し、かつ集合に一致する通信だけが対象です。Webページの要素を非表示にするフィルターとは異なり、広告枠の余白は取り除けません。データファイルにこの集合がない場合、コアの読み込みに失敗することがあります。まずログとデータファイルの入手元を確認し、データを更新するかルールを削除するか判断してください。

誤ってブロックした場合は、まず個別の例外を追加

広告ブロックを有効にした後、決済やログインに問題が起きた場合は、まず失敗するホストを特定します。該当するdirectまたはproxyの例外をfull:で追加し、広告ルールより前に配置してください。すぐに親ドメイン全体を許可するのではなく、対象範囲を広げる前に一連の操作が正常に完了するか確認します。

5. リクエストとログで出力先を確認する

「Webページが開いた」だけでは、利用可能な経路があることしか分からず、ルールが正しく動作した証拠にはなりません。検証ではリクエスト先、実際に使用した接続ポート、ログに記録された出力先タグを合わせて確認します。クライアントの速度テストは通常ノードの接続確認に使うもので、ブラウザーの通信が意図した経路で振り分けられたことを示すものではありません。

  1. ルーティング設定を保存してコアを再読み込みし、設定エラーがないことを確認します。必要であれば「設定」→「パラメーター設定」で、一時的にログの詳細度を上げてください。
  2. プロキシを明示したコマンドで接続先にアクセスし、ブラウザーのキャッシュ、バックグラウンド通信、プロキシ拡張機能の影響を避けます。
  3. 中国本土のドメイン、プロキシのフォールバック対象ドメイン、現在の広告集合に含まれていることを確認したテスト用ドメインを、それぞれ試します。
  4. リクエスト時刻をもとにコアのアクセスログを確認し、出力先タグを調べます。現在のログレベルでアクセス記録が出力されない場合は、テスト前にログ設定を変更してください。
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 -I https://www.qq.com/
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 -I https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

Windowsのターミナルでcurlが別のコマンドとして解釈される場合は、curl.exeを使ってください。HTTPプロキシ経由でHTTPSに接続すると、通常はCONNECTで接続先ホストを指定します。socks5hもドメイン名をプロキシ側で処理します。これによりドメインルールをテストしやすくなり、端末側で先に名前解決されてテスト対象が変わるのを防げます。コマンドの応答が403や405でも、必ずしも接続失敗とは限りません。接続先の応答と出力先のログを合わせて判断してください。

テスト対象想定されるタグ問題がある場合の確認箇所
www.qq.comdirectドメイン集合、先行するプロキシルール
example.comproxyこの記事の例にある完全一致ドメインのルールとプロキシ出力先
広告集合に含まれることを確認済みのホストblock集合の内容、許可リスト、ルールの順序

上の表は設定上の想定であり、このサイトで測定した通信性能の結果ではありません。ブラウザーが既存の接続を再利用すると、ルール変更後も新しい結果がすぐに表示されない場合があります。既存の接続を閉じるか、新しいコマンドでリクエストしてください。テスト後は通常のログレベルに戻し、アクセス先を含む詳細ログが長期間蓄積されないようにします。

6. DNS・IPルール・よくある振り分けの問題

ルーティングの判定とDNSの名前解決は関連しますが、同じ設定ではありません。domainStrategyはルーティング照合時にドメインをいつ名前解決するかを制御します。DNSサーバーを直接指定するものでも、DNSリクエストがプロキシ経由になることを保証するものでもありません。特にIPによるオンデマンド照合を有効にした場合、誤った名前解決結果によって、本来プロキシ経由にすべきドメインが中国本土のIP直結ルールに一致する可能性があります。

中国本土向けルールを選んだのに、国内サイトがプロキシ経由になるのはなぜ?

まずログで接続先がドメイン名かIPアドレスかを確認し、「設定」→「ルーティング設定」でgeosite:cnが存在するか、先行するプロキシルールに上書きされていないかを調べます。IPアドレスしか渡されていない場合、ドメインルールでは直接照合できません。IPルールとアプリの接続方法を確認してください。

geoip:cnを追加してもドメインに適用されないのはなぜ?

domainStrategyを確認してください。AsIsではルーティングのための名前解決は行われません。IPIfNonMatchの場合も、先行ルールや末尾の共通フォールバックがすでに一致している可能性があります。IPアドレスで判定する必要がある場合はIPOnDemandを検討し、DNSの名前解決が正常かどうかも確認してください。

広告ルールを追加したら、コアが起動しなくなった場合は?

ログに集合が見つからない、または出力先タグが存在しないというエラーがないか確認します。まず追加したルールを取り消して接続を復旧し、現在のgeosite.datにcategory-ads-allが含まれているか、blockが実際のブロック出力先に対応しているかを調べてください。

ブラウザーは正常なのに、ほかのアプリがルールどおりに通信しないのはなぜ?

まず127.0.0.1:10809を指定したコマンドで比較します。コマンドが正常ならルーティング経路は機能しています。次に、そのアプリがシステムプロキシに対応しているか確認するか、アプリ内でSOCKSを設定してください。アプリを接続するためにルールの順序を何度も変更する必要はありません。

7. ルールの保存とメンテナンス

サブスクリプションのノードとルーティング設定は役割が異なります。ノードはリモート接続のパラメーターを提供し、ルーティングはどの通信にそのパラメーターを使うかを決めます。サブスクリプションを更新してもgeositeやgeoipのデータは更新されず、ルール順の問題が解決するわけでもありません。コアを変更した後は、以前の設定がそのまま使えると決めつけず、ルール構文、データファイル、出力先タグを改めて確認してください。

最終的には、根拠を追える判定の流れを作ることが重要です。アプリの通信がクライアントに届き、ルール順が想定どおりで、接続先に明確なタグが一致し、その出力先で接続できることを確認します。この4点を設定とログで確認できれば、ルーティングの誤り、DNSの問題、ノード自体の不具合を切り分けられます。