設定のレイヤー：プロトコルだけでは接続全体を説明できない
まず4種類の設定項目を分けて考える
ノード名は技術仕様ではありません。リストに地域名や用途が書かれていても、使用プロトコルまでは分かりません。v2rayN のノード編集画面を開き、プロトコル、トランスポート、トランスポート層のセキュリティ設定の順に確認します。それぞれ「リクエストの形式」「データの運び方」「暗号化と接続先の確認」を担います。コアはこれらの取り決めを実際に処理します。各レイヤーを分けて考えると、どちらも VLESS と表示されたノードで設定項目や接続結果が異なる理由を理解できます。
プロトコルは、認証情報、接続先、リクエスト形式を定めます。たとえば VMess はユーザー識別子を使って認証し、Trojan はパスワードでリクエストを認証します。Shadowsocks は選択した暗号化方式と対応する鍵に依存します。トランスポートには、データを直接運ぶ TCP のほか、WebSocket などで追加のカプセル化を行う方式があります。TLS と REALITY は接続のセキュリティに関わる仕組みであり、プロトコルと同じ欄に並ぶ互換の選択肢ではありません。設定画面で一緒に表示されるのは入力しやすくするためで、概念上のレイヤーが同じという意味ではありません。
サーバーから提供された設定値をもとに照合する
ノードを確認する際は、まずアドレスとポートが同じ設定に属していることを確かめ、次に認証情報を照合します。その後、ネットワークの種類、パス、サービス名、セキュリティ層を確認してください。WebSocket のパスはサーバー側の設定と一致させる必要があります。gRPC のサービス名を別のノードからそのままコピーすることもできません。ドメイン名は、サーバーアドレス、TLS のサーバー名、トランスポートのリクエストヘッダーに現れる場合があります。これらは同じこともあれば、それぞれ別の役割を持つこともあります。3つすべてを接続先アドレスに書き換えても解決するとは限らず、正しい役割分担を崩す可能性があります。
クライアントのサーバー名は通常、TLS の SNI に対応し、ハンドシェイク時に接続先として指定する名前を示します。証明書の名前の確認にも使われます。一方、WebSocket リクエストヘッダーの Host はアプリケーション層のリクエスト情報です。接続先アドレスは「最初にどこへ接続するか」を示し、2つの名前はその後の異なる処理で使われます。提供元から完全な共有リンクを受け取った場合は、元の設定を維持してください。個別に変更するのは、明確な設定説明がある場合に限ります。名前が一致しないときは、見た目の不統一を誤設定と決めつけず、まず各項目の用途を確認しましょう。
| レイヤー | 主な設定項目 | 確認ポイント |
|---|---|---|
| プロキシプロトコル | VMess、VLESS、Trojan、Shadowsocks | 認証情報と暗号化方式がサーバー側と一致しているか |
| トランスポート | TCP、WebSocket、gRPC | パス、サービス名、関連するリクエストヘッダー |
| 接続セキュリティ | TLS、REALITY | サーバー名、認証パラメーター、証明書の条件 |
| 実装（コア） | Xray、V2Fly | 該当機能と設定項目の組み合わせに対応しているか |
ローカルでの接続方法とリモート接続を区別する
システムプロキシと Tun は、リモート側のプロトコルではありません。システムプロキシは、その設定に従うアプリのリクエストをローカルのプロキシポートへ送ります。Tun は仮想ネットワークインターフェースを作り、より多くの通信をクライアントの処理経路に取り込みます。どちらも通信がコアに入る方法を変えるもので、VMess を VLESS に変えたり、サーバー側に不足している機能を補ったりするものではありません。ウェブページを開けず、ログにも該当するリクエストがない場合は、まずローカル側の接続方法を確認してください。リクエストがコアに届いているのにハンドシェイクに失敗する場合は、リモート側のプロトコルとセキュリティ設定を見直します。
ルーティングと DNS も別々に考える必要があります。ルーティングはリクエストの出口を選び、DNS はドメイン名をアドレスに変換します。接続テストに成功しても、テスト対象の経路で特定の処理が完了したことを示すだけで、すべてのドメインが同じ出口を通るとは限りません。ルーティング規則を変更すると、ノードは同じままでも一部のサイトへのアクセス結果が変わることがあります。トラブルシューティングでは変更したレイヤーを記録し、一度に1種類の設定だけを変更してください。手順に沿って確認する場合は、接続済みなのにインターネットに接続できない場合の確認リストも参考になります。
プロトコルの設計：4つの方式の違い
VMess：認証と暗号化を一体で設計
VMess は Project V エコシステムを代表するプロトコルの一つです。ユーザー認証、リクエストヘッダー、データ保護を共通の仕様として扱い、プロキシ接続をまとめて定義する用途に適しています。単なるパスワード欄ではなく、ユーザー識別子や認証手順、暗号化方式も関係します。現在の設定では、使用中のクライアントが解析できる認証方式を基準にしてください。古い画面例に合わせて、過去の設定項目をむやみに追加しないようにしましょう。認証処理によっては時刻の精度が重要です。端末の時計が大きくずれていると、設定が正しく見えても認証できないことがあります。
v2rayN で VMess ノードを編集するときは、ユーザー識別子、暗号化方式、トランスポート、TLS の設定を確認してください。共有データに古い互換性向けの設定が含まれていても、すべての実装で今も有効とは限りません。まずサブスクリプションが現在のコアで使えるか確認し、必要であれば設定を再取得します。VMess の利点は、長く使われてきたエコシステムと既存の導入例の多さです。一方、設定の概念が比較的集中しているため、初心者はプロトコル自体の暗号化と外側の TLS を混同しやすく、両方を有効にすれば必ず安全性が上がると思い込むことがあります。
VLESS：プロトコル自体の役割をシンプルに
VLESS は軽量な認証とリクエストの表現を重視しており、プロトコル単体では汎用的なデータ暗号化を提供しません。通常は TLS や REALITY などのセキュリティ機構と組み合わせます。ここでいう「軽量」はプロトコルの役割を指し、回線速度を保証するものではありません。クライアントの暗号化欄が none でも、接続が平文だと判断することはできません。外側のセキュリティ設定も確認してください。逆に、外側のセキュリティも有効でなければ、プロトコル名だけで暗号化されると思い込まないようにしましょう。
VLESS の設定には flow フィールドが含まれる場合があります。これは特定のフロー制御動作を示すもので、自由に選べる速度向上モードではありません。サーバー側で Vision が必要な場合は、クライアントとコアの両方が該当する組み合わせに対応している必要があります。空欄の flow に Vision を設定しても、通常のノードにその機能が追加されるわけではなく、トランスポートの条件が合わなければ接続できないこともあります。ノードを選ぶ際は、プロトコル、トランスポート、セキュリティ層、flow を一つの組み合わせとして比較してください。後半では REALITY と Vision の関係と、両者が別の機能である理由を説明します。
Trojan：TLS を基盤とする認証方式
Trojan の一般的な構成では、TLS で通信を保護し、パスワードでプロキシリクエストを認証します。設定は比較的分かりやすいものの、接続にはサーバー名、証明書、サーバー側の接続口が適切であることも必要です。パスワードが正しくても、証明書名の不一致は解消されません。ノードを編集するときは、提供元のサーバー名とトランスポート設定を維持してください。パスワードの形式が分かりやすいからといって、セキュリティ層を省略してよいわけではありません。また、原因を特定せずに証明書検証を無効にして、設定ミスを隠すことも避けてください。
Shadowsocks：暗号化方式と鍵を正しく組み合わせる
Shadowsocks は SS と略されることが多く、明確な暗号化プロキシ方式を重視しています。設定項目は通常、サーバー、ポート、暗号化方式、パスワードが中心です。方式によって鍵の要件、実装の対応状況、プロトコルの動作が異なるため、似た暗号アルゴリズムを使っているという理由だけで置き換えることはできません。新しい方式と従来方式も、ラベルを一つ変えるだけで互換になるわけではありません。インポート時にパスワード形式のエラーが出たら、まずその方式で指定された鍵の形式を確認してください。構造化された鍵を短い通常のパスワードに置き換えないようにしましょう。
4つの方式はどれも日常的なプロキシ接続に利用できますが、サーバー側の構成を無視した絶対的な優先順位はありません。VMess が安定して使えているなら、別のプロトコル名のほうが新しいというだけで切り替える必要はありません。Xray の機能が必要なら、VLESS の設定全体を確認します。Trojan や Shadowsocks を使う場合は、TLS の条件や暗号化方式の対応状況を先に確かめてください。実際に使える選択肢とは、サーバーが正確なパラメーターを提供し、クライアントが設定全体を表現でき、コアが実行できる範囲の交わりです。ノード一覧で目立つラベルだけを基準にしないでください。
TLS、REALITY、Visionの役割の違い
TLS：接続先を確認してから通信を保護
TLS は通信を暗号化し、証明書などを使ってクライアントが接続先のサーバーを確認できるようにします。一般的な構成では、証明書の信頼チェーン、有効期限、名前の一致を確認する必要があります。ノードの接続先アドレスと、証明書に対応するドメイン名が異なることもあるため、機械的に同じ値にしないでください。ハンドシェイクに失敗したら、まず端末の時刻とサーバー名を確認し、その後にサーバー証明書の状態を調べます。「安全でない接続を許可」を有効にすると検証の範囲が変わるだけで、エラーの原因が解消されるわけではありません。
TLS のハンドシェイク設定と、ブラウザーの外観に関係する設定も区別してください。一部のクライアントには、ハンドシェイクの特徴を選ぶフィンガープリント設定があります。これはユーザーの識別情報ではなく、ユーザー識別子やパスワードの代わりにもなりません。また、すべてのコアで同じように対応されるわけではありません。他のノードのフィンガープリント、サーバー名、アプリケーション層のプロトコル一覧をそのままコピーすると、互換性の問題が増えることがあります。サーバー側から指定がない場合は、サブスクリプションの値か、クライアントに適した既定値を使い、詳細設定をすべて埋めようとしないでください。
REALITY：ハンドシェイクと認証の仕組みを変える
REALITY は、一般的な証明書ベースの構成とは異なる接続確立・認証の仕組みを使います。接続先サイトの TLS の特徴と独自の認証設計を組み合わせて動作するもので、「実在するドメインを適当に入力すれば接続できる」という仕組みではありません。クライアントにはサーバー名、公鍵、ショートIDなどの組み合わせが必要で、サーバー側にも対応する設定が必要です。公鍵は認証に使うもので、ユーザーのログインパスワードではありません。ショートIDもサーバー側で定められた認証パラメーターです。別のノードの値を流用したり、説明用の文字列を実際の接続設定に入力したりしないでください。
クライアントの画面では、公鍵が Public key と表示されることがあります。実装の変更に伴い、別の項目名が使われる場合もあります。設定が正しいか判断するときは、古い画面例の位置だけで照合せず、現在のクライアントの説明とサブスクリプションの解析結果を確認してください。公鍵と秘密鍵は役割が異なり、一般の利用者が必要とするのは通常、サーバーから提供されたクライアント用パラメーターです。サーバーの秘密鍵を要求したり共有したりしないでください。インポート後に項目が空欄なら、リンクにその情報が含まれているかを調べ、次にパーサーが対応しているかを確認します。似た名前の項目から情報を寄せ集めて、設定を完成させないでください。
Vision：フロー制御は暗号化のオン・オフではない
XTLS Vision は、特定の接続構成に対応するフロー制御機構です。プロキシ経路で暗号化済みの通信を再度カプセル化する際の処理を主に扱い、条件を満たすデータ経路で重複処理を減らします。あらゆる通信で使える万能な最適化ではなく、REALITY を有効にするだけで自動的に動作するものでもありません。TLS と REALITY は接続を安全に確立する方法、Vision は特定のデータ処理段階での動作を示します。相互に関係はありますが、役割は異なります。利用できるかどうかは、プロトコル、トランスポート、コア、サーバー設定の組み合わせが対応範囲内かで決まります。
v2rayN または v2rayNG で該当するノードを確認する際は、まず提供元が指定したプロトコルを選び、次にセキュリティ設定、最後に flow を確認します。サーバー側で該当するフロー制御が有効でなければ、クライアントで Vision を選んでも通常は期待どおりに動作しません。トランスポート方式に明確な制限がある組み合わせもあり、TCP で直接データを運ぶ設定を WebSocket にそのまま適用することはできません。インポートはできても起動に失敗する場合は、DNS やシステムプロキシを先に変更するのではなく、コアのログにある設定エラーを確認してください。
| 名称 | 主な役割 | 代替できないもの |
|---|---|---|
| TLS | 通信の暗号化と証明書による認証 | プロキシプロトコルのユーザー認証 |
| REALITY | 独自のセキュアなハンドシェイクと接続先認証の仕組み | 完全なプロキシプロトコルと正しいサーバー設定 |
| Vision | 特定の組み合わせにおけるデータのフロー制御 | 接続セキュリティ機構と互換性の確認 |
セキュリティ設定を一つずつ照合しても接続できない場合は、アドレスへの到達性、ポート番号、端末の時刻、サーバー側で該当する接続口がまだ提供されているかを確認してください。画面上の接続成功を目的に、検証要件を緩めないようにしましょう。暗号化の重複やフロー制御について詳しく知りたい場合は、REALITY と XTLS Vision の仕組みの解説をご覧ください。この記事では判断の枠組みを説明していますが、個々の設定項目は提供元と現在のコアが対応する構成に従ってください。
接続速度とリソース消費を判断する順序
初回表示、継続転送、リアルタイム応答を分けて考える
「速さ」には少なくとも3つの異なる要素があります。ページを初めて開くまでの時間、継続ダウンロード時のスループット、操作に対する応答の速さです。初回表示は DNS、接続確立、セキュリティハンドシェイクの影響を受けます。継続転送では回線容量、輻輳、両端の処理能力がより重要です。操作時の快適さは往復時間やパケットロスに左右されます。ノードの速度テストで転送量が多くても、ウェブページが必ず早く表示されるとは限りません。プロトコルを比較する前に、改善したい待ち時間の種類を明確にしましょう。
接続の確立には通常、いくつかの段階があります。ドメイン名を解決し、下位の接続を確立し、セキュリティ層のハンドシェイクを行い、トランスポートによっては追加のネゴシエーションも必要です。カプセル化を追加すると、互換性や導入面で便利になることがある一方、処理段階とデータ量も増えます。ただし、レイヤーの数だけで速度を一律に順位付けすることはできません。接続の再利用、サーバーの場所、キャッシュの状態、ネットワークのパケットロスによって結果は変わります。往復時間の長い回線ではハンドシェイクが1回減る効果が目立つことがありますが、別の環境では大きな差にならない場合もあります。
カプセル化、再利用、輻輳は多ければよいとは限らない
WebSocket はデータを独自のフレーム形式に格納し、対応するサーバー接続方式に適しています。gRPC はそのプロトコルスタックに依存し、ストリーム管理の特性も異なります。いずれもまずはデータの運び方や導入方法の選択であり、万能な高速化機能ではありません。接続を再利用すると一部の再接続コストを減らせますが、複数のリクエストが同じ接続を共有することで、同じ箇所の輻輳や転送のブロックに影響されることもあります。サーバー側が特定の再利用方式に対応していない場合、クライアントだけで有効にしても効果はなく、かえってリクエストの異常につながる可能性があります。
リソース消費も、プロトコル名だけでは判断できません。暗号化アルゴリズムがハードウェア支援を受けられるか、コアのバッファーがどう割り当てられるか、同時に有効な接続数はいくつか、ログの詳細度が過剰でないかなどが、CPU とメモリーに影響します。ある種のデバイスで効率のよいアルゴリズムが、別のデバイスでも有利とは限りません。クライアントに表示されるメモリー使用量には、GUI、キャッシュ、バックグラウンドタスクが含まれる場合があり、プロトコル自体の負荷を示すものではありません。判断する際は、起動直後の一つの数値だけを切り取らず、コアの動作と実際の用途を合わせて確認してください。
プロトコルのランキングではなく、条件をそろえて比較する
意味のある比較をするには、サーバーの地域、アクセス先、端末、接続ネットワーク、時間帯をできる限りそろえます。2つのノードで経路が異なるなら、まず結果に表れているのは経路の違いであり、プロトコルの優劣ではありません。同じページを初めて開くとき、再アクセスするとき、継続転送や操作時の応答を順に試します。一度に変更する要素は一つにし、再接続が発生したかも記録してください。接続を事前に確立した状態の結果と、キャッシュ消去直後・クライアント起動直後の結果をそのまま比べないようにしましょう。
「接続テストは速いのに、ウェブページが読み込み中のまま」という場合は、テスト先とウェブページが同じルーティングを通るかを確認し、DNS、証明書、実際のリクエストログを調べてください。テストによっては、下位の接続や特定の確認リクエストしか測定せず、ページ内の複数のリソースドメインまでは対象になりません。ルーティングによってメインページと静的リソースの出口が分かれていると、体感にも差が出ます。まず失敗した段階を特定し、その後でプロトコルを変更する必要があるか判断してください。ノードを頻繁に切り替えると、検証する変数が増えるだけです。
リアルタイムアプリでは UDP も個別に確認してください。ノードのプロトコルが UDP リクエストを扱えても、クライアントの接続方式、サーバー側の転送、接続先のネットワークがすべて対応しているとは限りません。アプリがシステムプロキシに従わない場合は、ノードに対応機能があっても通信がプロキシ経路に入らない可能性があります。Tun を有効にした場合は、ルーティング、権限、DNS も正しく設定されているかを確認してください。動画を継続して視聴する場合は、ノード名より安定性と輻輳制御が重要なことがあります。ウェブ閲覧では DNS と接続確立を優先して確認しましょう。
すべての指標で最良の構成を目指す必要はありません。通常のウェブ閲覧では設定の正確さと接続の安定性を優先し、長時間の転送では継続時の性能と端末負荷を、リアルタイム通信では往復時間とパケットロスを重視し、アプリの通信が実際にプロキシ経路へ入っているかも確認します。プロトコルが決めるのは経路の一部にすぎません。ノード一覧にある地域や倍率などの情報については、ノード選びで確認したいポイントもご覧ください。サービス上のラベルを技術仕様と混同しないようにしましょう。
モバイル端末の電池消費とバックグラウンド動作
消費電力は接続処理全体で発生する
Android 端末の電池消費は暗号化処理だけで決まるわけではありません。無線接続の維持、アプリからの継続的なリクエスト、バックグラウンドでの再接続、DNS クエリ、ログの書き込みも影響します。電波が不安定だと、ネットワークの切り替えやハンドシェイクの繰り返しで負荷が増えることもあります。そのため「このプロトコルのほうが省電力」と言うには、端末、通信の種類、ネットワーク条件を明らかにする必要があります。こうした条件を無視した一律の順位に、信頼できる判断材料としての価値はありません。まずクライアントが想定どおりに動作しているか確認し、その後でプロトコル間の細かな違いを検討しましょう。
モバイルでは v2rayNG をおすすめします。V2Fly コアが必要で、設定が対応範囲内であれば、v2flyNG も選択肢になります。画面が似ているだけで、ノードが完全に共通利用できるとは限りません。インポート後はプロトコル、セキュリティ層、高度な設定項目が正しく引き継がれているかを確認し、実際に接続してください。インストール先はAndroid クライアントのダウンロードをご覧ください。インストールパッケージは端末のアーキテクチャに合わせて選びます。パッケージのサイズを電池消費の目安にしないでください。端末への適合性に関係するのは、対応命令セットと実際の動作です。
暗号化の負荷より先に、再接続の繰り返しを確認する
待機中に電池が大きく減る場合は、クライアントのログに切断と再接続が繰り返し記録されていないか確認してください。よくある原因には、サーバーに到達できない、名前解決に失敗する、認証情報が一致しない、システムがバックグラウンドの通信を制限している、などがあります。接続失敗が続くと、クライアントは何度も再試行し、そのたびに名前解決とハンドシェイクが発生することがあります。この場合、暗号化方式の変更は原因から外れている可能性があります。まず安定して接続できるノードを復旧させ、その後に待機中の変化を確認すると、消費の原因が異常な再試行だったか判断しやすくなります。
別のケースとして、バックグラウンドの接続がシステムによって終了され、画面ロック解除後に再接続されることがあります。長時間接続を維持する必要がある場合は、システムのアプリ別バッテリー管理で v2rayNG または v2flyNG のバックグラウンド制限を確認してください。設定項目の名称は端末によって異なるため、「アプリ情報」からバッテリーやバックグラウンド動作に関する項目を開きます。制限を緩めると動作を維持しやすくなりますが、待機中の消費電力が増える可能性もあり、両方の改善を保証するものではありません。利用中だけ接続したい場合は、理論上の安定性のためにバックグラウンドで常時動かす必要はありません。
プロキシに取り込む範囲によって処理する通信量が決まる
Android クライアントは通常、システムが提供する仮想ネットワークインターフェースを使って通信を受け取ります。システムに接続中の表示が出ても、それはローカルインターフェースが作成されたことを示すだけで、リモートノードが使えるとは限りません。アプリごとの振り分けで、どのアプリの通信をプロキシ経路に入れるか変更できますが、アプリを除外する前に、そのアプリにプロキシが本当に不要か、依存するサービスに影響しないかを確認してください。不要な処理を減らせば負荷を軽減できる場合がありますが、ルールを誤ると一部のリクエストが意図した出口を通らなくなることもあります。まず正しく動作する状態を基準にし、段階的に対象範囲を絞りましょう。
自動テストの頻度が高すぎる、キープアライブの間隔が短すぎる、接続情報を絶えず更新している、といった設定も確認してください。キープアライブは特定の状態を維持するために使いますが、間隔を短くするほど快適になるわけではありません。小さなパケットが繰り返し送られることで、無線通信が頻繁に起動する可能性もあります。クライアントに該当する設定がある場合は、まず用途に合った既定値を使用してください。調整するのは、アイドル時の接続が切れる問題を確認できた場合に限ります。調査では不要な一括テストを一時停止し、設定変更直後の瞬間的な電池残量だけでなく、普段と同じ使い方で一定時間観察しましょう。
温度や電池残量を比較する際は、画面の明るさ、システム更新、アプリのダウンロード、動画のデコードなどの影響も除外してください。ネットワークとアプリの使用条件をそろえ、画面使用中と待機中の状態を分けて記録するのがおすすめです。通信量があまり変わらないのに CPU 負荷が上がっている場合は、接続失敗の再試行や詳細ログが関係している可能性があります。通信量が増え続ける場合は、実際に通信しているアプリを確認してください。バッテリー画面の内訳はシステムによる推定であり、GUI、コア、仮想インターフェースの使用量を完全に区別できるとは限りません。項目ごとの割合を、そのままプロトコルのコストとみなさないでください。
省電力を考える際の順序は、設定の互換性を確保し、再接続の繰り返しを解消し、バックグラウンド動作の設定を確認し、必要な通信だけをプロキシに取り込んだうえで、最後にプロトコル実装の負荷を比較することです。安定している既存ノードを別のプロトコルに変えても、電池消費が改善するとは限らず、新たなハンドシェイク条件が加わる可能性もあります。Wi-Fi とモバイルネットワークで動作に明確な差がある場合は、それぞれ記録し、ネットワーク切り替え後に DNS と接続を再確認してください。モバイル端末で最も効果的なのは、設定項目を複雑にすることではなく、クライアントが正しい処理を安定して続けられる状態にすることです。
V2Fly と Xray：プロジェクトの関係と互換性の境界
クライアントの画面とコアは役割が異なる
Project V は、このオープンソースプロキシエコシステムを理解するための背景です。V2Fly は V2Ray のコミュニティ開発を引き継ぎ、Xray は共通する技術的な基盤を持ちながら独自の機能開発を進めてきました。共通する概念や似た設定形式はありますが、同一のプログラムとして設定をそのまま置き換えられるわけではありません。オープンソースに関しては、各プロジェクト自体のライセンスと、含まれるコンポーネントのライセンスを区別してください。クライアントの利用にも、該当するライセンス条件が適用されます。オープンソースは公開された議論やレビューの基盤を提供しますが、すべての設定の組み合わせに互換性があることを意味しません。
v2rayN、v2rayNG、v2flyNG は、ノードの表示、サブスクリプションの管理、実行用設定の生成を行うグラフィカルクライアントです。コアは接続を確立し、ルーティングを処理し、プロトコルを実行します。画面上で設定項目を保存できても、現在呼び出しているコアがその項目を実行できるとは限りません。反対に、コアが機能に対応していても、クライアントに設定画面がなければ、GUI から利用できるとは限りません。選ぶ際は、画面で設定を表現できるかと、コアが実行できるかの両方を確認してください。
JSON の形式が似ていても、意味まで同じとは限らない
2種類のコアでよく使われる設定概念には、インバウンド、アウトバウンド、ルーティング、DNS があります。基本構造が似ていても、対応するフィールド、既定値、組み合わせの制限が異なることがあります。特に REALITY や Vision などの機能は、「どちらも V2Ray エコシステムに属する」という理由だけで V2Fly でもそのまま使えると判断しないでください。認識できないフィールドがある場合、起動を明確に拒否する実装もあれば、解析時に一部を無視する実装もあります。エラーが出ないからといって目的の機能が有効とは限りません。実際に生成された設定と動作結果を確認しましょう。
コアを切り替える前に、現在使えているノードを別のコピーとして保存し、クライアントのコア設定とノード種別の対応を確認します。画面の構成によって、コア選択が設定画面や各ノードのオプションにある場合もあります。トレイメニューのモード名だけで判断しないでください。選択したら、対象の接続を再起動し、ログで実際に呼び出されたコアとエラー情報を確認します。ルーティング、DNS、セキュリティ設定を同時に変えると、失敗の原因がコアの違いなのか他の設定なのか判別しにくくなります。
| クライアント | 主な用途 | 移行前に確認すること |
|---|---|---|
| v2rayN | デスクトップのサブスクリプションと接続を管理 | 実際に使われるコア、生成設定、システムへの接続方法 |
| v2rayNG | Android 向け Xray クライアント | ノードの詳細設定、セキュリティ設定、アプリごとの振り分け |
| v2flyNG | Android 向け V2Fly クライアントの選択肢 | プロトコルとトランスポートが該当する実装の対応範囲内か |
移行後は起動だけでなく、実際の動作も確認する
以下は、プライベートアドレス範囲に一致した通信を direct というタグの出口に送る、一般的なルーティング設定の例です。フィールドの関係を理解するためのもので、接続設定全体ではありません。使用前に、完全な設定内で該当する出口が定義されていることと、コアが使用するフィールドに対応していることを確認してください。また、LAN 内のすべてのドメイン名が直通になるわけではありません。ドメイン名を名前解決に使うか、ルールがいつアドレスを取得するかは、DNS とルーティングの設定全体によって変わります。
{
"routing": {
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}移行後は最低でも3つの点を確認します。コアが起動するか、対象のリクエストが意図した出口を通るか、クライアント終了後にシステムのネットワーク状態が元に戻るかです。最初の2点で設定の意味を確認し、最後の点でローカル側の接続動作を確認します。Tun とシステムプロキシでは必要な権限や後片付けが異なるため、ノードに接続できたからといって終了後の確認を省略しないでください。システムが停止済みのローカルプロキシポートを参照している場合は、リモートプロトコルのせいにせず、まずシステムプロキシの状態を戻しましょう。
安定して動作している設定のコアを切り替えるのは、対応しているプロトコル構成が必要、または再現できる実装上の問題を解決したいなど、明確な目的がある場合に限ります。定期メンテナンスとして切り替えたり、新旧のラベルを品質の順位とみなしたりしないでください。デスクトップで初回起動時に権限や起動の問題が発生した場合は、v2rayN の初回インストールと初期設定をご覧ください。用途に合ったクライアントとコアを選び、必要最小限の設定を維持するほうが、互換性設定を増やし続けるより管理しやすくなります。
サブスクリプション形式：インポートできても設定が完全とは限らない
共有リンク、サブスクリプションURL、実行設定
共有リンクは通常1つのノードを表し、サブスクリプションURLは更新可能な複数の設定を取得するために使います。実行設定は、最終的にコアが読み込む構造化データです。それぞれ用途が異なります。サブスクリプションURLを単一ノードの編集画面に入力しても解析できないことがあります。特定のコア向けの完全な JSON を汎用サブスクリプションとして扱っても、別のクライアントでは読み込めない場合があります。サブスクリプション本文がエンコードされていることもあるため、ブラウザーで開いたときに文字化けして見えるだけでは、無効だと判断できません。対応する形式を解析できるクライアントで読み込み、具体的なエラーを確認してください。
共有データには VMess、VLESS、Trojan、Shadowsocks のプロトコル識別子が含まれることがありますが、同じ識別子でもパラメーターのエンコード方法が異なる場合があります。ノード名、特殊文字、リクエストヘッダー、セキュリティ設定のエスケープ処理は、いずれも解析結果に影響します。コピー時に1文字欠けたり、リンク末尾の句読点まで選択したりすると、結果が変わる可能性があります。インポート後は、ノード名が表示されるかだけでなく、編集画面でプロトコル、アドレス、ポート、高度なセキュリティ設定も確認してください。名前が表示されるのは、一部の情報が読み取れたというだけです。
形式の変換で機能が失われることがある
クライアントのパーサーは、サブスクリプションの内容を内部のノード形式に変換し、その後でコア用の実行設定を生成します。内部形式に対応するフィールドがない場合、新機能の設定を完全に保持できないことがあります。セキュリティ層が既定値に戻る、flow が消える、サービス名が空欄になる、パラメーターが単なるメモとして扱われる、といった形で現れます。同じサブスクリプションを2つのクライアントに読み込んだ結果が異なっても、サーバー側の設定が変わったとは限りません。まずインポート後の項目を比較し、次に生成された設定を確認してから、コアの本当の非互換性を判断してください。
変換サービスを何も変更しない中継処理とみなさないでください。変換サービスがサブスクリプションの内容を読み取る場合があり、変換ルールによって設定項目の解釈が変わることもあります。サブスクリプションURLには個人向けの認証情報が含まれることが多く、URLを知る第三者がノードを取得したり、割り当てられたリソースを消費したりする可能性があります。スクリーンショットを共有する、ログを送る、サポートを求める場合は、URL全体、ユーザー識別子、パスワードなどを必ず隠してください。URLが漏えいした場合は、ローカルの一覧からグループを削除するだけでなく、提供元の管理画面から認証情報を更新してください。
サブスクリプションの更新とノードへの接続は別の処理
v2rayN では、まずサブスクリプショングループの設定を開き、URL が保存されていることを確認してから、「更新（プロキシを経由しない）」を実行します。これにより、直接取得する経路と現在のプロキシ経路の問題を切り分けられます。ただし、すべてのサブスクリプションを常に直接取得すべきという意味ではありません。サブスクリプションの接続先が利用可能なプロキシを必要とする場合は、接続が正常な状態で適切な更新方法を選んでください。重要なのは取得経路だけを変更し、エラーを比較できるよう元のグループを残すことです。すべてのノードを同時に削除しないでください。
更新に失敗しても既存ノードに接続できる場合は、まずサブスクリプションの接続先、認証、取得経路を確認します。サブスクリプションは更新できるのに、すべてのノードに接続できない場合は、ノード設定、サーバーの状態、コアの対応状況を優先して確認してください。両方に失敗する場合でも、サブスクリプションの取得とノード接続のエラーを分けて記録しましょう。HTTP リクエストが成功しても、本文がサブスクリプションとは限りません。ログイン画面、エラーメッセージ、別のウェブページが返されることもあります。パーサーで形式エラーが出た場合は、ノードのパスワードを繰り返し変更するのではなく、取得した内容の種類を確認してください。
サブスクリプションの更新によって、手動で行った変更が上書きされる場合もあります。サーバー名やトランスポート設定を一時的に変える必要がある場合は、ノードを別のコピーとして保存し、変更の目的を記録してください。次回の更新でテスト結果が置き換わるのを防げます。グループ名は管理用のラベルであり、サーバー側のプロトコルは変わりません。同じURLに異なる名前のグループを複数作っても、別の回線が得られるわけではありません。重複ノードを整理する前に、表示名だけで判断せず、セキュリティ層とトランスポート設定が本当に一致しているか確認してください。
複数の端末で同期する場合は、クライアントのデータフォルダー全体を上書きするのではなく、各端末で対応するサブスクリプションを個別に読み込み、設定項目を確認してください。デスクトップのシステムプロキシ、Android のアプリごとの振り分け、ローカルのファイルパスは端末ごとに異なります。設定全体を移行すると、使えない設定まで持ち込む可能性があります。解析エラーが発生した場合は、サブスクリプションの更新失敗・解析エラーの対処法に沿って確認してください。サブスクリプション管理では、正確な取得元と更新関係を保つことが重要です。ノード一覧をできるだけ長くすることが目的ではありません。
用途に合わせた選択と接続確認
プロトコル名ではなく、用途から選ぶ
日常のウェブ閲覧では、設定がそろっていて、安定して更新でき、クライアントが明確に対応しているノードを選びましょう。VMess、Trojan、Shadowsocks の設定が問題なく動作しているなら、名称が違うというだけで移行する必要はありません。REALITY や Vision が必要な場合は、Xray の対応状況とサーバーから提供された設定一式を確認してください。デスクトップでは、サブスクリプション、システムプロキシ、ルーティングを一元管理できるため v2rayN をおすすめします。ただし、プロトコルはサーバー側の機能に合わせて選ぶもので、クライアントの選択と混同しないでください。
動画や大容量ファイルを継続して転送する場合は、プロトコルのカプセル化を比較する前に、回線の安定性、継続時の輻輳、端末の温度を確認してください。リアルタイム通信では、往復時間、パケットロス、UDP の経路全体を確認します。不安定なネットワークをモバイル端末で使う場合、単発のハンドシェイク負荷より再接続の挙動やバックグラウンド制御が重要になることがあります。候補ノードの回線条件が近い場合に限り、プロトコルやトランスポートの違いを比較する意味が高まります。設定が不完全な候補や機能が合わない候補を先に除外すれば、無駄なテストを減らせます。
デスクトップではレイヤーごとに確認する
v2rayN にインポートしたら、まずノード編集画面でプロトコル、トランスポート、セキュリティ層を確認し、保存して使用するノードに選びます。次にシステムプロキシのメニューで「システムプロキシを自動設定」を選び、システムプロキシに従うアプリから対象サイトにアクセスしながら、該当リクエストがログに現れるか確認してください。アプリの通信がローカルプロキシに入っていない場合は、まずシステム側の接続方法を調べます。リクエストが入った後に認証エラーになる場合は、リモート側の設定を確認してください。最初から Tun の有効化、DNS の変更、コアの切り替えを同時に行わないでください。
Tun が必要な場合は、現在のクライアントとシステムが対応しているかを確認し、表示される案内に従って権限を設定します。有効にした後はルーティングと名前解決を再確認し、システムプロキシ使用時と同じ動作になると決めつけないでください。LAN 内の端末へのアクセスは、個別に動作確認が必要です。プライベートアドレスのルール、ドメイン名の解決、実際の出口を適切に組み合わせてください。終了時にはシステムプロキシと仮想インターフェースの状態が元に戻ったか確認します。クライアントを終了した後にすべてのウェブページを開けなくなった場合は、リモートノードを次々に変更するのではなく、ローカルに残った設定を優先して確認してください。
モバイルでの確認とトラブルの切り分け
v2rayNG にインポートした後も、まず高度な設定項目を確認してから接続を開始し、システムが求める仮想ネットワークインターフェースの権限を許可します。その後、システムのステータスバーに接続中と表示されるかだけでなく、実際のアプリで通信を確認してください。特定のアプリだけ失敗する場合は、アプリごとの振り分けと必要な通信の種類を調べます。すべてのアプリで失敗する場合は、ノードと名前解決を確認してください。v2flyNG に切り替える前に、ノードがそのコアで未実装の機能に依存していないかを確認しましょう。依存している場合は、クライアントを変えても同じ互換性の問題が残ります。
コアを起動できない場合は、設定項目、機能の対応状況、設定構文を確認します。起動するがハンドシェイクに失敗する場合は、アドレス、ポート、時刻、認証を確認します。ハンドシェイクに成功して一部のドメインだけ失敗する場合は、DNS とルーティングを調べます。特定のアプリだけ失敗する場合は、プロキシに取り込む範囲とアプリ側の設定を確認してください。この順序は、すべての問題を一つの原因にまとめるためではなく、それぞれの観察結果を該当するレイヤーに結びつけるためのものです。ログに表示されたエラーは後続の結果である可能性もあります。最後の行だけを探すのではなく、関連する失敗が最初に現れた箇所から読みましょう。
| 用途 | 先に確認すること | 次に検討すること |
|---|---|---|
| 日常のウェブ閲覧 | サブスクリプションの正確さ、名前解決、初回表示の安定性 | セキュアなハンドシェイクとトランスポートの負荷 |
| 継続的なデータ転送 | 回線の輻輳、継続時の性能、端末の温度 | 暗号化の実装とデータ処理の負荷 |
| リアルタイム通信 | 通信を取り込む範囲、往復時間、パケットロス | UDP のエンドツーエンド対応 |
| モバイル端末の待機中 | 再接続の繰り返しとバックグラウンド制限 | キープアライブ、通信を取り込む範囲、プロトコルの負荷 |
確認が終わったら、クライアント名、実際に使用したコア、プロトコルの組み合わせ、システムへの接続方法、残っている問題を簡潔に記録してください。認証情報やログ全体を記録する必要はありません。次回サブスクリプションを更新したりコアを変更したりするときに、同じ手順で再確認できます。新しい設定で問題が起きたら、動作が確認済みの組み合わせに戻し、差分を一つずつ比較してください。修正項目を次々と追加するより確実です。再現できる現象と変更内容の明確な記録は、「すべてのプロトコルを試した」という説明より役立ちます。
最終的な選択基準は、設定の意味を説明でき、必要な機能を満たし、実際の動作を確認できることです。回線や端末の条件を問わず常に最良のプロトコルはなく、スイッチ一つで互換性を補えるわけでもありません。初期設定はクイックスタートガイドに沿って進め、サブスクリプションや接続の問題が起きたら、このページの該当する章を確認してください。クライアントを変更する場合は、ダウンロードページからOSとアーキテクチャに合ったものを選び、信頼できる基本設定を作ってから、必要な高度な機能を一つずつ調整しましょう。