LOOKUP GUIDE
設定項目から用語を探す
インポートに失敗したりノード一覧が空だったりする場合は、まず「サブスクリプションとノード」を確認します。プロトコルの項目を比較するときは「プロキシプロトコル」、バイパス・直接接続・ドメイン判定を調整するときは「ルーティング」、仮想インターフェースや名前解決経路を扱うときは「トランスポートと暗号化」を参照してください。
01 / PROTOCOLS
プロキシプロトコル
プロトコルの項目は、クライアントがサーバーとセッションを確立する方法を決めます。同じ名称でもすべてのパラメータを互換利用できるとは限らないため、設定をインポートするときはトランスポート層とセキュリティ層も確認する必要があります。
- VMess vmess
- VMessはProject Vエコシステムのプロキシプロトコルです。クライアント設定には通常、サーバーアドレス、ポート、ユーザー識別子、セキュリティオプション、トランスポートパラメータが含まれます。共有リンクには一般的な項目を含められますが、拡張項目の解釈はクライアントによって異なる場合があります。
- VLESS vless
- VLESSは比較的シンプルなプロトコル構造を持ち、暗号化と通信相手の検証をTLSやREALITYなどの外部セキュリティ層に委ねることが多い方式です。設定時はユーザー識別子、トランスポート方式、フロー制御、サーバー名を同時に確認してください。アドレスとポートだけをコピーしても、完全な接続を確立できないことがあります。
- Trojan trojan
- TrojanはTLS接続上でデータを転送するプロキシプロトコルです。一般的な設定項目にはサーバーアドレス、ポート、パスワード、サーバー名、証明書検証オプションがあります。クライアントとサーバーのTLSパラメータが一致している必要があり、重要な項目が1つでも異なるとハンドシェイクに失敗する可能性があります。
- REALITY security
- REALITYはXrayエコシステムのトランスポートセキュリティ方式で、VLESSと組み合わせて使われることが多い機能です。独立したノード一覧ではなく、スイッチ1つだけで有効にできるものでもありません。クライアントのコアが対応していることに加え、公開鍵、ショートID、サーバー名などの関連パラメータを正しく入力する必要があります。
- TLS transport security
- TLSは暗号化された接続を確立し、通信相手の身元を検証するための汎用的なセキュリティプロトコルです。クライアント設定ではサーバー名が証明書検証に関わるため、接続先アドレスと単純に同一視できません。証明書検証を無効にすると安全性の境界が変わるため、通常のトラブルシューティングとして長期間設定すべきではありません。
02 / CORE
コアとアーキテクチャ
グラフィカルクライアントは設定のインポート、表示、生成を担当し、プロキシコアはプロトコル、DNS、ルーティングの処理を実行します。この関係を理解すると、機能が画面側とコア側のどちらによって提供されているかを判断しやすくなります。
- V2Ray Project V
- V2Rayは、Project Vエコシステムの設定モデル、プロトコル実装、ツール群を指す名称として使われるほか、初期のコアプログラムを指す場合もあります。ガイドを読むときは、技術エコシステム全体の話か、特定のコアの話かを文脈で判断してください。クライアント名にV2Rayが含まれていても、すべてのクライアントが同じコア派生系を使うとは限りません。
- V2Fly v2fly core
- V2FlyはV2Rayの技術路線を受け継ぐコミュニティ運営のプロジェクトおよびコア群で、汎用的なプロキシ機能とモジュール化された設定を重視します。v2flyNGはこのコア方針を採用しており、対応するプロトコル実装と設定仕様が必要なAndroid環境に適しています。コアは実際のプロトコル要件に基づいて選択してください。
- Xray xray core
- Xrayは関連する技術体系から発展したコアの派生系で、VLESSやREALITYなどの機能に対応しています。v2rayNやv2rayNGの一般的な設定でもXrayのコア機能が使われます。共有リンクを利用できるかどうかは、クライアントのバージョン、コアの対応状況、設定項目が揃っているかによって決まります。
- プロキシコア core
- プロキシコアは、プロトコルの解析、接続の確立、DNS処理、ルーティングを担う基盤プログラムです。グラフィカルクライアントは通常、ユーザーの選択をコア設定に変換してから、対応するプロセスを起動します。起動に失敗した場合は、画面設定の誤り、設定生成の誤り、コアの実行エラーを切り分けてください。
- インバウンド inbound
- インバウンドは、コアが端末上のアプリからのトラフィックを受け取る入口です。ローカルのSOCKS、HTTP、TUNインターフェースなどが一般的です。インバウンド設定では待受アドレス、ポート、受信方式を指定します。システムプロキシは通常、対応アプリのリクエストをローカルHTTPまたはSOCKSインバウンドへ送ります。
- アウトバウンド outbound
- アウトバウンドは、コアが処理したトラフィックの出口で、リモートプロキシ、直接接続、ブロックなどを指定できます。ルーティングルールの主な役割は、条件に一致したトラフィックへアウトバウンドを選ぶことです。アウトバウンドのタグを変更するときは、そのタグを参照するルーティングルールも同時に確認してください。
03 / SUBSCRIPTION
サブスクリプションとノード
サブスクリプションは設定をまとめて配布・更新する仕組みで、ノードはその中から選べる個別の接続情報です。速度測定、グループ分け、更新操作はいずれもこの2層の対象を中心に行います。
- サブスクリプション subscription
- サブスクリプションは1つのURLから提供され、定期的に更新できるノードまたは設定データの集合です。URLを追加した後、通常は一度更新を実行して、ノードをローカル一覧へ反映させる必要があります。更新に失敗した場合は、URLの有効性、ネットワーク接続、レスポンス内容、形式の互換性を順に確認してください。
- ノード profile
- ノードはクライアント内の1件のリモート接続設定で、プロトコル、アドレス、ポート、認証パラメータ、トランスポート設定などを含みます。ノード名は識別用にすぎず、実際の接続品質を決めるものではありません。利用できるかどうかは、設定の完全性、接続テスト、実際のアクセス結果を総合して判断してください。
- サブスクリプショングループ group
- サブスクリプショングループは、異なるサブスクリプションの提供元やノード集合を分類するためのクライアント上の管理単位です。更新元の区別、ノードの絞り込み、個別の更新方針の設定に役立ちます。グループを削除する前に、そこに含まれるノードが現在の設定やルーティングから参照されていないか確認してください。
- 遅延 latency
- 遅延は、端末からプローブを開始して応答を受け取るまでの時間です。特定の宛先、時刻、テスト方法における接続所要時間だけを示し、スループットや長期的な安定性を単独で表すものではありません。1回の数値より、複数回連続して測定した結果のほうが参考になります。
- 実接続遅延 real connection
- 実接続遅延は、実際にプロトコル接続を確立するかテスト対象へアクセスして所要時間を測定します。クライアントの実際の動作経路に近い一方、単純なネットワークプローブとは異なるテストです。2つの結果に大きな差がある場合は、プロトコルのハンドシェイク、DNS、ルーティング、トランスポート層の設定を詳しく確認してください。
04 / ROUTING
ルーティング
ルーティングシステムは宛先ドメイン、IP、ポートなどの属性を読み取り、トラフィックに使用するアウトバウンドを決定します。ルールの順序とマッチ条件も重要で、範囲が広すぎるルールは後続のトラフィックを先に捕捉する可能性があります。
- ルーティングルール routing rule
- ルーティングルールは、ドメイン、IP、ポート、ネットワーク種別、プロセスなどの条件に基づいてトラフィックのアウトバウンド方式を決めます。複数のルールは通常、設定順にマッチングされ、先に一致したルールがそのまま結果を決めることがあります。変更前に現在のモードを記録しておくと、異常時に元へ戻しやすくなります。
- トラフィック分岐 traffic routing
- トラフィック分岐は、異なる宛先やアプリをルールに従ってプロキシ、直接接続、その他のアウトバウンドへ振り分ける処理です。ノードを順位付けするのではなく、トラフィックの種類ごとに経路を決めます。ドメインルールとIPルールが同時に存在する場合は、DNSの応答結果とルールの優先順位も考慮する必要があります。
- GeoIP IP ruleset
- GeoIPは、IPアドレスの所属地域やネットワーク種別ごとに整理されたルールデータで、ルーティングシステムによる宛先アドレスの判定に利用できます。リアルタイムの位置情報サービスではなく、ルールデータファイルに依存します。データのバージョンや分類方法によって、最終的な判定結果が変わる場合があります。
- GeoSite domain ruleset
- GeoSiteは、用途やカテゴリ別に整理されたドメインルールの集合で、ドメインルールを一件ずつ管理する手間を減らします。通常はサーバーが最終的に返すIPではなく、ドメインそのものに基づいて判定します。利用前に、クライアントのコアが対応するルールデータを備えているか確認してください。
- システムプロキシ system proxy
- システムプロキシは、OSに保存され、対応アプリへ提供されるプロキシアドレス設定です。通常はクライアントのローカル待受ポートを指定します。この経路を自動的に使うのは、システムプロキシ設定を読み取るアプリだけです。設定を読み取らないプログラムには、必要に応じてTUNモードやアプリ側のプロキシ設定を検討してください。
05 / TRANSPORT
トランスポートと暗号化
この分類では、データがどのようにコアへ入り、何によって運ばれ、どのように名前解決されるかを説明します。接続トラブルの切り分けでは、プロトコル、セキュリティ層、トランスポート層、DNS経路を分けて確認する必要があります。
- TUNモード virtual interface
- TUNモードは仮想ネットワークインターフェースでシステムトラフィックを受け取り、システムプロキシ設定を読み取らないアプリにも適用できます。有効化には通常、対応するシステム権限が必要で、ルーティングテーブルやDNSが変更される場合があります。ネットワークに異常があるときは、まずTUNモードを終了し、仮想インターフェースとルーティングが復旧しているか確認してください。
- FakeDNS DNS mapping
- FakeDNSはドメインに一時的なマッピングアドレスを割り当て、コア内にドメインとマッピングの対応関係を保持します。アプリがそのマッピングアドレスへ接続すると、コアは元のドメインを復元してドメインルーティングを続行できます。TUNモードと併用されることが多い機能ですが、アドレスプールとDNSフローを適切に設計する必要があります。
- DNSリーク DNS path
- DNSリークは、アプリのドメイン検索が想定した名前解決経路を通らず、別のDNS経路から送信される現象です。アプリ独自の名前解決、システムキャッシュ、TUN設定の不備、ルール順序の不一致などがよくある原因です。切り分けでは、アプリ、OS、クライアントのコアがそれぞれどの名前解決入口を使っているか確認してください。
- WebSocket ws
- WebSocketはHTTP接続のアップグレード機構を基盤とする双方向通信方式で、プロキシプロトコルのトランスポート層として利用できます。設定には通常、パス、Hostフィールド、TLS関連パラメータが含まれます。クライアントとサーバーでパスやHostフィールドが一致しない場合、トランスポート層で接続を拒否されることがあります。
- gRPC http/2
- gRPCはHTTP/2を基盤とするリモート呼び出しフレームワークで、一部の設定ではプロキシデータストリームの転送に使われます。関連設定には通常、サービス名、セキュリティ層、サーバー名が含まれます。WebSocketとは項目構成が異なるため、トランスポート名だけを置き換えて元のパラメータを流用することはできません。
- トランスポート層 transport
- トランスポート層は、プロキシプロトコルのデータをどの接続方式で運ぶかを示します。TCP、WebSocket、gRPCなどが一般的です。同じプロトコルでもトランスポート層が異なれば、設定項目とハンドシェイクの流れも変わります。ノードのインポート後にトランスポート情報が欠けている場合は、むやみに選択肢を切り替えず、設定元に戻って確認してください。
NEXT STEP
用語をクライアント設定に対応付ける
用語集は概念の確認に使えます。具体的な操作手順は設定ガイドを参照してください。コア、サブスクリプション、ルーティング、TUNのつながりを体系的に理解したい場合は、初級から応用までのハンドブックをお読みください。