How to enable HTTP/3: nginx, LiteSpeed, Cloudflare, Apache & Plesk

HTTP/3 is not a single switch. Depending on your stack it lives in a completely different place – and in about half the cases we see, it is already switched on and fails for a different reason: UDP.

First: what actually goes wrong

HTTP/3 runs over QUIC on UDP port 443, not TCP. That is the decisive difference from HTTP/1.1 and HTTP/2. A great many firewalls, security groups and default hosting configurations happily pass TCP/443 while silently dropping UDP/443.

The result looks exactly like the one h3check reports: the site advertises HTTP/3 via Alt-Svc, but no connection is ever established. The server is configured correctly – the packets simply never arrive. So before you touch any server config, check this:

ufw allow 443/udp
# or
firewall-cmd --permanent --add-port=443/udp && firewall-cmd --reload

On cloud platforms, also check the security group or network firewall. AWS, Hetzner Cloud, DigitalOcean and Azure all have their own layer that filters independently of the host firewall.

nginx

HTTP/3 ships with nginx 1.25.0 and later, no third-party module required. Older versions need a patch – if your distribution still ships 1.22, upgrading is the easier path. Run nginx -V and look for --with-http_v3_module.

server {
    listen 443 ssl;
    listen 443 quic reuseport;   # reuseport goes on the port ONCE across your whole config
    listen [::]:443 quic reuseport;

    http2 on;
    http3 on;

    ssl_protocols TLSv1.3;       # QUIC mandates TLS 1.3

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

Two mistakes account for most failures. reuseport appearing in several server blocks stops nginx from starting – it belongs on a given port exactly once in the entire configuration. And a missing always on the header means nginx omits Alt-Svc on error pages and redirects.

LiteSpeed & OpenLiteSpeed

Here HTTP/3 is usually already running – LiteSpeed supported QUIC earlier than anyone else. You can verify it in the WebAdmin console under Listeners → SSL → QUIC and under Server Configuration → Tuning → QUIC. If it says Not Set, the default applies – and the default is on.

If LiteSpeed is running and HTTP/3 still fails, it is almost certainly UDP/443. See above.

Apache

The honest answer: Apache httpd cannot do HTTP/3. mod_h2 gives you HTTP/2 and nothing more. There is no official HTTP/3 module in the mainline branch.

If you want HTTP/3 with Apache in the back, put something in front that speaks QUIC: nginx as a reverse proxy, LiteSpeed instead of Apache, or a CDN such as Cloudflare. The Apache behind it keeps talking HTTP/1.1, which is perfectly fine – the benefit of HTTP/3 is realised between visitor and edge, not behind it.

Cloudflare and other CDNs

On Cloudflare it really is one switch: Dashboard → Speed → Optimization → Protocol Optimization → HTTP/3 (with QUIC). The DNS record has to be proxied (orange cloud) – with "DNS only" traffic bypasses Cloudflare and HTTP/3 never comes into play.

The pleasant side effect: your origin needs no HTTP/3 support at all. Whatever runs behind the edge is invisible to the visitor.

Plesk

Plesk has no HTTP/3 toggle of its own. What matters is the web server underneath:

• nginx as reverse proxy (the Plesk default): add the directives above under Websites & Domains → Apache & nginx Settings → Additional nginx directives. Plesk's nginx has to be recent enough.
• LiteSpeed via the Plesk extension: QUIC is active out of the box, nothing else to do.

Then verify

After every change, restart the service – a plain reload is often not enough when listen directives changed – and re-test with the HTTP/3 check. What matters is that both lines say "YES": "advertised" only means the header is set; only "working" proves a real QUIC connection.

Knowledge  ·  ← Back to the HTTP/3 check