V2Ray総合ガイド
v2rayNのインストールと応用設定

基本概念：クライアント、コア、サーバーの違い

接続はどのような仕組みで成り立つか

GUIクライアントはサーバー情報の保存、サブスクリプションの管理、システムプロキシの設定を行い、選択内容をプロキシコアに渡します。コアはローカルポートで待ち受け、ルーティングを判定し、リモート接続の確立とプロトコル処理を担います。サーバーは接続先を提供し、クライアントと互換性のあるプロトコルやパラメーターが必要です。v2rayNをインストールしただけでは、利用可能なリモートサーバーが用意されたことにはなりません。また、サブスクリプションURLはソフトウェアのダウンロード先ではありません。

一般的な通信経路は次のとおりです。ブラウザーがシステムプロキシの設定を読み取り、リクエストをローカルの待ち受けポートに渡します。コアは宛先のドメイン名やIPアドレスに応じてルーティングを判定し、直接接続、プロキシ経由、または遮断を選択します。プロキシ経由の場合に限り、選択中のサーバーとプロトコルを使ってリモート接続します。トラブル時はこの経路を順に確認しましょう。ページが開かないからといって、すぐにサーバーの停止と判断するのは禁物です。ブラウザーがプロキシを使っていない場合と、リモート接続のハンドシェイクに失敗した場合では、問題の発生箇所が異なります。

Project Vはこのツール群の背景を理解するうえで重要です。V2FlyやXrayは関連するコアの系統で、v2rayNなどはユーザー向けのGUIクライアントです。名前は似ていますが、それぞれの役割は異なります。解説を読む際は、クライアントのボタン、コアの設定項目、サーバーの構築パラメーターのどれを扱っているのかを確認しましょう。コアのJSONをサブスクリプションURLとして読み込ませたり、クライアントのバックアップを別のアプリで読み込ませたりしても、期待どおりには動作しないことがほとんどです。

プロトコル、トランスポート、セキュリティ設定を揃える

VMessやVLESSはプロキシプロトコル、TCP・WebSocket・gRPCなどは通信を運ぶトランスポート方式、TLSやREALITYはそれぞれのセキュリティ設定に関わります。接続の成否はプロトコル名だけでなく、アドレス、ポート、ユーザーID、トランスポートのパス、セキュリティパラメーターが一致しているかどうかで決まります。サブスクリプションに記載された設定をそのまま使い、項目が新しく見えるからといって単独で変更しないでください。

接続先アドレスとSNI（サーバー名）は特に区別が必要です。接続先アドレスはリクエストの宛先を決め、TLSのサーバー名はハンドシェイクや証明書の検証に使われます。構成によっては両者が異なる場合があります。トランスポートで使うHost、パス、サービス名にもそれぞれ役割があり、サーバーの表示名を代わりに入力してはいけません。サーバー側で指定された値が必要な場合、入力漏れや誤入力でハンドシェイクに失敗することがあります。証明書検証を無効にしても、アドレスやサーバー名の誤りを一般的に解決できるわけではありません。

検証しやすい最小構成から始める

初期設定の目標は、できるだけ小さくしましょう。システムプロキシに従うアプリを1つ選び、動作が分かっている設定で、特定の宛先にアクセスできる状態を目指します。最初はTUNを有効にせず、複雑なルーティングを追加せず、DNSも同時に変更しないでください。基本経路が確立して初めて、後から設定するルールを比較できます。複数の設定を同時に変えると、たまたま接続が戻っても何が効いたのか分からず、次に問題が起きたときの判断材料が残りません。

使用中のクライアント名、OS、プロキシの入口、プロトコル、テスト結果を記録しておくと便利です。サブスクリプションキーや共有リンク全体を保存する必要はなく、再現に必要な条件を残しましょう。用語が分からない場合は用語ガイドで確認してから設定を変更してください。この章の完了基準は、アプリからコアへリクエストが入る経路と、現在の接続が直接接続かリモートプロキシ経由かを説明できることです。すべてのプロトコル名を暗記する必要はありません。

クライアント選び：デスクトップはv2rayN、Androidはコアの要件で選ぶ

OSとCPUアーキテクチャを先に確認

デスクトップではWindows、macOS、Linuxに対応するv2rayNを優先して選びましょう。ダウンロード前にシステム情報でCPUアーキテクチャを確認し、ファイル名の数字から推測してインストーラーを選ばないでください。一般的なx64はIntelまたはAMDの64ビット環境、arm64は対応するARM環境を指します。OSとアプリのアーキテクチャが合わないと、インストールできない場合や互換レイヤー経由で動作する場合があります。後者を初期設定の標準的な方法にするのはおすすめできません。

Windows向けのダウンロードには、デスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のWindows向け画面を引き継いでいます。使い慣れた操作方法や対象OSとの互換性を考慮して選びましょう。プロキシプロトコルが異なるわけではありません。メニューの配置、設定ディレクトリ、移行方法は両者で異なる場合があります。既存の設定がある場合は先にバックアップし、クライアントが提供するインポート機能を使って移行してください。プログラムのフォルダー全体を直接上書きしないでください。

macOSではApple SiliconとIntelでインストール先が異なります。「このMacについて」でチップまたはプロセッサー情報を確認できます。Linuxではアーキテクチャに加え、ディストリビューションのパッケージ形式も確認しましょう。DebianやUbuntuでは通常deb、Fedoraではrpmを使います。パッケージ形式はソフトウェアを管理する仕組みを表し、プロトコルの対応状況とは関係ありません。特定のプロトコルを使うために、別のディストリビューション用パッケージを無理にインストールしないでください。

Android向け2種類のクライアントの選び方

AndroidではXrayコアを使用するv2rayNGを第一候補にし、V2Flyコアを使う場合はv2flyNGを選択肢に加えましょう。サーバーの説明で特定のコア実装が必要とされている場合は、プロトコル名だけで互換性を判断せず、クライアントが該当するパラメーターに対応しているか確認してください。同じ共有リンクを読み込めても、拡張フィールドがすべて正しく反映されたとは限りません。読み込み後にセキュリティ設定やトランスポート項目も確認しましょう。

Android向けインストーラーにはarm64版と汎用版があります。比較的新しい一般的なスマートフォンならarm64版が候補ですが、最終的には端末の実際のアーキテクチャに合わせてください。確認できない場合はシステム情報を調べ、より幅広いアーキテクチャに対応する汎用版を選びます。クライアントを比較するときに、2つのアプリで同時にVPN接続を有効にしないでください。通常、この種の接続を同時に維持できるのは1つだけです。後から起動したアプリが先の接続を置き換えるため、テスト結果が不安定に見えることがあります。

サービス設定は共有し、クライアント固有の設定は分けて管理

デスクトップとAndroidで共有しやすいのは、対応しているサブスクリプションURLや個別サーバーの共有リンクです。一方、ローカルパス、プロキシの入口、ルーティング設定ファイルは、そのまま流用するのに向いていません。デスクトップのシステムプロキシ、AndroidのVPNインターフェース、デスクトップのTUNは、いずれも通信の入口に関わりますが、権限の仕組みは異なります。複数の端末に同期した後は、どれか1台で接続できたことだけを根拠にせず、端末ごとに入口、DNS、ルーティングを確認してください。

ダウンロード先はダウンロードセンターにまとめています。クライアントごとの違いはクライアント比較で確認できます。この段階ではメインで使うクライアントとインストール方法を1つずつ決め、コアは初期設定のままにしておきましょう。基本接続に問題がなく、明確なプロトコル互換性の要件もないなら、コアの切り替えを日常的な最適化として行う必要はありません。設定を見直しやすくするには、ツールを頻繁に変えるより、変更する要素を少なく保つのが効果的です。

インストール準備：起動を確認してからネットワーク権限を設定

インストール前に保存先、プロセス、既存設定を確認

インストール前に、実行中の同種プロキシソフトを終了し、通知領域やメニューバーに古いインスタンスが残ってシステムプロキシを変更していないか確認します。既存のv2rayNを更新する場合は、元のクライアントでシステムプロキシを解除して終了し、設定をバックアップしてください。プログラムの実行中にファイルを上書きしたり、新旧のインストール先を混在させたりしないでください。画面は新しくてもバックグラウンドのコアだけ古いまま、といった外から分かりにくい問題を防げます。

インストール先には、安定していて、現在のユーザーがクライアントの要件に応じて読み書きできる場所を選びましょう。一時的な展開先、外付けドライブ、自動削除されるフォルダーに長期間置くと、次回起動時に設定やルールファイルが失われることがあります。設定がプログラムフォルダーとユーザーデータフォルダーのどちらに保存されるかは、クライアントの「設定フォルダーを開く」機能や説明を確認してください。すべてのインストール方法で同じだと決めつけず、デスクトップのショートカットだけでなく実際のデータをバックアップしましょう。

初回起動では、メインウィンドウが正常に表示されるか、ログにエラーが繰り返し出ていないか、コアが起動できるかを確認します。この時点ではリモートサーバーを設定していないため、目的のサイトにアクセスできなくてもインストール失敗とは限りません。一方、実行環境の不足、ファイルの隔離、設定フォルダーへの書き込み不可は、ローカルのインストールに関する問題です。セキュリティソフトの警告が出た場合は、対象ファイルと処理内容を確認してください。問題を回避するために保護機能をすべて無効にするのは避けましょう。

必要な権限だけを各プラットフォームで許可する

Windowsでシステムプロキシを使うだけなら、通常、クライアントを常に管理者として実行する必要はありません。TUNを有効にする場合やネットワーク関連コンポーネントをインストールする場合は、画面の案内に従って権限を付与してください。起動のたびにポートが変わる、設定が消えるといった場合は、一般ユーザーと管理者の2つのインスタンスが同時に動いていないか確認します。権限を上げるとプロセスが参照する環境が変わる場合があり、「管理者として開けた」だけで問題が解決したとは限りません。

macOSで開発元を確認できないという警告が表示された場合は、システムの「プライバシーとセキュリティ」からブロックされたアプリを確認し、配布元を確認したうえで、システムの手順に従ってください。出所の分からないファイルのセキュリティ制限をまとめて解除しないでください。システムプロキシと、その後のネットワーク制御では異なる許可が必要になる場合があります。ウィンドウが開いてもネットワーク権限がすべて設定済みとは限りません。詳しくはmacOSのインストールとネットワーク権限を参照してください。OSのバージョンによって表示は多少異なります。

Linuxでは、debまたはrpmに対応するディストリビューションのパッケージマネージャーからインストールし、依存関係を管理できる状態にしましょう。コンポーネント不足の警告が出た場合は、インストーラーや起動ログを先に確認し、出所不明のライブラリを次々に手動コピーしないでください。デスクトップ環境のシステムプロキシ設定が、すべてのデスクトップ環境やコマンドラインツールに反映されるとは限りません。インストール成功はプログラムが起動できることを示すだけです。アプリがプロキシを使うかどうかは、後の手順で個別に確認しましょう。

最初のインストール状態を記録する

クライアントが起動したら、ローカルの待ち受けアドレスとポートを確認します。一般的な混合待ち受けポートは10808ですが、実際の設定を優先してください。以前の設定やカスタマイズによって変更されている場合があります。待ち受けアドレスはローカルの入口に接続できる範囲を決めるもので、個人利用なら通常はループバックアドレスのままにします。トラブル対処のためにLANへ公開しないでください。ポートが使用中の場合は、使用プロセスを調べ、重複インスタンスかどうかを確認してから終了またはポート変更を行います。

この章の終了時には、「起動でき、ローカルエラーが継続していない」設定を起点として保存してください。完全な接続を確認するまではTUNと自動起動を無効にしておきましょう。コアが起動しない場合は、ログからコアの起動エラーを特定する方法を参考に、ポート、設定構文、項目の互換性、ルールファイルの順に確認します。インストール中にリモート接続の設定まで変更すると、ローカルの問題とネットワークの問題が同じログに混在します。

サブスクリプションの追加：URL、共有リンク、設定バックアップを区別する

受け取った内容の形式を確認する

サブスクリプションURLは通常、アクセスするとサーバー情報を取得できる更新可能なURLです。個別の共有リンクには1つのサーバー接続情報が記載されます。クライアントの設定バックアップには、グループ、ルーティング、画面設定、ローカル設定などが含まれる場合があります。それぞれ追加する場所が異なります。受け取った内容を確認し、管理画面のURLをサブスクリプションURLとして登録したり、完全な設定ファイルをサーバー共有リンクとして貼り付けたりしないようにしましょう。

v2rayNでは、まずサブスクリプショングループを作成し、見分けやすい名前を付けてから、サブスクリプションURL欄にアドレスを貼り付けて保存します。グループ名はローカル管理用であり、URLの内容を修正するものではありません。貼り付け後は、前後の空白や改行、引用符、チャットアプリによる文字の置換がないか確認してください。URLには認証情報が含まれる場合があるため、機密情報として扱い、公開画像やログの共有、オンライン変換サービスへの貼り付けは避けましょう。

グループを保存したらサブスクリプションを更新し、ログとサーバー一覧に変化が反映されたか確認します。更新完了の表示は、クライアントが処理の一段階を終えたことを示すだけです。サーバー情報が実際に読み込まれたか、トランスポートやセキュリティ設定が維持されているかも確認しましょう。別グループのフィルターが選ばれていると、新しい項目が表示されないことがあります。すぐに削除して作り直さず、該当グループまたは全件表示に切り替えてください。

更新エラーはネットワークと内容の問題に分けて確認

ログにサブスクリプションのドメイン名を解決できない、接続がタイムアウトする、証明書エラーが出るといった内容があれば、まずサブスクリプションを取得する経路を調べます。端末がインターネットに接続できること、システム時刻が正しいことを確認し、更新リクエストに既存のプロキシが必要かを判断してください。初回設定で使えるプロキシがないのに、プロキシ経由の更新を必要とすると循環が起きます。利用可能な設定がすでにある場合は、クライアントの更新方法に応じてリクエスト経路を選びましょう。ボタンの名称だけから実際の通信経路を推測してはいけません。

リクエストに成功しても解析できない場合は、取得した内容がログインページ、エラーページ、または別のクライアント向け形式ではないか確認します。サブスクリプション変換サービスは接続情報を再生成できますが、クライアント固有の項目が失われることもあります。形式が本当に互換性の問題である場合に限り変換を検討し、配布元が提供する対応用URLを優先してください。解析エラーを解決するために、認証情報を含む元のサブスクリプションを、データの扱いを確認できないサービスに渡さないでください。

個別の共有リンクは、設定が明確な1つの接続を検証するのに適しています。まずクリップボードから読み込み、アドレス、ポート、プロトコル、ユーザーID、トランスポート、セキュリティ設定を順に確認します。QRコードは同じ種類のテキストを運ぶ方法の1つにすぎず、読み取りに成功しても接続設定が有効とは限りません。サブスクリプションから生成された項目を手動で変更する前に、次回更新で変更が上書きされるか確認しましょう。長期間残す変更は、手動のグループに分けて理由を記録してください。

使用するサーバーを選び、元に戻せる状態を保つ

読み込みが終わったら、対象サーバーを現在の接続先に設定し、メイン画面の状態とログに表示される設定の再読み込み結果を確認します。一覧にサーバーがあるだけでは、コアがそのサーバーを使っているとは限りません。遅延テスト、接続テスト、Webページの閲覧はそれぞれ別のものです。テストに成功しても、確認できたのはそのテスト経路に限られます。実際に使う前に、対象アプリで動作を確認しましょう。テストに失敗しても、すぐにすべてのパラメーターを変更せず、どの段階で失敗したのかを先に調べてください。

日常的に更新する前に、動作確認済みの設定をバックアップしてください。更新後は、現在選択中のサーバーを確認してから古い項目を整理します。唯一使える設定をバックアップせずにすべて削除しないでください。複数の端末で対応済みのサブスクリプションを共有する場合は、配布元の端末数や接続に関するルールを守り、ルーティングは端末ごとに管理しましょう。移行方法は複数端末でのサブスクリプション共有と設定のエクスポートを参照してください。この段階の完了基準は、パラメーターを確認済みで、選択済みかつ単独で検証できるサーバー設定があることです。

プロキシモード：アプリの入口を確認してから接続先の方針を判断

システムプロキシですべての通信を制御できるわけではない

v2rayNのシステムプロキシ設定には通常、「システムプロキシを解除」「システムプロキシを自動設定」「システムプロキシを変更しない」があります。自動設定では、システム側のプロキシをクライアントのローカル待ち受け先に向けます。解除は該当設定を取り消し、変更しない場合は現在のシステム設定を維持します。これらはアプリがプロキシを利用する入口を制御する設定です。ドメインごとに直接接続するかプロキシを使うかは、ルーティングや接続先の設定で決まります。

システムプロキシの影響を受けるのは、主にその設定を参照するアプリです。環境変数を使うコマンドラインツール、独自のプロキシ設定を持つアプリ、直接接続するプログラムもあります。そのため「ブラウザーは使えるがターミナルでは使えない」場合でも、サーバーに問題があるとは限りません。まず対象アプリがシステムプロキシに対応しているか確認し、アプリ内設定、明示的なプロキシ指定、TUNのいずれを使うか判断してください。入口の違いが分からないまま、リモートサーバーを次々に変更しないでください。

ブラウザー拡張機能がシステムプロキシを上書きする場合もあります。トラブル対処では、まずプロキシ関連の拡張機能を一時的に無効にし、ブラウザーに独自の設定が残っていないことを確認してから、システムプロキシで比較します。ブラウザーによって結果が異なる場合は、セキュアDNS、キャッシュ、拡張機能の動作も考慮してください。テスト環境がシンプルなほど、リクエストがコアに届いているか判断しやすくなります。複数のプロキシ管理ツールを同時に使うと、システム設定が互いに上書きされることがあります。

明示的なプロキシ指定でローカルの待ち受けを確認

現在の混合待ち受けポートが10808であることを確認できたら、次のコマンドでHTTPSリクエストを1回だけ明示的にローカルHTTPプロキシ経由で送信できます。接続先には例示用ドメインを使っているため、実行時にはネットワークからアクセスできる必要があります。コマンドの接続出力から、失敗がローカルの入口、リモート接続、接続先の応答のどこで発生したかを判断できます。1回の結果だけで、すべてのアプリの通信がプロキシ経由になったと判断しないでください。

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

コマンドを実行してすぐにローカルポートへの接続エラーが出た場合は、クライアントとコアが起動しているか、ポートが一致しているか、待ち受けアドレスがループバック接続を許可しているかを確認します。プロキシ接続までは進んでもハンドシェイクに失敗する場合は、サーバー設定、システム時刻、セキュリティ設定を調べてください。コマンドで接続先の応答を取得できるのにブラウザーだけ失敗する場合は、ブラウザーのプロキシ設定を優先して確認します。Windowsの一部のターミナルでは、同名コマンドによる引数の違いを避けるため、curl.exeを明示的に実行できます。

SOCKSを明示的に指定する場合は、名前解決の場所にも注意が必要です。対応するパラメーターを使ってcurlにsocks5h://127.0.0.1:10808を指定すると、ドメイン名の解決をSOCKSプロキシ側で行います。ローカルで先に名前解決してから接続する方法とは異なります。この違いはDNSの問題を切り分ける際に役立ちますが、すべてのアプリが同じ形式に対応しているわけではありません。アプリでアドレスとポートを別々に指定する場合は、各欄に分けて入力し、アドレス欄にプロキシURL全体を貼り付けないでください。

入口の方式とルーティングの方式を分けて記録

「全般」や「ルール」は接続先への通信方針を表すことが多く、システムプロキシやTUNは通信を取り込む入口の方式です。この2つは組み合わせて使えます。TUNを有効にしても、一部の通信を直接接続するルールを設定できます。システムプロキシだけを使う場合でも、コアに入ったリクエストをすべてプロキシ経由にできます。設定を判断する際は、「どのアプリの通信がコアに入るか」と「入った通信をどう送るか」を分けて明記しましょう。クライアントによって異なるモード名に惑わされにくくなります。

終了前にシステムプロキシを解除すれば、ローカルの待ち受けが停止した後もアプリが古いポートへ接続しようとするのを防げます。終了後にネットワークの問題が起きた場合は、まずシステムプロキシの設定が残っていないか確認し、ほかのプログラムがプロキシを設定していないかも調べてください。最初からネットワーク全体をリセットする必要はありません。基本接続が安定してから自動起動を設定し、システムがプロキシを使い始める前にコアが起動するか確認しましょう。手早く操作する方法は使い方ガイドのプロキシモード解説を参照してください。この章では、動作の違いが生じる理由を判断します。

ルーティング：ルールの順序、照合対象、DNS

シンプルなルールで動作を予測する

ルーティングの役割は、コアに入ったリクエストの接続先を選ぶことです。よく使われる接続先タグはdirect、proxy、blockで、それぞれ直接接続、プロキシ経由、遮断を表します。これらのタグは実際に定義された接続先に対応している必要があります。ルールは通常、上から順に確認し、最初に一致した処理を実行します。そのため、対象範囲の広いルールを先頭に置くと、後ろの細かいルールが適用されないことがあります。

初めて使う場合は、要件に合うルーティングのプリセットを選び、実際のルールを確認してから始めましょう。多数のルールセットをいきなり読み込む必要はありません。一般的には、プライベートアドレスを直接接続し、明示的に直接接続が必要なドメインやアドレスにdirectを指定し、それ以外は最後のフォールバックに任せます。広告の分類と遮断は任意の設定であり、接続の前提ではありません。追加後にログイン、画像、決済ページなどで問題が起きた場合は、依存するリクエストが誤って遮断されていないか、ルールの適用記録を確認してください。

以下はXrayのルーティングオブジェクトの一部で、照合順序を説明する例です。単独で起動できる完全な設定ではありません。同じ名前の接続先が定義済みで、geositeとgeoipのデータも用意されていることを前提にしています。この断片では最後のルールがTCPとUDPを対象とするフォールバックです。クライアントによってはプリセットなどでデフォルトの接続先が生成されます。既存の構成を理解せずに、機械的に追記しないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ドメインルールとIPアドレスルールは相互に置き換えられない

ドメイン名の照合には、ルーティングの段階で対象のドメイン名を取得できる必要があります。アドレスの照合は、実際の宛先IPアドレスや、ポリシーで許可された名前解決結果に依存します。アプリがIPアドレスへ直接リクエストすると、ドメインルールを使えない場合があります。反対に、ドメイン名のリクエストを受け取っても、すべてのドメインルールがその場で名前解決し、アドレスルールを確認するわけではありません。上の例はAsIsを使用しているため、地域分類を判定するために各ドメインを自動で名前解決する動作は期待できません。

geositeとgeoipは分類データであり、オンライン検索用のインターフェースではありません。ルールで認識できるかどうかは、コアの対応状況、ファイルの有無、データ内容によって決まります。分類が見つからない、ファイルを読み込めないというエラーが出た場合は、ルールデータと設定パスを確認してください。リモートサーバーを変更しても解決しません。分類と実際のサービスの提供地域が完全に一致するとは限りません。特定のサービスに明確な要件がある場合は、地域分類に頼りきらず、対象範囲の分かるドメインルールを追加しましょう。

DNSは名前解決で返されるアドレスを変えるだけでなく、その後のルーティング判定にも影響します。アプリ独自の暗号化DNS、システムの名前解決、コアのDNSが同じ経路を通るとは限りません。設定を変更する前に現在の名前解決方法を記録し、一度に1か所だけ変更して、名前解決が成功するか、接続先が変わるか、ルーティングが意図どおりかを確認しましょう。パブリックDNSを指定しても、必ず到達できるとは限りません。名前解決に成功しただけでリモートプロキシ接続も正常だと判断しないでください。

用途ごとにルールを検証し、変更範囲を絞る

検証では、直接接続するはずの宛先、プロキシ経由にする宛先、アクセスが必要なLAN内サービスを1つずつ選び、関連ログと実際の結果を確認します。ページが開いても分かるのはリクエストが完了したことだけです。接続確認ページだけを見て、アプリ内のすべての通信経路を判断することはできません。1つのページでも複数のドメインへアクセスし、本文、静的ファイル、ログインAPIが別々のルールに一致する場合があります。一部だけ失敗するときは対象を個別に調べ、サイト全体のルールをむやみに広げないでください。

カスタムルールには目的を明記し、適切な位置に配置してください。特定の業務用ドメインを修正する場合は、まず明確なドメイン範囲で検証してから、対象の拡大が必要か判断します。変更後は保存して再読み込みし、同じ宛先で再テストしてください。元のルールも残しておけば、必要なときに戻せます。用語を確認したい場合はDNS、ドメイン照合、接続先の解説を参照してください。応用とはルールを増やすことではなく、1つのルールがどのリクエストに影響するかを予測できることです。

TUN設定：通信の入口を広げ、ルーティングと権限を確認

TUNが本当に必要か判断する

TUNは仮想ネットワークインターフェースとシステムルートを使って通信を取り込みます。システムプロキシを参照しないアプリや、複数種類のネットワークリクエストを一括して処理したい場合に適しています。TUNが変更するのは通信をコアに取り込む方法です。サーバー設定の誤りは修正できず、すべてのプロトコルや宛先との通信が成功するとも限りません。システムプロキシで基本接続がまだ確立していない場合は、先に前の手順で検証を済ませてください。リモート接続と仮想ネットワークインターフェースの問題を同時に抱えずに済みます。

有効にする前に、現在使えるサーバー、ルーティングのプリセット、DNS設定、LANへのアクセス状況を記録し、無効にする場所も確認しておきましょう。リモートデスクトップや遠隔メンテナンス中は、ルーティングの変更で管理接続が切れる可能性があるため、特に注意が必要です。初回テストは端末を直接操作できる環境で行い、既存のネットワーク設定を維持してください。無線LAN、ゲートウェイ、サブスクリプション、コアを同時に変更しないでください。

有効化の際は、クライアントの要件に従って管理者権限や適切なネットワーク権限を付与し、インターフェースの作成、ルートの書き込み、権限の拒否に関するエラーがないか確認します。実装はプラットフォームやクライアントの機能によって異なる場合があるため、あるプラットフォームのドライバー手順を別のプラットフォームにそのまま適用しないでください。画面上でスイッチがオンになっていても、ログと対象アプリの動作で確認が必要です。スイッチの状態は設定の意図を示すもので、システム側の処理がすべて成功した保証にはなりません。

ループを防ぎ、LANの例外を確認する

プロキシコア自身がリモートサーバーへ送る通信を、同じ入口へ誤って戻すとループが発生します。通常、クライアントは対応するルートや除外設定を管理しますが、カスタムのシステムルート、ほかのVPN、セキュリティソフトが影響する場合があります。有効化後にログが繰り返し大量に出る、すべてのアクセスがすぐ失敗するといった場合は、まずTUNを無効にして元の状態へ戻し、競合するプログラムやカスタム設定を確認してください。再起動を繰り返して解決しようとしないでください。

ルーターの管理画面、プリンター、共有フォルダー、開発用サーバーなど、LANへのアクセスは個別にテストしましょう。プライベートアドレスを直接接続するルールは接続先の指定に役立ちますが、システムルート、DNS、アプリのデバイス検出には別の経路も関わる場合があります。ルールを1つ追加しただけで、すべてのLAN機能が復旧したと考えないでください。まず明確なLANアドレスでテストし、名前解決、接続経路、サービス側のアクセス制限のどこに問題があるかを調べます。

DNSの処理も、現在のクライアントの実装に合わせて理解する必要があります。システムのDNS経路を変更する設定もあれば、特定のリクエストだけを処理する設定もあります。アプリ独自の暗号化DNSを使っていると、さらに挙動が異なる場合があります。「IPアドレスではアクセスできるがドメイン名ではできない」場合は、まず名前解決を確認します。「名前解決できるのに接続できない」場合は、ルーティングとトランスポートを調べてください。現在のコアに対応していないDNS設定項目をコピーしないでください。項目名が似ていても意味が異なる場合があります。

UDP、スリープ復帰、他のネットワークツールは個別にテスト

アプリの通信がTUNに入っても、リモートサービスが必要なUDP通信にすべて対応しているとは限りません。音声通話やリアルタイム通信などは、サーバーの機能、トランスポート方式、ローカルネットワークの状態にも左右されるため、実際の利用環境で確認してください。ブラウザーが正常だからといって、リアルタイムアプリの不具合をクライアントの性能の問題と決めつけないでください。特定の種類の通信だけに問題がある場合は、使用プロトコル、宛先、接続先を特定したうえで、個別の直接接続や互換性設定が必要か判断しましょう。

スリープから復帰した後、ネットワークを切り替えた後、無線LANに再接続した後は、TUNが復旧しているか、システムDNSが使えるかを確認してください。企業VPNやほかの仮想ネットワークツールと併用すると、双方がルートを書き換えたり、起動順が結果に影響したりすることがあります。競合が確認できた場合は、通信を制御する方法を明確に1つ選び、除外設定を重ね続けないでください。この章の完了基準は、対象アプリが使え、LANへのアクセスが期待どおりで、TUNを無効にすれば元の状態に戻せることです。

日常メンテナンス：バックアップ、更新、ログの確認

設定のバックアップとサブスクリプション更新を別々に管理

サブスクリプションの更新で取得できるのは、配布元が提供するサーバー情報です。クライアント全体のバックアップの代わりにはなりません。ルーティングルール、DNS、プロキシの入口、グループ設定、手動で追加した項目は、サブスクリプションに含まれない場合があります。基本接続が安定したとき、重要なルールを変更したとき、アップグレード前に、それぞれバックアップを取り、OS、クライアントの種類、用途を記録しましょう。バックアップフォルダーをそのまま公開の同期サービスに置かないでください。サブスクリプションの認証情報や接続IDなど、機密設定が含まれる可能性があります。

復元する前に、対象クライアントがバックアップ形式に対応しているかを確認し、必要な内容だけを選んで復元します。プラットフォームごとのローカルパス、権限、待ち受け設定をそのまま流用しないでください。サーバーだけを移行する場合は、サブスクリプションまたは対応済みの共有リンクを使うのが適切です。クライアント全体の状態を復元する場合は、ルーティングとDNSも追加で確認してください。復元成功の表示はファイルを読み込めたことを示すだけです。実際の接続と、終了後にネットワークが復旧することもテストしましょう。

サブスクリプションの自動更新で手間を減らせますが、失敗しても既存の利用可能な項目をすぐに削除しないでください。エラーの原因と現在の接続設定が残っているかを確認してから、再試行するか配布元に確認しましょう。サブスクリプションから作成した項目を手動で変更している場合は、更新時の上書きにも注意が必要です。長期間維持したい特殊な設定は、画面のスクリーンショットだけでなく、変更箇所と理由を記録すると、移行や再確認が容易になります。

アップグレードでは変更する要素を必要最小限に

クライアントをアップグレードする前に終了してバックアップを取り、対象機能に関する変更点を確認します。特に設定形式、ルーティングデータ、権限要件に注意してください。クライアントの更新、コアの切り替え、サブスクリプションの変更、DNS設定の書き換えを同時に行わないでください。更新後に問題が起きても、変更要素が少ないほど原因を特定しやすくなります。元に戻す方法を確認してから旧環境を置き換え、更新後に動作せず、以前の設定も復元できない状態を避けましょう。

アップグレード後は、同じ宛先を固定して検証します。システムプロキシを使ったブラウザー、明示的なプロキシリクエスト、必要なLANサービス、実際に使うTUN対応アプリを確認してください。アップグレード前と同じ項目でテストし、画面が開くかどうかだけで判断しないでください。追加された機能だけが失敗する場合は、その機能を一時的に無効にして基本接続を維持できます。基本経路も失敗する場合は、ログを確認し、設定の互換性とローカルの実行環境を調べましょう。

自動起動は動作が安定してから設定し、GUIクライアントの起動、コアの起動、システムプロキシの自動設定を別々に考えてください。Linuxデスクトップの自動起動はユーザーセッションに依存します。詳しくはdeb/rpmでの導入と自動起動を参照してください。起動させるために、GUIアプリ全体を不適切な高権限サービスとして登録しないでください。権限と実行セッションが合わないと、設定フォルダーやネットワーク状態の違いが大きくなることがあります。

ログの前後関係を確認し、共有前に機密情報を削除

ログを調べる際は、問題が発生した時刻の近くにある最初の関連エラーを探し、その前の起動、設定の再読み込み、接続記録も確認しましょう。後から繰り返されるエラーは、同じ根本原因の結果である場合があります。接続拒否、タイムアウト、証明書の失敗、未知の項目は、それぞれ異なる原因を示します。すべてを一律にネットワークの不調と判断しないでください。調査時には直前に行った操作、対象アプリ、システムプロキシとTUNそれぞれの状態を記録しましょう。

一時的にログの詳細度を上げると原因を特定しやすくなりますが、確認後は通常のレベルに戻し、無関係な記録が増えすぎないようにします。外部に共有する前に、サブスクリプションURL、ユーザーID、サーバー情報全体、閲覧履歴などのプライバシー情報を削除し、エラーの種類と必要な前後関係だけを残してください。ログの時刻がシステム時刻と一致しているかも確認しましょう。変更のたびにバックアップとテストを行い、結果を記録し、失敗時に手順どおり戻せる状態になれば、メンテナンスの流れが整ったといえます。再起動後に一度接続が戻ったことを覚えているだけでは不十分です。

応用編：プロトコルとトラブル対処を問題ごとに学ぶ

手順を決めて段階的に確認する

応用とは設定を増やすことではなく、現象を適切な層に分類できることです。次の順に確認する方法がおすすめです。ローカルネットワークが使えるか、アプリがプロキシを使っているか、コアが起動しているか、サーバー設定が一致しているか、DNSが成功しているか、ルーティングが想定どおり適用されているか、最後に接続先サービス自体を確認します。各段階で判断を裏付ける観察結果を探し、未検証の推測で途中の確認を飛ばさないでください。

たとえばブラウザーでページが開かない場合は、明示的なプロキシリクエストを比較用に実行します。ローカルポートに接続できなければ、プロセスと待ち受け設定を確認します。ポートには接続できてもリモートのハンドシェイクに失敗するなら、プロトコル、セキュリティ設定、システム時刻を調べます。プロキシリクエストが成功してブラウザーだけ失敗するなら、拡張機能、独自のプロキシ設定、名前解決方法を確認してください。「接続できない」という同じ症状も、原因ごとに分けて調べれば、毎回クライアントを再インストールする必要はありません。

特定の宛先だけ失敗する場合も、複数の既知の宛先と比較します。すべての宛先で失敗するなら、共通の入口やリモート接続を優先して確認します。特定のドメインだけ失敗するなら、名前解決、ルーティング、接続先サービス、アクセス条件を調べましょう。1つのページに表示された地域に関する案内、アカウントの状態、サービス側の制限を、基盤のプロキシプロトコルの問題と混同しないでください。接続が確立したことと、サービスがアクセスを許可することは別の問題です。

実際の要件に沿ってプロトコルとコアを学ぶ

VLESSやVMessなどのプロトコルを学ぶ際は、まずサーバーとクライアントで一致させる必要がある項目を把握し、その後でトランスポート層とセキュリティ層の組み合わせを理解しましょう。プロトコル名だけで速度、安定性、用途が決まるわけではありません。具体的な構成や通信経路も重要です。ある環境で動作した組み合わせが、別の環境でも同じ結果になるとは限りません。プロトコル名だけでなく、実際の設定条件を保存してください。

コアを切り替える前に、現在のサーバー設定、カスタムルーティング、DNS項目が切り替え先のコアでサポートされているか確認します。クライアントの画面で一般的な操作を簡略化できても、すべての高度な設定が完全に同じ意味で使えるとは限りません。まず最小限の設定で基本接続を確認し、その後カスタム設定を1つずつ戻してください。未知の項目というエラーが出た場合は、対象コアの設定仕様に沿って修正します。項目名の大文字・小文字を次々に変えたり、エラーが出た行を削除したりして対処しないでください。

JSONを編集する場合は、括弧、カンマ、文字列の引用符、配列の構造を確認してください。JSONでは自由な形式のコメントは使えず、最後の要素の後に余分なカンマを置くこともできません。構文が正しくても、接続先タグが実在するか、ルールが参照するデータを読み込めるか、待ち受けポートが競合していないかを確認します。形式が正しいことは最初の段階にすぎず、起動できることも次の段階にすぎません。リクエストが期待どおりに処理されて初めて完了です。

個別の最適化を再現可能なテストにする

DNS、UDP、特定サービスとの互換性を調べる場合は、「このアプリはシステムプロキシを使わずに接続しているか」「このドメインは直接接続ルールに一致しているか」のように、毎回1つの問題を設定します。まず元の結果を記録し、関連する設定を最小限だけ変更して、同じ宛先で繰り返し検証してください。いわゆる最適化を一度に複数読み込むと、改善しても原因が分からず、悪化した場合に元に戻す範囲も特定できません。

テスト結果の適用範囲も理解しておきましょう。接続テストで分かるのは、その方法での結果に限られ、長時間の実利用を保証するものではありません。一度応答が速くても、後続のすべての通信で同じ結果になるとは限りません。家庭、モバイル、会社のネットワークではDNS、プロキシ、ルーティングの方針が異なる場合があります。ネットワークをまたいで比較するときは条件を明記してください。数値を追い求めて、実務に必要な安定した設定を壊さないようにしましょう。

最後に、自分用の操作メモをまとめましょう。起動と終了の方法、現在の入口とポート、直接接続が必要な宛先、バックアップの保存場所、問題が起きたときに確認するログを記録します。メイン画面の使い方が分からない場合はv2rayNのメイン画面と各機能を参照してください。基本の接続経路を作り直す場合は使い方ガイドに戻りましょう。総合ガイドの目標は、説明・検証・復旧ができる設定を作ることです。すべての高度な機能を同時に有効にすることではありません。