インストールガイド・プラットフォーム別

全プラットフォーム向けインストール・設定ガイド

このページでは、Windows、macOS、Linux、Androidの各章に分けて、パッケージの選択から接続トラブルの確認までを解説します。デスクトップではv2rayN、Androidではまずv2rayNGを使い、V2Flyコアが必要な場合はv2flyNGを確認してください。メニュー名は画面の更新により変わることがあります。設定の目的と、現在のパッケージに付属する説明を基準に探してください。

初めて設定する方や、まず接続までの基本手順を知りたい方はクイックスタートガイドをご覧ください。アーキテクチャ、権限、ルーティング、サブスクリプションの更新で困ったときは、このページの該当する章に戻って確認できます。インストーラーはクライアントのダウンロードページからOSに合わせて選んでください。サーバー設定やサブスクリプションURLは、クライアントに付属するものではありません。

事前準備と設定の基本

クライアント、コア、接続情報の違い

GUIクライアントはサーバー情報の保存、サブスクリプションの管理、設定の生成、動作状態の制御を担い、コアは設定に基づいて接続を処理します。v2rayNはデスクトップ向けの管理ツールです。対応するプロトコルは、実際に使用するコアによって異なります。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。同じ設定項目が表示されても、各コアがすべての拡張パラメーターに対応しているとは限りません。選ぶ前に接続情報の要件を確認してください。

クライアントをインストールしても、接続先サーバーが自動で用意されるわけではありません。信頼できる提供元のサブスクリプションURL、またはサーバーアドレス、ポート、ユーザーID、通信方式、安全設定を含む設定を準備してください。サブスクリプションURLにはアクセス権限が含まれることが多いため、パスワードと同様に慎重に扱いましょう。他の人に相談するときは、完全なURL、QRコード、ユーザーIDを公開しないでください。クエリパラメーターの一部が見えているだけでも、設定を読み取られるおそれがあります。

手動設定では、混同しやすい3種類のドメイン名を区別してください。サーバー接続先のアドレスは接続先を指定し、TLSのサーバー名は証明書とハンドシェイクに使われ、HTTPやWebSocketのHostは各トランスポート層で使われます。同じ値の場合もあれば、サーバー側で個別に指定される場合もあります。接続先アドレスが一般的なWebサイトの形式でないからといって、複数の項目を同じドメイン名に変更しないでください。

システムのアーキテクチャと保存先を確認

インストールパッケージは、OS、CPUアーキテクチャ、配布形式のすべてに合ったものを選びます。x64は主に一般的なIntel・AMD製デスクトップCPU向け、arm64は別の命令セット向けです。端末が新しいかどうかだけでは判断できません。Windowsでは「設定」の「システム情報」、macOSでは「このMacについて」、Linuxではコマンドでアーキテクチャを確認できます。AndroidでCPUの対応状況が不明な場合は、まず端末の仕様を確認し、必要に応じて汎用パッケージを検討してください。

クライアントには、長期的に書き込み可能な保存場所を選びましょう。展開が必要なパッケージは完全に解凍してから、展開先のフォルダー内で起動してください。圧縮ソフトの一時表示から直接実行するのは避けましょう。設定やログの保存先は、プログラムのフォルダーまたはユーザーデータフォルダーなど、配布形式によって異なります。アップグレード前に必要な設定をクライアントからエクスポートし、既存のデータ保存先も控えてください。プログラムだけをコピーして、サブスクリプションやルーティング設定を失わないようにしましょう。

プラットフォーム優先して確認すること初回設定時の注意点
Windowsx64、デスクトップ版、WPF版インストールまたは解凍を完了し、実行環境を確認
macOSApple SiliconまたはIntelアプリケーションフォルダーにコピーし、初回起動時の警告に対応
Linuxアーキテクチャ、debまたはrpm依存関係、デスクトップ環境、権限の付与方法を確認
Androidarm64または汎用パッケージ今回のインストールを許可し、VPNの承認を確認

再現可能なテスト環境を用意する

初回設定の前に、他のプロキシ、VPN、ネットワークを制御するツールを終了し、現在のシステムプロキシ設定をスクリーンショットで保存してください。既知のアクセス可能なサイトを開き、通常のネットワークが動作していることを確認します。システムの日付、時刻、タイムゾーンも正しく設定してから、設定をインポートしましょう。こうしておけば、問題が起きたときに元からあるネットワーク障害と、新しい設定による変化を切り分けられます。複数のネットワーク機能を同時に動かして、原因を推測し続ける必要もありません。

最初のテストでは、サーバーを1つ、通信の取り込み方法も1つだけ有効にします。デスクトップでは通常、まずシステムプロキシを試し、AndroidではVPNの使用を許可してください。カスタムDNS、複雑なルーティング、LAN共有はまだ追加しないでください。接続できたら機能を1つずつ追加し、変更するたびに同じアプリとアドレスで再テストします。変更内容、エラーの原文、発生時刻を記録しておくと、「有効にしたがつながらない」だけの記録より原因を特定しやすくなります。

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

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

Windowsのダウンロードページからv2rayNを選びます。デスクトップ版は複数のプラットフォームに対応したUIを採用し、従来のWPF版はWindowsデスクトップの操作感を維持しています。どちらも、現在のパッケージの説明で実行条件を確認してください。UIの違いは、サーバーを買い直す必要があることや、必ずプロトコルが異なることを意味しません。接続の互換性を決めるのは、使用するコアとサーバー設定です。

ダウンロードしたパッケージの形式に応じて、インストールまたは解凍してください。解凍して使う場合は、決まったフォルダーに配置し、パスをできるだけ短くして、現在のユーザーが書き込めるようにします。プログラム、コア、付属ファイルはすべて一緒に保管してください。初回起動時に実行環境がないと表示されたら、必要なコンポーネントとアーキテクチャを確認し、通常のソフトウェアのインストール手順で追加します。出所不明のサイトから同名のDLLを個別にダウンロードして、プログラムのフォルダーへ入れるのは避けてください。

起動できない場合は、「ウィンドウが開かない」状態と「ウィンドウは開くがコアが起動しない」状態を分けて確認します。前者では実行環境、ファイルの解凍状態、システムのセキュリティ履歴を確認してください。後者ではクライアントのログから、コアの不足、設定生成の失敗、ポートの競合を調べます。セキュリティソフトがファイルを隔離した場合は、ダウンロード元と検出内容を確認してください。手間を省くためにセキュリティ機能をすべて無効にするのは避けましょう。

サブスクリプションを追加し、ローカルの待ち受けを確認

サブスクリプショングループの設定を開き、グループを作成して識別しやすい名前を付け、完全なサブスクリプションURLを貼り付けます。保存しただけでは登録は完了しません。サブスクリプションを更新してください。更新後はサーバー一覧に戻り、接続先を1つ選んで有効にします。一覧が空の場合は、更新ログ、グループの絞り込み、URLが途中で切れていないかを先に確認してください。サーバー情報がない状態で接続を何度もクリックしても解決しません。

次に、設定画面でローカルの待ち受けポートと待ち受け方式を確認します。HTTP、SOCKS、混合方式の設定場所は、コアによって異なる場合があります。アプリにプロキシを手動入力する際は、対応するプロトコルを指定してください。ポート番号は画面に表示された値を使い、他人のスクリーンショットをそのまま真似しないでください。端末内だけで使う場合は、待ち受け範囲をループバックアドレスに設定します。LAN共有は初回接続に必要ありません。

画面下部のステータスバーまたはタスクトレイからシステムプロキシを開き、「システムプロキシを自動設定」を選びます。Windowsのシステムプロキシに従うアプリはローカルの待ち受けを使いますが、すべてのプログラムにプロキシを強制するわけではありません。まず既知のアクセス可能なサイトをブラウザーで開き、対応する接続ログがクライアントに表示されるか確認します。ブラウザーでは成功するのに特定のアプリだけ失敗する場合は、そのアプリがシステムプロキシを利用するか調べてください。

TUN、権限、終了後の復旧

システムプロキシを参照しないアプリの通信も取り込みたい場合に限り、TUNの有効化を検討してください。仮想ネットワークインターフェースとルーティングを使うため、通常は管理者権限が必要ですが、必要な権限はパッケージと起動方法によって異なります。まず他のVPNを終了し、通常のプロキシで接続できることを確認してから、クライアントの案内に従って権限を付与します。有効化後にすべてのネットワーク接続に問題が出たら、TUNを無効にして通信が戻るか確認し、DNSとルーティングを見直してください。

Windowsではポートの競合がよくある起動トラブルです。クライアントが複数起動していないか確認し、ログに記録された具体的なポート番号を調べます。以下のコマンドをターミナルで実行する場合は、ポートを設定画面の値に置き換えてください。これはポートの使用状況を調べるためのコマンドです。PIDからタスクマネージャーでプログラムを特定し、正体のわからないシステムプロセスを終了しないでください。

netstat -ano | findstr LISTENING

ウィンドウを閉じても、プログラムが終了したとは限りません。タスクトレイでクライアントが動作し続ける場合があります。完全に終了する前に「システムプロキシを解除」を選び、TUNを無効にしてからクライアントを終了してください。異常終了した場合、Windowsの設定が停止中のローカルプロキシを指したままになり、ブラウザーで何も開けなくなることがあります。システムプロキシを元に戻して通信が回復するなら、サブスクリプションの失効ではなく、残った設定の解除が必要な可能性があります。

スタートアップに登録する場合は、まず数回、手動で起動、接続、終了を試してから関連オプションを有効にします。ログイン直後はネットワークがまだ準備できていないことがあり、サブスクリプションの更新に失敗してもURLが無効とは限りません。少し待ってから手動で再試行し、ログを確認してください。デスクトップ版とWPF版をアップグレードまたは切り替える前にも、古いプロセスを終了します。複数のプログラムが同じポートやシステムプロキシを取り合うのを防げます。

macOSのインストールとネットワーク権限

チップに合ったパッケージを選んで初回起動

「このMacについて」でチップを確認してください。Apple製チップの場合はApple Silicon向けのarm64パッケージ、Intelプロセッサの場合はx64パッケージを選び、macOSのダウンロードページからv2rayNを入手します。Macのアーキテクチャに合った配布パッケージを優先し、互換レイヤーを日常的な設定の前提にしないでください。

ディスクイメージを開き、アプリを「アプリケーション」フォルダーにコピーしてから、コピー先で起動します。イメージ内のアプリを使い続けると、イメージの取り出し、ファイルの移動、アップグレード時に実際の起動場所がわかりにくくなります。初回起動をシステムにブロックされた場合は、まずファイルの入手元を確認してください。その後、「システム設定」の「プライバシーとセキュリティ」で該当する警告を確認し、システムの案内に沿って許可します。

一度の警告を回避するために、システム全体のセキュリティ機能を無効にしないでください。アーキテクチャ、ファイルの破損、権限に関する警告は、それぞれ別に対処します。アーキテクチャが違う場合は対応パッケージに変更し、コピーが不完全なら再コピーし、権限の問題なら現在のユーザーがアプリとデータフォルダーにアクセスできるかを確認します。組織管理の端末では、ネットワーク設定が管理ポリシーで制限されていることがあり、クライアントを何度再インストールしても解決しない場合があります。

サブスクリプションの追加とネットワーク接続

v2rayNを起動したら、サブスクリプショングループの設定でURLを追加し、保存してから更新を実行します。有効なサーバーを選ぶ前に、セキュリティ方式、トランスポートの種類、サブスクリプションで必要な項目が正しく読み込まれているか確認してください。特定のクライアント向けの拡張設定は、そのまま別のクライアントで使えるとは限りません。インポートはできても起動時にパラメーターエラーが出る場合は、すべてのオプションを有効にするのではなく、ログにある項目名を確認してください。

最初の接続テストではシステムプロキシを使います。macOSのプロキシ設定はネットワークサービスごとに管理されるため、Wi-Fi、有線ネットワーク、その他のインターフェースに個別の設定がある場合があります。自動設定後、現在使用中のネットワークサービスの詳細を開き、プロキシの状態を確認してください。有線から無線へ切り替えて動作が変わった場合は、サーバーやサブスクリプションを疑う前に、新しいネットワークサービスのプロキシ設定を確認します。

ブラウザーには独自の拡張機能や専用プロキシ設定がある場合があり、ターミナルのツールもシステムプロキシを使うとは限りません。検証には、まずシステム設定に従うアプリを選び、対象の接続がログに表示されるか確認してください。ターミナルのリクエストが一度失敗しただけで、システムプロキシの問題と判断しないでください。ツールが手動プロキシに対応している場合は、その指定方法に従ってローカルアドレスと待ち受けポートを入力します。

TUNの権限、スリープ、アップグレード

TUNは仮想インターフェースとシステムルートを扱うため、許可の方法はクライアントの配布パッケージによって異なります。基本のプロキシが使えることを確認してから、画面の案内に従って有効にしてください。管理者権限を求められたら、操作の要求元が起動したばかりのクライアントであることを確認します。出所不明のターミナルスクリプトを一般的な修復方法として使わないでください。すべてのプログラムを常に権限を昇格させて実行するのも避けましょう。

スリープからの復帰、テザリングへの切り替え、ネットワーク変更後は、以前の接続が応答待ちのまま残ることがあります。まず新しいネットワークが使えることを確認し、接続を再起動してください。必要ならTUNをいったん無効にして再度有効にし、インターフェースとルートを再構築します。特定のネットワークだけで失敗する場合は、他の設定を変えずに2つのネットワークでログを比較し、名前解決とハンドシェイクの段階を確認します。すぐに設定をすべて作り直す必要はありません。

アップグレード前に、残しておきたい設定をエクスポートし、現在のユーザーデータの保存先を控えてください。アプリを置き換えてもユーザー設定が消えるとは限らないため、アップグレード後に以前の設定が残っていても正常です。一方、アプリをゴミ箱に入れただけでは、ネットワークの取り込み設定が解除されない場合があります。アンインストールやアプリの変更前にTUNを無効にし、システムプロキシを戻してからアプリを終了し、現在のネットワークサービスのプロキシ設定も確認してください。

クライアント上では接続できているのに、管理対象のブラウザーでアクセスできない場合は、ブラウザーのポリシー、拡張機能、システムプロファイルで別のプロキシが指定されていないか確認してください。これらの設定は、通常のユーザー設定とは異なる優先順位で適用される場合があります。まずポリシーの適用元を記録し、端末の管理者に相談してください。影響範囲がわからないプロファイルを削除して試すと、業務ネットワークや他の管理対象アプリに影響するおそれがあります。

Linuxのインストールとデスクトップ環境

パッケージ形式、アーキテクチャ、依存関係を確認

Linuxでは、まずディストリビューションのパッケージ形式を確認し、次にCPUアーキテクチャを調べます。DebianやUbuntuなどでは通常deb、Fedoraなどrpmを使うシステムでは対応する形式を選びます。他のディストリビューションで異なる形式を無理にネイティブパッケージとしてインストールしないでください。Linuxのダウンロードページからv2rayNを選び、x64またはarm64を実際のマシンのアーキテクチャに合わせます。

次の2つのコマンドは、マシンの情報を確認するだけです。1つ目はアーキテクチャ、2つ目はディストリビューションの識別情報を表示します。一般にx86_64はx64、aarch64はarm64に対応します。ディストリビューション名だけでは依存関係が満たされるとは限りません。OSのバージョン、デスクトップ環境、パッケージ管理ツールが示す依存関係も確認してください。ファイルの拡張子が同じという理由だけで、必ずインストールできると判断しないでください。

uname -m
cat /etc/os-release

インストールには、ディストリビューション標準のソフトウェアインストーラーまたはパッケージ管理ツールを優先してください。依存関係やアンインストール情報をシステムで管理できます。依存関係が不足していると表示された場合は、エラー全文を保存して、ソフトウェアリポジトリとサポート対象のシステムを確認します。他のディストリビューションから共有ライブラリをむやみにコピーしないでください。GUIクライアントには利用可能なデスクトップセッションも必要です。ターミナルだけのサーバー環境は、ここで説明するGUIのインストール手順の対象外です。

通常のユーザーセッションで設定を追加してテスト

インストール後はアプリケーションメニューから起動し、通常のデスクトップユーザーとして設定を保存します。管理者アカウントでGUIを直接起動すると、別のユーザーフォルダーに設定が保存され、通常起動時に設定が「消えた」ように見えることがあります。その場合は実行ユーザーとデータ保存先を確認し、同じサブスクリプションを何度も追加しないでください。権限が必要なネットワーク操作はクライアントがサポートする方法で許可し、通常の設定とは分けて扱います。

サブスクリプションは、新しいグループの作成、URLの入力、保存、更新の実行、有効なサーバーの選択、という順で追加します。更新後はデスクトッププロキシを設定する前に、コアが正常に起動するか確認してください。Linuxではデスクトップ環境ごとにプロキシ設定の場所が異なります。デスクトップ設定を使うアプリ、環境変数を参照するアプリ、独自の設定が必要なアプリがあるため、「システムプロキシ有効」がすべてのプログラムに適用されるわけではありません。

まず、デスクトップのプロキシ設定に従うことがわかっているアプリでテストし、他のツールは個別に設定してください。待ち受けを確認する前に、すべてのシェル起動ファイルへプロキシ環境変数を書き込むのは避けましょう。新しいターミナルも、起動していないポートを参照し続ける可能性があります。以前にHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定した場合は、トラブルの確認時に大文字と小文字の両方、およびアプリ独自の設定も調べてください。

TUN、DNS、複数のネットワーク管理機能

TUNを有効にする前に、システムが必要な仮想ネットワークインターフェースを利用できるか確認し、クライアントログに表示される権限の案内も確認してください。環境によっては、権限昇格サービスやネットワーク管理ツールとの連携も必要です。権限エラーを解決するために設定フォルダー全体を全ユーザー書き込み可能にしないでください。エラーがプログラムの実行権限、データフォルダーの権限、インターフェースやルートの作成に必要なシステム権限のどれを示しているかを確認します。

Linuxでは、デスクトップのネットワーク管理、システムの名前解決サービス、コンテナネットワーク、他のVPNが同時に動作している場合があります。TUNを有効にした後、通常のネットワークに戻すとドメインにアクセスできる場合は、DNSが実際にどの経路で処理されているかを重点的に確認してください。システムが自動生成している可能性があるため、最初から名前解決の設定ファイルを上書きしないでください。変更してもすぐに書き戻され、問題を再現しにくくなることがあります。

次のコマンドでローカルの待ち受けを確認し、クライアントのポートが開いているか調べられます。待ち受けが確認できても、ローカルの接続口が用意されたというだけで、リモートとのハンドシェイクが成功したとは限りません。プロセス名の確認に権限が必要な場合でも、まずアドレスとポートを照合できます。さらに調べる必要がある場合は、システム管理のルールに従って権限を付与してください。この確認のためにクライアント全体を管理者として実行する必要はありません。

ss -lntp

終了前にデスクトップのプロキシ設定を元に戻し、TUNを無効にします。停止後も問題が続く場合は、クライアントが複数起動していないか、永続的な環境変数や他のネットワークサービスのルールが残っていないか確認してから、関連サービスを再起動してください。アップグレード後は、タスクトレイ、バックグラウンド動作、自動起動も再テストします。デスクトップセッションによってバックグラウンドプログラムの扱いが異なることがあるため、ウィンドウが閉じたかどうかだけでは動作状態を判断できません。

AndroidのインストールとVPNの許可

v2rayNGとv2flyNGを選ぶ

Androidのダウンロードページを開き、まずXrayコアを使用するv2rayNGを検討してください。接続情報でV2Flyコアが明示的に必要な場合は、v2flyNGを選びます。名前が似ていても、両クライアントがすべての拡張パラメーターに対応しているとは限りません。特にREALITYなどの設定では、コアの対応状況とサーバー側の要件を確認してください。未対応の項目を、スイッチを何度も切り替えて補うことはできません。

比較的新しい一般的な端末ではarm64を選べることが多いものの、最終的にはCPUとOSがサポートするアプリのアーキテクチャに合わせてください。インストーラーで非対応と表示された場合は、汎用パッケージを使うべきか確認します。ダウンロード後はシステムのファイルアプリからインストーラーを開いてください。提供元不明のアプリのインストールを許可するよう求められた場合は、今回使うブラウザーまたはファイルアプリだけに許可し、インストール後は必要に応じて許可を取り消します。

更新インストールで署名が一致しないと表示されても、すぐに既存アプリを削除しないでください。必要な設定をエクスポートし、旧アプリと新しいパッケージの入手元、アプリの識別情報、署名が同じ配布元のものか確認します。アンインストールするとアプリのデータが削除され、サブスクリプショングループや手動設定も失われる場合があります。別のクライアントへの移行に上書きインストールは使わず、それぞれが提供するインポート・エクスポート機能を利用してください。

サブスクリプションを追加し、システムVPNを設定

サブスクリプショングループの設定で名前とURLを追加し、保存後にメイン画面へ戻って更新を実行します。画面によっては、現在のプロキシ経由で更新する方法と直接更新する方法を選べます。まだ接続していない初回は、サブスクリプションURLに直接アクセスできるなら、直接更新を選んでください。URLへのアクセスに既存の接続が必要な場合は、先に使える設定を用意する必要があります。空のグループだけで接続が確立されることはありません。

一覧にサーバーが表示されたら、接続先を選んでから接続を開始します。Androidでは初回にVPN接続の確認画面が表示されます。許可すると、クライアントはシステムのVPNインターフェースを使って、選択したアプリの通信を取り込めるようになります。VPNのアイコンが表示されても、確立されたのはインターフェースだけで、サーバーへの接続成功を示すものではありません。ログと実際のアプリでのアクセスを確認してください。許可画面で承認していない状態では、サーバーを何度タップしても通信は取り込まれません。

Androidクライアントの通信取り込み方法は、デスクトップの「システムプロキシを自動設定」とは異なります。設定画面にアプリごとのプロキシ設定がある場合は、VPNを通すアプリと除外するアプリを選べます。モードによってチェックリストの意味が逆になる場合があるため、有効にする前に画面の説明を確認してください。初回テストでは範囲を初期設定のままにし、接続後にアプリを1つずつ除外します。テストに使うブラウザーを誤って除外しないようにしましょう。

バックグラウンド制限、ネットワーク切り替え、共有

しばらくすると接続が切れる場合は、まずバッテリー最適化、バックグラウンド動作の制限、省電力モードを確認してください。設定場所は端末メーカーによって異なります。アプリ情報画面から、バッテリーとバックグラウンドの権限を確認しましょう。このクライアントに関係する項目だけを変更し、画面ロックの前後でログが途切れるか観察します。すべての切断をバックグラウンド制限のせいにせず、プロセスが動作し続けてハンドシェイクに失敗する場合は、サーバー設定も確認してください。

Wi-Fiとモバイルネットワークを切り替えると、ローカルインターフェースは残っていても、既存の接続が無効になることがあります。新しいネットワークが完全に使える状態になってから、選択中のサーバーへ再接続してください。モバイルネットワークだけで失敗する場合は、サーバーとルーティングを変えずに、名前解決、IPv4・IPv6の到達性、ハンドシェイクエラーを比較します。原因を特定できなくなるため、トランスポート方式とセキュリティ設定を同時に変更しないでください。

「LANからの接続を許可」は別の機能です。他の端末向けにローカルのプロキシ待ち受けを公開する設定であり、スマートフォン自身のネットワーク接続に必要なスイッチではありません。有効にする場合は、待ち受けアドレスとポート、接続中のネットワークが信頼できるかを確認してください。スマートフォンのテザリングで他の端末の通信もVPNを通るかは、システムの実装によって異なります。スマートフォンが接続できたからといって、テザリング先も自動的にVPNを利用できるとは限りません。

接続を停止するときは、まずクライアント内で切断し、システムのVPN接続も終了したことを確認します。常時接続VPNやVPNを通さない接続をブロックする設定が有効だと、クライアントの停止後にシステムのポリシーでネットワークが遮断される場合があります。VPNの詳細設定で確認してください。サブスクリプションの操作手順を短く確認したい場合は、Androidのサブスクリプション追加ガイドもご覧ください。

サブスクリプションの整理と接続パラメーターの確認

サブスクリプションの更新とサーバー接続を分けて確認

サブスクリプションURLは設定を配布するための入口です。クライアントがURLにアクセスして初めて、サーバー情報を取得できます。更新に成功したということは、今回の取得と解析が完了したという意味であり、各サーバーが現在利用できるとは限りません。接続に成功しても、今後もURLへアクセスできる保証にはなりません。更新と接続は別の段階です。トラブルの確認では、サブスクリプションのダウンロード、内容の解析、コアの起動、リモートへの接続のどこで失敗したかを調べ、「インポート失敗」と一括りにしないでください。

接続元ごとにグループを作り、用途や提供元がわかる短い名前を付けます。グループ名にURL全体を含めないでください。URLを貼り付けるときは、前後の空白、改行、コピー時に混入した句読点を確認します。クエリパラメーターがあるURLは省略せずに残してください。URLの無効化、権限の変更、提供元からのWebページの返却などにより、クライアントがサブスクリプション以外の内容を受け取る場合があります。その場合は、サーバー一覧より更新ログのほうが原因を把握しやすくなります。

ブラウザーでページを開けても、そのURLがクライアントで読み取れる設定を返すとは限りません。アクセス方法によって返される内容が異なる場合や、アカウントの有効期限が切れている場合もあります。ログインページや共有ページのURLを、サブスクリプションURLとして使わないでください。提供元が複数の形式を用意している場合は、現在のクライアントが対応する形式を選びます。複数の場所から取得したサブスクリプションの内容を、1つのファイルに継ぎ合わせないでください。

接続とセキュリティのパラメーターを1つずつ確認

手動入力では、まずプロトコル、サーバーアドレス、ポート、ユーザーIDを確認し、次にトランスポートとセキュリティ層を確認します。VLESS、VMess、Trojanでは認証に使う項目が異なります。ある方式のパスワードを、別の方式のユーザーID欄へ入力しないでください。トランスポートもサーバー側の設定と一致させます。サーバーがWebSocketを使う場合、パスとHostの大文字・小文字、先頭のスラッシュも元の情報どおりに入力してください。

TLSのサーバー名は証明書の確認に使われ、画面ではSNIまたはサーバー名と表示されることがあります。REALITYの設定には、公開鍵、Short ID、フィンガープリントなどが含まれる場合があります。サーバーの情報を確認し、各項目を正しく入力してください。公開鍵をパスワードと取り違えたり、すべてのドメイン名をサーバーIPに置き換えたりしないでください。インポート後に必須項目が空欄の場合は、共有形式に互換性があるか確認してから、必要に応じて手動で補います。

パラメーター主な役割入力時によくある間違い
サーバーアドレス接続先のサーバーを指定共有リンク全体をアドレス欄に入力
ポートリモートサービスの接続口を指定ローカルの待ち受けポートを誤って使用
SNITLSのハンドシェイクと検証に使用証明書と関係のないドメイン名に変更
トランスポートのパス対応するトランスポートサービスを指定スラッシュを付け忘れる、または余分な空白を残す

共有リンクやサブスクリプションには、エンコードされたパラメーターが含まれる場合があります。テキストを直接編集すると、区切り文字やエスケープ文字を壊しやすくなります。通常はクライアントが対応する入力画面で編集し、変更前の設定もエクスポートして保存してください。プロトコルの仕組みを確認する場合は、VLESSの設定ガイドとREALITYパラメーターの解説を参照できます。実際に入力する値は、サーバーから提供された情報に従ってください。

更新、フィルタリング、バックアップの注意点

サブスクリプションを更新すると、サブスクリプションで管理されるサーバー情報が上書きされることがあります。手動で一時変更した内容を、長期保存の手段として使わないでください。カスタム項目を残す場合は、クライアントが対応する方法で別グループへ移動するか、バックアップをエクスポートします。更新後に選択中のサーバーが見つからなくなっても、提供元が削除または名前変更しただけの場合があります。接続異常と判断する前に、別のサーバーを選び直してください。

フィルタリングルールは一覧の表示に影響するため、リストが空でもサブスクリプションから情報が返されていないとは限りません。まず全グループに切り替え、キーワードフィルターを解除してから更新ログを確認してください。重複を整理するときも、表示名だけで判断しないでください。同じ名前でもポート、トランスポート、認証情報が異なる場合があります。整理の参考としてサブスクリプショングループとサーバーフィルターの設定メモを確認できます。一括操作の前には、復元できるエクスポートファイルを保存してください。

設定のバックアップは、保護された場所に保存し、公開用のスクリーンショットや問い合わせ内容と一緒にアップロードしないでください。エクスポートファイルには、サーバーの認証情報やサブスクリプションURLも含まれる場合があります。表示名を変更しただけでは、機密情報を消したことになりません。別の端末に復元した後は、ローカルポート、システムプロキシ、ファイルの保存先、権限を改めて確認してください。端末に依存する設定を、古いバックアップからそのまま引き継ぐことはできません。

システムプロキシ、TUN、ルーティング

通信の取り込み方法を理解してからモードを選ぶ

システムプロキシ、TUN、ルーティングルールは、それぞれ異なる層で動作します。システムプロキシは、設定に従うアプリへローカルポートにリクエストを渡すよう指示します。TUNは仮想インターフェースを通じて対象のネットワーク通信を取り込みます。ルーティングルールは、すでにコアに届いた接続の出口を決定します。ルーティングをどれだけ細かく設定しても、クライアントに届いていないアプリの通信が自動でプロキシされるわけではありません。トラブルを調べる際は、まずこの違いを理解してください。

デスクトップで普段Webを閲覧する場合は、まずシステムプロキシを使い、ページへのアクセスとログが対応していることを確認します。その後、必要に応じて他の通信も取り込みます。独自のプロキシ設定があるアプリでは、ローカルの待ち受けアドレスを直接指定する方法もあります。TUNはより広範囲の通信を扱えますが、インターフェース、ルーティング、DNS、権限も関係します。最初に試すべき方法とは限らず、サーバー設定の誤りを直すスイッチでもありません。

「グローバル」は通常、クライアントに入った通信の出口の選択方法を指します。端末上のすべての通信が取り込まれる保証ではありません。システムプロキシを使っている場合、グローバルルーティングを選んでも、プロキシを参照しないアプリは直接接続することがあります。逆にTUNを有効にしていても、ルーティングによって一部の接続を直接接続できます。通信の経路を判断するときは、取り込み方法、ルールの一致状況、実際の出口ログを合わせて確認してください。

ルールの順序とDNSの連携

ルールは通常、順番に照合されます。細かな動作は使用するコアによって異なります。具体的な例外ルールを広範なルールより先に置き、それぞれの目的を記録してください。ルールを追加したら、明確な対象で検証します。互いに上書きし合う複数のルールセットを一度にインポートしないでください。ドメインルールとIPルールは同じではありません。接続がコアに入ったときにドメイン名を取得できるかどうかで、適用されるルールが変わる場合があります。

以下は、プライベートアドレス範囲をdirectという出口へ振り分けるXrayルーティングオブジェクトの構造例です。完全な設定の一部として使うものであり、該当する出口ラベルが定義済みである必要があります。単独で起動できるクライアント設定ではありません。GUIクライアントが設定を自動生成する場合、生成ファイルへの直接変更は上書きされることがあります。まず画面のルーティング設定を使ってください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメイン名をどこで解決するかによっても、結果が変わります。アプリが先にIPアドレスへ変換する方法と、プロキシにドメイン名を渡して解決する方法は異なります。TUNではDNSも取り込まれる場合があり、ブラウザーの設定を変更しただけで名前解決の経路が変わったとは限りません。ドメイン名では失敗するのにIPアドレスへはアクセスできる場合は、実際の名前解決の経路とログを確認してください。すべてのDNSアドレスをすぐに変更せず、一度に1か所だけ変更すると比較しやすくなります。

LAN共有とアクセス範囲

他の端末と共有する場合は、まずPC本体で接続できることを確認してから、「LANからの接続を許可」または同等の待ち受け設定を有効にします。他の端末には、PCの現在のLAN内アドレスとローカルのプロキシポートを入力します。リモートサーバーのアドレスや127.0.0.1ではありません。ループバックアドレスは、そのアドレスを設定した端末自身を指します。スマートフォンに入力すると、スマートフォン上のサービスを探すことになります。

同じWi-Fiに接続していても、端末間の通信が許可されるとは限りません。ゲストネットワーク、クライアント間通信の分離、システムファイアウォールによって接続がブロックされる場合があります。まず両方の端末のネットワークセグメントとネットワークの種類を確認し、必要なプログラムまたはポートだけを許可してください。待ち受けを公開する場合は信頼できるネットワークに限定し、クライアントが認証に対応しているなら必要に応じて有効にします。テストのために、ルーターのポート転送を使ってローカルプロキシをインターネットに公開しないでください。

共有先の端末が対応するプロキシ方式も確認してください。端末の設定がHTTPプロキシにしか対応しない場合、SOCKS専用ポートを入力しても使えません。端末のプロキシ設定によっては、一部のアプリだけに適用されることもあります。共有をやめるときはLANの待ち受けを無効にし、他の端末に設定したプロキシアドレスも削除してください。端末側の設定手順はv2rayNのLAN共有メモを参照してください。共有の問題と、PCからリモートサーバーへ接続できない問題を混同しないようにしましょう。

よくある設定ミスと接続トラブルの対処

失敗した段階ごとに情報を集める

まず、サブスクリプションを更新できない、コアが起動しない、すべてのアプリで失敗する、特定のアプリや接続先だけ失敗する、のどれに当たるか整理します。最後に正常に使えた後で変更した項目と、現在の通信の取り込み方法も記録してください。ネットワークやサーバーを次々に変えながらDNSも変更すると、最初のエラーを再現できなくなります。確認中はテスト対象のアプリと接続先を固定しましょう。

クライアントのウィンドウが正常に表示されても、コアが正常に動いているとは限りません。ログで設定の読み込みやローカルの待ち受け開始を確認し、その後に最初に現れたエラーを探します。ポートの競合、未対応の設定項目、データファイルの不足、リモート接続のタイムアウトは、それぞれ別の問題です。起動エラーがある場合は、まずローカルの実行条件を修正します。すぐにサブスクリプションを変更する必要はありません。ローカルの接続口が正常になってから、リモート接続とアプリの通信経路を確認してください。

ログを確認する時間の範囲は、できるだけ短くします。テスト開始時刻を記録し、リクエストを1回実行してから、その直後の記録を確認してください。無関係な古いログが大量にあると、本当の最初のエラーが見つけにくくなります。調査のため一時的にログの詳細度を上げた場合は、原因を特定した後に通常のレベルへ戻してください。ログを共有する前に、サブスクリプションURL、ユーザーID、認証パラメーターを削除し、エラーの種類、発生段階、必要な環境情報だけを残します。

タイムアウト、接続拒否、証明書エラー

「接続拒否」は、指定のアドレスとポートで接続を受け付けるサービスが動作していない場合によく表示されますが、中継ネットワーク機器が原因のこともあります。「タイムアウト」は、応答を待つ段階で期待した応答がなかった状態で、原因はさまざまです。まず接続先アドレスとポートを確認し、次にローカルログで実際に接続している宛先を調べます。特定のネットワークだけで失敗する場合は、設定を変えずに別のネットワークと比較してください。すぐにプロトコルを変更しないでください。

TLS証明書またはハンドシェイクのエラーが出た場合は、まずシステムの日付、時刻、タイムゾーンを正しく設定し、SNI、サーバーアドレス、セキュリティ方式、トランスポートがサーバー側の情報と一致しているか確認します。ドメイン名が誤った接続先に解決され、証明書が一致しない場合もあります。「証明書を検証しない」に設定しても、パラメーターの誤りは直りません。認証機能も低下するため、日常的な回避策や既定の設定として使わないでください。

コアが設定項目を認識しない場合は、別のコア専用形式をインポートしていないか、クライアントで適切なコアが選択されているか確認してください。クライアントの更新とコアの切り替えは別の操作であり、どちらか一方で互換性の問題がすべて解決するとは限りません。エラーに表示された項目から必要な機能を確認して、クライアントを選びます。コアの違いはXrayとV2Flyの違い、具体的なハンドシェイクの問題はTLSと証明書のトラブル対処メモをご覧ください。

初期設定に戻して1項目ずつ再テスト

ブラウザーでは接続できるのに他のアプリで失敗する場合は、そのアプリがシステムプロキシを使うか、独自の設定があるか、アプリ別ルールで除外されていないかを確認します。一部の接続先だけで失敗する場合は、ルーティングルールの適用状況、名前解決、接続先の状態を調べます。そのためにクライアント全体を再インストールする必要はありません。システムプロキシでは正常なのにTUNで失敗する場合は、サーバーの認証情報よりも、仮想インターフェース、DNSの取り込み、ルートの競合、権限を優先して確認してください。

設定を戻す前に、現在の設定をエクスポートします。カスタムルーティングと追加のDNS設定を無効にし、TUNを停止して、明確な接続先を1つ選んだ状態でシステムプロキシをテストしてください。Androidではアプリ別の範囲を初期設定に戻し、VPNの使用を再許可します。一度に変更する項目は1つにして結果を記録します。基本の接続経路が正常になったら、元の順序で機能を1つずつ有効にし、どの設定で最初に問題が起きるかを特定してください。

クライアントを終了しても通常のネットワークに問題が残る場合は、まずシステムプロキシを元に戻し、常時接続VPNの設定を確認して、他のプログラムが通信を取り込んでいないか調べます。ネットワークが復旧したらクライアントを起動し、ローカルの待ち受けとリモートのハンドシェイクを確認してください。相談する場合は、OSとアーキテクチャ、クライアント名、通信の取り込み方法、個人情報を削除したエラー全文、試した手順を伝えます。「接続できない」とだけ表示されたスクリーンショットより、原因の特定に役立ち、すでに確認した項目を繰り返さずに済みます。

サブスクリプションの更新は成功したのに、サーバーへ接続できない場合は?

更新に成功したということは、サブスクリプションの取得と解析が完了したという意味です。まず接続先を選び、コアとローカルの待ち受けが正常か確認します。次に、実際のリクエストがクライアントに届いているか確認し、ログを見ながら接続先アドレス、トランスポート、セキュリティの設定を調べてください。

テスト後に元へ戻す設定は?

クライアントが設定したシステムプロキシを解除し、TUNまたはVPNを停止し、一時的なLAN待ち受けを無効にします。テスト中に変更したアプリのプロキシ設定と環境変数も元に戻してください。その後、通常のネットワークが使えることを確認し、日常的に使う設定だけを残します。