サブスクリプションのインポート、ルーティング、プロトコルの選択を中心に、クライアントの設定とコアの対応関係を解説します。
クライアントの設定は、大きく3つに分けられます。サブスクリプションとノードは接続先を決め、システムプロキシまたはTUNモードはクライアントに通すアプリを決めます。ルーティングとDNSは、通過した通信の処理方法を決めます。インストールしただけでは接続は有効になりません。まず利用可能な設定をインポートしてノードを選び、次に通信の入口を設定します。最後にログと実際の接続状況を確認すれば、問題の箇所を特定しやすくなります。
下のパネルは設定項目の構成例です。項目名はクライアントの画面更新に伴い変わる場合があるため、実際の操作では現在の画面を確認してください。サブスクリプション、通信方式、DNS、ルーティングを一度に変更するのは避けましょう。動作する設定を1つ保存し、変更は1種類ずつ行って結果を確認してください。元に戻しやすくなり、ノード自体の問題とアプリのプロキシ設定の問題を混同せずに済みます。
サブスクリプションを使うと、ノードをまとめて管理できます。URLや設定が変更される場合に便利です。まずサブスクリプショングループに名前と完全なURLを登録し、保存後に更新してから、使用するノードを選びます。URLを追加しただけでは接続されません。共有リンクを1つずつ貼り付ける方法に比べて一括管理しやすい一方、更新によって手動編集した内容が上書きされる場合があります。自分で作成したノードは別のグループに分けておくとよいでしょう。サブスクリプションURLにはアクセス情報が含まれることがあるため、公開しないでください。更新に失敗する場合は、まずURLが有効かを確認し、次に更新リクエストの接続経路を調べます。
domain:example.com192.168.0.0/16geosite:privateルーティングでは、ドメイン、IP、カテゴリデータを使って、通信を直接接続・プロキシ・ブロックのどれで処理するか決めます。通常は、まずLANや明確な例外を設定し、次に汎用ルール、最後に最終ルールを設定します。条件に一致した場合にどのルールが適用されるかは、コアの照合順序を確認してください。すべての通信を同じアウトバウンドに通すより、ルール方式はローカル機器とリモートサービスを併用する環境に向いています。ルールを追加する前に、クライアントが生成するアウトバウンド名を確認しましょう。カテゴリを参照する場合は、対応するデータファイルも必要です。ルールが適用されないときは、実際のドメインとログを確認し、Webページの表示だけで判断しないでください。
TUNモードは仮想ネットワークインターフェースで通信を受け取るため、システムプロキシ設定を参照しないアプリにも適しています。システムプロキシとは通信の入口が異なり、ノードのプロトコルを切り替える機能ではありません。有効にする前に、通常のプロキシ接続でノードが使えることを確認し、クライアントが使用するTUN実装、権限、DNS設定を確認してください。プロキシ設定に従うアプリだけを対象にする場合と比べ、TUNはより広い範囲の通信を制御できる一方、ほかの仮想NICやプロキシソフトと競合しやすくなります。有効化後にLANへ接続できなくなった場合は、まず除外ルールを確認します。通信を制御する必要がなくなったら無効にし、経路設定が後の接続に影響しないようにしてください。
DNS設定ではドメイン名をIPアドレスに変換しますが、コアのDNSを変更しても、すべてのアプリの名前解決経路が変わるとは限りません。システムプロキシ、TUN、ブラウザー内蔵の暗号化DNSでは、異なる経路が使われることがあります。まず、どこで名前解決されているかを確認し、接続可能なDNSサーバーを選んで、DNSリクエストのアウトバウンドも確認してください。DNSサーバーのアドレスを置き換えるだけでなく、名前解決とルーティングを連携させることが重要です。特にIPアドレスで照合するルールは、名前解決の結果に左右されます。例に示したアドレスは形式の説明用で、一般的な推奨値ではありません。ドメインでは接続できず、IPアドレスなら接続できる場合は、ノードを変更する前にDNSを調べてください。
GUIクライアントは設定を管理し、コアは実際の接続を確立します。複数のコアに対応していると、同じ画面から異なる機能の組み合わせを扱えますが、すべての設定を共通して使えるわけではありません。切り替える前に、プロトコル、通信方式、セキュリティ層、ルーティングの各項目が移行先のコアに対応しているか確認してください。特にVLESSとREALITYの組み合わせでは、個別の実装を確認する必要があります。画面テーマの変更とは異なり、コアを切り替えると設定の意味やログの内容に影響します。接続が安定しているなら、頻繁に切り替える必要はありません。新機能の利用や互換性の問題解消で切り替える場合は、まず設定をバックアップし、ノードを1つだけテストしてから全体に適用してください。
VMess、VLESS、Trojan、Shadowsocksはプロキシプロトコル、WebSocketなどは通信方式、TLSとREALITYはトランスポートのセキュリティに関する設定です。それぞれ異なる階層にあります。VLESSノードを使う場合は、プロトコル名を選んで保存するだけでなく、通信方式、TLSまたはREALITYの有無、flowの指定も確認してください。上のカードは設定項目の構成例であり、そのまま接続できるノード設定ではありません。
VLESSのencryptionには通常noneを指定しますが、これはセキュリティ層を省略してよいという意味ではありません。Trojanでは、正しいパスワードとサーバー認証設定が必要です。証明書エラーが発生した場合は、証明書の検証を無効にするのではなく、システム時刻、SNI、サーバー証明書を確認してください。Shadowsocksの暗号化方式はサーバー側と一致させる必要があります。年号が付いた方式には特定の鍵要件もあるため、通常の文字列パスワードをどの方式にも使えるわけではありません。
ノードを選ぶときは、提供元が指定したパラメーター一式をそのまま使うのが基本です。手動で入力する場合は、アドレス、ポート、ユーザー認証情報、通信方式、セキュリティ層の順に確認してから接続をテストしてください。クライアントにノード名が表示されても、設定が登録されたことを示すだけで、コアがすべての項目を読み取れたことや、リモートサーバーへ接続できることを保証しません。各プロトコルの設計上の違い、モバイル端末の電池への影響、設定の互換性については、プロトコルとコアの技術解説もご覧ください。
デスクトップではv2rayN、Android端末ではXrayコアを使用するv2rayNGが基本です。V2Fly設定との互換性が必要な場合は、v2flyNGを検討してください。名称が似ていても、対応OS、コア、インストールパッケージの形式は異なります。ダウンロード前にOSとプロセッサーアーキテクチャを確認し、インストール後にサブスクリプションとノードを設定しましょう。インストールパッケージの不適合を接続トラブルと混同せずに済みます。
下のリンクをクリックすると、ダウンロードページの各OS向け案内が開きます。トップページからインストールパッケージが直接ダウンロードされることはありません。ダウンロードページでは、デスクトップ版、クラシック版、チップアーキテクチャ、ディストリビューション別のパッケージ形式をまとめて比較できます。別の端末に移行する際はサブスクリプションを引き継げますが、元の端末のシステムプロキシ、権限、ルーティング設定は引き継がれません。改めて確認してください。
Windowsでは、v2rayNのデスクトップ版とクラシックなWPF版から選べます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のデスクトップ操作を維持しています。まずOSのアーキテクチャを確認し、次にUIの好みや使い慣れた操作方法に合わせて選びましょう。パッケージごとに設定フォルダーや移行方法が異なるため、ファイル名だけで上書きインストールできるか判断しないでください。
初回起動後は、サブスクリプションをインポートしてからシステムプロキシを有効にします。システムプロキシ設定を参照しないアプリでは、その後にアプリ内プロキシまたはTUNを検討してください。クライアントを変更したあともブラウザーが古いポートを使用する場合は、OSの設定に別のプロキシソフトの情報が残っていないか確認し、想定したプログラムだけが通信の入口を管理する状態にしてください。
macOSのインストールパッケージは、Apple SiliconとIntelのプロセッサー別に用意されています。「このMacについて」でチップまたはプロセッサーを確認し、Apple Siliconはarm64、Intelはx64を選びます。互換モードでの動作を前提にせず、対応アーキテクチャのパッケージを選んでください。インストール前にダウンロードページのシステム要件も確認しましょう。
デスクトップクライアントでは、サブスクリプションの管理とOSのネットワーク権限の許可は別の手順です。インポートに成功しても、使用中のノード、通信の入口、アプリが実際に使う経路を確認してください。TUNを有効にする場合は、画面とOSの指示に従って必要な権限を許可します。組織の管理下にある端末では、ネットワーク設定を変更する前に端末管理のルールを確認してください。
Androidではv2rayNGを、V2Flyコアの代替としてv2flyNGを選べます。最近の一般的な端末の多くはarm64パッケージに適しています。アーキテクチャが不明な場合は端末情報を確認するか、汎用パッケージを検討してください。アプリ名やアイコンが似ているため、インストール前に名称を確かめましょう。インポート後は対応プロトコルを確認し、両アプリの設定手順が同じだと思い込まないでください。
接続時に表示されるVpnServiceの許可は、端末上で通信を制御するインターフェースを作成するためのものです。サブスクリプションが自動的に使えるようになるわけではありません。長時間の待機後に切断される場合は、ノードの状態に加えて、バックグラウンド実行の制限や省電力設定も確認してください。アプリごとにプロキシを適用すると対象範囲を調整できます。設定する際は、一覧が対象アプリを含むのか除外するのかを理解し、必要なアプリを誤った側に設定しないようにしましょう。
Linuxでは、v2rayNのdebまたはrpmパッケージを確認し、x64とarm64を区別してください。パッケージ形式はディストリビューションのパッケージ管理方式に、アーキテクチャはプロセッサーに対応します。どちらも環境に合わせて選ぶ必要があります。ファイルをダウンロードできても、現在のOSで使えるとは限りません。依存関係、デスクトップ環境、権限の要件をダウンロードページの説明に沿って確認してください。
Linuxでシステムプロキシが有効になるかは、デスクトップ環境やアプリ自体にも左右されます。ブラウザーは使えるのにほかのソフトで接続できない場合は、すぐにノードを変更せず、そのソフトがプロキシ設定を参照するか確認してください。TUNを有効にする前に、権限とルーティングの制御範囲を確認しましょう。特にLAN、コンテナネットワーク、既存の仮想インターフェースに注意し、変更前の設定に戻せるようにしておきます。
設定の移行で再利用できるのは、一部の項目に限られます。新しい端末でもコアの対応状況、通信の入口、DNSの経路を確認してください。詳しくはクイックスタートガイドをご覧ください。
v2rayN · v2rayNG · v2flyNG
サブスクリプション管理、画面操作、設定の生成Xray · V2Fly
接続の確立、プロトコル処理、ルーティングの実行Project Vは、プロキシやネットワークツールを中心とするオープンソースプロジェクト群です。V2Rayは、その中で広く使われているコアの名称です。特定のプロトコルだけでなく、インバウンド、アウトバウンド、ルーティング、通信方式を共通の設定構造で組み合わせられる点に特徴があります。クライアントで「ノード」と表示されるものは、多くの場合、リモート側のアウトバウンドを画面上で表したものです。システムプロキシ、ローカルの待ち受け、DNSは別の設定項目に含まれるため、ノード名だけで動作環境全体を説明することはできません。
日常の会話では、V2Rayがエコシステム全体を指す総称として使われることもあります。そのため、ダウンロード時は具体的なアプリ名を確認することが大切です。v2rayNはGUIクライアントであり、V2Rayコア本体とは別のものです。v2rayNGとv2flyNGはAndroid端末向けです。この関係を理解しておくと、ドキュメントで「画面に機能の入口が追加された」のか「コアにプロトコル機能が追加された」のかを区別でき、クライアントのログとプロトコルパラメーターのどちらを調べるべきか判断しやすくなります。
V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは関連するコードを基盤に独自の機能を発展させてきました。共通の背景はありますが、それぞれ独立して保守・開発されており、同じプログラムの外観違いではありません。一部の設定項目が似ていても、新しい通信方式、セキュリティ機能、ルーティングの選択肢、初期動作には違いがある場合があります。コアは名称やリリース日だけで比較せず、ノードが必要とする機能と実際の互換性を基準に選びましょう。
VLESS、Vision、REALITYを組み合わせる場合は、Xrayの対応範囲に加え、サーバー側から指定されたflow、サーバー名、公開鍵、shortIdを確認してください。REALITYはトランスポートのセキュリティ機構であり、VMessやTrojanと同じ階層の独立したプロキシプロトコルではありません。既存のV2Fly設定を別のコアにまとめて移行するのも避けましょう。まずノードを1つ選んで各項目を確認し、ルーティングとDNSをテストしてから、設定全体を移行してください。
v2rayN、v2rayNG、v2flyNGはいずれもオープンソースクライアントで、ノード編集、サブスクリプション管理、接続制御などを画面から操作できます。オープンソースとは、ソースコードとライセンスを確認できるという意味であり、実行権限や設定の入手元を確認しなくてよいわけではありません。サブスクリプションの提供元、リモートサーバー、クライアントはそれぞれ異なる役割です。クライアントをインストールしてもサーバーアカウントが手に入るわけではなく、インポートしたすべてのノードが使える保証もありません。
v2rayNはデスクトップ向けで、1つの画面からサブスクリプションとルーティングを管理し、対応状況に応じてコアを選べます。v2rayNGは主にXrayコアを基盤とし、対応プロトコルを使いたいAndroidユーザーに適しています。v2flyNGはV2Flyコアを採用し、対応する設定との互換性が必要な場合に向いています。別のアプリに移行するときは、画面上のメモ名だけをコピーせず、完全な共有リンクまたはサブスクリプションを再インポートしてから接続モードを確認してください。
Project V関連プロジェクト、GUIクライアント、コア、パッケージの依存関係には、それぞれ異なるオープンソースライセンスが適用される場合があります。エコシステム内の1つのライセンスを、すべてのコンポーネントに共通するルールとみなすことはできません。個人利用、再配布、改変版の公開では要件が異なるため、各プロジェクトのライセンスファイルと付属の説明を個別に確認してください。ページの「オープンソース」という表記は、開発や配布の性質を示すものであり、サブスクリプションの内容やリモートサービスを保証するものではありません。
一般の利用者は、アプリ名、OSのアーキテクチャ、使用しているコアを記録し、設定の入手元も残しておくと実用的です。クライアントが要求する権限も把握しておきましょう。設定に含まれるパスワード、ユーザー識別子、サブスクリプションURLの扱いには注意してください。相談用のスクリーンショットでは、これらを隠しましょう。ノードのアドレス、SNI、公開鍵は用途が異なりますが、個人設定全体をそのまま公開するのは避けてください。問題の切り分けには、項目の整合性が分かる情報だけで足りることが多くあります。
クライアントの更新は主に画面や設定管理に、コアの更新は主に接続処理に影響します。サブスクリプションの更新では、設定の提供元がノード一覧を変更します。この3種類では、更新元も影響も異なります。更新後にノード数やパラメーターが変わっても、クライアントのアップグレードが原因とは限りません。クライアントのアップグレード後に設定を起動できなくなっても、サブスクリプションURLが無効とは限りません。まず、どの層が直近で変更されたかを確認してから、ロールバック、再インポート、項目の調整を判断しましょう。
更新前に現在の設定を残し、使用中のノードとルーティングモードを記録してください。更新後は、よく使うノードを1つテストし、LANへのアクセス、ドメイン名の解決、プロキシが必要なアプリを確認します。自動更新の間隔はサブスクリプション提供元の制限に合わせ、必要以上に頻繁な更新は避けましょう。失敗が続く場合は、更新リクエストを繰り返さず、URLの有効性、リクエストの経路、システム時刻、エラーログを順に確認してください。変更を重ねて原因が追えなくなるのを防げます。
インポートできても接続できない場合は、まず使用するノードが選択されていることと、コアが正常に起動していることを確認し、次にアプリの通信が実際にプロキシを通っているか調べます。ブラウザーは接続できてもほかのソフトが接続できない場合は、通信の入口を確認してください。ドメイン名でのみ接続に失敗するなら、まず名前解決の経路を調べます。すべてのアプリで失敗する場合は、ノードの設定とリモートへの到達性を確認します。遅延テストの結果は特定のテストリクエストを示すもので、すべてのプロトコルやアプリの通信が正常である証明にはなりません。
用語を確認するには用語集で、サブスクリプション、共有リンク、インバウンド、アウトバウンドの違いを調べてください。症状別の対処法はよくある質問をご覧ください。エラーが発生した時刻、直近で変更した設定、ログの種類を整理すると、プロトコルを手当たり次第に切り替えるより効率よく調査できます。最適な構成はサーバーの対応状況とアプリの要件を踏まえて選び、特定のプロトコル名を追いかけるより設定の整合性を保つことが重要です。
基本的な接続ができたら、目的に応じて各ガイドを確認してください。サブスクリプションの形式によってインポート方法が異なり、更新に失敗した場合はリクエストの経路を確認する必要があります。ルーターへのデプロイでは、デスクトップクライアントとは異なるネットワーク上の役割を扱います。各記事では1種類の問題に絞って解説しているため、変更前に適用条件を確認でき、別ルーター構成、Androidの権限、デスクトップのシステムプロキシの手順を混同せずに済みます。
メインルーターまたはバイパスルーターでXray/V2Flyコアを直接実行する方法を解説します。ハードウェアのアーキテクチャとメモリ要件、透過プロキシ方式の選び方、DNSルーティング設定のポイントを取り上げます。
クライアントの通信経路を理解し、LAN全体へ対象を広げたい方に適しています。ゲートウェイとDNSサーバーがそれぞれ担う役割を整理してから、デプロイ先を決めてください。
デプロイの記事を読む →Base64形式のサブスクリプション、ネイティブJSON設定、vmess://・vless://共有リンクの構造の違いを比較し、各クライアントの互換性と相互変換の考え方を解説します。
インポート時に形式エラーが出る方や、別のクライアントへ設定を移行したい方に適しています。変換前に入力形式を見分け、変換によって通信方式やセキュリティのパラメーターが失われないか確認してください。
形式の記事を読む →サブスクリプションURLの無効化、更新リクエストのプロキシ経由の有無、システム時刻のずれ、証明書の問題を順に調べます。自動更新間隔とグループ別サブスクリプションの設定例も紹介します。
ノードには接続できるのに、サブスクリプションを更新できない場合に適しています。「サブスクリプションの取得」と「ノードの利用」を分けてテストし、使える設定を残してから更新経路を修復しましょう。
トラブル対処の記事を読む →