HTTP/3 Deployment Checklist

Deploy HTTP/3 without breaking HTTP/2: open UDP, verify TLS 1.3 and Alt-Svc, test fallback, measure protocol use, and roll back safely in production.

HTTP/3 is an application mapping for the QUIC transport, not a new URL scheme. The practical change is that browsers can carry the same HTTPS requests over QUIC and UDP instead of TCP. RFC 9114 defines the HTTP/3 mapping, while RFC 9000 defines the transport.

The safest production rollout is additive: keep the existing HTTP/2 listener, enable HTTP/3 on the same hostname, expose the same certificate and content, then compare protocol-specific error and latency signals. This checklist covers a single origin behind a reverse proxy or edge service. It does not replace a vendor’s load-balancer runbook.

What must be true before enabling HTTP/3?

Start with four conditions:

1. The origin has a valid certificate for every hostname that clients will request.
2. The edge or server supports HTTP/3 and QUIC version 1.
3. The firewall and load balancer pass the selected UDP port to the HTTP/3 listener.
4. HTTP/2 or HTTP/1.1 remains available for clients that cannot complete a QUIC connection.

HTTP/3 uses the ALPN token h3 during the TLS handshake. RFC 9114, section 3.2 requires QUIC version 1 and TLS 1.3 or later for the HTTP/3 connection, and it requires the server name to be indicated with SNI when a hostname identifies the origin. The TLS 1.3 specification is the cryptographic baseline; HTTP/3 is not a way to run an unencrypted UDP service.

QUIC packets are UDP datagrams. RFC 9000, section 14 says that QUIC packets must not be fragmented at the IP layer and that a path must support a maximum UDP payload of at least 1,200 bytes. A firewall rule that allows TCP 443 but drops UDP 443 is therefore a complete HTTP/3 outage even when the old HTTP/2 path is healthy.

Choose the HTTP/3 endpoint and fallback

Most deployments use UDP 443 on the same hostname as HTTPS. That is a convention, not a protocol requirement: RFC 9114, section 3.1 allows an HTTP/3 server on another UDP port, but an alternative-service advertisement must name its port explicitly. A non-standard port adds firewall, monitoring, and support work, so use it only when the edge product requires it.

An origin can tell an HTTP client that an equivalent HTTP/3 service exists with Alt-Svc. A conservative first advertisement is:

Alt-Svc: h3=":443"; ma=86400

ma=86400 asks a client to keep the advertisement for 24 hours. During a canary, use a shorter lifetime such as 300 seconds so a bad advertisement expires sooner. The exact header syntax and rollout behavior depend on the proxy, but the protocol rule is stable: a client may try the advertised QUIC endpoint and should use a TCP-based HTTP version when QUIC cannot connect.

Keep the fallback path observable. A successful HTTP/2 response does not prove that the browser tried HTTP/3; it may mean that UDP was blocked, the advertisement was absent, or the client does not support HTTP/3. Record the negotiated protocol at the edge, not only the status code at the application.

The browser ecosystem is ready for a fallback-based rollout. MDN’s HTTP/3 glossary describes HTTP/3 as the successor to HTTP/2, using QUIC over UDP and avoiding TCP’s connection-level head-of-line blocking. Chrome’s performance guidance recommends serving resources over HTTP/2 or HTTP/3 and notes that local development and CI often do not support modern HTTP versions. Test a deployed hostname, not only localhost.

Configure the edge or origin

Managed edge

If a CDN terminates TLS, enable HTTP/3 at the edge first. For Cloudflare, the current path is Speed → Settings → Protocol Optimization → HTTP/3. Cloudflare documents HTTP/3 as available on all plans when an SSL certificate is present at its edge; its HTTP/3 guide also describes QUIC’s UDP transport and the dashboard toggle.

After enabling the edge feature, confirm that the origin connection is still governed by the existing policy. The client-to-edge protocol and edge-to-origin protocol are separate. You can serve HTTP/3 to browsers while the edge uses HTTP/2 or HTTP/1.1 to the origin, or enable HTTP/3 on both legs where the platform supports it. Do not assume that an edge setting changed the origin listener.

nginx origin or reverse proxy

For nginx, HTTP/3 support is provided by ngx_http_v3_module. The nginx QUIC documentation says the module is available in nginx 1.25.0 and later, recommends OpenSSL 3.5.1 or later for a QUIC build, and requires TLS 1.3. The minimum shape of a dual-protocol listener is:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http3 on;

    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        proxy_pass http://app;
    }
}

The directive names vary with the nginx release and packaging choice, so validate the installed binary and module before applying a copied configuration. Run nginx -V and check the module’s current documentation. The QUIC page recommends a simple client such as ngtcp2 for an initial server test and notes that browser certificate checks can hide lower-level configuration errors.

reuseport matters when multiple nginx workers accept QUIC traffic. Address validation is available with quic_retry on;. Treat 0-RTT as a separate decision: nginx enables it with ssl_early_data on;, but RFC 9114, section 10.9 warns that HTTP/3 early data can be replayed. Do not allow replay-sensitive actions such as a purchase, password change, or state-changing request solely because a client sent 0-RTT data.

The verification sequence

Run these checks in order. Each step narrows the failure domain before you change another setting.

1. Verify DNS, certificate, and both transports

dig +short A example.com
dig +short AAAA example.com
curl -sS -D- -o /dev/null https://example.com/
curl -sS --http2 -D- -o /dev/null https://example.com/
curl -sS --http3 -D- -o /dev/null https://example.com/

The last command requires a curl build with HTTP/3 support; it is not present in every distribution. If it fails with “unknown option,” use an ngtcp2 client or a browser with a protocol inspector rather than treating that local curl limitation as a server failure. The certificate must match the hostname, and the HTTP/2 request must continue to work before you proceed.

2. Check the advertisement

curl -sS -D- -o /dev/null https://example.com/ \
  | grep -i '^alt-svc:'

The response should advertise h3 and the same UDP port you opened. A stale Alt-Svc value can make a healthy server appear broken to clients that cached yesterday’s endpoint. During a canary, inspect responses from more than one edge point if the CDN publishes region-specific configuration.

3. Check UDP reachability

Use the edge provider’s protocol test or a QUIC-aware client from a network outside the server’s VPC. Test a residential connection and a corporate or VPN connection when those are important audiences. A local UDP probe that never reaches the edge can point to a cloud security group, network ACL, host firewall, load balancer, or intermediate network policy.

QUIC’s address validation limits an unvalidated server to sending no more than three times the bytes it received from a client. That anti-amplification rule is defined in RFC 9000, section 8. It is one reason to inspect handshake failures at the edge and not infer them from application logs: a request may never reach the HTTP layer.

4. Confirm the negotiated protocol in a browser

In Chromium-based browsers, open DevTools, inspect a document or asset request, and add the Protocol column to the Network panel. Look for h3; compare it with an h2 request from a network where UDP is blocked. Firefox and other browsers expose equivalent connection details in their network tooling, although the labels differ by version.

Check more than the HTML document. A page can negotiate HTTP/3 for its main response while a third-party font, image, API, or analytics host uses another protocol. Measure the origin you control and record protocol use by hostname.

What to monitor after the switch

HTTP/3 is a transport change, so the first dashboard should separate transport symptoms from application symptoms:

QUIC connection IDs let a connection survive some client address and port changes. RFC 9000, section 9 therefore warns that systems using the client address for logging or access control must account for address changes. Use a request identifier and authenticated session identity for correlation; do not make the original IP the only key for a long-lived connection.

Compare like with like. HTTP/3 can reduce setup delay and avoid TCP’s connection-level head-of-line blocking, but a small static page on a warm connection may show no meaningful change. Chrome’s modern HTTP guidance calls out multiplexing as the reason to prefer HTTP/2 or HTTP/3 over HTTP/1.1 when an origin serves enough assets. Track p75 and p95 by route, cache status, geography, and protocol for at least one normal traffic cycle.

A rollback plan that does not strand clients

Use a staged rollout:

1. Enable HTTP/3 for an internal hostname or a small traffic slice.
2. Verify certificate, Alt-Svc, UDP reachability, h3 negotiation, and HTTP/2 fallback.
3. Compare protocol-specific errors, latency, resource use, and support tickets.
4. Expand the slice only if the fallback path stays healthy.
5. If the QUIC path regresses, stop advertising h3 and disable the edge listener, but leave HTTP/2 or HTTP/1.1 serving traffic.

Removing Alt-Svc does not instantly erase a client’s cached advertisement. Lower the ma value before a planned migration, and expect clients with an older cached value to retry until it expires. If an edge provider can revoke its advertisement immediately, use that control as well. Keep the TCP path until the HTTP/3 endpoint has been absent for longer than the longest advertisement lifetime.

If a deployment fails only for some networks, do not “fix” it by removing the fallback. A blocked UDP path is an expected condition in some enterprise networks. HTTP/3 should add a faster path, not turn a firewall policy into a site outage. Check the HTTP 421 reference when a shared connection reaches an origin that cannot serve the requested authority, and the HTTP 431 reference when header-size limits surface during protocol testing.

Frequently asked questions

Read next

• Check response headers with the HTTP header inspector.
• Read the HTTP status code reference before mapping transport failures to application responses.
• Review the TLS certificate guide before changing the certificate served by the QUIC listener.

Tags: #http3, #quic, #web-performance, #nginx, #deployment