HTTP/3 mit QUIC in nginx: aktivieren, prüfen, Fallback sichern

Warum es HTTP/3 überhaupt gibt

HTTP/1.1 und HTTP/2 laufen beide über TCP. TCP garantiert die Reihenfolge aller Pakete – und genau das wird zum Problem, wenn ein Paket unterwegs verloren geht: Alles dahinter wartet, auch Datenströme, die mit dem Verlust nichts zu tun haben. HTTP/2 hat dieses „Head-of-Line-Blocking“ nur auf die Verbindungsebene verschoben, nicht beseitigt.

HTTP/3 setzt deshalb auf QUIC, ein eigenes Transportprotokoll auf Basis von UDP. Die Streams werden einzeln verwaltet, ein verlorenes Paket blockiert nur seinen eigenen Stream. Dazu kommen ein kürzerer Verbindungsaufbau (TLS 1.3 ist eingebaut, nicht aufgesetzt), Verbindungsmigration (Wechsel von WLAN zu Mobilfunk ohne Neuaufbau) und – bewusst abschaltbar – 0-RTT.

Was dein nginx können muss

Zwei Dinge müssen zusammenpassen: Das Modul http_v3 und eine TLS-Bibliothek, die QUIC spricht. Ob beides da ist, sagt der Build-Aufruf deines nginx:

nginx -V 2>&1 | tr ' ' '\n' | grep -E 'nginx/|http_v3|http_v2|openssl'

Erwartet wird eine Version ab 1.25.0 – dort kam HTTP/3 offiziell dazu – und die Zeile --with-http_v3_module. Fehlt sie, hilft kein Konfigurationstrick: Du brauchst ein anderes Paket.

UDP 443: die häufigste Fehlerquelle

HTTP/3 braucht UDP 443 – und in den meisten Setups ist UDP der Port, der nie geöffnet wurde. Symptom: Die Konfiguration ist korrekt, nginx -t ist grün, und trotzdem bleibt der Browser bei HTTP/2. Die Verbindung kommt einfach nie an.

# UFW (Debian)
sudo ufw allow 443/tcp
sudo ufw allow 443/udp        # <-- entscheidend

# nftables (Beispiel, an die eigene Tabelle anpassen)
sudo nft add rule inet filter input udp dport 443 accept

# Docker: der UDP-Port muss separat veroeffentlicht werden
docker run -d -p 443:443/tcp -p 443:443/udp nginx

In docker-compose.yml entsprechend:

ports:
  - "443:443/tcp"
  - "443:443/udp"     # ohne diese Zeile bleibt HTTP/3 im Container unsichtbar

Der Serverblock

Der entscheidende Punkt vorweg: Es wird nichts ersetzt. Der bestehende listen 443 ssl;-Block bleibt genau so, wie er in Teil 2 aussah – dazu kommt ein zweiter Listener auf UDP, die Direktive http3 on; und der Alt-Svc-Header, der den Browsern von HTTP/3 erzählt.

server {
    # QUIC laeuft ueber UDP - eigener Listener, plus TCP wie bisher
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    http3 on;                      # ab nginx 1.25

    server_name pdf.meine.domain;

    ssl_certificate     /etc/ssl/private/pdf.meine.domain_ecc/fullchain.cer;
    ssl_certificate_key /etc/ssl/private/pdf.meine.domain_ecc/pdf.meine.domain.key;

    ssl_protocols TLSv1.2 TLSv1.3;         # HTTP/3 nutzt intern immer TLS 1.3
    ssl_ecdh_curve X25519:prime256v1:secp384r1;

    # Der Hinweis an den Browser: dieselbe Adresse gibt es auch per HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Danach sudo nginx -t && sudo systemctl reload nginx. Ein Neustart ist nicht nötig – der Reload öffnet den UDP-Socket mit.

Die Schrauben im Detail

Für einen funktionierenden Betrieb reichen die vier Zeilen aus dem Serverblock. Die folgenden Direktiven sind für Sonderfälle – und man sollte wissen, welche davon echte Auswirkungen haben.

# Eigene Logdatei mit Protokoll-Kennzeichnung
log_format quic '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                'proto=$server_protocol h3=$http3';

access_log /var/log/nginx/access-h3.log quic;

Prüfen in vier Schritten

Nach dem Reload lässt sich in wenigen Sekunden belegen, ob HTTP/3 wirklich ausgeliefert wird.

# 1) Hat nginx das Modul?
nginx -V 2>&1 | tr ' ' '\n' | grep with-http_v3_module

# 2) Antwortet der Dienst ueberaupt per HTTP/3?
#    (curl muss mit HTTP/3 gebaut sein: curl -V | grep HTTP3)
curl --http3-only -sI https://pdf.meine.domain/ | head -n 1
# HTTP/3 200

# 3) Ist der Fallback-Hinweis gesetzt? Die Antwort kommt hier bewusst per HTTP/2
curl -sI --http2 https://pdf.meine.domain/ | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

# 4) Der Handshake selbst - ALPN und Protokollversion
openssl s_client -quic -connect pdf.meine.domain:443 -alpn h3 < /dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher|ALPN'
# Protocol: QUICv1
# ALPN protocol: h3
# Cipher is TLS_AES_256_GCM_SHA384

Diese vier Ausgaben sind die ganze Wahrheit: Modul vorhanden, QUIC-Verbindung möglich, Fallback angekündigt, ALPN verhandelt. Im Browser ergänzt die Entwicklerwerkzeuge-Ansicht den letzten Beweis – im Reiter „Netzwerk“ steht unter Protokoll dann h3 statt h2.

Warum HTTP/2 bleiben muss

Alt-Svc ist keine Weiterleitung, sondern ein Angebot: „Dieselbe Ressource gibt es auch unter dieser Adresse per HTTP/3.“ Der Browser entscheidet. Deshalb sind vier Dinge wichtig:

Zusammenspiel mit acme.sh

Die gute Nachricht: Für HTTP/3 brauchst du kein eigenes Zertifikat. QUIC nutzt dasselbe ssl_certificate wie der TCP-Listener – das ECC-Zertifikat aus Teil 2 gilt also für beide Wege. Auch die Erneuerung ändert sich nicht: acme.sh stellt neu aus und ruft --reloadcmd, nginx lädt neu, der UDP-Socket bekommt das neue Zertifikat mit.

Drei Punkte sind dennoch erwähnenswert:

• Kein Port 80 mehr im Spiel: Für die Ausstellung selbst ändert HTTP/3 nichts. Wer aber ohnehin auf die DNS-Challenge umsteigt, kann Port 80 ganz schließen – HTTP/3 braucht ihn nicht.
• TLS 1.3 ist Pflicht: Steht in ssl_protocols nur TLSv1.2, funktioniert HTTP/2 weiter, HTTP/3 aber nicht. Der Listener ist dann still tot – es gibt keine Fehlermeldung, nur kein h3.
• 0-RTT und Session-Tickets: In Teil 2 haben wir ssl_session_tickets off gesetzt – für Forward Secrecy. 0-RTT („ssl_early_data“) braucht aber genau diese Tickets, um eine frühere Sitzung fortzusetzen.

Was es wirklich bringt – und was nicht

HTTP/3 ist kein allgemeiner Turbo. Die ehrliche Einordnung: Auf einer guten Verbindung mit niedriger Latenz misst man kaum einen Unterschied, weil der Flaschenhals dort die Serverantwort ist. Der Gewinn entsteht dort, wo Verbindungen schlecht sind – Mobilfunk, WLAN mit Verlusten, hohe Paketumlaufzeiten.

# Latenz-Vergleich derselben URL, einmal h2, einmal h3-only
curl -o /dev/null -s -w 'h2: %{http_version} appconnect=%{time_appconnect}s ttfb=%{time_starttransfer}s\n' \
     --http2 https://pdf.meine.domain/
curl -o /dev/null -s -w 'h3: %{http_version} appconnect=%{time_appconnect}s ttfb=%{time_starttransfer}s\n' \
     --http3-only https://pdf.meine.domain/

# Bei viel Durchsatz: UDP-Puffer des Kernels anheben (Werte in /etc/sysctl.d/)
# net.core.rmem_max = 26214400
# net.core.wmem_max = 26214400

Wenn es schiefgeht

Gefahrlos einführen

Häufige Fragen (FAQ)

Fazit

HTTP/3 ist keine Revolution, sondern eine Ergänzung: ein zweiter Transportweg über UDP, der dort gewinnt, wo TCP nervt – Mobilfunk, Verluste, Netzwechsel. Technisch ist der Aufwand klein, weil die Zertifikate und die TLS-Einstellungen der ersten beiden Teile unverändert weiterverwendet werden. Gefährlich ist nur ein Punkt: zu glauben, es funktioniere, weil die Konfiguration grün ist.

Deshalb ist der wichtigste Teil dieses Artikels nicht der Serverblock, sondern die Prüfung – vier Befehle, die zeigen, ob QUIC wirklich verhandelt wird, und ein UDP-Port, der in den meisten Setups vergessen wird.