DOCUMENTATION / インストール・設定ガイド

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

プラットフォーム別のインストール手順と、通信経路に沿ったトラブルシューティングを解説。サブスクリプションの追加、システムプロキシ、TUN、ルーティング、DNSの設定範囲を確認できます。

初めて接続する場合は、まず利用ガイドのクイックスタートに沿って進めてください。このページでは、設定項目やプラットフォームごとの差を理解し、問題の原因を特定する方法を解説します。ダウンロード先はクライアントページにまとめています。画面上の名称はクライアントの更新によって変わる場合があるため、設定の意味を手がかりに探してください。

  • サブスクリプションと共有リンク
  • システムプロキシ / TUN
  • routing / DNS
  • 段階別トラブルシューティング

準備 / クライアントとネットワークの前提

共通の準備：設定の入手元と通信の制御方法を確認

クライアント、コア、接続設定を区別する

v2rayNはデスクトップ向けのGUIクライアントです。サーバー情報の保存、サブスクリプションの管理、実行用設定の生成、システムプロキシなどの制御を担います。実際の接続は、v2rayNが呼び出すコアが行います。Project Vは関連するプロキシ技術のプロジェクトで、V2FlyとXrayは代表的なコアの系統です。Androidでは、Xrayをコアに採用したv2rayNG、またはV2Flyをコアに採用したv2flyNGを利用できます。クライアント名が似ていても、対応する設定が同じとは限りません。接続情報を受け取ったら、まずプロトコル、転送方式、安全性の設定を確認し、選んだクライアントとコアで扱えるかを確かめてください。

クライアントをインストールしても、利用可能なサーバーが自動的に用意されるわけではありません。利用を始める前に、信頼できる入手元のサブスクリプションURL、単一の共有リンク、またはサーバー設定一式を準備してください。サブスクリプションURLには通常、アカウントを識別する情報が含まれます。URLを知る人が同じ接続情報を取得できる場合があるため、スクリーンショットやフォーラム、共有メモに公開しないでください。また、システムの日付とタイムゾーンが正しいこと、ネットワークから必要なサービスにアクセスできることも確認します。時刻が大きくずれていると証明書の検証に影響し、時刻に依存する認証が失敗する場合もあるため、ノードが使えないと誤認しやすくなります。

アーキテクチャを確認してからインストール方法を選ぶ

デスクトップではv2rayNを使用し、ダウンロードページでOSとプロセッサのアーキテクチャに合ったものを選んでください。Macは「このMacについて」でチップを確認します。Windowsは「システム情報」の「システムの種類」、Linuxはプロセッサのアーキテクチャとディストリビューションのパッケージ形式を確認してください。Androidでは通常arm64を選びます。端末のアーキテクチャが不明な場合や、互換性がないというインストールエラーが出た場合に限り、汎用パッケージを検討してください。ファイル名に見覚えのある単語があるからといってアーキテクチャを推測したり、異なるOSのパッケージを使い回したりしないでください。すでにクライアントを使っている場合は、現在の動作モードと必要な設定を記録してから更新し、更新とネットワーク設定の変更を同時に行わないようにします。

方式制御する場所主な制約
システムプロキシOSのプロキシ設定アプリ側がこの設定を参照する必要がある
アプリごとの手動プロキシ設定アプリ固有のHTTPまたはSOCKS設定設定したアプリだけに適用
TUN仮想ネットワークインターフェースとルーティング権限、除外ルール、コアの実装によって異なる

元に戻せる初期状態を用意する

初回の設定はシステムプロキシから始め、TUN、サードパーティ製の通信最適化ツール、別のプロキシクライアント、カスタムDNSを同時に有効にしないでください。システムプロキシは、設定に従うアプリの通信をローカルの待ち受けポートに送るもので、すべての通信がプロキシを通るわけではありません。TUNは仮想インターフェースを通じてルールに合う通信を制御するため、ルーティングや権限も関係し、調査範囲が広がります。ブラウザーの接続だけが必要なら、まずシステムプロキシを使います。システムプロキシを参照しないアプリがある場合に、手動プロキシやTUNを検討してください。必要なことと動作モードを対応づけると、どの症状が仕様上の制約なのか判断しやすくなります。

クライアントに表示されている実際の待ち受けアドレス、ポート、現在のサーバーを記録してください。例示のポートを自分の環境の値と取り違えないようにします。自分の端末だけで使う場合は、ループバックアドレスでの待ち受けを維持し、LAN全体に公開しないでください。テストには一般的なHTTPSサイトを1つ選び、比較用に別の独立したサービスも用意します。特定サイトのアカウント制限、地域別ポリシー、サービス障害だけでは、クライアント全体の問題とは判断できません。設定を変えるときは一度に1項目だけ変更し、保存後にログとアクセス結果を確認してから、変更を維持するか元に戻すか決めてください。

インストール前に、保存先に書き込みできるか、古いプロセスが待ち受けポートを使用していないか、会社や学校の端末でネットワークが管理ポリシーにより制御されていないかも確認してください。管理対象端末では、プロキシ、証明書、仮想ネットワークの権限を自分で変更できない場合があります。その場合は端末の管理ルールに従い、ポリシーを回避しようと繰り返し試さないでください。すでに使える設定がある端末では、必要な情報をエクスポートして安全に保管します。エクスポートデータにはアクセス認証情報が含まれることがあるため、機密情報のない一般的な設定ファイルとして共有してはいけません。

プラットフォーム / macOS

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

チップに合った版を選び、アプリの保存先を固定する

Appleメニューから「このMacについて」を開き、Appleシリコン搭載機ならApple Silicon版、Intelプロセッサ搭載機ならIntel版を選びます。macOSのダウンロードから対応するインストーラーを入手し、ディスクイメージを開いてv2rayNを「アプリケーション」フォルダにドラッグしてから起動してください。ディスクイメージ内から使い続けたり、削除される可能性のある一時フォルダに置いたりしないでください。アプリの保存場所を固定すると、権限の保持や今後の更新がしやすくなります。初回起動後に終了する場合は、インストール用ディスクイメージを取り出しても、コピー済みのアプリには影響しません。

システムに開けないと表示された場合は、まずダウンロード元、チップの選択、インストールの完了を確認し、「システム設定 → プライバシーとセキュリティ」に今回の起動を許可する操作が表示されているか確認してください。入手元を確認したうえで、システムが用意する一度限りの許可方法だけを使い、アプリを開くためにシステム全体の保護を無効にしないでください。組織の管理下にある端末では、ポリシーにより権限が制限されている場合があります。何度もダブルクリックしても通常は状況は変わりません。表示されたメッセージ全文を控え、システムのセキュリティによるブロック、アプリの破損、プロセッサの非互換性を区別してください。それぞれ対処方法が異なります。

サブスクリプションを追加し、現在のサーバーを確認する

サブスクリプショングループの設定を開き、新しいグループを作成して完全なサブスクリプションURLを入力します。保存した後、サブスクリプションの更新も実行してください。グループ名が表示されても、サーバーの取得に成功したとは限りません。更新後にサーバー一覧を確認し、そこから1つ選んで現在のサーバーに設定します。プロトコルのプレフィックスで始まる単一の共有リンクを受け取った場合は、クリップボードからのインポートを使い、リモートサブスクリプション欄には入力しないでください。ビルドによってメニューの配置が変わる場合がありますが、操作の目的は「サブスクリプション元を保存 → 更新 → サーバーを選択」です。スクリーンショットだけを頼りにボタンを探さないでください。

続いて「システムプロキシを自動設定」を有効にし、クライアントのコアが起動していることを確認します。この操作はシステムのネットワークプロキシ設定を書き換え、設定に従うアプリをローカルプロキシに接続させます。Wi-Fiの変更、有線LANへの切り替え、新しいネットワークサービスの追加後に動作が変わった場合は、現在使っているネットワークサービスのプロキシ設定を開き、クライアントが待ち受けているアドレスとポートを指定しているか確認してください。必要性を確認せずにすべてのプロキシ方式を有効にしないでください。HTTP、HTTPS、SOCKSを設定する必要があるかは、クライアントの自動設定と利用するアプリの要件に従います。

TUN、スリープ復帰、終了後のネットワーク

システムプロキシが動作することを確認してから、TUNが必要か検討します。有効にする前に、使用中のビルドに表示される権限の説明を読み、必要に応じて補助コンポーネントやネットワーク機能を許可してください。また、別の仮想ネットワークツールがデフォルトルートを同時に制御していないことを確認します。TUNを有効にした後、通常のネットワークまで使えなくなった場合は、まずTUNを無効にしてシステムプロキシモードが引き続き正常か確かめてください。スイッチが有効と表示されていても、仮想インターフェース、ルーティング、DNSのすべてが正常に設定されたとは限りません。権限不足、インターフェース作成失敗、ルート設定失敗がコアのログにないか確認してください。

Macがスリープから復帰した後、ネットワークのホットスポットを切り替えた後、またはドッキングステーションを接続した後は、既存の接続が切れている場合があります。まず現在のネットワークが使えることを確認し、クライアントに再接続してください。一部のアプリだけに問題がある場合は、そのアプリを完全に終了して再起動します。切断された接続を古い接続プールが使い続けるのを防げます。ブラウザーは使えるのにターミナルで失敗することは珍しくありません。多くのコマンドラインプログラムはシステムプロキシを参照せず、個別にプロキシを指定する必要があります。逆に、ターミナルで使えても、ブラウザー独自のプロキシ設定や拡張機能が影響していないとは限りません。テストでは接続経路を区別してください。

通常終了する前にシステムプロキシを解除し、TUNを無効にしてください。アプリが予期せず終了してWebページを開けなくなった場合は、現在のネットワークサービスのプロキシ設定を開き、停止したローカルポートが参照されたままになっていないか確認します。今回のクライアントが書き込んだ設定だと確認できたものだけを削除してください。組織が設定したプロキシを、よく分からないまま削除しないでください。同じネットワークの端末と共有する場合は、自分の端末のループバックアドレスを相手に伝えるだけでは接続できません。待ち受け範囲やファイアウォールも設定する必要があります。詳しくはLANからの接続を許可する方法を参照してください。

プラットフォーム / Windows

Windows：デスクトップ版、WPF版、プロキシによる通信制御

UIの種類を選び、実行データの保存先を分ける

Windowsのダウンロードには、v2rayNデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来のWindows向けUIを維持しています。どちらもGUIクライアントであり、UIの違いがサーバープロトコルの違いを意味するわけではありません。端末のアーキテクチャとインストーラーの説明に従って選び、実行コンポーネントが不足している場合は、起動時に表示された内容を確認してください。他のユーザーのスクリーンショットだけを根拠に、自分の端末にも特定の依存コンポーネントが不足していると判断したり、起動確認のために入手元不明のランタイム一式をまとめてインストールしたりしないでください。

インストール先または展開先には書き込み権限が必要です。読み取り専用の場所や、一時的な圧縮ファイルの表示内から直接実行しないでください。2種類のUIを同時に比較する場合は、プログラムとデータの保存先をそれぞれ分け、必要な設定をあらかじめエクスポートします。2つのプロセスに同じデータを同時に書き換えさせないでください。タスクバーや通知領域に古いインスタンスが残っていないかも確認します。複数起動するとポートが競合したり、実際には別のインスタンスがシステムプロキシを制御しているため変更が反映されないように見えたりする場合があります。ウィンドウを閉じると終了するかどうかは、通知領域の状態とプロセスで確認してください。

サブスクリプション更新とシステムプロキシ設定は別の操作

サブスクリプショングループを追加したら更新を実行し、サーバー一覧から現在使うサーバーを選びます。まず更新ログでコンテンツの取得に成功したかを確認し、その後サーバーに接続できるかを調べてください。他の端末からリンクをコピーした場合は、改行、空白、末尾のクエリパラメーターに注意します。チャットアプリでは、表示文字列と実際のリンク先が別になっていることがあります。インポート後に名前が表示されても接続できない場合は、プロトコル、安全性の設定、転送方式の項目がそろっているか確認してください。サーバー名だけを根拠に設定が同じだと判断しないでください。手動で変更する前に、元の情報を保存して復元できるようにします。

「システムプロキシを自動設定」を有効にすると、Windowsのユーザープロキシ設定に従うアプリはローカルプロキシを使おうとします。ブラウザーがアクセスできても、システムサービス、バックグラウンド更新プログラム、すべてのコマンドラインツールが同じ経路を通るとは限りません。アプリ独自のプロキシ設定や異なるネットワークインターフェースを使うプログラムもあります。初回テストは標準のユーザー権限で行い、TUNや明確な権限要求があるシステム操作に限って、より高い権限を使ってください。管理者として常に実行しても、サブスクリプションの誤りやサーバー設定の不一致は修正されません。むしろ権限と設定の問題を区別しにくくなります。

ファイアウォール、TUN、ポート競合への対処

ログにポートのバインド失敗が表示されたら、まず他のプロキシプログラムを停止し、古いv2rayNのプロセスが残っていないか確認してから、ローカルポートの変更を検討します。ポートを変更した場合、プロキシを手動設定したすべてのアプリにも反映し、システムプロキシも再設定してください。ファイアウォールの警告への対応は、プログラムの入手元、ネットワークの種類、利用範囲を考慮して決めます。端末1台だけで使うなら、通常はLANからの受信接続を積極的に許可する必要はありません。問題を調べるためにファイアウォール全体を無効にせず、ブロックされたプログラムや接続を特定し、対象範囲を限定したルールを追加してください。

TUNは仮想ネットワークインターフェース、ルーティング、権限に関わるため、まずシステムプロキシモードで動作を確認してください。端末で別の仮想ネットワークツールも実行していると、デフォルトルート、DNS、ネットワークセグメントが競合する場合があります。TUNの起動後にすべての通信が途切れたら、まずTUNを無効にして通常の接続を復旧し、インターフェース作成やルーティングに関するログを確認します。他のツールを停止して復旧した場合は、制御対象の範囲を1つずつ比較してください。クライアントを何度も再インストールする必要はありません。リモートデスクトップ環境では、ルートの変更で現在の管理接続が切れるおそれがあるため、特に慎重に操作してください。

ネットワークを元に戻すときは、クライアントでシステムプロキシを解除してから終了します。クライアントがクラッシュした場合は、Windowsのプロキシ設定で手動プロキシが残っていないか確認してください。自動構成スクリプトと手動プロキシは別の設定です。端末に組織が配布したスクリプトがある場合、それまで一緒に消さないでください。スリープやネットワーク切り替え後に問題が起きた場合も、アプリを再インストールする前に接続を再起動してみます。更新前にサブスクリプション元とカスタムルーティングを保存し、更新後は追加機能を有効にする前に、従来のシステムプロキシの手順を再テストしてください。問題が起きた場合に、更新と新しい設定のどちらが原因か判断しやすくなります。

プラットフォーム / Linux

Linux：パッケージ、デスクトッププロキシ、権限の範囲

アーキテクチャとディストリビューションのパッケージ形式を確認

Linuxにインストールする前に、プロセッサがx86_64かaarch64か、ディストリビューションがdebとrpmのどちらを使うかを確認します。前者はプログラムを実行できるか、後者はシステムのパッケージ管理ツールでインストールできるかに関わり、互いに代用できません。Linuxのダウンロードで、アーキテクチャと形式に合ったv2rayNを選んでください。GUIインストーラーでインストールできない場合は、まず具体的なエラーを確認し、アーキテクチャの不一致、依存関係の不足、システム環境の非対応を区別します。あらゆるインストール失敗をファイル破損と決めつけないでください。

以下の読み取り専用コマンドで環境を確認できます。uname -mの結果がx86_64なら通常はx64、aarch64なら通常はarm64に対応します。ディストリビューション名とバージョンはパッケージ管理方式を判断する参考になりますが、同じ形式のパッケージなら必ず互換性があるわけではありません。依存関係はディストリビューション標準のソフトウェアリポジトリとパッケージ管理手順を使ってインストールし、複数の不明な入手元から基盤ライブラリを寄せ集めないでください。起動直後に終了する場合は、デスクトップアプリの起動記録やターミナル出力でエラーを確認し、グラフィカル環境の問題か、コアが起動していないのかを切り分けます。

uname -m
cat /etc/os-release

サブスクリプションを追加したら、デスクトップ環境のプロキシ設定を確認

v2rayNを起動し、サブスクリプショングループを作成してURLを保存した後、サーバー一覧を更新し、現在使うサーバーを選びます。Linuxのクリップボードはデスクトップセッションが管理するため、リモートセッション、表示プロトコルの違い、権限の変更などで読み取れない場合があります。クリップボードからインポートできない場合は、まず現在のユーザーのクリップボードにリンクがあるか確認し、必要ならクライアントの手動入力機能を使ってください。クリップボードを読み取れないからといって、プロトコルが非対応だと判断しないでください。また、そのためにクライアント全体を高い権限で実行し、データの所有者とデスクトップセッションが食い違う状態にしないでください。

デスクトップ環境によってシステムプロキシの実装は異なります。クライアントによる自動設定後、すべてのディストリビューションで同じように動作すると決めつけず、使用中のデスクトップ環境のネットワークプロキシ設定を開いて確認してください。ブラウザーはデスクトップのプロキシ設定を参照することがありますが、ターミナルのプログラムは独自の引数やプロキシ環境変数を使うことがよくあります。すでに起動しているプロセスが環境変数の変更を再読み込みするとも限りません。テストでは、特定のコマンドに一時的にプロキシを明示して、「コアが接続できるか」と「デスクトッププロキシが参照されるか」を切り分けられます。診断用コマンドはトラブルシューティングの章で説明します。

ループバック待ち受けとTUNの権限を理解する

自分の端末だけで使う場合は、ループバックアドレスでの待ち受けを優先してください。すべてのネットワークインターフェースで待ち受けると、自分の端末から接続しやすくなるだけでなく、同じネットワーク上の端末にもポートが公開される場合があります。ファイアウォールとアクセス制御も検討してください。サーバー一覧で選択するリモートアドレスと、ローカルの受信待ち受けアドレスは別の設定です。互いに置き換えないでください。ポートが使用中の場合は、古いクライアントや別のプロキシプロセスがないか確認します。ポート変更後はデスクトップのプロキシ設定を再適用し、ターミナルやアプリに直接入力したアドレスも更新してください。新しいコアが正常に待ち受けても、アプリが古い宛先に接続し続ける場合があります。

TUNでは通常、仮想インターフェースの作成とルーティングの変更に権限が必要です。具体的な許可方法は、ディストリビューションとクライアントのビルドによって異なります。クライアントの明確な説明に従って許可し、プログラムのディレクトリ全体にむやみに広い権限を付与しないでください。まず通常ユーザーとしてサブスクリプションと設定を管理し、明示的に必要とされたネットワーク機能にだけ対処します。別のユーザーで起動するとデータディレクトリも変わり、「サーバー一覧が消えた」ように見える場合があります。その場合は実行ユーザーとデータの保存先を確認してください。元のディレクトリをすぐに上書きしたり、空の画面を見て元データが削除されたと判断したりしないでください。

ネットワークに問題がある場合は、コンテナネットワーク、別のトンネル、カスタムルートが同時に存在し、TUNの制御範囲と重複していないか確認します。TUNを無効にすると復旧するなら、リモートサーバーの設定ではなく、ルーティングとDNSを確認してください。終了前にデスクトッププロキシを元に戻し、予期せず終了した後は、起動スクリプトでプロキシ環境変数が永続的に設定されていないか確認します。メンテナンス用に使える設定のコピーを保管し、アップデート後はプログラムの起動、サブスクリプション更新、システムプロキシ、TUNの4項目を確認してください。デスクトップ環境の変更をクライアント自体の問題と取り違えにくくなります。

プラットフォーム / Android

Android：v2rayNG、v2flyNG、VPNの許可

コアを選んでからインストーラーのアーキテクチャを選ぶ

Androidのダウンロードでは、Xrayコアを使用するv2rayNGを第一候補として案内しています。V2Flyコアを使用するv2flyNGは、互換性が必要な場合の選択肢です。サーバーのプロトコルと転送設定を基準に選び、名前が似ているからといって何度も切り替えないでください。新しめの一般的な端末の多くはarm64を選べます。汎用パッケージは対応するアーキテクチャが広い反面、通常はファイルサイズが大きくなります。インストーラーに解析失敗や非互換の警告が出た場合は、システム要件、パッケージのダウンロード完了、アーキテクチャを確認してください。すべてのエラーを端末の性能不足と決めつけないでください。

ブラウザーやファイル管理アプリからインストーラーを開くと、Androidでその入手元からのアプリインストールを許可するよう求められる場合があります。実際に使う入手元だけに必要な許可を与え、インストール後は必要に応じて取り消してください。既存のクライアントを更新する際、署名、インストール元、パッケージの識別情報が異なるために上書きできない場合があります。まず必要なサブスクリプションとカスタム設定を保存してから、移行するか判断してください。アンインストールするとアプリ内のデータに影響するため、最初の対処として行うべきではありません。特に、ダイアログの「更新に失敗しました」という表示だけで、保存済みのサーバー設定まで使えなくなったと判断しないでください。

インポート、更新、接続の開始

v2rayNGのサブスクリプショングループ設定にURLを追加し、保存後にサブスクリプションを更新して、サーバー一覧から1つ選びます。単一の共有リンクを受け取った場合は、クリップボードまたはQRコードからインポートしてください。QRコードは設定を渡すための形式にすぎず、テキストリンクより多くの情報を含むわけではありません。追加したばかりのサーバーが現在の接続先として選ばれているか確認し、一覧の更新後も古い項目を使い続けないようにします。v2flyNGではメニュー名が異なる場合がありますが、リモートサブスクリプションの更新と単一設定のインポートは同様に区別してください。一般的なWebページのURLをサブスクリプションとして扱うことはできません。

接続を開始すると、システムからVPN接続の許可を求められます。この許可は、Androidの仮想ネットワークインターフェースを通じてクライアントが通信を受け取るためのものです。サーバーへの接続成功を意味するわけではなく、すべてのアプリの通信が必ずリモートプロキシを経由するわけでもありません。ステータスバーに接続中のアイコンが表示されても、通信制御の仕組みが動作中だと分かるだけです。クライアントのログと実際のアクセス結果も確認してください。デスクトップの「システムプロキシを書き込む」操作をそのままAndroidに当てはめないでください。Androidクライアントでは通常、システムのVPNサービスを通信の入口として使いますが、ルーティングルールによって一部のリクエストが直接接続されることもあります。

アプリごとの振り分けとバックグラウンド動作

アプリごとのプロキシ設定には通常、「選択したアプリだけをプロキシする」と「選択したアプリを除外する」という逆の動作があります。画面の説明に従ってください。設定を変更したら、サービスを停止して再起動してから対象アプリをテストします。古い接続が以前の経路を使い続けるのを防げます。原因を調べる間はアプリ別の絞り込みを無効にし、通信の対象範囲を明確にしてください。基本の接続を確認してから、例外を1つずつ追加します。Webページは開けても特定のアプリが使えない場合は、そのアプリ独自のDNS、長時間接続、アカウントの状態、サービス側のポリシーが原因の可能性もあります。1回の失敗だけでクライアント全体のプロトコル設定を変えないでください。

画面が点灯している間は正常でも、ロック後に切断される場合は、バッテリー最適化、バックグラウンド動作、メーカー独自の自動起動管理を確認してください。必要なクライアントに限って制限を緩和し、システムの省電力機能をすべて無効にする必要はありません。常駐通知がシステムに制限されると、バックグラウンドサービスの継続に影響することもあります。Wi-Fiからモバイルデータに切り替えた後は、切り替えが完了するのを待ってから接続を再起動してテストしてください。特定のネットワークだけで失敗する場合は、ネットワーク権限とサーバーへの到達性を比較し、すぐにサブスクリプションを削除しないでください。モバイル回線の電波状態、通信制限、テザリング環境も結果に影響します。

最初から「常時接続VPN」や「VPNを使わない接続をブロック」などのシステムポリシーを有効にしないでください。再起動、画面ロック、ネットワーク切り替え後にもクライアントが復帰することを確認してから設定します。確認前に強制ブロックを有効にすると、通常のネットワークも使えなくなるおそれがあります。完全に通信できなくなった場合は、接続を停止してシステムのネットワークを復旧し、その後クライアントのログを確認してください。v2flyNGへの切り替えも万能な解決策ではありません。プロトコルまたはコアの互換性に違いがあると明確に判断できた場合にのみ比較します。移行時はルーティング、DNS、アプリ別ルールも確認してください。サーバー項目だけをコピーしても、完全な移行にはなりません。

設定 / サブスクリプションとサーバー情報

サブスクリプション管理：形式、更新、デバイス間同期

リモートサブスクリプション、共有リンク、設定一式を見分ける

リモートサブスクリプションURLは、クライアントが設定内容を取得するための入口で、通常はHTTPSのURLです。単一の共有リンクは、vmess://、vless://などのプロトコルプレフィックスで始まり、1つの接続情報を表します。完全なJSON設定には、インバウンド、アウトバウンド、DNS、ルーティングなどが含まれる場合があります。この3種類を、自由に置き換えられるテキストとして扱わないでください。長いエンコード文字列を見ても、外見だけでサブスクリプションか単一リンクかを判断できません。提供元の説明とクライアントが対応するインポート方法を確認し、何度も変換して元データを壊さないようにしてください。

サブスクリプションの中には、複数の共有リンクをBase64でまとめたものもあれば、クライアントが解釈できる構造化データをそのまま返すものもあります。Base64はエンコード方式であり、アクセス権を保護する暗号化ではありません。サブスクリプションをクライアントで扱えるかどうかは、リンクがブラウザーで開けるかだけでなく、返される形式とコアとの互換性によって決まります。詳しいインポート方法の違いは、サブスクリプションの追加とBase64・URI形式の解説を参照してください。サービスがログイン画面、エラーページ、認証ページを返す場合、通常クライアントはサーバー一覧として解析できません。

更新失敗をリクエストと解析の段階に分ける

サブスクリプショングループを保存しても、URLがローカル設定に登録されただけです。更新を実行したら、まずクライアントがリモートから応答を取得できたか、次にその内容を解析できたかを確認します。接続タイムアウトや証明書検証エラーはリクエスト段階の問題です。形式非対応や空の内容が表示された場合は、返された内容とサブスクリプションの種類を確認してください。更新に失敗しても、すでに使える項目をすぐ削除しないでください。現在のグループとログを残し、URLの有効期限、クエリパラメーターの欠落、システム時刻を確認します。ログを公開する前に、完全なサブスクリプションURLやアカウント識別情報を隠してください。

サブスクリプションの更新にプロキシを使うかどうかは、クライアントの更新オプションと実装によって決まります。現在のネットワークからサブスクリプションの接続先に直接アクセスできず、既存のプロキシが実際に使えると確認できた場合に限り、プロキシ経由で更新する設定を試してください。使えるサーバーが1つもない状態でこの設定を有効にすると、更新にはサーバーが必要なのに、そのサーバーを取得するためにも更新が必要という循環に陥ることがあります。その場合は直接アクセスできる更新経路に戻すか、設定の提供元に現在のネットワークで利用できる取得方法を確認してください。接続先不明のノードを次々切り替えて、更新を繰り返さないでください。

グループ管理と手動変更の扱い

入手元や用途ごとにサブスクリプショングループを分けると、どのURLがどのサーバーを管理しているか分かりやすくなります。更新によって項目が再作成されたり、名前や設定値が上書きされたりする場合があるため、手動で変更した内容が永久に残るとは限りません。設定を試すときは独立した項目にコピーし、元のサブスクリプションに自動追従しないことを明記して、変更理由も記録してください。更新後は現在のサーバーを選び直します。名前が同じでも、接続先や転送設定が変わっている場合があります。既存の接続が再作成されるかどうかはクライアントの動作によります。

デバイス間でサブスクリプションを共有すると、主にサーバー情報が同期されます。ルーティング、DNS、アプリ別の絞り込み、システムプロキシ、TUNの権限まで一緒に移行されるとは限りません。MacのプロセスルールをAndroidのアプリルールにそのまま使うこともできません。QRコードは少数の単一設定を渡すときに便利です。ローカル設定全体の移行にはエクスポートを使いますが、移行先のクライアントが同じ形式をインポートできるか確認してください。詳しくは複数デバイス間の同期方法を参照し、サーバー情報の同期が必要なのか、クライアントの動作設定一式が必要なのかを決めてから方法を選びましょう。

更新頻度は実際の必要性に合わせてください。頻繁な更新でトラブルシューティングを代用しないでください。複数の端末で同時に一覧が空になった場合は、まずサブスクリプションの状態と返却形式を確認し、次に各クライアントとの互換性を調べます。1台だけで失敗する場合は、ローカルネットワーク、プロキシ経由での更新設定、システム時刻を優先して比較してください。設定提供元が項目を無効化または置き換えた後も、古いクライアントに名前が残っているからといって接続できるとは限りません。削除前にグループの所属を確認し、手動設定まで一緒に消さないようにしてください。復元に必要な情報を保管し、繰り返し使われる分かりやすい表示名だけに頼らないでください。

設定 / インバウンド、アウトバウンド、名前解決

ルーティングとDNS：リクエストの経路から設定を理解する

ボタンの名前ではなく、インバウンドからアウトバウンドへの流れを見る

リクエストは通常、まずローカルのインバウンドに入り、次にルーティングルールによってどのアウトバウンドに渡すか決まります。inboundsはローカルの待ち受け方法、outboundsは実際の接続先、routingは両者の間で行き先を選びます。システムプロキシとTUNは、通信をクライアントに入れる方法を扱います。ルーティングは、入ってきた後の処理方法を決めます。「グローバル」は通常、制御対象になったリクエストをできるだけプロキシ経由のアウトバウンドに送る設定で、すべてのアプリにクライアントの使用を強制するものではありません。「ルール」は条件に応じてプロキシ、直接接続、ブロックを使い分けます。最終的には、画面の項目名も設定内容に照らして理解する必要があります。

以下は、ローカルインバウンドとタグの関係を確認するための最小限のV2Ray設定例です。直接接続とブロックのアウトバウンドのみを含み、リモートプロキシ接続は提供しません。また、クライアントが自動生成する実行用ファイルを置き換えるものでもありません。2つのポートは説明用の例にすぎず、ローカルで使用中なら同時に起動できません。ループバック待ち受けはアクセスを自分の端末に限定します。directとblockは任意に付けたタグで、実際の動作はそれぞれfreedomとblackholeのプロトコルで決まります。この違いを理解すれば、タグ名をコアにあらかじめ備わった機能と取り違えずに済みます。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom", "settings": {} },
    { "tag": "block", "protocol": "blackhole", "settings": {} }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールは順番に照合され、リソースファイルも結果に影響する

一般的なルーティング設定では、ルールを上から順に照合し、最初に一致したルールで処理方法が決まります。そのため、具体的な例外は通常、広い条件より前に置きます。outboundTagは実在するアウトバウンドタグと一致させる必要があり、綴りが違っていても自動修正されません。どのルールにも一致しない場合のデフォルトの出口は、コアの設定とクライアントによる生成方法を確認してください。config.jsonの構造解説を読むときは、1行だけで最終的な経路を判断せず、アウトバウンドの一覧とルールを合わせて確認しましょう。

geositeはドメインの集合、geoipはIPアドレスの集合を表します。どの宛先にも自動的に適用される万能なキーワードではありません。関連するルールを使う前に、現在のコアがその構文に対応しており、必要なリソースファイルを読み込めることを確認してください。ドメインの集合やIPの地理的な割り当て情報だけでは、個別サービスの方針を代替できません。複数のアドレスを使うサービス、コンテンツ配信、ルールデータの更新によって一致結果が変わることがあります。中国本土の通信を直接接続する設定などを行う場合は、対象範囲を明確にし、geositeとgeoipによる通信の振り分けを参考にしたうえで、ログから実際の結果を確認してください。

システムDNS、コアのDNS、リモート側の名前解決を区別する

DNSによる名前解決は、アプリ、OS、クライアントのコア、リモート接続の相手側で行われる場合があります。システムDNSを変更しても、プロキシ経由のすべてのリクエストで名前解決経路が変わるとは限りません。アプリが独自の暗号化DNSを有効にしていると、システム設定を通らない場合もあります。domainStrategyは、ルーティング判定でいつドメインを名前解決するかに影響する設定で、「特定の値にすればすべてリモートで名前解決する」という一括スイッチではありません。よく使われるIPIfNonMatchは、ドメインのルールに一致しない場合に、名前解決でIPを取得して照合を試みます。ただし、実際の連携動作は利用するコアの設定仕様を確認してください。

DNSの問題を調べるときは、まずドメイン名の解決に成功したか、次にアドレス取得後の接続が確立したかを確認します。証明書の名前が一致しない場合、証明書検証を無効にして問題を隠さないでください。宛先ドメイン名、安全性の設定に使うサーバー名、ネットワーク上に認証ページが表示されていないかを確認します。TUNでは、DNSリクエストが制御対象になっているか、DNSサーバーに到達できるか、再帰的な依存関係が生じていないかも確認してください。名前解決の入口は一度に1か所だけ変更し、変更前後のログを記録します。DNS、ルール、サーバーを同時に変えると、接続が復旧してもどの変更が有効だったか分からなくなります。

トラブルシューティング / 症状から原因の段階を特定

設定に関するよくある問題：段階ごとに確認して復旧する

まず基本のネットワークとローカル待ち受けを確認

アクセスできない場合は、まずTUNを無効にしてシステムプロキシを解除し、ほかの通信制御ツールも停止して、通常のネットワークが使えるか確認します。ホテルや公衆ネットワークでは、先にブラウザーで認証を完了する必要がある場合があります。基本のネットワークがつながっていない状態でサーバーを次々切り替えても意味はありません。通常の接続が復旧したら、クライアントを起動してコアの動作状態を確認してください。ログの「接続が拒否されました」がローカルのループバックアドレスで発生した場合は、リモートサーバーのパスワードより先に、待ち受けの有無とポートの誤りを調べます。同じエラーでも、接続先のアドレスによって調査する箇所が異なります。

クライアントが実行中と表示されているのに、すべてのアプリで接続できない場合は、まずローカルの待ち受けポートを確認し、明示的にプロキシを指定したリクエストでシステム設定の影響を切り分けます。以下のコマンドはcurlを利用できるデスクトップ環境向けです。例ではローカルのSOCKSポートを10808としていますが、実行前にクライアントに表示された実際のポートに置き換えてください。socks5hではドメイン名の解決をプロキシ側に依頼します。接続先の例は一般的なHTTPSサイトです。テストに成功しても、その接続経路が使えると分かるだけで、すべてのアプリやプロトコルが制御されている証明にはなりません。

curl --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 10 \
  --max-time 20 \
  --head https://example.com/

明示的にプロキシを指定した接続には成功するのにブラウザーで失敗する場合は、現在のネットワークにシステムプロキシが適用されているか、ブラウザー独自のプロキシ設定があるか、拡張機能が設定を上書きしていないか確認してください。明示的なプロキシ接続にも失敗する場合は、コアのログでローカルの入口、リモート接続、ハンドシェイクエラーを切り分けます。ターミナルで成功した結果をAndroidにそのまま当てはめないでください。モバイル端末では、クライアントのログとアプリのアクセス結果を比較して判断します。テスト中はサーバーと接続先を同じに保ち、まず条件をそろえてから比較対象を変えます。そうすればネットワークの変動による誤判定を防げます。

エラーの種類に応じて次の確認項目を決める

接続タイムアウトの場合は、宛先アドレス、ポート、現在のネットワークからの到達性、サーバーの状態を優先して確認します。認証失敗なら、認証情報とプロトコルの設定項目を確認してください。TLSハンドシェイク失敗では、システム時刻、安全性の設定に使うサーバー名、転送設定、サーバー側の要件を調べます。項目が空欄でも必ず誤りとは限らず、別の設定から値をコピーして埋めるのも避けてください。転送パラメーターは組み合わせて使うため、1項目だけ変えると原因を特定しにくい失敗につながることがあります。ログは調査範囲を絞る手がかりですが、1行だけで唯一の原因を特定できるとは限りません。変更の記録と比較テストも合わせて確認してください。

サブスクリプションを更新できても、すべてのサーバーで接続に失敗する場合、設定情報を取得する経路が少なくとも部分的に使えることは分かりますが、プロキシ接続の設定が正しいとは限りません。一部のサーバーだけで失敗する場合は、プロトコルや転送方式の違いを比較してください。すべてのサーバーで同時に失敗する場合は、システム時刻、コアの起動、ネットワーク環境など共通要因を確認します。特定のWebサイトだけに問題がある場合は、DNS、ルールの適用、接続先サービスの状態、アカウント制限を分けて検討してください。1つのサービスのために全体の通信モードを変更したり、クライアントの接続テストを実際のサービス利用の代わりにしたりしないでください。

TUNの問題とネットワークの復旧を分けて対応

システムプロキシは正常でTUNだけに問題がある場合、最初に疑うべきなのは通常、リモート接続情報ではありません。権限、仮想インターフェース、ルーティング、DNS、他のトンネルとの重複を確認してください。TUNを無効にするとすぐ復旧する場合は、その比較結果を記録します。リモート管理中の端末では、デフォルトルートを直接変更せず、まずローカルから復旧できる手段を用意してください。ネットワーク切り替え後に失敗した場合は、設定をすべて消す前に、通信制御サービスを停止して再起動します。再インストールによって一部のデータが残ったり変更されたりすることがあるため、設定の正しさを判断する信頼できるテストにはなりません。

通常終了後にネットワークが切れる場合は、システムプロキシが残っていないか確認します。TUN停止後も問題が続く場合は、別のネットワークツールが動作していないかを調べ、まずOSの通常のネットワーク接続を復旧してください。問い合わせる前に、OSとアーキテクチャ、クライアント名、通信の制御モード、発生時刻、再現性、直近の変更を記録します。ログは問題に関係する部分だけを残し、サブスクリプションURL、ユーザー識別情報、サーバーの認証情報を隠してください。「明示的なプロキシ接続は成功するが、システムプロキシは失敗する」のような比較結果があれば、「使えない」とだけ伝えるより調査箇所を絞りやすくなります。

操作手順を最初から確認する場合は、利用ガイドに戻り、インポート、モードの選択、動作確認の順に進めてください。別のプラットフォームにインストールする場合は、クライアントのダウンロードページでOSとチップを確認します。普段のメンテナンスでは、サブスクリプションの更新、クライアントのアップデート、ネットワークポリシーの変更を別々に行い、元に戻せるよう記録を残してください。設定どうしの影響を抑え、問題が起きたときに原因の段階を特定しやすくなります。何度も再インストールしたり、複数のスイッチを同時に切り替えたりする必要もありません。