プロキシプロトコルの比較

プロキシプロトコルは、完全なデプロイメントの組み合わせにおいて比較すべきである。ローカル側でどのようにトラフィックをインターセプトし、リモート側でどのようにターゲットと認証を表現するか、TCP/UDPがどのようにトランスポートするか、そしてセキュリティレイヤーが誰を検証するかである。特定のプロトコル名を「速度が高い」「絶対に識別できない」といった固定された等級に単純に変換してはならない。

HTTP CONNECT、SOCKS5は汎用プロキシインターフェースである。Shadowsocks、VMess、Trojan、VLESS、Hysteriaはそれぞれ独自の認証、メッセージ構造、トランスポート設計を持つ。TUNはローカルIPデバイスインターフェースであり、TLSはトランスポートセキュリティメカニズム、WebSocketはメッセージトランスポート、REALITYとVisionは異なる役割を担う。

5つの次元で範囲を絞り込む

ローカルエントリとリモートエグジットは組み合わせ可能である。例えば、TUNでインターセプトした後、1つのリモートTCPプロキシプロトコルを使用する。これにより、そのリモートプロトコルが自動的にネイティブUDP機能を獲得するわけではない。また、SOCKSエントリからQUICのリモートトランスポートに接続することも可能だが、SOCKSは単なるローカルインターフェースに過ぎない。

コアメカニズムの対照

表は能力構造を記述するものであり、すべてのクライアントと組み合わせが全機能を実装することを保証するものではない。プロトコル拡張、Mux、UDPカプセル化は両端のバージョンに応じて確認する必要があり、ある実装のオプションモジュールをプロトコルの必須部分として扱ってはならない。

Shadowsocks：AEAD保護とワイヤーフォーマットバージョン

旧AEAD TCPストリームは、最初にsaltを送信し、セッションサブキーで長さブロックとコンテンツブロックを保護する。長さにも独立した認証タグがある。各チャンクには2回のAEAD操作があり、nonceは仕様に従って進化する。UDPは独立したデータグラムとして構築され、TCPストリームのチャンク状態を再利用しない。Shadowsocks AEAD

AES-128-GCM旧AEADフォーマットを例にとると、salt 16B、長さ 2B とそのタグ 16B、コンテンツ N B とそのタグ 16B となる。1000Bのプロトコルペイロードを1つのチャンクとして送信する場合、この方向の初回合計は 16+2+16+1000+16=1050B となる。2つのチャンクに分割すると 1084B となる。ここでペイロードには宛先アドレスなどのプロトコルデータが含まれる可能性があり、1000Bの純粋なアプリケーションコンテンツではない。また、TCP/IPヘッダーは含まれていない。

def old_aead_tcp_size(payload_sizes, salt=16, tag=16):
    assert all(0 < size <= 0x3fff for size in payload_sizes)
    return salt + sum(2 + tag + size + tag for size in payload_sizes)

assert old_aead_tcp_size([1000]) == 1050
assert old_aead_tcp_size([500, 500]) == 1084
assert old_aead_tcp_size([500, 500]) - old_aead_tcp_size([1000]) == 34
print('1チャンク / 2チャンク:', old_aead_tcp_size([1000]), old_aead_tcp_size([500, 500]))

AEAD-2022は、鍵の要件、セッション、リプレイ処理、メッセージ構造などを更新したものであり、単に暗号名を置き換えて旧saltとチャンク図式を適用してはならない。設定の移行時には、両端のプロトコル世代、鍵フォーマット、UDPサポートを同時に確認する必要がある。SIP022

認証暗号は規定条件下での機密性と完全性を保証するが、暗号文の長さ、チャンク分割、または接続動作が通常のHTTPSと一致することを約束するものではない。あるデプロイメントが識別されたからといって、AEADの暗号学的安全性が失われたことを意味するわけではない。

同じ1000バイトでも、小さく分割するとどれくらい余分にかかるか？

チャンク数を1から2に変更し、コンテンツの総量は変わらず、認証と区切りコストが1回分（34B）追加されるだけである。20チャンクに増やすと、認証と区切りのコスト比率が顕著に上昇する。ここでは明確なワイヤーフォーマットの予算を説明しており、バイト数が少ないことが必ずしも実際の速度が速いことを意味しない。

$$L=16+N+34k$$

VMess：プロキシメッセージと外部トランスポートの分離

VMessは独自の認証要求ヘッダーとデータフォーマットを使用して、ターゲット、オプション、アイデンティティを表現する。AEADヘッダーフォーマットは区別すべきプロトコルバージョンである。時間関連の検証は、時計の条件がハンドシェイクに影響することを意味する。これを「TCPの中にランダムな暗号化バイトを置くもの」と単純化してはならない。V2Fly VMess仕様

WebSocketなどのトランスポート上でVMessをトランスポートすると、接続確立、フレーム、またはプロキシ動作のレイヤーが追加される。CDNが利用可能かどうかは、実際にサポートされているHTTPトランスポートと転送設定に依存し、1つのTCPストリームにTLSを被せただけで、任意のCDNが中継できるとは限らない。

複数の論理セッションをマルチプレクシングすると、接続確立回数を減らせる場合もあるが、外部TCPのヘッドオブブロッキングを共有することになるかもしれない。マルチプレクシングの選択は、短寿命接続の数、インタラクションレイテンシ、パケット損失条件に応じて行うべきであり、Muxが常に高速であると仮定してはならない。

Trojan：TLSの外観とアプリケーション認証は異なる保証

TrojanはTLS接続内でプロキシ認証および要求情報を送信し、そのプロトコルにはTCP CONNECTおよびUDP ASSOCIATE類のコマンドが含まれる。TLSはチャネルを保護しサーバーを検証するために使用され、プロキシ資格情報はリレーを許可するかどうかを決定するために使用される。どちらかが欠けても、互いを補完することはできない。

UDPデータは、このプロトコル内でターゲット、長さ、コンテンツなどのレコードフォーマットを持ち、TLSストリームでトランスポートされる。データグラムの境界は保持されるが、外部の信頼できるストリームにギャップが発生すると、後続のデータは復旧を待つ。TCPの信頼性特性は、リアルタイムUDPアプリケーションには適していない可能性がある。Trojanプロトコル

通常のTLSハンドシェイクとフォールバックサイトは、観察される動作を変更するのに役立つが、ハンドシェイクパラメータ、トラフィックサイズ、タイミング、デプロイメントの応答は依然として異なる可能性がある。有効な公開証明書は、対応するサービスアイデンティティを証明するだけであり、「通常のウェブページアクセスと区別できない」ことを保証するものではない。

VLESS、Vision、REALITYはそれぞれ何を担うか

VLESSはユーザーIDおよびプロキシ要求セマンティクスを保持しており、UUID類のアイデンティティフィールドを削除していない。従来のencryption: none組み合わせは、外部TLS/REALITYなどに保護を依存する。2026年9月現在、Project XドキュメントではVLESS暗号化オプションも定義されているため、「VLESSは常にプロトコル暗号化がない」と不変の事実として記述することはできない。

Visionは特定のストリーム処理モードであり、内部TLSの識別、パディング、適用パスの最適化に関係するものであり、新しいTLSスイートではなく、XUDPやMuxと同等に扱ってはならない。モードの選択はUDP443の処理ポリシーを変更する可能性があり、「VLESS」ラベルだけでなく、具体的なflowを確認する必要がある。Project X VLESS設定

REALITYは専用認証とハンドシェイク処理を採用し、認証に失敗した接続用のフォールバック動作を設計している。サーバーは独自の設定鍵を持ち、クライアントは対応する検証材料を保持する。これはサードパーティのウェブサイトの秘密鍵を取得するものではなく、「备案（登録）によって某ウェブサイトの真正な証明書を取得する」ことで合法なプロキシクライアントの認証を完了するものでもない。REALITYプロジェクト

現在のXrayクライアントコードには、AuthKeyなどの材料に基づく専用証明書検証パスが含まれており、通常の証明書検証と期待されるREALITY認証状態に達したかどうかを区別している。InsecureSkipVerifyフラグの1つを読み取って「全く検証を行わない」と断言するのは誤りであり、カスタム検証が設定されているからである。Xray REALITYクライアント実装

公開証明書をコピーしても、任意のサーバーがその証明書の秘密鍵を保持していることを証明することはできない。フォールバック転送と専用クライアント認証は別のパスである。このメカニズムは特定の違いを減らすことができるが、プロジェクトの目標から直接、すべてのアクティブな探査が無効である、またはすべての観察者に対して識別不可能な保証があることを導き出すことはできない。

Hysteria 2：QUICマルチストリームとオプションの外部難読化

Hysteria 2はQUIC/TLSを使用し、HTTP/3認証交換を通じてプロキシ使用権限を確立する。認証を通過した後、TCP接続はそれぞれ対応する双方向ストリームを使用し、UDP機能はサーバーによって表明され、プロトコルに従ってカプセル化される。これは、すべてのプロキシコンテンツを通常のウェブページHTTP応答としてトランスポートするものではない。

QUICはストリーム間で個別に回復を許可するが、接続の輻輳制御は依然として共有される。Hysteriaの輻輳と帯域幅設定は送信戦略に影響し、より大きな帯域幅値を埋め込んでも実際のリンク容量が増加するわけではない。ボトルネックのキューイングは、小さなインタラクションレイテンシを損なう可能性さえある。Hysteria 2プロトコル

Salamanderはオプションの外部難読化であり、saltを追加してQUICパケットバイトを処理する。これはパケット長、方向、タイミングを消除するものではなく、すべての検出が無効になることを保証するものでもない。現在のドキュメントには他の難読化オプションもリストされており、1つのオプションをプロトコルの唯一の永久形式として記述することはできない。QUICはTLSハンドシェイクを含み、Initial保護材料は公開情報から派生できるため、「QUICにはTLSフィンガープリントがない」という主張自体が成立しない。

UDPが制限されたネットワークでは、QUIC類のトランスポートは利用できないか不安定になる可能性がある。利用可能な場合でも、最初のバイト、尾部レイテンシ、スループット、CPUを測定すべきであり、「UDPベースである」という理由だけでパフォーマンスを判断すべきではない。クライアント設定は、サーバーおよび使用されているバージョンと一致させる必要がある。Hysteriaクライアント設定

有意義な比較を行うには

比較では、サーバーの位置、パス、負荷、クライアントバージョンを固定し、設定の組み合わせを記録する必要がある。1回の失敗は、DNS、証明書、UDPパス、またはバージョンの不一致に起因する可能性がある。プロトコルのセキュリティ目標、実装の正しさ、デプロイメントの到達可能性、識別リスクは、それぞれ証拠に基づいて提示するべきである。

継続的な参照

• フォワードプロキシ：CONNECT、SOCKS5、DNSの位置。
• トランスパレントプロキシとTUN：ローカルインターセプトおよびアウトバウンドバイパス。
• TLS 1.3：認証、鍵、ハンドシェイクの可視性。
• UDPとQUIC：信頼できるストリーム、DATAGRAM、および輻輳の境界。