01 ・交通の出入り

システム プロキシ設定は、参加しているアプリケーションをローカル コアに誘導します。すべてのアプリにその使用を強制するものではありません。トラフィックが到着すると、ルーティングによってダイレクト、プロキシ、ブロック、または別のアウトバウンドが選択されます。

自動システム プロキシは、選択した宛先をバイパスするルールと共存できます。ルーティングの変更は、トラフィックをコアに送信しないアプリケーションには影響しません。

  1. アプリ
  2. システム / 手動プロキシ / TUN
  3. コアルーティング
  4. ダイレクト / プロキシ / ブロック

02・4つのシステムプロキシモード

これらのモードは、サービスの開始時または再起動時のシステム設定を制御します。別のアプリケーションでもそれらの設定を管理しているかどうかを確認してください。

モード動作一般的な使用方法
システム プロキシをクリアしますプロキシ設定を削除する通常のネットワークに戻る
自動システムプロキシローカル クライアント リスナーをポイントしますシステム設定を使用するブラウザとアプリ
変更しないでください既存の設定を保持する手動で設定されたアプリまたは別のマネージャー
PAC (Windows)スクリプトは直接またはプロキシを選択しますコアルーティング前の宛先決定

03 · 日常のワークフロー

作業プロファイルをインポートしてアクティブ化し、コアの起動を確認し、自動システム プロキシを有効にして、適切な既存のルーティング プリセットを選択します。ブラウザーリクエストを作成し、ログ内のターゲット/アウトバウンドを検査します。

手動プロキシ設定を持つ単一アプリの場合は、127.0.0.1 で HTTP または SOCKS5 と、クライアントの実際の混合リスニング ポートを使用します。これはリモートサーバーのポートではありません。

ローカルポート参照

04 · PAC と自動モード

自動モードでは、アプリのリクエストがルーティングのためにコアに送信されます。 PAC は最初にアプリケーション側のスクリプトを実行します。DIRECT はコアをバイパスしますが、プロキシされたリクエストは引き続きコア ルーティングを通過します。

Windows では、ストレージ内の pac.txt に FindProxyForURL などの JavaScript が含まれています。編集する前にバックアップし、有効な構文を保持してください。アプリがスクリプトをキャッシュする可能性があるため、変更後に設定を再適用してください。 PAC は、それをサポートするアプリケーションにのみ影響します。

05 · プリセットとカスタムルーティング

生成されたルーティング プリセットから始めます。ルールは順番に評価されます。特定のドメイン/IP ルールはキャッチオールの前に属します。ターゲットのルールを追加し、編集したルール セットをアクティブ化します。

グローバル ルーティング プリセットは、コア内部にすでにあるトラフィックを制御します。システム プロキシを無視するアプリケーションにコアの使用を強制することはできません。

ルーティング ルールの書き込み

06 · ネットワークを終了して復元する

不要になった場合は、終了する前にシステム プロキシをクリアを選択してください。シャットダウン、強制終了、クラッシュにより設定が残る可能性があります。

クライアントが停止し、参照が失敗した場合は、プロキシがまだ 127.0.0.1 を指しているかどうかを確認してください。クライアントを再度開いてクリアするか、OS のネットワーク設定から古い設定を削除してから、通常の接続をテストします。

07 · ルールは順序付けられた JSON 配列です

各オブジェクトはルールです。有効にするとそれが切り替わり、コメントにラベルが付けられ、outboundTag で既存のアウトバウンドが選択されます。クライアント エディターのスキーマは、ネイティブのコア構成と同一ではありません。開始点としてクライアント ルールをエクスポートします。

保存後、ルール セットをアクティブ化し、プロファイルを再適用します。評価は最初に一致したルールで停止します。

08 · 共通の一致フィールド

条件内の複数の値は通常、代替手段を提供します。さまざまな条件が相互に制約します。 v2rayN は、結合時にドメイン、IP、およびプロセス フィールドを分割するため、ルールごとにこれらのいずれかを使用します。

フィールド構文と効果
domain配列: full:example.com 正確; Domain:example.com にはサブドメインが含まれます。正規表現: 正規表現;ジオサイト: カテゴリ
ipIP、CIDR または geoip: カテゴリ; geoip:private はプライベート範囲と一致します
port宛先ポートまたは範囲、例: 443 または 1000-2000
sourcePort / source送信元ポート/IP 制約、コア サポートの対象
networktcp、udp、またはその両方
protocolhttp、tls、bittorrent などのスニッフィングされたアプリケーション プロトコル。匂いを嗅ぐ必要がある
inboundTagリクエストを受信した受信と一致します
outboundTagダイレクト、プロキシ、ブロック、または既存のカスタム タグ
enabled / remarksクライアント有効化フラグ/ラベル

09 · 正確なルールから始める

この例では、example.com とそのサブドメインを直接送信し、その他すべてをプロキシ経由で送信します。キャッチオールは最後に属します。既存のルール セットでは、既存のキャッチオールの前に特定のルールを追加します。

JSON · クライアント ルーティング ルールコピー
[
  {
    "remarks": "Example domain direct",
    "domain": [
      "domain:example.com"
    ],
    "outboundTag": "direct",
    "enabled": true
  },
  {
    "remarks": "Fallback proxy",
    "port": "0-65535",
    "outboundTag": "proxy",
    "enabled": true
  }
]

10 ・共通ルールの組み合わせ

プライベート IP 範囲とプライベート ドメインに直接ルールを使用して、一致する GEO データがインストールされたローカル リソースにアクセスできるようにします。 network=udp、port=443、outboundTag=block のルールは UDP 443 をブロックし、QUIC/HTTP/3 に影響を与える可能性があります。これはユニバーサル接続の修正ではありません。

ドメイン ルールにはドメイン情報が必要です。 IP に直接接続しているアプリは、それらと一致しない可能性があります。スニッフィング、DNS モード、およびアプリケーション管理の暗号化 DNS は、コアが認識できる内容に影響します。

11 · ドメイン解決戦略

Xray AsIs はルーティング中にドメインを維持します。 IPIfNonMatch は、ドメインの一致が失敗した後に解決されます。 IPOnDemand は、IP ベースのルールで必要な場合に解決されます。このルーティング ポリシーは、実際の送信 DNS 解決とは別のものです。

ドメイン ルールを意図的に配置し、広範な IP ルールが意図せずに優先されることを避けます。

DNS 設定

12 · インポート、検証、元に戻す

ファイル、クリップボード、またはサブスクリプション URL からルールをインポートします。古いセットを保持し、コメントや末尾のカンマのない有効な JSON を使用し、送信タグとデータ カテゴリを検証し、広すぎる最初のルールを避けます。

新しい接続で特定の宛先をテストし、選択した送信を検査します。既存の長期間存続する接続は古いパスを保持する場合があります。必要に応じてターゲット アプリを再起動します。失敗した場合は、以前のルールセットに戻ります。

ソース公式ドキュメント

手順とパラメータはこのページに記載されています。参照によりソースが特定されます。 2026 年 10 月 19 日にレビュー済み。