HTTP/3 and QUIC Setup

HTTP/3 is the latest version of the HTTP protocol, built on QUIC (a UDP-based transport). It improves page load times: especially on mobile or unreliable connections: by eliminating head-of-line blocking and reducing connection setup time.

LiteSpeed supports HTTP/3 natively. No additional modules needed.

Prerequisites

• LiteSpeed Web Server (standard on every RemarkableCloud managed VPS)
• A valid SSL certificate on the domain (HTTP/3 requires HTTPS)
• Port 443 UDP open in the firewall (in addition to TCP 443)

Opening UDP port 443

By default, firewalls only open TCP 443. HTTP/3 uses UDP 443. Open it:

# CSF firewall
csf -a UDP_IN 443
# Or edit /etc/csf/csf.conf: add 443 to UDP_IN and UDP_OUT, then restart CSF
csf -r

# iptables directly
iptables -I INPUT -p udp --dport 443 -j ACCEPT

Enabling HTTP/3 in LiteSpeed WebAdmin

1. Open the WebAdmin console at https://YOUR_IP:7080
2. Go to Configuration → Listeners → Default (HTTPS) → Edit
3. Find QUIC section
4. Set Enable QUIC to Yes
5. Save and Graceful Restart LiteSpeed

Enabling HTTP/3 per virtual host (cPanel)

For cPanel servers, LiteSpeed manages virtual hosts per account. Enable QUIC at the server level and it applies to all domains:

1. WebAdmin → Server → General → HTTP/3 (QUIC)
2. Set to Enabled
3. Save and restart

Verifying HTTP/3 is active

Use Chrome DevTools → Network tab → Protocol column. HTTP/3 connections show as h3.

Or from the command line:

curl -I --http3 https://yourdomain.com
# Should show: HTTP/3 200

Or use an online checker: http3check.net

The Alt-Svc header

LiteSpeed automatically adds the Alt-Svc header to responses, advertising HTTP/3 support to browsers:

alt-svc: h3=":443"; ma=2592000

On the first visit, browsers use HTTP/2. When they see this header, they upgrade to HTTP/3 on subsequent requests (or the next visit). The ma=2592000 value means the browser caches this for 30 days.

Troubleshooting: Alt-Svc present but no h3 connections

The most common failure mode is silent: LiteSpeed advertises HTTP/3, the browser tries QUIC, the UDP packets go nowhere, and the browser falls back to HTTP/2 without any error. Your site works, so nothing looks broken, but you never get the protocol you enabled. Check in this order:

1. UDP 443 at every layer. The server firewall is only the first hop. If there is a provider-level firewall or security group in front of the server, UDP 443 must be open there too. Confirm the server is actually listening:

ss -ulnp | grep ':443'
# Expect a litespeed (lshttpd) process bound to UDP 443

2. A CDN or proxy in front of the domain. Cloudflare and similar CDNs terminate connections themselves. The browser negotiates HTTP/3 with the CDN edge, not with your LiteSpeed server, so DevTools can show h3 while your origin never sees a QUIC packet. To test your own server directly, use a hostname that bypasses the proxy.

3. QUIC disabled per listener. The server-level switch and the listener-level switch are independent. If the HTTPS listener has Enable QUIC set to No, the server-level setting never applies to it.

0-RTT and connection migration

Two QUIC behaviors matter in practice and are easy to miss in benchmarks:

0-RTT resumption. A returning visitor’s browser can send the first HTTP request in the very first packet, before the handshake completes. Repeat visits skip the round trips that TCP and TLS normally spend before any content moves. This is why HTTP/3 gains show up more on second page views than on cold first loads.

Connection migration. A QUIC connection is identified by a connection ID, not by the IP and port pair. When a phone moves from Wi-Fi to mobile data mid-session, the connection survives the network change instead of resetting. On TCP, that same handoff kills the connection and every in-flight request with it.

WordPress and LSCache

HTTP/3 works at the protocol layer and needs nothing from WordPress. But the combination with LSCache is where LiteSpeed servers pull ahead: a cache hit served over an established QUIC connection skips PHP entirely and the transport round trips at the same time. If you run WordPress on this server, enable the LiteSpeed Cache plugin alongside HTTP/3; each covers a different part of the load time.

Performance expectations

HTTP/3 improvements are most noticeable:

• On mobile networks: high latency, packet loss → QUIC’s multiplexing helps significantly
• On first page load: QUIC reduces the number of round trips to establish a connection
• On pages with many resources: QUIC eliminates head-of-line blocking between requests

For users on fast wired connections, the difference is minimal. For mobile users, HTTP/3 can reduce load time by 20-30%.

Related

• LiteSpeed overview: architecture and how it compares with Apache
• WebAdmin console basics
• Blog: LiteSpeed vs Nginx covers where HTTP/3 support differs between the two servers