Eine Website kann modern wirken und trotzdem nur über HTTP/2 ausliefern. Ein sauberer HTTP/3-Test zeigt, ob der Browser oder Client tatsächlich QUIC nutzt, ob UDP auf Port 443 erreichbar ist und ob nur der CDN-Rand oder auch der eigene Server korrekt konfiguriert wurde. Ich zeige die zuverlässigsten Prüfungen mit Browser, curl und HTTP-Headern und ordne typische Fehlermeldungen realistisch ein.
So erkennen Sie echte HTTP/3-Unterstützung
- Browser-Test: In den Entwicklerwerkzeugen muss bei einer Anfrage „HTTP/3“ als Protokoll erscheinen.
- curl-Test: Mit --http3-only lässt sich ein Fallback auf HTTP/2 ausschließen.
- Technischer Hinweis: Der Header Alt-Svc kann HTTP/3 ankündigen, beweist allein aber noch keine erfolgreiche Verbindung.
- Netzwerkfaktor: Firewalls, Unternehmensproxys und Mobilfunknetze können QUIC über UDP 443 blockieren.
- Geschwindigkeit: HTTP/3-Unterstützung bedeutet nicht automatisch kürzere Ladezeiten.
Was ein HTTP/3-Test tatsächlich prüft
HTTP/3 überträgt HTTP nicht über TCP, sondern über QUIC und UDP. Dadurch können sich einzelne Datenströme unabhängiger voneinander bewegen. Verliert ein Stream ein Paket, müssen andere Streams nicht zwangsläufig auf dieses Paket warten. Gerade bei mobilen, instabilen oder weit entfernten Verbindungen kann das einen Unterschied machen.
Der Standard ist in RFC 9114 beschrieben. Für die praktische Prüfung ist vor allem das Kennzeichen h3 wichtig. Es wird bei der Protokollaushandlung verwendet und zeigt, dass der Client tatsächlich HTTP/3 und nicht nur HTTP/2 beherrscht.
Ich trenne bei der Diagnose immer drei Fragen. Unterstützt der Server HTTP/3? Erreicht der verwendete Client den Dienst über QUIC? Und wird die konkrete Anfrage, etwa das HTML-Dokument, wirklich über HTTP/3 ausgeliefert? Erst wenn alle drei Antworten positiv sind, ist der Test eindeutig.
Der schnellste Nachweis im Browser
Für einen ersten Praxistest genügt ein aktueller Browser. Öffnen Sie die Entwicklerwerkzeuge mit F12, wechseln Sie zum Bereich „Network“ oder „Netzwerk“ und blenden Sie die Spalte „Protocol“ ein. Nach einem vollständigen Neuladen sollte bei der Dokumentanfrage HTTP/3 oder eine entsprechende Bezeichnung erscheinen.
- Entwicklerwerkzeuge öffnen und den Netzwerkbereich auswählen.
- Die Spalte „Protocol“ einblenden, falls sie nicht sichtbar ist.
- Den Cache für den Test deaktivieren oder einen privaten Tab verwenden.
- Die Seite vollständig neu laden.
- Die Anfrage des HTML-Dokuments prüfen, nicht nur einzelne Drittanbieter-Ressourcen.
Ein Eintrag wie h2 bedeutet HTTP/2, während http/1.1 auf die ältere Variante hinweist. Ein positiver Test bei einer Bilddatei eines CDN sagt außerdem nicht sicher, dass auch Ihre eigene Domain oder das zentrale HTML-Dokument HTTP/3 nutzt.
Wenn HTTP/3 erst nach dem zweiten oder dritten Laden erscheint, ist das nicht automatisch ein Fehler. Viele Verbindungen entdecken die alternative HTTP/3-Routeninformation zunächst über eine normale HTTPS-Verbindung. Auch zwischengespeicherte Verbindungsdaten und die sogenannte Happy-Eyeballs-Logik des Browsers können beeinflussen, welches Protokoll zuerst gewinnt.
Mit curl ohne Fallback kontrollieren
Für eine technisch klare Aussage nutze ich gern curl. Prüfen Sie zuerst mit curl -V, ob Ihre Installation überhaupt HTTP3 oder eine vergleichbare QUIC-Unterstützung aufführt. Nicht jede Distribution liefert automatisch eine curl-Version mit aktivierter HTTP/3-Funktion.
Der entscheidende Unterschied liegt zwischen einem normalen HTTP/3-Versuch und einem Test ohne Ausweichmöglichkeit:
curl -v --http3-only [IHRE-ZIELADRESSE]Erfolgt eine Antwort, konnte der Client eine reine HTTP/3-Verbindung herstellen. Scheitert der Befehl, bleibt die Ursache offen. Möglich sind eine fehlende HTTP/3-Unterstützung in curl, ein blockierter UDP-Port, eine fehlerhafte Serverkonfiguration oder ein Zertifikatsproblem.
Ein Test mit --http3 ist für den normalen Betrieb ebenfalls nützlich, weil curl bei Problemen auf HTTP/2 oder HTTP/1.1 zurückfallen kann:
curl -v --http3 [IHRE-ZIELADRESSE]Dieser Befehl beantwortet jedoch nur, ob die Anfrage erfolgreich abgeschlossen wurde. Für die Fehlersuche ist --http3-only aussagekräftiger, weil ein stiller Fallback nicht als Erfolg durchgeht. In der ausführlichen Ausgabe sollten Hinweise auf QUIC sowie eine HTTP/3-Antwort wie HTTP/3 200 erkennbar sein.
Header und Netzwerkpfad richtig bewerten
Eine HTTP/2-Antwort kann den Header Alt-Svc enthalten, zum Beispiel:
Alt-Svc: h3=":443"; ma=86400Damit teilt der Server dem Client mit, dass dieselbe Ressource auch über HTTP/3 auf UDP-Port 443 erreichbar ist. Der Wert ma beschreibt, wie lange diese Information verwendet werden darf. Der Header ist ein guter Hinweis, aber noch kein Beweis für eine erfolgreiche QUIC-Verbindung.
Fehlt Alt-Svc, kann HTTP/3 trotzdem über eine andere Konfigurationsmethode bekannt sein oder bereits im Client gespeichert sein. Umgekehrt kann der Header vorhanden sein, während eine Firewall UDP verwirft. Genau deshalb kombiniere ich die Headerprüfung mit dem Browser- oder curl-Test.
| Prüfung | Was sie zeigt | Typische Grenze |
|---|---|---|
| Browser-Netzwerkbereich | Das tatsächlich ausgehandelte Protokoll | Abhängig von Browser, Cache und aktuellem Netzwerk |
| curl mit --http3-only | Ob eine reine HTTP/3-Verbindung möglich ist | Benötigt eine passende curl-Version |
| Alt-Svc-Header | Ob HTTP/3 angekündigt wird | Keine Garantie für eine erfolgreiche QUIC-Verbindung |
| DNS- oder CDN-Konfiguration | Ob HTTP/3 am vorgesehenen Endpunkt aktiviert ist | Zeigt nicht zwingend den realen Clientpfad |
Für eine Website mit Besuchern in Timor-Leste würde ich zusätzlich von mindestens zwei unterschiedlichen Netzen testen, etwa über Festnetz und Mobilfunk. Lange internationale Leitungswege, Carrier-NAT, restriktive Router oder ein Satellitenzugang können Ergebnisse verändern. Ein Test aus Deutschland beweist daher nicht automatisch, dass die Verbindung aus Dili oder einer ländlicheren Region genauso funktioniert.
Warum HTTP/3 manchmal nicht verwendet wird
Der häufigste Irrtum ist die Annahme, dass ein aktivierter Schalter beim CDN jede Anfrage über HTTP/3 erzwingt. In der Praxis entscheidet der Client gemeinsam mit dem Server und dem Netzwerkpfad. Wird UDP blockiert, fällt der Browser meist unauffällig auf HTTP/2 über TCP zurück.
Der Client unterstützt HTTP/3 nicht
Bei curl weist eine fehlende HTTP3-Funktion in curl -V auf eine ungeeignete Installation hin. Eine Neuinstallation aus einem aktuellen Paket oder die Verwendung eines Clients mit QUIC-Unterstützung kann das Problem lösen. Ein Browser kann HTTP/3 unterstützen, während ein Diagnosewerkzeug auf demselben Rechner dazu nicht in der Lage ist.
UDP 443 wird gefiltert
Unternehmensfirewalls, Hotelnetzwerke und manche Mobilfunk- oder Providerstrukturen behandeln UDP vorsichtiger als TCP. Wenn HTTP/3 nur in einem bestimmten Netz fehlt, liegt die Ursache häufig dort. Ein Gegencheck über ein anderes Netz ist dann aussagekräftiger als wiederholtes Neuladen derselben Seite.
Nur der CDN-Rand spricht HTTP/3
Bei einem CDN endet die HTTP/3-Verbindung oft am nächstgelegenen Edge-Knoten. Die Strecke vom CDN zum Ursprungsserver kann weiterhin HTTP/2 oder HTTP/1.1 verwenden. Das ist technisch normal und bedeutet nicht, dass der Origin-Server selbst QUIC anbieten muss.
Lesen Sie auch: Mesh-Topologie: Wann Full Mesh wirklich sinnvoll ist
TLS und Hostnamen passen nicht zusammen
HTTP/3 benötigt eine funktionierende HTTPS-Konfiguration. Ein falsches Zertifikat, ein nicht passender Hostname oder eine unvollständige CDN-Zuordnung kann die QUIC-Aushandlung verhindern, obwohl HTTP/2 noch funktioniert. Ich prüfe deshalb immer zuerst, ob die normale HTTPS-Anfrage fehlerfrei ist.
Unterstützung und Geschwindigkeit getrennt messen
Ein positiver Protokolltest beantwortet nur die Frage, ob HTTP/3 funktioniert. Er sagt nicht, ob die Seite schneller lädt. Die tatsächliche Wirkung hängt unter anderem von Latenz, Paketverlust, Dateigrößen, Serververarbeitung, Cache-Zustand und der Anzahl paralleler Ressourcen ab.
Für einen fairen Vergleich teste ich dieselbe Seite mindestens fünfmal über HTTP/2 und fünfmal über HTTP/3. Dabei sollten Standort, Gerät, Browser, Cache-Zustand und Uhrzeit möglichst vergleichbar bleiben. Entscheidend ist eher der Median als der beste Einzelwert, weil Netzwerke kurzfristig stark schwanken können.
Besonders interessant ist der Vergleich bei hoher Latenz oder leichtem Paketverlust. Auf einer schnellen Glasfaserleitung in Deutschland kann der Unterschied klein bleiben, während eine mobile Verbindung mit langen internationalen Wegen stärker von QUIC profitieren kann. Eine allgemeine Prozentangabe wäre hier unseriös, weil das Ergebnis vom gesamten Übertragungspfad abhängt.
Für die Bewertung beobachte ich neben der Gesamtzeit auch Time to First Byte, Largest Contentful Paint und mögliche Verbindungsabbrüche. HTTP/3 kann die Übertragung robuster machen, aber keine langsame Datenbankabfrage, ein übergroßes Bild oder schlecht abgestimmtes JavaScript reparieren.
Der verlässlichste Prüfablauf für die Praxis
Ich beginne mit dem Browser, weil er die reale Nutzung am besten abbildet. Danach folgt curl mit --http3-only, um Fallbacks auszuschließen. Erst wenn die Ergebnisse widersprüchlich sind, untersuche ich Alt-Svc, CDN-Einstellungen, DNS und die UDP-Erreichbarkeit genauer.
- Schritt 1: HTTPS-Aufruf auf Fehler prüfen.
- Schritt 2: Im Browser die Protokollspalte kontrollieren.
-
Schritt 3: Mit curl und
--http3-onlygegenprüfen. - Schritt 4: Alt-Svc und die HTTP/3-Aktivierung am CDN untersuchen.
- Schritt 5: Aus einem zweiten Netzwerk testen, möglichst auch über Mobilfunk.
- Schritt 6: Geschwindigkeit erst danach mit mehreren Messungen vergleichen.
So lässt sich sauber unterscheiden, ob HTTP/3 nicht aktiviert ist, ob der Client die Funktion nicht beherrscht oder ob lediglich das aktuelle Netzwerk QUIC verhindert. Genau diese Trennung spart in der Praxis die meiste Zeit und verhindert, dass ein unauffälliger HTTP/2-Fallback fälschlich als erfolgreicher HTTP/3-Test gilt.
