v2rayN完全ガイド
基本から日常のメンテナンスまで

ステップ1 · 基本を理解する

基本知識と接続の流れ

クライアント、コア、リモートサーバーの違い

まず接続の流れを分解してみましょう。アプリがリクエストを送り、PC上のプロキシの入口からコアへ渡され、ルーティングルールによって直接接続するか、リモートサーバーへ転送するかが決まります。v2rayNは設定を管理するGUIクライアントです。サーバー情報やサブスクリプションを管理し、使用する設定を選択してコアを起動します。実際にプロトコルや接続を処理するのはコアです。クライアントをダウンロードしても、リモートサービスが利用できるようになるわけではありません。サーバーアドレスや認証情報、有効期限は、正規のサービス提供元から取得してください。

Project Vは、このエコシステムを理解するうえでの出発点です。V2FlyとXrayは関連するコアの系統です。クライアントの画面とコアの機能は別物です。画面に項目が表示されていても、使用中のコアがその組み合わせに対応しているとは限りません。インポート時にプロトコル、通信方式、セキュリティ設定が非対応と表示された場合は、まず実際に使われているコアを確認し、設定を見直してください。対応していないことをサブスクリプションの期限切れと誤認したり、クライアントが起動しただけでリモート接続も成功したと判断したりしないようにしましょう。

プロトコルと通信方式を項目ごとに理解する

VMess、VLESS、Trojanは接続設定におけるプロトコルの情報です。TCP、WebSocket、gRPCなどは通信の運び方を表し、TLSやREALITYなどは安全なハンドシェイクや関連する仕組みに関わります。これらは自由に入れ替えられる性能設定ではありません。リモート側の要件に合わせて、アドレス、ポート、ユーザーID、サービス名、パス、サーバー名などを正しく設定してください。VLESS自体が暗号化された通信を意味するわけではありません。必要な保護があるかどうかは、通信方式やセキュリティ設定を含めて確認してください。

ドメイン名に関する項目も、それぞれ役割が異なります。サーバーアドレスは最初に接続する宛先、TLSのサーバー名は証明書やハンドシェイクの処理に使われ、WebSocketのHostはリクエストヘッダーに含まれます。3つの値は同じ場合もあれば、異なる場合もあります。アドレスを名前解決できても、確認できるのは名前解決の結果だけです。ポートに接続できても、認証が成功したとは限りません。トラブル時は、名前解決、ネットワーク接続、安全なハンドシェイク、プロトコル認証、接続先へのアクセスの順に確認し、すべてを回線速度の問題として扱わないようにしましょう。

再現可能な確認環境を用意する

プロキシなしで日常的にアクセスできるサイトと、実際にプロキシが必要な接続先を1つずつ用意します。ほかの通信制御ツールを終了し、使用中のサーバー、システムプロキシの状態、ルーティングのプリセットを記録してください。同じブラウザーとネットワークを使い、設定を1項目だけ変更してログとアクセス結果を確認します。たまたまページが開いたかどうかだけで判断すると、キャッシュ、接続の再利用、アプリ独自の名前解決などが結果に影響します。設定を切り替えた後は、同じページを何度も再読み込みするより、新しい接続を開始したほうが変化を確認しやすくなります。

テスト結果から分かることには限界があります。リストに表示される遅延は、そのテスト方法で測った結果にすぎず、ダウンロード速度を直接示すものではありません。Webページにアクセスできても、リアルタイム通信、ゲーム、すべてのUDP通信が正常とは限りません。「接続できない」とだけ記録するより、どの段階で、どの種類のアプリから、どの接続先への通信が失敗したかを記録しましょう。以降の各章でも、まず前の段階が正常であることを確かめてから次の機能を追加します。異常が起きたら、直近の正常な状態に戻してください。

ステップ2 · ツールを選ぶ

クライアントとプラットフォームを選ぶ

デスクトップではまずv2rayNを検討する

Windows、macOS、Linuxでは、サブスクリプション、サーバー一覧、ルーティングをまとめて管理できるv2rayNをまず検討しましょう。ダウンロードページを開く前に、OSとCPUアーキテクチャを確認してください。同じOS向けでも、インストーラーが共通とは限りません。特にARMとx64は、アイコンだけを見て判断できません。条件ごとに比較したい場合は、まずクライアント選びガイドを確認してから、ダウンロードページで該当するものを選んでください。

Windows版には、デスクトップ版と従来のWPF版があります。デスクトップ版は新しいクロスプラットフォームのUIを採用し、WPF版は従来のWindowsらしい操作性を保っています。初めて使う場合は、デスクトップ版から試すとよいでしょう。すでに安定した運用方法がある場合は、画面や設定の違いを確認してから移行を検討してください。どちらも同じサービスを利用するクライアントであり、サービスの提供元が異なるわけではありません。トラブル対応のために両方を同時に起動すると、ローカルポート、システムプロキシ、設定フォルダーが競合することがあります。

システム情報に合わせてアーキテクチャを選択

Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認してください。PCのメーカー名だけで判断してはいけません。macOSでは「このMacについて」を開き、「Appleチップ」と表示される場合はApple Silicon用、「Intel」と表示される場合はIntel用を選択します。LinuxではCPUだけでなく、ディストリビューションがdebとrpmのどちらを採用しているかも確認してください。パッケージ形式とデスクトップ環境は必ずしも対応しているわけではありません。同じデスクトップ環境だからといって、別のPCと同じインストール方法を選ばないようにしましょう。

AndroidではXrayコアを使用するv2rayNGが第一候補です。V2Flyコアと同じ動作が必要な場合は、v2flyNGも検討してください。最近の一般的なスマートフォンにはarm64が適しています。アーキテクチャが分からない場合は汎用版を検討できますが、システム要件は別途確認してください。汎用版は、あらゆるプロトコルの組み合わせに自動対応するという意味ではありません。主に対応するCPUアーキテクチャの範囲を広げるためのものです。設定項目が似ていても、両アプリの機能対応が同じとは限りません。詳しくはXrayとV2Flyコアの比較を参照してください。

性能を予想する前に、選定条件を確認する

まず必須条件を整理します。接続先のプロトコルに対応しているか、サブスクリプション形式をインポートできるか、対象アプリにTUNが必要か、必要な権限を取得できるかを確認してください。条件を満たしたうえで、画面の使いやすさや日常のメンテナンスにかかる手間を比較しましょう。クライアントを変えてもリモート回線の品質は改善せず、画面を変えてもサービスの期限切れや設定ミスは解決しません。同じ設定を比較する場合は、ネットワーク、接続先、テスト時間をなるべくそろえ、回線の変動をクライアントの違いと誤認しないようにしましょう。

移行時は、現在使えている方法を残しつつ、複数のクライアントで同時に通信を制御しないようにしてください。サブスクリプションの提供元と必要なカスタムルールをバックアップし、新しいクライアントではインポート、サーバー選択、接続先へのアクセスを個別に確認してから、複雑なルーティングを移行します。PCとスマートフォンで同じサービスを利用する場合も、提供元が定める利用台数や同時接続の条件を守ってください。クライアント選びの完了は、アプリを増やすことではありません。メインで使うクライアント、復旧方法、設定の提供元を確認できる状態を決めることです。

ステップ3 · 初期設定を完了する

インストール、権限、初回起動

安定して使える場所に配置する

まずダウンロードページの該当プラットフォームからインストーラーを選び、システムの案内に沿ってインストールします。インストーラー版と展開して実行する版では、管理方法が異なります。圧縮ファイルを入手した場合は、長期間使うフォルダーにすべて展開してください。圧縮ソフトからメインプログラムを直接開いてはいけません。初回起動時に設定ファイルやログなどが作成されるため、実行フォルダーには書き込み権限が必要です。一時ファイルの削除対象になる場所は避け、同期ソフトから同時に変更される場所もできるだけ使わないようにしましょう。

Windowsの初回起動時に実行環境がないというメッセージが表示された場合は、エラー内容に記載されたコンポーネントとアーキテクチャを確認してください。見覚えのないポップアップから修復ツールをダウンロードしてはいけません。組織のポリシーで管理されている端末では、プロキシソフトの実行や仮想ネットワークアダプターの作成が許可されているか、事前に確認してください。通常のシステムプロキシは、常に管理者として実行しなくても利用できます。一方、TUNでは追加の権限が必要になる場合があります。通常起動と管理者権限での起動を分けて試すと、プログラム、フォルダーの権限、ネットワークドライバーのどこに問題があるかを切り分けやすくなります。

プラットフォームごとに起動時の問題を解決する

macOSでは、インストール後にアプリを安定したアプリケーション用フォルダーへ移してから起動します。セキュリティ警告が表示された場合は、ダウンロード元とOSとの互換性を確認し、システムに用意されたセキュリティ設定から対処してください。システム保護を無効にするコマンドを安易にコピーしてはいけません。Linuxでは、ディストリビューションのパッケージ管理ツールで依存関係を処理します。起動できない場合は、不足しているライブラリや実行環境についてのメッセージを確認してください。画面が表示されても、ネットワーク権限が使えるとは限りません。仮想ネットワークアダプターを利用する場合は、システムの許可方法も別途確認してください。

Androidにv2rayNGまたはv2flyNGをインストールして初回接続すると、システムのVPN接続許可が求められることがあります。これは端末の通信をアプリに渡すための入口であり、リモートサービスを利用できるという意味ではありません。許可内容を確認し、提供元が確認できているクライアントだけを許可してください。同じ入口を使うほかのアプリは、いったん無効にしましょう。画面ロック後にバックグラウンド制限で接続が切れる場合があります。基本的な接続が安定してから、端末のバッテリー設定でバックグラウンド実行の許可を調整してください。

ローカルの待ち受け設定と画面の状態を確認する

v2rayNのメイン画面で、サーバー一覧、サブスクリプショングループ、ログ、画面下部のステータス欄を確認します。設定をまだインポートしていない場合、一覧が空でも正常です。すぐにコアの設定を変更する必要はありません。「設定 → パラメーター設定」を開き、実際のローカル待ち受け設定を確認して、ポートと待ち受けアドレスを記録してください。設定によって入口が異なる場合があるため、アプリでプロキシを手動設定するときは、ここに表示される値を使い、解説記事でよく見かける数字を推測で入力しないようにしましょう。

ログにアドレスが使用中と表示された場合は、まずほかのクライアントを終了し、古いプロセスが残っていないか確認してください。ポートを手当たり次第に変更してはいけません。ブラウザーやほかのアプリが古いポートを参照したままになり、別の問題が起きることがあります。通常、待ち受けアドレスはローカルの範囲に設定します。LAN内で共有する必要が明確な場合に限り、待ち受け範囲を広げ、アクセス制御とファイアウォールも設定してください。ローカルの接続失敗を解決するために、PCのポートをネットワークへ公開するのは一般的な方法ではありません。

初回起動時の確認項目は3つです。画面が安定して開くこと、設定を保存できること、コアの起動エラーが続かないことです。この段階ではリモートの情報を設定していないため、すべてのサイトにアクセスできる必要はありません。ログの場所を把握するために、まずメイン画面の解説を読んでから、サブスクリプションの章へ進むことをおすすめします。インストール時に問題が起きた場合は、エラー文とシステムのアーキテクチャを記録し、明確な環境上の問題から解決してください。原因の切り分けをせずにOSを再インストールするのは避けましょう。

ステップ4 · 設定をインポートする

サブスクリプションの追加とサーバー管理

サブスクリプションURLと共有リンクを区別する

まず手元の情報の種類を確認します。サブスクリプションURLは、通常、サーバー一覧を取得するためのURLです。vmess://やvless://などで始まる文字列は、一般に個別の共有リンクです。完全なJSONはコアの設定ファイルの場合があります。どれも単なるテキストだからといって、同じ方法で扱えるわけではありません。通常のサブスクリプション更新機能では、完全な設定ファイルを読み込めない場合があります。共有リンクをサブスクリプションURLの欄に貼り付けるのも避けてください。

サブスクリプションURLには、サービスをすぐに利用できる認証情報が含まれている場合があります。アカウント情報と同様に大切に保管してください。URL全体を公開画像やフォーラム、速度測定の相談に貼り付けたり、見知らぬオンライン変換サイトに送ったりしてはいけません。情報を伏せて記録する場合は、プロトコルの種類、エラーの分類、必要な項目名だけを残してください。サービス提供元から新しいURLが届いたら、古いURLが無効になったかを確認してから登録元を入れ替えましょう。同じサービスを指すグループが重複するのを防げます。

グループを作成して設定を追加・更新する

1. 「サブスクリプショングループ → サブスクリプショングループ設定」を開き、提供元が分かる名前を付けて追加します。
2. 「任意のアドレス(URL)」にサブスクリプションURL全体を入力し、前後の空白、改行、コピー時の欠落がないことを確認します。
3. 「更新を有効にする」がオンであることを確認して保存し、「サブスクリプショングループ」メニューから現在のサブスクリプションを更新します。
4. 該当するグループに戻り、一覧とログを確認してから、使用するサーバーを選択します。

初回の更新では、サブスクリプションURLに直接アクセスできる場合、現在のプロキシを経由しない方法を選びます。URLへのアクセスにプロキシが必要な場合は、まず別の利用可能な接続を用意し、メニューからプロキシ経由での更新を選択してください。まだ正常にインポートできていないサブスクリプションを使って、自分自身をダウンロードしようとしてはいけません。更新エラーが出たら、名前解決の失敗、リクエストのタイムアウト、認証拒否、内容の形式が不明のどれかを確認します。原因を区別せずに削除して作り直すのは避けましょう。

サブスクリプショングループ → サブスクリプショングループ設定 → 任意のアドレス(URL) → 保存 → 現在のサブスクリプションを更新

更新によるローカル設定への影響を理解する

サブスクリプションは提供元の情報を同期したものであり、手動編集を続けるための唯一のコピーには向きません。提供元の更新により、サーバー名、アドレス、項目の順序が変わることがあります。サブスクリプション内の項目に加えた変更が上書きされる場合もあります。設定を試す場合は、項目を複製して用途を記録し、メインの登録元を直接編集しないでください。自動更新の間隔は必要に応じて設定します。頻繁に更新しても接続先が増えるわけではなく、提供元のアクセス制限にかかる可能性があります。

一覧が空の場合は、選択中のグループと画面の絞り込み条件を確認してから、更新ログを見てください。ログイン画面や案内ページが返ってきても、解析可能なサブスクリプションを取得できたとは限りません。期限切れ、アクセス制限、形式の非対応などが、インポート失敗の原因になります。特定のプロトコルの項目だけが表示されない場合は、クライアントとコアの対応状況を確認し、すべての設定をすぐに入れ替えないようにしましょう。サブスクリプション形式の違いや変換時の注意点は、サブスクリプション形式の解説を参照してください。

更新が成功しても、すぐに古い項目をまとめて削除しないでください。新しい項目を1つ選んで実際にアクセスし、以前使っていたサーバーが残っているか確認します。よく使うグループには分かりやすい名前を付け、有効期限と更新方法を記録してください。ただし、認証情報を名前に含めてはいけません。登録元が分かり、使用中の項目を特定でき、更新結果を確認できれば、その後のプロキシモード設定に進む準備が整います。操作手順だけを確認したい場合は、サブスクリプション追加の手順に戻ってください。

ステップ5 · アプリを接続する

システムプロキシと全体プロキシ

まず通常のアプリ用のプロキシ入口を設定する

使用するサーバーを選択したら、v2rayN画面下部のシステムプロキシ設定から「システムプロキシを自動設定」を選びます。OSがアプリに知らせるプロキシの入口を設定しますが、すべてのプロセスに従わせるものではありません。システム設定に従うブラウザーもあれば、独自に設定するアプリや、そもそもシステムプロキシを使わない接続もあります。まずシステム設定に従うブラウザーで確認し、その後に特殊なアプリを設定しましょう。最初からPC上のすべての通信が制御されると考えるより、確実に確認できます。

「システムプロキシをクリア」は、該当するシステムプロキシ設定を削除します。終了前に直接接続へ戻したい場合や、入口を調べる場合に使います。「システムプロキシを変更しない」は、クライアントがその設定を変更しないという意味であり、現在のシステムにプロキシが設定されていないとは限りません。以前設定した値が残っていれば、「変更しない」を選んでも古いポートを参照し続ける場合があります。終了後に通信できなくなった場合は、まずOSのプロキシ設定でアドレスとポートを確認し、クリアするか判断してください。クライアントを終了した状態で、アプリが無効な入口を参照し続けないようにしましょう。

全体ルーティングをすべてのアプリの通信制御と混同しない

V2Rayの全体プロキシという場合、どの範囲で全体なのかを明確にする必要があります。クライアントの全体ルーティングは、コアに届いたリクエストを優先してプロキシ経由で送ります。クライアントを経由していないアプリの通信経路は変わりません。システムプロキシは入口を設定し、ルーティングのプリセットは出口を設定します。それぞれ別に設定してください。全体ルーティングは、短時間のテストで分流ルールの影響を切り分けるのに便利です。長期間使う場合は、ローカルサービス、LAN内の機器、日常的な直接接続が必要な通信も考慮しましょう。

ブラウザーとほかのアプリを分けて確認する

ブラウザーにアクセスできない場合は、まずプロキシを制御する拡張機能を一時的に無効にし、ブラウザー独自の入口が設定されていないか確認してください。クライアントのログに新しい接続がまったく記録されない場合は、まず入口を調べます。リクエストが記録され、リモート側のエラーが出ている場合は、使用中のサーバーやハンドシェイクの設定を確認してください。テスト前に古いページを閉じるか、新しいセッションを開始し、古い接続を再利用しないようにします。通常のプライベートウィンドウでも、すべてのネットワーク設定が無効になるとは限りません。独立したプロキシ環境として扱わないようにしましょう。

コマンドラインや一部の開発ツールは、システムプロキシを使わない場合があります。ブラウザーでは接続できても、ターミナルでは失敗する場合、すぐに使用中のサーバーを変更しないでください。まずツール側のプロキシ設定を確認し、実際に待ち受けているアドレスとポートを指定します。HTTPプロキシの入口を、どの場面でもSOCKSプロキシとして使えるわけではありません。認証方式も一致させる必要があります。詳しい切り分け方法は、ブラウザーとターミナルの別々の確認方法を参照してください。この段階では、原因を絞りやすくするため入口を1つに保ちます。

最後に、終了後に復旧できることを確認します。システムプロキシをクリアして通常の直接接続に戻ることを確認し、クライアントを再起動してシステムプロキシを有効にし、目的のサイトへアクセスできることを確かめます。これで、設定の残留や起動順の問題を見つけられます。「有効にすると接続でき、無効にすると元に戻る」の両方を確認できたら、プロキシの入口設定は完了です。アプリが通常の入口を使えない場合は、PC全体のルーティングを変更するのではなく、TUNの章に進みましょう。

ステップ6 · 出口を調整する

ルーティングとDNSの連携

プリセットを使って動作の基準を作る

まずクライアントに用意されたルーティングのプリセットを使い、出所不明の大規模なルールを最初からインポートしないでください。「中国本土を迂回」は通常、該当地域のルールに一致するリクエストを直接接続し、それ以外をプリセットに従ってプロキシへ送る設定です。「全体」は、クライアントに入ったリクエストを全体向けのポリシーで処理します。プリセットのルールは変更される場合があるため、ルーティング設定を開いて実際の内容を確認してください。名前は概要にすぎず、すべてのLAN内の接続先、特殊なドメイン、アプリに適した設定がされているとは限りません。

コアは設定されたルールと照合順に従って出口を選びます。幅広いルールを先に置くと、後にある詳細なルールが適用されない場合があります。どのルールにも一致しなければ、既定の出口に送られます。調査では、一致したルールと、どのルールにも一致しない場合の動作を両方確認してください。リストにドメインがあるかどうかだけを見ても不十分です。ルールを追加する前に、対象のドメインやネットワーク、直接接続かプロキシか、例外が必要な理由、確認に使うリクエストを明確にしましょう。

ドメインルールとIPルールを分けて考える

ドメインルールは、クライアントが該当するドメイン情報を取得できることが前提です。IPルールは、接続先アドレスや名前解決の結果をもとに判定します。アプリがIPアドレスへ直接接続する場合、ドメインルールだけでは対象にならないことがあります。1つのドメインが複数のIPアドレスを使う場合、特定の1つのアドレスだけを設定しても安定しません。DNSはまず名前解決を行うものであり、すべての通信の出口を自動的に決めるものではありません。ルーティングのポリシー、名前解決のポリシー、接続時に実際に使われるアドレスを連携させる必要があります。「DNSを変えれば出口も変わる」と単純に考えないでください。

以下は、項目間の関係を説明するコア向けのルール例です。単独で起動できる完全な設定ではなく、サブスクリプションURLに入力するものでもありません。例示したドメインとそのサブドメインを、directという名前のアウトバウンドへ送ります。利用するには、そのアウトバウンドが定義済みである必要があります。GUIクライアントは設定を再生成する場合があるため、普段の設定はルーティング画面から行い、実行時ファイルを繰り返し編集しないでください。例示したドメインは説明用であり、実際のルールに常時追加すべきものではありません。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

特定の接続先からルーティングの問題を調べる

特定のサイトにアクセスできない場合は、一時的に全体ルーティングへ切り替えて、同じ接続先をテストします。全体ルーティングでは接続でき、元のプリセットでは失敗する場合、ルールへの一致、直接接続の経路、DNSを重点的に確認してください。どちらでも失敗する場合は、サーバーや接続先のサービスを確認します。切り替えるたびに新しい接続を開始し、古い接続で元の出口が使われ続けないようにしましょう。テスト中にDNS、サーバー、ルーティングを同時に変更すると、接続が復旧しても、どの設定が有効だったのか判断できません。

ルーターの管理画面、プリンター、ローカル開発サーバーにアクセスする場合は、プライベートIPアドレスやローカルドメインが正しく直接接続されるか確認してください。プロキシ経由の通信が、LAN内でしか使えないアドレスに接続しようとしても、通常はリモート側から到達できません。一方、LAN内の1つの接続先に対応するために、広い範囲のグローバルIPアドレスをすべて直接接続にするのも避けてください。スニッフィングは、一部の接続でドメイン情報の取得に役立つ場合がありますが、暗号化された通信をすべて認識できるとは限りません。アプリとの互換性も考慮し、必要な場合に有効にして確認してください。

ルールは必要最小限にし、目的を明確にします。カスタム項目には用途を記録し、無効になったドメインや条件が広すぎるルールを定期的に確認してください。ルールのデータを更新したら、重要な接続先を再テストします。ネットワークを切り替えたときは、まず名前解決とLAN環境を比較してから、長期的な設定を変更するか判断しましょう。この章の完了基準は、あるリクエストが特定の出口を使う理由と、どのルールにも一致しない場合の確認先を説明できることです。ルールの数を増やすことではありません。次にTUNを有効にするときも、この確認済みのルーティング設定を維持してください。

ステップ7 · 通信制御の範囲を広げる

TUNモードとネットワークの復旧

仮想ネットワークアダプターが本当に必要か確認する

システムプロキシを使わないアプリを接続したい場合や、より多くの種類の通信をクライアントに通したい場合は、v2rayNのTUNモードを検討してください。TUNは仮想ネットワークアダプターとシステムルーティングを通じて通信を取り込みます。サーバーの速度を上げる機能でも、無効な接続設定を直す機能でもありません。まず同じサーバーが通常のプロキシで利用できることを確認してから、TUNを有効にしましょう。通常のプロキシで接続できていない状態で仮想ネットワークアダプターを追加すると、権限、ルーティング、DNSなどの要因が加わり、問題の切り分けが難しくなります。

有効にする前に、現在使える設定を保存し、システムプロキシの状態を記録して、システムルーティングを変更するほかのツールを一時停止します。社内ネットワーク、リモート接続ツール、ほかの仮想ネットワークアダプターが、既定のルートやDNSを取り合う場合があります。遠隔デスクトップだけに頼っている場合、PC全体の通信を制御するテストを安易に行わないでください。ローカルで操作できる方法や、別の接続手段を用意します。管理対象の端末では、仮想ネットワークアダプターのドライバーや昇格した権限が禁止されている場合があります。権限の警告を何度も回避しようとするのではなく、組織のポリシーで許可されているか確認してください。

権限、ルーティング、名前解決の順に確認する

v2rayNのメイン画面で「TUNを有効にする」を選び、システムの案内に従って必要な権限を許可します。起動に失敗した場合は、権限不足、デバイス作成の失敗、アドレスの競合などがログに記録されていないか確認してから、該当する問題を解決してください。仮想ネットワークアダプターを作成できていない場合、サーバーを変えても通常は解決しません。アダプターは作成できてもすべての接続に失敗する場合は、システムルーティングが有効か、既定の出口が正しいか、DNSリクエストを処理できる経路があるかを確認します。設定名はプラットフォームによって異なることがあるため、実際の画面を確認してください。

初回テストでは、システムプロキシとTUNを同時に使って動作確認しないでください。クライアントの動作に合わせて、不要なシステムプロキシの入口を一時的にクリアし、もともとシステムプロキシを使わないアプリでテストします。ブラウザーだけで接続できる場合、ブラウザーが通常のプロキシを引き続き使っている可能性があります。接続ログ、接続先へのアクセス、終了後に元へ戻ることの3点を確認し、通信を取り込む経路が実際に動いているか確かめてください。UDPは、その機能に明確に依存するアプリでテストします。Webページが開いただけで対応を判断してはいけません。

LANや特殊なネットワークへの影響を確認する

プリンターの検出、LAN共有、仮想マシン、コンテナのネットワークは、ルーティングの変更によって影響を受けることがあります。ローカルサービスに接続できなくなった場合は、対象のアドレスとネットワーク範囲を確認してから、除外ルールを調べてください。すべての通信を直接接続に変更するのは避けましょう。DNSの処理経路が変わると、内部ドメインの名前解決に影響する場合があります。特に社内ネットワークでは、専用のDNSサーバーへ正しく接続できるようにしてください。公衆Wi-Fiの認証画面が表示されない場合は、通信制御をいったん無効にしてログインし、再び有効にして接続を確認します。

MTUを常に使える高速化設定として扱わないでください。基本的な接続ができていて、一部の通信で大きなパケットの転送が安定して失敗し、テスト結果から原因を判断できる場合に限って変更を検討します。数値をむやみに変えると、回線やプロトコルの問題を見えにくくする可能性があります。スリープからの復帰、Wi-Fiの切り替え、テザリングへの接続後に問題が出た場合は、まず接続をやり直すかTUNを再起動し、ルーティングの変化を比べてください。ネットワークごとの問題が同じ設定に起因するとは限りません。それぞれの環境を記録しましょう。

復旧する場合は、まずTUNを無効にしてクライアントを終了し、システムプロキシが残っていないことを確認してください。それでも問題が続く場合は、ほかのネットワークツールとシステムDNSの設定を調べ、必要に応じてネットワークに再接続します。判断せずにシステムのネットワークアダプターをすべて削除したり、ネットワーク設定全体をリセットしたりしないでください。普段使うアプリ、LANへのアクセス、スリープからの復帰、終了後の復旧をテストできれば、安定して使える状態です。通常のプロキシで必要な通信ができるなら、通常モードのまま使い、TUNは明確な用途があるときだけ有効にしても構いません。

ステップ8 · メンテナンスしやすい状態を保つ

更新、バックアップ、日常のトラブル対応

3種類の更新を分けて管理する

クライアント、コア、サブスクリプションの更新は別々に扱います。クライアントの更新は画面や設定管理に、コアの更新はプロトコル処理や動作に、サブスクリプションの更新はリモートの項目の同期に影響します。同じ更新ではなく、問題が起きたときに3つをまとめて更新する必要もありません。現在の正常な状態を記録し、必要なものを1つだけ更新して、接続を確認してから次へ進みましょう。問題が起きても、どの段階で変化したかを判断しやすくなります。

「更新を確認」などの項目を操作する前に、案内を読み、設定のバックアップを取ってください。インストーラーを入手する場合は、ダウンロードページで該当するプラットフォームを選びます。新機能を使うためだけに、唯一の作業用コピーを上書きしてはいけません。カスタムルーティングや複雑なDNS設定がある場合は特に注意が必要です。バックアップには、サブスクリプションの提供元、個別に登録したサーバー情報、ルール、必要な設定の説明を含めます。データフォルダーの場所はシステムやインストール方法によって異なるため、実際のクライアントにあるデータ管理の項目から確認してください。

コピーするだけでなく、復元できるバックアップを作る

設定ファイルには、ユーザーID、サブスクリプションの認証情報、接続パスワードが含まれている場合があります。アクセスを制限できる場所に保管してください。複数の端末で同期する場合は、同期サービスのアクセス権限を確認し、設定一式を公開共有フォルダーへアップロードしないようにしましょう。バックアップ後は、使用しているクライアントの種類と主な設定を記録し、復元時には別のフォルダーや管理された環境で検証します。実行ファイルをコピーするだけではユーザー設定は保存されず、画面のスクリーンショットだけでは非表示の項目を正確に復元できません。どちらも完全なバックアップの代わりにはなりません。

日常の管理では、最近動作を確認した設定と更新前のバックアップを1つずつ残せば十分です。認証情報を含む古いファイルを際限なくため込む必要はありません。別のPCへ移行するときは、まずサブスクリプションと使用するサーバーを復元し、その後にルーティングとTUNを追加します。システムプロキシ、ドライバーの許可、ローカルポートは端末ごとの環境です。設定ファイルと一緒に問題なく移行されるとは限りません。新しい端末で接続を確認してから、必要に応じて古い端末の許可を取り消すか、古い情報を削除してください。

ログから問題を絞り込み、再インストールを繰り返さない

V2Rayに接続できない場合は、発生時刻、対象アプリ、使用中のサーバー、プロキシの入口、直前の設定変更を記録し、同じ時間帯のログを確認します。名前解決に失敗した場合は、DNSとドメイン名を優先して調べます。接続拒否はポートやサービスの状態が原因かもしれません。安全なハンドシェイクのエラーでは、時刻、サーバー名、安全設定を確認します。認証エラーの場合は、認証情報を見直してください。ログに一度エラーが記録されても、サービス全体が使えないとは限りません。実際のアクセス結果と複数回のテストを合わせて判断しましょう。

速度が遅い場合は、段階を分けて確認します。まず同じグループ内の別の利用可能な接続先に切り替え、次に時間帯や接続先を変えて比較し、最後にPCのリソース、通信制御ツールの競合、ルーティング設定を確認してください。遅延が最小の接続先が最も高速とは限りません。リモート側での速度制限をローカルポートの問題と誤認しないようにしましょう。テスト結果を記録するには、速度が遅いときの段階的な確認方法を参照してください。1回のテストで変更する項目は1つにし、失敗したら元に戻します。検証していない高速化設定を積み重ねるより効果的です。

ログを共有する前に、サブスクリプションURL、ユーザーID、パスワード、アクセス履歴全体を伏せ、必要なエラー情報だけを残してください。一時的にログの詳細度を上げると調査に役立ちますが、詳細な記録を長期間続けると、ディスク使用量とプライバシー上のリスクが増します。確認が終わったら適切なレベルに戻しましょう。サービスの有効期限、自動更新の結果、バックアップから復元できることを定期的に確認してください。メインの接続先が使えなくなってから、元の情報を探すことのないようにしましょう。

日常のメンテナンスは、まず提供元が有効かを確認し、次に使用中のサーバー、入口とルーティング、システム環境の順にチェックします。再インストールは、プログラムや設定が実際に破損していて、復元に必要な情報がある場合に限って行ってください。あらゆるネットワークの問題に対する最初の手段ではありません。カスタム設定を必要最小限にして、それぞれの目的を把握しておけば、端末やネットワークを切り替えた後もすぐに復旧できます。

ステップ9 · 応用設定を学ぶ

応用設定の進め方と構成の確認

複雑な設定に進む前に、設定の構造を理解する

最初の8つの段階を終えたら、コアの設定にある入口、出口、ルーティング、DNS、ログの構造を学びましょう。目的はGUIをすべて手書きの設定ファイルに置き換えることではありません。生成された設定を読み、各設定が最終的にどこで使われるかを理解することです。GUIクライアントは実行用の設定を管理・生成するため、一時的に生成されたファイルを直接編集しても、再起動やサーバー切り替え時に上書きされる場合があります。ユーザーが保存する設定、カスタム設定、実行時ファイルを区別してから、変更する場所を決めましょう。

設定を読むときは、1つのリクエストがどのインバウンドに入り、どの接続先情報を持ち、どのルールを経て、最終的にどのアウトバウンドを選ぶかを追います。次に各名称の参照関係を確認します。特にルーティングルールで使用されているアウトバウンドのタグが、実際に定義されているか確認してください。構文が正しくても、用途に合うとは限りません。JSONを解析できても、接続先がその設定を受け入れるとは限りません。構文の検証、コアの起動、接続先へのアクセスを別々に確認すれば、「ファイルを保存できた」だけで正常と判断するのを防げます。

必要に応じてプロトコルとDNSを学ぶ

プロトコルは、まず現在使っているサービスに必要な機能から学びます。VLESSを使う場合は、ユーザーID、通信方式、セキュリティレイヤーの役割をそれぞれ確認してください。REALITYなどの機能が必要な場合は、提供元の要件に沿って個別に設定し、別の接続設定から項目を継ぎ合わせないようにしましょう。コアごとに対応範囲や既定の動作が異なる場合があります。移行前に実際の対応状況を確認してください。見慣れない項目は、まず該当するコアの説明を調べ、独立した設定で試します。メインの設定を直接上書きしないでください。

DNSを詳しく調べる場合は、名前解決の経路から確認します。どのコンポーネントが問い合わせるのか、直接接続とプロキシのどちらを通るのか、返されたアドレスがルーティングにどう影響するのか、アプリがシステムの名前解決を回避していないかを確認してください。暗号化DNSを有効にしても、プライバシーや接続性の問題がすべて自動的に解決するわけではありません。利用できるネットワーク経路が必要であり、社内ドメインと競合することもあります。DNSサーバー、ドメインのルール、ルーティング用のデータを同時に変更しないでください。使える状態を保ったまま、変更の影響を段階的に確認しましょう。

利用シーンごとに構成を確認する

確認対象をWebページ1つだけにしないでください。通常のブラウザー、個別にプロキシ設定が必要なアプリ、LAN内の接続先、実際に必要なUDP通信をそれぞれテストします。そのうえで、クライアントの終了、システムのスリープ、ネットワークの切り替え、再起動後も確認してください。各状況で、どの通信がプロキシを使い、どれが直接接続し、切断後に元の状態へ戻るかを明確にします。必要な場面をまだテストできていない場合は、未確認として記録してください。一度接続できたからといって、すべての状況で正常だと判断してはいけません。

複数の端末で使う場合は、各端末で正規の提供元から個別にインポートし、プラットフォームごとに動作を確認する方法を優先してください。ローカルの入口を共有する必要が明確な場合に限り、LANからの接続を受け付ける設定を検討します。待ち受け範囲を広げると、ほかの端末からプロキシサービスに接続できる可能性があるため、認証、ファイアウォール、ネットワークの信頼範囲、利用規約をあわせて考慮してください。「LANからの接続を許可」を日常的な高速化設定として使わないでください。信頼できないネットワークにローカルの管理インターフェースを公開するのも避けましょう。

問題に応じた記事を参照してください。画面の操作場所が分からない場合は、メイン画面の解説へ。インポートする情報が分からない場合は、サブスクリプションと共有リンクの形式へ。入口とルーティングを混同している場合は、本ページのプロキシモードとルーティングの章に戻ってください。このサイトには個別のQ&Aページはありません。よくある操作上の問題は、使い方ガイドの動作確認手順で調べてください。存在しないメニューやページを探す必要はありません。

設定全体のゴールは、内容を説明でき、同じ結果を再現でき、問題が起きたときに復旧できることです。設定の提供元や権限、アプリがクライアントに接続する経路、ルールが出口を選ぶ理由、更新に失敗した場合の戻し方を把握しましょう。メインで使う設定はシンプルに保ち、試行は独立した設定で行います。新しいプロトコル、ネットワーク、アプリに対応するときも、基本、入口、出口、確認の順に進めれば、すべての設定を最初から推測する必要はありません。