CONFIGURATION LAYERS
設定がどのレイヤーに属するかを確認してから、該当する画面や項目を変更しましょう。サブスクリプション管理、システムプロキシ、コア設定はそれぞれ役割が異なります。「接続済み」という表示だけで、通信経路全体が正常だと判断することはできません。
インバウンドは、クライアントがどこから通信を受け付けるかを決めます。一般的には、ローカルでSOCKSまたはHTTPポートを待ち受け、アプリやシステムプロキシからそのポートへ接続します。サーバーをインポートしただけでは、アプリがプロキシを使うとは限りません。問題の切り分けでは、待ち受けアドレスとポート、アプリ側の設定が一致しているかをまず確認しましょう。自分の端末だけで使う場合は通常、ループバックアドレスにバインドします。LANに公開する場合は、アクセス制御とファイアウォールも確認してください。アプリごとにアドレスを入力するよりシステムプロキシでまとめて設定するほうが簡単ですが、それを利用するかどうかはアプリによって異なります。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}
]
}ルーティングでは、ドメイン名、アドレス、インバウンドのタグなどに基づいて通信を判定し、指定したアウトバウンドへ振り分けます。ルールは通常、上から順に評価されるため、具体的な条件を広い条件より前に置きます。まず直接接続とプロキシの基本的な使い分けを設定し、その後でLAN内通信、特定ドメイン、アプリごとの要件を追加しましょう。未知のルールを一度に大量に取り込むより、問題を特定しやすくなります。全体モードの切り替えだけで運用する場合と違い、ルールによる振り分けならLANへのアクセス経路を維持できます。以下はルールの一例です。参照先のアウトバウンドタグが実際の設定に存在すること、ドメイン判定に必要な情報を取得できることを確認してください。
{
"routing": {
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
}
]
}
}DNSはドメイン名をIPアドレスに変換しますが、アプリ、OS、プロキシコアがそれぞれ名前解決を行う場合があります。接続できないときは、DNSサーバーのアドレスを変えるだけでなく、どこで名前解決しているか、リクエストがどの経路を通るかを確認しましょう。特定のリクエストにコアのDNS設定が使われるかは、インバウンド、ルーティング、アウトバウンドの設定によって異なります。システムDNSを単独で変更する方法と比べ、コア側ではルーティング要件に応じて一部の名前解決を制御できますが、すべてのアプリに自動で適用されるわけではありません。以下には実際の設定キーを示しています。リゾルバーへの到達性、暗号化方式、ブートストラップ用の名前解決は別途確認してください。
{
"dns": {
"servers": ["1.1.1.1", "8.8.8.8"]
}
}アウトバウンドは、コアから接続をどのように送出するかを定義します。プロキシサーバーへの接続のほか、直接接続やブロックも設定できます。サーバーのプロトコル、トランスポート、セキュリティ設定は一式で一致させる必要があり、アドレスとポートが同じだからといって同じ設定とは限りません。GUIクライアントでは、サーバー情報からプロキシ用アウトバウンドが生成され、ルーティングからタグで参照されるのが一般的です。設定全体を直接編集するより、まずクライアントが対応するインポート機能を使うほうが、項目間の関係を保ちやすくなります。以下は直接接続用アウトバウンドの例で、リモート接続情報は含まれていません。サブスクリプションの代わりになるサーバー設定でもありません。タグを変更する場合は、ルーティング側の参照先も確認してください。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}サブスクリプションは、サーバー情報をまとめて取得するためにクライアントが管理する仕組みであり、コア設定のトップレベルキーではありません。配布元ごとにグループを作り、サブスクリプションURLを入力して更新した後、サーバー情報が表示されるか、プロトコルを正しく読み取れるかを確認しましょう。共有リンクを1件ずつ貼り付ける方法に比べ、サブスクリプションならサーバー情報の更新を管理しやすくなりますが、手動で加えた変更は次回の更新で上書きされる場合があります。複数の配布元を使う場合は、グループごとの用途を明確にしてください。個人のアクセス情報を含むURLをスクリーンショットや公開ログに載せないよう注意しましょう。以下のキーは生成後のコア設定に含まれるもので、サブスクリプション自体の項目ではありません。
{
"log": { "loglevel": "warning" },
"inbounds": [],
"outbounds": []
}設定例は構造を確認するためのもので、接続設定一式ではありません。実際に動作させるには、有効なサーバー情報と、互いに対応するタグが必要です。コアによって対応する項目やプロトコルの機能が異なる場合があるため、変更前にクライアントで選択中のコアを確認してください。正常に動作している設定を保存し、一度に変更するレイヤーを1つに絞って、同じアプリと接続先で結果を確認することをおすすめします。サブスクリプションの更新によって設定が再生成される場合は、生成された一時ファイルを直接編集せず、クライアントが用意するルール設定やカスタム設定の画面を使いましょう。
CLIENT SHELF
デスクトップではv2rayNを中心に、Androidではまずv2rayNGを確認し、V2Flyコアが必要な場合はv2flyNGを検討しましょう。OSを選んだら、CPUアーキテクチャとインストール形式を確認してください。クライアント名が似ていても、インストールパッケージを相互に使えるとは限りません。
v2rayNを選びましょう。ダウンロードページでは、クロスプラットフォームのUIを採用したデスクトップ版と、従来のUIを維持したWPF版を選べます。どちらもサーバー、サブスクリプション、ルーティングの管理に使えます。初めてインストールする場合は、OS要件に合うものを1つ選べば十分です。同じサブスクリプションを取り込むために、両方のクライアントを同時に実行する必要はありません。
インストール後は、まずローカルプロキシのポートを確認し、システムプロキシを設定しましょう。アプリがシステムプロキシに従わない場合は、アプリ側で個別にプロキシを設定するか、TUNモードについて確認してください。複数のクライアントが同時にシステム設定を変更すると、ポートの競合やプロキシの接続先の混乱が起きることがあります。問題を切り分ける際は、実行するクライアントを1つに絞りましょう。
v2rayNのデスクトップクライアントを選び、Macのチップに応じてApple Silicon版またはIntel版をダウンロードしてください。「このMacについて」でチップやプロセッサ情報を確認してから、対応するアーキテクチャを選べます。実際にインストールを繰り返して判別する必要はありません。
初回起動時は、OSのアクセス許可に関する通知を確認し、ネットワークプロキシがクライアントの待ち受けポートを指しているか確認してください。クライアントを終了してもネットワークに接続できない場合は、システムプロキシの設定が残っていないかを確認しましょう。TUNはより低いレイヤーで通信を取り込む機能です。有効にする前に、必要な権限とルーティングの説明を確認してください。あらゆる接続問題を解決する万能なスイッチではありません。
まずはXrayコアを採用したv2rayNGを検討してください。既存の設定でV2Fly固有の機能が必要な場合は、v2flyNGも確認しましょう。ダウンロードページにはarm64版と汎用版があります。最近の一般的な端末ではarm64が使われていますが、アーキテクチャがわからない場合は、端末情報と各パッケージの要件を先に確認してください。
初回接続時は、OSのVPN接続許可が必要です。アプリごとの設定では、どのアプリの通信をプロキシ経由にするかを指定します。これはサーバー側のルーティングルールとは別の設定です。バックグラウンドで接続が切れる場合は、OSのバッテリー管理やバックグラウンド実行の制限を確認してください。また、VPN接続を使う他のアプリが通信の取り込み機能を使用していないかを確認してから、クライアントの設定を調整しましょう。
v2rayNを選び、ディストリビューションのパッケージ形式に合わせてdebまたはrpmを選んだ後、x64またはarm64のアーキテクチャを確認してください。ここではGUIクライアントのダウンロード先を案内しています。実際に動作するかは、デスクトップ環境、実行時の依存関係、パッケージの要件にも左右されるため、ディストリビューション名だけで判断しないでください。
デスクトップ環境やアプリによって、プロキシ設定の参照方法は異なります。まず、プロキシアドレスを手動で入力できるアプリを使ってローカルポートを確認し、その後でデスクトップ環境のシステムプロキシを確認しましょう。TUNを使う場合は、権限とルーティングを別途設定してください。ネットワークインターフェースを変更するツールを複数同時に実行しないようにしましょう。アップデート前にサブスクリプショングループとカスタムルールを保存しておくと、動作の変化を後から確認できます。
クライアントは設定の実行と管理を行うもので、インストールパッケージにサーバーアドレス、アカウント、サブスクリプションは含まれません。共有リンクを持っている場合は、対応するプロトコルとトランスポートの機能を確認してください。サブスクリプションURLを使う場合は、クライアントが返却される形式を読み取れるか確認しましょう。ウェブページのURLをサブスクリプションURLとして入力したり、単一の共有リンクをサブスクリプション更新欄に入力したりすると、一覧が空になることがあります。インポートに失敗したら、まず入力内容の種類とURLの完全性を確認してください。クライアントを何度も再インストールする必要はありません。
インストール後の動作確認は2段階で行います。まず、クライアントがサーバー設定を読み込み、コアを起動できることを確認します。次に、対象アプリの通信が想定した経路を通っているかを確認します。サーバー一覧が表示されること、接続スイッチがオンであること、テストが一度成功したことだけでは、すべてのアプリが同じ出口を使っているとは限りません。サブスクリプション、サーバー情報、ログのスクリーンショットを共有する場合は、アクセスURLに含まれる個人識別情報や認証情報を隠し、必要なエラーの種類と設定名だけを残してください。
PROJECT V ECOSYSTEM
プロジェクト、コア、クライアント、サーバー設定を区別すると、それぞれの機能がどこで提供されているかを把握でき、問題の切り分けにも役立ちます。名称が似ていても、設定できる内容まで同じとは限りません。
PROJECT / CORE / CLIENT
Project Vはプロキシ通信に関連するツールやコンポーネントを展開しており、V2Rayはそのエコシステムで広く使われている名称です。実際の利用では、GUIクライアントからサーバーを取り込み、コアを起動してプロキシ設定を管理するのが一般的です。すべての動作パラメーターを直接編集する必要はありません。コアはプロトコル、トランスポート、ルーティングなどを処理し、GUIクライアントはよく使う操作を画面上にまとめます。この役割分担を理解すると、画面を変えてもプロトコルの機能が変わるとは限らない一方、コアを切り替えると設定が受け付けられない場合がある理由がわかります。
日常会話で「V2Rayの設定」と呼ばれるものには、サーバーの共有リンク、クライアントに保存されたサーバー情報、コアが読み込むJSONファイルなど、複数の種類があります。これらをそのまま混同してはいけません。共有リンクには通常、サーバー1台分の情報が含まれます。サブスクリプションは複数のサーバー情報を配布するためのもので、コア設定にはローカルのインバウンドやルーティングも含まれます。問題を調べる前に、どの種類の情報を指しているのかを確認すると、クライアントのサブスクリプション設定をコア設定に誤って書き込むといった混乱を避けられます。
V2FlyはV2Ray関連コアのコミュニティでの開発を引き継ぎ、Xrayは共通の技術基盤から独自の実装や機能を発展させてきました。共通する概念や設定方法もありますが、すべての項目、プロトコルの組み合わせ、トランスポートの動作が完全に一致するとは限りません。名前や画面の見た目ではなく、既存のサーバー設定に必要な機能と、クライアントに実際に組み込まれているコアを基準に選びましょう。
たとえば、サーバーのプロトコル名が同じでも、トランスポート層やセキュリティ設定、拡張機能の違いによって、特定のコアが必要になる場合があります。設定を読み込めない、または起動できない場合は、エラーに記載された項目名や機能名を確認し、その設定がどの環境に対応するかを調べましょう。サーバーに接続できないと決めつけると、コアが設定を受け付ける前の段階で起きている問題を見落とすことがあります。
v2rayNはデスクトップ向けの設定・実行クライアントで、当サイトで紹介する3種類のデスクトップOSに対応しています。利用できる機能は配布パッケージやコアの設定によって異なります。v2rayNGはAndroid端末向けで、当サイトではXrayコアを使う一般的な方法を紹介しています。v2flyNGはV2Flyコアを使いたい場合の選択肢です。いずれもオープンソースのクライアントで、公開されている実装や設定の動作を確認しながら使えますが、サーバーサービスではなく、利用可能なサブスクリプションを自動で生成するものでもありません。
あるクライアントで正常に動作している設定を別のクライアントへ移す場合も、インポート形式、ルーティングルール、通信の取り込み方を確認してください。サーバー情報をインポートしても、システムプロキシ、アプリごとの設定、ローカルのカスタムルールまで自動で移行されるわけではありません。移行後は、まずサーバー1台と対象アプリ1つで動作を確認し、その後でグループや振り分け設定を戻すと、違いを特定しやすくなります。クライアントの選び方はクライアント比較をご覧ください。
Project Vのエコシステムに含まれるプロジェクト、コア、GUIクライアントは、それぞれ異なるオープンソースライセンスを採用している場合があります。たとえばV2FlyのV2RayコアとXrayコアはMPL 2.0を採用していますが、GUIクライアント本体や同梱コンポーネントについては、それぞれのライセンスを確認してください。オープンソースライセンスは、コードの利用、変更、再配布に関する条件を定めるもので、サブスクリプションの提供元が定める利用規約やサーバーの稼働状況とは別です。認証情報、アクセス権、サーバー設定は利用者自身で管理する必要があります。
クライアントの更新、コアの更新、サブスクリプションの更新は、それぞれ別の操作です。クライアントの更新は画面や管理方法を変える場合があり、コアの更新は設定の読み込みやプロトコルの動作に影響することがあります。サブスクリプションの更新は、主にサーバー情報を更新します。動作が変わった場合は、まずどの種類の更新を行ったか記録し、更新前に保存した設定と比較してください。クライアント、コア、DNS、ルールを同時に変更してからテストすると、接続経路が変わった原因を特定しにくくなります。
FIELD NOTES
サブスクリプションの入力からウェブサイトへのアクセスまで、問題が起きた段階に応じて記事を探せます。インポート時の問題はURLや形式を確認し、クライアントが起動しているのにアクセスできない場合は、システムプロキシ、ルーティング、DNSを調べましょう。段階に応じたチェックリストを使い、関係のない手順を繰り返さないようにします。
プロキシには接続できるのにインターネットへアクセスできない場合に、システムプロキシの状態、ローカルポート、ルーティングルール、DNSの名前解決、時刻同期の順に確認し、問題の箇所を特定します。
記事を読むサブスクリプションが使えなくなる主な原因を、リンク切れ、形式の非互換、更新時にプロキシを経由していない、証明書エラーなど、発生頻度の高い順に紹介し、それぞれの確認・修正手順を解説します。
記事を読むv2rayNのサブスクリプショングループ設定と、v2rayNGのサブスクリプション画面での操作をそれぞれ解説します。Base64形式のサブスクリプション、単一サーバーの共有リンク、クリップボードからの取り込みの違いも説明します。
記事を読む