V2Ray クライアントのインストール・設定ガイド

事前準備：プラットフォーム・設定・接続方法

クライアント、コア、サーバー設定の違いを確認

V2RayはProject Vエコシステムにおける技術名称です。インストールや日常の操作には、主にGUIクライアントを使用します。デスクトップではv2rayN、AndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGを検討してください。クライアントは設定の保存、サブスクリプションの更新、設定画面を提供し、コアはプロトコル処理、接続、ルーティングを担います。クライアントをインストールしても、サーバーが用意されたり、利用可能なサブスクリプションが自動生成されたりするわけではありません。開始前に、設定の提供元から渡されたサブスクリプションURL、共有リンク、または完全な設定ファイルを用意し、対応クライアントを確認してください。

設定の互換性は、名称が似ているかどうかだけでは判断できません。VMess、VLESS、Trojanなどのプロトコルでは、それぞれに対応したフィールドが必要です。トランスポート方式とTLS設定も一致させてください。REALITYのパラメーターを含む設定では、使用するコアとその実装が必要な機能に対応しているか確認します。元の設定にあるセキュリティオプションを、別の方式へ安易に変更しないでください。クライアントに項目が表示されても、インポート処理が一部を読み取っただけで、コアがすべてのパラメーターを受け入れたとは限りません。形式の説明が不明確なサブスクリプションは、出力形式を提供元に確認してください。コアを何度も切り替えて推測するのは避けましょう。

システムのアーキテクチャとインストール先を確認

ダウンロード前にシステム設定でCPUアーキテクチャを確認し、対応するインストーラーを選びます。Windowsのダウンロードページではデスクトップ版と従来のWPF版、macOSではApple SiliconとIntel、Linuxではdeb・rpmとCPUアーキテクチャ、Androidではarm64と汎用パッケージを選択できます。アーキテクチャが合わないと、インストーラーが起動しない場合や、コアの起動時にエラーが発生する場合があります。デスクトップ版は、現在のユーザーが書き込める一般的なフォルダーに配置してください。圧縮ファイルのプレビューから直接起動したり、一時ダウンロード領域、同期エラーが頻発するフォルダー、読み取り専用の場所に実行フォルダーを置いたりしないでください。

ネットワークと設定情報を準備

プロキシを起動していない状態で、システムのネットワークから通常のサービスにアクセスできることを確認します。システムの日付とタイムゾーンも正しく設定してください。サブスクリプションURLは、クエリパラメーター、大文字・小文字、末尾の文字まで含めて正確に保存します。URLに含まれるアクセストークンは認証情報です。公開の掲示板などに投稿しないでください。トラブル対処のために記録するのは、クライアント名、システムアーキテクチャ、使用中のコア、エラー発生時刻にとどめ、サブスクリプションURL全体は記録しないでください。スクリーンショットを共有する場合は、サーバーアドレス、ユーザーID、個人アカウント情報を隠します。既存クライアントから移行する前に、エクスポート機能で設定を保存し、自分で管理できる場所にバックアップしてください。

システムプロキシ、TUN、VPNの違いを理解

デスクトップのシステムプロキシは、システム設定に従うアプリへローカルプロキシのアドレスを通知します。ブラウザーや一般的なデスクトップアプリに適しています。TUNは仮想ネットワークインターフェースを介して、より多くの通信を取り込みます。ルーティング、DNS、追加権限の設定も必要です。Androidクライアントは通常、システムのVPNインターフェースを使ってアプリの通信を取り込み、初回起動時にシステムの許可画面を表示します。これらは通信をコアに取り込む方法であり、コアがどの経路へ送るかとは別の設定です。初回は接続方法を一つだけ有効にして動作を確認し、必要に応じて追加してください。複数のプロキシツールによるネットワーク設定の競合を避けられます。

このガイドのメニュー名は機能を探すための目安であり、すべてのクライアントで表示が完全に一致するとは限りません。アップデートで画面の配置が変わる場合があります。「サブスクリプショングループ」「システムプロキシ」「ルーティング設定」など、機能名を手掛かりに探してください。ボタンの色や固定の位置には依存しないでください。ランタイム、権限、ドライバーに関する警告は、現在のリリースノートやシステムのダイアログを確認します。古いガイドに管理者として起動すると書かれていても、日常の操作すべてを高い権限で実行する必要はありません。事前準備ができたら、該当するプラットフォームの章に進み、別のシステム向け手順を流用しないようにしてください。

Windows：v2rayNのインストールとシステムプロキシ

デスクトップ版と従来のWPF版を選ぶ

Windowsダウンロードを開き、デスクトップ版と従来のWPF版のどちらかを選びます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のWindows向け画面を引き継いでいます。メニュー配置、設定項目、必要な依存関係が異なる場合があります。システムとの互換性と使い慣れた操作を基準に選び、2種類のプログラムを同じフォルダーに上書きしないでください。ダウンロードページには対応アーキテクチャ別の項目が用意されています。デバイスのアーキテクチャと一致しない場合は、最新のリリース情報を確認してください。Windowsという名称だけで、どのインストーラーもそのまま動作すると判断しないでください。

インストーラーを取得したら、ファイルの種類に応じてインストールするか、すべてのファイルを展開します。展開が必要なパッケージは、全フォルダーを解凍し、クライアントと同梱コアの相対的な配置を保ってから、展開先で起動してください。初回起動時にランタイムの不足が表示されたら、プログラムが示す環境名とアーキテクチャに合ったコンポーネントをインストールします。複数のランタイムを手当たり次第に追加しないでください。システムが起動をブロックした場合は、ファイルの入手元、システムが示す具体的な理由、ローカルの保護機能の記録を確認します。保護機能全体を無効にしないでください。画面は開くのにコアが動かない場合も、コアのファイルが所定のフォルダーに残っているか確認してください。

サブスクリプションを登録し、利用可能な設定を選ぶ

サブスクリプショングループの設定でグループを追加し、識別しやすい名前と完全なサブスクリプションURLを入力して保存します。グループの保存と内容の取得は別の操作です。保存後にサブスクリプションを更新し、設定が一覧に表示されるまで待ちます。共有リンクが1件だけの場合は、クライアントのクリップボードからのインポート機能を使えます。単一の設定を追加するために、リモートサブスクリプションを作成する必要はありません。インポート後、プロトコル、トランスポート、セキュリティ設定が提供元の説明と一致しているかを確認し、設定を一つアクティブにします。一覧をクリックしてハイライト表示しただけでは、アクティブな設定に切り替わっていない場合があります。クライアントの状態表示を確認してください。

サブスクリプション一覧が空の場合は、更新時の表示に接続失敗、認証失敗、解析失敗のいずれが含まれているか確認します。接続失敗の場合は、サブスクリプションの取得に直接接続と既存プロキシのどちらを使ったか確認してください。認証失敗ならURLの有効期限、解析失敗なら応答内容がクライアント対応のサブスクリプション形式かを確認します。同じ名前のグループを何度も作って解決しようとしないでください。重複が増えて原因が分かりにくくなります。利用可能な設定がすでにある場合は、予備として残し、新しいグループだけを確認します。設定をすべて削除して、接続手段を失う事態を避けられます。

システムプロキシを有効にし、必要に応じてTUNを使う

まずアクティブな設定を起動し、システムプロキシの自動設定を選びます。次にシステムプロキシの設定を開き、プロキシアドレスがクライアントの実際の待ち受け先を指していることと、ポートが一致していることを確認してください。HTTP、SOCKS、混合ポートは同じものではありません。アプリに手動設定する場合は、ポートの種類を合わせます。ブラウザーに独自のプロキシ拡張機能があると、システム設定が使われない場合があります。動作確認中は、その拡張機能によるプロキシ制御を無効にしてください。システムプロキシに従わないアプリも接続する必要がある場合は、TUNを検討します。有効にする前にシステムプロキシを解除し、二つの接続経路が重なることによる影響を抑えてください。

権限、終了時の復元、移行に対応

TUNでは権限の昇格やネットワークコンポーネントのインストールが必要な場合があります。クライアントの現在の案内に従って設定し、プログラム全体を常に管理者として実行しないでください。有効にした後、社内ネットワーク、共有フォルダー、プリンターに影響が出た場合は、まずTUNを無効にし、ルーティングの取り込み範囲が原因か確認してから、必要な直接接続ルールを追加します。別のVPNや社内接続ソフトを使っている場合は、一つずつ動作を確認してください。複数の仮想ネットワークアダプターが自動で連携するとは限りません。スリープ復帰後に不具合が起きたら、サービスを停止して再起動し、仮想インターフェースとDNSが正常に戻るか確認します。

通常終了する前に、クライアントのシステムプロキシ解除機能を使ってからプログラムを閉じます。クライアントが予期せず終了すると、システムにローカルポートを指すプロキシ設定が残る場合があります。その場合、ブラウザーは待ち受けが停止したアドレスへ接続しようとします。クライアントを再起動して設定を解除するか、システムプロキシの画面で状態を確認して元に戻してください。別のフォルダーへ移行する場合は、終了して設定をバックアップしてから、フォルダー全体を移動します。同じ設定フォルダーを共有するインスタンスを二つ起動しないでください。デスクトップ版の画面の違いはv2rayN Windows版のインストール・設定手順もご覧ください。トラブル対処には、現在のログを使ってください。

macOS：チップの選択、権限、ネットワークサービス

チップに合わせてv2rayNを選ぶ

システムの「このMacについて」でチップ情報を確認し、macOSダウンロードからApple SiliconまたはIntel向けのv2rayNインストーラーを選びます。購入年からチップを推測したり、ファイル名のアーキテクチャ表記を無視したりしないでください。ダウンロード後にディスクイメージを開き、パッケージ内の案内に従ってアプリを通常のアプリケーションフォルダーへ配置し、インストール先から起動します。ダウンロードしたディスクイメージをマウントしたまま使い続けると、アップデート、パスの参照、アンインストール時に混乱しやすくなります。

初回起動時、システムからアプリの入手元の確認を求められたり、起動をブロックされたりする場合があります。まずシステムが示す具体的な理由を読み、入手元とインストール手順を確認してから、システムが提供する一度限りの起動手順を使ってください。システム保護を一括解除するコマンドを使ったり、「入手元の制限」と「アプリが破損している」という警告を同じ問題として扱ったりしないでください。クライアント画面は正常でもコアが終了する場合は、アーキテクチャ、実行権限、ログに記録されたファイルパスを確認します。アプリのアイコンを何度もドラッグし直しても、コアの実行環境の不一致は解決しません。

サブスクリプショングループとアクティブ設定を作成

サブスクリプション管理を開き、専用のグループを作成してURLを入力し、更新を実行します。グループ名はローカルで識別するためのもので、リモートから取得する内容はURLとそのパラメーターで決まります。共有リンクをインポートする場合は、クリップボードにチャットアプリの説明、引用符、改行が混ざっていない完全なリンクだけが入っていることを確認してください。更新後にアクティブな設定を選び、コアが正常に起動することを確認してからシステムプロキシを設定します。デスクトップから移行した設定には、ルールファイルや証明書など別のシステム上のローカルパスが含まれる場合があります。パスをそのまま使わず、指定し直してください。

サブスクリプション更新時に使われるネットワーク経路は、クライアントの更新オプションとその時点の接続状況によって異なります。利用可能な設定がない初回起動時に、更新にプロキシが必要だと「設定が先か更新が先か」という循環が発生します。その場合は、提供元の案内に従って利用可能な初期設定を取得するか、現在のネットワークからサブスクリプションの接続先へ直接アクセスできるか確認してください。すでに接続できる状態なら、サブスクリプションを更新するために古い設定をすべて削除しないでください。更新後、アクティブな項目が残っているか確認します。リモート設定の名前が変わった後、代わりの設定が自動選択されない場合があります。

現在のネットワークサービスのプロキシ状態を確認

macOSのプロキシ設定はネットワークサービスごとに管理されます。クライアントでシステムプロキシを有効にした後、現在実際に使っているWi-Fiや有線接続などのネットワークサービスで設定を確認してください。ネットワークの切り替え、ドックの接続、サービス順の変更後は、以前のプロキシ設定が現在の経路に適用されなくなることがあります。ブラウザーがシステムプロキシを使うかどうかはブラウザー自身の設定にも左右されます。独自のプロキシ拡張機能を使っている場合は、個別に確認してください。まずシステム設定を参照するアプリで動作を確認してから、ほかのアプリを調べます。メニューバーのアイコンだけで、システム全体の通信が取り込まれていると判断しないでください。

システムプロキシが正常でも特定のアプリが直接接続する場合、そのアプリがシステム設定を無視しているか、独自のネットワークスタックを使っている可能性があります。より多くの通信を取り込む必要がある場合に限り、TUNを検討し、クライアントの案内に従って権限を設定してください。有効にする前に現在のプロキシとDNS設定を記録し、ほかのネットワーク制御ツールを停止します。管理対象のデバイスでは、ポリシーによってネットワーク設定の変更が制限されている場合があります。許可を何度も求めてもポリシー制限は解消しません。許可されたことだけではコアが通信を取り込んだとは言えないため、ログと実際のアプリのリクエストで確認してください。

スリープ、ネットワーク切り替え、終了後に残る設定に対応

スリープ復帰後に接続できない場合は、まずシステムがネットワークに接続済みか確認し、クライアントのサービスを停止して再起動します。ネットワーク切り替え後だけ失敗する場合は、プロトコルをすぐ変更せず、現在のネットワークサービスのプロキシ設定、DNS、古い接続が残っていないかを確認してください。通常終了する前にシステムプロキシを解除します。アプリが予期せず終了した後、ブラウザーにプロキシサーバーへ接続できないと表示される場合は、現在のネットワークサービスがローカルアドレスを指したままか確認します。設定を戻すときは、今回クライアントが変更した項目だけを元に戻し、社内ネットワークに必要な設定まで削除しないでください。

クライアントをアップデートする前に、サブスクリプショングループとカスタムルートを保存し、選択中のコアを記録します。アプリを置き換えたら、まず以前のシンプルな設定で動作を確認してから複雑なルールを戻してください。新しいプログラムが旧フォルダーを読み込めない場合は、設定の保存場所と現在のユーザー権限を確認します。キャッシュフォルダー全体をコピーすると、権限が引き継がれて問題になることがあります。トラブル対処では、アプリの起動、コアの起動、システムへの接続を分けて考えてください。アプリが開かない場合はシステムの警告、コアが終了する場合はログ、特定のアプリだけ失敗する場合はプロキシ経路を確認します。段階ごとに調べる方が、何度も再インストールするより原因を追いやすくなります。

Linux：パッケージ形式、デスクトッププロキシ、TUN権限

ディストリビューションとアーキテクチャに合うパッケージを選ぶ

Linuxダウンロードを開き、ディストリビューションに合わせてdebまたはrpmを選び、x64かarm64かを確認します。debはDebian、Ubuntuおよび関連ディストリビューション、rpmはFedoraなどでよく使われますが、同じ形式でも依存関係がすべて共通とは限りません。インストール前に、現在のディストリビューションのソフトウェア管理ツールが示す依存関係を確認してください。エラーを無視して起動を試さないでください。GUIクライアントにはデスクトップセッションが必要です。コマンドラインのみのサーバーはこのページの対象外であり、デスクトップの自動起動やシステムプロキシの手順をそのまま使うことはできません。

システムのGUIソフトウェアインストーラーでパッケージを開き、パッケージマネージャーに依存関係の処理とファイル登録を任せてください。依存関係が不足していると表示されたら、コンポーネント名とシステムのバージョンを記録し、現在のパッケージがそのシステムに適合するか確認します。入手元が不明な共有ライブラリをシステムフォルダーへコピーしたり、依存関係の不足と実行権限の不足を混同したりしないでください。インストール後、デスクトップのアプリ一覧からv2rayNを起動し、GUI、設定フォルダー、ログ機能が使えることを確認します。クライアントとコアの実行ファイルは、パッケージ内の所定の構成を保ってください。メインプログラムだけをデスクトップへコピーしないでください。

通常ユーザーでインポート・実行する

初回起動は普段使っているデスクトップユーザーで行い、サブスクリプショングループを追加して更新するか、共有リンクを一件ずつインポートします。設定フォルダーには現在のユーザーが書き込める必要があります。以前に高い権限で起動したため、一般ユーザーが編集できないファイルが残っている場合があります。保存に失敗したら、プログラム全体の権限を上げず、まずフォルダーの権限と空き容量を確認してください。アクティブな設定を選んだらコアのログを確認し、ポート競合、ファイル不足、未対応フィールドがないか調べます。デスクトップ版の設定画面はWindowsに近い場合がありますが、ローカルパス、権限、ネットワークの取り込み方法は別のプラットフォームと同じとは限りません。

カスタムルール、証明書、外部リソースファイルは、安定して参照できる場所に保存し、クライアントの設定から指定してください。リムーバブルストレージの一時パスや、別のPCからエクスポートした絶対パスをそのまま使わないでください。サブスクリプション内のリモートサーバーパラメーターは通常システムに依存しませんが、追加ファイルやローカルの待ち受け設定は環境に依存します。移行後に一つずつ確認してください。設定をインポートできても起動しない場合は、画面に表示された「起動失敗」の概要だけでなく、ログで最初に記録された明確なエラーを確認します。

デスクトップのシステムプロキシが適用される範囲を理解

Linuxのシステムプロキシはデスクトップ環境やアプリの実装によって異なり、すべてのプログラムが必ず従う一つのスイッチではありません。クライアントがデスクトップのプロキシ設定を書き込むと、ブラウザーはそれを使う一方、一部のアプリは独自設定や環境変数だけを参照する場合があります。検証時はブラウザー、対象アプリ、クライアントのログをそれぞれ確認してください。一つのアプリが使えただけで、すべての通信が取り込まれたと判断しないでください。対象アプリに手動プロキシ設定がある場合は、正しいHTTPまたはSOCKSの種類と、クライアントが実際に待ち受けているポートを指定します。環境変数とGUIのデスクトップ設定は別々に管理されている場合があります。

待ち受けの種類を確認する前に、同じアドレスをすべてのプロキシ欄へコピーするのは避けてください。HTTPプロキシ、SOCKS、混合ポートでは動作が異なり、UDPに対応するかどうかも接続方法やコアの設定によって変わります。ローカルプロキシには通常ループバックアドレスを指定します。一つのアプリに認識させるために、待ち受け先をすべてのインターフェースへ変更しないでください。LANから接続する設定は別途検討が必要です。認証、ファイアウォール、アクセス範囲も考慮し、一般的なデスクトップ導入の既定手順にしないでください。

必要な場合にTUNを有効にし、権限とポリシーを分けて確認

TUNは仮想ネットワークデバイス、ルーティングテーブル、DNSに関係し、必要な許可の方法はパッケージやシステムによって異なります。クライアントが提供する機能に沿って権限を設定し、アプリのフォルダー全体に広い権限を与えないでください。有効化に失敗した場合は、ログにデバイス作成、ルーティング操作、権限拒否のどれが示されているか確認し、システムのポリシー記録も調べます。ファイアウォールやシステムのアクセス制御がネットワーク接続に影響する場合も、具体的なルールを確認してください。すべてのポリシーを無効にしてはいけません。コンテナネットワーク、社内VPN、別の仮想インターフェースがある場合は、まず一つだけ有効にして最小構成で確認します。

デスクトップへのログイン時に起動する設定と、システムサービスは別のものです。GUIクライアントは通常、ユーザーセッションに依存します。自動起動を設定したら、ログアウトして再ログインし、動作を確認してください。常時高権限で動作するサービスとして登録しないでください。システム更新後にTUNだけが使えなくなった場合は、まず権限、仮想インターフェース、ルーティングの復元を確認し、その後にクライアントとの互換性を調べます。通常終了する前に接続設定を解除してください。再起動後も問題が残る場合は、システムに手動プロキシ設定が残っていないか確認します。トラブル対処の記録には、デスクトップ環境、ディストリビューション、アーキテクチャ、接続モードを含めると、アプリの問題とシステム環境の違いを切り分けやすくなります。

Android：設定のインポートとVPNモード

まずv2rayNGを検討し、必要に応じてv2flyNGを選ぶ

Androidダウンロードでは、Xrayコアを使う設定向けにv2rayNGを案内しています。V2Flyコアを使う場合はv2flyNGが選択肢です。名前が似ているから同等と考えず、設定のプロトコルとコアの機能を基準に選んでください。比較的新しい一般的なデバイスでは、まずarm64を検討します。アーキテクチャが分からない場合やインストーラーに非対応と表示された場合は、デバイス情報を確認して汎用パッケージも検討してください。CPUが対応していても、システムの実行環境まで同じとは限りません。最終的にはデバイスのシステムとインストーラーの要件に従ってください。

ダウンロード後、システムのファイルマネージャーでインストーラーを開き、案内に従って今回のインストールに必要な提供元の許可を行います。許可の対象はブラウザーやファイルマネージャーの場合があります。許可するアプリを確認し、無関係なアプリにインストール権限を与えないでください。インストール後にクライアントを開き、設定とログの画面を確認してから設定をインポートします。アップデート時に署名の不一致や上書き失敗が表示されたら、既存のグループと設定をバックアップし、旧アプリの入手元と新しいパッケージが一致するか確認してください。設定が旧アプリ内にしか保存されていないことに気付く前に、アンインストールしないでください。

サブスクリプション、共有リンク、QRコードをインポート

サブスクリプション管理でグループを追加し、完全なURLを入力して保存した後、更新を実行します。URLをコピーするときは、チャットの吹き出しに含まれる説明文を一緒に取り込まないようにしてください。提供元から共有リンクを受け取った場合は、専用のインポート機能を使います。サブスクリプションURLの欄に貼り付けないでください。QRコードは単一設定のインポートに便利ですが、読み取った後にプロトコルとパラメーターを確認します。貼り付けても項目が増えない場合は、クライアントの表示とクリップボードの内容を確認してください。重複を防ぐため、インポートを連続で押さないでください。更新が完了したらアクティブな設定を選び、接続を開始します。

v2rayNGとv2flyNGの間で移行する場合は、双方が対応する標準共有形式を使うか、提供元に対応するサブスクリプションを再発行してもらいます。一方のクライアントの内部データ全体を、もう一方のデータフォルダーへ上書きしないでください。同じプロトコル名でも、セキュリティパラメーター、トランスポート設定、コアの拡張機能が異なる場合があります。特定のコア機能を使う設定では特に注意してください。インポート後に一部の項目だけ表示される場合は、表示されない設定のプロトコルと形式を確認します。一覧の件数だけでリモートのサブスクリプションが完全かどうか判断しないでください。

VPNインターフェースを許可して接続を確認

初回起動時は通常、AndroidのVPN接続要求が表示されます。現在のクライアントが要求したことを確認してから許可してください。この許可でアプリがシステムのVPNインターフェースを作成できるようになりますが、リモート接続が成功したという意味ではありません。起動後、クライアントでコアが正常に動作しているかを確認し、実際に使うアプリで接続をテストします。ステータスバーにVPNアイコンが表示されても、インターフェースが接続状態にあることを示すだけです。リモートサーバー、DNS、ルーティングに問題が残っている場合があります。別のVPNが接続中なら、先に切断してからテストしてください。Androidが接続を切り替えたり、新しいインターフェースの作成を拒否したりすることがあります。

アプリごとのルーティングでは、どのアプリの通信をVPNインターフェースに送るかを指定します。「選択したアプリのみ許可」と「選択したアプリを除外」では、動作が逆になる場合があります。有効にする前に現在の画面の説明を読み、テストするアプリを選んでください。アプリの通信がインターフェースに入った後、直接接続かプロキシかはコアのルーティングで決まります。アプリを選んでも、すべてのリクエストが同じ出口を通るとは限りません。初回の確認では複雑なアプリの絞り込みを無効にして、シンプルな設定で全体が使えることを確認してから、一つずつ追加します。除外されたブラウザーを使っていると、サーバーの不具合と誤解することがあります。

バックグラウンド制限、プライベートDNS、ネットワーク切り替えに対応

画面消灯後に接続が切れる場合は、システムがクライアントのバックグラウンド動作、バッテリー使用、自動起動を制限していないか確認してください。設定の場所はデバイスによって異なります。固定のメーカー別手順を当てはめず、アプリのバックグラウンド実行権限を探してください。バックグラウンド動作を許可して再接続し、前景の状態通知が表示され続けるか確認します。クライアントが動作中なのにドメインへのリクエストだけ失敗する場合は、システムのプライベートDNS、クライアントのDNS、ネットワーク環境が競合していないか調べます。一度に変更する項目は一つにし、元の設定を記録してから、変更後に残すか判断してください。

Wi-Fiとモバイルネットワークを切り替えると、古い接続が使えなくなり、クライアントが再接続することがあります。一時的な再接続だけで設定ミスと判断しないでください。接続が戻らない場合は、まず接続を停止し、システム自体のネットワークが復旧してからサービスを再起動します。同じ設定が特定のネットワークだけで失敗する場合は、そのネットワークからサブスクリプションの接続先やサーバーにアクセスできるか確認し、具体的なエラーを提供元に伝えてください。終了時はクライアントのVPNを明示的に停止します。接続を長時間維持する場合は、システムの常時接続や接続遮断の設定も確認してください。クライアント停止後にシステムのポリシーで通信できなくなる場合があります。

サブスクリプション管理：形式、更新、設定の移行

サブスクリプションURL、共有リンク、完全な設定ファイルの違い

サブスクリプションURLは、設定一式をクライアントが取得するためのリモートの入口です。内容は提供元によって変更される場合があります。共有リンクは通常、単一の設定を表し、インポート後もリモート更新と連動するとは限りません。完全な設定ファイルには、インバウンド、アウトバウンド、DNS、ルーティングなど複数の項目が含まれることがあります。見た目だけで相互に置き換えることはできません。WebページのURLをサブスクリプション欄に入力すると、設定データではなくページ本文が取得される場合があります。完全なJSONを共有リンクとしてインポートしても、認識されないことがあります。受け取ったデータの種類を確認してから、対応する画面で読み込めば、多くのインポートエラーを防げます。

サブスクリプションのエンコードやコンテナ形式は外側の形式にすぎません。実際の互換性は、内部のプロトコルとフィールドによって決まります。デコードできてもすべての設定が起動できるとは限りません。変換しても、元データにない公開鍵、サービス名、パスを補うことはできません。変換が必要な場合は、提供元が明確で、管理された方法を優先してください。変換処理にサブスクリプションの認証情報が渡ることを理解しておきましょう。データの取り扱いが不明なツールに個人のサブスクリプションURLを入力しないでください。特定のコア機能に依存する設定では、まず移行先クライアントの対応状況を確認し、形式変換で無理に移行しようとしないでください。

更新の流れを4段階に分けて確認

サブスクリプションの更新は、URLの読み込み、ネットワーク要求、内容の解析、一覧への反映の4段階に分けて確認できます。URLを読み込めない場合は、空白、途中での切断、エスケープの誤りが原因として考えられます。ネットワーク要求の失敗は、DNS、接続経路、認証、サーバーの状態などを確認します。内容の解析に失敗した場合は、応答の形式が想定と異なっています。一覧への反映がおかしい場合は、絞り込み条件、重複ルール、現在のグループを確認してください。ログに全体的な失敗しか表示されないときは、より前の段階に具体的なメッセージがないか探します。エラーのたびにコアを変更するより、段階ごとに調べる方が効果的です。サブスクリプションの要求が、現在使用中のプロキシ接続を経由するとは限りません。

更新前に、クライアントが選択しているダウンロード経路を確認します。直接接続、現在のプロキシ経由、その他の方法など、選択肢は画面の表示に従ってください。現在の設定が使えず、サブスクリプション更新もその設定に依存していると、問題が重なります。正常に使える設定を一つ予備として残し、必要なら更新経路を先に復旧してください。認証に失敗した場合は、何度も短時間に更新せず、サブスクリプションがリセットされていないか、アカウント状態が変わっていないか、URLのパラメーターが完全かを確認します。要求が成功しても一覧が空なら、リモートに利用可能な設定が本当にない場合もあります。新しいグループを作り続けず、画面の案内を確認してください。

グループ、アクティブ設定、ローカル変更を管理

入手元ごとにグループを分け、自分で用途や提供元を識別できる名前を付けます。すべての設定をデフォルト一覧にまとめないでください。サブスクリプションの更新でリモート管理の設定が置き換わると、ローカルで変更した名前や一部のパラメーターが保持されないことがあります。長期保存が必要なカスタム設定は、クライアントの複製機能や独立設定の機能を使います。元のサブスクリプションに自動追従しなくなる点を理解してください。リモート設定の名前が変わったり削除されたりすると、以前のアクティブ設定が無効になる場合があります。更新後は選択中の設定が残っているか確認し、コアの状態も改めて確認してください。

データの種類	主な内容	移行時の確認ポイント
サブスクリプションURL	リモート設定へのアクセス先	URLの有効性とアクセス権
共有リンク	単一接続のパラメーター	移行先コアとフィールドの互換性
クライアントのバックアップ	グループとローカル設定	プラットフォームのパス、ポート、接続モード

移行時はデータを復元してからシステム接続を復元

新しいデバイスへ移行する際は、まず旧デバイスのデータをバックアップし、新しいデバイスで最小構成を作ります。サブスクリプションまたは共有設定を復元し、コアが起動することを確認してから、ルーティング、アプリの絞り込み、自動起動を戻してください。システムプロキシのポート、ネットワークインターフェース名、ローカルファイルのパス、権限はデバイス環境に依存するため、そのままコピーできません。環境が近い場合はクライアント全体のバックアップを復元できますが、コアの選択と接続設定は確認が必要です。同期ツールを使って新旧デバイスから同じアクティブなデータベースに同時に書き込まないでください。上書きやロックの原因になります。

サブスクリプションURL、エクスポートファイル、接続パラメーターが写ったスクリーンショットは、すべて認証情報として扱ってください。公開の場で助けを求める場合は、エラーの種類、プロトコル名、必要なフィールド構造だけを残し、ユーザーID、サーバー情報、アクセストークンを削除します。URLが漏えいした場合、投稿を削除しても認証情報は無効になりません。提供元の管理機能でリセットし、各デバイスに保存したURLを更新してください。よくある形式の問題はFAQをご覧ください。サブスクリプションと設定フィールドの違いは、用語集で確認できます。更新失敗と接続失敗を混同しないようにしましょう。

プロキシ・ルーティング：接続、経路制御、DNS

通信経路に沿って設定を理解

通信の経路は、アプリからのリクエストがローカルの入口に入り、コアがルールを照合して出口を選び、接続先へ送る流れとして理解できます。システムプロキシとTUNは前半の接続方法を決め、ルーティングルールは後半の直接接続、プロキシ、拒否のいずれかを決めます。クライアントに「グローバル」と表示されても、それがシステムプロキシの適用範囲を指すのか、取り込んだ通信をすべてプロキシの出口へ送ることを指すのか確認してください。画面によって名称が異なる場合があります。ローカルの入口に入っていないリクエストは、コアのルーティングモードを切り替えても自動的には取り込まれません。一部のプログラムが常に直接接続するのはそのためです。

一般的なブラウザーの利用なら、まずシステムプロキシを選びます。より多くのアプリやプロトコルを取り込む必要がある場合に限り、TUNを有効にしてください。システムプロキシ利用時にアプリがローカルアドレスを迂回する場合は、アプリ独自の例外リストが原因かもしれません。TUNで直接接続される場合は、コアのルールやネットワーク範囲の除外を確認します。まずリクエストがコアに届いているかを確認し、その後、どのルールに一致したかを調べます。問題がどの段階で起きているか分からないまま、TUNの有効化、DNSの変更、グローバルモードへの切り替え、サーバーの変更を同時に行わないでください。接続が復旧しても、何が効いたのか分からなくなります。

ルーティングルールは優先順位を確認

多くのルールは記載順に照合され、先に一致したルールが最終的な出口に影響します。LAN、特定サービスのドメイン、デフォルトの出口をそれぞれ明確な位置に設定してください。広すぎるルールを先頭に置くと、後続の細かなルールが適用されません。反対に、最後のフォールバック動作がないと、一致しなかったリクエストが想定外の出口へ送られる場合があります。以下はXray形式のルーティング例で、プライベートアドレスの直接接続と特定ドメインのサフィックス照合だけを示しています。完全な接続設定ではありません。既存のアウトバウンドに対応するタグが必要です。この断片をサーバー設定全体としてインポートしないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

例のdomain:example.comは、そのドメインとサブドメインへの一致を表します。実際の通信確認に使うアドレスではありません。directとproxyはアウトバウンドのタグで、実際の設定にあるタグと一致させる必要があります。プライベートアドレスの分類には、コアが該当するルールデータを読み込めることも必要です。GUIクライアントがタグやルールを自動生成する場合は、ルート編集画面の現在の仕様に従ってください。異なるコアの構文を混ぜて貼り付けないでください。変更前に古いルールを保存し、変更後は設定が起動することを確認してから、ルールの適用結果をテストします。

DNSの名前解決とドメイン照合の関係

DNSはドメイン名をIPアドレスに変換しますが、アプリ、ローカルシステム、コアを通過する間に、ドメイン情報が常に保持されるとは限りません。アプリが先に名前解決し、IPアドレスだけを送信すると、コアが元のドメイン名で直接照合できない場合があります。ドメイン情報を復元できるかは、接続方法と関連機能にも左右されます。DNSサーバーを選ぶ際は、そのサーバーへのアクセス経路も考慮してください。現在の経路から到達できないアドレスを唯一の名前解決先にしないでください。既知の接続は確立できるのにドメインが開けない場合は、プロトコルの非互換と決めつけず、まず名前解決の経路を確認します。

FakeDNSは仮想アドレスとの対応付けでドメイン情報を保持する機能で、通信の取り込みやドメイン情報の復元と連携して動作します。DNSサーバーのアドレスを変更するだけで単独動作するものではありません。有効にすると、LANサービス、アプリのキャッシュ、ネットワーク切り替えに影響する場合もあります。初回導入時に設定をそろえるためだけに有効化するのはおすすめしません。ドメイン単位のルーティングが必要な場合は、通常のDNS設定を記録してから、クライアントの対応方法に沿って設定し、動作を確認します。問題が起きた場合に元へ戻せる状態にしてください。仕組みと適用範囲はFakeDNSの仕組みを解説をご覧ください。

変更を絞ってルーティングを検証

一度に確認する対象アプリと接続方法は一つだけにします。リクエストがコアに届いていることを確かめてから、出口とDNSを調べてください。LANへのアクセスに問題がある場合は、プライベートネットワークの範囲と名前解決を確認します。リモートサービスに問題がある場合は、プロトコルとサーバーへの接続を調べます。ルールデータを更新する場合は、ルールリソースの更新とサブスクリプションの更新を区別してください。別々の操作です。XrayとV2Flyでは対応機能が完全には一致しないため、コアを切り替えたらカスタムルールを再確認します。エコシステムと機能の違いはXrayとV2Flyのコアの違いをご覧ください。名前を変えて互換性を試さないでください。

設定時によくある問題：発生段階から原因を特定

インストールの失敗とコアの起動失敗を分けて対処

インストーラーが起動しない場合は、システムのアーキテクチャ、パッケージ形式、インストーラーの案内を確認します。GUIは開くのにサービスが起動しない場合は、コアのログを調べてください。ポート競合、存在しないファイルパス、権限不足、未対応フィールドなど、コアが終了する原因はさまざまで、対処方法も異なります。ログでは最後の失敗概要より、最初に記録された明確なエラーが重要です。ポートが競合している場合は、古いインスタンスや同じポートを使用する別のプログラムがないか確認します。そのうえで競合するプログラムを停止するか、待ち受けポートを変更してください。変更後はアプリとシステムプロキシの設定も合わせる必要があります。更新しないと別の接続エラーが発生します。

未対応プロトコルやフィールドのエラーが出たら、まず設定が必要とするコアを確認してください。エラーに表示されたフィールドを安易に削除しないでください。セキュリティ関連のフィールドを削除すれば解析を通過できる場合がありますが、提供元の想定と異なる接続動作になる可能性があります。ファイルが見つからない場合は、インストール先、リソースのパス、保護機能の記録を確認します。権限エラーでは対象のファイルやネットワーク操作を調べ、プログラム全体の権限を一律に上げないでください。完全な設定ファイルでは、余分なカンマ、引用符の不一致、フィールドの型など、JSONの構文も確認します。エラーの分類についてはv2rayNのコア起動失敗ログを診断をご覧ください。

接続済みなのにWebページを開けない

「接続済み」は、コアまたはシステムの接続インターフェースが起動したことを示すだけで、すべてのリクエストが成功したとは限りません。まず実際に使うアプリの通信がローカルの入口に入っているか確認します。デスクトップではシステムプロキシとブラウザー独自のプロキシ設定、AndroidではVPNが動作中か、アプリが除外されていないかを確認してください。次に待ち受けポート、DNS、ルーティング、最後にリモート接続を調べます。ログに対象リクエストがまったくない場合は、まず通信の取り込みを解決します。リクエストがログに記録されているのにタイムアウトする場合は、出口、ネットワーク、サーバーを確認してください。前の段階を飛ばして、すべてをリモート側の障害と決めつけないでください。

一部のWebサイトだけ開けない場合、ドメインルール、名前解決の結果、接続先サービス、使用中のトランスポートが原因かもしれません。クライアント全体の障害とは限りません。同じアプリで接続先を変えて比較し、別のアプリから同じ接続先を試すと、アプリの設定と接続先までの経路を切り分けられます。短時間に複数の設定を切り替えず、接続やエラーが出るまで一つずつ待ってください。システムプロキシ、DNS、ルーティングの確認手順は接続済みなのにWebページが開けないときの確認リストをご覧ください。結果を記録してから次の変更を行い、一時設定が互いに上書きされないようにします。

サブスクリプション、ハンドシェイク、時刻に関する問題

サブスクリプションの更新に失敗した場合は、要求の経路と応答形式を確認します。リモート接続のハンドシェイクに失敗した場合は、サーバーアドレス、ポート、ユーザーID、トランスポートのパス、セキュリティパラメーターを確認してください。TLS関連のエラーでは、システムの日付とタイムゾーン、サーバー名のフィールドも調べます。検証を無効にして問題を隠さないでください。設定で必要なサービス名、ホスト名、サーバーアドレスは同じとは限りません。提供元の情報に従って一つずつ入力し、似た値を経験則で置き換えないでください。共有リンクのエンコード済みパラメーターを編集すると構文が壊れやすいため、まず元の完全なリンクを再インポートし、ローカルの設定と比較してください。

別のデバイスでは同じ設定が使えても、そのテスト条件ではリモート側が動作したことを示すだけで、手元のクライアントに問題がある証拠にはなりません。両方のデバイスでコア、システム時刻、接続方法、DNS、ネットワーク環境、アプリの絞り込みを比較し、条件をできるだけそろえてください。特定のネットワークでだけ失敗する場合は、サブスクリプションの接続先へアクセスできるか、どの段階でどのエラーが出るか記録します。再インストールは設定フォルダーの破損やインストーラーの異常を確認してから行います。ネットワーク経路やコアのエラーを調べる代わりにはなりません。分析せずに再インストールすると、同じ問題を再び読み込むことになりかねません。

アップデートのロールバック、ネットワーク復旧、効果的な問い合わせ

アップデート前に設定をエクスポートし、使用中のコア、接続モード、カスタムルートを記録してください。アップデート後はまずシンプルな設定で動作を確認し、その後に追加機能を戻します。ロールバックが必要な場合はバックアップを保管し、旧プログラムが新しい設定形式を読み込めるか確認してください。異なるプログラムから同じフォルダーへ交互に書き込まないでください。クライアントを停止した後もシステム全体で通信できない場合は、デスクトップにシステムプロキシが残っていないか確認し、次にTUN、VPN、手動DNSが解除されているか調べます。Androidでは、VPNが利用できないときに通信を遮断するポリシーが有効になっていないかも確認してください。復旧時は今回のクライアントに関係する項目だけを変更します。

問い合わせには、プラットフォーム、アーキテクチャ、クライアント名、選択中のコア、障害が起きた段階、直近の変更内容、機密情報を削除したエラー箇所を含めてください。特定のアプリだけで失敗するのか、ネットワーク切り替え後に起きたのか、クライアント停止後に復旧するのかを説明すると、「接続できない」だけの場合より原因を特定しやすくなります。サブスクリプション全体、接続用QRコード、未加工の設定ファイルを公開しないでください。修正後は同じ条件で再テストし、不要になった一時設定を解除します。最小構成で接続をやり直す場合はクイックスタートガイドへ戻ってください。概念やよくある症状を確認する場合はFAQをご覧ください。インストール、検証、トラブル対処を一連の流れとして進められます。