HTTP/2 & HTTP/3 Not Enabled? How to Turn Them On Properly

A PageSpeed Insights report flags "does not use HTTP/2" and you're not sure why, because you're sure you've got SSL installed and everything looks modern. This one trips people up because HTTP/2 support depends on your web server's configuration, not just having HTTPS active. Here's how to check what's actually being served, turn on HTTP/2 wherever you're hosted, and layer HTTP/3 on top with Cloudflare.

Symptom: Your Site Is Stuck on HTTP/1.1

You'll usually spot this one of three ways:

• A speed-test tool (PageSpeed Insights, GTmetrix, WebPageTest) reports the page isn't using HTTP/2.
• Browser DevTools → Network tab → right-click the column header → enable Protocol → it shows http/1.1 instead of h2 or h3.
• A client asks why competitor sites "load instantly" and yours doesn't, even though your TTFB looks fine.

HTTP/2 matters because it multiplexes many requests over a single connection, so the browser isn't queuing up CSS, JS, and image requests one at a time. HTTP/3 goes a step further and drops TCP entirely in favor of QUIC over UDP, which cuts connection setup time and avoids head-of-line blocking on lossy connections (mobile networks especially).

Quick Way to Check What You're Actually Serving

Skip the browser guesswork and ask the server directly:

curl -Iso /dev/null -w '%{http_version}\n' --http2 https://yourdomain.com

A result of 2 means HTTP/2 is live. If it prints 1.1 even with --http2 forced, the server isn't offering it during the TLS handshake (ALPN negotiation), which is the real root cause almost every time — not a DNS or Cloudflare setting.

Cause: It Depends on Where You're Hosted

Shared/managed cPanel hosting on LiteSpeed

If your account runs on LiteSpeed Web Server (most Getwebup shared plans do), HTTP/2 is on by default for any domain with a valid SSL certificate — you don't flip a switch for it. If curl still shows HTTP/1.1, the actual cause is almost always one of these:

• AutoSSL hasn't issued a certificate yet, or it's expired — HTTP/2 requires TLS, so without a valid cert LiteSpeed falls back silently.
• You're testing the non-HTTPS URL. HTTP/2 only negotiates over https://; plain http:// traffic stays on 1.1 by spec.
• A CDN or proxy in front of the site (Cloudflare set to "Flexible" SSL, for example) is terminating TLS itself and talking HTTP/1.1 to your origin — check the CDN side too.

cPanel on Apache with EasyApache 4

Apache needs the mod_http2 module compiled in, and it only works cleanly with the MPM Event handler — not mpm_prefork, which most cPanel installs default to when using suPHP or DSO as the PHP handler.

1. In WHM, go to EasyApache 4.
2. Under Apache MPM, confirm MPM Event is selected (switching from prefork means your PHP handler needs to be PHP-FPM — DSO and suPHP aren't compatible with Event MPM).
3. Under Apache Modules, search for http2 and make sure it's checked.
4. Click Review, then Provision to rebuild Apache.

This is the one that catches people out: switching MPM without switching the PHP handler to FPM first will take the site down, so make that change on a quiet window and check error_log immediately after.

Self-managed Nginx on a VPS

Nginx has supported HTTP/2 since 1.9.5, but you have to declare it explicitly on the listen directive:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name yourdomain.com;
    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ...
}

Test and reload rather than restarting outright, so you don't drop live connections:

sudo nginx -t
sudo systemctl reload nginx

If nginx -t throws unknown directive "http2", your build doesn't have the module — check with nginx -V 2>&1 | grep -o with-http_v2_module. Stock Nginx packages from most distro repos include it; only custom-compiled builds tend to miss it.

Layering On HTTP/3 (QUIC)

HTTP/3 is newer and, for most Getwebup customers, the practical path is Cloudflare rather than configuring QUIC directly on the origin server (Nginx's QUIC support is still marked experimental in mainline builds, and cPanel/LiteSpeed doesn't expose it as a toggle yet).

1. In the Cloudflare dashboard, go to Network.
2. Toggle HTTP/3 (with QUIC) to on.
3. Make sure your VPS firewall or provider-level firewall allows outbound/inbound UDP 443 — QUIC runs over UDP, and a firewall that only opens TCP 443 will silently force browsers back to HTTP/2 with no error shown anywhere.

Because Cloudflare terminates TLS and speaks HTTP/3 to the visitor, then proxies to your origin over HTTP/1.1 or HTTP/2, your origin server's protocol support barely matters here — this is the fastest win if you're already orange-clouded through Cloudflare.

Fix: Verifying It Actually Worked

After making any of the changes above, re-run the curl check from earlier, or open DevTools → Network, reload with cache disabled, and look at the Protocol column for h2 or h3. Test from an actual mobile connection too — some corporate and hotel networks block UDP outright, which will make HTTP/3 silently fall back to HTTP/2 for those visitors even when your server is configured correctly. That's expected behavior, not a bug on your end.

Prevention

• Renew AutoSSL or Let's Encrypt certificates before they lapse — a gap in SSL coverage takes HTTP/2 down with it, even though the symptom looks like a caching or speed issue.
• Re-check your Apache modules after every EasyApache 4 rebuild or WHM update; profile changes have been known to reset MPM/module selections.
• When writing new firewall rules on a VPS (UFW, CSF, or a cloud security group), explicitly allow 443/udp alongside 443/tcp if you're running HTTP/3 — it's easy to only think in TCP terms and lock QUIC out by accident.
• If you manage the CDN and origin separately, keep the SSL mode set to Full (strict) rather than Flexible — Flexible mode terminates TLS at Cloudflare and talks HTTP/1.1 in the clear to your origin, which caps what protocol your origin side reports even if the edge is fine.