全プラットフォームの導入
とサブスクリプション設定

事前準備と設定の基本

クライアント、コア、サブスクリプション、システム側の通信制御は、それぞれ別の役割です。クライアントは画面表示やグループ管理、設定の生成を担い、コアは実際の接続とルーティングを処理します。サブスクリプションURLからサーバー情報を取得し、システムプロキシまたは仮想ネットワークインターフェースを通じてアプリの通信をコアへ渡します。この4つは個別に問題が起こり得ます。画面が開いてもコアが起動しているとは限らず、サブスクリプションの更新に成功しても、ブラウザーがプロキシを使っているとは限りません。

OS、アーキテクチャ、ダウンロード先を確認する

システムのデバイス情報を開き、OS、プロセッサのアーキテクチャ、空き容量を確認します。デスクトップPCは外観だけで判断しないでください。同じ機種でも搭載チップが異なる場合があります。クライアントのダウンロードページでプラットフォームを選び、対応するパッケージをダウンロードします。Windowsではデスクトップ版とWPF版で画面や操作方法が異なります。macOSはApple Silicon版とIntel版、Linuxはパッケージ形式も確認してください。

Androidでは、端末に適したarm64版を選びます。アーキテクチャがわからない場合は、汎用版の説明を確認してください。ダウンロードできても、OSが実行に対応しているとは限りません。最低動作要件はダウンロードページとインストーラーの表示を確認します。アーキテクチャが合わない場合は、ダウンロードページに戻って適切なパッケージを選び直してください。プロキシ設定を繰り返し変更しても解決しません。インストールの問題とネットワーク接続の問題は分けて対処します。

サブスクリプションURLと利用条件を確認する

利用中のサービスの管理ページから、サブスクリプションURLを省略せずにコピーします。アカウントが有効であること、プランの利用条件を満たしていること、登録端末数が上限を超えていないことを確認してください。このサイトでは設定方法を解説していますが、サブスクリプション情報は発行しません。URLにはアカウントの認証情報が含まれることがあります。公開の掲示板に貼り付けず、スクリーンショットを共有する場合もURL、QRコード、個人メモの機密情報を隠してください。

サブスクリプションURLと個別の共有リンクは別物です。サブスクリプションは通常、ネットワーク経由で複数の設定を取得します。個別の共有リンクには、1台のサーバーのパラメーターが直接含まれます。個別リンクをサブスクリプションURLの欄に貼ると形式エラーになることがあります。アカウント管理ページのURLを入力すると、ノード情報ではなくWebページが取得される場合もあります。サービスの管理画面でクライアント用と明記されたサブスクリプションの項目を使ってください。

URLの前後に空白、改行、日本語の句読点が混ざっていないか確認します。クエリパラメーター付きのURLは全体を保持してください。「?」より前だけをコピーしてはいけません。URLを短く見せるためにパラメーターを削除したり、サブスクリプションの認証情報をオンライン変換ツールに貼り付けたりしないでください。形式の変換が必要な場合は、提供元と用途を確認し、URL全体が第三者に送信されないかも確かめます。

一度に1項目だけ変更して検証する

システムの時刻自動設定を有効にし、日付とタイムゾーンが正しいことを確認します。証明書の検証や一部のプロトコル認証では正確な時刻が必要です。接続エラーを解決するために時刻を手動で進めても意味はありません。現在のネットワークでログイン認証が済んでいることも確認してください。ホテル、学校、ゲスト用ネットワークで認証ページを通過していない場合、クライアントではタイムアウトとして表示され、サブスクリプションやサーバーの問題に見えることがあります。

ほかのプロキシや仮想ネットワークインターフェースを使用するツールを一時停止し、元の設定を記録しておきます。初回の検証では、クライアント1つ、サーバー1つ、通信制御方式1つに絞ってください。まずサブスクリプションを追加してコアの起動を確認し、次にシステムプロキシを有効化します。TUNは最後に試します。問題が起きたときに、どの手順で結果が変わったのか特定しやすくなります。

用途が明確なテスト先を2つ用意します。1つは直接接続する日常的なサイト、もう1つは現在のルールでプロキシ経由になるサービスです。ブラウザーにキャッシュ済みのページが表示されても、接続が正常とは限りません。テスト時はページを再読み込みし、クライアントのログでリクエストを確認します。ノード横のテスト結果だけで全アプリの状態を判断しないでください。通常、特定の疎通確認リクエストの結果しか示しません。

職場のネットワークや組織管理端末の利用条件も確認してください。管理対象の端末では、ローカルプロキシ、ネットワーク拡張、管理者権限が制限されている場合があります。明確なポリシー制限がある場合は、端末の管理者に相談してください。制限を回避するためにシステム保護を無効化してはいけません。以降の各プラットフォームの章では、ダウンロード、インストール、追加、通信制御、動作確認の順に説明します。各段階を確認してから次へ進んでください。

Windows：v2rayNをインストールする

Windowsでは、まずプラットフォーム別ダウンロードからv2rayNを選びます。デスクトップ版はクロスプラットフォームの画面を採用し、WPF版は従来のデスクトップ操作を引き継いでいます。使い慣れたほうを選べばよく、サブスクリプションを追加するために両方をインストールする必要はありません。以下では「サブスクリプショングループ」「システムプロキシ」などの機能名で説明します。メニューの位置は画面の変更に伴い異なる場合があります。

インストールを完了し、コアの起動を確認する

インストーラーの実行時は、インストール先に書き込み可能か確認してください。展開が必要な配布形式の場合は、すべてのファイルを展開してからフォルダー内のプログラムを起動します。圧縮ファイルのプレビュー画面から直接実行したり、メインプログラムだけを取り出したりしないでください。関連コンポーネントや設定ファイルが相対パスを前提としている場合があり、ファイルが不足すると画面は開いてもコアを起動できないことがあります。

初回起動時はログ欄を確認し、コンポーネント不足、設定の解析失敗、ポートの競合がないか見ます。実行環境が不足していると表示された場合は、そのビルドに適したコンポーネントを指示に従って追加し、クライアントを再起動してください。出所不明のサイトから同名の動的リンクファイルを取得してフォルダーに入れるのは避けてください。依存関係が適合する保証はなく、インストール状態も把握しにくくなります。

通常、システムプロキシの利用に管理者権限は必要ありません。まず標準権限でサブスクリプションを追加し、ブラウザーで動作を確認してください。権限昇格が必要な機能を有効にする場合に限り、画面の指示に従います。管理者として起動したら設定一覧が空になった場合は、別のプログラムを起動していないか、設定フォルダーが変わっていないか確認してください。既存データを上書きするために、すぐ再追加するのは避けます。

サブスクリプショングループを追加してサーバーを更新する

サブスクリプショングループの設定を開き、新しいグループを作成します。用途がわかる名前を備考に入力し、URL欄にサブスクリプションURL全体を貼り付けます。グループの更新設定を有効にして保存し、サブスクリプションを手動で更新してください。自動更新間隔は以後の更新を制御するもので、最初の手動更新の代わりにはなりません。初回はUser-Agentの既定値を使い、サービス提供元から指定された場合に限り変更します。

更新後、サーバー一覧に戻り、別のグループや検索条件で項目が絞り込まれていないか確認します。サーバーを選択して有効にし、ログに新しい設定が生成されたか確認してください。サブスクリプションに現在のコアが対応していない項目が含まれている場合、サーバー名は表示されても起動時にエラーになることがあります。プロトコルとコアの対応状況を確認し、URLを何度も貼り直すのは避けてください。

サブスクリプションの更新方法として、直接接続とプロキシ経由が選べる場合は、まず現在のネットワークで使える方法を試します。プロキシ経由の更新には、すでに利用可能な接続が必要です。すべてのサーバーが使えない状態で、更新だけを復旧させることはできません。既存のグループは残し、更新結果を確認してから取得方法を変更してください。使える復旧経路を失わないよう、先にすべてのサーバーを削除するのは避けます。

システムプロキシを設定してポートを確認する

システムプロキシの自動設定を選ぶと、Windowsのシステムプロキシに従うアプリがローカルの待ち受けアドレスを使います。システム設定のプロキシ画面を開き、手動プロキシのアドレスとポートがクライアントの現在の設定と一致しているか確認してください。ローカルポートはサーバー側のポートでも、サブスクリプションURLに含まれるポートでもありません。用途が異なるため、同じ値を使い回さないでください。

現在の用途に合ったルーティングプリセットを維持し、まずブラウザーから新しいリクエストを送ります。失敗する場合は、プロキシを個別に制御する拡張機能がないか、ブラウザー独自のプロキシアドレスが設定されていないか確認してください。システムプロキシの適用範囲はアプリによって異なります。1つのアプリが直接接続しても、コアが動作していないとは限りません。そのようなアプリも通信制御が必要な場合は、システムプロキシとTUNの章を参照してください。

Windows特有の終了・権限の問題に対処する

TUNを有効にする前に、実行中のネットワーク作業を保存し、クライアントの指示に従って権限を昇格します。仮想ネットワークインターフェースの作成失敗とサーバーへの接続失敗は別の問題です。前者は権限、ドライバー、ネットワークツールとの競合を確認し、後者はノードとルーティングを確認します。エラーが表示されたからといって、クライアントの再インストール、ネットワークインターフェースの削除、システムネットワークのリセットを同時に行わず、まず具体的なエラーを記録してください。

クライアントを終了するときは、先にシステムプロキシを解除してからプログラムを終了します。誤って終了した後にブラウザーで通信できなくなった場合は、Windowsのプロキシ設定を開き、停止したローカルポートが残っていないか確認してください。残っている手動プロキシを解除して直接接続を試します。復旧すれば通信制御の状態が原因です。サブスクリプションを変更したり、設定をすべて削除したりする必要はありません。

スタートアップ時に起動する設定では、アプリの起動と通信制御の自動開始を区別します。再起動後の動作を一度確認してから、自動接続するか決めてください。複数ユーザーのPCでは、実際に使うアカウントでプロキシ設定を確認します。設定を移行するときはクライアントを終了してからバックアップし、起動中の複数インスタンス間で設定ファイルを直接上書きしないでください。

macOS：インストールとネットワークの許可設定

macOSでv2rayNを使う場合は、「このMacについて」を開いて搭載チップを確認します。Appleシリコン搭載機にはApple Silicon版、Intelプロセッサ搭載機にはIntel版を選択してください。macOSダウンロードからチップに合ったパッケージを入手します。アーキテクチャの選択はアプリが実行できるかどうかに関係しますが、サブスクリプションの内容は変わりません。起動エラーを解決するためにプロトコルを変更しないでください。

アプリを適切な場所にインストールする

ディスクイメージを開き、インストール画面の指示に従ってアプリを「アプリケーション」フォルダーに入れ、その場所から起動します。マウント中のイメージや一時ダウンロードフォルダーから常用するのは避けてください。安定した場所にインストールすると、システムが権限や起動項目を認識しやすくなります。アップデート後に同名アプリが複数できたり、古いコピーを起動したり、設定場所が見つからなくなったりする問題も減らせます。

初回起動時にシステムのセキュリティ警告が出た場合は、インストール元とアプリ名を確認してから、システム設定の「プライバシーとセキュリティ」で許可できる操作を確認します。項目の場所はOSのバージョンによって異なるため、画面に表示される案内に従ってください。システムのセキュリティ機能をまとめて無効にしたり、警告を消すために出所不明のターミナルコマンドを実行したりしないでください。

起動後はログを確認し、コアが正常に読み込まれているか確認します。アプリを実行できないという表示が出た場合は、まずシステム要件、チップのアーキテクチャ、インストールの完了状況を確認してください。画面は正常に開いてコアだけがエラーになる場合は、エラー内容に応じてコンポーネントや設定を確認します。2つの段階を分ければ、システム互換性の問題をサブスクリプションサービスの障害と取り違えずに済みます。

サブスクリプションを追加して最初の接続を確立する

サブスクリプショングループの設定で新しいグループを追加し、備考とURL全体を入力して保存した後、手動で更新します。URLを貼り付ける際は、パスワード管理ツールやリッチテキストのページからコピーした内容に問題がないか確認し、末尾に空白を残さないでください。更新後に有効なサーバーを選び、まずは接続パラメーターを既定のまま使います。サブスクリプション内の通信方式、サービス名、証明書関連の項目を独断で変更しないでください。

更新後に似た名前のサーバーが複数表示された場合は、サービスの説明に基づいて用途を選びます。名前が同じでも設定が完全に同じとは限りません。サブスクリプションを更新するとサーバーパラメーターが置き換わり、手動変更した内容が次回の更新で上書きされる場合もあります。長期的に使うカスタム設定は、独立したグループやクライアントが対応する永続化ルールで管理し、変更理由を記録してください。

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

クライアントのシステムプロキシ機能を有効にしたら、現在使っているネットワーク接続の詳細画面でプロキシ設定を確認します。macOSのプロキシ設定はネットワークサービスごとに異なり、Wi-Fiと有線接続で別々の状態が保存されていることがあります。ドッキングステーションを接続した後やネットワークの切り替え後にブラウザーがプロキシを通らなくなった場合は、サーバーをすぐ変更せず、現在使用中のネットワークサービスを確認してください。

Webプロキシ、セキュアWebプロキシ、SOCKSプロキシの項目はそれぞれ別の設定です。クライアントが複数項目を自動設定している場合は、待ち受け方式に合わせてください。すべてに同じポートを入力すればよいわけではありません。手動プロキシを使うアプリではHTTPとSOCKSのどちらかを正しく選択します。方式と待ち受けポートが合わないと、多くの場合すぐに接続エラーになります。

ブラウザーで動作を確認した後、実際に使うアプリも確認します。システムプロキシを読み込むアプリもあれば、独自のネットワーク設定を使うもの、起動時に一度だけ設定を読み込むものもあります。プロキシ設定を変更したら、対象アプリを終了して再起動し、ログにリクエストが記録されるか確認してください。既存の接続が再利用されているだけなのに、新しい設定が反映されていないと判断しないようにします。

必要に応じてTUNを使い、復旧方法も確認する

選択したビルドにTUN機能がある場合は、クライアントの案内に従って必要な許可を設定し、ログで仮想インターフェースとルートの初期化結果を確認します。システムにない設定項目を、他のプラットフォーム向けコマンドをコピーして無理に追加しないでください。システムプロキシでは対象アプリをカバーできない場合に限り、TUNの利用を検討します。普段のブラウザー利用に、追加の通信制御を導入する必要はありません。

スリープから復帰した後に接続が止まった場合は、通信制御をいったん停止して再度有効にし、ネットワークが復旧しているか確認します。復帰時にIPアドレス、ゲートウェイ、DNSが変わることがあります。既存の接続が切れても、サブスクリプションの更新が必要とは限りません。復帰のたびに失敗する場合は、TUN使用時だけか、特定のネットワークサービスやアプリに限られるかを記録し、対象を絞り込みます。

終了やアンインストールの前にTUNとシステムプロキシを無効にし、現在のネットワークサービスに設定が残っていないか確認します。その後、直接接続を試して問題がないことを確認してからアプリを削除してください。設定を残す場合は個別にバックアップし、設定フォルダー全体を公開しないでください。ネットワーク切り替え後に切断が続く場合は、トラブルシューティングも参照し、権限や通信制御の競合を確認してください。

Linux：パッケージとデスクトッププロキシ

Linuxでは、まずディストリビューションのパッケージ形式と端末のアーキテクチャを確認し、Linuxダウンロードからv2rayNを選びます。Debian系ではdeb、RPM系ではrpmが一般的です。同じ形式でもx64版とarm64版があります。デスクトップGUIクライアントには利用可能なデスクトップ環境が必要です。パッケージを展開できただけで、GUIアプリの実行環境が整ったとは限りません。

システムのパッケージマネージャーでインストールする

ダウンロードしたパッケージは、まずディストリビューションのソフトウェアインストーラーで開き、依存関係をパッケージマネージャーに処理させます。依存関係が不足していると表示された場合は、具体的なパッケージ名とOSの対応状況を確認してから、ディストリビューション公式のソフトウェアリポジトリで対処してください。別のディストリビューションのリポジトリを混用したり、依存関係を無視して強制インストールしたりすると、起動不能やシステムコンポーネントの競合につながるおそれがあります。

次のコマンドでアーキテクチャを確認できます。本体の種類を表示するだけで、システム設定は変更しません。一般にx86_64はx64版、aarch64はarm64版に対応します。コンテナ、リモートデスクトップ、互換レイヤーで実行する場合は、ホストと実際の実行環境を区別してください。ホストのハードウェア名だけでパッケージを選ばないようにします。

uname -m

インストール後はデスクトップメニューから起動し、まず標準ユーザーで実行します。画面が開かない場合は、ターミナルからインストール済みのプログラムを起動してエラーを確認できますが、エラーを回避するためにGUIクライアント全体を管理者アカウントで実行しないでください。標準ユーザーと管理者アカウントでは設定フォルダーが異なります。混在するとサブスクリプション、権限、ファイル所有者が食い違い、管理が難しくなります。

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

サブスクリプショングループを開き、備考とURLを追加して保存・更新し、有効なサーバーを選択します。デスクトッププロキシを設定する前に、コアが起動していることを確認してください。ポート競合のログが出た場合は、他のプロキシプログラムや重複起動したインスタンスを終了します。一般的な既定ポートを確認するには、次のコマンドを使います。端末の設定が異なる場合は、実際のポート番号に置き換えてください。

ss -ltnp 'sport = :10808'
ss -ltnp 'sport = :10809'

コマンドの結果が表示されない場合、そのポートで待ち受けていないか、クライアントが別のポートを使っている可能性があります。一部のプロセス情報は権限によって表示されないこともあります。まずクライアントの設定を確認し、例示されたポート番号だけで問題を判断しないでください。通常のローカル利用ではループバックアドレスへのバインドを優先します。LAN内の端末から使う必要が明確な場合に限り、公開範囲とファイアウォールのルールを検討してください。

デスクトッププロキシとターミナルの環境変数を区別する

デスクトップ環境によってシステムプロキシの保存方法が異なるため、クライアントの自動設定がすべてのアプリに適用されるとは限りません。システムプロキシを有効にしたら、デスクトップのネットワーク設定でモードとポートを確認し、ブラウザーで動作を検証します。システムトレイにアイコンが表示されることと、コアが動作することも別の問題です。トレイに対応していない場合は、ウィンドウとログで状態を判断してください。

ターミナルのプログラムは独自のプロキシ設定を使うことが多く、デスクトップの設定に従うとは限りません。テストする場合は、ログイン環境全体を変更する前に、1つのコマンドだけにプロキシを指定できます。以下の例ではHTTPの待ち受けを10809、SOCKSの待ち受けを10808としています。実際に使うポートは事前に確認してください。テスト先からWebページが返っても、すべての通信プロトコルが使えるとは限りません。

curl --proxy http://127.0.0.1:10809 --head https://example.com
curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

2つ目の例にあるsocks5hは、接続先のドメイン名解決をプロキシ側で行うことを示します。一部のローカル名前解決方式とは異なります。ターミナルでは成功してブラウザーでは失敗する場合は、デスクトッププロキシやブラウザー設定を確認してください。両方失敗する場合は、待ち受け、有効なサーバー、ログを確認します。環境変数を設定済みのターミナルは、デスクトッププロキシを無効にしてもローカルポートを参照し続けることがあります。

TUN、権限、デフォルトルートは慎重に扱う

TUNの利用可否はクライアントのビルド、システム機能、権限の取得方法によって異なります。実際の画面に表示される指示に従ってください。仮想インターフェースの作成に失敗した場合は、ログで権限またはデバイス対応の問題か確認し、プログラム全体を常に高い権限で起動する設定にはしないでください。リモート接続中の端末では復旧手段を確保します。デフォルトルートの変更によって、利用中のリモートセッションが切断されることがあります。

ほかのVPN、コンテナネットワーク、追加のファイアウォール管理ツールを使っている場合は、ルートとルールがどのツールに属するかを個別に確認します。接続復旧のためにシステムファイアウォールを一括で消去しないでください。他のサービスに影響する可能性があります。クライアントを終了して直接接続を試し、デスクトッププロキシやターミナルの環境変数が残っていないか確認します。必要に応じてターミナルを再起動し、設定のない状態で検証してください。

アップグレード前にサブスクリプショングループとカスタムルールをバックアップし、同じパッケージ管理方式で更新します。更新後に画面だけが不調な場合は、デスクトップ環境とエラー出力を記録し、すぐに設定を削除しないでください。コアの解析に失敗する場合は、カスタムパラメーターが現在の対応範囲に合っているか確認します。GUI、パッケージ、ネットワークの問題を分けて記録すれば、どの層を戻すべきか判断しやすくなります。

Android：サブスクリプションとVPNの許可

Androidでは、Xrayコアを採用するv2rayNGを優先してください。V2Flyコアが必要で設定も対応している場合は、代替としてv2flyNGを選べます。Androidダウンロードから、まず端末に合ったarm64版を入手します。アーキテクチャを確認できない場合や特殊な端末の場合は、汎用版の説明を確認してください。画面を比較するためだけに、2つのクライアントの接続機能を同時に起動しないでください。

アプリをインストールしてシステムの許可を設定する

ダウンロードしたファイルからインストーラーを起動すると、現在のファイル提供元からのアプリインストールを許可するよう求められる場合があります。提供元を確認し、必要な場合に限って、今回使うブラウザーまたはファイル管理アプリに許可を与えてください。インストールに失敗したら、システムの表示を確認します。ストレージ不足、アーキテクチャ不一致、OS要件、既存アプリとの署名の不一致は、それぞれ対処方法が異なります。サブスクリプションを再追加しても解決しません。

同名のアプリがすでにある場合は、バックアップなしにアンインストールしないでください。既存のサブスクリプションやルールが保存済みか、上書きインストールが可能か確認します。署名が一致しないという警告が表示されたら、インストール元を確認し、異なる署名のアプリを混在させないでください。アンインストール時にアプリデータが削除されることがあります。サーバー名だけではサブスクリプションURLやローカル設定を完全には復元できません。

サブスクリプショングループを作成して利用するサーバーを選ぶ

サブスクリプション設定を開き、新しい項目に備考とURLを入力します。更新を有効にして保存し、サブスクリプションを更新してください。画面によってはサーバー一覧とサブスクリプション管理が別の場所にあります。目的のグループを更新しているか確認します。クリップボードにあるのが個別の共有リンクなら、ネットワーク経由でデータを取得するサブスクリプション欄ではなく、対応するインポート機能を使ってください。

更新に成功したら一覧に戻り、利用するサーバーを選んで接続を開始します。備考は表示だけに使われ、認証には関係しません。URL、ポート、ユーザーID、通信方式、安全設定はサーバー側の設定と一致している必要があります。名前に特定の用途が書かれていても、あらゆるプロトコルやアプリに対応するとは限りません。提供元がサブスクリプションを更新した後は、選択中の項目が引き続き存在するか確認してください。

設定の「安全でない接続を許可」は、ネットワークエラーを解決するための汎用スイッチではありません。証明書エラーが発生した場合は、まずシステム時刻、接続先ドメイン、サービスの説明を確認し、証明書検証を有効に保ってください。検証を無効にすると接続の安全性が損なわれますが、URLの失効、ポートへの接続不能、アカウント停止などの問題は解決しません。

ローカルVPNによる通信制御と対象アプリを理解する

初回接続時、通常はシステムにVPN接続の要求が表示されます。インストールしたクライアントからの要求だと確認してから許可してください。この許可は端末上に通信制御用の経路を作るためのもので、接続先サーバーが使えることを確認するものではありません。システムに接続中の表示が出ても、実際にリクエストを送り、アプリのログでコアの接続処理が完了したか確認してください。

AndroidのローカルVPN機能は、デスクトップのシステムプロキシとは仕組みが異なります。Windowsのプロキシ設定画面の項目をそのまま設定する必要はありません。通常、この方式のVPNサービスを同時に有効にできるのは1つです。同じ仕組みを使うほかのネットワークツールが接続を奪う場合があります。自動切断が起きたら、サブスクリプションを削除する前に、ほかのサービスが起動していないか確認してください。

アプリごとのプロキシ設定を有効にしている場合は、現在のモードが「選択したアプリだけをプロキシ経由にする」か「選択したアプリをプロキシから除外する」か確認してください。2つのリストは意味が反対です。誤解すると、ブラウザーだけ使えてほかのアプリは使えないことがあります。対象範囲を変更したら接続を再確立してからアプリを開きます。必要なら、アプリを絞り込まない基本設定で一度動作を確認してください。

ネットワーク切り替え、スリープ、名前解決を確認する

Wi-Fiからモバイルネットワークに切り替えると、既存の接続を再確立する必要がある場合があります。まずモバイルデータ通信が利用可能か確認してから、クライアントを再接続します。Wi-Fiでは使えてモバイルネットワークでは失敗する場合は、ネットワークの違いを記録し、IPv6、接続先ポート、DNSの経路を確認してください。自動再接続に任せて無制限に再試行させず、失敗が続く場合は一時停止して最初に関係するエラーを確認します。

システムのプライベートDNS、アプリ独自の暗号化DNS、クライアントのDNS設定は同時に有効になることがありますが、役割は同じとは限りません。ほかのリクエストは正常なのにドメイン名だけ解決できない場合は、これらの設定を記録し、1つずつ検証してください。すべての名前解決先を同時に変更すると、復旧してもどの設定が影響したのか特定できません。

接続を停止した後の状態も確認してください。常時接続VPNや、VPNを経由しない通信をブロックする設定が有効な場合、クライアント停止後に直接接続できないことがあります。これはシステムの設定による動作です。実際の用途に応じて設定を維持または変更し、ネットワーク障害と誤認しないでください。クライアントを切り替える場合は、先に古いサービスを停止してから新しいアプリに設定を追加し、プロトコル対応とバックグラウンドでの安定性を個別に確認します。

システムプロキシ、TUN、通信制御

まずアプリがどのように通信するかを判断し、それに合わせて通信制御の方法を選びます。システムプロキシは通常、アプリに「プロキシの接続先」を知らせるだけで、利用するかどうかはアプリ側で決まります。TUNは仮想ネットワークインターフェースとルートを使って、対象の通信を処理プログラムに渡します。どちらも接続先サーバーではなく、特定のドメインが最終的に直接接続かプロキシ経由かを決めるものでもありません。後者は主にルーティングルールで制御します。

通信制御の範囲とアウトバウンドルールを区別する

「システムプロキシを有効にする」と「グローバルルーティングを使う」は別の操作です。前者はアプリのリクエストをクライアントへ渡す設定で、後者はクライアントに渡ったリクエストのアウトバウンドを選ぶ設定です。グローバルルーティングに変えても、システムプロキシを無視するアプリの通信経路は変わりません。TUNを有効にしても、すべての通信が必ずリモートプロキシを経由するとは限りません。直接接続のルールが適用される場合があります。

「システムプロキシを解除」「システムプロキシを自動設定」「システムプロキシを変更しない」は、それぞれ異なる管理操作です。解除は通常、管理対象のシステムプロキシ設定を削除します。自動設定はクライアントの待ち受け先を登録します。変更しない場合は現在のシステム設定を維持します。実際の動作はクライアントの案内を確認してください。特に組織のポリシーや手動設定がある場合は、操作前に現在の値を記録します。

対象を絞って段階的に有効化する

まずシステムプロキシを使うブラウザーで正常にアクセスできることを確認し、次に対象アプリが設定に従うか試します。アプリにプロキシを手動入力できる場合は、ローカルのHTTPまたはSOCKS接続先を使って、コアとサーバーが正常か先に確認できます。こうすれば、後からTUNで問題が起きても、サブスクリプションから接続先までの経路全体ではなく、システム側の通信制御に原因を絞れます。

TUNを有効にする前に、同様の通信制御を行うほかのツールを終了し、作業中の内容を保存してから、必要な権限を案内に従って許可します。起動後はインターフェースの作成、ルートの設定、DNSの初期化が成功したか確認してください。ビルドによって補助コンポーネントが異なる場合があるため、他のプラットフォーム向けのドライバー手順をそのまま使わないでください。ログがインターフェース初期化の段階で止まる場合は、まずローカルの問題に対処します。

TUNとシステムプロキシを併用するかどうかは、クライアントの実装と利用状況によって異なります。常に併用が必要とは限りません。基本動作の確認では、主要な通信経路を1つに絞ります。併用する場合は、ローカルプロキシへの接続が再度誤って通信制御されないことを確認してください。接続の繰り返し、異常なリソース使用、出口の頻繁な変化が見られたら、まず単一の経路に戻して確認します。

UDP、LAN、仮想ネットワークを確認する

Webページを表示できても、UDPを使うアプリが動作するとは限りません。対象アプリがUDPを使うこと、選択したプロトコルとサーバーが対応していること、クライアントの受信側が通信を制御することが、それぞれ必要です。UDPの通信に失敗したからといって、すぐにグローバルルーティングへ変更しないでください。ルールでアウトバウンドを選べても、サーバーが提供していない機能は補えません。まずサービスの説明を確認し、ログに記録された通信の種類を調べます。

プリンター、ファイル共有、LAN内の管理画面では、ローカルネットワークへの経路を維持する必要があります。TUNを有効にした後に使えなくなった場合は、LANのアドレスが誤ってリモート側へ送られていないかを確認し、次にクライアントの除外ルールを確認してください。組織内ネットワークでは複数のプライベートアドレス帯を使うことがあります。家庭用ルーターのネットワークだけを設定しても、すべてをカバーできるとは限りません。

仮想マシン、コンテナ、ほかのVPNもネットワークインターフェース、DNS、ルートを追加することがあります。競合が起きたら、起動中のネットワークツールを記録し、1つずつ停止して確認してください。すべてのルートを消去しないでください。リモートワークやリモート管理では特に注意が必要です。通信制御ルールを変更する前に、現在の接続を維持する経路まで変更してしまわないよう、ローカルで復旧できる方法を確保します。

リクエストの経路から結果を判断する

動作確認では、アプリ、待ち受け先、ルーティングの適用状況、リモート接続を個別に確認します。アプリからのリクエストがログにない場合は、通信制御を確認します。リクエストが記録されても直接接続のルールに一致する場合は、ルールを確認します。プロキシ経由になった後にタイムアウトする場合は、サーバーとネットワークを調べます。設定の適用範囲についてはv2rayNのTUNモード解説も参照してください。TUNだけですべての接続問題が解決するわけではありません。

接続を終了してから同じアプリで再度確認し、想定どおりの結果になるか確かめます。ブラウザーは既存の長時間接続を再利用することがあり、アプリによっては独自の接続プールを保持します。新しい経路を確認するには、新しいリクエストを発生させてください。まず成功時の基本設定を記録し、スタートアップ、自動接続、アプリごとの対象範囲、複雑な除外ルールを1つずつ追加すると、すべての機能を一度に有効にするより管理しやすくなります。

ルーティングとDNSの連携

ルーティングはコアに渡されたリクエストのアウトバウンドを選び、DNSはドメイン名をIPアドレスに変換します。両者は相互に影響しますが、同じ設定ではありません。まず、どのサービスを直接接続にするか、プロキシ経由にするか、遮断するかを決め、その目的に近いプリセットを選びます。出所がわからない大規模なルールセットを、最初から現在の設定全体に上書きしないでください。

プリセットで安定した基本設定を作る

「グローバル」「中国本土を除外」「ブラックリスト」などの名称は、クライアントが用意するプリセットです。実際のルールは、ルールリソースや設定によって異なることがあります。グローバルは通常、一般的な接続先をプロキシへ送る傾向がありますが、必要なローカル例外が残る場合もあります。「中国本土を除外」はドメインやアドレスの分類に依存します。「ブラックリスト」の具体的な動作は、実際のルールを確認してください。名前だけで通信先を推測できません。

プリセットを切り替えたら、準備した直接接続先とプロキシ接続先へそれぞれリクエストを送信し、ルーティングの適用状況を確認します。出口IPだけで判断しないでください。確認できるのは、そのリクエストの経路だけです。1つのアプリが認証、コンテンツ、更新など複数のドメインへ接続している場合があります。ホームページが表示できても特定の機能だけ失敗するなら、全体をグローバルに変える前に失敗したリクエストを確認します。

ルールの順序とドメインのマッチ方法を理解する

多くのルールは上から順に評価され、最初に一致したルールで処理方法が決まります。特定の接続先を例外にする場合は、対象を包括する広いルールより前に追加してください。サーバーのアドレスは変わることがあるため、任意のIPアドレスを固定するよりドメインルールのほうが管理しやすいのが一般的です。ただし、アプリがIPアドレスへ直接接続する場合は、ドメインルールに一致しないため、別途確認が必要です。

以下はXray形式のルーティング設定例で、プライベートアドレスと指定ドメインを直接接続にする方法を示しています。単独で動作する完全な設定ではありません。アウトバウンドのタグは既存の設定と一致させてください。GUIクライアントは通常、設定を自動生成するため、同じ内容をルーティング編集画面から設定することをおすすめします。実行時に生成されたファイルを直接上書きすると、次回起動時に再生成される場合があります。

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

domainによるマッチは指定ドメインとサブドメインに適用されます。完全一致のホスト名にはfullを使う方法もあります。geositeとgeoipを使う場合は、対応するリソースファイルが必要で、分類名も実際に定義されていなければなりません。AsIsは「ドメインを一切解決しない」という意味ではありません。ルーティング段階の方針を示すものであり、ほかの接続処理やDNS処理では名前解決が行われることがあります。1つの項目だけでリクエスト全体の経路を判断しないでください。

接続先とサーバーの名前解決を分けて確認する

クライアントでは、利用者がアクセスする接続先ドメインだけでなく、プロキシサーバー自体のドメインも解決する必要がある場合があります。後者が、まだ確立していないプロキシ経路に依存すると、起動時に循環が発生することがあります。初期化中に名前解決エラーが続く場合は、どちらのドメインかを切り分けてください。すべてのDNSリクエストを、まだ使えないプロキシへ無条件に送らないでください。

システム、ブラウザー、クライアントのそれぞれにDNS設定がある場合があります。ブラウザー独自の暗号化DNSを使っていると、クライアントのログに想定したシステムDNSリクエストが出ないことがあります。TUNを有効にすると、クライアントが一部の名前解決通信を制御する場合もあります。トラブル調査では、どこが名前解決を要求し、どこが応答し、リクエストがどの経路を通るかを整理してから変更する項目を決めます。

ルールやDNSを変更した後も、古いキャッシュや既存の接続が使われることがあります。新しいリクエストを発生させ、必要なら対象アプリを再起動して結果を確認してください。ページを一度再読み込みしても変化がないからといって、ルールを追加し続けないでください。一時的な変更を重ねると、本来の名前解決の問題が複雑なルーティングに隠れ、どの設定を残すべきかも判断しにくくなります。

IPv6とルーティングの境界を確認する

IPv4とIPv6を両方利用できるネットワークでは、アプリが異なるアドレスファミリーを優先することがあります。特定のドメインへの接続が不安定な場合は、ログに記録された接続先アドレスを確認し、それぞれの経路が使えるか調べます。原因を特定するために一時的に一方のアドレスファミリーへ限定する方法はありますが、分析せずにIPv6を恒久的に無効化するのは避けてください。IPv6に依存するネットワークでは特に注意が必要です。

組織内ドメインでは、通常、組織が指定する名前解決経路を使います。パブリックDNSでは内部レコードを解決できない場合があります。イントラネットのページが開かないときは、ドメインの名前解決と内部ネットワークへのルートの両方を確認してください。直接接続ルールを追加するだけでは解決しないことがあります。逆に、名前解決に成功してもルーティングが可能とは限らないため、2つの段階を個別に検証します。

目的が明確なルールを一度に1つだけ追加し、用途を備考に記録して変更前の設定を保存します。まず国内外のルーティング設定を参考に基本設定を整え、例外が必要な場合はカスタムルールの構文に沿って追加します。ルールが具体的であれば、検証する対象が明確になり、サーバーアドレスが変わったときも修正箇所を見つけやすくなります。

よくある設定の問題とトラブルシューティング

トラブルシューティングでは、まず現象を具体的に記録してから変更する設定を決めます。プラットフォーム、クライアント、通信制御方式、利用中のサーバー、問題が起きた操作を記録してください。たとえば「サブスクリプションの更新に失敗」「TUNを有効にした後、イントラネットに接続できない」のように書きます。「接続できない」だけでは、サブスクリプションの取得、コアの起動、通信制御、リモート接続のどの段階か判断できず、必要な情報も異なります。

サブスクリプションを更新できない・サーバーが表示されない

まずURLが完全か、アカウントが有効か確認し、更新結果がネットワークエラー、Webページの内容、解析エラーのどれかを調べます。ネットワークエラーでは現在の取得経路を確認します。Webページが取得された場合は、ログインページやエラーページの可能性があります。解析エラーではサブスクリプション形式とクライアントの対応状況を確認してください。何らかのデータを取得できても、それが有効なサブスクリプションとは限りません。「ダウンロード成功」の表示だけで判断しないでください。

更新後に一覧が空になった場合は、まず検索条件を解除して対象のグループを選び、そのグループで更新が有効か確認します。更新前の設定を残し、削除と作成を繰り返さないでください。一部のサーバーだけ消えた場合は、提供元がサブスクリプションを変更したか、特定の設定を解析できなかった可能性があります。省略された種類とエラーを記録してサービスの説明と照合し、サーバーのパラメーターを手作業で作り直さないでください。

コアが起動しない・ローカルポートに問題がある

今回の起動後に記録された関連エラーのうち、最初のものを確認します。ポート競合なら重複したインスタンス、設定項目のエラーなら直近の変更、ファイル不足ならインストールの完全性を調べます。その後に発生する多数の接続エラーは、最初の起動エラーの連鎖にすぎないことがあります。起動していないコアの状態で、後続のタイムアウトを1つずつ対処しても解決しません。

複数の配布形式を使っている場合は、現在の実行パスを確認してください。設定を一方のプログラムで変更しても、実際には別のプログラムが起動していることがあります。アップグレード直後に古いフォルダー全体を新しいプログラムへ上書きせず、まず基本の起動を確認してから、クライアントが対応する方法で設定を復元します。実行ファイル、実行コンポーネント、ユーザー設定は別のものです。すべてのファイルを設定として扱わないでください。

ブラウザーでは使えるが、ほかのアプリでは使えない

まず、対象アプリがシステムプロキシを読み込むか、独自のプロキシ設定やアプリごとの除外設定がないか確認します。ログにリクエストがない場合は、通常アプリからクライアントまでの経路を調べます。リクエストが記録され、プロキシ経由になっている場合は、プロトコル、リモート接続、アプリの通信内容を確認してください。TUNが必要なら前の章に沿って段階的に有効にし、サブスクリプションの認証項目を先に変更しないでください。

Webページは表示できても、音声、ゲーム、リアルタイム機能が動かない場合は、UDPとサービス側の対応状況を確認します。Webのテスト結果を別の通信プロトコルの動作確認に使わないでください。ダウンロードが失敗する場合も、アプリ独自のネットワーク機能や複数のドメインが関係することがあります。失敗した機能と時刻を記録し、関連するログを確認すると、サーバーを何度も切り替えるより原因を絞り込みやすくなります。

ハンドシェイクエラー、タイムアウト、一部機能の失敗

証明書またはハンドシェイクのエラーが発生した場合は、システム時刻、サーバー名、サブスクリプションが最新かを確認し、現在のコアが該当パラメーターに対応しているか調べます。REALITYの公開鍵、サーバー名、関連する識別情報は、サーバー側の設定と一致させる必要があります。推測で置き換えないでください。サブスクリプションのサーバー情報が変更された場合は、まず更新し、提供元に確認します。セキュリティ検証を無効にしないでください。

接続タイムアウトでは、サーバーのアドレスに到達できない場合、接続先へのアクセスがタイムアウトする場合、DNSがタイムアウトする場合を区別します。特定のネットワークだけで失敗する場合は、Wi-Fi、モバイル通信、有線接続の違いを記録してください。特定のサーバーだけで失敗する場合は、通信制御とルーティングを同じ条件にして、ほかのサーバーと比較します。ほかの条件を固定しなければ、比較結果を正しく判断できません。

調査に必要な情報を保存し、正常な基本設定に戻す

問い合わせる際は、エラーが起きた時刻、操作手順、機密情報を隠したログを用意します。サブスクリプションURL、ユーザーID、QRコード、アカウント情報は削除してください。ログに含まれる接続先ドメインから個人の利用状況がわかる場合もあるため、必要な範囲だけ共有します。設定フォルダー全体をそのまま共有したり、認証情報を含むバックアップを公開場所にアップロードしたりしないでください。

設定を元に戻すときは、まず直近の変更を1つ取り消し、クライアント1つ、サーバー1つ、通信制御方式1つの基本状態に戻します。正常に動作した設定を簡潔に記録し、その後カスタムルールや自動起動を1つずつ戻してください。日常的な問題はトラブルシューティングを参照できます。操作を最初から確認したい場合はクイックスタートガイドへ戻ってください。環境全体をすぐに再インストールする必要はありません。