GUIクライアントから始め、実際のJSON設定でインバウンド、アウトバウンド、ルーティングを理解し、中国語の操作ガイドを参照できます。
CONFIGURATION / 設定ガイド
まず、リクエストの入口、マッチング条件、最終的な転送先を整理しましょう。そのうえで設定を調整すれば、問題の切り分けが明確になります。
インバウンドはアプリから渡されたリクエストを受け取る設定で、リモートサーバーのアドレスとは異なります。デスクトップアプリはローカルのSOCKS経由でコアに接続でき、対応していればシステムプロキシを利用することもできます。例ではループバックアドレスだけで待ち受けるため、ローカル利用に適しています。ポート番号はクライアントの画面やアプリ側の設定と一致させてください。UDPを有効にすると、その入口で該当するリクエストを処理できるようになりますが、転送の成否はアプリ、アウトバウンド、サーバーにも左右されます。GUIクライアントは通常、インバウンドの設定項目の多くを自動生成します。手動編集する前に、現在の設定が再生成されるか確認しましょう。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}ルーティング判定はリクエストがコアに届いた後に行われます。アプリがシステムプロキシを参照するかどうかとは別の仕組みです。通常、ルールは上から順に照合され、一致すると指定されたタグのアウトバウンドに転送されます。例ではプライベートIPアドレスを直結アウトバウンドに送ります。LANへのアクセスを理解するための基本例であり、地域別の振り分け設定一式ではありません。クライアント内蔵のモードはルールとデータファイルを組み合わせるため、モード名だけで各ドメインの接続先を判断することはできません。手動でルールをすべて書くより、プリセットのほうが始めやすいでしょう。細かく振り分ける場合は、タグ、条件、ルールの順序を確認してください。
{
"outbounds": [
{ "tag": "direct", "protocol": "freedom" }
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}DNS設定はリクエストの入口とあわせて考える必要があります。アプリが先に名前解決してIPアドレスをコアに渡す場合もあれば、ドメイン名を渡して、ルーティング時や接続時にコアが名前解決する場合もあります。例では設定の構造を示すためにローカルのリゾルバーを使用しており、すべての環境で最適な選択というわけではありません。DNSサーバーを変更する前に、問い合わせの経路、ネットワークへの到達性、ルーティング方針を確認し、一度に複数の条件を変えないようにしましょう。システムDNSだけを変更する場合と比べて、コアのDNS設定は適用範囲が明確ですが、すべてのアプリの問い合わせが自動的にコアを経由するわけではありません。ブラウザー独自の名前解決も別途確認が必要です。
{
"dns": {
"hosts": {
"docs.example.com": "192.0.2.10"
},
"servers": ["localhost"]
}
}ログはリクエストがどの段階で失敗したかを調べるのに役立ちますが、1件のエラーだけですべての接続状況を判断することはできません。問題を一度再現してから、時刻を手がかりに名前解決、接続、ハンドシェイクに関する記録を確認しましょう。例ではログレベルをwarningに設定しています。切り分け中は、クライアントが対応する範囲で一時的に詳細度を上げ、作業後に元へ戻してください。設定一式を何度も入れ替えるより、エラーの種類ごとに検証するほうが、確認できた内容を維持しやすくなります。ログを共有する前に、サブスクリプションURL、識別情報、アクセス先を削除してください。設定の構文が正しくても、リモートサーバーに接続できるとは限りません。
{
"log": {
"loglevel": "warning"
}
}CLIENTS / プラットフォーム
デスクトップではv2rayN、Androidではまずv2rayNGを検討し、コアの互換性に応じてv2flyNGも選べます。OSとCPUアーキテクチャを確認してから、ダウンロードページでインストーラーを選んでください。
v2rayNにはデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォーム対応のUIを採用し、WPF版は従来の操作画面に慣れたユーザー向けです。UIフレームワークは異なりますが、実際に使える機能はリリースノートと選択したコアをあわせて確認してください。画面の違いをそのままプロトコルの違いと考えることはできません。
設定がある場合は、サブスクリプショングループ、ルーティング、DNSの設定を保管してから、プログラムの保存先を切り替えてください。初めて使う場合は、まずどちらか一方のUIでインポートと接続を済ませましょう。クライアントを2つ同時に実行すると、待ち受けポートの競合やシステムプロキシ設定の上書きが起きることがあります。
ダウンロードページへv2rayNにはApple Silicon用とIntel用のダウンロード項目があります。「このMacについて」でチップ情報を確認し、対応するアーキテクチャのインストーラーを選んでください。クロスプラットフォーム版では設定の考え方は共通ですが、権限の確認、メニューの場所、システムプロキシの設定方法は、ほかのデスクトップOSと異なる場合があります。
起動後、まず設定ディレクトリを読み込めることを確認してからサブスクリプションを追加してください。システムプロキシを有効にしてもアプリがプロキシを使わない場合は、アプリ側のネットワーク設定を確認します。システムプロキシを参照しないツールでは、説明に従ってローカルアドレスとポートを個別に指定してください。
ダウンロードページへv2rayNGはXrayコアを使用し、対応するプロトコルやトランスポートが必要な場合に適しています。v2flyNGはV2Flyコアを使う選択肢です。比較的新しい端末ではまずarm64向けを確認し、アーキテクチャがわからない場合は汎用パッケージを検討してください。対応条件はダウンロードページと端末情報で確認してください。
初回接続時に、システムからVPNインターフェースの作成許可を求められます。これは端末の通信をクライアントに渡すための入口であり、リモートサーバーへの接続が確立したことを意味するものではありません。バックグラウンド動作の制限、アプリごとの振り分け、同じシステムインターフェースを使うほかのアプリが、接続の状態に影響することがあります。
ダウンロードページへv2rayNにはdeb形式とrpm形式があり、x64とarm64を選べます。DebianやUbuntuでは通常deb、Fedoraなどでは通常rpmを選択します。パッケージ形式はシステムのパッケージ管理方式に合わせ、CPUアーキテクチャは使用中の端末に一致させてください。
デスクトップ環境によって、システムプロキシへの対応状況は異なります。ブラウザーでは接続できるのにターミナルのツールでは接続できない場合、まずそれぞれが使う接続経路を確認し、すぐにリモートノードを変更しないでください。ログイン時の自動起動、設定ディレクトリへの書き込み権限、ローカルポートの使用状況も個別に確認しましょう。
ダウンロードページへFIRST CONNECTION / はじめての接続
始める前に、有効なサブスクリプションURLか、個別ノードの接続情報を用意してください。クライアントは設定を保存してコアを起動するもので、インストールするだけでは接続先の情報は提供されません。ここでは主にGUIを使い、まず最小限の構成で接続し、その後ルーティングやカスタム設定を追加します。
v2rayNのサブスクリプショングループにURLを追加し、識別しやすい名前を付けてから更新します。Androidクライアントでも、先にサブスクリプショングループを保存してからノード一覧を更新してください。個別の共有リンクはクリップボードからインポートできますが、共有リンクとサブスクリプションURLは入力方法が異なります。誤った画面に入力すると、解析に失敗する場合があります。
一覧に項目が表示されたら、プロトコル、サーバーアドレス、ポート、トランスポート方式、安全設定が保持されているか確認してください。ノード名は表示用のラベルであり、接続情報の確認には代わりません。サブスクリプションを更新すると手動で変更した項目が上書きされることがあります。継続して使う変更は、独立した設定やクライアントのオーバーライド機能を使い、変更元も記録しておきましょう。
サブスクリプションURLには認証情報が含まれる場合があります。トラブル調査でURL全体が写ったスクリーンショットを共有しないでください。一覧が空の場合は、まず更新結果を確認し、URLにアクセスできないのか、応答内容に対応していないのか、解析エラーなのかを切り分けてから再インポートを検討します。
使用するノードを設定してから、システムプロキシの入口とルーティングモードを選びます。システムプロキシは、システム設定に従うアプリのリクエストをクライアントへ渡すかどうかを決めます。ルーティングモードは、コアに届いたリクエストを直結とプロキシのどちらのアウトバウンドに送るかを決めます。どちらにも「プロキシ」という言葉が含まれていても、同じレイヤーの設定ではありません。
初回の確認では、ルールが少なく経路を把握しやすい設定から始めましょう。LANのリソースにアクセスする場合は、プライベートアドレスのルールが優先されるか確認してください。「中国本土を除外」モードでも、ドメインやIPアドレスのルールデータに依存することがあり、モード名だけで全アプリが想定どおりに振り分けられるとは限りません。切り替えた後は新しい接続を作り、実際の動作を確認しましょう。
Androidでは、アプリごとのプロキシ対象も確認してください。「選択したアプリだけをプロキシ」と「選択したアプリを除外」は意味が逆です。検証中は一度に設定を1つだけ変更し、直前に動作を確認できたノードを残しておくと、入口の問題とノードの問題を切り分けやすくなります。
接続を開始したら、まずクライアントが設定エラーをすぐに報告していないことを確認し、対象アプリから新しいリクエストを送ります。ノード一覧のテスト結果は特定の方法で測定した値にすぎず、ブラウザーの閲覧、ファイル転送、リアルタイム通信が必ず使えることを示すものではありません。実際に利用するアプリと接続先で判断してください。
接続できない場合は、ローカルの入口、名前解決、リモート接続、プロトコルのハンドシェイクの順に確認します。アプリの通信がローカルの入口を通っていないなら、リモート側の設定を繰り返し変えても解決しにくいでしょう。リモートには到達しているのにハンドシェイクに失敗する場合は、プロトコルの項目、安全設定、システム時刻を確認します。ログのエラー種別は、この2つの状況を見分ける手がかりになります。
接続を確認したら、カスタムルーティング、バックグラウンド動作、自動起動を追加します。クライアントを終了する前に、使わなくなったシステムプロキシを解除してください。停止したローカルポートをアプリが参照し続けるのを防げます。詳しいガイドでは、各設定画面とよくある分岐を解説しています。
PROJECT V / コアとクライアント
設定を管理するのはクライアント、接続を実行するのはコアです。プロジェクト間には技術的なつながりがありますが、プロトコル対応、設定項目の意味、更新頻度はそれぞれ確認する必要があります。
Project Vは、V2Rayの技術的な背景を理解するための出発点です。V2Rayはプロキシ機能をインバウンド、アウトバウンド、トランスポート、ルーティングなどのモジュールに分け、ローカルアプリの入口とリモートへの接続方法を個別に設定できます。V2FlyはV2Rayを引き継いでコミュニティによるメンテナンスを続けています。Xrayは関連する技術基盤から発展した独自の実装と拡張を持ちます。共通する設定概念はありますが、すべての項目やプロトコルの組み合わせを相互に置き換えられるわけではありません。
資料を読むときは、まずどのコアを対象にした説明なのかを確認し、次にクライアントがその設定を生成できるかを見ましょう。たとえばREALITYは安全なトランスポートに関わる技術の組み合わせで、あらゆるプロキシプロトコルと並ぶ単独の選択肢として単純化できません。クライアントに関連する設定項目があっても、接続を確立するにはリモート側の情報と実際に使うコアの両方が対応している必要があります。
v2rayNはデスクトップでノード一覧、サブスクリプション、ルーティングのプリセット、コアの起動を管理します。v2rayNGはAndroidのシステムVPNインターフェースとXrayコアを組み合わせて通信を処理します。v2flyNGはV2Flyをベースにした別の設定経路を提供します。いずれもオープンソースのクライアントですが、画面操作、設定の生成方法、互換性の範囲は、名前が似ているだけでは判断できません。
画面上で保存できても、設定値が記録されたことを示すだけです。コアが生成された設定を読み込み、解析し、リモート側とネゴシエーションする必要があります。カスタム設定モードと通常のノードモードでは生成手順が異なる場合があるため、生成ファイルを直接編集しても変更が維持されるとは限りません。編集前に、そのファイルが設定の元データなのか、クライアントが実行時に生成した結果なのか確認しましょう。
まず接続したい場合は、基本ガイドから読みます。「ノード」「サブスクリプション」「トランスポート」などの用語を理解したい場合は用語集を、自分で動作を設定したい場合はJSONガイドを設定セクションごとに参照してください。サンプルコードは一部の構造を説明するもので、アウトバウンド情報がない断片を接続設定一式として使うことはできません。複数の断片を組み合わせる場合は、タグの参照先、配列の階層、ルールの順序も確認しましょう。
READING NOTES / 技術記事
基本の接続を確認したら、具体的な課題に合わせて記事を参照しましょう。インストーラーはOSとUIフレームワーク、速度の問題は経路とローカルの入口、プロトコル選びはリモート設定とコアの対応状況を確認します。課題を分けることで、調整すべき設定を見極めやすくなります。
クロスプラットフォーム版と従来のWPF版について、UIフレームワーク、対応OS、操作性の違いを比較します。まずインストーラーの対応範囲を確認し、既存設定を移行するか判断しましょう。画面の違いとコアの機能は分けて考える必要があります。
記事を読む →速度の問題をノードの負荷、接続経路、ローカル設定の3段階に分けて調べます。DNS、スニッフィング、MTU、ルーティングルールを確認し、再現可能なテスト条件を整えてから、変更前後の結果を一つずつ比較しましょう。
記事を読む →暗号化方式、ハンドシェイク、トランスポートとの組み合わせ、クライアントの対応状況から、各プロトコルの違いを解説します。TLSやREALITYとプロキシプロトコルの組み合わせも整理し、名称だけでなく実際の互換性を基準に選びましょう。
記事を読む →設定キーを探す場合はJSONガイドをご覧ください。サブスクリプション、ノード、コアの違いを確認したい場合は、用語集から参照できます。