最初に意図した結果を定義してください

保守可能なルーティング設定により、各トラフィック クラスに明確な宛先が与えられ、決定が適用されたという証拠が生成されます。検証可能な例外を 1 つから開始し、徐々にルールセットを拡張していきます。

1. 通信ごとの目的を表にする

内部サービスは直接的なままにし、仕事用 Web サイトは安定したノードを使用し、その他すべてを既存のポリシーを維持したいとします。ターゲット、意図するアウトバウンド、および検証方法から始めます。この説明は、UI やコアが変更された場合でも役立ちます。

通信の分類 期待する処理 収集する証拠
既知のローカル デバイス 直接 到達可能性と予想される接続レコード
固定した出口が必要な業務ドメイン 検証されたノードまたはグループ 新しい接続は指定されたアウトバウンドを使用します
選択したアプリケーション 1 つ 用途に応じてプロキシまたは直接接続 実際のプロセスとその新しいリクエストは一致します
その他すべて 既存のデフォルトを保持します 一致しないサンプルは影響を受けません

これは設計例であり、普遍的な構成ではありません。内部サービスには、特定の企業の VPN が必要な場合があります。プライベート IP アドレスだけでは、物理インターフェイスが正しいパスであることは確立されません。

2. ルールの順番を確認する

公式 v2rayN UI ガイドでは、順序付けされたマッチングについて説明しています。つまり、前のルールが一致すると、後のルールはそのリクエストのアウトバウンドを選択しません。[1] Xray には、対応するルーティング動作が文書化されています。[2] したがって、広範な一致ルールの下に置かれた厳密な例外は無効なままになる可能性があります。

ルールを狭い例外、必要な一般ルール、および最終的なデフォルトとして確認します。ローカル サービス、作業ドメイン、およびブロックされた宛先の相対的な優先順位は、意図によって異なります。広告ルールが常に最初になければならないと想定しないでください。

変更前に動作中のルールセットを複製し、routing-before-test など識別しやすい名前を付けます。一度に追加するルールは一つにし、備考に目的を書きます。元の設定を残すことで、原因の切り分けと元に戻す操作が容易になります。

3. 二つの宛先で例外ルールを検証する

以下は、一つのドメインを直接接続の例外にし、残りをプロキシへ送る例です。v2rayN のカスタムルーティング書き出し形式であり、どのコアにもそのまま渡せる完全な設定ではありません。例示用の example.com を目的の宛先に置き換え、複製したルールセットで試してください。[3]

[
  {
    "remarks": "example-domain-direct",
    "domain": ["domain:example.com"],
    "outboundTag": "direct",
    "enabled": true
  },
  {
    "remarks": "remaining-traffic-proxy",
    "port": "0-65535",
    "outboundTag": "proxy",
    "enabled": true
  }
]

Xray のドメイン指定では、domain:example.com はそのドメインとサブドメインに一致します。一つのホスト名だけに完全一致させたい場合は full: の指定方法を確認してください。[2] 業務用ドメインを厳密に振り分けたい場面で、範囲の広いキーワード一致を代用しないでください。

対象のドメインをリクエストし、ダイレクトアウトバウンドを確認します。次に、そのドメインの外部にある別のテスト宛先を要求し、プロキシが引き続き適用されることを確認します。これらのポジティブ コントロールとネガティブ コントロールは、正しい例外と、すべてを直接送信する偶発的な変更を区別します。

4. プロセス規則とグループの役割を分ける

プロセス ルールは、どのアプリケーションのリクエストが一致するかを特定します。ポリシーグループは、ルーティングがグループを選択した後、プロキシ メンバーを選択します。プロセスの一致に依存する前に、コアが実際にどのようなプロセス情報を参照しているかを確認してください。ブラウザ ヘルパー、ランチャー、アップデータ、およびメインの実行可能ファイルには異なる名前が付いている場合があります。 OS の権限、コア バージョン、キャプチャ方法も可用性に影響します。

v2rayN ルール エディターのドキュメントでは、各ルールにドメイン、IP、またはプロセス名のいずれか 1 つだけを入力することを推奨しています。ポートやネットワーク タイプなどの他のフィールドは、一致をさらに制限します。[1] このエディターの動作は、コアのネイティブ ルールを直接記述することと互換性がありません。何かをインポートする前に、構成レイヤーを特定します。

ルールの出口にグループを指定する場合、対応するメンバーが少なくとも一つ動作することを先に確認します。ログイン状態の維持が重要な業務サービスでは、地域をまたいで出口がランダムに変わる構成より、少数の安定した候補の方が挙動を理解しやすくなります。ルールに一致しても、選ばれたノードでリクエストが成功するとは限りません。

5. DNS とルールを一緒に管理する

ドメインの一致には、コアが対象のホスト名を取得できることが必要です。IP の一致では、コアと名前解決方針によって DNS 参照が行われることがあります。ブラウザーの暗号化 DNS、IP 直接指定、スニッフィング、FakeIP により観察できる情報は変わります。ドメイン規則に一致しないときは、項目を増やす前にコアが何を認識したかを調べます。

ルールセットにはソースとバージョンもあります。インポート URL、更新時間、目的を記録します。リモート ルールセットが変更された後、代表的なテストを再実行します。新しいフィールドまたは形式は、古いコアでは機能しない可能性があります。 Xray JSON、sing-box ルール セットおよび他のクライアントの形式は互換性のあるファイルではありません。

一部のビデオは、QUIC の動作を変更するために UDP ポート 443 をブロックします。これは普遍的な速度向上ではありません。アプリケーションが TCP にフォールバックするか、その動作とパフォーマンスが悪化する可能性があります。実験に関連性がある場合は、それを分離して文書化し、前後を比較します。すべての UDP トラフィックのブランケット ブロックにしないでください。

6. 五つの項目で動作を確認する

  1. 一致させたい通信: 対象のドメインまたはプロセスが新しいルールに一致します。
  2. 一致させたくない通信: 無関係な宛先は以前のポリシーを保持します。
  3. 内部アクセス: ローカル デバイスと必要な内部サービスは引き続き動作します。
  4. 永続性: ルールとグループは、コアの再起動とサブスクリプションの更新後も引き続き使用できます。
  5. ロールバック: 元のルールセットを選択すると、以前に動作していた動作が復元されます。

次回の変更でも使える少数の検証対象を保存してください。一度の高速な動画読み込み、出口 IP の結果、速度のスクリーンショットだけでは、方針全体を検証できません。

ルールは多いほうが良いですか? 必ずしもそうとは限りません。ルールが重複していたり、冗長であったり、古くなったりすると、設定が理解しにくくなります。明確な目的と再現可能なチェックを備えたルールを維持します。

インポートが成功すると互換性が証明されますか? いいえ。コアの起動、生成されたルール、実際のマッチング、出口の到達性を別の手順として確認します。

参考にした YouTube 動画

公開されている動画タイトル・説明・チャプター索引を、テーマ選びと画面操作の参考にしました。本文は独自に作成したガイドで、動画の書き起こしではありません。技術的な内容は以下の公式資料で確認しています。

公式資料と適用範囲

資料確認日:2026-10-26。メニュー名や機能はクライアント、コア、OS のバージョンによって異なります。本文のチェックリストは推奨する検証手順であり、実測済みの性能データではありません。

  1. 公式 v2rayN UI および設定ガイド
  2. 公式 Xray ルーティングとドメイン マッチング
  3. 公式 v2rayN カスタム ルーティング形式

シリーズの関連記事