HTTP/3 のリクエストには UDP 対応のプロキシ経路が必要

TCP プロキシ経由で HTTPS に到達できたクライアントが、HTTP/3 の経路を確立したわけではありません。HTTP/3 は QUIC を使い、QUIC は UDP を使います。

通常の HTTP CONNECT トンネルは宛先への TCP ストリームを提供します。URL が HTTPS で始まる場合や宛先がポート 443 で待ち受けている場合でも、UDP リレーには変わりません。

SOCKS5 にも UDP の経路が必要

SOCKS5 は UDP アソシエーションを定義していますが、クライアントとサーバーの両方が実装している必要があり、リレーのエンドポイントに到達できなければなりません。SOCKS の TCP ダイヤラーだけを公開するライブラリは、型名が SOCKS5 だからという理由だけでデータグラム転送を提供できるわけではありません。

同様に、proxy という名前のツールのコンポーネントが、汎用の上流プロキシクライアントではなく開発用のパケットロスシミュレーターである場合もあります。その実際のインターフェースと対応するトランスポートを確認してください。

CONNECT-UDP のような標準は、HTTP プロキシシステムを通じて UDP を運ぶ別の方法を定義しています。両端での対応が必要であり、従来の CONNECT と混同すべきではありません。

HTTP クライアントが TCP 上の HTTP/2 や HTTP/1.1 にフォールバックした場合、HTTP/3 接続を使わないまま通常のプロキシ経由でリクエストが成功することがあります。この区別が重要な場合は、ネゴシエートされたプロトコルを記録してください。

したがって有用な互換性の問いは具体的です。このクライアントは、この対応済みの仕組みを使って、このプロキシ経由で QUIC データグラムを運べるのか。動作するブラウザページや TCP ポートの確認では、より小さな問いにしか答えられません。