結論の先取り：「速さ」と「検閲耐性」は環境で逆転する
Hysteria 2（以下 Hy2）と、VLESS に Reality と呼ばれる TLS 上の偽装機構を載せた構成は、2026 年現在も高性能プロキシを語るうえでの定番コンビです。ただし、どちらが「絶対に速い」「絶対に検閲に強い」かは、あなたの ISP、ルーター、モバイル回線の混雑、職場 Wi-Fi の DPI の深さで答えが変わります。
本稿では、ベンチマーク一枚勝負ではなく、パケットがどのレールを走るかと検閲装置からどう見えるかの二本立てで整理します。最後に、複数プロトコルをルールで束ねられる Clash 系クライアントとの相性も触れます。
Hysteria 2 が強みを出す場面
Hy2 は QUIC（UDP 上のトランスポート）を前提に設計されており、ユーザー体感的には 遅延のぶれが小さい・損失に強いと評価されることが多いです。モバイル回線の瞬断やバッファブロートが出やすい経路では、TCP 前提の隧道よりスループットが頭打ちになりにくい、という説明が実務でも出てきます。
一方で UDP は運用者にとって両刃です。キャリアが QUIC をまとめて遅くしたり、UDP を細くしたりするポリシーを敷いているエッジでは、Hy2 が論理上優れていても 物理レーンが空いていないことになります。また、データセンターから見た「一定パターンの上り UDP 負荷」は、単純なレート制限やフローキーの対象になりやすい、というリスクも無視できません。
VLESS Reality が狙っている「見せ方」
Reality は、いわゆる 本物のウェブサイトの TLS に見えるハンドシェイクを作るための仕組みです。プロキシそのものが特徴的なフィンガープリントを晒さない設計思想があり、特徴一致型の検出と組み合わせた議論では強いカードになります。転送層は基本的に TCP の TLS で、ブラウザや CDN と似た見え方を目指します。
クライアント側では Vision（XTLS Vision など）を用いて、TLS 上の応用データの載せ方を現実的なアプリに寄せる、というレイヤーの話がセットになることが多いです。細部のパラメータや実装の更新は速いので、実運用ではクライアントとコアのバージョン互換を固定してメモしておくと再現性が上がります。
速度・遅延：数字より「ボトルネックの位置」
スピードテストのトップラインだけを比べると誤解が生まれます。典型例は次の三つです。
- 最後マイルの UDP が細い：Hy2 が伸びず、TCP/TLS の Reality が意外と勝つ。
- 往復が長くランダムな損失がある：QUIC の再送・輻輳制御が効き、Hy2 が快適に感じる。
- CPU がボトルネック：どちらも暗号処理やユーザースペース実装の差で頭打ち。古いスマホや仮想マシンでは必ず計測してください。
運用上の Practical な指標は、長時間のファイル転送、複数並列の TLS 接続、低遅延が要る VoIP やリモートデスクトップの三種の神器です。単発の数値より、自分が毎日困るシナリオに近い負荷を当てる方が意思決定の質が上がります。
公平な比較のコツ：同じ出口ノード帯域、同じ時間帯、同じ端末で交互に切り替え、少なくとも数分単位で複数回繰り返してください。一度きりのピークはバースト料金や相手サーバーの混雑の影響を拾います。
検閲耐性：プロトコル名より「運用の厚み」
検閲は「その名前のプロトコルをブロック」と一択ではありません。ドメインフィルタ、SNI の許可リスト、TLS の稽古、レートやフロー長のヒューリスティクス、標準ポート以外への注目、などが層になっています。
Hy2 に対しては、QUIC 全体、または「海外の特定 ASN に向かう UDP」を広く締める対策が効く場面があります。逆に言えば UDP が通りやすい商業回線では、シンプルな特徴一致より先に通過するケースもあります。
Reality は TLS の外観を寄せる一方、運用ミスで証明書鎖やクライアント挙動から浮くと、アプリ層の特徴に戻って検出議論が始まります。偽装先、許可リスト、中間機器の挙動まで含めた設計がセットです。
現場で効くのはしばしば 複数経路・複数ポート・フェイルオーバーの冗長化です。一本だけ神プロトコル、というより「片方が死んでも業務が止まらない」構成の方が 2026 年の現実には合います。
観点別の早見表
| 観点 | Hysteria 2 | VLESS + Reality |
|---|---|---|
| 主なトランスポート | QUIC / UDP | TCP 上の TLS（外観を偽装） |
| 損失・変動遅延に強いか | 設計上の有利が出やすい | TCP 特性に依存 |
| UDP を細くする ISP | 不利になりやすい | 比較的影響が小さいことが多い |
| TLS フィンガープリント対策 | 別筋の議論（実装依存） | Reality の主戦場 |
| 設定の気難しさ | 帯域・ブレークアウト・証明書 | 偽装先・Vision・互換性 |
用途別の素朴なおすすめ
- モバイル回線が主で、夜間に速度が荒ぶる：まず Hy2 を試し、UDP が明らかに詰まるなら Reality へ。
- 企業フリーライドの Wi-Fi で DPI が深い：Reality を軸に、可能ならホワイトリスト型ポートも検討。
- 自宅は有線で安定、出口は混雑しがち：両方のエンドポイントを用意し、ルールで自動フェイルオーバー。
- 勉強がてら片方だけ構築したい：手早く体感するなら手元のネット条件に合う方を先に。もう一方は「保険」として後から追加。
よくある質問
「絶対こっちが速い」はありますか
ありません。出口の帯域制御、混雑、クライアント実装、DNS の出口、MSS/MTU、IPv6 の有無まで含めて結果が変わります。コミュニティのベンチマーク動画は参考にしても、自宅の再現実験を最優先にしてください。
TCP と UDP を同時に賢く使い分けたい
アプリごとにプロキシを手で切り替えると運用が破綻しがちです。ルールエンジン付きのクライアントでドメインや GEOIP に応じてプロキシグループを変える方が長期戦向きです。
合法性と規約
国・組織によって許容される通信手段は異なります。会社や学校のネットワークではポリシー確認が先です。本稿は技術説明であり、違法行為を助長する意図はありません。
単体ツール量産より、ルールで束ねる運用
Hy2 専用クライアントと、Xray 系単体を行き来する運用でも隧道自体は張れます。ただしトラブル時に どのルールでどのフローがどこへ逃げたかを追うコストが積み上がります。購読プロフィールを一つにまとめ、ターミナルからブラウザまで同じルールテーブルに載せられるクライアントの方が、長期では切り分けが速いです。
また、新プロトコルはクライアントとコアのアップデートが早いため、GitHub の散発リリースを手作業で追うより、プラットフォーム別に整理された入手経路から更新する方がミスが減ります。片方の隧道だけが古いバージョンに取り残される、という事故が一番つらいタイプの不具合です。
もし「Hy2 と Reality のどちらをメインにするか」の前に、そもそも毎回別アプリを立ち上げてプロファイルを手で切り替えるのが面倒という段階なら、ルールとログが一枚岩になっている Clash 互換スタックに寄せた方が、速度調整や検閲対策の試行錯誤そのものが軽くなります。比較の次の一歩として、OS 別の最新ビルドをまとめて入手できるページから揃えると、検証サイクルが短くなるはずです。