システムプロキシと TUN：v2rayN の通信経路を検証する

1. 通信の取り込みと出口を区別する

システムプロキシは、対応するアプリにローカルのプロキシポートへリクエストを送るよう指示します。TUN は仮想ネットワークインターフェイスと OS のルートを使って対象の通信を受け取ります。その後、コアのルーティング規則が直接接続・プロキシ経由・遮断を選びます。公式のシステムプロキシ説明も、この二つの段階を区別しています。^[1]

TUN は、すべての接続がリモート プロキシを使用することを意味するわけではありません。同様に、グローバル ルーティング ポリシーは、すべてのアプリケーションがキャプチャされたことを証明するものではありません。エントリーパスとアウトバウンドの決定を個別にテストします。

2. アプリの動作に合わせて選ぶ

Windows、macOS、Linux では、ネットワーク サービス、権限、パッケージの動作が異なります。すべてのプラットフォームで同じ管理コマンドを再利用しないでください。 macOS では、自動構成を有効にした後、実際のネットワーク設定を確認します。公式 FAQ では、一部の環境ではセットアップ スクリプトが失敗する可能性があると記載されています。^[2]

3. 明示的なプロキシ接続を確認する

TUN を無効にし、動作確認済みの単一ノードを選び、クライアントに表示されるローカル混合待受ポートを確認します。以下では 10808 を例にしていますが、設定が異なる場合は置き換えてください。混合ポートは HTTP と SOCKS の両方を受け付けます。ポート番号は変更可能な設定値です。^[3]

Windows PowerShell では curl.exe、macOS と Linux では curl を使います。example.com は置き換え可能な HTTPS テスト用の宛先です。その後、実際に接続できない宛先でも同じテストを行ってください。

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

このコマンドで確認できるのは、明示的にプロキシへ渡したリクエストです。システムプロキシや TUN による通信の取り込みが動作している証明にはなりません。socks5h は宛先ホスト名の名前解決を SOCKS プロキシへ委ねますが、端末上のすべての DNS 問い合わせが同じ経路を使うわけではありません。^[4] 宛先が HEAD リクエストを拒否する場合は -I を外し、ログと合わせて結果を判断します。

4. 三つの経路を比較する

A: 明示的なプロキシ。 TUN を無効にして、上記のコマンドを実行します。失敗した場合は、まずノード、ローカル リスナー、またはコアを調査します。この時点で TUN を有効にすると、別の変数が追加されます。

B: システム プロキシ。 同じノードを維持し、自動システム プロキシ構成を有効にし、テスト用のブラウザ固有のプロキシ オーバーライドを削除します。同じターゲットを開き、コアの接続レコードでリクエストを探します。 A は機能するが B が失敗する場合は、ブラウザ、拡張機能、OS プロキシ設定に注目してください。

C: TUN。 現在の設定を記録し、この分離テストのシステム プロキシをクリアしてから、プラットフォームに必要な権限を使用して TUN を有効にします。明示的なプロキシ設定を行わずに、ターゲット アプリケーションから新しい接続を作成します。これをコアの接続レコードおよびアウトバウンド選択と関連付けます。既存のブラウザ接続は再利用される場合があるため、必要に応じて関連するウィンドウを閉じて再試行してください。

出口 IP の確認ページは補助的な証拠ですが、そのページ自身のリクエストしか説明しません。特定のアプリの通信が取り込まれているかを確かめるには、そのアプリから新しく送ったリクエストとコアの接続記録を対応させます。

5. DNS と内部サービスを個別に確認する

DNS は OS、ブラウザーの暗号化 DNS、アプリ、コア、遠隔のプロキシなどで処理される可能性があります。TUN を有効にしてページが開いても、すべての DNS 問い合わせが同じ経路を使った証明にはなりません。sing-box の TUN 文書にも、OS やコアのバージョンによって異なる動作が記載されています。^[5] ここには、すべての DNS パスがカバーされることを保証する汎用スイッチ シーケンスはありません。

切り替え後、通常の Web サイト、プロキシを必要とするタスク、およびアクセスを許可されているローカル デバイスまたは内部サービスをテストします。内部アクセスのみが失敗した場合は、サブネット、VPN 状態、および一致したルールを記録します。ファイアウォール全体を無効にするのではなく、除外ルールとダイレクト ルーティング ルールを確認します。

厳密なルーティング、FakeIP、またはサードパーティの VPN インタラクションを変更する前に構成を保存し、一度に 1 つの設定を変更します。アップストリーム コア ドキュメントには、クライアントがサポートするコア範囲よりも新しいフィールドが含まれる場合があります。最新の完全な JSON サンプルを古いインストールに貼り付けないでください。

6. 元の状態に戻す手順を用意する

接続が切断された場合は、有効にしたばかりの TUN モードを無効にし、記録されたプロキシと VPN 状態を復元してから、通常のアクセスを再度テストします。変更する前に、どのアプリケーションが元の設定を所有しているかを確認してください。組織が管理するプロキシを無差別にクリアしないでください。

ターゲット アプリケーションのリクエストが目的のパスに入り、ルーティングが目的のアウトバウンドを選択し、内部サービスが引き続き動作し、TUN を無効にすると以前のネットワーク動作が復元される場合にのみセットアップを受け入れます。変更されたアイコンは、これらのチェックの代わりにはなりません。

TUN は常に速いですか? いいえ。トラフィックのキャプチャが変更されます。ノードの品質、コアの動作、ネットワークの状態、ワークロードがパフォーマンスを決定します。

TUN とシステム プロキシを同時に有効にすることはできますか? 一部の構成ではそれが可能です。問題を診断するときにそれらを個別にテストし、組み合わせたセットアップが実際に必要かどうかを判断します。

参考にした YouTube 動画

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

• 科技分享 · v2rayN チュートリアル 2026-04-1605:48 · 06:39
• 科技分享 · v2rayN チュートリアル 2025-09-2807:50

公式資料と適用範囲

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

1. 公式 v2rayN システム プロキシおよびルーティング ガイド
2. 公式 v2rayN FAQ およびログ ガイダンス
3. 公式 v2rayN UI および設定ガイド
4. curl 公式：プロキシと DNS オプション
5. sing-box TUN の公式ドキュメント

シリーズの関連記事

• v2rayN のノード測定とポリシーグループ：安定した接続の選び方
• v2rayN の振り分けルール：ドメイン・プロセス・優先順位
• v2rayN が接続できないとき：ポート・DNS・TLS の切り分け
• v2rayN の更新と環境移行：バックアップ・検証・復元