プロトコルとコアのガイド

1. 設定のレイヤーと項目の対応

クライアント、コア、サーバーの役割を把握する

クライアントは設定を管理するGUIで、共有リンクの読み込み、サブスクリプションの管理、サーバーの選択、システムプロキシの変更などを行います。コアはクライアントが生成した設定を読み込み、待ち受け、名前解決、ルーティング、リモート接続を実行します。サーバー側では、クライアントに対応する接続設定が動作します。この3つはそれぞれ役割が異なります。画面上で設定を保存できても、それは入力が画面上のチェックを通ったことを示すだけです。コアがすべての項目に対応していることや、サーバー側にも同じ設定が反映されていることを意味しません。

接続設定は4つのレイヤーに分けて確認できます。プロキシプロトコルは認証とプロキシ要求の形式を定め、トランスポート方式はその内容をどう運ぶかを決めます。セキュリティ層は外部との接続を暗号化し、相手を認証します。ルーティングルールは、どの要求にこの接続を使うかを決めます。サブスクリプションURLは設定を配布する入口であり、接続の各レイヤーには含まれません。サブスクリプションURLをサーバーアドレス欄に入力したり、トランスポート名をプロキシプロトコルと取り違えたりすると、以後の確認で項目の対応が取れなくなります。まず編集対象がサブスクリプションなのか、個別のサーバー設定なのかを確認してください。

表示名だけで設定を判断しない

サーバーの別名は一覧で見分けるためのもので、サブスクリプションの提供元が自由に付けられます。別名にプロトコル名が含まれていても、実際のプロトコル項目がその種類だとは限りません。編集画面で種類、アドレス、ポート、認証情報、トランスポート方式、セキュリティ設定を確認してください。アドレスはドメイン名の場合もIPアドレスの場合もあります。ポートはリモートサーバーの待ち受けポートであり、ローカルプロキシのポートとは異なります。ブラウザーがローカルプロキシに接続するポートと、サーバー側のポートは別々の接続区間に属するため、一方を変えても他方の問題は解決しません。

トランスポートのパスとサーバー名も、互いに置き換えられる項目ではありません。Webベースのトランスポートでは、パスは通常、サーバー側でリクエストを振り分けるために使います。サーバー名はセキュリティハンドシェイクや証明書の検証に関わります。設定によってはリクエストヘッダーのHost名も含まれます。これらが同じ値になるか異なる値になるかは、サーバーの構成次第です。クライアントの画面で項目が近くに並んでいるのは編集しやすくするためで、意味が同じということではありません。トラブル対処では、元の設定を項目ごとに確認し、ドメイン名の欄をすべてサーバーアドレスに書き換えるのは避けてください。

変更を最小限にして再現できる条件を整える

サブスクリプションの設定には通常、必要な項目が一式そろっています。好みでその一部だけを変更するのは避けましょう。たとえば既存設定のセキュリティ層を別の種類に変更しても、サーバー側にその機能が自動で追加されるわけではありません。トランスポート方式を変える場合も、サーバー側の対応が必要です。2つの方式を比較するなら、サーバー側が明示的に提供する設定一式を用意し、ローカルのルーティング、テスト対象、接続ネットワークをそろえてください。個別設定の種類だけを変更しても、有意義な比較にはならず、接続できなくなることがあります。

最初にトラブル対処を始める前に、クライアント名、使用中のコア、プロトコルの種類、トランスポート方式、セキュリティ層を記録しておきましょう。あわせて、問題が読み込み、起動、ハンドシェイク、アクセスのどの段階で起きたかも記録します。「使えない」という状態を具体的な段階に切り分けやすくなります。ログに未対応の設定項目が表示される場合は、まずコアと設定形式を確認してください。コアが起動していてリモートとのハンドシェイクに失敗する場合は、アドレス、認証情報、セキュリティ設定を確認します。レイヤーをまたいで何度も変更すると、正常だった設定も元に戻しにくくなります。

2. 4種類のプロキシプロトコルを比較

VMessとVLESS：役割の違い

VMessはProject Vのエコシステムで早くから使われているプロキシプロトコルです。ユーザー認証とメッセージ保護の仕組みを備え、一般的な設定ではユーザーIDを認証情報として使います。過去には複数の認証方式がありましたが、比較的新しい設定では通常AEAD方式を使います。古い解説にある追加のIDパラメーターを、新しい設定にそのまま推奨値として使わないでください。クライアントを使う際は、サーバー提供元の設定項目に従って読み込み、端末の時刻を正確に保つことが大切です。認証エラーの一部は時刻のずれが原因の場合があり、すぐに回線の問題と決めつけないようにしましょう。

VLESSは役割を分ける考え方から、プロトコル自体をシンプルにし、一般的な構成ではトランスポートの保護を外部のセキュリティ層に委ねます。暗号化方式がnoneの設定でも、接続全体が必ず平文になるわけではありません。また、セキュリティ設定を省略してよいという意味でもありません。実際の保護は、外側でTLS、REALITY、または明示的に設計された別のセキュアな通信路が正しく有効になっているかによります。通常はユーザーIDで認証しますが、VMessの認証情報、暗号化、トランスポートの各項目と自由に入れ替えることはできません。VLESSを選ぶ場合は、セキュリティ層と必要なフロー制御も設定全体の一部として確認してください。

VLESSの構成には、XTLS Visionなど特定のフロー制御方式を使うものがあります。フロー制御の項目は、どのトランスポートでも使える万能の高速化設定ではありません。コア、トランスポート、サーバー側のすべてが要件を満たす必要があります。既存のサブスクリプションにフロー制御が設定されていない場合、名前だけを見て独自に追加しないでください。設定済みの場合も、別のコアに合わせるために安易に削除してはいけません。どちらも接続動作を変える可能性があります。新しいプロトコル名かどうかより、接続設定一式に双方が対応しているかを優先してください。

Trojan：適切なTLS設定が前提

Trojanの一般的な構成では、プロキシ認証とリクエストをTLSの通信路に載せ、主な認証情報としてパスワードを使います。このパスワードはプロキシの認証用であり、証明書検証は外部とのセキュアな接続先を確認するためのものです。互いに代用はできません。パスワードが正しくても証明書の名前が一致しなければ接続に失敗することがあります。証明書の検証に成功しても、パスワードが誤っていればプロキシ要求は完了しません。編集時はサーバーアドレス、サーバー名、ポート、パスワードをそれぞれ確認してください。「安全でない接続を許可」は、あらゆるハンドシェイクエラーに対する通常の対処方法ではありません。

Trojanは設定項目が比較的分かりやすい一方、導入のしやすさは証明書、ドメイン名、サーバーの管理方法に左右されます。拡張トランスポートや追加オプションへの対応範囲も、コアによって異なる場合があります。プロトコル名が付いた共有リンクを見ただけでは、どのトランスポートが使われているか判断できません。読み込み後にパスが空になったり、セキュリティ設定が消えたり、拡張項目が認識されなかったりした場合は、元の設定を確認してください。すべてのクライアントが同じ設定を自動で補うとは限りません。

Shadowsocks：シンプルな構成と暗号化方式の互換性

Shadowsocksは比較的シンプルなプロキシ構成で、一般的な設定ではサーバーアドレス、ポート、パスワード、暗号化方式が中心になります。暗号化方式ごとにデータ処理と鍵の要件が異なるため、パスワードだけ残して方式を自由に変更することはできません。旧式の方式、一般的なAEAD方式、後発の新しいプロトコル系列は、互換性が保証されているわけではありません。方式によっては特定の長さや形式の鍵が必要です。クライアントが通常のテキスト入力を受け付けても、サーバー側で同じ有効な鍵として解釈されるとは限りません。

設定レイヤーを少なくしたい場合によく使われますが、適しているかどうかはクライアントの実装、サーバー側の暗号化方式、追加のトランスポートコンポーネントの有無によります。共有リンクが追加コンポーネントを参照していても、使用中のクライアントが対応していなければ、基本項目だけを読み込んでも不十分です。リソース負荷を比較する際は、追加コンポーネントを含めた接続全体のコストを考慮してください。構成がシンプルなら一部の処理を減らせることはありますが、リモート側の帯域、回線の混雑、アプリのリクエスト特性までは変わりません。

3. TLSとREALITYの設定項目

証明書検証、サーバー名、端末時刻

TLSは上位レイヤーの接続を保護し、証明書検証などによって接続先の身元を確認します。接続先のサーバーアドレスはネットワーク接続に使われ、サーバー名は通常、ハンドシェイクで送信する名前や証明書との照合に使われます。両者は必ずしも同じ値ではありませんが、サーバー側の設定と一致している必要があります。IPアドレスで接続し、証明書がドメイン名に対して発行されている場合、サーバー名までIPアドレスに変更すると名前の検証に失敗することがあります。検証を無効にしてエラーを回避するのではなく、サーバー側が指定する名前を確認してください。

証明書の検証は、端末の時刻と証明書チェーンにも依存します。端末の日付が大きくずれていると、証明書が有効期間前または期限切れと判定されることがあります。サーバーが適切な証明書チェーンを提供していない場合、一部の環境では信頼を確立できません。同じ端末で複数のサーバーに接続して証明書エラーが起きる場合は、まず端末の時刻とネットワーク環境を確認します。特定の設定だけが失敗する場合は、そのサーバーの証明書と名前を優先して確認してください。原因に応じて対処は異なり、パスワードを何度も変更しても解決しないことがほとんどです。

REALITY特有の照合項目

クライアント側のREALITY設定では、通常、サーバー名、サーバー公開鍵、short IDなどを指定します。認証方式は一般的な公開証明書の構成とは異なります。サーバー公開鍵は該当するサーバー設定から取得する必要があり、クライアント側で任意に生成した値では代用できません。short IDの値と形式も、サーバー側で許可された範囲に合わせます。セキュリティ層の設定を切り替えるだけで有効になるものではありません。クライアントとコアが対応しており、サーバー側も同じ方式で構成されている必要があります。

ここで使う公開鍵とユーザーIDは役割が異なります。ユーザーIDはプロキシレイヤーの認証に使い、公開鍵は該当するセキュリティ認証に使います。short IDにも別の照合要件があります。文字の見た目が似ていても、ある項目の値を別の入力欄にコピーして同じ設定になるわけではありません。クライアントによっては、ハンドシェイクの動作に関わるフィンガープリントを指定できます。フィンガープリントは任意に付けるブランド名ではありません。使用中のコアが明示的に対応する値を選び、提供元の指定に従って他の設定と組み合わせてください。

解説によってはREALITY、VLESS、Visionがひとまとめに書かれているため、常に3つすべてが必要だと思われがちです。実際には、プロキシレイヤー、セキュリティ層、フロー制御を分けて理解し、実装に応じて有効な組み合わせを確認してください。ある組み合わせでの成功を根拠に、すべてのトランスポートが同じフロー制御に対応すると判断することはできません。特定のコア専用の設定項目を別のコアに移しても、同じ動作が得られるとは限りません。画面に似た名前の項目があるかではなく、使用中のコアが実際に対応しているかを判断基準にしてください。

トランスポートのパスとネゴシエーション設定

WebSocketではパスやリクエストヘッダー、gRPCではサービス名やモードの設定がよく使われます。これらはサーバー側や中継プロキシの設定と一致させる必要があります。セキュリティハンドシェイクが成功しても、パスやサービス名が誤っていればトランスポート層で失敗することがあります。証明書だけを確認しても解決できません。ALPNはアプリケーション層のプロトコルネゴシエーションの優先候補を示すため、値もサーバー側の要件に合わせます。候補を増やせば互換性が高まるとは限らず、サーバーが処理できない経路に接続されることもあります。

セキュリティ層の設定を保存する前に、元の共有設定と項目ごとに照合してください。特にコピー時の空白、エンコード、大文字と小文字の違いに注意します。見慣れない項目がある場合は、まずクライアントが対応しているか、次にコアが対応しているかを確認してください。空欄をすべて埋めれば完全な設定になるわけではなく、多くの項目は既定値のままにするか、設定しないのが適切です。原因を切り分けるために一時的な変更が必要な場合は、元の設定を複製しておき、テスト後に戻してください。セキュリティ検証の恒常的な設定を、一度たまたま接続できたという理由だけで決めるべきではありません。

4. 速度、リソース、接続コスト

初回接続と継続的な通信を分けて考える

「速い」という言葉が指すのは、Webページの初回表示、継続的なダウンロード速度、動画の再生開始までの時間、あるいは操作に対する応答などさまざまです。初回接続には、名前解決、ネットワーク接続、必要に応じてセキュリティハンドシェイクやプロキシ要求が含まれます。継続的な通信は、帯域、輻輳制御、回線のパケットロス、サーバー負荷の影響をより強く受けます。ハンドシェイクの手順が少ない構成でも、大容量ファイルのダウンロードが必ず速くなるわけではありません。逆に、継続通信の性能がよい回線でも、名前解決に時間がかかるとページの初回表示が遅く感じられることがあります。

プロキシプロトコルの暗号化やカプセル化には処理コストがかかりますが、最新の端末ではボトルネックがそこにないことも少なくありません。処理能力に余裕がない端末、長時間の高スループット通信、多数の同時接続などでは、プロトコルの実装やハードウェアアクセラレーションの違いが表れやすくなります。一般的なWeb閲覧では、リモート回線やアクセス先の応答が主な所要時間を占めることがあります。一度のダウンロード結果だけでサーバー負荷の変化をプロトコルの違いと決めつけたり、すべての端末に一律の速度・使用率ランキングを当てはめたりしないでください。

多重化とトランスポートの範囲

多重化は、少数の下位接続に複数の論理リクエストを載せることで、接続を繰り返し確立するコストを抑える場合があります。一方で、複数リクエストが同じ回線を共有する仕組みも変わります。下位接続でパケットロスやブロックが起きると、複数のリクエストに同時に影響することがあります。トランスポートやフロー制御の組み合わせによっては一般的な多重化設定に対応しておらず、無理に有効化しても効果がない、またはエラーになる場合があります。まずクライアントとサーバーが標準で対応する設定を使い、接続の頻繁な確立が問題だと確認できてから、対応する多重化方式を検討してください。

Web向けのトランスポートなどでカプセル化レイヤーを追加すると、特定の構成で接続やリクエストの振り分けに役立つ場合があります。その一方で、ヘッダー、バッファリング、中継プロキシの制約が増えることもあります。ネイティブな接続経路が短くても、あらゆるネットワークで安定するとは限りません。中継プロキシを通る接続が複雑でも、必ず遅くなるわけではありません。比較する際は、2つの設定が同じ地域、同じサーバーリソースに接続しているか確認してください。回線の違いとプロトコルの違いが混ざると、結果はその2つの接続全体についてのものになり、プロトコル一般の評価には使えません。

遅延テストの見方

基本的なネットワーク到達性の確認で分かるのは、特定のレイヤーに接続できるかどうかです。プロキシ認証やアクセス先への接続をすべて検証するものではありません。実際の接続遅延テストでは、通常、プロキシ経由で指定したアクセス先へ接続しますが、結果はテスト先、ルーティング、名前解決、タイムアウト設定にも左右されます。テストに成功しても、すべてのアプリがプロキシを使っているとは限りません。失敗した場合も、どの段階でエラーが起きたかを確認してください。初回接続の確認手順はv2rayNの初回接続とプロキシ動作の確認をご覧ください。

比較する際は、同じネットワーク、近い時間帯、同じテスト先を使い、まず各設定を個別にテストしてから、回数を絞って繰り返します。大容量の通信を複数同時に開始したり、サブスクリプションを自動更新しながら接続を比較したりしないでください。リクエストが完了するか、初回応答が安定しているか、継続通信が途切れないかを記録するほうが、最もよく見えた数値だけを残すより参考になります。試行ごとに結果が逆転する場合は、無理に優劣を決めず、「現在の条件では安定した差がない」と結論づけてください。

リソースを確認する際は、クライアントの画面とコアのプロセスを分けて考えてください。大量のログを長時間表示したり、一覧を頻繁に更新したり、バックグラウンドでテストを繰り返したりすると、画面側の負荷が増える場合があります。継続接続やルール処理の多くはコア側で行われます。システムのタスク管理ツールでは両方を観察し、ウィンドウの使用量をプロトコルの負荷と取り違えないようにしましょう。メモリの増加は接続キャッシュ、名前解決キャッシュ、ルールセットが原因の場合もあります。一時的なピークだけを理由にプロトコルを変更せず、まずテストやバックグラウンド処理を止めて安定時の状態を確認してください。

5. V2FlyとXrayのコア

共通のルーツがあっても機能は同じではない

Project Vは、設定に基づいてプロキシ接続、ルーティング、複数のトランスポートを扱う技術エコシステムを形成してきました。V2FlyはV2Ray関連プロジェクトの開発を引き継ぎ、Xrayはその技術基盤から分岐して発展し、独自の方針でプロトコルやトランスポートの機能を拡張しています。概念や過去の設定形式の一部を共有するため、項目名が似ていることがあります。しかし、それぞれの開発が進むにつれ、対応範囲、既定の動作、拡張項目は完全には一致しなくなっています。コア選びは必要な機能との適合性で判断し、単純に新旧の関係として捉えないようにしてください。

REALITYやXTLS Visionなどを組み合わせる場合は、Xrayの対応状況と必要な設定を重点的に確認してください。V2Flyも同じ意味で動作すると決めつけてはいけません。両方が対応するプロトコルでも、具体的なトランスポート、暗号化方式、追加オプションを確認する必要があります。サポート一覧にプロトコル名があるからといって、そのプロトコルに関する過去の拡張や新しい拡張がすべて使えるとは限りません。設定項目が認識されない、または起動できない場合は、プロトコルの大分類だけで互換性を判断せず、該当する機能まで絞り込んでください。

3つのクライアントの選び方

v2rayNはデスクトップ向けの設定管理クライアントです。サーバー一覧、サブスクリプション、ログ、ルーティングの状態を確認したい場合に適しています。管理できるコア機能は、実際に使用するコアとクライアントの対応状況によって決まり、画面上の名前だけでは判断できません。v2rayNGはAndroid向けで、Xray関連の設定によく使われます。v2flyNGはV2Fly系のAndroid向け選択肢です。2つのモバイルクライアントは画面が似ている場合がありますが、設定を移行する前に対応範囲を項目ごとに確認してください。名前を置き換えるだけで同じアプリとして扱うことはできません。

クライアントの更新、コアの更新、サブスクリプションの更新は、それぞれ別の操作です。クライアントの更新は画面や設定生成の処理に影響し、コアの更新は実行時の機能に影響します。サブスクリプションの更新は、リモートから提供されたサーバー設定を置き換えたり追加したりします。更新に成功しても、コアが未対応の機能が追加されるわけではありません。コアを更新しても、誤ったサブスクリプションURLは修正されません。操作前にどのレイヤーを変更するのかを明確にし、更新後はログで実際に動作しているコアを確認してから、既存の接続が想定どおり動くか検証してください。

設定の互換性は形式だけでなく意味で確認する

どちらのファイルもJSONとして読み込めることから分かるのは、構文が正しいということだけです。項目の階層、指定可能な値、既定値、動作によって互換性が決まります。読み込み時に拒否される項目もあれば、無視される項目もあります。後者は問題に気づきにくいため注意が必要です。別のコアへ移行する場合は、設定ファイル全体をそのまま差し替えるのではなく、移行先のクライアントで対応する共有リンクから設定を生成する方法を優先してください。独自のルーティング、名前解決、特殊なトランスポートを使っている場合は、該当箇所を個別に確認します。

移行テストでは、元に戻せる設定を保管し、まず動作確認済みのサーバーを1つ検証してください。コアの変更、新しいサブスクリプションの読み込み、ルーティングの変更を同時に行うと、失敗時に原因を特定しにくくなります。まず起動ログに未認識の項目がないことを確認し、次にセキュリティハンドシェイクとアクセス先への接続を検証してから、複雑なルールを移行してください。元のコアでしか明確にサポートされていない機能を使う場合は、元の構成を維持するか、サーバー提供元から別の設定一式を入手してください。起動させるためにエラー項目を削除するのは適切ではありません。

オープンソースであれば実装を調査し、継続的に保守できますが、利用環境での動作確認に代わるものではありません。プロジェクトによってオープンソースライセンスは異なり、ライセンスはコードの利用や再配布を定めるもので、接続速度やサーバーとの互換性を直接決めるものではありません。当サイトはダウンロードと解説への案内を提供するもので、各プロジェクト独自の技術仕様に代わるものではありません。インストーラーの対応プラットフォームやCPUアーキテクチャだけを確認したい場合は、インストーラーのページに戻ってください。プロトコル機能は、この章で解説するコアと設定項目の対応関係をもとに判断してください。

6. サブスクリプション形式と読み込みの互換性

サブスクリプションの取得と設定の解析は別の段階

サブスクリプションURLは通常、設定内容を返すアドレスを指します。内容は共有リンクの一覧、エンコードされたテキスト、または構造化された設定データの場合があります。クライアントはまず応答を取得し、形式を判別してから、項目を独自のサーバー設定に変換します。そのため「サブスクリプションの更新に失敗した」という状況には、ネットワーク要求の失敗、応答形式の不一致、個別設定の解析エラーなどが含まれます。ブラウザーでURLを開けても、何らかの応答を取得できたというだけで、その内容が使用中のクライアントに適していることや、各設定がすべて利用可能であることは保証されません。

認証が失効すると説明ページを返すURLもあれば、別ページに転送されたり、空の内容を返したりする場合もあります。クライアントがそのページをサブスクリプションのテキストとして解析すると、形式エラーになったり、何も読み込まれなかったりすることがあります。サブスクリプション設定に登録したURL全体、アクセス権限、提供元の形式説明を確認してください。同じURLを複数のグループに繰り返し登録するのは避けましょう。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、パスワードと同様に管理してください。エラーについて相談する際は、クエリパラメーターと個人識別情報を隠し、エラーの種類だけを共有します。

共有リンクの読み込み時に設定項目が変換される

プロトコルごとに共有リンクの内部構造は異なります。設定オブジェクトをエンコードしてURLに含めるものもあれば、ユーザー情報、ホスト、ポート、クエリパラメーターで項目を表すものもあります。パーセントエンコーディングは予約文字を表すために使われます。エンコードの階層を誤ったり、コピー時に区切り文字が欠落したりすると、解析結果が変わることがあります。文字化けのように見える部分を自己判断でデコードして保存したり、プラス記号やスラッシュをまとめて置き換えたりしないでください。まずクライアントの標準の読み込み機能を使い、失敗した設定でどの項目が不足しているかを確認します。

読み込み後も、変換が完全に行われたか確認してください。特にセキュリティ層、公開鍵、short ID、フロー制御、パス、サービス名は、実装によって扱いが異なることがあります。別名やグループが一覧に表示されていても、重要な設定が失われていないとは限りません。基本的なプロトコルを認識していても、リンクの拡張項目に対応していないクライアントがあります。その場合、サーバー一覧が正常に見えても、実際に生成される設定がサーバーの要件を満たしていないことがあります。編集画面の項目を提供元の説明と照合し、起動ログでコアが設定を受け付けたか確認してください。

設定全体と個別サーバー設定を区別する

ルール、名前解決、インバウンド、複数のアウトバウンドを含む設定ファイル全体は、1つのサーバー共有リンクとは異なります。設定全体を個別サーバーの読み込み欄に貼り付けると、読み込めなかったり、一部だけ抽出されたりすることがあります。逆に、個別リンクにはローカルのルーティング設定全体が含まれないのが一般的です。サブスクリプションを変更してもローカルアプリの通信経路が変わらないのは、ルーティングがサーバー設定とは別だからかもしれません。共有リンクだけでローカルの待ち受け、システムプロキシ、アプリ別の選択が自動で修正されると期待しないでください。

サブスクリプショングループを使うと、設定の提供元を管理しやすくなります。更新時に、リモート側で項目の変更や設定の削除、表示名の変更が行われることがあります。手動で編集した内容が維持されるかどうかは、クライアントの動作によって異なります。長期間使うテスト用設定は、独立した設定として複製し、用途が分かる名前を付けてから試すとよいでしょう。複製した設定は元のサブスクリプションの変更に自動追従しないため、その後の確認は自分で行う必要があります。すべての項目を手動管理したい一方で、サブスクリプション更新が手動設定も常に修正してくれると想定するのは避けてください。

同じサブスクリプションでもクライアントによって結果が異なる場合は、すぐに一方のコアが不安定だと判断せず、読み込まれた設定の数と主要項目を比較してください。一方は形式全体に対応し、もう一方は一部のリンクしか読み込めない場合があります。また、一方は既存のプロキシ経由でサブスクリプションを取得し、もう一方は直接アクセスを試みている可能性もあります。「どの内容を取得したか」と「設定をどう実行するか」を分けて確認してから、接続方法を調べてください。必要に応じて、提供元が対象クライアント向けに明示している形式を使い、信頼できないオンライン変換サービスで認証情報を漏らさないようにしましょう。

7. ルーティング、ローカル接続、電池消費

システムプロキシとルーティングは別の役割

システムプロキシは、設定に従うアプリに対し、リクエストを送るローカルのアドレスとポートを知らせます。コアのルーティングは、リクエストが取り込まれた後に、直接接続するか、プロキシを使うか、拒否するかを決めます。「システムプロキシを自動設定」を選んでも、すべてのプログラムが必ず接続するわけではありません。ルーティングルールを設定しても、まだ接続されていないプログラムが自動的にプロキシを使い始めるわけではありません。Webページの表示が変わらない場合は、まずブラウザーがシステムプロキシを参照しているか、ローカルポートが正しいかを確認し、次にリクエストがコアに届いてどのルールに一致したかを調べてください。

ローカルの待ち受けは、必要なインターフェースに限定するのが基本です。端末内のアプリだけで使う場合、トラブル対処のためにすべてのネットワークインターフェースで待ち受ける必要はありません。LAN内で共有する場合は、アクセス制御と端末のファイアウォールも確認してください。待ち受けアドレスを変更した後も、システムプロキシが古いアドレスを参照していることがあります。ポートが別のプロセスに使われていると、コアが起動に失敗したり、インバウンドを作成できなかったりします。この場合、リモート側のプロトコル処理は始まりません。詳しくはローカルポートの使用中エラーを解決する方法をご覧ください。

ルールの順序と名前解決

ルーティングは通常、ルールを上から順に照合し、一致したリクエストを指定のアウトバウンドに送ります。ドメインルールはリクエストにドメイン名が保持されているかどうかに左右され、アドレスルールは名前解決の結果やドメイン処理の設定に左右される場合があります。適用範囲の広いルールを先に置くと、その後の細かいルールが適用されないことがあります。次のコードはXray形式の設定の一部で、ローカルのドメイン2つを直接接続する例です。単独で起動できる設定ファイルではありません。組み込む前に、directという名前のアウトバウンドが定義済みであることと、使用中のコアの構文に合っていることを確認してください。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:localhost",
          "domain:local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールの一致と名前解決の位置は、同じ設定項目ではありません。アプリが自分で名前解決してからアドレスをプロキシに渡す場合もあれば、ドメイン名のままローカルプロキシに渡す場合もあります。コアの名前解決方法、システムのDNS設定、ブラウザー独自の設定が別々に作用することもあります。一部のドメインだけ接続できない場合は、実際のリクエストでドメイン名とIPアドレスのどちらが使われているか、名前解決の結果に到達できるかを確認してください。名前解決先を1か所変更しただけで、通信経路全体が統一されたと判断しないでください。ルールの順序を把握しないまま例外を大量に追加するのも避けましょう。

Androidの接続とアプリ別プロキシ

Androidクライアントは通常、OSが提供する仮想ネットワークインターフェースを通じてアプリの通信を取り込みます。これは、デスクトップアプリがシステムプロキシを参照する方法とは異なります。接続を有効にする際はOSの許可が必要で、同じ仕組みを使う他のアプリと競合することもあります。アプリ別プロキシでは、どのアプリがこの接続経路に入るかを選択します。取り込まれた後の通信は、コアのルーティングで直接接続に振り分けられる場合もあります。そのため、アプリを選択してもすべてのリクエストがリモートサーバーを経由するとは限りません。逆に、選択していないアプリをコアのルールで後から取り込むこともできません。

電池消費はプロトコルの影響を受けることがありますが、プロトコル名だけでは判断できません。アップロードやダウンロードの継続、電波の弱い場所での再送信、頻繁な再接続、過度なバックグラウンド確認、アプリによる定期的な起動は、無線通信やプロセッサを動作状態に保つ原因になります。2つの設定で処理するアプリ通信が異なる場合、電池使用量を単純に比較することはできません。同じアプリのタスクと画面状態を保ち、余計なテストを減らしてから、OSの電池使用量と接続ログを確認してください。接続が繰り返し切れる場合は、セキュリティ設定を一律に弱める前に、再接続の原因を調べましょう。

クライアントを電池の最適化対象外にすると、バックグラウンドでの接続維持が改善する場合がありますが、バックグラウンド動作が増えることもあります。バックグラウンドを制限すれば電池を節約できる可能性がある一方、待機後の接続復帰に影響する場合があります。メッセージを常時受信する必要があるかどうかに応じて選んでください。アプリ別プロキシで接続対象を減らしても、電池消費が一定割合で減るとは限りません。詳しい設定方法はv2rayNGのバックグラウンド動作と省電力設定をご覧ください。テストが終わったら不要なバックグラウンド確認を停止し、診断時の負荷を通常利用時のものと混同しないようにしましょう。

8. 用途に応じた選択と段階的なトラブル対処

条件を整理してから構成を比較する

利用可能なサブスクリプションがある場合、まずサーバー側で実際に提供されている設定を確認し、次にクライアントとコアがすべての項目に対応しているかを確認します。デスクトップではまずv2rayNで管理と動作確認を行い、Androidでは必要な機能に応じてv2rayNGまたはv2flyNGを選べます。サブスクリプションに、対応済みで安定した構成が1つだけ提供されているなら、プロトコル名にこだわって設定を分解・変更する必要はありません。複数の構成が提供されている場合は、初回応答、継続通信、バックグラウンドでの安定性、管理のしやすさを比較してください。あらかじめ万能の最適解を決めつけないことが大切です。

保守の手間を抑えたい場合は、選択肢を増やすより、設定項目が明確で提供元が信頼でき、安定して更新できることが重要です。新しいセキュリティ層や特殊なフロー制御が必要なら、明確に対応するコアを選び、サーバー側から設定一式を提供してもらってください。処理能力が限られた端末では、継続的なタスク中の使用率を実際に確認し、重複するカプセル化、不要な確認処理、過剰なバックグラウンド通信を避けます。モバイル端末ではネットワーク切り替えや待機後の復帰もテストしてください。画面を点灯させたまま一度接続できただけで評価を終えないようにしましょう。

読み込みからアクセスまで段階ごとに切り分ける

最初の段階では、入力と解析を確認します。サブスクリプションから設定が生成されない場合は、要求が成功したか、応答形式が正しいか、リンクが完全かを調べてください。設定が表示されてもコアが起動しない場合は、未認識の項目、無効なパラメーター、ローカルの待ち受けエラーを確認します。この段階では、接続がまだ始まっていない可能性があるため、まずリモートサーバーを変更するのは避けてください。ログの場所が分からない場合は、v2rayNのメイン画面と各機能を参考に、サーバー編集、画面下部の状態表示、ログの場所を確認します。

2段階目では、リモート接続とセキュリティ認証を確認します。コアが正常に起動した後、アドレスを名前解決できない、接続がタイムアウトする、接続を拒否される、セキュリティハンドシェイクに失敗する、プロキシ認証に失敗する、といった状態を区別してください。タイムアウトだけでパスワードの誤りとは限りません。認証エラーもローカルポートを変更して解決するものではありません。ログの段階に応じて、名前解決、リモートポート、端末時刻、サーバー名、認証項目、セキュリティ設定を確認します。サーバーの状態をこちらで管理できない場合は、有効な項目を手当たり次第に変更するのではなく、提供元に該当設定を確認してください。

3段階目では、リクエストが実際に取り込まれているか、どのルールで処理されているかを確認します。コアのテストは成功するのにブラウザーからアクセスできない場合は、ブラウザーが参照するプロキシ、ローカルの待ち受け、ルールの一致を調べます。一部のアプリだけで失敗する場合は、アプリの接続方法と名前解決の動作を比較してください。一部のアクセス先だけ失敗する場合は、アクセス先の状態、ルール、名前解決の結果を確認します。Androidではアプリ別の対象範囲とOSの許可も確認してください。「サーバーが使えること」と「アプリが正しく接続すること」を分けて検証すれば、すでに利用できるサーバーを何度も切り替えずに済みます。

結論の適用範囲を明確にする

接続はできるものの動作が不安定な場合は、次に速度と電池消費を調べます。まずバックグラウンドの速度テストと並列ダウンロードを止め、同じネットワークで設定ごとの安定性を比較してから、別の接続ネットワークでも確認してください。すべての設定が特定のネットワークでのみ失敗する場合は、そのネットワークの名前解決、接続方法、回線状況を優先して調べます。1つの設定だけ失敗する場合は、そのサーバーの状態と設定の組み合わせを確認してください。一度に変更する要素は1つにし、変更前の結果も残して、偶然の復旧を設定の効果と取り違えないようにしましょう。

適切な設定を選ぶには、次の4点を確認できる必要があります。サーバーが提供する設定一式は何か、使用中のコアが対応しているか、アプリが想定どおり接続しているか、実際のタスクで安定しているか。プロトコルに恒久的な速い・遅い、優れている・劣っているという評価を付ける必要はありません。設定の提供元、重要な項目、テスト条件、エラーが起きた段階を記録しておけば、更新や移行時に比較できます。操作手順を最初から確認したい場合はクイックスタートガイドに戻ってください。個別のエラーはよくある質問とトラブル対処をご覧ください。クライアントを再インストールして設定をすべて作り直すより、原因を絞り込みやすくなります。