クライアントは設定を保存し、コアは接続を処理します。まず設定がどの層に属するかを確認し、該当する項目を変更しましょう。
サブスクリプションURLはクライアントのグループ設定に保存されるもので、コアのJSONに共通する項目ではありません。v2rayNのサブスクリプショングループ設定でURLを入力し、グループ名を付けてから更新します。更新後はサーバー一覧に内容が表示されているか確認してください。自動更新の間隔は提供元の案内に従って設定します。失敗した場合は、URLの失効、ネットワークのタイムアウト、形式の不一致を切り分けましょう。共有リンクを1件ずつ追加する方法と比べ、グループなら接続情報の変更をまとめて管理できますが、ルーティングルールが提供されるわけではありません。右側はコアのアウトバウンド構成例です。この設定にサブスクリプションURLを入力しないでください。
対応する設定例 →{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}ルーティングでは、ドメイン名、宛先アドレス、インバウンドのタグなどに応じてアウトバウンドを選択します。サーバーへの接続を作成する機能ではありません。ルーティング設定では、まずルールセットを確認し、ルールが参照するアウトバウンドタグが存在するか確かめます。XrayとV2Flyで一般的な設定ではrouting.rulesを使い、ルールは上から順に照合されます。一致するとoutboundTagで指定した出口が選択されます。すべての接続を同じ出口に送る方法と異なり、LAN向け通信と特定のドメイン宛て通信を個別に扱えます。geositeやgeoipの項目を使う場合は、対応するデータファイルも必要です。ルールの記述だけをコピーしても動作しません。
対応する設定例 →{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}TUNモードは、システムプロキシを参照しないアプリの通信を仮想ネットワークアダプター経由で取り込むための機能です。有効にする前に通常のプロキシでノードの接続を確認し、実行権限、仮想ネットワークアダプター、DNSの設定を確認してください。v2rayNでは対応するコアを利用してこの機能を実現できますが、利用できる範囲はクライアントとコアの組み合わせによって異なります。システムプロキシとの違いは通信を取り込む場所であり、必ず速度が向上するわけではありません。右側はsing-boxのTUNインバウンド設定例です。Xray共通の項目ではないため、この設定一式をV2Flyの設定に貼り付けないでください。
対応する設定例 →{
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"address": ["172.19.0.1/30"],
"auto_route": true
}
]
}コアは名前だけで比べず、サーバーのプロトコル、通信方式、セキュリティ層の要件に合わせて選びます。v2rayNのパラメーター設定でコアの種類を確認し、起動ログで実際に呼び出されたコアを確かめてください。Xray、V2Fly、sing-boxでは機能や設定形式が異なり、同じ名前の項目でも動作が一致するとは限りません。コアを切り替える前に現在の設定を保存し、まず単一の接続を確認してから複雑なルーティングを戻しましょう。右側はXrayとV2Flyでよく使われるログ設定の例です。コアの種類はクライアント側の設定であり、このJSONの項目ではありません。
対応する設定例 →{
"log": {
"loglevel": "warning"
}
}システムプロキシは、対応するアプリにローカルの待ち受けポートへリクエストを渡すよう指定します。クライアントが起動しても、システムプロキシが有効とは限りません。v2rayNのメイン画面にあるシステムプロキシメニューから操作を選び、アプリ側のプロキシアドレスとローカルポートを一致させてください。システムプロキシを参照しないアプリは、個別に接続先を設定するか、必要に応じてTUNを利用します。クライアントを終了する前に、不要になったシステムプロキシを解除してください。解除しないと、アプリが停止済みのポートへ接続し続けることがあります。右側はXrayのローカルSOCKSインバウンドの例で、システムプロキシの切り替え設定ではありません。
対応する設定例 →{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}
]
}デスクトップではv2rayN、Androidではv2rayNGをまず確認しましょう。OS、CPUアーキテクチャ、インストール形式を確かめてから、ダウンロードページでファイルを選びます。
v2rayNにはデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版はおなじみのデスクトップ操作を維持しています。画面の構成は異なる場合があるため、ガイドに記載された設定項目は実際のメニューで探してください。初めてインストールする場合は、待ち受けポートの競合を避けるため、どちらか一方だけを使うことをおすすめします。
ダウンロード前にシステム設定でCPUアーキテクチャを確認し、インストール後はまずメイン画面を開いてからサブスクリプションを追加します。起動直後に終了する場合は、必要なデスクトップランタイム、フォルダーへの書き込み権限、セキュリティソフトの記録を確認してください。起動できないことだけでノードの障害と判断しないでください。アップグレード前にはサブスクリプショングループとカスタムルーティングをバックアップしましょう。インストーラーの更新は、個人設定のバックアップの代わりにはなりません。
ダウンロードページへ →v2rayNにはApple Silicon用とIntel用のダウンロードがあります。「このMacについて」でチップ情報を確認してから選び、外観だけでアーキテクチャを判断しないでください。インストール後はアプリを決まった場所に置いて実行します。初回起動時にシステムの警告が表示されたら、内容とダウンロード元を確認し、システムが案内する手順に従ってください。
初期設定では、まずサブスクリプションの追加とローカルプロキシを確認し、その後にログイン時の起動やTUNを設定します。システムプロキシの影響を受けるのはシステム設定に従うアプリです。ブラウザー拡張機能で個別にプロキシを設定している場合、そちらが優先されることもあります。仮想ネットワークアダプターを使う場合は、クライアントの案内に従って権限を許可してください。トラブルの切り分け中は、通信を取り込む方式を一度に1つだけ使うと、問題の発生箇所を特定しやすくなります。
ダウンロードページへ →v2rayNGはXrayコアを使用するAndroid向けの第一候補です。v2flyNGはV2Flyコアを使用し、対応する設定が必要な場合に選べます。一般的な新しいスマートフォンではarm64を選びます。アーキテクチャが分からない場合は、システム情報とインストール手順を確認してから汎用パッケージを検討してください。2つのクライアントでは設定を個別に確認し、インポートできたからといってすべての項目が一致すると考えないでください。
サブスクリプションを追加してサーバーを選ぶと、初回接続時にシステムのVPN接続許可が求められます。バックグラウンドで接続を維持できるかどうかは、バッテリー最適化やアプリのバックグラウンド権限にも左右されます。アプリを切り替えると接続が切れる場合は、省電力設定を確認してからクライアントのログを確認してください。接続情報には認証情報が含まれるため、問い合わせる際はエラー内容を伏せ字にし、サブスクリプションURLや共有リンクを公開しないでください。
ダウンロードページへ →v2rayNにはdeb形式とrpm形式のインストール方法があり、CPUアーキテクチャ別にパッケージが分かれています。まずディストリビューションのパッケージ形式を確認し、x64またはarm64を選んでください。GUIの起動、デスクトップのシステムプロキシ、TUNの権限はそれぞれ別の問題です。画面が開いただけでは、コアのプロセスやローカル待ち受けが正常とは限りません。
デスクトップ環境によってシステムプロキシの扱いが異なり、アプリ内でプロキシアドレスを指定する必要がある場合もあります。まずループバックアドレスとローカルポートで動作を確認し、その後にルーティングやDNSを調整しましょう。TUNを有効にする前に、必要な権限と既存の仮想ネットワークアダプターとの競合を確認してください。ルーターやバイパスルーターに導入する場合はコアの導入記事を参照し、デスクトップ用インストーラーをルーターのファームウェアとして使わないでください。
ダウンロードページへ →クライアント、コア、接続プロトコルは、それぞれ異なる層を表します。関係を理解すれば、設定一式をそのまま流用するよりも管理しやすくなります。
Project Vは、V2Rayの技術エコシステムを理解するための出発点です。初期のV2Rayは、プロトコル処理、トランスポート、ルーティングなどの機能を組み合わせて設定できるネットワークツールでした。その後、コミュニティでは開発方針の違いから複数のプロジェクトが生まれています。V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは関連技術を基盤に独自の機能と実装を発展させました。共通の背景はありますが、名前を自由に置き換えられる同一のプログラムではなく、すべての設定に互換性があるわけでもありません。
GUIクライアントはコアの上位に位置します。画面でサブスクリプションを保存し、サーバーを選択してルールを編集すると、クライアントが実行用の設定を生成または整理し、対応するコアに渡します。そのため、画面の「サブスクリプションを更新」は、コアのJSONに同名の項目として追加されるわけではありません。「システムプロキシを設定」もリモートサーバーのプロトコル設定ではありません。ドキュメントを読む際は、画面の設定、コアの項目、サーバー側のパラメーターのどれを扱っているか、最初に確認すると無駄な試行を減らせます。
v2rayNはデスクトップ向けで、サーバー情報、サブスクリプショングループ、システムプロキシ、ルーティングをまとめて管理し、複数のコアに関する設定もできます。v2rayNGはAndroid向けで、主にXrayコアを使用します。v2flyNGはV2FlyをベースにしたAndroidクライアントです。いずれもオープンソースですが、名前が似ていてもメニュー、設定の保存場所、機能範囲が同じとは限りません。
クライアントを選ぶ際は、まず端末のプラットフォーム、次にサーバー側の要件を確認します。Xray固有の機能を使う接続情報がある場合は、クライアントが呼び出すコアに対応機能があるか確認してください。V2Fly用の設定を使う場合は、移行前に各項目の互換性を確認します。あるクライアントの設定ファイルを別のクライアントのフォルダーにコピーしただけで、すべての設定が反映されるとは限りません。
クライアントとコアの関係を確認 →VLESS、VMess、Trojanは接続プロトコル、WebSocketやgRPCはトランスポート方式を表します。TLSやREALITYは接続のセキュリティ層に関する設定です。これらは同じ一覧から選ぶ代替項目ではありません。接続情報を確認するときは、プロトコル、サーバーアドレス、ポート、認証パラメーター、トランスポート方式、セキュリティ層を個別に照合してください。どれか1つでも一致しないと、ハンドシェイクに失敗することがあります。
VLESS自体にはデータを暗号化する機能がありません。実際に運用する際は適切なセキュリティ層と組み合わせてください。インポート用リンクから多くの項目を自動入力できますが、サーバー名、トランスポートのパス、関連オプションがそろっているか確認が必要です。接続に失敗した場合はサーバー側の要件と1項目ずつ照合しましょう。複数の設定を同時に変更すると、どの変更が結果に影響したのか分からなくなります。
プロトコルと設定範囲を確認 →オープンソースとは、各プロジェクトのライセンス条件に基づいてソースコードが公開されていることです。利用、改変、再配布には、それぞれのライセンス条件が適用されます。クライアント、コア、依存コンポーネントでライセンスが異なる場合があり、エコシステム全体を単一のライセンスとして扱うことはできません。一般ユーザーはプロジェクトの説明から機能の提供元を確認できます。ソフトウェアを再パッケージ化または再配布する場合は、ライセンス文や著作権表示を保持する要件も確認してください。
クライアントとリモートサービスも別々に考える必要があります。ソフトウェアをインストールしても、サーバー、アカウント、サブスクリプションが自動的に提供されるわけではありません。サブスクリプションの内容は、そのURLを提供するサービス側で決まります。クライアントがオープンソースかどうかと、リモートサービスがデータをどのように記録するかは別の問題です。業務情報を扱う場合は、クライアント名だけで判断せず、サーバーの提供元、アクセス権限、利用環境も確認してください。
このサイトの位置付けと掲載内容 →クライアント、コア、サブスクリプション、ルールデータの各更新は、それぞれ異なる問題に対応します。クライアントの更新は画面や設定生成のロジックに、コアの更新はプロトコル実装に影響します。サブスクリプションの更新では接続情報が同期され、ルールデータの更新ではドメインやアドレスの分類が変わることがあります。接続に問題が起きたら、直近で変更された層を確認しましょう。4種類の更新を同じ操作として何度も実行しないでください。
設定を保守するときは、元に戻せるよう変更履歴を残しましょう。変更前にカスタムルールや必要なパラメーターをバックアップし、変更後は起動ログ、ローカル待ち受け、アプリからの実際のアクセスを確認します。自動更新は繰り返し作業を減らせますが、更新結果の確認に代わるものではありません。長期間使っているカスタムJSONは、コアの変更後に各項目が引き続きサポートされているか確認し、参照されなくなったアウトバウンドタグを削除してください。
JSON設定リファレンスを見る →初回設定では、順番に動作を確認しましょう。まずサブスクリプションを追加し、サーバー一覧に表示されることを確認します。次にサーバーを1つ選んで接続し、エラーログを確認します。その後、アプリからローカルプロキシを使って実際の通信を試し、最後にルーティングやTUNを追加します。サブスクリプションを追加できても、接続情報を読み込めたことを示すだけで、サーバーに到達できるとは限りません。コアの起動成功も、ブラウザーがプロキシを使っている証拠ではありません。それぞれ個別に確認してください。
ログでは、エラーがどの段階で起きたかを確認します。アドレスの名前解決に失敗した場合はDNSを、接続がタイムアウトする場合は宛先アドレスとポートを確認してください。ハンドシェイクの失敗はプロトコルとセキュリティ層を照合し、ローカルポートが使用中なら重複して起動したプロセスを確認します。ログにはアドレスや認証情報が含まれることがあるため、共有前に伏せ字にしてください。サーバーの変更やクライアントの再インストール、設定全体の変更を繰り返すより、層ごとに原因を切り分けるほうが再現性のある解決につながります。
サブスクリプションと共有リンク：サブスクリプションURLは通常、複数の接続情報を取得するためのものです。共有リンクは一般に、1つの接続情報を表します。リンクに長い文字列が含まれているかだけで判断せず、それぞれに対応する追加方法を使ってください。URLにアクセス用の認証情報が含まれる場合があるため、アカウント情報と同様に管理しましょう。詳しくはサブスクリプション用語の解説をご覧ください。
システムプロキシとルーティング：システムプロキシは、対応アプリの通信をどこに渡すかを決めます。ルーティングルールは、コアが受け取った通信の出口を選びます。直結ルールを選んでも、アプリからのリクエストがまずローカル待ち受けに送られることがあります。また、システムプロキシを有効にしても、すべてのアプリが設定に従うとは限りません。詳しくはルーティングとアウトバウンドタグをご覧ください。
トラフィックのスニッフィングとDNS：スニッフィングでは、一部の通信からドメイン情報を識別してルーティングの照合に利用できます。ただし、毎回ドメインを取得できるとは限らず、DNSの設計を置き換えるものでもありません。ドメインルールに一致しない場合は、インバウンド設定、名前解決の方式、ルールの順序を合わせて確認しましょう。スニッフィングの切り替えだけを繰り返しても解決しないことがあります。各項目の場所はインバウンド設定の解説をご覧ください。
TUNと接続品質：TUNはアプリの通信をクライアントに取り込む方法を変える機能であり、サーバーのタイムアウトやプロトコル設定の誤りを自動で解消するものではありません。通常のプロキシでも接続できない場合は、まず基本の接続を解決してから仮想ネットワークアダプターを有効にしてください。複雑なネットワーク環境では、ほかのVPNソフトや仮想ネットワークアダプターがルーティングに与える影響にも注意が必要です。詳しくはTUNモード用語の解説をご覧ください。
具体的な設定場所やエラーから調べられる記事を紹介します。以下の3記事は新しい順に並んでおり、環境別導入、サブスクリプションの追加、コアのエコシステムを扱います。
ルーターやバイパスルーター上でコアを直接動かせば、家庭内の端末ごとにクライアントをインストールする必要はありません。この記事では、ハードウェアの選び方、透過プロキシの仕組み、設定ファイルの配置、よくある注意点を解説します。
記事を読む →この記事では、デスクトップ版とAndroid版でサブスクリプショングループを設定する場所を案内し、Base64形式のサブスクリプションとvless://・vmess://共有リンクの違いや見分け方を解説します。
記事を読む →この記事では、Project Vが単一のプロジェクトからV2FlyとXrayという2つのコアの系統へ発展した経緯を整理し、各GUIクライアントがどのコアを使うのか、それぞれの役割を解説します。
記事を読む →