Xray · V2Fly コア / デスクトップ・モバイル4プラットフォーム
OSに合わせてオープンソースクライアントを選び、サブスクリプションの読み込みから config.jsonの項目リファレンスまで、ローカルポート、outboundプロトコル、ルーティングルールを順に確認できます。
設定ワークベンチは一部の項目を抜粋した例です。認証情報、サーバーポート、direct outboundの定義は省略しているため、そのまま完全な設定として実行することはできません。
CONFIGURATION / 設定項目一覧
クライアントの画面で設定を生成し、コアがその設定に基づいて接続を処理します。通信の入口、outboundの選択、ドメイン名の解決を切り分けてから該当項目を変更しましょう。すべてのパラメーターを一度に表示する必要はありません。
{
"inbounds": [{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}]
}inboundは、アプリからコアへ接続を渡す方法を定義します。端末内だけで使う場合、待ち受けアドレスには通常ループバックアドレスを指定し、ポートはブラウザーや呼び出し元のプログラムに合わせます。例ではSOCKS inboundを使用しているため、このポートをHTTPプロキシのポートとして使うことはできません。起動に失敗した場合は、まずポートの競合を確認し、次にクライアントが同名のinboundを生成していないか確認します。システムプロキシのオン・オフだけを見るのではなくinboundを調べることで、「アプリが通信を送っていない」場合と「コアが待ち受けに失敗している」場合を区別できます。待ち受け範囲を変更する前に、どの端末から接続できるようにするのかも確認してください。
設定リファレンスを見る →{
"outbounds": [{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}]
}outboundは、コアから接続を送り出す方法を定義します。プロキシoutboundにはサーバーアドレス、ポート、認証情報が必要です。直接接続にはfreedomを使用できます。VLESSなどのプロトコル名だけではノードの全仕様は分からないため、トランスポート方式やTLS・REALITY関連のパラメーターも確認してください。ルーティングではtagを使ってoutboundを参照するため、名前は完全に一致させる必要があります。ノードを何度もインポートするより、プロトコル、トランスポート、セキュリティ層を順に確認したほうが、設定項目の不足を見つけやすくなります。例では直接接続outboundのみを示しています。プロキシプロトコルを使う場合は、サーバーから提供されたパラメーターと、使用するコアの対応範囲に従ってください。
設定リファレンスを見る →{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}]
}
}ルーティングルールは上から順に照合され、一致した時点で対応するoutboundが選択されます。明確な例外を広範なルールより前に置き、outboundTagがoutbound側で定義されていることを確認してください。domainStrategyはルーティングの照合中にドメイン名をいつ解決するかを決める項目であり、システムのDNS設定とは異なります。例ではプライベートIPアドレスをdirectに割り当てています。地理データを使うルールでは、必要なデータファイルが利用できることも確認してください。グローバルモードへ切り替えるだけでなく、ルールを明示すればLANへのアクセスを保ち、特定のドメインだけ別の経路にできます。問題を調べるときは、まずルールを絞り込み、1つずつ戻して確認しましょう。
設定リファレンスを見る →{
"dns": {
"servers": ["localhost"]
}
}DNS設定は、コアがドメイン名を解決するときに使うリゾルバーに影響しますが、端末上のすべてのアプリの問い合わせを自動的に処理するわけではありません。例のlocalhostは端末の名前解決機能を使う指定であり、パブリックDNSのアドレスを手入力する意味ではありません。設定する前に、アプリ独自の名前解決、システムの名前解決、コアの名前解決という3つの経路を区別し、ルーティング方針と合わせて実際にどの層で処理されるかを確認してください。リゾルバーのアドレスを変えるだけでなく、問い合わせがどこへ送られているかを調べると、原因を特定しやすくなります。クライアントにDNSルーティングや問い合わせポリシーの設定がある場合は、現在のコアでの具体的な意味も確認してください。
設定リファレンスを見る →クライアントのサブスクリプショングループ
備考 日常設定
自動更新 必要に応じて有効化
更新後 選択中のノードを確認
エクスポート前 サブスクリプションURLと認証情報を削除サブスクリプションURLはクライアントが読み込み、ノードをまとめて更新するために使います。config.json共通のトップレベル項目ではありません。用途ごとにグループを作成し、分かりやすいメモを付けておくと便利です。更新後は、選択していたノードが残っているか、手動で変更した設定が再生成されていないかを確認してください。共有リンクを1つずつコピーするより一元管理しやすい一方、サブスクリプションの形式や拡張パラメーターへの対応はクライアントごとに異なります。スクリーンショット、設定ファイル、トラブルシューティング用ログを共有する前に、サブスクリプションURLと認証情報を必ず削除してください。端末を移行する際は、ノード情報と端末固有の設定を分けて整理しましょう。
設定リファレンスを見る →DOWNLOADS / プラットフォーム別ダウンロード
デスクトップではv2rayN、Androidではまずv2rayNGを確認し、V2Flyコアが必要な場合はv2flyNGと比較してください。インストーラーと設定ドキュメントを分けて掲載しているため、先にOSとアーキテクチャを選び、続けてチュートリアルで設定できます。
デスクトップ版にはクロスプラットフォームのUIがあり、WPF版では従来型のデスクトップ操作を利用できます。まず使い慣れたUIを選び、インストール要件を確認してください。設定済みのユーザーは、サブスクリプショングループ、カスタムルーティング、ローカルポートを先にバックアップしましょう。プログラムのフォルダー全体を、別のUIのバージョンにそのまま上書きするのは避けてください。
初回起動後は、まず設定画面でローカルの待ち受けポートを確認し、そのうえでシステムプロキシを有効にするか決めましょう。アプリが正常に開いても、コアが起動しているとは限りません。実行環境に関するメッセージが表示された場合は、インストールページの説明に従って必要なコンポーネントを導入してから、ノードをインポートしてください。
「このMacについて」でチップ情報を確認し、対応するアーキテクチャのインストーラーを選んでください。システムプロキシの設定とクライアントのルーティングは別の層です。前者はアプリが接続をクライアントへ渡すかを決め、後者は受け取った接続にどのoutboundを使うかを決めます。
初回起動時はシステムの確認ダイアログをよく読み、トラブルシューティングのために複数の権限を同時に変更しないでください。ブラウザーでは接続できても他のアプリが通常の経路を使う場合は、そのアプリがシステムプロキシに従うか、独自のネットワーク設定を持つかを確認しましょう。
まずv2rayNGのarm64版と汎用版のダウンロード先を確認してください。端末のアーキテクチャが分からない場合は、システム情報も参考に選びます。v2flyNGは別のコアファミリーを使う選択肢です。既存のノードに適しているかは、アプリ名だけでなくプロトコルや拡張パラメーターに基づいて判断してください。
接続時には、システムのVPN接続許可が必要です。アプリごとの通信振り分け、バックグラウンド実行の制限、バッテリー管理によって動作が変わることがあります。画面表示中は接続できてもロック後に切れる場合は、サブスクリプションを何度も再読み込みする前に、バックグラウンド動作の制限を確認してください。
ディストリビューションのパッケージ形式に応じてdebまたはrpmを選び、x64とarm64を区別してください。デスクトップ環境によってシステムプロキシへの対応は異なります。インストール後は、コアの動作状態、デスクトップのプロキシ設定、対象アプリ独自のネットワーク設定をそれぞれ確認しましょう。
ローカルポートの競合、権限不足、依存関係の不足はそれぞれ別の問題です。ログに記録された具体的なエラーに応じて対処してください。GUIクライアントと他のプロキシプログラムを同時に動かす場合は、まずどのプログラムが対象ポートを待ち受けているか確認しましょう。別のプログラムからの応答を、現在の設定が反映された結果と誤認するのを防げます。
QUICKSTART / 設定の手順
初期設定では、動作を説明できる接続経路を1つ作りましょう。まず読み込み、次に通信の受け渡し方法を選び、最後に動作を確認します。複数の詳細設定を同時に有効にするより、変更する項目を1つずつに絞るほうが問題を特定しやすくなります。
01 / 読み込み
クライアントのサブスクリプション管理からURLを追加し、グループに分かりやすいメモを付けて更新します。共有リンクが1つだけある場合は、クリップボードまたはQRコードから読み込めます。2つの方法では管理対象が異なります。サブスクリプションの更新ではグループの内容を再取得しますが、個別の共有リンクでは通常、ローカル項目が1つ作成されます。
読み込み後はノードの編集画面を開き、プロトコル、サーバーアドレス、ポート、トランスポート設定を確認してください。サブスクリプション名は接続パラメーターではなく、ノードの表示名から設定の完全性を判断することもできません。形式を認識できないというメッセージが出た場合は、余分な空白、説明文、WebページのURLが含まれていないかを確認してから、クライアントがその形式に対応しているか調べましょう。
サブスクリプションURLにはアクセス情報が含まれることがあるため、公開スクリーンショットや掲示板に貼り付けないでください。問題を報告するときはプロトコルの種類とエラーメッセージだけを記録し、認証情報は公開しないようにします。更新失敗とノードの接続失敗は別の段階の問題です。更新できない場合は、outboundプロトコルを変更する前に、サブスクリプションの取得状況を確認してください。
02 / 通信の受け渡し
ノードを選んでから、通信をクライアントへ渡す方法を設定します。デスクトップではまずシステムプロキシを使い、Androidでは画面の案内に従ってVPN接続を許可してください。システムプロキシが影響するのは、その設定に従うアプリだけです。ルーティングモードはコアに届いた接続を処理するものであり、両者は置き換えられません。
初めて使う場合は、まずクライアント標準の基本ルーティングを維持し、LAN内の機器にアクセスできることを確認してから特定のドメインルールを追加しましょう。1つのアプリを動かすためだけにLANからの接続をすぐ許可したり、通信の振り分けに関する問題をすべてノードのせいにしたりしないでください。まずアプリの通信がクライアントに渡っているか確認すると、調査範囲を絞れます。
ローカルポートを変更する場合は、そのポートを使うアプリ側の設定も合わせて変更してください。HTTPとSOCKSは異なるプロキシインターフェースです。待ち受けアドレスが同じでも、自由に置き換えることはできません。クライアントに混合ポートの設定がある場合は、その項目の説明を確認し、別の端末のポート番号をそのまま使わないようにしましょう。
03 / 動作確認
接続を開始したら、まずコアが正常に動作しているか確認し、次に対象アプリからリクエストを送信します。ノードのテスト結果は特定のテスト方法を反映するだけで、実際のアプリによる確認の代わりにはなりません。「コアの起動に成功した」「アプリのリクエストが届いた」「ルールで想定したoutboundが選ばれた」「リモート接続が完了した」を分けて判断しましょう。
証明書関連のエラーが出た場合は、システム時刻、サーバー名、トランスポートのセキュリティ設定を確認してください。アドレスが使用中というメッセージの場合は、ローカルポートの設定に戻ります。トラブルシューティングの前に元のパラメーターをバックアップし、変更内容と発生した現象を記録しておきましょう。元の設定に戻す根拠が残り、試行を重ねて元の設定を失うことも防げます。
接続が期待どおりに動作することを確認してから、自動更新、OS起動時の自動起動、アプリごとの通信振り分けを検討しましょう。ネットワークの切り替え、端末の再起動、画面ロック解除後にも、同じ手順で再確認できます。特定のアプリだけで問題が起きる場合は、全体設定を変更する前に、そのアプリ独自の名前解決やプロキシ設定を確認してください。
PROJECT V / コアとクライアント
V2Ray、V2Fly、Xray、GUIクライアントは、それぞれ異なる層のソフトウェアです。役割を区別すると、機能を提供しているコンポーネントやエラーの発生元、設定移行時に引き継ぐ内容を判断しやすくなります。
Project Vは、ネットワークプロキシ関連のコンポーネントから成るオープンソースエコシステムで、V2Rayはその中で広く使われているコア実装です。V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは関連するコードを基盤に独自のコアとして発展しています。共通する設定概念もありますが、プロトコル拡張、項目の対応状況、既定の動作には、それぞれの開発に伴う違いがあります。すべてを同じコアとして扱うと、設定の読み込みやドキュメントの確認時に、適用範囲を見落とすおそれがあります。
コアはプロトコル処理、トランスポートの確立、ルール照合、名前解決などを担当します。GUIクライアントはそれらの機能を、ノード一覧、サブスクリプショングループ、設定画面としてまとめます。画面に項目があっても、選択したすべてのコアが同じ方法で解釈するとは限りません。互換性の問題を調べるときは、共有リンクの先頭だけで設定全体を判断せず、使用中のクライアントとコアを記録してから、対応する項目の説明を確認してください。
v2rayNはデスクトップ向けのオープンソースGUIクライアントで、ノードの読み込み、サブスクリプションの更新、ルーティング管理、システムプロキシの操作に対応しています。一般的な設定を画面から管理できる一方、カスタム設定も利用できます。コアの切り替えやノードタイプの変更後は、生成されたトランスポートとセキュリティ層のパラメーターを再確認してください。ノード情報が保存されていても、接続先サーバーがその機能に対応しているとは限りません。
v2rayNGはAndroid向けのオープンソースクライアントで、Xrayコアを使用します。v2flyNGはV2Flyコアを採用した別の互換ルートの選択肢です。画面上の操作が似ていても、すべての拡張項目を相互に使えるとは限りません。既存の設定要件を確認したうえで、サブスクリプション形式、アプリごとの通信振り分け、バックグラウンドでの使い勝手を比較してください。デスクトップとスマートフォンで同じサブスクリプションを使う場合も、ローカル待ち受けやシステムへの通信の受け渡しは端末ごとに設定する必要があります。
V2FlyコアはMITライセンス、XrayコアはMPL 2.0ライセンスを採用しています。クライアントとその依存コンポーネントにも、それぞれのライセンスが適用されます。オープンソースであることは、ライセンスの範囲内でコードを閲覧、使用、変更できるという意味であり、すべてのコンポーネントが同じペースでリリースされるという意味ではありません。ライセンス情報はソフトウェアの使用条件や配布条件を理解するためのもので、個々の機能、動作環境、設定内容の確認に代わるものではありません。
クライアントは接続に使うツールであり、利用可能なリモートサービスを自動で用意するものではありません。サーバーアドレス、認証情報、関連パラメーターは利用者自身で用意する必要があります。トップページに掲載したサンプルアドレスは項目の説明用で、ルーティングの例も照合方法を示すものです。学習用に例を使う場合は、構造の説明と既存サービスの値に置き換える必要がある項目を見分け、サンプル設定を完全なノードとして使わないようにしてください。
クライアントの画面、コア、ルーティング用データファイルは、それぞれ別に更新されることがあります。クライアントの更新後に一部の項目が再生成されたり、ルールデータの更新後に同じ分類名に含まれるドメインやアドレスが変わったりする場合があります。設定の入手元とカスタム内容を分けて記録し、重要なルールには内容が分かるメモを残してください。動作が変わった場合は、まず生成された設定とログを比較してから、設定を戻すか判断しましょう。
サブスクリプションはリモートのパラメーターをまとめて更新するのに適しています。一方、バックアップでは端末側の設定も保存する必要があります。両者は代用できません。サブスクリプションに、システムプロキシの設定、アプリごとの通信振り分け、手動で追加したルーティングルールが含まれるとは限りません。端末間で移行する際は、再利用できるノード情報と、端末固有の待ち受け、権限、自動起動設定を分けて整理してください。このサイトでは設定リファレンスを項目別に、チュートリアルを操作順にまとめています。問題に合わせて参照先を選べます。
NOTES / 設定メモ
初回インストールからルールの優先順位、証明書エラーまで、問題に応じて確認できます。記事のパラメーター解説は設定リファレンスとあわせて活用し、変更前に使用中のコアとクライアントの設定範囲を確認してください。
TLS証明書エラーの主な原因として、システム時刻のずれ、SNIと証明書ドメインの不一致、偽装ドメインの誤設定を取り上げ、クライアントでの確認箇所を順に解説します。
記事を読む →domain、full、regexp、geosite、geoipなどの照合プレフィックスの書き方を解説し、routingルールが上から順に照合される仕組みと、domainStrategyが照合結果に与える影響を説明します。
記事を読む →v2rayNの展開と起動、システムプロキシモード、ローカルポート、自動起動など初回設定のポイントを紹介し、ランタイム不足、ポート競合、権限ダイアログなどへの対処法を解説します。
記事を読む →