HTTP/2はTCP上で動作し、TCPはまさにCONNECTトンネルやSOCKS5接続が運ぶものなので、プロキシを問題なく通過します。HTTP/3はそうではありません。HTTP/3はUDPベースのQUIC上で動作し、通常のHTTPプロキシはUDPをトンネリングできず、ほとんどのSOCKS5デプロイメントも同様に転送しません。 実際の結果として、プロキシ経由のクライアントは、サイトがHTTP/3をサポートしている場合でも、ほとんどの場合HTTP/2（またはHTTP/1.1）で通信します。ブラウザは静かにフォールバックします。これはほとんどの作業では問題ありませんが、宛先から見えるものが変わるため、後で発見するよりも理解しておく価値があります。
3つのプロトコルを1分で
- HTTP/1.1（1997年）：テキストベースで、1接続につき1リクエスト。ブラウザは並列に複数の接続を開いて補います。
- HTTP/2（2015年）：バイナリフレーミング、1つのTCP接続で多重化される多数の同時ストリーム、ヘッダー圧縮（HPACK）、サーバープッシュ（現在はほぼ廃止）。基盤はHTTP/1.1と同じTCP + TLS。
- HTTP/3（2022年）：HTTP/2と同じセマンティクスですが、QUICによって運ばれます。QUICはUDP上で動作し、TLS 1.3をハンドシェイクに組み込み、TCPのヘッドオブラインブロッキングを回避し、IPアドレスの変更（スマートフォンがWi-Fiから4Gに移行する場合など）でも接続を維持できます。
ブラウザは、サイトがHTTP/3を提供していることを、以前のHTTP/2応答のAlt-Svc: h3=":443"応答ヘッダー、またはそれを宣伝するDNS HTTPSレコードの2つの方法のいずれかで学習します。認識すると、次の接続でQUICを試行し、その結果を記憶します。
各プロトコルをプロキシが運ぶ方法
HTTPプロキシ
HTTPS宛先の場合、クライアントはCONNECT host:443を送信し、プロキシは宛先へのTCP接続を開き、単純なバイトパイプになります。そのパイプ内でクライアントと宛先がネゴシエートするもの（TLS 1.3、次にALPNを介したHTTP/1.1またはHTTP/2）はプロキシからは見えず、そのまま機能します。したがって、HTTPプロキシ経由のHTTP/2は完全に正常です。
UDPはこのモデルには場所がありません。CONNECTはTCPトンネルを作成します。プレーンなHTTP/1.1プロキシが「UDPデータグラムをこのホストに転送する」と言う標準的な方法はありません。HTTPプロキシで構成されたブラウザは、オリジンへのQUICを単に試行しません（ChromeとFirefoxはプロキシ接続でHTTP/3を無効にします）。代わりにトンネル経由でHTTP/2を使用します。エラーも警告もありません。
SOCKS5プロキシ
SOCKS5は、データグラムを中継するためのUDP ASSOCIATEコマンドを定義しています。原理的にはSOCKS5プロキシはQUICを運ぶことができます。実際には：
- 多くの商用SOCKS5プロキシは
CONNECT（TCP）のみを実装し、UDP ASSOCIATEを拒否または無視します。 - SOCKS5を介したUDPリレーでは、プロキシが到達可能なUDPポートを持ち、クライアントがアソシエーションダンスをサポートする必要がありますが、ブラウザはHTTP/3ではそれを実行しません。
- ChromeとFirefoxは、この目的ではSOCKSプロキシをHTTPプロキシと同じように扱います：HTTP/3は試行されません。
したがって、プロキシがUDPを転送できる場合でも、ブラウザはそれを要求しません。コマンドラインのQUICクライアントや一部のライブラリは、UDP対応のSOCKS5プロキシを指定できますが、これは専門的な構成であり、デフォルトではありません。SOCKS5とHTTPプロキシの比較では、TCP/UDPの違いについて詳しく説明しています。
HTTP/3を運ぶもの：MASQUEとCONNECT-UDP
IETFのMASQUEワーキンググループは、CONNECT-UDP（RFC 9298）を標準化しました。これは、HTTP/3（またはHTTP/2）プロキシがUDPペイロード（および拡張としてオリジンへのQUIC）をトンネリングできるようにする拡張機能です。AppleのiCloud Private Relayや一部の新しいプライバシープロキシで使用されています。汎用の商用プロキシやブラウザのプロキシ設定でのサポートはまだ一般的ではありません。プロバイダーが「HTTP/3サポート」を宣伝している場合、プロキシがあなたとHTTP/3で通信することを意味するのか、オリジンへのHTTP/3をトンネリングできることを意味するのかを尋ねる価値があります。これらは別物です。
実際に何が起こるか、ステップバイステップ
- プロキシ経由のブラウザが
https://example.comをリクエストします。プロキシを介してCONNECT example.com:443を開きます。 - トンネル内でTLS 1.3ハンドシェイクを行い、ALPN
h2とhttp/1.1を提供します。オリジンはh2を選択します。HTTP/2で通信しています。 - 応答には
Alt-Svc: h3=":443"が含まれます。ブラウザはそれを記録しますが、プロキシが構成されているため、接続目的では無視します。 - そのオリジンへの後続のすべてのリクエストは、トンネル経由のHTTP/2で継続されます。
プロキシをオフにしてリロードすると、ブラウザはAlt-Svcを尊重し、同じサイトがHTTP/3で提供されます。どちらの場合も何も壊れていません。プロトコルが異なるだけです。
なぜ重要か
パフォーマンス
HTTP/3の利点（高速なハンドシェイク、損失の多いリンクでのヘッドオブラインブロッキングの回避、接続マイグレーション）は、プロキシを介すると失われます。良好なリンク上のデータセンタープロキシでは、その差は小さいです。モバイルプロキシでは、最後のホップが損失の多いセルラーリンクであり、QUICが最も役立つはずなのに、まさにそこでは使用できません。直接のHTTP/3接続よりも少し余分なレイテンシを見込んでください。プロキシ速度の測定方法の方法論を参照してください。
フィンガープリンティングと一貫性
これは微妙な点です。アンチボットシステムは、クライアントが使用したプロトコルとHTTP/2 SETTINGSの内容を記録します（アンチボットシステムの仕組みを参照）。直接接続の最新のChromeは、ほとんどの大規模サイトにHTTP/3で到達します。同じChromeがプロキシを経由すると、HTTP/2で到達します。それ自体は疑わしいことではありません（多くの実際のユーザーが企業プロキシの背後にいて、HTTP/3を使用したことがない）が、もう1つのデータポイントであり、HTTP/2フィンガープリント（SETTINGS値、ヘッダー順序）が常に公開され、主張するブラウザと一致している必要があることを意味します。ブラウザを偽装するHTTPクライアントは、TLSレイヤーだけでなくHTTP/2レイヤーも偽装する必要があります。TLSフィンガープリンティングの記事でスタックを説明しています。
スクレイピングツール
PythonのrequestsはHTTP/1.1のみを話します。httpxはh2エクストラでHTTP/2をサポートします。aiohttpはHTTP/1.1です。どれもプロキシ経由のHTTP/3はできません。プロキシ経由のブラウザはとにかくHTTP/2なので、クライアントでHTTP/2を使用する（ライブラリがサポートしている場合）と、実際のプロキシユーザーに最も近くなります。Pythonでのプロキシの例を参照してください。
実用的なガイダンス
| 状況 | 得られるもの | アクション |
|---|---|---|
| ブラウザ + HTTPプロキシ、HTTP/3サイト | CONNECTトンネル経由のHTTP/2 | 何もする必要はありません。これは正常です |
| ブラウザ + SOCKS5プロキシ、HTTP/3サイト | HTTP/2（ブラウザはSOCKS経由でQUICを試行しません） | 何もする必要はありません |
| プロキシ経由でオリジンへのHTTP/3が必要 | エンドツーエンドのCONNECT-UDP/MASQUEサポートが必要 | プロバイダーに具体的に確認してください。確認されない限り、サポートされないと想定してください |
| サイトがプロキシ経由と直接で動作が異なる | プロトコル関連の可能性、IP関連の可能性が高い | HTTP/3のせいにする前に、同じプロキシ上の実際のブラウザと比較してください |
| 保護されたサイトのクライアント偽装 | ブラウザのHTTP/2 SETTINGSとヘッダー順序を一致させる必要があります | TLSだけでなくHTTP/2も偽装するクライアントを使用してください |
| プロキシのレイテンシ測定 | 同等のものと比較：HTTP/2直接 vs HTTP/2プロキシ経由 | HTTP/3直接とHTTP/2プロキシ経由を比較しないでください |
よくある質問
HTTP/2はプロキシ経由で機能しますか？
はい。HTTP/2はTCPとTLS上で動作し、CONNECTトンネルやSOCKS5接続が透過的に運びます。プロキシはHTTP/2を理解する必要はまったくありません。
HTTP/3はプロキシ経由で機能しますか？
一般的にはいいえ。HTTP/3はUDP上のQUICを使用します。HTTPプロキシはUDPをトンネリングできず、ブラウザはプロキシが構成されている場合QUICを試行しません。ブラウザは自動的にHTTP/2にフォールバックします。CONNECT-UDP（MASQUE）をサポートするプロキシのみがHTTP/3をオリジンに運ぶことができますが、それはまれです。
SOCKS5プロキシはQUICを運べますか？
プロトコルにはUDPリレーコマンドがありますが、多くの商用SOCKS5サービスはそれを実装しておらず、ブラウザはHTTP/3に使用しません。プロキシがUDP ASSOCIATEを実際にサポートしている場合、専門的なクライアントは使用できます。
HTTP/2の代わりにHTTP/3を使用すると検出されますか？
それ自体では検出されません。多くの正当なユーザーがHTTP/2を強制するプロキシの背後にいます。ただし、HTTP/2フィンガープリントが常に表示されるため、主張するブラウザと一致している必要があります。
HTTP/3はプロキシ経由で高速ですか？
通常のプロキシではHTTP/3は得られないため、その質問は発生しません。HTTP/2が得られ、損失の多いリンクではHTTP/3よりもわずかに遅くなります。良好なデータセンターリンクでは、その差は無視できます。
Alt-Svcとは何ですか？
HTTP応答ヘッダーで、サイトが同じリソースが別のプロトコルまたはポートで利用可能であることをクライアントに通知します。通常はh3=":443"でHTTP/3を宣伝します。ブラウザは直接接続では尊重しますが、プロキシが構成されている場合は接続目的では無視します。