HTTP/2 passiert Proxys ohne Schwierigkeiten, weil es über TCP läuft, und TCP ist genau das, was ein CONNECT-Tunnel oder eine SOCKS5-Verbindung transportiert. HTTP/3 tut das nicht: Es läuft über QUIC, das UDP-basiert ist, und gewöhnliche HTTP-Proxys können UDP überhaupt nicht tunneln, während die meisten SOCKS5-Implementierungen dies ebenfalls nicht tun. Die praktische Konsequenz ist, dass ein proxierter Client fast immer über HTTP/2 (oder HTTP/1.1) mit einer Website spricht, selbst wenn die Website HTTP/3 unterstützt — der Browser fällt still zurück. Das ist für die meisten Arbeiten in Ordnung, aber es ändert, was das Ziel sieht, und es ist verständlich, das zu wissen, anstatt es zu entdecken.
Die drei Protokolle in einer Minute
- HTTP/1.1 (1997): textbasiert, eine Anfrage pro Verbindung; Browser öffnen mehrere Verbindungen parallel, um das zu kompensieren.
- HTTP/2 (2015): binäres Framing, viele gleichzeitige Streams multiplexed über eine TCP-Verbindung, Header-Kompression (HPACK), Server Push (inzwischen weitgehend aufgegeben). Gleiches TCP + TLS wie bei HTTP/1.1.
- HTTP/3 (2022): dieselbe Semantik wie HTTP/2, aber übertragen über QUIC, ein Transport, der über UDP läuft, TLS 1.3 in den Handshake integriert, Head-of-Line-Blocking von TCP vermeidet und es einer Verbindung ermöglicht, einen IP-Wechsel zu überleben (ein Telefon, das von Wi-Fi zu 4G wechselt).
Ein Browser erfährt auf zwei Arten, dass eine Website HTTP/3 anbietet: über einen Alt-Svc: h3=":443"-Response-Header in einer früheren HTTP/2-Antwort oder über einen DNS-HTTPS-Eintrag, der es bewirbt. Sobald er es weiß, versucht er bei der nächsten Verbindung QUIC und merkt sich das Ergebnis.
Wie Proxys jedes Protokoll transportieren
HTTP-Proxy
Für ein HTTPS-Ziel sendet der Client CONNECT host:443, der Proxy öffnet eine TCP-Verbindung zum Ziel und wird zu einer dummen Byte-Pipe. Was auch immer Client und Ziel innerhalb dieser Pipe aushandeln — TLS 1.3, dann HTTP/1.1 oder HTTP/2 über ALPN — ist für den Proxy unsichtbar und funktioniert unverändert. HTTP/2 durch einen HTTP-Proxy ist daher völlig normal.
UDP hat in diesem Modell keinen Platz. CONNECT erstellt einen TCP-Tunnel; es gibt keinen Standardweg für einen einfachen HTTP/1.1-Proxy, um zu sagen: „Leite meine UDP-Datagramme an diesen Host weiter.“ Ein Browser, der mit einem HTTP-Proxy konfiguriert ist, versucht daher einfach kein QUIC zu Origins — Chrome und Firefox deaktivieren HTTP/3 für proxierte Verbindungen — und verwendet stattdessen HTTP/2 durch den Tunnel. Kein Fehler, keine Warnung.
SOCKS5-Proxy
SOCKS5 definiert zwar einen UDP ASSOCIATE-Befehl zum Weiterleiten von Datagrammen. Prinzipiell könnte ein SOCKS5-Proxy QUIC transportieren. In der Praxis:
- viele kommerzielle SOCKS5-Proxys implementieren nur
CONNECT(TCP) und lehnen UDP ASSOCIATE ab oder ignorieren es; - UDP-Relay über SOCKS5 erfordert, dass der Proxy einen erreichbaren UDP-Port hat und der Client den Assoziations-Tanz unterstützt, was Browser für HTTP/3 nicht tun;
- Chrome und Firefox behandeln einen SOCKS-Proxy für diesen Zweck wie einen HTTP-Proxy: HTTP/3 wird nicht versucht.
Selbst wenn der Proxy UDP weiterleiten könnte, wird der Browser ihn also nicht darum bitten. Kommandozeilen-QUIC-Clients und einige Bibliotheken können auf einen UDP-fähigen SOCKS5-Proxy zeigen, aber das ist eine Spezialkonfiguration, nicht der Standard. Unser SOCKS5 vs. HTTP-Vergleich behandelt die TCP/UDP-Unterscheidung allgemeiner.
Was HTTP/3 transportieren würde: MASQUE und CONNECT-UDP
Die IETF-Arbeitsgruppe MASQUE hat CONNECT-UDP (RFC 9298) standardisiert, eine Erweiterung, die es einem HTTP/3- (oder HTTP/2-)Proxy ermöglicht, UDP-Payloads zu tunneln — und damit auch QUIC zu einem Origin. Das verwendet Apples iCloud Private Relay und einige neuere Privacy-Proxys. Die Unterstützung in allgemeinen kommerziellen Proxys und in Browser-Proxy-Einstellungen ist noch ungewöhnlich; wenn ein Anbieter „HTTP/3-Unterstützung“ bewirbt, lohnt es sich zu fragen, ob sie meinen, dass der Proxy mit Ihnen HTTP/3 spricht oder HTTP/3 zu Origins tunneln kann — das sind verschiedene Dinge.
Was tatsächlich passiert, Schritt für Schritt
- Ihr proxierter Browser fordert
https://example.coman. Er öffnetCONNECT example.com:443durch den Proxy. - Innerhalb des Tunnels führt er einen TLS-1.3-Handshake durch und bietet ALPN
h2undhttp/1.1an. Der Origin wählth2. Sie sind auf HTTP/2. - Die Antwort enthält
Alt-Svc: h3=":443". Der Browser notiert es — und ignoriert es für Verbindungszwecke, weil ein Proxy konfiguriert ist. - Jede weitere Anfrage an diesen Origin läuft weiterhin über HTTP/2 durch den Tunnel.
Schalten Sie den Proxy aus und laden Sie neu: Der Browser berücksichtigt jetzt Alt-Svc und dieselbe Website wird über HTTP/3 ausgeliefert. In beiden Fällen ist nichts kaputt; das Protokoll unterscheidet sich lediglich.
Warum es wichtig ist
Leistung
Die Vorteile von HTTP/3 — schnellere Handshakes, kein Head-of-Line-Blocking auf verlustbehafteten Verbindungen, Verbindungsmigration — gehen durch einen Proxy verloren. Bei Datacenter-Proxys auf guten Verbindungen ist der Unterschied gering. Bei mobilen Proxys, wo der letzte Hop eine verlustbehaftete Mobilfunkverbindung ist, würde QUIC am meisten helfen und ist genau dort nicht verfügbar. Kalkulieren Sie etwas mehr Latenz ein als bei einer direkten HTTP/3-Verbindung; siehe die Methodik in Proxy-Geschwindigkeit messen.
Fingerprinting und Konsistenz
Das ist die subtile Sache. Anti-Bot-Systeme zeichnen auf, welches Protokoll ein Client verwendet hat und wie seine HTTP/2-SETTINGS aussahen (siehe Wie Anti-Bot-Systeme funktionieren). Ein modernes Chrome erreicht die meisten großen Websites über eine direkte Verbindung mit HTTP/3. Dasselbe Chrome über einen Proxy kommt mit HTTP/2 an. Für sich genommen ist das nicht verdächtig — viele echte Benutzer sitzen hinter Unternehmens-Proxys und nutzen nie HTTP/3 — aber es ist ein weiterer Datenpunkt, und es bedeutet, dass Ihr HTTP/2-Fingerabdruck (SETTINGS-Werte, Header-Reihenfolge) jetzt immer exponiert ist und mit dem behaupteten Browser konsistent sein muss. HTTP-Clients, die Browser imitieren, müssen genau aus diesem Grund die HTTP/2-Schicht imitieren, nicht nur die TLS-Schicht; der TLS-Fingerprinting-Artikel erklärt den Stack.
Scraping-Tools
Pythons requests spricht nur HTTP/1.1; httpx kann HTTP/2 mit dem h2-Extra; aiohttp ist HTTP/1.1. Keines macht HTTP/3 durch einen Proxy. Da ein proxierter Browser ohnehin auf HTTP/2 ist, hält die Verwendung von HTTP/2 in Ihrem Client (wo die Bibliothek es unterstützt) Sie am nächsten an dem, wie ein echter proxierter Benutzer aussieht. Beispiele in Proxys in Python.
Praktische Anleitung
| Situation | Was Sie bekommen | Aktion |
|---|---|---|
| Browser + HTTP-Proxy, HTTP/3-Website | HTTP/2 über CONNECT-Tunnel | Nichts zu tun; das ist normal |
| Browser + SOCKS5-Proxy, HTTP/3-Website | HTTP/2 (Browser versucht kein QUIC über SOCKS) | Nichts zu tun |
| Sie benötigen HTTP/3 zu einem Origin durch einen Proxy | Erfordert CONNECT-UDP/MASQUE-Unterstützung Ende-zu-Ende | Fragen Sie den Anbieter gezielt; gehen Sie davon aus, dass es nicht geht, es sei denn, es wird bestätigt |
| Website verhält sich proxied anders als direkt | Möglicherweise protokollbedingt, wahrscheinlicher IP-bedingt | Vergleichen Sie mit einem echten Browser auf demselben Proxy, bevor Sie HTTP/3 die Schuld geben |
| Client für geschützte Websites imitieren | Muss die HTTP/2-SETTINGS und Header-Reihenfolge eines Browsers abgleichen | Verwenden Sie einen Client, der HTTP/2 imitiert, nicht nur TLS |
| Proxy-Latenz messen | Vergleichen Sie Gleiches mit Gleichem: HTTP/2 direkt vs. HTTP/2 proxied | Vergleichen Sie nicht HTTP/3 direkt mit HTTP/2 proxied |
Häufig gestellte Fragen
Funktioniert HTTP/2 durch einen Proxy?
Ja. HTTP/2 läuft über TCP und TLS, was ein CONNECT-Tunnel oder eine SOCKS5-Verbindung transparent transportiert. Der Proxy muss HTTP/2 überhaupt nicht verstehen.
Funktioniert HTTP/3 durch einen Proxy?
Im Allgemeinen nein. HTTP/3 verwendet QUIC über UDP; HTTP-Proxys können UDP nicht tunneln und Browser versuchen kein QUIC, wenn ein Proxy konfiguriert ist. Der Browser fällt automatisch auf HTTP/2 zurück. Nur Proxys, die CONNECT-UDP (MASQUE) unterstützen, können HTTP/3 zu Origins transportieren, und das ist selten.
Kann ein SOCKS5-Proxy QUIC transportieren?
Das Protokoll hat einen UDP-Relay-Befehl, aber viele kommerzielle SOCKS5-Dienste implementieren ihn nicht und Browser verwenden ihn nicht für HTTP/3. Spezialisierte Clients können es, wenn der Proxy UDP ASSOCIATE wirklich unterstützt.
Werde ich erkannt, wenn ich HTTP/2 statt HTTP/3 verwende?
Nicht allein dadurch — viele legitime Benutzer sind hinter Proxys, die HTTP/2 erzwingen. Aber es bedeutet, dass Ihr HTTP/2-Fingerabdruck immer sichtbar ist, also muss er mit dem Browser konsistent sein, der Sie zu sein behaupten.
Ist HTTP/3 durch einen Proxy schneller?
Sie bekommen HTTP/3 nicht durch einen gewöhnlichen Proxy, also stellt sich die Frage nicht; Sie bekommen HTTP/2, das auf verlustbehafteten Verbindungen etwas langsamer ist als HTTP/3. Auf guten Datacenter-Verbindungen ist der Unterschied vernachlässigbar.
Was ist Alt-Svc?
Ein HTTP-Response-Header, mit dem eine Website dem Client mitteilt, dass dieselbe Ressource über ein anderes Protokoll oder einen anderen Port verfügbar ist — typischerweise h3=":443", um HTTP/3 zu bewerben. Browser berücksichtigen es bei direkten Verbindungen und ignorieren es für Verbindungszwecke, wenn ein Proxy konfiguriert ist.