Eine HTTP/3-Anfrage braucht einen UDP-fähigen Proxy-Pfad
Unterscheiden Sie den QUIC-Transport von HTTP/3 von gewöhnlichen HTTP-CONNECT-TCP-Tunneln und von der optionalen UDP-Unterstützung eines SOCKS5-Dienstes.
Ein Client, der HTTPS erfolgreich über einen TCP-Proxy erreicht, hat noch keinen Pfad für HTTP/3 aufgebaut. HTTP/3 verwendet QUIC, und QUIC verwendet UDP.
Ein gewöhnlicher HTTP-CONNECT-Tunnel liefert einen TCP-Stream zu seinem Ziel. Er wird nicht zu einem UDP-Relay, wenn die URL mit HTTPS beginnt oder das Ziel auf Port 443 lauscht.
Auch SOCKS5 braucht den UDP-Pfad
SOCKS5 definiert eine UDP-Assoziation, aber sowohl Client als auch Server müssen sie implementieren, und der Relay-Endpunkt muss erreichbar sein. Eine Bibliothek, die nur einen SOCKS-TCP-Dialer anbietet, kann keinen Datagrammtransport bereitstellen, nur weil ihr Typname SOCKS5 lautet.
Ebenso kann eine Komponente eines Werkzeugs namens proxy ein Entwicklungssimulator für Paketverluste sein statt ein allgemeiner Upstream-Proxy-Client. Prüfen Sie ihre tatsächliche Schnittstelle und den unterstützten Transport.
Standards wie CONNECT-UDP definieren einen anderen Weg, UDP durch ein HTTP-Proxy-System zu transportieren. Sie erfordern Unterstützung an beiden Enden und sollten nicht mit dem traditionellen CONNECT verwechselt werden.
Wenn der HTTP-Client auf HTTP/2 oder HTTP/1.1 über TCP zurückfällt, kann eine Anfrage über den gewöhnlichen Proxy gelingen, obwohl keine HTTP/3-Verbindung genutzt wurde. Halten Sie das ausgehandelte Protokoll fest, wenn diese Unterscheidung wichtig ist.
Die nützliche Kompatibilitätsfrage ist daher konkret: Kann dieser Client seine QUIC-Datagramme über diesen Proxy mit diesem unterstützten Mechanismus transportieren? Eine funktionierende Browserseite oder eine TCP-Portprüfung beantwortet eine kleinere Frage.