V2Ray Windows版 初心者から上級者までのガイド

基本概念：クライアント、コア、プロキシ設定

3つの層を区別してから操作を始める

v2rayN、v2rayNG、v2flyNGはいずれもGUIクライアントです。クライアントはサーバー情報の保存、サブスクリプションの管理、コア設定の生成を担い、システムプロキシ、ルーティング、ログなどの操作画面を提供します。XrayやV2Flyはプロキシコアにあたり、設定に従って接続を確立し、プロトコルと伝送を処理し、ドメイン名やIPのルーティングを実行します。両者を同じものとして扱ってはいけません。クライアントの「起動」をクリックしても、GUIがすべての通信を直接処理するわけではなく、クライアントが設定を整えてコアを呼び出します。トラブル対処では、GUIによる管理、コアの起動、リモート設定、アプリがローカルプロキシに接続していないことのどこで問題が起きたかを先に判断します。

3つ目の層がプロキシ設定です。サーバーアドレス、ポート、ユーザー識別子、プロトコル、伝送、TLS、ルーティング、DNSなどのパラメータを定義します。クライアントはこれらのデータを管理するツールにすぎず、利用できるかどうかは各フィールドが正しく対応しているかで決まります。サブスクリプションは設定を一括配布する方法の一つであり、クライアントでもコアでもありません。サブスクリプションの更新に成功したということは、クライアントが内容を取得して解析できたという意味にとどまり、すべての設定で接続できることを直接証明するものではありません。逆に更新に失敗しても、ローカルのコアが壊れているとは限りません。サブスクリプションURL、ネットワーク経路、返却形式に問題がある可能性もあります。

1つのリクエストが通る経路

ブラウザーでWebページにアクセスする場合、一般的な経路は次のとおりです。ブラウザーがシステムプロキシ設定を読み取り、リクエストをv2rayNのローカルHTTPまたはSOCKS待受ポートへ渡します。コアはルーティングルールに従って直接接続かプロキシ出口かを選び、プロキシ出口の場合はサーバー設定に基づいてリモート接続を確立します。どこか一つが途切れても、見た目には「Webページが開けない」だけに見えます。そのため、最初から設定を何度も入れ替えるべきではありません。まずローカル待受が存在するかを確認し、次にアプリがその待受ポートへ通信を送っているか、続いてコアのログにリクエストが届いているかを見て、最後にリモートパラメータとネットワーク条件を確認します。

システムプロキシとルーティングも異なる層の機能です。システムプロキシは「システム設定に従うアプリがどの通信をクライアントへ渡すか」を決め、ルーティングルールは「コアが受け取ったリクエストをどの出口へ送るか」を決めます。ターミナルプログラムがシステムプロキシを読み取らない場合、ルーティングルールを10回変更しても結果は変わりません。リクエストがそもそもコアへ入っていないからです。同様に、TUNを有効にして接続範囲を広げても、誤ったサーバーアドレス、TLSパラメータ、ユーザー識別子が自動的に直るわけではありません。この境界を理解することが、以降の設定を互いに干渉させない基本です。

戻せる学習環境を作る

初回設定では、信頼できる1つのサーバー設定だけを残し、しばらくはデフォルトルーティングを使います。すぐにTUNを有効にしたり、DNSを同時に変更したりしないでください。まずブラウザーがシステムプロキシ経由で再現可能な通信を1回行える状態にし、その後で機能を一つずつ追加します。各段階で、クライアントの重要な設定、ローカルポート、現在の設定名を記録します。後でルーティングに問題が起きても、「単一設定、デフォルトルーティング、システムプロキシ」という基準状態へ戻せます。クライアントの再インストールは通常、GUIやファイルを整理するだけで、サブスクリプション内容、リモートパラメータ、アプリ自身のプロキシ設定を自動修正するものではありません。

クライアントの選定：プラットフォームとコア要件で判断する

デスクトップではv2rayNを優先する

Windows、macOS、Linuxのデスクトップではv2rayNが基本の選択肢です。デスクトップGUIで、サブスクリプション、設定、システムプロキシ、ルーティング、DNS、TUN、ログをまとめて管理できます。Windowsのダウンロードページにはデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームUIを採用し、異なるデスクトップOSで近い操作感を求めるユーザーに向いています。従来のWPF版はWindows標準のデスクトップ技術を使い、以前のv2rayNの操作位置に慣れているユーザーに適しています。どちらもクライアントの選択肢であり、プロトコルやコアの種類と混同しないでください。

デスクトップパッケージを選ぶときは、プロセッサのアーキテクチャとパッケージ形式も確認します。一般的なWindowsデスクトップではx64を選びます。macOSではApple SiliconかIntelかを先に確認します。Linuxではx64とarm64に加え、ディストリビューションに応じてdebまたはrpmを選びます。アーキテクチャが合わないと、インストーラーが起動しない、対応していない形式だと表示される、起動直後に終了するといった症状が出ます。これはクライアントの実行層の問題で、サブスクリプションURLやサーバー設定とは無関係です。まずクライアントのダウンロードページに戻り、プラットフォームの入口を確認してください。

Androidではv2rayNGとv2flyNGから選ぶ

Androidではv2rayNGを第一候補にします。主にXrayコアを実行コンポーネントとして使い、一般的なプロトコル、ルーティング、アプリごとのプロキシ設定が必要な場面に適しています。v2flyNGはV2Flyコアを使用し、V2Fly固有の動作や既存の設定手順が必要な場合の選択肢になります。2つのアプリは画面や設定場所が完全に同じではありません。同じサブスクリプションをインポートできるかどうかも、設定フィールドとコアの対応状況によって決まります。名前が似ているからといって、すべての項目がそのまま対応すると考えないでください。

Androidのダウンロードパッケージは通常、arm64版と汎用版に分かれています。比較的新しい主流スマートフォンは多くがarm64です。アーキテクチャが分からない場合は汎用版を選びます。インストール後、初回にVPN接続を開始すると、システムの許可ダイアログが表示されます。この許可はローカル仮想ネットワークインターフェースを作成するためのもので、アプリが通信を処理するために必要な仕組みです。端末で別のVPN接続が有効になっている場合は、先に競合する接続を終了してください。通常、この種のインターフェースは同時に1つしか有効にできません。バックグラウンド動作は省電力設定の影響も受けますが、これは基本接続が安定してから確認します。

機能の多さで実際の要件を置き換えない

クライアント選びは、3つの問いから始めます。端末のプラットフォームは何か、既存設定が必要とするコア機能は何か、アプリはどの方法で接続するのかです。Windowsのブラウザーと一般的なデスクトップアプリが中心なら、v2rayNとシステムプロキシで十分なことが多いです。Androidでアプリごとのプロキシが必要なら、v2rayNGで対象に含める範囲や除外範囲を設定します。システムプロキシを読み取らないプログラムに出会った場合だけ、アプリ自身のプロキシ設定やTUNを検討します。必要最小限の構成から始めるほうが、最初からすべての高度な機能を有効にするより、保守コストを大きく抑えられます。

古いクライアントから移行する場合は、プログラムフォルダー全体を直接コピーせず、サブスクリプションまたは標準の共有設定を再インポートすることを優先します。古いフォルダーには、期限切れのルーティングファイル、ポート設定、ログ、GUIの状態が残っていることがあり、コピーすると過去の問題まで持ち込むおそれがあります。移行後は、まず1つの設定を選んでローカル待受を確認し、その後でルーティングルールを一つずつ戻します。サーバー設定は機密性のある接続情報です。管理下にある端末と信頼できるバックアップ先だけに保存し、スクリーンショットやトラブル対処用の記録では、サブスクリプションURL、ユーザー識別子、認証情報を隠してください。

まだ判断できない場合は、まずクライアント比較を読んでください。プラットフォームとクライアントを決めてからインストールへ進むことで、アーキテクチャやパッケージ形式の誤りによる起動失敗を、サブスクリプションやネットワーク障害と誤認せずに済みます。

インストールと初回起動：コアと待受ポートを確認する

Windowsのインストールと保存先の注意点

Windowsでシステムアーキテクチャに合うv2rayNパッケージを取得したら、ダウンロードページに記載された形式に従ってインストールまたは解凍します。解凍して使う形式では、現在のアカウントに読み書き権限がある固定フォルダーへ配置してください。圧縮ファイルのプレビュー画面や一時ダウンロードフォルダーから長期間実行するのは避けます。クライアントは設定の保存、コンポーネントの更新、ログの書き込みを行うため、フォルダー権限が不足すると、GUIは開くのに設定を保存できない、コアを終了できない、更新後にファイルが不足するといった症状が起きます。

初回起動後は、いきなり大量のサブスクリプションをインポートしないでください。クライアントの設定またはログ画面を開き、コアプロセスを呼び出せることを確認して、ローカルHTTPとSOCKSの待受アドレスを記録します。一般的な待受アドレスはループバックインターフェース 127.0.0.1 です。これは同じ端末上のプログラムだけがアクセスできることを示します。ポートはクライアント設定によって決まるため、ガイドの例示ポートを現在の端末の固定値だと考えないでください。システム保護ツールがネットワークアクセスを確認してきた場合は、利用範囲に応じて判断します。ローカルのループバックプロキシを使うだけなら、待受を公共ネットワークへ公開する必要はありません。

macOS、Linux、Androidの初回許可

macOSで初めてダウンロードしたアプリを起動すると、システムが提供元の確認やネットワーク設定に関する権限を求めることがあります。許可後は、メニューバーまたはクライアント画面のシステムプロキシ操作が、現在のネットワークサービスへ設定を書き込めるか確認します。Wi-Fi、有線ネットワーク、別のネットワークサービスを切り替えると、システムプロキシの状態を再確認する必要があります。ネットワークサービスごとに設定を保存できるためです。Linuxではデスクトップ環境によってシステムプロキシの対応が異なります。デスクトップのプロキシ設定を読むアプリもあれば、自身の引数や環境変数だけを読むコマンドラインプログラムもあります。そのため「クライアントが動いている」ことと「すべてのプログラムが接続済み」であることは別です。

Androidで初回接続するときは、システムVPNの許可を確認します。許可後にステータスバーへVPNアイコンが表示されても、それは仮想インターフェースが作成されたことを示すだけで、リモート設定が利用可能だとは限りません。まず1つの設定を選び、クライアントに明確なエラーが出ていないかを確認してから、ブラウザーで基本アクセスを試します。バックグラウンドに移るとすぐ切断される場合は、バッテリー最適化、バックグラウンド動作の許可、システムのタスク終了ポリシーを確認します。一部のアプリだけ通信できない場合は、再インストールを繰り返すのではなく、アプリごとのプロキシ範囲を確認します。

1. クライアント自体が安定して起動することを確認 同名プロセスが複数起動していれば終了し、1つのインスタンスだけを起動します。画面がすぐ消える場合は、まずシステムアーキテクチャ、実行権限、クライアントログを確認し、サブスクリプションはまだ調べません。
2. コアが正常に呼び出されていることを確認 ログで設定解析、待受失敗、権限に関する情報を探します。この段階ではローカル実行経路だけを判断し、Webページの表示結果でコアの確認を代用しません。
3. ローカルポートが待ち受け状態であることを確認 HTTP、SOCKS、または混合待受の実際のポートを記録します。以降、ブラウザー、ターミナル、システムプロキシはすべて同じポート種別を指す必要があります。
4. 初期設定の記録を1つ保存 クライアントの種類、コアの選択、待受アドレス、ポート、システムプロキシの有効・無効を記録し、以降のトラブル対処の基準にします。

Windowsで指定ポートが待ち受け状態か確認します。例ではポート10809を使います。

netstat -ano | findstr :10809

コマンドの結果が何も表示されない場合、そのポートは現在待ち受けていないか、実際のポートが例とは異なります。クライアントに戻ってローカル待受設定を確認してください。ポートが別のプロセスに占有されていると表示された場合は、最後の列のPIDを使ってタスクマネージャーでプロセスを特定します。v2rayNの二重起動、別のローカルプロキシ、開発ツールなどが競合の原因になります。詳しい手順はv2rayNのローカルポート占有を切り分ける方法をご覧ください。

初回接続では最短経路だけを検証する

ローカル確認が終わったら、1つの設定をインポートしてアクティブ項目にします。まずはクライアントのデフォルトルーティングとデフォルトDNSを使い、複雑なルールは有効にしません。システムプロキシを有効にし、システムプロキシを確実に読み取るブラウザーで通常のHTTPSページへアクセスします。同時にログに対象ドメインのリクエストが出るか確認します。ブラウザーのリクエストが記録されているのに接続できない場合は、リモート設定またはネットワーク層の問題です。ログにリクエストがまったく出ない場合は、ブラウザーが独自プロキシを使っていないか、システムプロキシが正常に設定されたか、ポートが一致しているかを重点的に確認します。

検証が終わったら、「システムプロキシをクリア」を自分でテストします。クライアントを終了する前にシステムプロキシを元へ戻すと、OSが停止済みのローカルポートを指し続ける事態を防げます。クライアントが異常終了してWebページがすべて開けなくなった場合も、最初に残留したシステムプロキシを確認してクリアします。すぐDNSを変更する必要はありません。インストール段階の目標は、すべての機能を有効にすることではなく、起動、待受、接続、終了ができるローカル基準を作ることです。

サブスクリプションと設定管理：取得、解析、接続を分けて考える

サブスクリプション更新には3つの独立した結果がある

サブスクリプションの更新は、少なくともURLへのアクセス、内容の解析、設定の書き込みという3段階を経ます。クライアントはまずサブスクリプションURLへアクセスし、応答を取得してから形式を判定し、設定を解析します。最後に有効な項目を対応するグループへ書き込みます。3段階すべてが完了して初めて一覧が更新されます。ネットワークリクエストに失敗した場合は、現在のネットワークからURLへアクセスできるか、システム時刻が正しいか、クライアントの更新リクエストが適切な経路を使っているかを確認します。解析に失敗した場合は、返却内容がクライアント対応形式かを確認し、ローカルポートを何度も変更するのは避けます。

サブスクリプションURL自体にアクセス権が含まれていることが多く、機密情報として扱う必要があります。完全なURLを公開スクリーンショット、ログの添付ファイル、ブラウザー同期メモに載せないでください。追加時には、用途や出所が分かるグループ名を設定し、「サブスクリプション1」「サブスクリプション2」のような名前だけにしないようにします。グループ名は接続動作を変えませんが、どの更新でどの設定が上書きされたかを後から判断しやすくします。複数の出所を同じグループに混在させると、同名項目やフィールドの違いが出たときに、問題がどちら側にあるか分かりにくくなります。

インポート後の確認は「一覧に表示された」だけでは不十分

設定が一覧に入ったら、少なくともプロトコル、サーバーアドレス、ポート、伝送方式、TLSの状態、サーバー名などの重要フィールドを確認します。ユーザー識別子などの認証データは、日常の画面で完全表示しなくても構いませんが、存在と形式が正しい必要があります。VLESSやVMessなどのプロトコル名は設定の一部しか示しません。WebSocket、gRPC、TCPなどの伝送方式に加え、TLS、SNI、パス、サービス名も一致させる必要があります。プロトコル欄だけを同じ名前に変更しても、他のフィールドの不一致は直りません。

一括テストの結果は、候補を絞る手がかりにすぎません。テスト失敗は現在のネットワーク、リモートの状態、テスト先、DNSが原因かもしれず、テスト成功もすべてのアプリが正しく接続できることを意味しません。より確実なのは、1つの設定を選び、デフォルトルーティングを保ったまま、ブラウザーで実際のリクエストを送り、コアログと照合する方法です。同じ問題に対して複数の設定を次々と切り替えると、ログとシステムプロキシの状態が頻繁に変わり、因果関係を判断しにくくなります。

1. サブスクリプションを追加してグループ名を付ける クライアントのサブスクリプション管理画面からURLを追加し、先頭と末尾に空白や改行がないことを確認します。保存後は追加したグループだけを更新し、返却結果を確認しやすくします。
2. 更新メッセージとグループの変化を確認 リクエスト失敗、解析失敗、書き込み後に有効な項目がない状態を区別します。段階ごとに確認対象は異なるため、すべてをコアの問題と決めつけないでください。
3. 1つの設定を選びフィールドを確認 プロトコル、アドレス、ポート、伝送、TLS関連フィールドが揃っていることを確認し、アクティブ設定にしてコアを起動します。
4. 直近で使えた戻し先を残す 更新前に現在の設定データベースをエクスポートまたはバックアップします。出所の内容が変わった場合に、更新が原因なのかローカル環境の変化なのかをすぐ判断できます。

更新に失敗したら段階ごとに確認する

クライアントにサブスクリプションURLへ接続できないと表示されたら、まずURLが完全か確認し、システムプロキシが停止中のローカルポートを指していないかを調べます。ブラウザーでアクセスできても、クライアントの更新リクエストが同じ経路を使うとは限りません。別々のプロキシ設定を使っている可能性があるためです。返却されたものがログインページ、エラーページ、通常のテキストの場合、クライアントは通常形式エラーを報告します。この場合はサブスクリプションの出所を確認し、Webページの内容を共有設定として手動インポートしないでください。

更新に成功したのに一覧が空の場合は、特定項目を除外するグループ設定が有効になっていないか、返却内容に現在のクライアントが認識できる設定が含まれているかを確認します。更新後に既存項目が消えた場合は、連続して更新せず、そのサブスクリプションが上書き更新を採用しているか確認し、残したい手動項目をバックアップから戻します。より詳しい分類手順はサブスクリプション更新のよくある質問を、初回インポートの簡単な手順はクイックスタートのサブスクリプション手順をご覧ください。

手動設定はフィールドを正確に確認したいときに向く

設定が1つだけの場合や具体的なフィールドを確認したい場合は、クライアントの手動追加機能を使えます。入力時は上から順に一項目ずつ確認し、似た名前から推測しないでください。TLSハンドシェイクで使うサーバー名は、設定要件と一致させます。伝送パス、Host、サービス名などにもそれぞれ役割があります。証明書やTLSハンドシェイクのエラーが出た場合は、まずシステム時刻、証明書の有効期限、ドメインの一致、SNIを確認します。詳しい仕組みはTLSハンドシェイクと証明書エラーの切り分けを参照してください。証明書検証を無効にすることを日常的な対処方法にしてはいけません。

サブスクリプション段階を終えたら、4つの問いに答えられる状態にします。設定はどのグループから来たのか、現在のアクティブ項目はどれか、コアはどの種類の設定を使っているか、ローカル待受ポートはいくつか。これらが明確であって初めて、次のシステムプロキシとアプリ接続テストに確かな土台ができます。

プロキシモードとアプリの接続範囲

システムプロキシはシステム設定を読むアプリだけを対象にする

v2rayNの「システムプロキシを自動設定」は、通常、OSのプロキシアドレスをクライアントのローカル待受ポートへ向けます。ブラウザーや一部のデスクトップアプリはこの設定を読むため、個別設定なしで接続できます。一方、独自のプロキシ設定を持つプログラムや、システムプロキシを完全に無視するプログラムもあります。例として、一部のターミナルコマンド、開発ツール、ゲームプラットフォーム、独自ネットワークスタックを持つアプリが挙げられます。システムプロキシが有効なのに特定のプログラムが直接接続する場合、それだけでv2rayNやコアが失敗したとは限りません。まずそのプログラムがどの接続方式に対応しているかを確認します。

「システムプロキシをクリア」は、クライアントが書き込んだシステム設定を削除するために使います。クライアントを停止するとき、ローカルポートを変更するとき、別のネットワークツールへ切り替えるときは、先に古いプロキシをクリアします。システムが 127.0.0.1 のポートを指し続け、そのポートを待ち受けるプロセスがなければ、システムプロキシに従うアプリは一斉に接続失敗します。この障害はプログラムの異常終了後によく起きます。ネットワーク全体が使えないように見えても、実際にはシステムプロキシを元に戻すだけで解決することがあります。

HTTPとSOCKSのポートは自由に入れ替えられない

ローカルHTTPプロキシは、HTTPプロキシに明確に対応するアプリに適しています。SOCKSプロキシは、SOCKSプロトコルで接続を転送します。クライアントは個別のポートを提供することも、複数の接続方式に対応する混合ポートを提供することもあります。アプリに入力する値は待受種別と一致させる必要があります。SOCKSポートをHTTPプロキシ専用の欄へ入力すると、通常はプロトコルハンドシェイクエラーや接続リセットが起きます。アドレスには一般に 127.0.0.1 を使い、同じ端末のクライアントへ接続します。LAN向け待受とアクセス制御を明確に設定していない限り、ループバックアドレスを任意のNICアドレスへ変更しないでください。

ブラウザーはまずシステムプロキシで基準テストを行います。ブラウザーにプロキシ拡張を入れている場合は、拡張が「システムに従う」設定かカスタム設定かを確認します。拡張に固定ポートが設定されていると、システム設定が上書きされ、クライアントがポートを変更してもブラウザーが古い待受へアクセスし続けることがあります。プライベートウィンドウや別のブラウザープロファイルが独自ルールを使う場合もあります。ブラウザーは使えるのにターミナルが使えない場合は、両者を分けて確認し、具体的な手順はブラウザーとターミナルのプロキシ範囲を確認する方法を参照してください。

ターミナルプログラムは通常、明示的な設定が必要

多くのコマンドラインツールは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY などの環境変数を読み取りますが、対応範囲はツールによって異なります。環境変数には、現在のプロセス、現在のターミナルセッション、システムの永続設定という違いもあります。トラブル対処では、現在のターミナルだけに一時設定し、検証後はウィンドウを閉じて元に戻すことをおすすめします。期限切れのポートをグローバル環境へ長期間残さないためです。以下の例では、v2rayNのHTTP待受ポートが10809であると仮定しています。使用前に、クライアント画面に表示される実際のポートへ置き換えてください。

Windowsコマンドプロンプトの現在のセッション：

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl https://example.com

PowerShellの現在のセッション：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe https://example.com

コマンド実行後もコアログにリクエストが出ない場合は、そのツールが環境変数を読み取るか、変数名が正しいか、アドレスとポートがHTTP待受に対応しているかを確認します。ログにリクエストが出ているのに接続できない場合は、ルーティング、DNS、リモート設定を調べます。ターミナル出力の「タイムアウト」だけで層を判断しないでください。ローカルポートが待ち受けていない、リモートへ到達できない、ドメイン名の解決に失敗した場合も似た表示になります。

出口の結果だけでなくプロキシ範囲を検証する

確実な検証では、3つの信号を同時に確認します。アプリが実際に対象のプロキシ設定を使っていること、クライアントログがそのアプリのドメインまたは接続を受け取っていること、ルーティング結果が想定どおりであることです。出口を示すページを1つ見るだけでは、すべてのアプリが同じ経路を使っていることも、DNS問い合わせが想定どおり処理されたことも確認できません。テストではブラウザー、ターミナル、対象アプリを分けて起動し、毎回少数の識別しやすいリクエストだけを発生させ、ログからコアへ入ったかを判断します。

この段階を終えたら、システムプロキシに従うアプリ、自身の設定を使うアプリ、まだ接続できないアプリを明確に分類できる状態にします。3番目のアプリが実際に存在し、個別設定もできない場合に限ってTUNを検討します。システムプロキシで安定して動いている環境なら、まずルーティングへ進むほうが簡単です。

ルーティング：リクエストがコアに入った後で出口を選ぶ

ルーティングが解決するのは出口の選択

ルーティングルールが処理するのは、すでにコアへ入った通信だけです。ドメイン、IP、ポート、ネットワーク種別、インバウンドタグなどの条件に基づき、プロキシ、直接接続、ブロックなどの出口へリクエストを振り分けます。一般的には、LANと明確な内部アドレスを直接接続し、それ以外をプロキシへ送ります。ドメインリストで細かく分けることもできます。どの戦略でも、まずデフォルトの動作を定義し、対象範囲の明確な例外ルールを追加します。例外だけを書いて最終的なフォールバック出口を理解していないと、どのルールにも一致しないリクエストが想定外の経路へ進むことがあります。

ルールは通常、上から順に照合されます。前方に広い条件を置くと、後方の精密な条件が隠れてしまいます。たとえばすべてのTCPとUDPを対象にするプロキシルールを先に書くと、後に置いたプライベートアドレスの直接接続ルールは一致する機会を失います。順序を設計するときは、まず必ず直接接続する条件や個別処理が必要な精密ルールを置き、次に範囲の広い分類ルール、最後にフォールバックを置くのが一般的です。変更後は明確なドメインを使って一つずつ確認し、長いルールセットを一度にインポートしてWebページを1つだけテストする方法は避けます。

ドメインルール、IPルール、名前解決戦略

ドメインルールは、コアが元の対象ドメインを保持している場合に分かりやすく、完全なドメイン、ドメインサフィックス、あらかじめ定義された分類に一致させられます。IPルールは対象IPに依存します。リクエストが最初にドメイン名で現れた場合、ルーティング実行時に追加の名前解決を行うかどうかは、domainStrategy などの設定に左右されます。名前解決戦略を過度に積極的にするとDNS問い合わせが増え、照合経路が変わることがあります。まったく解決しなければ、IP条件だけを書いたルールでドメインリクエストを処理できない可能性があります。特定の戦略名を普遍的な最適解と考えず、実際に使う条件に合わせて選択してください。

プライベートアドレスへの直接接続は、本機、LAN機器、内部サービスでよく使われますが、実際のネットワークと組み合わせて考える必要があります。企業ネットワーク、仮想マシン、コンテナ、開発環境では異なるプライベートセグメントが使われることがあります。複数の仮想NICがある場合は、システムルーティングも接続先に影響します。ドメインが最終的にプライベートアドレスへ解決される場合は、DNSの結果が現在のネットワークから得られたものかも確認します。「ドメインでは失敗するが、内部IPを直接入力すれば使える」場合は、プロキシ出口だけを変更せず、ドメインの解決結果とルールの一致状況を比較します。

ルール構造を説明するためのXrayルーティング断片です。出口タグは完全な設定内のoutboundタグと一致させます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

この設定は、指定した内部ドメインを直接接続し、プライベートIPも直接接続し、それ以外のTCPとUDPを proxy という名前の出口へ渡すことを表します。これは完全な設定のルーティング部分であり、クライアント全体の設定として単独実行するものではありません。クライアントがGUIでルーティングを管理する場合は、対応するルール編集画面で同じロジックを表現し、クライアントが生成した他のフィールドを直接上書きしないでください。出口タグが存在しないと、コアは設定エラーを報告します。ルールデータファイルが不足している場合や、対応していない名前を使った場合も、起動時または照合時に通知が出ます。

最小限のルールセットから段階的に拡張する

ルーティングを作るときは、まずプライベートアドレスの直接接続ルールを1つと、明確なフォールバックを残し、ブラウザー、ターミナル、LANサービスが想定どおり動くか確認します。その後、ドメインルールを1グループずつ追加し、対象と管理元を明記します。ルール名は「LAN直接接続」「開発サービス直接接続」のように用途を表し、「ルール1」だけの名前は避けます。異常の原因になったルールは一時的にそのグループを無効にし、直前の安定状態へ戻せます。

DNSとルーティングは分けて記録します。ルーティングは出口を決め、DNSはアドレスの取得方法を決めます。互いに影響しますが、同じ設定ではありません。ドメインだけ失敗する場合は、まず解決結果を比較します。IP接続も失敗するなら出口とリモート接続を確認します。リクエストがログにまったく出ないなら、アプリ接続層へ戻ります。この3つの現象を分ければ、ルーティング画面でDNSを何度も変更しながら、システムにも別の名前解決サービスを設定する状況を避けられます。

ルーティング後の受け入れテスト

少なくとも3種類の対象をテストします。LANアドレス、明確に直接接続したいドメイン、プロキシ出口を使う通常のドメインです。各対象について、アプリの接続方式、解決結果、一致したルール、最終出口を記録します。プロキシを有効にするとLANアクセスが途切れる場合は、まずプライベートアドレスがより広いプロキシルールに先に一致していないかを確認します。特定ドメインが時々異なる経路を通る場合は、複数のアドレスへ解決されていないか、ルールがドメイン基準かIP基準かを調べます。

ルーティングが安定してからTUNを検討します。この時点なら、通信の接続範囲を広げても、検証済みのルールで出口を判断できます。システムプロキシの段階でルーティングが整理されていないままTUNを有効にすると、より多くのプログラムとシステム通信が未検証のルールへ入り、障害範囲が広がります。

TUNモード：システムプロキシを読まない通信に対応する

TUNが変えるのは通信の入口

TUNは仮想ネットワークインターフェースでシステム通信を受け取り、HTTPやSOCKSのプロキシ設定に対応しないアプリもコアへ入れる可能性を作ります。解決するのはアプリの接続範囲であり、プロトコルを変更するものではありません。誤ったリモート設定が自動的に直るわけでもありません。有効にすると、システムルーティング、仮想NIC、DNS、コアのインバウンドが共同で処理するため、システムプロキシより故障点が増えます。基本設定がシステムプロキシで検証済みで、個別にプロキシ設定できないアプリが実際にある場合に限り、この段階へ進むことをおすすめします。

デスクトップOSでは、仮想インターフェースの作成やルーティングの変更に追加権限が必要な場合があります。権限が足りないと、クライアント画面ではスイッチが操作済みに見えても、ログにはインターフェース作成、ルート書き込み、ドライバーアクセスの失敗が出ます。AndroidのVPN接続自体はシステム提供の仮想ネットワーク機構を使いますが、許可、他のVPNとの競合、アプリごとの範囲、バックグラウンド制限を確認する必要があります。プラットフォームによって実装は異なるため、別のプラットフォームのドライバーや権限手順をそのまま使わないでください。

有効化前に基準状態を固定する

• 現在のアクティブ設定は、システムプロキシでブラウザーのテストを完了している。
• ローカル待受ポートとコアログは正常で、設定エラーが継続していない。
• ルーティングルールで、少なくともプライベートアドレスの直接接続とデフォルト出口を検証済みである。
• システム上で別のVPNや仮想ネットワーク制御ツールを同時に実行していない。
• 有効化前のDNS、システムプロキシ、クライアント設定を記録している。

これらの条件を満たしたら、まず重複するネットワーク制御方式を整理します。主要な通信をTUNで処理する場合は、クライアントの説明に従ってシステムプロキシを調整し、同じリクエストが不要な入口を重複して通らないようにします。有効化後は、基本Webページ、もともとシステムプロキシを読まなかった対象アプリ、最後にLANサービスの順でテストします。各段階で、ログにリクエストが出るか、ルーティング選択が正しいかを確認します。初回から新しいDNS、複雑なルール、複数の除外リストを同時に追加しないでください。

1. 競合する可能性のある仮想ネットワーク接続を切断 他のVPNセッションや同種の制御プログラムを終了し、通常の物理ネットワークだけを残します。仮想マシンやコンテナのネットワークは無闇に削除せず、セグメントとルートを記録します。
2. 必要な権限でTUNを有効にする クライアントログで、仮想インターフェースの作成とルートの書き込みが成功したことを確認します。スイッチの色だけでは、システム層の処理完了を判断できません。
3. DNSと通常のTCPリクエストを検証 まずドメイン名の解決をテストし、次にブラウザー接続をテストします。IPは使えるのにドメインが失敗する場合は、TUNが使うDNS経路を重点的に確認します。
4. 対象アプリとLANをテスト これまで接続できなかったプログラムがログに入ることを確認し、同時にプリンター、ルーター管理画面、内部サービスがルールどおり直接接続できることも確認します。

よくある競合を層ごとに判断する

有効化後に完全にネットワークへ接続できなくなった場合は、まず仮想インターフェースとデフォルトルートが作成されたかを確認し、次にコアが動作し続けているかを調べます。TUNを無効にするとすぐ復旧するなら、問題はTUNの入口、ルーティング、DNSに集中しています。クライアントを再インストールする必要はありません。ドメインだけ失敗してIPが使える場合は、DNSサーバーへ到達できるか、問い合わせが想定した出口を通っているか、解決結果を優先して確認します。LANだけ失敗する場合は、プライベートアドレスのルールとシステムルーティングの優先順位を調べます。特に仮想NICと実際のLANが重複したセグメントを使っている場合は注意が必要です。

特定のアプリがまだプロキシに入らない場合は、アプリごとのルールで除外されていないか、独立したネットワークインターフェースを使っていないか、対象通信が現在のTUN実装の対象外ではないかを確認します。Androidでは、「選択したアプリだけをプロキシする」設定か「選択したアプリを除外する」設定かも確認してください。この2つは意味が逆です。バックグラウンドやアプリごとの問題についてはAndroidの権限、省電力設定、アプリごとのプロキシを参照してください。

DNSはTUNのトラブル対処で重要

TUNの接続範囲を広げると、システムサービスやより多くのアプリのDNS問い合わせも処理経路に入る可能性があります。誰が問い合わせを受け、どのサーバーを使い、結果をルーティングにどう利用し、返されたアドレスへ現在の出口から到達できるかを明確にします。システムDNS、クライアントDNS、アプリ内の暗号化DNSを同時に設定すると、実際の経路が想定と異なる場合があります。いったん層を減らし、明確なクライアントDNSを1つ使って検証してから、必要に応じてアプリ固有の設定を戻します。

ログにドメイン解決成功後の接続失敗が出た場合は、解決されたアドレスとルーティング出口を確認します。問い合わせ記録がない場合は、アプリがキャッシュや独自の名前解決機構を使っている可能性があります。キャッシュの更新は確認手段になりますが、何度もキャッシュを消すことを恒久対策にしないでください。同じネットワーク条件で、同じドメインが説明可能で再現性のある名前解決とルーティング結果になることが最終目標です。

TUNを終了するときはシステム状態を戻す

TUNを無効にした後、仮想インターフェースと一時ルートが削除されたか確認し、システムプロキシがまだ実行中のクライアントを指しているかも確認します。クライアントの異常終了でルートが残った場合は、いったんクライアントを再起動してTUNを正常に無効化し、その後でOSのネットワークツールを使ってルートを確認します。復旧中にすべてのネットワーク設定を同時にリセットしないでください。既存の固定アドレス、企業ネットワーク、仮想マシン設定を失う可能性があります。有効化前の記録を残しておけば、変化を一つずつ照合できます。

TUN段階の完了基準は「スイッチが有効のまま」ではありません。対象アプリが実際にコアへ入り、LANへアクセスでき、DNS経路が明確で、終了後にシステムが復元できることが基準です。システムプロキシで要件をすべて満たせるなら、より簡単な接続方式を使い続けるのも合理的です。

日常の管理とトラブル対処：直近の変更から確認する

管理の中心は設定、状態、変更履歴

日常の管理で頻繁に再インストールする必要はありません。サブスクリプショングループ、手動設定、ルーティングルール、DNS設定、ローカルポートの記録を残し、クライアント更新やルール変更の前にバックアップを作成することが重要です。バックアップにはサブスクリプションURLや接続認証情報が含まれる場合があるため、管理下の場所に保存し、通常のテキストとして公開転送しないでください。復元時は最小限の設定を先にインポートして検証し、その後で大規模なルールを戻します。問題がバックアップそのものにあるのか、新しい環境にあるのか分からなくなるのを防ぐためです。

クライアントを更新したら、まずGUI設定が保持されているか、コアが起動できるか、ローカルポートが変わっていないかを確認し、その後でシステムプロキシをテストします。更新、サブスクリプション更新、ルーティング置換、TUN変更を同じ操作で行わないでください。一度に変更する変数を一種類にすれば、異常時に戻せます。端末を移行する必要がある場合は、古いクライアントの種類、アーキテクチャ、コアの選択、サブスクリプショングループ、待受ポート、ルーティング方針、特殊なアプリプロキシ設定を記録するほうが、古いフォルダー全体をコピーするよりリスクを管理しやすくなります。

障害を統一的に分類する

トラブル対処では、発生時刻、直近の変更、影響範囲を先に記録します。システムプロキシに従うすべてのアプリが同時に失敗した場合は、クライアントプロセス、ローカル待受、システムプロキシを確認します。1つのアプリだけ失敗した場合は、その独自設定を優先して確認します。同じ設定がネットワークによって異なる動作をする場合は、DNS、ネットワーク経路、システム時刻に注目します。影響範囲の判断は、エラーメッセージそのものより価値があります。「接続タイムアウト」だけでは、どの層でタイムアウトしたか分からないことが多いためです。

ログは最初の有効なエラーから読む

クライアントとコアのログは、1回の失敗後に大量の連鎖メッセージを出すことがあります。今回の起動または操作時刻から読み始め、設定解析、待受、DNS、TLS、接続に関する最初のエラーを探します。後から繰り返し出る再試行ログは、結果を示しているだけの場合が多いです。ログを共有する前に、サブスクリプションURL、ユーザー識別子、サーバーアドレス、その他の機密フィールドを削除し、エラーの種類、時系列、必要な前後関係だけを残します。

コアがアドレスの使用中を示した場合は、まずポートを占有しているプロセスを特定します。設定フィールドが無効だと表示された場合は、直近の編集またはサブスクリプション更新に戻り、現在のコアが認識できないフィールドをインポートしていないか確認します。TLS証明書関連のエラーが出た場合は、まずシステム時刻を同期し、サーバー名と証明書のドメインを確認します。DNS問い合わせがタイムアウトする場合は、DNSの経路とサーバーへの到達性を確認し、すぐにサーバー設定の問題だと決めつけないでください。

ポート、システムプロキシ、異常終了

ローカルポートが占有されている場合は、まず同じクライアントを二重起動していないかを確認し、その後で他のプログラムを調べます。ポート変更で競合を回避できますが、すべての手動接続側に影響します。変更後は、ブラウザー拡張、ターミナル変数、開発ツール、LAN端末の設定も更新します。不要になった古いプロセスが占有しているなら、長期的にポートを変更し続けるより、そのプロセスを正常終了させるほうが保守しやすい場合があります。

クライアントが異常終了すると、システムプロキシが残ることがあります。その場合、ブラウザーは存在しないローカルポートへリクエストを送り続けます。v2rayNを再び開いて「システムプロキシをクリア」を使うか、OSのネットワーク設定で元に戻します。Webページがすべて失敗したからといって、すぐネットワークアダプターを削除しないでください。TUNを使っている場合は、仮想インターフェースとルートも追加で確認します。システムプロキシの残留とTUNルートの残留は別の問題であり、個別に確認する必要があります。

サブスクリプション、時刻、証明書を定期的に確認する

起動するたびにサブスクリプションを無条件で連続更新する必要はありません。実際の更新頻度に合わせて周期を設定し、直近で使えた設定を残します。更新後に多数の項目が同時に変わった場合は、まず1項目を検証し、すぐに古い記録をすべて消去しないでください。TLS証明書の検証には正確な時刻が必要なため、システム時刻は自動同期を維持します。時刻のずれは、証明書がまだ有効でない、または期限切れに見える原因になります。サーバー名、SNI、証明書ドメインも一致させる必要があり、接続を繰り返してフィールドの誤りを解消することはできません。

長期運用では、ディスク容量とログの増加にも注意します。ログはトラブル対処に必要ですが、無制限に残すと検索しにくくなります。クライアントが提供する方法で古いログを整理し、内容が分からない設定データベースを直接削除しないでください。更新前に画面の変更内容を読み、更新後は最短経路を検証します。その他のよくある症状は、よくある質問から「インストールと設定」「トラブル対処」の分類で探せます。

再利用できるトラブル対処記録を作る

有効な記録には、プラットフォーム、クライアント、コア、接続方式、アクティブ設定の種類、待受ポート、ルーティングとTUNの有効・無効、エラー発生時刻、最初の有効なログ、検証済みの手順を含めます。「使えない」だけでは不十分です。これらの情報があれば、問題をクライアント、コア、設定、アプリの接続範囲へすばやく絞り込み、次回に最初から試し直す必要を減らせます。解決後は、本当に効果があった変更を追記し、トラブル対処中に追加した無効な一時設定を元に戻します。次の障害の原因になるのを防ぐためです。

詳細設定の進め方：使える状態から説明できる状態へ

詳細設定とはスイッチを増やすことではない

基本段階を終えた後の目標は、より多くの機能を同時に有効にすることではなく、設定を説明でき、テストでき、元へ戻せる状態にすることです。成熟した環境では、どのアプリがシステムプロキシを通り、どのアプリが自身の設定やTUNを使うのか、DNS問い合わせを誰が処理するのか、各ドメインやIPがどのルートへ一致するのか、アクティブ設定がどのプロトコル、伝送、TLSパラメータを使うのか、クライアント更新やポート変更後にどこを同期するのかを明確に答えられます。GUIで有効にした項目数より、これらに答えられることのほうが重要です。

学習の道筋は、観察、ルール、プロトコル、自動化の4層に分けることをおすすめします。まずクライアントとコアのログを読み、アプリから出口までの経路を把握します。次に小規模なルーティングとDNSルールを管理します。その後でプロトコル、伝送、TLSフィールドの組み合わせを理解し、最後に設定のバックアップ、移行、再現性のある検証手順を考えます。各層は、前の層が安定していることを前提にします。

プロトコル、伝送、TLSを分けて理解する

VLESSやVMessなどはプロキシプロトコル、TCP、WebSocket、gRPCなどは伝送方式、TLSは暗号化接続の確立と相手の身元確認を担います。接続できるかどうかは、これらの層のフィールドが全体として一致するかで決まります。「プロトコルが同じ」だからといって、伝送経路、サービス名、サーバー名、安全パラメータまで同じとは限りません。新しい設定を学ぶときは、プロトコル層、伝送層、TLS層ごとに重要フィールドを整理し、コアログと照合して失敗段階を判断します。

TLSハンドシェイクは、保護された接続を確立する段階で行われます。システム時刻の誤り、証明書の有効期限不一致、サーバー名と証明書ドメインの不一致は、ハンドシェイク失敗の原因になります。SNIは接続時に対象サーバー名を示すために使われ、設定と無関係なドメインを適当に入力してはいけません。伝送層のパスやサービス名はリモートサービスの設定で決まるため、経験だけで推測できません。詳細なトラブル対処の要点は、ランダムな組み合わせを試すのではなく、層ごとに確認することです。

ルーティングとDNSのテスト項目を作る

ルーティングルールを追加したら、固定したテスト対象を用意します。LANアドレス、内部ドメイン、通常の直接接続先、プロキシ接続先、UDPが必要なアプリです。ルールを変更するたびに同じ順序でテストし、一致した出口を記録します。DNSのテストでは、名前解決サーバー、返されたアドレス、問い合わせが想定した入口を通ったかも記録します。固定サンプルを使えば、変化がルール自体によるものか、対象サイト、キャッシュ、現在のネットワークによるものか判断しやすくなります。

ルールファイルや分類データを更新するときも、まず少数の対象で検証します。分類名の対象範囲が変わることがあり、広範囲ルールの位置は特に見直す必要があります。カスタムルールには作成理由と日付を明記しますが、根拠のない性能数値を記録する必要はありません。長期間、明確な用途がないルールは削除を検討し、将来の競合を減らします。単純で説明できるルールセットのほうが、出所不明のルールを大量に使うより信頼性が高いことが多いです。

異なる端末は独立した環境として扱う

デスクトップとAndroidで同じサブスクリプションを使うことはできますが、システムプロキシ、VPNインターフェース、バックグラウンド方針、アプリごとの機能は異なります。Windowsで検証した接続方式をAndroidへそのままコピーできると考えないでください。AndroidのVPN許可の問題をサブスクリプションのせいにするのも誤りです。端末間で切り分けるときは、まず両方が同じ設定を選んでいるか、システム時刻が正しいか、ネットワーク条件が近いかを確認し、その後でコアとフィールドの対応を比較します。

複数のデスクトップ端末でv2rayNを使う場合は、サブスクリプショングループ名とルーティング対象を統一できます。ただし、待受ポート、インストール先、システムプロキシは端末ごとに記録します。macOSとLinuxではシステムプロキシの実装が異なり、コマンドラインツールも独自の環境変数を使うことがあります。共有するのは設定のロジックであり、OSの状態ではありません。移行文書には「実現したい動作」を記載し、同時にプラットフォームごとの具体的な確認方法も残します。

安定した3つの設定プロファイルを設計する

日常設定を3つの段階に分けられます。基本プロファイルは、アクティブ設定1つ、デフォルトルーティング、システムプロキシだけで、コアとブラウザーの検証に使います。分流プロファイルは、検証済みの直接接続ルールと明確なDNS経路を加え、日常のデスクトップ利用に使います。拡張プロファイルは、分流プロファイルにTUNを追加し、システムプロキシを読まないアプリまで対象にします。3つのプロファイルはそれぞれ独立して戻せるようにし、問題が起きたら全設定を削除するのではなく、まず基本プロファイルへ下げます。

各プロファイルの違いを文書化します。システムプロキシの状態、TUNの状態、DNS設定、ルーティングルールのグループ、アプリ独自のプロキシを含めます。切り替え後は同じテスト対象で受け入れ確認を行います。これにより、障害がリモート設定の変化によるものか、ローカルの高度な機能によるものかをすばやく判断できます。基本プロファイルでも失敗するならTUNを調整する必要はありません。基本プロファイルは正常で拡張プロファイルだけ失敗するなら、問題は仮想インターフェース、ルーティング、DNSに絞れます。

継続的に学ぶための資料の順序

まず用語クイックリファレンスで、プロトコル、コア、サブスクリプション、システムプロキシ、ルーティングの用語を確認します。次にクライアント比較でプラットフォームごとの差を理解します。具体的な障害が起きたら、よくある質問から分類を探し、対応する記事を読みます。Project V、V2Fly、Xray、3つのクライアントの関係は、オープンソースエコシステムとクライアント選びを参照してください。資料は「概念—操作—検証—トラブル対処」の順につなげて使い、断片的なパラメータだけを集めないようにします。

この段階では、設定の重点は「一度接続を成功させる」ことから、「動作を長期的に予測できるようにする」ことへ移ります。最小基準を残し、同時に変更する変数を制限し、アプリの接続範囲を記録し、各ルートの一致を証拠で確認し、サブスクリプションと機密設定を管理下でバックアップします。この方法はv2rayN、v2rayNG、v2flyNGに使え、クライアントGUIの違い、コアの動作、OSのネットワーク機構を区別する助けにもなります。