So funktioniert’s
HTTP/3 (RFC 9114) überträgt dieselben Anfragen und Antworten wie HTTP/2, nutzt als Transport aber QUIC (RFC 9000) statt TCP. QUIC läuft über UDP, meist auf Port 443, und hat TLS 1.3 fest eingebaut. Verbindungsaufbau und Verschlüsselung passieren in einem Schritt; kennt der Browser den Server schon, kann er sogar ohne zusätzliche Runde Daten schicken.
Ein verlorenes Paket hält bei QUIC nur den betroffenen Datenstrom auf, nicht alle parallel geladenen Dateien wie bei TCP. Das merkst du vor allem im Mobilfunk und in wackligen WLANs. Außerdem übersteht eine QUIC-Verbindung einen Netzwechsel, etwa vom WLAN ins Mobilfunknetz.
Browser starten immer über HTTP/1.1 oder HTTP/2 und erfahren erst aus dem Header Alt-Svc (z. B. Alt-Svc: h3=":443"; ma=86400), dass der Server auch HTTP/3 spricht. Ab dann versuchen sie für diesen Ursprung QUIC. Alternativ kann ein HTTPS-Record im DNS (RFC 9460) HTTP/3 ankündigen.
Warum gefährlich
Fehlendes HTTP/3 ist kein Sicherheitsproblem, die Website läuft dann einfach über HTTP/2. Heikel wird es, wenn der Server HTTP/3 ankündigt, aber nicht über QUIC antwortet: Nach einem Serverumzug, einer neuen Firewall oder einem neuen Load Balancer ist UDP 443 oft zu, während der Alt-Svc-Header weiter ausgeliefert wird.
Browser versuchen dann QUIC, warten auf eine Antwort und fallen erst nach einer Verzögerung auf HTTP/2 zurück. Die Seite wirkt sporadisch träge, obwohl jede normale Erreichbarkeitsprüfung grün ist – ein Fehler, den Kunden spüren, aber kaum jemand findet.
So vermeidest du es
- Kläre mit Hoster oder CDN, ob HTTP/3 verfügbar ist, und schalte es dort ein, statt es selbst in den Webserver einzubauen; viele CDNs und Managed-Hoster bieten es als Schalter an.
- Gib UDP-Port 443 in jeder Firewall und Security Group vor dem Webserver frei – TCP 443 allein reicht für HTTP/3 nicht.
- Liefere den Alt-Svc-Header nur aus, wenn der Server wirklich über QUIC lauscht, und nimm ihn bei einem Umzug heraus, bis HTTP/3 auf dem neuen System läuft.
- Prüfe, ob ein Proxy oder Load Balancer vor dem Server UDP überhaupt weiterreicht; viele ältere Setups leiten nur TCP durch.
- Teste nach jeder Änderung gezielt über QUIC, etwa mit curl --http3-only -I https://example.com/ von einem Rechner außerhalb deines Netzes.
So erkennt DomainWarn es
Der Check HTTP/3 ruft jede überwachte Website normal ab und liest den Alt-Svc-Header der endgültigen Antwort. Kündigt er h3 an, folgt ein zweiter Abruf ausschließlich über HTTP/3 auf dem angekündigten UDP-Port. Antwortet die Website darüber nicht, gibt es eine Warnung; nach zwei Läufen in Folge eröffnet DomainWarn den Incident „HTTP/3 angekündigt, aber nicht erreichbar“. Fehlt h3 ganz, ist das nur ein Hinweis.
Vor jedem Befund prüft DomainWarn den eigenen QUIC-Weg gegen Referenzziele, damit ein gestörter Prüfstandort keinen Fehlalarm auslöst. Der Monitor läuft stündlich, startet abgeschaltet und schaltet sich ein, sobald der Check Website eine HTTP/3-Ankündigung sieht. Der Check Website hält außerdem die ausgehandelte HTTP-Version fest und weist darauf hin, wenn nicht einmal HTTP/2 aktiv ist.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.