V2Rayの全プラットフォーム導入・設定

事前準備：デバイス・設定・通信の対象範囲を確認

クライアント、カーネル、接続設定を区別する

まず、次の3つの層を分けて考えましょう。v2rayN、v2rayNG、v2flyNGは、ノードの表示やサブスクリプションの保存、プロキシモードの変更を行うGUIクライアントです。Xrayとv2flyは、プロトコル処理やルーティング、接続を担うカーネルです。サブスクリプションや共有リンクには、サーバーアドレス、ポート、認証情報、通信パラメーターが含まれます。クライアントをインストールしただけでは、利用可能なサーバーは用意されません。開始前に有効な設定情報を準備し、提供元が現在のデバイスでの利用を許可していることを確認してください。接続情報の不足をインストール失敗と取り違えないようにしましょう。

デスクトップではまずv2rayNを選びます。Windows、macOS、Linuxで基本的な考え方は共通ですが、インストール形式や必要な権限は異なります。AndroidではXrayカーネルを使用するv2rayNGを優先し、設定でv2flyが明確に必要な場合にv2flyNGを選びます。プロトコル名だけで互換性を判断するのは避けてください。同じVLESSでも、通信方式やセキュリティ層、追加オプションが異なる場合があります。設定一式と、選択したクライアントのカーネルが対応しているかを併せて確認しましょう。アプリのアイコンを変えても設定の違いは解決しません。

アーキテクチャ、システム環境、設定情報の入手元を確認

システムのデバイス情報を開き、OS、CPUアーキテクチャ、現在のネットワーク接続方式を確認します。デスクトップでよく使われるx64とarm64は別のアーキテクチャです。インストール形式だけではCPUアーキテクチャは決まりません。まずダウンロードページでプラットフォームを選び、対応するダウンロード項目を確認してください。対応OSはダウンロードページの説明とインストーラーの実際の表示を基準にし、古い記事からすべてのシステムで動くと判断しないでください。デバイスの日時は自動同期に設定しましょう。大きなずれがあると、証明書の検証や一部プロトコルの認証に影響します。

手元の情報がサブスクリプションURL、単一ノードの共有リンク、完全な設定ファイルのどれに当たるか確認します。サブスクリプションURLは、ネットワーク経由で設定一式を取得するためのURLです。単一ノードのリンクには通常、プロトコルのスキームが含まれます。完全な設定ファイルには、inbound、outbound、ルーティングが記述されている場合があります。それぞれに対応するインポート方法を使ってください。元の情報は別途保存し、コピー時に改行や末尾の空白、チャットアプリによる途中切れがないか確認します。サブスクリプションURLにはアカウントを識別する情報が含まれることがあります。スクリーンショット、ログ、問い合わせ内容では必ず伏せてください。

まず最小構成で接続し、機能は一つずつ追加

初回の設定では、クライアント1つ、明確に選んだノード1つ、通信の取り込み方式1つだけを使います。まずデスクトップではシステムプロキシ、AndroidではVPNによる通信の取り込みを使い、ブラウザーが想定どおりアクセスできることを確認してから、振り分け、アプリの除外、TUNを追加します。複数のプロキシアプリを同時に起動すると、ローカルポートの競合、システム設定の上書き、ルートの二重取り込みが起きることがあります。問題が起きたら最小構成に戻しましょう。サブスクリプション、カーネル、DNSを同時に変更するより、原因を特定しやすくなります。

システムプロキシの適用範囲を理解しておきましょう。システム設定に従うアプリにローカルプロキシを使わせる機能であり、すべてのプログラムが利用するとは限りません。ブラウザー拡張、アプリ独自のプロキシ設定、コマンドライン環境には別の設定がある場合があります。TUNは仮想ネットワークインターフェースを通じて、より多くの通信を取り込みますが、ルーティング、DNS、アプリの除外設定、システム権限の影響を受けます。「グローバル」を、どのような状況でもすべての通信が同じ出口を通るという意味に捉えないでください。クライアントの実際のルールとログで確認しましょう。

最後に、プロキシを使わない状態で基本的なネットワーク接続を確認します。ログインページすら開けない場合は、クライアントの設定より先にWi-Fi接続、ネットワーク認証、ローカルDNSを確認してください。元のシステムプロキシ設定や手動DNSも記録しておきましょう。特に組織のネットワークや管理対象デバイスでは、既存のポリシーをそのまま上書きしないでください。テストはできるだけ同じネットワーク、同じ接続先、同じモードで行います。一度に変更する項目は1つにして結果を記録すれば、問題が起きた際に正確に元に戻せます。何度も再インストールして運任せにする必要はありません。

Windows：v2rayNをインストールしてシステムプロキシを設定

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

Windowsのダウンロードページを開き、v2rayNを確認します。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindowsらしい画面と操作感を保っています。メニューの位置は異なる場合がありますが、サブスクリプション、選択中のノード、システムプロキシ、ルーティングという設定の層は共通です。ダウンロードページに記載されたシステム要件に基づいて選び、同じポートを使う2つのバージョンを同時に起動しないでください。使用するバージョンを決め、ショートカットと作業ディレクトリを対応させましょう。

インストーラーを実行し、システムの案内に従ってインストールします。設定は、現在のユーザーに書き込み権限がある場所に保存してください。圧縮形式で配布された場合は、先にすべて展開してから展開先のフォルダーで起動します。圧縮ファイルのプレビュー画面から直接実行してはいけません。ランタイムコンポーネントが必要な場合は、システムの案内とダウンロードページの説明を確認してください。不明なポップアップからコンポーネントを入手しないでください。初回起動時にセキュリティ警告が表示されたら、ファイルの入手元と警告内容を確認し、システムの保護機能全体を無効にしないようにします。

サブスクリプションを追加して使用ノードを選ぶ

メイン画面でサブスクリプショングループの管理を開き、新しいグループを作成します。識別しやすい名前とサブスクリプションURL全体を入力して保存し、更新を実行してください。URLを追加しただけではサブスクリプションが登録されるだけで、ノードを取得するには通常、手動で更新する必要があります。更新後、グループ内のノードを選び、「アクティブサーバーに設定」など同じ意味の操作を行います。行を選択しただけでは切り替わっていない場合があります。アクティブ表示を確認し、ログに対応する設定が読み込まれたことも確認してください。

まずカーネルを起動し、その後システムプロキシを有効にします。自動設定を使う場合は、クライアントが提供するシステムプロキシの設定を選んでください。Windowsにリモートサーバーのアドレスを直接入力するものではありません。システムプロキシが指定するのはローカルの待ち受け先で、リモート接続はカーネルが処理します。システムのプロキシ設定を開き、アドレスがローカルループバックアドレスであること、ポートがクライアントの設定と一致することを確認します。他人の固定ポートをそのまま使わず、現在のクライアントに表示されている値を使ってください。

アプリごとにシステムプロキシとTUNを確認

システムプロキシに従うブラウザーでテストページを開き、新しい接続記録が追加されるか確認します。ブラウザーは正常で特定のアプリだけ失敗する場合は、そのアプリ独自のプロキシ設定、拡張機能、ネットワークオプションを先に確認してください。すぐにノードを変更する必要はありません。アプリが手動プロキシに対応していると明確に分かっている場合は、クライアントの実際の待ち受けプロトコルに合わせてHTTPまたはSOCKSの入口を設定します。SOCKSポートをHTTPポートとして指定しないでください。確認後は、アプリ側のプロキシ設定を分かりやすい形で1つだけ残しましょう。

システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNを検討します。現在の設定を保存し、クライアントの案内に従って仮想ネットワークインターフェースやルートの変更に必要な権限を許可してから有効にしてください。初回テストでは、別のVPNや手動ルートを重ねないようにします。TUNの起動後は、関連インターフェースや起動ログが確認できるはずです。スイッチが有効でも権限エラーが出ている場合、通信を取り込めているとは限りません。TUNモードの解説も併せて確認してください。

Windows特有の起動・終了時の問題に対処する

起動できない場合は、別のインスタンスが待ち受けポートを使用していないか確認します。重複しているインスタンスを終了してから再起動してください。それでも失敗する場合はログを開き、ポート競合、設定の解析エラー、コンポーネント不足などの具体的なメッセージを探します。保護された場所へのインストールや、同期ソフトによる設定ファイルのロックが保存を妨げることもあります。ディレクトリの権限とファイルの状態を確認し、すべての問題を常時管理者として実行して回避しないでください。バックアップ前にサブスクリプション情報を削除するのも避けましょう。

正常に終了する前に、TUNを無効にし、クライアントが設定したシステムプロキシを解除してからアプリを終了します。異常終了後にWebページがすべて開けなくなった場合は、Windowsが停止済みのローカルプロキシを参照していないか確認してください。元の設定に戻してからクライアントを再起動します。自動起動は手動接続が安定してから有効にし、ログイン後の起動と権限昇格の確認をそれぞれ行います。スリープ復帰後に問題が起きた場合は、まず通信の取り込み機能を再起動してネットワークを確認してください。サブスクリプション全体を再インポートする必要はありません。

macOS：チップに合ったバージョンを導入しネットワークサービスを確認

チップを確認してアプリをインストール

「このMacについて」を開き、AppleシリコンかIntelプロセッサかを確認してから、macOSのダウンロードページでv2rayNを選びます。Apple Siliconはarm64、Intelはx64に対応します。購入年だけで判断しないでください。アーキテクチャを間違えると起動できなかったり、追加の互換レイヤーが必要になったりして、トラブルの切り分けが難しくなります。ダウンロードページに2種類の項目がある場合は、両方をインストールして試すのではなく、本体のネイティブアーキテクチャに合う方を選んでください。

ディスクイメージを開き、案内に従ってアプリを「アプリケーション」フォルダーに移動し、移動先から起動します。マウントしたイメージから長期間実行すると、アップデート、ショートカット、権限の確認が複雑になることがあります。初回起動時はシステムの案内に従ってアプリの入手元を確認してください。起動をブロックされた場合は、「プライバシーとセキュリティ」で今回の操作に関する通知を確認し、入手元を確認したうえでシステムが案内する方法で許可します。原因の分からないブロックを回避するために、システム全体のセキュリティを無効にするコマンドは使わないでください。

設定情報を追加しシステムプロキシの適用先を確認

v2rayNのサブスクリプション管理を開き、新しいグループにURL全体を入力して保存し、更新します。ノードが表示されたら使用するノードを明示的に選んでからプロキシを起動してください。設定を読み込めてもカーネルが起動しない場合は、ログでプロトコル、セキュリティ層、通信方式のエラーを確認します。インポートに成功したことはクライアントが情報を認識したことを示すだけで、選択したカーネルがすべてのオプションに対応しているとは限りません。別のデバイスから移行する際は、他の環境専用のカスタム設定ファイルを誤って使っていないかも確認します。

システムプロキシを有効にしたら、システムのネットワーク設定で現在使用中のネットワークサービスを確認します。Wi-Fi、Ethernet、その他のネットワークサービスでプロキシ設定が別々に保存されていることがあります。接続方式を切り替えると、以前の設定が新しいサービスには引き継がれない場合があります。ローカルアドレス、ポート、プロトコルを確認し、サーバーのドメイン名をローカルプロキシの欄に入力しないでください。組織のネットワークで自動プロキシ設定スクリプトが使われている場合は、既存の通信経路を上書きして復元できなくならないよう、先に元の設定を記録します。

ブラウザーでテストが通ったら、必要なアプリも確認します。アプリ独自のプロキシ設定を保持するものや、ターミナルで環境変数だけを参照するものもあります。システムプロキシを有効にしただけで、すべてのアプリが利用しているとは限りません。トラブル時はブラウザーのプロキシ拡張を一時的に無効にし、同じ接続先で標準設定とアプリ独自設定を比較します。特定のアプリだけに問題がある場合は、システム全体のDNSを何度も変更するのではなく、そのアプリのネットワーク設定を確認してください。

TUNを有効にし権限やネットワーク切り替えに対処

より広い範囲の通信を取り込む必要がある場合は、クライアントが実際に提供しているTUN機能を使います。設定を保存し、現在の画面に表示される権限の案内に従って操作したうえで、仮想インターフェースとルートが正しく作成されたか確認してください。配布形式やシステム環境によって、補助コンポーネントや権限の案内が異なる場合があります。現在のクライアントの表示を基準にし、古い記事のインターフェース名をそのまま使わないでください。用途が分からないままシステムのネットワークインターフェースを削除するのも避けましょう。有効化後にネットワークが切れた場合は、まずTUNを無効にして元の状態に戻します。

Wi-Fiから有線接続、テザリング、Web認証が必要なネットワークに切り替える場合は、まず基本的な接続が確立していることを確認してください。認証ページを開くには現在のネットワークへ直接接続する必要があり、以前のプロキシ、DNS、ルートが妨げになることがあります。通信の取り込みを一時的に無効にして認証を済ませてから、再度有効にしてください。スリープ復帰後、カーネルは動作中なのに接続できない場合は、ネットワークサービスが変わっていないか確認し、通信の取り込みを再設定します。ノード情報の更新が必要なのは、サブスクリプションの期限切れやパラメーターの変更が確認された場合だけです。

設定を保存し終了時の手順を明確にする

アプリをアップデートする前に、クライアントが対応している方法でサブスクリプショングループと必要な設定をバックアップし、現在のルーティングと通信の取り込み方式を記録します。プログラムのインストール先とユーザー設定フォルダーは役割が異なります。アプリを削除しても設定が消えるとは限りません。新しいデバイスへ移行する場合は、元のサブスクリプションを再インポートしてからカスタム設定を一つずつ戻してください。古いデバイスのネットワーク経路、権限状態、インターフェース関連のパラメーターをそのまま引き継がないようにします。バックアップは自分で管理できる場所に保存し、公開しないでください。

アプリ終了後もネットワークに接続できない場合は、使用中のネットワークサービスのプロキシ設定にローカルアドレスが残っていないか、該当するローカルプロセスが停止しているかを確認します。記録した内容に沿って元の設定を復元し、基本的なネットワーク接続をテストしてください。社内ネットワークツールが併用されている場合は、デバイス管理の要件に従い、管理対象のポリシーを独断で変更しないでください。日常的な利用では、手順を明確にします。起動時はネットワーク、カーネル、通信の取り込みの順に有効化し、終了時は逆の順に戻すと、設定の残りを見つけやすくなります。

Linux：パッケージを選びデスクトッププロキシとTUNを使い分ける

ディストリビューションとアーキテクチャに合ったインストール方法を選ぶ

Linuxのダウンロードページでv2rayNを選びます。まずシステム設定またはデバイス情報で、ディストリビューションとCPUアーキテクチャを確認してからパッケージを選んでください。debはDebian、Ubuntuおよび関連ディストリビューションでよく使われ、rpmは対応するパッケージ管理方式を採用するディストリビューションで一般的です。どちらも任意に置き換えられる圧縮形式ではありません。デスクトップではx64が一般的ですが、一部のデバイスではarm64が使われます。パッケージ形式とアーキテクチャの両方が合っている必要があります。拡張子だけでインストール可能かを判断しないでください。

システムのソフトウェアインストーラーからローカルパッケージをインストールし、依存関係やインストール記録の管理はパッケージ管理ツールに任せます。依存関係が不足していると表示された場合は、対象のコンポーネントとシステムのバージョンを確認し、現在の環境がサポート対象か判断してください。依存関係を無視して強制的にインストールしたり、クライアントを動かすためだけにシステムの基本ライブラリを安易に入れ替えたりしないでください。インストール後はアプリメニューから起動します。メニューにすぐ表示されない場合は、デスクトップセッションに再ログインしてからインストールが完了しているか確認してください。

通常ユーザーでサブスクリプションとローカルの接続先を設定

まず普段使うユーザーアカウントでクライアントを起動し、サブスクリプションを追加してノードを更新し、使用するノードを選びます。サブスクリプションや画面設定は通常、現在のユーザーに属します。高い権限で常用すると、一般ユーザーが変更できない状態でファイルが保存され、次回の保存に失敗することがあります。設定を保存できない場合は、権限をさらに上げるのではなく、設定ディレクトリの所有者と書き込み権限を確認します。設定を移行する場合は先にバックアップし、クライアントが対応するインポート方法で復元してください。

Linuxのデスクトッププロキシは、すべてのプロセスに一律に適用されるスイッチではありません。デスクトップ環境によって設定方式が異なり、ブラウザー、ソフトウェアストア、ターミナル、バックグラウンドサービスがそれぞれシステム設定、環境変数、独自設定を参照することがあります。まずシステムプロキシに明確に対応するブラウザーでテストし、その後ほかのアプリを一つずつ確認してください。環境変数を変更した後は、ターミナルを開き直す必要がある場合があります。実行中のサービスにも、デスクトップセッションで後から変更した変数は自動反映されません。

クライアントの案内に沿ってTUNの権限を設定

TUNを有効にする前に、現在のLinux環境でクライアントが該当機能を提供していることを確認し、画面に表示される権限の要件を読んでください。仮想ネットワークデバイスやルートの変更には追加の権限が必要な場合がありますが、GUIを常に高い権限で起動する必要はありません。クライアントがサポートする補助サービスや権限の許可手順を優先してください。他のディストリビューション向けの権限コマンドをそのままコピーしたり、案内を省くためにアプリのディレクトリ全体へ過剰なアクセス権を与えたりしないでください。

起動後はログを確認し、仮想インターフェースとルートが実際に作成されたことを確かめてからアプリの通信をテストします。システムのDNS管理ツール、ネットワーク管理サービス、クライアントのDNS設定が同時に存在する場合があります。DNS問い合わせをどれが受け取り、上流のDNSサーバーをどれが提供しているのかを切り分けてください。ドメイン名へのアクセスだけが失敗し、IPアドレスへの接続は正常な場合は、DNS関連のエラーを先に確認します。すべての問題をサーバー側の不具合と決めつけないでください。DNS設定を変更する前に元の状態を記録し、クライアントの停止後に通常の名前解決へ戻せることも確認します。

ポート、デスクトップセッション、ネットワーク管理の競合に対処

ローカルポートの競合は起動失敗のよくある原因です。別のユーザーセッション、古いインスタンス、他のプロキシツールが同じポートを待ち受けていると、新しいインスタンスが接続口を作れない場合があります。不要なインスタンスを終了してください。ポートを変更する場合は、そのポートを手動で指定しているアプリもすべて変更します。クライアント側だけを変更すると、ブラウザーは古い接続先を参照したままです。ファイアウォールのルールも必要な範囲だけ確認してください。ローカルで使うだけなら、通常、プロキシの待ち受けをLAN全体に公開する必要はありません。

GUIが開かない問題とネットワークに接続できない問題は別々に扱います。ディスプレイサービス、デスクトップセッション、UIの依存関係に問題がある場合は、まずアプリを起動できるようにします。カーネルは動いているのに通信できない場合は、その後で設定とネットワーク経路を確認してください。デスクトップ環境のないリモートシステムを、GUI利用と同じ前提で扱わないでください。この手引きはGUIクライアントを中心に解説しており、トラブル対処のために別のバックグラウンドプロキシサービスを追加する必要はありません。同一マシンでルート設定の管理元が分からなくなるのを防ぐためです。

自動起動を設定する前に、通常のログイン後に手動で接続できることを確認してください。自動起動タスク、ユーザーサービス、システムサービスでは、実行ユーザーや環境が異なります。デスクトップで使えるパスがバックグラウンドでも使えるとは限りません。ソフトウェアを更新した後は、自動起動の設定が有効な場所を参照しているか確認します。正常終了時にはTUNを無効にし、プロキシを元に戻してください。異常終了後にネットワークへ接続できない場合は、ファイアウォールやシステムルートをすべて消去するのではなく、元のネットワーク管理設定に照らして基本状態を復元してからクライアントを再起動します。

Android：クライアントをインストールしてVPNによる通信の取り込みを管理

v2rayNGまたはv2flyNGを選ぶ

Androidのダウンロードページから始め、Xrayカーネルを使用するv2rayNGを優先します。v2flyカーネルが必要な場合はv2flyNGを検討してください。2つは別のクライアントであり、サブスクリプション、ルーティング、アプリの除外などの設定が自動的に共有されるとは限りません。比較的新しい一般的なスマートフォンではarm64を確認してください。古い端末やアーキテクチャが分からない場合は、汎用版の説明を確認します。最終的には端末が対応するアーキテクチャとインストール時の案内を基準にし、見た目だけで判断しないでください。

インストール前に、現在のダウンロード元からアプリをインストールできるように許可します。実際に使用するブラウザーやファイル管理アプリにのみ、必要な権限を付与してください。インストール後、不要になったダウンロード元の許可は無効にできます。解析エラー、インストール失敗、既存アプリとの競合が起きた場合は、まずファイルが端末に対応しているか、既存アプリの入手元に問題がないか確認します。すぐにアンインストールして再インストールしないでください。設定が消えることがあります。サブスクリプションURLと必要な設定を保存してから、移行や再インストールの要否を判断します。

サブスクリプションを追加してノードを選び接続を許可

アプリを開き、メニューからサブスクリプショングループまたはサブスクリプション設定に進みます。名前とURLを追加して保存し、メイン画面に戻って更新してください。ノードが表示されたら使用するものを選び、接続を開始します。単一ノードの共有リンクをコピーした場合は、クリップボードからのインポートなど対応する入口を使ってください。完全なサブスクリプションURLを単一ノードとして扱うことはできません。リスト上の選択状態、サービスの起動状態、システムのVPNアイコンはそれぞれ異なる状態を示します。テスト時はすべてを併せて確認しましょう。

初回接続時には通常、システムのVPN許可ダイアログが表示されます。使用中のクライアントからの要求であることを確認して接続を許可してください。この許可は端末内に通信の取り込み用インターフェースを作成するためのものであり、サブスクリプションのサーバーが利用可能であることを意味しません。VPNアイコンが表示されてもWebページを開けない場合は、ノード、DNS、ルーティングを確認します。Androidのこの通信方式は、デスクトップのブラウザーにシステムHTTPプロキシを設定する方法とは異なります。Wi-Fiのプロキシ設定画面にリモートノードのアドレスを重ねて入力する必要はありません。

アプリの対象範囲とバックグラウンド制限を確認

まず標準のアプリ対象範囲でテストし、必要に応じてアプリごとのプロキシを設定します。「選択したアプリだけプロキシを使う」と「選択したアプリをプロキシから除外する」は逆の意味です。表示名は現在の画面で確認してください。アプリを追加・削除した後、クライアントの案内に従って接続を再確立します。ブラウザーは正常で特定のアプリだけ失敗する場合は、そのアプリが除外されていないか、別のユーザー領域で動作していないかを確認し、その後ルーティングとプロトコルを調べます。デスクトップで動くからといって、スマートフォンでも設定がまったく同じとは限りません。

一般的な利用環境では、同じユーザー領域で有効にできるVPN接続は通常1つです。他のVPN、ローカルVPN方式のフィルタリングツール、企業ネットワークツールが現在の接続を置き換え、クライアントが起動後すぐ停止したように見えることがあります。トラブルの切り分け中は通信の取り込みツールを1つだけにし、システムの状態とクライアントログを確認してください。管理対象デバイスでは組織のポリシーに従います。接続を維持するために企業の管理機能を無効にしたり、システムの制限を回避したりしないでください。

画面ロック後に切断される、アプリを切り替えるとサービスが停止するなどの問題は、バックグラウンド管理が原因の場合があります。クライアントがバッテリー最適化の対象になっていないか、バックグラウンドデータ通信が許可されているかを確認して、もう一度ロック状態を再現します。端末全体の省電力設定を一度に無効にせず、必要なアプリだけ変更してください。常時起動にしても通信が永久に途切れないとは限りません。Wi-Fiからモバイルネットワークに切り替わると、接続の再確立が必要になることがあります。復旧の判断は、通知領域のアイコンだけでなく、実際のアクセスと新しい接続記録を確認してください。

ネットワーク切り替えと常時接続の設定に対処

テザリング、Wi-Fi、モバイルデータを切り替えた後は、まず端末自体がインターネットに接続できることを確認し、その後ノードへの接続を確認します。Web認証が必要なネットワークでは、通信の取り込みを一時停止してログインを済ませてから再接続してください。モバイルデータだけで失敗する場合は、クライアントと対象アプリにモバイルネットワークの利用が許可されているか確認します。すべてのネットワークで失敗する場合は、サブスクリプションの有効性、時刻、設定値を確認してください。問題が特定のネットワークに限られるかを切り分ける方が、ノードを次々と切り替えるより有効です。

VPNの常時接続や、切断後の通信をブロックする設定が必要な場合は、影響を理解してから有効にします。サービス停止、端末の再起動、サブスクリプションの無効化時に、システム設定によって他のネットワークアクセスも制限されることがあります。通常の接続が安定してから設定し、解除する場所も確認しておきましょう。別のクライアントへ移行する前に元のサービスを停止し、設定をバックアップして新しいアプリのカーネル対応状況を確認します。移行後はアプリの対象範囲を再設定してください。以前のルールを覚えているだけで、実際には保存されていない設定をそのまま使わないようにします。

サブスクリプション管理：追加・更新・設定の移行

3種類の設定情報を見分けて正しい方法で取り込む

まず情報の形式を確認します。vmess://、vless://などのプロトコルスキームで始まるものは、通常、1台のサーバーへの接続情報を含む単一ノードの共有リンクです。サブスクリプションURLは設定一式を取得するためのURLで、完全なJSON設定にはinbound、outbound、DNS、ルーティングがまとめて記述されている場合があります。それぞれ共有リンクのインポート、サブスクリプショングループの管理、カスタム設定の入口を使ってください。拡張子やURLの見た目だけでは判断できないため、最終的には内容の形式を確認します。

単一ノードのリンクは一時的なテストや固定設定に適しています。パラメーターが変更された場合は、通常、再インポートが必要です。サブスクリプションは、提供元が管理する複数のノードを扱うのに適しており、更新時に新しい内容を取得します。QRコードは文字列を伝える方法にすぎません。読み取った後は、どの種類の情報かを確認してください。ブラウザーでリンクを開けるからといって、クライアントが読み込めるサブスクリプションとは限りません。ログインページ、エラーページ、アカウント管理ページは有効なノード一覧ではありません。

グループを作成して更新結果を確認

情報源ごとに別のグループを作成し、用途やデバイスが分かる名前を付けます。追跡できないリストに複数の情報源を混在させないでください。URLを保存したら一度手動で更新し、結果とノードの表示を確認します。クライアントにプロキシ経由と直接接続の更新方法がある場合は、現在実際に使える経路を選びます。利用可能なノードがない状態で、動作していないプロキシ経由の更新に頼ると、接続が循環することがあります。サブスクリプションへのアクセスに別の正常な経路が必要だと確認できた場合にのみ更新方法を切り替え、ボタンを何度も押すだけで解決しようとしないでください。

更新後はアクティブノードを確認します。元の選択を維持しようとするクライアントもありますが、ノードが削除、改名、置き換えられると選択中の項目が変わったり無効になったりする場合があります。ノード名は表示用のラベルにすぎず、サーバーを識別する確かな情報ではありません。同じ名前の項目がある場合は、グループと接続パラメーターを併せて確認してください。自動更新は、手動更新が安定してから設定します。間隔を過度に短くする必要はありません。頻繁に更新してもアカウントの期限切れ、リクエスト制限、形式の非互換性は解決せず、エラーの切り分けが難しくなることがあります。

一覧が空、項目が欠落、パラメーターが非対応の場合の確認

ノードが表示されない場合は、ダウンロード失敗と解析失敗を区別します。ダウンロードに失敗した場合は、URLの完全性、ネットワーク経路、アカウントの状態、システム時刻を確認します。解析に失敗した場合は、取得内容が有効な形式か、現在のカーネルが対応していないオプションを含んでいないか確認してください。アクセス権が含まれる可能性があるため、サブスクリプションURLを公開オンラインツールに貼り付けて解析しないでください。問い合わせる際は、ホストの識別情報、アカウントパラメーター、認証情報を伏せたエラー概要だけを共有し、クライアントとプラットフォームを伝えます。

一部のノードだけ表示されない場合は、プロトコル、通信方式、セキュリティ層の組み合わせが対応しているか、クライアントのフィルターが有効になっていないかを確認します。プロトコル名が同じでも、拡張パラメーターを別のカーネルが認識できるとは限りません。インポートを成功させるためにTLS、REALITY、サービス名、パスなどの項目を安易に削除しないでください。クライアントとサーバーでこれらのパラメーターを一致させる必要があります。共有リンクとサブスクリプションURLの違いを確認してから、元の情報を照合してください。

移行前にバックアップし、更新後に動作を確認

デバイスの変更や再インストールの前に、サブスクリプションの情報源、手動で追加したノード、ルーティングルール、アプリの除外設定をそれぞれバックアップします。サブスクリプションを再更新すれば情報源に残っているノードは復元できますが、ローカルのメモ、独自の並び順、情報源から削除された項目は戻らない場合があります。完全な設定をエクスポートしても、ローカルの待ち受け先、ファイルパス、仮想インターフェース、権限が異なるため、別のプラットフォームでそのまま使えるとは限りません。まず接続情報を復元し、次に共通ルール、最後にプラットフォーム固有の設定を調整します。

サブスクリプションから生成されたノードを直接編集し、恒久的な管理方法にするのは避けてください。次回の更新で変更が上書きされることがあります。変更が必要な場合は、クライアントが対応している方法で独立した項目として複製し、変更理由を記録します。こうすれば、情報源を更新してもローカルの試験設定が元の設定と混ざりません。手動ノードも定期的に有効性を確認してください。自動更新の対象外だからといって、サーバーのパラメーターが変わらないとは限りません。

復元が完了したら、ノードを1つだけ使って最小限のテストを行い、カーネルの起動、アプリの通信取り込み、ドメイン名へのアクセスを確認してから、他のグループやルールを戻します。サブスクリプションに表示されるメモや期限は、実際の接続テストの代わりにはなりません。クライアントが一覧を読み込めても、アカウントが接続を許可しているとは限りません。提供元が形式やカーネル要件を変更した場合は、クライアントの設定を更新する前に移行案内を確認します。バックアップ前にグループをまとめて削除しないでください。トラブルの比較に使う元の情報が失われます。

モードと振り分け：通信の入口とルールの順序を確認

通信の取り込み方式とルーティングモードを分けて考える

システムプロキシとTUNが決めるのは「通信をどうクライアントに取り込むか」です。グローバル、直結、ルールによる振り分けが決めるのは「取り込んだ通信をどこへ送るか」です。この2種類の設定は別の層にあります。システムプロキシを有効にしても、設定に従わないアプリは直接接続する場合があります。TUNを有効にしても、ルールによって一部の通信が直結することがあります。トラブル時は、まずアプリの通信がカーネルに入っているかを確認し、その後どのアウトバウンドが選ばれたかを確認してください。「グローバル」という表示だけを見て、通信が実際に取り込まれているかどうかを見落とさないようにします。

まず初期ルールで基本状態を確認し、必要な変更を判断します。グローバルプロキシは、短時間だけ振り分け設定の影響を除外するのに役立ちますが、サーバーの不具合や名前解決の問題は自動で修復しません。グローバル直結はローカルネットワークの検証に使えますが、クライアントのバックグラウンド通信にも独自設定がないことを意味しません。ルールによる振り分けを継続して使う場合は、デフォルトのアウトバウンド、LANの処理、アプリの除外設定がどこで行われるか把握してください。画面の表示名は異なる場合があるため、実際のルール内容とログを基準にします。

具体的なルールから一般的なルールの順に並べる

一般的なルーティングルールは順番に評価され、前のルールで送信先が決まると、後続の同種ルールは通常その決定を変更しません。そのため、特定のドメイン、業務ネットワーク、LAN向けのルールは、より広範なルールより前に配置します。ドメインルールとIPルールは完全に同じではありません。接続先のドメイン名がまだ解決されていない場合や、アプリや通信の取り込み方式によってはIPアドレスしか取得できない場合があります。トラブルを調べる前に、カーネルが実際に取得している接続先の情報を確認してください。ブラウザーのアドレスバーだけからルールの一致を推測しないようにします。

以下は、ルールの順序を理解するためのXrayルーティング例です。例示したドメインとそのサブドメインはプロキシ経由にし、一般的なプライベートIPアドレスは直結にします。これは完全なクライアント設定ではありません。対応するoutboundタグを持つ設定へ組み込む必要があります。proxyとdirectは実際のoutboundタグと一致させてください。GUIクライアントが設定を自動生成する場合は、起動のたびに再生成されるファイルを直接上書きせず、カスタムルールの画面で同じロジックを設定します。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

ここでのdomain:example.comは、例示したドメインとそのサブドメインを照合するもので、文字列を含むすべてのアドレスに一致するわけではありません。プライベートネットワークのルールも、特殊用途のアドレスやIPv6のすべてを対象にするものではありません。AsIsはIPルールのためにドメイン名を強制的に解決しないため、ドメイン名の接続先が後続のIPルールに一致するとは限りません。この例は明示した2種類の意図だけを示しています。残りの通信は完全な設定のデフォルト動作に従うため、これを完全な振り分け設定としてそのままインポートしないでください。

ルール用リソース、DNS、IPv6を確認

geositeやgeoipの分類を使う場合は、ルールファイルが存在し、現在のカーネルが対応する形式と分類名である必要があります。分類が見つからない、リソースを読み込めない、ネットワークに接続できないという問題はそれぞれ別です。まず起動ログを確認してください。データの出所や分類の意味が分からないまま、ルールを大量に追加しないでください。設定を整理する場合はルーティング設定の解説を参照し、対象ドメインに合わせて少数の分かりやすいルールを追加します。

DNSは名前解決の方法を決め、ルーティングは接続の送信経路を決めます。両者は影響し合いますが、互いの代わりにはなりません。アプリ独自の暗号化DNSを使う場合や、先にIPアドレスを取得してから接続する場合があります。クライアントが取得する情報が異なれば、ドメインルールの動作も変わることがあります。TUNを有効にしたら、DNS問い合わせが想定した経路に入っているか、リモートDNSに必要な接続先が有効なアウトバウンド経由で利用できるかを確認します。すべてのDNSサーバーを一度に変更せず、ログで問題が発生している段階を特定してください。

IPv6も独立した経路として確認します。デバイスがIPv6アドレスを取得できても、現在のノード、接続先、通信の取り込みルールが同じ接続方式に対応しているとは限りません。デュアルスタック環境で問題が起きる場合に限り、制御されたテストでアドレスファミリーごとの結果を比較してください。IPv6の恒久的な無効化を、あらゆる問題に対する汎用的な解決策にしないでください。LANプリンター、ファイル共有、内部ドメインでは直結が必要な場合もあります。広範なルールを追加する前にローカルサービスを確認し、既存のネットワーク利用を妨げないようにします。

変更するたびに同じ接続先で再テストし、一致したルールやアウトバウンドのログを確認してください。ルールを増やしても精度が上がるとは限りません。用途を説明できない古いルールは、整理する前にバックアップします。問題がないことを確認してから長期利用の設定として保存し、デフォルトのアウトバウンドと元に戻す方法も記録してください。システムプロキシに従わないアプリが原因なら、ドメインルールを増やすより通信の入口を直す方が有効です。カーネルに入っていない接続は、ルーティングでは処理できません。

設定のトラブル対処：接続経路を段階的に確認

症状を分類して確認箇所を決める

再現できる症状として記録します。アプリが起動しない、サブスクリプション更新に失敗する、カーネルが起動しない、ドメイン名へのアクセスだけが失敗する、特定のアプリだけ失敗する、画面ロック後やネットワーク切り替え後に切断される、といった形です。プラットフォーム、通信の取り込み方式、選択中のノード、最後に変更した設定も記録してください。原因の異なる症状を「使えない」の一言にまとめないようにします。まず通信の取り込みを無効にして基本ネットワークを確認し、ノード1つとアプリ1つで再現する方法が、安定した切り分けの出発点です。

アプリが開かない場合は、インストール、アーキテクチャ、システム依存関係、権限を先に確認します。画面は正常でもカーネルが起動しない場合は、設定の解析とローカルポートを調べます。カーネルが正常なのにアプリの接続記録がない場合は、システムプロキシ、アプリの除外、TUNを確認します。接続記録があるのに失敗する場合は、その後で接続先の名前解決、サーバー、プロトコルのパラメーターを確認してください。この順番なら、アプリが起動していない段階でルーティングを変更したり、サブスクリプションの期限切れを権限の問題と取り違えたりせずに済みます。

ログを読み必要な前後情報を残す

最後に表示された単語だけを切り取るのではなく、エラーの発生時刻を確認して前後数行を読みます。ポート使用中のエラーは、ローカルプロセスの競合を示すことがよくあります。認証やハンドシェイクの失敗には、認証情報、時刻、通信方式、セキュリティ層のパラメーターが関係する場合があります。名前解決の失敗ではDNS経路を確認します。ログのタイムアウトは、ある操作が制限時間内に完了しなかったことを示すだけで、どちら側の障害かを直接示すものではありません。要求先、使用したアウトバウンド、基本ネットワークの結果と併せて、原因を絞り込みます。

詳しいログが必要な場合は、クライアントが提供するログレベル設定を一時的に変更します。以下はXray設定で有効なログオブジェクトの例です。サーバー情報は含まず、完全な接続設定でもありません。GUIクライアントでは画面上の設定を優先してください。自動生成ファイルを直接編集すると、再起動後に変更が失われることがあります。infoで動作状況を確認し、不十分な場合に限って短時間だけ詳細なログレベルを有効にします。調査後は元に戻し、不要なアクセス情報を長期間記録しないようにしてください。

{
  "log": {
    "loglevel": "info"
  }
}

ログを共有する前に、サブスクリプションURL、識別パラメーター、サーバーの認証情報、個人を特定できるパスを削除してください。通常はエラーの種類、発生時刻の順序、必要な接続先の種類を残せば、問題を検討できます。完全なエクスポート設定を公開ページに貼り付けたり、見知らぬツールにサブスクリプションを読み込ませたりしないでください。よくある質問はFAQを確認できます。追加情報は、すべての設定画面を公開するのではなく、現在の問題が起きている層に絞ってください。

遅延、スループット、実際の接続性を区別する

遅延テストはトラブル診断の手がかりであり、接続を保証するものではありません。TCP接続テストは主にポートへの接続を確認し、実接続テストではプロキシのハンドシェイクやテスト先も関係します。ダウンロード速度の測定結果は、スループット、混雑、同時接続の影響を受けます。数値が低くてもWebページを開けないことはあり、テスト経路と実際のアプリの経路が異なる場合があります。同じノード、ネットワーク、接続先を使って比較してください。異なる時間やプロトコルの結果を並べただけで、安定性を判断しないようにします。

特定の接続先だけ失敗する場合は、ほかの接続先が正常か比較し、その接続先の名前解決、プロトコル、ルーティングを確認します。すべての接続先で失敗する場合は、選択中のノードと通信の入口を優先して調べます。アプリが1つだけ失敗する場合はアプリの設定を、特定のネットワークだけ失敗する場合はネットワーク認証、アドレスファミリー、接続制限を確認します。テスト方法の詳しい違いは遅延テストとダウンロード速度測定の解説を参照してください。エラーログを読まずに測定を繰り返しても、問題の代わりにはなりません。

設定を元に戻して復旧を確認

複雑な問題が起きた場合は、最近の変更を逆の順番で取り消します。追加したルールを無効にし、DNSと通信の取り込み方式を初期状態に戻してから、最後に接続情報の再インポートを検討します。変更を戻すたびに同じ接続先をテストして結果を記録してください。クライアントをリセットする前には、サブスクリプション、手動ノード、ルーティング、アプリの対象範囲をバックアップします。再インストールしてもユーザー設定が消えるとは限らず、システムのネットワーク設定も元に戻るとは限りません。最初に試すべき確実なトラブル対処ではありません。

最後に、動作確認済みの最小構成と復旧手順を記録しておきます。デスクトップではシステムプロキシを解除できるか、TUNを正常に無効化できるかを確認します。Androidではバックグラウンド動作、アプリの対象範囲、常時接続の設定が想定どおりかを確認してください。アップデート前にバックアップし、更新後は最小構成でテストしてから複雑なルールを戻します。接続手順を最初から確認する場合はクイックスタートガイドへ、インストール方法を確認する場合はクライアントのダウンロードページへ戻ってください。導入、設定、トラブル対処の役割を分けて確認できます。