システムプロキシとTunは、通信をクライアントに取り込む方法です。ルーティングモードは、取り込んだ通信をどの出経路に流すかを決めます。普段のブラウジングではシステムプロキシと中国本土をバイパスするルールを組み合わせ、ルールの動作確認には一時的に全般モードを使います。システムプロキシに従わないアプリでは、Tunの利用を検討してください。この記事ではWindows版v2rayNの操作を例に、ポートの確認、コマンドによるテスト、元の設定に戻す手順を解説します。
システムプロキシとルーティング：入口と出口
システムプロキシを有効にしても、全般モードになるわけではありません。システムプロキシは、OSのプロキシ設定にローカルのプロキシアドレスを書き込み、その設定に従うアプリが利用できるようにします。一方、全般モードは通常、クライアントのルール設定を指し、コアに取り込まれた通信をプロキシ経由で外部へ接続します。この2つは個別に変更できるため、「システムプロキシは有効だが、ルーティングでは直接接続を選択している」という状態もあり得ます。
アクセス時の流れは、アプリがリクエストを送信し、ローカルの受け口が接続を受け取り、ルーティングルールが出経路を選ぶ、という3段階に分けられます。VMessやVLESSなどのプロトコルは、クライアントとリモートサーバー間の接続設定です。ブラウザーがシステムプロキシを自動的に使うようにするものではありません。サブスクリプションの更新に成功しても、アプリの通信がクライアントに取り込まれているとは限りません。
| 設定レイヤー | 解決すること | 単独では保証できないこと |
|---|---|---|
| システムプロキシ | OSの設定に従うアプリをローカルのプロキシポートに接続する | すべてのプロセス、UDP通信、個別に設定されたプロキシを取り込めるとは限らない |
| 全般ルーティング | コアに取り込まれた通信を主にプロキシ経由で外部へ接続する | もともとコアに取り込まれていない通信を自動で取り込むことはできない |
| 中国本土をバイパスするルーティング | ドメイン名やIPアドレスなどのルールで、直接接続とプロキシ接続を振り分ける | 中国本土のサービスが使う海外ドメインを、すべて直接接続にできるとは限らない |
| Tunモード | 仮想ネットワークアダプターとシステムルートを使い、より多くのアプリ通信を取り込む | 出経路の振り分けはなくならず、例外ルートをすべてカバーできるとも限らない |
全般モードと中国本土バイパスの使い分け
普段使いでは、通信の振り分けをおすすめします。中国本土のWebサイト、LAN内のデバイス、社内サービスは通常、直接接続し、それ以外のプロキシが必要な通信をリモートサーバー経由にします。不要な遠回りを避け、ローカルで完結する通信がサーバー側の通信量に含まれるのも防げます。全般モードは、問題の原因がルーティングルールにあるか短時間で確認するときに適しています。
2つのルーティング方式
全般ルーティング
- 特定のドメイン名が誤って直接接続に振り分けられているか調べるのに適しています。
- 取り込まれた通信を一時的にすべてプロキシ経由にしたい場合に適しています。
- ローカルデバイスに接続する前に、プライベートIPアドレスが直接接続の対象として維持されているか確認します。
- 切り替え後に接続をやり直してください。既存の接続はすぐに出経路が変わらないことがあります。
中国本土をバイパスするルーティング
- 中国本土のサービスと他地域のサービスを併用する場合に適しています。
- ドメイン名ルール、IPデータ、実際のルール順に左右されます。
- サービスが海外ドメインや海外CDNを使っていると、プロキシ経由になる場合があります。
- 特定のサイトだけに問題がある場合は、まず対象ドメインのルールを追加してください。
普段は通信を振り分け、問題の切り分け時だけ一時的に全般モードを使います。原因を特定したら元の設定に戻し、あらゆるネットワーク障害の解決策として全般モードを使わないでください。
「中国本土をバイパス」は、Webページの言語やユーザーの所在地で判定する機能ではありません。Xrayのルーティングを例にすると、geosite:cnはドメイン名の分類、geoip:cnはIPアドレスの分類で、対象が異なります。ドメイン名によっては名前解決前にルールに一致します。IPアドレスで判定する通信は、ルーティングの名前解決方法にも左右されます。Webサイトの表示が中国語でも、すべてのリソースのドメイン名が直接接続になるとは限りません。
- ルールの順序：通常は上から順に照合され、最初に一致したルールで出経路が決まります。例外のドメイン名は、それを上書きする広範なルールより前に配置してください。
- 複数のドメインを使うページ：ログイン、画像、APIで異なるドメイン名が使われる場合があります。アドレスバーに表示されたメインのドメイン名だけでなく、それぞれ確認してください。
- デフォルトの出経路：どのルールにも一致しない通信の行き先は、生成されたコア設定によって決まります。モード名だけで判断しないでください。
システムプロキシ：ポートと有効化の手順
まずシステムプロキシで基本の接続を確認してから、Tunを検討してください。メニュー名はWindowsで一般的な画面を基準にしています。デスクトップ版とWPF版、バージョンによって表示名や位置が異なる場合があります。同じ名前、または同じ意味の設定項目を探し、現在のクライアントに表示されている待ち受けポートを確認してください。
上記2つのポートは説明用の設定例であり、すべてのバージョンのデフォルト値を示すものではありません。HTTPとSOCKSを同じポートで受け付ける混合受け口もあれば、別々のポートで待ち受ける設定もあります。ポート番号が同じというだけで、特定のプロトコルに対応していると判断しないでください。
-
有効な設定を確認する
メイン画面で使用するサーバー設定を選び、右クリックメニューから「アクティブサーバーに設定」を選択します。コアの起動を待ち、まずログにポートの競合や設定の解析エラーがないか確認してください。
-
待ち受けポートを確認する
「設定」→「パラメーター設定」を開き、「ローカルリスニングポート」や関連する受け口の設定を探して、プロトコルとポートを確認します。画面に混合ポートが1つだけ表示される場合は、そのポートが実際に対応する機能に合わせてアプリを設定してください。
-
システムプロキシを設定する
メイン画面下部の「システムプロキシ」メニューから「システムプロキシを自動設定」を選択します。画面によっては、タスクトレイのメニューから操作できます。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、設定されたアドレスとポートを確認してください。
-
ルーティングルールを選ぶ
メイン画面下部の「ルーティング」から、中国本土をバイパスするルールを選択します。「設定」→「ルーティング設定」で実際のルールを確認し、プライベートIPアドレス、直接接続するドメイン名、ルールに一致しなかった場合の接続先を確認してください。
-
接続をやり直す
テスト中のページを閉じてから開き直し、必要であればテスト対象のアプリも再起動します。新しい接続のログで接続先と出経路を確認してください。ノードの遅延テストに成功しただけで、ブラウザーの設定も正しいとは判断できません。
Tunモード：利用条件と注意点
システムプロキシを参照しないアプリや、手動で設定できるプロキシ項目がないアプリを使う場合、またはUDP通信を取り込む必要がある場合に、Tunの利用を検討してください。Tunは仮想ネットワークアダプターとルーティングを使ってIP通信を処理するため、通常はシステムプロキシより広い範囲を取り込めます。ただし、「すべての接続がリモートサーバー経由になる」という意味ではありません。Tunに取り込まれた通信も、ルーティングルールに従って振り分けられます。
システムプロキシでの基本設定
- 接続方法
- アプリがシステムプロキシ設定に従う
- 待ち受けアドレス
127.0.0.1- ポートの例
- HTTP
10809。実際の設定を確認してください - ルーティングの選択
- 普段は中国本土をバイパス
ブラウザーなど、システムプロキシに従うアプリに適しています。まずはこの接続経路が機能するか確認してください。
Tunで通信を取り込む設定
- 接続方法
- 仮想ネットワークアダプターとシステムルート
- 必要な権限
- ネットワークアダプターの作成とルート変更に必要な権限がある
- DNSの確認
- 名前解決の通信経路がルーティング設定と一致している
- 除外する対象
- LAN、社内ネットワーク、必要なサービスへの接続
システムプロキシで通信を取り込めないアプリに適しています。有効にした後も、通信の振り分けとネットワークの競合を確認してください。
v2rayNのTun機能では、クライアントで選択したTunの実装と関連コンポーネントも重要です。特定のプロキシプロトコルとTunのスイッチを直接結び付けて考えないでください。VMessやVLESSの設定が使えても、現在のTunコンポーネントが利用可能とは限りません。反対に、仮想ネットワークアダプターを作成できても、リモートサーバーが必要なUDP転送に対応するとは限りません。
- 権限：クライアントの案内に従って必要な権限を付与してください。作成に失敗した場合は、サブスクリプションを何度もインポートせず、まず起動ログを確認します。
- ルーティングの競合：社内ネットワークへの接続、ほかの仮想ネットワークアダプター、重複するプライベートネットワークの範囲によって、通信経路が変わる場合があります。
- DNS：OS、ブラウザー、TunそれぞれにDNS設定がある場合があります。ブラウザー独自の暗号化DNSを使うと名前解決の経路が変わるため、個別に確認してください。
- UDP：アプリの通信がTunに取り込まれていること、ローカルの転送経路がUDPに対応すること、リモート側の設定で対象の通信が許可されていることをすべて確認してください。
- 既存の接続：通信の取り込み方法を切り替えた後は、対象アプリを再起動し、古い接続が元の経路を使い続けないようにしてください。
プロキシ接続の確認：コマンドとログ
問題を調べるときは、システムプロキシ設定を使わず、ローカルのプロキシポートを明示して接続します。明示的にプロキシを指定すれば接続できるのにブラウザーでは失敗する場合は、ブラウザーの設定や拡張機能、システムプロキシからの取り込みに原因があると考えられます。明示的に指定しても失敗する場合は、待ち受け、アクティブな設定、リモート接続を先に確認してください。
以下はWindowsのターミナルで使う2種類のテスト方法です。例としてHTTPとSOCKSのポートをそれぞれ有効にし、予約済みのサンプルドメインを接続先にしています。実際に調べるときは、診断したい接続先に置き換えてください。コマンドの成功・失敗だけで、特定地域のサービスに接続できるかを判断しないでください。
# HTTPプロキシポート経由でHTTPSリクエストを送信
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/
# SOCKSプロキシ経由で接続し、接続先のドメイン名をプロキシ側で処理
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/socks5hとsocks5の主な違いは、接続先のドメイン名をローカルで先に名前解決するかどうかです。前者はドメイン名の処理をプロキシ側に渡しますが、最終的な名前解決方法はコアの設定によって異なります。コマンド内の10秒と20秒は、それぞれ接続タイムアウトと全体の制限時間です。実測の遅延や性能を示す値ではありません。コマンドラインツールはWindowsのシステムプロキシを自動的に使うとは限らないため、ここではプロキシを明示的に指定しています。
| テスト結果 | まず確認すること | 次の手順 |
|---|---|---|
| ローカル接続が拒否される | コアが起動していない、ポート番号が違う、対応する受け口がない | 起動ログと待ち受け設定を確認する |
| プロキシのハンドシェイク後にタイムアウトする | リモート接続、接続先サービス、DNS、ルーティング | ログからどの段階で失敗したかを確認する |
| コマンドでは接続できるが、ブラウザーでは失敗する | ブラウザー独自のプロキシ設定、拡張機能、既存の接続 | システムプロキシを確認してからブラウザーを再起動し、テストする |
| 全般モードでは接続できるが、ルールによる振り分けでは失敗する | 対象ドメインが直接接続に振り分けられている、IPルール、名前解決の違い | 対象通信の出経路を確認し、より具体的なルールを追加する |
| Webページは使えるが、アプリは接続できない | アプリがシステムプロキシに従わない、またはUDPを使用している | まずアプリのプロキシ設定を確認し、その後Tunを検討する |
よくある質問と元の設定に戻す手順
全般モードに切り替えても、特定のアプリが直接接続するのはなぜですか？
まず、そのアプリの通信がクライアントに取り込まれているか確認してください。システムプロキシを無視している、個別にプロキシを設定している、切り替え前の接続を使い続けている、といった可能性があります。ログに該当するリクエストがなければ、ルーティングを変更しても効果はありません。まず取り込み方法を確認し、その後に出経路を調整してください。
中国本土をバイパスする設定なのに、中国本土のWebサイトがプロキシ経由になるのはなぜですか？
サイトがドメイン名の分類に含まれないAPIや海外のリソースを使っている場合や、より上位にあるカスタムルールに一致している場合があります。まず対象のドメイン名と出経路を特定し、必要な直接接続ルールを追加してください。1つのリソースに問題があるからといって、共有範囲の広いドメイン全体や海外のIPアドレスすべてを直接接続に変更しないでください。
Tunを有効にした場合、システムプロキシも有効にする必要がありますか？
すべての設定に当てはまる答えはありません。Tunが対象アプリの通信を取り込んでいるなら、システムプロキシは不要な場合があります。一方、アプリによっては引き続き個別のプロキシ設定を優先します。問題を調べるときは、原因を絞り込めるよう、まず接続方法を1つに決めてください。また、Tunがコア自身のリモート接続まで再度取り込み、ループが発生しないことも確認してください。
Android版でも同じメニューを使えますか？
いいえ。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。Androidでは通常、システムが提供する仮想ネットワークインターフェースを通じて通信を取り込みます。入口の仕組みはWindowsのシステムプロキシとは異なります。プロトコルや設定項目も、実際に使用するコアに合わせて確認してください。「まず通信が取り込まれているか確認し、次にルーティングの出経路を確認する」という切り分け方は共通です。
Tunを有効にしてインターネット接続全体に問題が出た場合は、以下の順に、動作確認済みの基本設定へ戻してください。一度に変更する設定を1つに絞り、結果を記録しましょう。ノード、DNS、ルール、コアを同時に変更するより、原因を特定しやすくなります。
- Tunを無効にし、クライアントが関連ルートを削除するまで待ちます。LANと元のネットワークが復旧したか確認してください。
- システムプロキシを確認します。使う場合は正しいローカルポートを指定し、使わない場合は解除するか、元の設定に戻してください。
- 動作確認済みのアクティブな設定を1つ残し、プロキシを明示するコマンドでローカルの受け口からリモートまでの接続を確認します。
- 一時的に全般モードへ切り替えて接続し直し、ルールによる振り分けが原因か比較します。確認後は普段使いのルールに戻してください。
- 通信を取り込む必要がある場合は、Tunだけを有効にして、権限、DNS、ルーティングの競合、アプリの接続を順番に確認します。