HTTP/3 an einer konkreten Domain prüfen: Alt-Svc, curl, Browser, UDP, IPv4 und IPv6 mit nachvollziehbarer Verbindungsevidenz einordnen.
HTTP/3 ist erst nachgewiesen, wenn eine konkrete Anfrage tatsächlich über HTTP/3 beantwortet wird. Eine Hostingbeschreibung, ein LiteSpeed-Header oder ein Alt-Svc-Hinweis reicht dafür nicht. Dieser Ratgeber entwickelt einen Prüfweg, der Clientfähigkeit, Netzwerk, Zieladresse und ausgehandeltes Protokoll auseinanderhält. Das Ergebnis bleibt auf den geprüften Anfrageweg begrenzt.
Die Frage entsteht häufig nach einem Hostingwechsel: Der Anbieter nennt HTTP/3, aber ein Browser zeigt weiterhin HTTP/2. Daraus lässt sich noch kein Defekt ableiten. Der Browser könnte eine andere Verbindung benutzen, das Netzwerk könnte QUIC verhindern oder die erste Anfrage könnte zunächst über eine bekannte Transportverbindung laufen. Umgekehrt kann ein sichtbarer Hinweis auf HTTP/3 vorhanden sein, obwohl der eigene Client die Verbindung nicht herstellen kann.
Die Spezifikation RFC 9114 beschreibt HTTP/3 über QUIC sowie die Protokollauswahl mit dem ALPN-Bezeichner h3. Ein Nachweis sollte daher eine tatsächlich ausgeführte HTTP-Anfrage und das dabei verwendete Protokoll enthalten. Die Zieladresse, der Zeitpunkt und das verwendete Werkzeug gehören zur Aussage. Ein anderes Gerät oder ein anderer Zugang zum Internet kann einen anderen Weg nehmen.
Formulieren Sie Ihr Prüfziel konkret. Beispielsweise: Die öffentliche Hauptseite soll von diesem Prüfgerät über die normale Domainauflösung mit HTTP/3 erreichbar sein. Das ist überprüfbar. Die Aussage, dass der gesamte Server immer HTTP/3 benutze, wäre dagegen zu breit. Einzelne Domains, vorgeschaltete Dienste und nicht unterstützende Clients können unterschiedlich behandelt werden. Ein sinnvoller Bericht benennt deshalb die tatsächlich bestätigte Verbindung.
| Beobachtung | Was sie aussagt | Was noch fehlt |
|---|---|---|
| Anbieter nennt HTTP/3 | Veröffentlichte Produktfähigkeit | Prüfung der konkreten Domain |
| Alt-Svc nennt h3 | Alternative Verbindung wird angekündigt | Erfolgreiche Verbindung und HTTP-Antwort |
| Server-Header nennt LiteSpeed | Antwort bezeichnet ihren Server | Protokoll dieser Anfrage |
| Werkzeug meldet HTTP/3 | Konkrete Anfrage verwendet HTTP/3 | Dokumentation von Ziel und Prüfbedingungen |
Alt-Svc kann einen Client auf einen alternativen HTTP/3-Endpunkt hinweisen. Das entsprechende RFC-Kapitel trennt die Ankündigung von dem anschließenden Verbindungsversuch. Deshalb ist ein Header wie h3 auf Port 443 kein Beleg für einen bereits erfolgreichen QUIC-Handshake. Er zeigt eine angebotene Möglichkeit. Ob sie aus Ihrem Netzwerk nutzbar ist, muss eine tatsächliche Anfrage ergeben.
Ein Browser kann den Hinweis für spätere Zugriffe berücksichtigen. Beim ersten Aufruf steht möglicherweise noch eine TCP-Verbindung im Vordergrund. Bereits gespeicherte Verbindungsinformationen können ebenfalls beeinflussen, welche Anfrage Sie beobachten. Notieren Sie daher, ob es sich um ein frisches Profil oder eine wiederholte Nutzung handelt. Aus einem einzelnen ersten Aufruf folgt nicht automatisch, dass die Alternative nicht erreichbar ist.
Auch der im Header genannte Endpunkt verdient Aufmerksamkeit. Er muss nicht in jeder denkbaren Umgebung derselbe Anschluss sein wie die ursprüngliche Verbindung. Bei vorgeschalteter Auslieferung kann ein anderer Dienst die HTTP/3-Antwort liefern. Prüfen Sie deshalb den realen Anfrageweg und die Zuständigkeit für diesen Endpunkt. Eine manuell eingetragene Ankündigung ohne passenden Dienst würde den gewünschten Nachweis nicht ersetzen.
Für eine Kommandozeilenprüfung bietet curl eine ausdrücklich auf HTTP/3 begrenzte Option. Die offizielle curl-Anleitung unterscheidet sie von einem Aufruf, der auf TCP-basierte Verfahren ausweichen kann. Prüfen Sie zunächst die Ausgabe von curl –version. Die vorhandene Binärdatei und ihre Features sind entscheidend; der Name des Programms garantiert keine HTTP/3-Unterstützung.
Wenn die Option unbekannt ist oder die Ausgabe die erforderliche Unterstützung nicht enthält, beschreibt der Fehler die Werkzeugumgebung. Er beweist keinen Fehler des Zielservers. Verwenden Sie einen bereits geeigneten Client oder eine unterstützende Browserprüfung. Die Diagnose sollte an dieser Stelle nicht in ungeprüfte Serveränderungen übergehen. Zuerst muss feststehen, dass der verwendete Prüfer überhaupt die gewünschte Verbindung erzeugen kann.
Das folgende Beispiel ist eine Anleitung mit einer reservierten Beispieldomain. Ersetzen Sie das Ziel durch eine eigene autorisierte Adresse. Der Aufruf lädt eine normale Seite und meldet Protokoll sowie Status. Er enthält keine bereits gemessenen Ergebnisse. Ein Zeitlimit sorgt dafür, dass ein ausbleibender Verbindungsaufbau als begrenzter Versuch sichtbar wird.
curl --version
curl --http3-only --max-time 20 --silent --show-error \
--output /dev/null \
--write-out 'HTTP=%{http_version}\nSTATUS=%{response_code}\n' \
https://example.org/Ein ausgegebener HTTP/3-Wert muss mit einem erfolgreichen Verbindungsversuch zusammen betrachtet werden. Bewahren Sie den Prozessstatus und gegebenenfalls die Fehlermeldung auf. Eine leere oder nicht ausgeführte Anfrage ist kein Erfolg. Der HTTP-Status kann zugleich auf einen Zugriffsschutz hinweisen: Auch eine authentifizierungsbedingte Antwort kann über HTTP/3 übertragen werden. Das Protokoll und die fachliche Zugriffsberechtigung sind verschiedene Prüfpunkte.
Bei Weiterleitungen bleibt wichtig, welche Adresse geprüft wurde. Ein Aufruf der Hauptdomain kann auf www oder einen anderen Host weiterleiten. Wenn Sie diesen Weg verfolgen, dokumentieren Sie die einzelnen Ziele beziehungsweise mindestens die endgültige Adresse. Andernfalls könnte der Bericht das Protokoll des letzten Hosts fälschlich dem ursprünglichen Ziel zuschreiben. Für eine Domainabnahme sollten die gewünschte Hauptadresse und ihre Weiterleitungen ausdrücklich benannt sein.
Verwenden Sie reguläre Zertifikatsprüfung. Eine Verbindung, die nur nach Abschalten der Namens- oder Zertifikatskontrolle gelingt, bestätigt nicht die korrekte öffentliche HTTPS-Einrichtung. Der Prüfbericht soll zeigen, dass der Zielname und seine Verbindung zusammenpassen. Ein falsch zugeordnetes Zertifikat wird gesondert behoben oder als offener Punkt dokumentiert. Das Protokoll allein macht eine falsche Namenszuordnung nicht akzeptabel.
Die Chrome-Netzwerkreferenz beschreibt, wie sich die Netzwerkübersicht um eine Protokollspalte ergänzen lässt. Suchen Sie die HTML-Anfrage der gewünschten Seite und betrachten Sie ihr tatsächlich verwendetes Protokoll. Ein Bild von einem fremden Auslieferungsdienst kann h3 verwenden, während das Hauptdokument über HTTP/2 kommt. Die Beobachtung einer beliebigen Ressource wäre dann kein Nachweis für die eigene HTML-Ausgabe.
Wiederholen Sie den Aufruf bewusst und halten Sie den Zustand fest. Browsercache, wiederverwendete Verbindungen und gespeicherte Alternativinformationen können das Ergebnis beeinflussen. Prüfen Sie, ob eine Ressource tatsächlich aus dem Netzwerk angefordert wurde. Eine ausschließlich lokal verwendete Kopie enthält keine neue Verbindungsevidenz. Bei einer schwierigen Beobachtung hilft ein geeignetes frisches Browserprofil, ohne andere laufende Arbeit oder bestehende Sitzungen zu verändern.
Für einen verständlichen Bericht genügen Ziel, Zeitpunkt, Browserfassung und die relevante Netzwerkzeile. Entfernen Sie vertrauliche Header oder Cookies aus einer weitergegebenen Aufnahme. Ein Screenshot sollte den eigentlichen Nachweis lesbar machen und nicht unnötig sämtliche offenen Tabs zeigen. Die schriftliche Aussage erklärt anschließend, für welche Ressource und welche Bedingungen HTTP/3 bestätigt wurde.
LiteSpeed beschreibt in seiner HTTP/3-Dokumentation die Rolle von UDP. In üblichen HTTPS-Konfigurationen wird Port 443 verwendet; alternative angekündigte Endpunkte sind gesondert zu beachten. Ein Netzwerk kann UDP-Verkehr anders behandeln als TCP. Daher kann eine normale HTTPS-Seite erreichbar sein, während der ausdrücklich auf HTTP/3 begrenzte Versuch aus demselben Netz scheitert.
Ein einfacher UDP-Portscan ersetzt keinen QUIC-Verbindungsaufbau mit einer gültigen HTTP-Antwort. Aus einem ausbleibenden Scanergebnis folgt keine eindeutige Diagnose des Dienstes. Sammeln Sie stattdessen das Ergebnis des geeigneten Clients und fragen Sie nach den tatsächlichen Firewall- und Dienstbedingungen. Wenn ein Vergleich aus einem zweiten bekannten Netz möglich ist, kann er die Eingrenzung unterstützen. Beide Ergebnisse werden mit ihrem Netzkontext dokumentiert.
IPv4 und IPv6 verdienen getrennte Prüfung. Eine erfolgreiche IPv4-Verbindung bestätigt natives IPv6 nicht. Für IPv6 müssen zunächst passende autoritative DNS-Antworten vorhanden sein; anschließend wird die Verbindung tatsächlich über diese Adressfamilie aufgebaut. Bei curl können entsprechende Adressfamilienoptionen Teil eines getrennten Versuchs sein. Ohne veröffentlichtes AAAA-Ergebnis ist ein direkter Test zu einer bekannten IPv6-Adresse noch kein Nachweis einer normal erreichbaren öffentlichen Domain.
Ein CDN oder Proxy kann das vom Besucher beobachtete Protokoll bereitstellen und den Ursprungsserver über einen anderen Weg ansprechen. Für Besucher ist die äußere Verbindung relevant, für die Serverdiagnose zusätzlich die Verbindung zum Ursprung. Beschreiben Sie beide Ebenen getrennt, soweit sie tatsächlich geprüft wurden. Der Nachweis des äußeren Dienstes darf nicht als ungeprüfte Eigenschaft des Ursprungsservers ausgegeben werden.
Bei LiteSpeed-Projekten hilft der Architekturplan aus QUIC.cloud einordnen. Halten Sie fest, welche DNS-Zuordnung aktiv ist und welcher Dienst die Antworten liefert. Wenn ein alternativer Prüfweg den Ursprung direkt anspricht, bleibt dessen Zweck ausdrücklich begrenzt. Eine Direktverbindung kann die technische Eingrenzung unterstützen, beschreibt aber nicht automatisch den normalen Weg der öffentlichen Besucher.
Diese Trennung schützt auch vor falschen Performanceaussagen. HTTP/3 kann erfolgreich verwendet werden, während eine Website weiterhin große Bilder oder aufwendige Skripte ausliefert. Das Protokoll beantwortet nicht allein, wie schnell ein wichtiger Inhalt sichtbar wird. Unser Messleitfaden verbindet die nachgewiesene Verbindung mit weiteren Beobachtungen, ohne aus der Protokollwahl einen erfundenen Geschwindigkeitsfaktor zu berechnen.
Bei einem gescheiterten Kommandozeilentest bleibt die konkrete Fehlermeldung Teil des Ergebnisses. Ein nicht unterstütztes Argument, eine ausbleibende Namensauflösung und ein gescheiterter Verbindungsaufbau sind verschiedene Zustände. Sammeln Sie sie mit dem verwendeten Aufruf, ohne Zugangswerte oder vertrauliche Header weiterzugeben. Danach kann die nächste Prüfung an der tatsächlichen Stufe ansetzen. Ein unspezifisches Etikett wie HTTP/3 kaputt wäre für diese Fälle zu grob und könnte eine unnötige Änderung am falschen System auslösen.
Auch eine konfigurierte Proxyverbindung kann für den gewählten Client relevant sein. Die curl-Dokumentation beschreibt Grenzen der HTTP/3-Nutzung über Proxys. Prüfen Sie daher den tatsächlich verwendeten Verbindungsweg, bevor Sie aus einem solchen Versuch eine Aussage über die Zieladresse ableiten. Die zugehörige Konfiguration wird gezielt und ohne vollständige Ausgabe vertraulicher Umgebungswerte betrachtet. Ein direkter Vergleich braucht wiederum einen bekannten geeigneten und autorisierten Netzweg. Der Bericht erklärt, welche Bedingung verändert wurde und weshalb die Ergebnisse miteinander betrachtet werden.
Für eine wiederholbare Störungsanalyse hilft eine kleine Versuchsmatrix. Die Spalten können Client, Netz, Adressfamilie und Ziel enthalten; jede Zeile beschreibt einen tatsächlich ausgeführten Aufruf. Erfinden Sie keine Ergebnisse für noch nicht geprüfte Kombinationen. Eine bereits bestätigte IPv4-Verbindung aus einem Prüfnetz kann neben einem offenen IPv6-Versuch stehen. Diese Darstellung zeigt genau, wo zusätzliche Evidenz benötigt wird. Sie erlaubt außerdem, spätere Änderungen mit passenden vorherigen Beobachtungen zu vergleichen, statt unterschiedliche Bedingungen zufällig gegeneinanderzustellen.
Schließen Sie die Prüfung mit einer präzisen Notiz ab: HTTP/3 für diese URL aus diesem Netz mit diesem Client bestätigt, oder nicht bestätigt mit einer konkreten Fehlermeldung. Ergänzen Sie offene Bedingungen wie fehlende Clientunterstützung, nicht veröffentlichtes IPv6 oder einen unklaren Proxyweg. Ein begrenzter ehrlicher Nachweis ist nützlicher als eine allgemeine Erfolgsmeldung aus einem Alt-Svc-Header.
Wenn eine Änderung erfolgt, wiederholen Sie denselben passenden Versuch und bewahren Sie das vorherige Ergebnis auf. So bleibt erkennbar, was sich geändert hat. Ein späteres erfolgreiches Ergebnis ersetzt den alten Fehler nicht rückwirkend. Für die Hostingauswahl kann dieser Bericht eine sachliche Grundlage sein: Der Anbieter wird zu einem tatsächlichen Ziel und einem nachvollziehbaren Zustand befragt, statt nur zu einem Protokollschlagwort.