共通の準備:まず3つの情報を確認
始める前に、デバイス、クライアント、接続情報を分けて確認しましょう。OSによってインストーラーが決まり、CPUアーキテクチャによってアプリが動作するかが決まります。サブスクリプションの内容は、有効な設定をクライアントが作成できるかに関わります。この3つは互いに代用できません。クライアントをダウンロードしただけでは、使えるサーバーは自動で用意されません。情報を1件インポートできても、接続先サービスが有効とは限りません。事前に条件を整理しておけば、問題が起きても再インストールを繰り返さずに済みます。
OS、アーキテクチャ、コアの要件を確認する
デスクトップではv2rayNを基本に選びます。Windowsのダウンロードページにはデスクトップ版と従来のWPF版があり、主な違いはインターフェースと実行環境です。サブスクリプションアカウントが異なるわけではありません。macOSではApple SiliconかIntelかに合わせて選び、LinuxではCPUアーキテクチャとディストリビューションのパッケージ形式の両方を確認してください。拡張子だけでアーキテクチャを判断したり、デスクトップ用インストーラーをスマートフォンで開こうとしたりしないでください。
AndroidではXrayコアを搭載したv2rayNGが基本です。既存の設定が明確にV2Fly向けの場合は、v2flyNGも選択肢になります。コアは見た目を変えるテーマではなく、設定の解釈やプロトコルの処理、接続の確立を担います。REALITYなど特定の機能が必要な接続情報では、対応するコアが必要です。インポート画面が似ていても、すべての設定項目を相互に使えるとは限りません。
デバイスの時刻が自動同期されているか、インストールに必要な空き容量があるか、現在の入手元からのアプリのインストールがOSで許可されているかも確認してください。時刻が大きくずれていると、証明書の検証や一部の認証処理に影響することがあります。最初の切り分けでは安定した通常のネットワークを使い、複数のプロキシやVPNツールを同時に有効にしないでください。通信がどの経路に入っているのか判断できなくなります。
サブスクリプションURLと単体の共有リンクを区別する
サブスクリプションURLは通常、複数の接続情報を返す更新可能なネットワークアドレスです。一方、共有リンク1件には単一のサーバー設定が記述されています。コピーする際は、チャットアプリの説明文や引用符、改行を含めず、URLやリンク全体を取得してください。ブラウザーで表示されるアカウント管理ページが、サブスクリプション用のエンドポイントとは限りません。ウェブページを正常に開けても、「サブスクリプショングループ」のURL欄に貼り付けられるとは限りません。
サブスクリプションURLにはアカウント情報が含まれることがあるため、パスワードと同じように扱ってください。公開フォーラムに投稿したり、URL全体が写ったエラー画面を共有したり、URLを含む設定バックアップをアップロードしたりしないでください。問題を相談するときは、エラーの種類、操作手順、クライアント名を伝えれば十分です。URLが漏えいした場合は、クライアント上でグループを削除するだけでなく、サービスのアカウント管理機能から再発行してください。
旧クライアントを使っている場合は、画面のエクスポートまたはバックアップ機能で設定を保存し、サブスクリプショングループ名、現在のサーバー、ルーティングプリセット、ローカルの待ち受けポートを記録しておきましょう。バックアップは自分で管理できる場所に保存してください。移行時は、まずサブスクリプションを1つだけ追加して動作を確認し、その後ほかのグループを移します。設定を一度にすべてコピーすると、旧ポートの競合、古いルール、無効なリンクまで引き継いでしまいます。
再現可能な確認手順を用意する
初回の接続確認ではサーバーを1つだけ選び、TUNを無効にして、既定のルーティングとシステムプロキシを使います。まずクライアントがコアを起動できるか確認し、次にブラウザーがシステムプロキシを使っているかを見て、最後に目的のページを開けるか試します。変更は一度に1つだけにし、毎回同じ手順で確認してください。インストール、接続情報、通信の取り込みに関する問題を切り分けやすくなり、「速くなった気がする」といった感覚に頼らずに済みます。
ログは再現確認が必要なときだけ一時的に詳細化し、作業後は通常のレベルに戻してください。共有前にアドレス、ユーザー識別情報、サブスクリプションの認証情報を隠します。エラーの記録には、赤い警告のスクリーンショットだけでなく、「どの手順を実行したか」「画面に何が表示されたか」「次にどうなったか」を含めると役立ちます。まず最短の手順で接続したい場合はクイックスタートガイドへ。このマニュアルの後半では、OSごとの違いを説明します。
Windows:v2rayNのインストールと通信の取り込み
Windowsでは、インストーラーの選択、初回起動、サブスクリプションの追加、システムプロキシの有効化の順に進めます。最初からすべての機能を有効にする必要はありません。クライアントの画面が表示されても、起動したのはGUIだけかもしれません。コアの起動、ローカルポートの待ち受け、ブラウザーのプロキシ利用状況は、それぞれ個別に確認してください。問題が起きたらこの順番を逆にたどると、サーバーをむやみに変えるより原因を特定しやすくなります。
デスクトップ版と従来のWPF版を選ぶ
Windowsのダウンロードページで、用途に応じてv2rayNのデスクトップ版または従来のWPF版を選びます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版はおなじみのWindowsデスクトップレイアウトを維持しています。メニューの位置はバージョンによって異なることがあるため、この記事では「サブスクリプショングループ」「システムプロキシ」「ルーティング設定」などの機能名で案内します。ボタンの位置は固定せず、実際の画面表示を確認してください。
インストールウィザードに従ってインストールし、スタートメニューまたはインストール先から起動します。実行環境が不足していると表示された場合は、メッセージにあるコンポーネント名とアーキテクチャを確認し、アプリの案内に従ってください。不明なサイトから個別の動的ライブラリをダウンロードし、プログラムのフォルダーに追加するのは避けてください。インストーラーを起動できない場合は、OSのセキュリティ通知、ファイルのダウンロード状況、アプリのインストールに関するデバイスの制限を確認します。
初回は通常のユーザー権限で起動すれば十分です。システムプロキシの設定には通常、管理者権限は必要ありません。TUNでは権限の引き上げや追加のネットワークコンポーネントが必要になる場合があります。許可を求められる手間を省くために、すべてのネットワークアプリを常に管理者として実行しないでください。画面は開くもののコアがすぐ終了する場合は、ログでポートの競合、書き込みできないファイルパス、コアの起動失敗を確認し、該当する原因に対処します。
グループを作成してサブスクリプションを更新する
「サブスクリプショングループ」でグループを追加し、識別しやすい名前と完全なサブスクリプションURLを入力します。保存後、現在選択しているグループを更新してください。共有リンク1件をインポートする場合は、クリップボードからのインポート機能を使い、サブスクリプションURL欄には貼り付けないでください。どちらも似た項目が表示される場合がありますが、今後の一括更新元として保持されるのはサブスクリプショングループです。
更新が終わったら、まずサーバー一覧のキーワードフィルターを解除し、目的のグループが選択されているか確認します。一覧が空でも、ダウンロードに失敗したとは限りません。フィルターですべての項目が非表示になっている可能性もあります。サーバーを1つ選んでアクティブにし、プロトコル名が想定どおりか確認してください。同名の項目が多い場合は、名前の末尾だけで接続情報の違いを判断せず、提供元ごとにグループ分けして整理します。
サブスクリプションの更新に失敗したら、まずURLが途中で切れていないか、アカウントページのURLを誤ってコピーしていないかを確認し、エラーの詳細を見ます。既存のプロキシ経由でないとアクセスできないサブスクリプションもあります。その場合は、既存の接続が有効かを確認してから、プロキシ経由での更新を選んでください。有効な接続がない状態で更新方法を何度も切り替えないでください。詳しくはサブスクリプション更新失敗時のチェックリストを参照してください。
システムプロキシ、TUN、Windows特有の問題
「システムプロキシ」で「システムプロキシを自動設定」を選び、システム設定に従うブラウザーで接続を確認します。「システムプロキシをクリア」はクライアントが設定した値を取り消します。「システムプロキシを変更しない」は現在の状態を維持するだけで、プロキシを無効にする設定ではありません。別のツールが以前設定したプロキシが残っている場合、「変更しない」に切り替えても古いアドレスを使い続けることがあります。問題の切り分けでは、システム設定に実際に登録されている値を確認してください。
ブラウザーは使えるのに一部のアプリがつながらない場合は、そのアプリがシステムプロキシを参照するかを確認します。より広い範囲の通信を取り込む必要があるときだけTUNを有効にし、指示に従って権限を許可して、仮想ネットワークインターフェースとコアのログを確認してください。有効化後にデバイス全体がネットワークにつながらなくなった場合は、すぐにTUNを無効にし、動作確認済みのシステムプロキシに戻します。そのうえで仮想インターフェース、ルーティングの競合、ほかのネットワークツールを順に確認してください。DNSと複数のルールを同時に変更しないでください。
スリープ復帰後につながらない場合は、ネットワークインターフェースの変化や、ほかのツールによる設定の上書きが考えられます。まずアクティブなサーバーを選び直し、システムプロキシを再適用してください。異常終了後にブラウザーでページを開けない場合は、Windowsのプロキシ設定でローカルアドレスを確認します。クライアントが終了していれば、そのクライアントのポートを指すプロキシは応答できません。手動で元に戻す前に、その設定が組織の管理ポリシーではないことを確認してください。
スタートアップ、サブスクリプションの自動更新、既定のルーティングは、最初の接続に成功してから設定してください。ファイアウォールの確認画面で待ち受け範囲を尋ねられたら、まずはローカルデバイスのみで使う設定にします。ブラウザーから接続するためにLANへのアクセスを許可する必要はありません。ログにポートの競合が表示された場合は、古いインスタンスを終了するか、クライアントの設定で未使用のポートに変更します。手動でプロキシを設定したアプリも合わせて変更し、接続元と接続先の設定を一致させてください。
macOS:チップの選択とネットワーク権限
macOSでv2rayNを使うときは、まずチップを確認し、インストール後に必要なシステム権限を許可します。アプリが起動すること、メニューバーに状態が表示されること、システムの通信がプロキシを使うことは、それぞれ別の状態です。デスクトップにはWi-Fi、有線LAN、仮想インターフェースが同時に存在する場合があります。ネットワークを切り替えた後は、現在のインターフェースでプロキシが有効か確認してください。クライアントのスイッチの位置だけで判断しないようにしましょう。
チップに合った版を選び、初回起動を完了する
システムの「このMacについて」を開き、「チップ」または「プロセッサ」を確認してください。Apple Siliconにはarm64版、Intelにはx64版を使用します。macOSのダウンロードページから対応する版を選んでください。外観や購入時期だけで判断しないようにしましょう。通常はネイティブアーキテクチャ版が適しています。誤ったアーキテクチャのインストーラーで起動できない場合は、互換レイヤーを追加するのではなく、適切な版をダウンロードし直してください。
ダウンロードしたディスクイメージを開き、画面の案内に従ってアプリを「アプリケーション」フォルダーに移動してから起動します。マウント中のインストールイメージから長期間起動しないでください。更新やファイルの場所、終了後の動作が分かりにくくなります。旧版がある場合は、置き換える前に旧インスタンスを正常終了してください。古い場所から開いたウィンドウと、新しい場所を指す起動項目が混在するのを防げます。
初回起動がシステムにブロックされた場合は、ファイルの入手元とアプリ名を確認し、「プライバシーとセキュリティ」に表示される該当アプリ向けの案内に従ってください。アプリを開くために、システム全体のセキュリティ機能を無効にしないでください。管理対象デバイスでは、ユーザーが個別に許可できない場合があります。その際はデバイスの管理者に対応を依頼してください。権限の確認画面が出たときも、要求元が起動したばかりのアプリであることを確かめます。
サブスクリプションを追加し、アクティブな項目を確認する
v2rayNのサブスクリプショングループ機能でグループを追加し、URLを保存してから更新します。ブラウザーからコピーしたテキストをインポートできない場合は、自分で管理できるローカルのテキスト欄に貼り付け、内容が完全か確認してください。認証情報をオンライン変換ツールに送信しないでください。サブスクリプションからエラーページが返ることもあります。内容を受信できたことと、解析に成功したことは別なので、クライアントの更新結果を確認します。
更新後、目的のグループを選択し、一覧のフィルターを解除してからアクティブなサーバーを設定します。初回確認では、生成された既定の設定を使い、転送パラメーターやセキュリティ設定をすぐに変更しないでください。接続情報にあるサーバー名、接続先アドレス、証明書の検証名は、必ずしも同じではありません。似た名前だからと手動で項目を入れ替えると、画面上は問題なく見えても、暗号化接続の確立に失敗することがあります。
複数のサブスクリプションがある場合は、それぞれに名前を付け、まず1つを確認してから順に追加します。自動更新の間隔は、手動更新が安定してから設定してください。スリープ中に更新できなくても、必ずしも故障ではありません。復帰後に手動で更新できます。古い項目が残っている場合は、すべてを一括削除する前に、個別にインポートした項目があるか、表示中のグループが今回更新したものかを確認します。
システムプロキシとTUNの権限を確認する
システムプロキシの自動設定を有効にしたら、システム設定の「ネットワーク」で現在使っているネットワークサービスを選び、詳細設定のプロキシ情報を確認します。OSのバージョンによって設定画面の場所は変わることがありますが、確認するのは常に現在アクティブなネットワークサービスです。自動プロキシ設定スクリプトを使っていた場合は、元の値を記録しておきます。クライアントが設定を引き継いだ後、以前の環境に戻せなくなるのを防げます。
まずシステムプロキシに従うブラウザーで確認してください。アプリ独自のプロキシ設定を使う場合や、システムプロキシを参照しない通信もあります。これはサブスクリプションが消えたという意味ではありません。通信を取り込む範囲を広げる必要がある場合は、TUNを試し、アプリとシステムの案内に従って権限を許可します。許可しても有効にならないときは、スイッチがオンかどうかだけでなく、仮想インターフェースが実際に作成されたかログで確認してください。
Wi-Fiから有線LANに切り替えたときや、スリープ後に再接続したときは、まず基本ネットワークでアドレスを取得できることを確認してからプロキシを再適用します。特定のネットワーク環境だけで失敗する場合は、同じサーバーとルーティングを使って比較してください。公衆ネットワークでは、先に通常のログイン手続きを完了する必要があります。ネットワーク認証が済んでいなければ、クライアントのコアが起動しても接続できません。
アプリを終了する前に、アプリが設定したシステムプロキシを解除するか、通常終了時に設定が復元されることを確認してください。異常終了後にページを開けない場合は、現在のネットワークサービスのプロキシ設定を開き、停止したローカルの接続先を指したままになっていないか確認します。必要な作業用設定を残し、すべてのネットワークサービスを一括で初期化しないでください。共通する問題はよくある質問で確認できます。ネットワークが変わるたびにインストールが壊れたと考える必要はありません。
Linux:パッケージ形式、デスクトッププロキシ、権限
Linuxはディストリビューション、デスクトップ環境、権限の仕組みによって動作が異なります。この章では、グラフィカルデスクトップでv2rayNを使う場合を中心に、システムのソフトウェアインストーラーでパッケージを導入し、クライアントでサブスクリプションとプロキシを設定する手順を説明します。パッケージマネージャーはファイルをインストールし、デスクトップ環境は一部のシステムプロキシ設定を担い、コアとネットワークインターフェースは接続を処理します。それぞれの問題を混同せずに確認してください。
ディストリビューションの形式とCPUアーキテクチャを確認する
Linuxのダウンロードページからインストーラーを選びます。debパッケージを使うディストリビューションではdeb、rpmパッケージを使うディストリビューションではrpmを選択し、x64とarm64も確認してください。パッケージ形式とCPUアーキテクチャは別々の条件です。片方が合っていてもインストールできないことがあります。システムの「情報」やハードウェア情報でアーキテクチャを確認し、デバイスのブランドだけで判断しないでください。
ディストリビューション付属のソフトウェアインストーラーでパッケージを開き、依存関係と権限の案内を確認してインストールします。依存関係が不足していると表示された場合は、まず対応するディストリビューションとソフトウェアリポジトリの状態を確認し、システムの修復機能を使ってください。依存関係の確認を無理に回避したり、別のディストリビューションの基盤ライブラリをコピーしたりしないでください。更新やアンインストールの根拠が失われるおそれがあります。
インストール後はアプリメニューから起動し、GUI全体を管理者権限で実行するのを常態化させないでください。通常ユーザーと管理者では設定の保存先が異なることがあり、権限を混在させると「インポートしたサブスクリプションが見つからない」、設定フォルダーに書き込めないといった問題が起きます。以前に権限を引き上げて実行した場合は、設定を移行する前に、現在のユーザーが自分のアプリ設定へ正常に書き込めるか確認してください。
サブスクリプションを追加し、デスクトッププロキシの適用範囲を確認する
サブスクリプショングループにURLを追加して保存し、更新してから一覧でアクティブなサーバーを選びます。コピーした内容が不完全な場合は、クリップボードにターミナルの改行、ウェブページの説明、全角記号が混ざっていないか確認してください。初回接続では高度な転送パラメーターを変更しません。サブスクリプションの解析に成功しても接続できない場合は、同じURLのインポートを繰り返すのではなく、コアのログを確認します。
システムプロキシを有効にしたら、デスクトップ環境のネットワークプロキシ設定でモードとローカルの接続先を確認します。デスクトップ環境によってシステムプロキシの参照方法は異なります。アプリ独自の設定を使うものもあれば、起動時の環境変数に依存するものもあります。そのため、ブラウザーが使えても、バックグラウンドサービス、サンドボックスアプリ、コマンドラインプログラムが同じプロキシを使うとは限りません。
GUIアプリに独自のプロキシ設定がある場合は、クライアント画面に表示された待ち受けアドレス、ポート、プロトコルを入力してください。SOCKSの接続先をHTTPプロキシ専用の欄に入力したり、サブスクリプションURLをプロキシサーバーのアドレスとして指定したりしないでください。変更後はアプリを再起動してテストします。古いプロセスが起動時のネットワーク設定を使い続けるのを防げます。
TUNの権限、インターフェースの競合、復旧手順
より多くのアプリの通信を取り込む必要がある場合にだけ、TUNを有効にします。TUNには仮想ネットワークインターフェース、ルーティング、アプリに必要なネットワーク権限が関係します。許可方法はクライアントとディストリビューションの案内に従ってください。画面上では有効でも、ログにインターフェースの作成失敗が出る場合は、権限と実行環境を確認します。リモートサーバーの問題と決めつけたり、アプリのフォルダー全体のアクセス権を無条件に広げたりしないでください。
TUNを有効にする前に、同種のネットワークツールを終了し、残す必要がある特殊なルートがないか確認してください。コンテナー、仮想マシン、リモートワーク用ネットワークが独自のサブネットを使っている場合、新しい通信取り込みルールと競合することがあります。LAN上のサービスに接続できなくなったら、まずTUNを無効にして復旧するか確認し、必要な通信だけにダイレクト接続ルールを追加します。すべてのインターフェースのデフォルトルートを一度に変更しないでください。
終了後にシステムプロキシが残った場合は、デスクトップ環境のネットワーク設定から、記録しておいた以前のモードに戻します。TUNを無効にしても問題が続く場合は、クライアントが関連プロセスを正常に終了したかを確認し、ほかのツールがネットワークを制御していないか調べます。リモートデスクトップでは特に慎重に対応してください。ルーティングを変更する場合は、管理接続を失わないよう、ローカルで復旧できる手段を確保します。
ログイン時の起動とサブスクリプションの自動更新は最後に設定します。デスクトップセッションが確立する前にGUIクライアントを起動すると、デスクトッププロキシサービスを利用できないことがあります。Wi-Fiの接続前にサブスクリプションを更新しても、一時的に失敗する可能性があります。手動起動、手動更新、終了時の復元が安定したことを確認してから自動化を有効にすれば、セッションの起動順序と接続情報の問題を切り分けやすくなります。
Android:インポート、VPNの許可、バックグラウンド動作
Androidではv2rayNGを基本とし、V2Flyコアが必要な場合はv2flyNGを選びます。インストールとインポートの基本手順は似ていますが、コアの機能は相互に置き換えられません。スマートフォンの接続ボタンは通常、システムのVPNインターフェースを使って通信を取り込みます。デスクトップでブラウザーにシステムプロキシを設定する操作とは異なります。この違いを知っておくと、「システムプロキシをどこで有効にするのか」と探し回らずに済みます。
アーキテクチャを選んでインストールする
Androidのダウンロードページで、比較的新しい一般的なデバイスにはarm64版を選びます。アーキテクチャが不明な場合や互換性の警告が出る場合は、汎用版を検討し、デバイスのOS要件も確認してください。汎用版は対応アーキテクチャの範囲を広げるもので、古いOSがアプリの実行要件を満たすようにするものではありません。「インストール失敗」をサブスクリプションやサーバーの問題だと決めつけないでください。
インストールファイルを開くと、現在使っているブラウザーやファイルマネージャーからのアプリのインストールを許可するよう求められる場合があります。実際に使う入手元だけを許可し、インストール後は必要に応じて権限を無効にしてください。既存アプリを更新する場合は、必要な設定を事前に保存します。署名が一致しないと表示された場合は、すぐにアンインストールせず、入手元と元のアプリが一致しているか確認してください。アンインストールすると、ローカルのデータも削除されることがあります。
初回起動後は、まずアプリが正常にメイン画面を表示できることを確認してから接続情報をインポートします。デバイスのセキュリティ設定や仕事用プロファイルによってVPN機能が制限されている場合、アプリをインストールできてもシステムがVPN接続を許可しないことがあります。組織管理のデバイスでは管理ポリシーに従い、制限を回避するために再インストールを繰り返さないでください。システム時刻も自動同期に設定します。
サブスクリプショングループ、共有リンクのインポート、アクティブな設定
サブスクリプショングループの設定で名前とURLを追加し、保存してから更新します。メニュー名はクライアントやUIのバージョンによって異なるため、機能を目印に探してください。共有リンク1件を受け取った場合は、クリップボードからのインポート機能や該当するスキャン機能を使います。アカウント管理ページをサブスクリプションとして貼り付けないでください。インポート結果が表示されたら、使う設定をタップしてアクティブにします。
一覧に項目があっても、選択中の設定が正しいとは限りません。更新後に名前が同じ項目が並ぶ場合は、所属グループ、プロトコル、設定の入手元を確認してください。サブスクリプションがXray固有の機能を使う場合は、対応するクライアントで確認します。解析エラーを消すためにセキュリティ項目をむやみに削除しないでください。違いについてはXrayとV2Flyのコア選びを参照してください。
サブスクリプションの更新が成功と表示されても一覧が空の場合は、グループの表示状態とフィルターを確認し、更新ログも見てください。ログイン画面やエラーページが返っている場合、クライアントを変えてもURL自体の問題は解決しません。ネットワークに接続できない場合は、正常な別のネットワークで再確認できますが、サブスクリプションURLは変えないでください。ネットワーク、URL、クライアントを同時に変更すると原因を判断できなくなります。
VPNによる通信の取り込み、アプリごとの振り分け、バックグラウンド制限
接続をタップすると、初回はシステムのVPN接続要求が表示されます。要求元のアプリが正しいことを確認して許可してください。ステータスバーにVPNアイコンが表示されても、システムがインターフェースを作成したことが分かるだけで、接続先のサーバーが利用可能とは限りません。続けてブラウザーで目的のページを開き、クライアントのログを確認します。独自のVPNを使う仕事用アプリと競合する場合があります。通常、同じユーザー環境で同時に利用できる一般的なVPNサービスは1つです。
Androidでは、デスクトップ向けのシステムプロキシ設定を重ねて行う必要はありません。一部のアプリだけプロキシを通らない場合は、クライアントでアプリごとのプロキシ設定が有効か確認し、一覧が「選択したアプリのみをプロキシ経由にする」のか「選択したアプリを除外する」のかを見てください。この2つは逆の意味です。変更後に接続を切って再接続し、対象アプリを開き直します。古い接続が以前の経路を使い続けるのを防げます。
画面ロック後に切断される場合は、システムのバッテリー最適化、バックグラウンド動作、自動起動の設定を確認します。設定の場所はデバイスごとに異なるため、対象クライアントの項目だけを調整し、端末全体の省電力機能を無効にしないでください。最近使ったアプリの一覧に残すだけでは不十分な場合があります。一方、バックグラウンド動作を許可しても無効なサブスクリプションは直りません。まず画面を表示した状態で接続が安定することを確認し、その後にバックグラウンド動作を調べます。
Wi-Fiとモバイルネットワークを切り替えた後は、通常のウェブページにアクセスできることを確認してから再接続します。システムの「VPNを常時接続」や「VPNが切断されたときに接続をブロックする」が有効だと、クライアント終了後にデバイス全体がネットワークにつながらなくなることがあります。切り分けの前に、これらの機能を理解したうえで、一時的に無効にするか判断してください。復旧後は実際の用途に合わせて設定します。システムによる通信遮断をクライアントのフリーズと誤認しないようにしましょう。
プロキシとルーティング:入口と出口を区別する
プロキシ設定は2つの段階に分けて考えられます。最初の段階では、アプリのリクエストをクライアントにどう渡すかを決めます。次の段階では、クライアントに届いたリクエストをどの出口から送るかを決めます。システムプロキシとTUNは主に最初の段階を扱い、ルーティングルールは次の段階を扱います。TUNを有効にしても、すべてのリクエストがプロキシ経由で送信されるとは限りません。ダイレクト接続のルールを選んでも、クライアントを経由しなくなるわけではありません。「グローバル」や「バイパス」といった名称を確認する前に、通信経路を整理しましょう。
システムプロキシの3つの状態とTUNの役割
「システムプロキシを自動設定」は、システム設定に従うアプリをローカルの接続先へ向けます。「システムプロキシをクリア」は該当する設定を解除し、「システムプロキシを変更しない」は現在の状態を維持します。これらは接続品質を示す段階ではありません。ローカルのコアが停止しているのに、システムがそのポートを参照し続けていれば、ブラウザーは接続できません。システムプロキシを解除すると、コアが動作中でもブラウザーはプロキシを通らず直接接続することがあります。
TUNは仮想ネットワークインターフェースを通して、取り込み対象の通信を受信します。システムプロキシを参照しないアプリにも適していますが、権限、ルーティング、DNSの連携が新たに必要です。環境によっては両方を併用できますが、初回の切り分けで同時に有効にするのは避けてください。まずシステムプロキシの経路が正常に動くことを確認してからTUNを追加すれば、新たに加えた通信取り込み層に問題があるか判断できます。
| 設定レイヤー | 解決すること | 保証しないこと |
|---|---|---|
| システムプロキシ | アプリがローカルのプロキシ接続先を使うか | すべてのアプリが設定を参照するとは限らない |
| TUN | 仮想インターフェースと通信の取り込み | 接続先サービスが利用できるとは限らない |
| ルーティングルール | リクエストがどの出口にマッチするか | 誤った接続認証情報は修正しない |
| DNS | ドメインの名前解決と関連するマッチ条件 | 転送と認証の設定は別途必要 |
まずプリセットを使い、必要最小限のルールを追加する
初回はクライアントが用意している適切なルーティングプリセットを選び、基本接続を確認してから、特定のサイトやLAN上のサービスを調整します。通常、ルールは上から順に評価されます。範囲の広いルールが先にあると、後続の具体的なルールにマッチしない場合があります。ルールを追加したら、配置順、マッチ条件、出口名を確認してください。ドメインを一覧に追加しても、誤った出口を指定すれば期待と逆の結果になります。
geosite:cnは該当するドメインリストを参照し、geoip:privateはプライベートアドレスのリストを参照します。これらは実行環境が対応するルールデータを提供する必要があり、すべての設定で常に使えるわけではありません。directは通常、設定の作成者がダイレクト接続の出口に付けたラベルです。同じ名前の出口が実際に定義されている場合にのみルールから参照できます。コアが自動的に認識する予約済みの出口名だと考えないでください。
LAN上のプリンター、家庭用ストレージ、ルーターの管理画面にアクセスできない場合は、まずプライベートアドレスがダイレクト接続されているか、対象の名前が正しいローカルアドレスに解決されるか確認します。LAN内のデバイス検出にはブロードキャストやマルチキャストが関わることがあり、ウェブページへのアクセスとは仕組みが異なります。デバイス一覧が空だからといって、すべての通信をダイレクト接続にしないでください。アドレスを直接指定した接続と、自動検出機能を分けてテストします。
DNSの設定と検証方法をあわせて考える
ドメインルールではクライアントがリクエスト先の名前を把握する必要があり、アドレスルールは宛先のIPアドレスに依存します。アプリが事前に名前解決する場合、暗号化DNSを使う場合、またはプロキシにアドレスだけを送る場合は、マッチ条件が変わることがあります。DNSの動作はクライアントの通信取り込み方式にも左右されます。ドメインへのアクセスに失敗したら、証明書の検証を無効にしたり、すべてのDNSサーバーをむやみに置き換えたりする前に、名前解決結果とルーティングログを確認してください。
ブラウザーのセキュアDNS、システムの名前解決、クライアントのDNS、TUNによるDNSの取り込みが同時に使われていることがあります。まず、どの機能が名前解決を担当しているか記録してから、そのうち1つだけ変更してください。変更後にブラウザーだけ挙動が変わった場合は、ブラウザー独自の設定を確認します。すべてのアプリで失敗する場合は、システムネットワークと通信の取り込み層に戻って確認してください。名前解決のキャッシュが再テストに影響することがあるため、設定変更後は対象アプリを再起動して新しい接続を作成します。
ルールを検証するときは、対象とアクティブなサーバーを1つに固定し、ルールを1つだけ変更して、新しいリクエストがどの出口にマッチするか確認します。ページのキャッシュ、既存の長時間接続、接続の再利用によって、結果がすぐに反映されない場合があります。対象アプリを終了してから開き直し、必要に応じてクライアントを再接続してください。同じページを連続で再読み込みするだけでは不十分です。ログに記録された対象と出口が、実際にテストした時刻に対応するかも確認します。
「グローバル」という言葉は、クライアントによって通信の取り込み方式を指す場合も、ルーティングプリセットを指す場合もあります。問題を説明するときは、具体的なメニュー名と選択項目を記載してください。ルールは多いほど正確になるわけではありません。カスタムルールの用途を記録しておけば、異常時に追加した順番で元に戻せます。日常的に必要なサイトやアプリへの対応に絞り、表示されている高度な設定をすべて有効にする必要はありません。
設定ファイル:入口からルーティングまで
GUIクライアントは通常、サーバー、サブスクリプション、ルーティングの設定に基づいて実行用の設定ファイルを生成します。画面上の1つの選択が、設定ファイル内の複数の項目に影響することもあります。設定ファイルを読むと問題の切り分けに役立ちますが、実行中のファイルを直接編集しても変更が保存されるとは限りません。サーバーの切り替え、サブスクリプションの更新、コアの再起動時に、クライアントが再生成する場合があります。長期的に保持する設定は、まずGUIまたは専用のカスタム設定機能で管理してください。
主な設定項目とタグ参照を理解する
inboundsは、待ち受けアドレス、ポート、プロトコルなど、リクエストをローカルで受け取る入口を定義します。outboundsはリクエストの送信に使う出口を定義し、routingはリクエストと出口の対応を決めます。入口のポートはリモートサーバーのポートとは異なります。両者を取り違えると、ローカルアプリが接続できなくなったり、コアが誤った接続先へ接続を試みたりします。
tagは設定内で参照する名前です。分かりやすい名前を付け、重複しないようにしてください。ルーティングのoutboundTagは、定義済みの出口を参照する必要があります。大文字と小文字も一致させます。logはログの動作を制御し、dnsはコア関連の名前解決設定を定義します。これらを追加しても、出口の不足は補えず、サブスクリプションの認証情報の誤りも自動で修正されません。
動作するダイレクト接続設定で構造を確認する
以下はXrayのダイレクト接続用の設定例です。SOCKSの接続先をループバックアドレスだけで待ち受け、リクエストをダイレクト接続の出口へ送ります。リモートのプロキシサービスは含まれず、通信をサブスクリプションのサーバーへ送信するものでもありません。設定構造を理解するための例であり、クライアントが生成した実運用設定を置き換えないでください。利用する場合は、カスタム設定に対応した機能から別途保存し、選択してください。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom"
}
],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["local-socks"],
"outboundTag": "direct"
}
]
}
}
例で使う待ち受けポートは、ほかのプログラムが使用していない必要があります。クライアントの既存コアが同じポートを使用している場合は、旧設定を停止するか、独立した設定で別のポートを使い、テスト用アプリの接続先も変更してください。この例では通信範囲が同じデバイス内に限られるため、ローカルのみで待ち受け、認証は設定していません。十分に検討せず、待ち受けアドレスをすべてのネットワークインターフェースに変更しないでください。
この設定のSOCKS接続先をHTTPプロキシとして使うことはできません。SOCKSに対応するブラウザーやアプリでは、ローカルアドレスと該当するポートを入力します。HTTPプロキシ専用の入力欄に同じプロトコルを指定することはできません。接続先がUDPに対応していても、通信経路全体で利用できるとは限りません。アプリ、通信の取り込み方式、実際の出口が、それぞれ該当する転送方式をサポートしている必要があります。
変更範囲とエラーからの復旧
JSONのオブジェクトではキー名を二重引用符で囲みます。標準のJSONにはコメントを自由に追加できず、最後の要素の後ろに余分なカンマも置けません。ブール値や数値を、コピー時の習慣で一律に引用符で囲まないでください。解析エラーが出たら、ログに示された行と列の周辺で括弧、引用符、カンマを確認します。構文が解析できるようになる前に、ネットワークのパラメーターを変更しないでください。
構文が正しくても、それで完了ではありません。コアは続いて項目、プロトコル、参照関係を検証し、その後に実際のネットワーク接続を開始します。問題を「テキストの解析失敗」「設定の検証失敗」「接続の確立失敗」に分けると、原因を大幅に絞り込めます。未知の項目や未対応のセキュリティモードがログに表示された場合は、現在のコアの種類と設定の入手元を確認してください。起動させるために重要な項目を削除しないでください。
TLSやREALITYを使う場合、サーバーアドレス、検証名、その他のネゴシエーションパラメーターにはそれぞれ異なる役割があります。接続情報どおりに正確に設定してください。サーバー証明書の検証問題を単なるスイッチの不具合と考えたり、エラーを消すために検証を長期間無効にしたりしないでください。まずデバイスの時刻、接続情報の有効期限、コアの対応状況を確認し、必要に応じて接続情報の提供元に問い合わせます。
カスタム設定は、GUIのすべてのオプションを自動で引き継ぐとは限りません。画面でルーティングを変更しても、独立した設定ファイルのルールには反映されないことがあります。反対に、ファイルを編集してもサーバー一覧が更新されるとは限りません。各セクションの関係を詳しく知りたい場合は、設定ファイルのJSON構造を詳しく解説した記事を参照してください。まず設定の入手元と適用先を確認してから、変更方法を決めましょう。
設定のよくある問題:失敗した箇所から確認する
トラブルシューティングでは、まず「どの手順で失敗したか」を明確にし、確認する対象を決めます。インストール失敗は実行環境、サブスクリプションの失敗は接続情報の取得または解析、コアの起動失敗はローカル設定の問題です。起動後にページを開けない場合は、通信経路とリモート接続を確認します。以下ではよくある症状ごとに、まず最小構成で復旧し、その後に高度な設定を1つずつ戻す方法を説明します。設定を何度も切り替えて運任せにしないでください。
サブスクリプションの失敗、一覧が空、プロトコルの非対応
サブスクリプションの更新がタイムアウトしたら、まず基本ネットワークを確認し、URLが完全か、既存のプロキシが必要かを調べます。内容は取得できても解析に失敗する場合は、エラーページが返っていないか、現在のクライアントがその形式に対応しているか確認してください。リンク切れ、アカウント状態の変化、古いクライアントも原因になり得ます。「昨日は使えた」という理由だけで接続情報の入手元を問題から除外せず、具体的なメッセージをもとに判断します。
更新に成功しても項目が表示されない場合は、キーワードフィルターを解除し、現在のグループと非表示状態を確認してから、どのグループを更新したか確認します。すぐにすべてのグループを削除して作り直さないでください。複数のサブスクリプションがある場合は、関係のないグループを一時的に無効にすると、同名項目による混乱を減らせます。整理方法はv2rayNのサブスクリプショングループとフィルターの解説を参照してください。
未対応のプロトコルや項目が表示されたら、まず設定が要求するコアを確認します。UIテーマを変えたり、ポートを変更したり、TUNを有効にしたりしても、プロトコルへの対応は追加されません。デスクトップでv2rayNを使う場合は、アクティブな設定に対応するコアの種類を確認します。Androidでは、XrayまたはV2Flyの要件に合わせてクライアントを選んでください。移行後は設定を1つだけテストし、使えることを確認してから残りをインポートします。
接続成功と表示されるのにページを開けない
まず、クライアントがコアを起動しただけなのか、実際のリクエストログが記録されているのか確認します。リクエストが届いていない場合は、システムプロキシ、アプリ独自のプロキシ、またはTUNの通信取り込み範囲を確認してください。リクエストが記録されているのに接続できない場合は、リモートアドレス、認証、転送方式、DNSを調べます。ステータスバーの接続表示が示すのはローカルの状態であり、目的のサイトにアクセスできることの証明にはなりません。
すべてのドメインで失敗し、一部のIPアドレスには直接アクセスできる場合、DNSを確認項目に加えることはできますが、それだけで原因と決めつけてはいけません。暗号化されたサイトでは通常、ドメイン名と証明書の照合が必要です。IPアドレスを直接開いて証明書の警告が出ても、同等のテストにはなりません。ログにある名前解決エラー、リクエスト先、出口をあわせて確認し、テストを完了するために証明書の警告を無視しないでください。
特定のサイトだけで失敗する場合は、同じ設定でほかの正常な接続先をテストし、そのサイトのルーティング、アプリのキャッシュ、接続先側の制限を確認します。特定のアプリだけが失敗する場合は、システムプロキシを使っているか、アプリごとのルールで除外されていないか調べてください。サーバーを切り替えて復旧した場合は、その差を記録して続けて確認します。一度成功しただけで設定全体が正しいと判断しないでください。
TUNを有効にした後、デバイス全体がネットワークにつながらなくなった場合は、まずTUNを無効にし、今回のテストで追加した通信取り込み層を解除して、動作確認済みのシステムプロキシに戻します。その後、権限、仮想インターフェース、ほかのVPNツール、DNSの取り込みを確認してください。復旧は一度に1項目ずつ進めます。リモート接続で管理しているデバイスでは、ローカルで復旧できる方法を確保してください。唯一の管理経路でルーティングの変更を続けないでください。
終了、更新、デバイス間の移行
クライアント終了後にページを開けなくなった場合は、停止したローカルプロキシをシステムがまだ参照していないか確認します。まず元のシステムプロキシの状態に戻し、その後で基本ネットワークを調べてください。Androidでは「VPNを常時接続」と、切断時の通信ブロック設定も確認します。ネットワーク設定のリセットを最初に行わないでください。Wi-Fi、仕事用ネットワーク、残しておきたいほかの設定も消えることがあります。
アップグレード後に問題が起きたら、まず旧インスタンスを正常終了し、新しい起動項目と設定フォルダーを確認してください。自動起動の項目を2つ同時に残さないようにします。カスタム設定を使っている場合は、新しいコアが従来の項目を引き続き受け付けるか確認してください。サブスクリプションから設定を生成する場合は、まず既定のオプションで再テストします。バックアップを残してから移行し、更新と同時に唯一の復旧用設定を削除しないでください。
デバイス間の移行では、システムの通信取り込み設定全体をそのままコピーせず、サブスクリプションの入手元と必要なルールを優先して移します。ローカルポート、待ち受けアドレス、権限、インターフェース名は、新しいデバイスで異なる場合があります。まず新しいデバイスで接続を1つ確認し、その後にグループ、自動更新、アプリごとの振り分けを追加します。旧デバイスを使わなくなったら、システムプロキシと自動起動を解除し、把握しにくいバックグラウンド状態が残らないようにしてください。
さらにサポートが必要な場合は、OS、クライアント名、コアの種類、失敗した手順、機密情報を隠したエラーメッセージ、TUNの使用有無を整理してください。サブスクリプションURLやアカウントの認証情報をそのまま添付しないでください。個別の問題はよくある質問でも確認できます。まだ接続に成功したことがない場合は、クイックスタートガイドに戻り、既定の設定で基本の手順を試してください。