Enabling HTTP/2 and HTTP/3 for Your Laravel App: A Practical Nginx Guide

Open your Laravel app on a phone with two bars of signal and watch the network waterfall. On HTTP/1.1, the browser opens six TCP connections and queues everything else behind them. Your Vite bundle, your CSS, your fonts, and a dozen images line up single file, and every lost packet stalls its entire connection until TCP retransmits it. On HTTP/2, all of those requests share one connection and interleave cleanly. On HTTP/3, a lost packet delays only the one file it belonged to, and everything else keeps streaming. On a fast office connection the three waterfalls look nearly identical. On a lossy mobile connection they look like three different websites.

That gap is why the protocol under your app deserves an afternoon of your time. Google's original QUIC deployment paper reported an 8% reduction in mean search latency on desktop and a measurable improvement on mobile, with the biggest wins on the slowest connections (Google, SIGCOMM, 2017). Roughly a third of all websites now serve HTTP/3, and every major browser supports it (W3Techs, 2026). Meanwhile plenty of Laravel apps are still quietly serving HTTP/1.1 because nobody ever checked.

This guide covers what each protocol version actually fixed, what that means for a Laravel application specifically, how to verify HTTP/2 is really on, and the full HTTP/3 upgrade path for nginx on Ubuntu 24.04. We'll also cover the Cloudflare shortcut that gets you HTTP/3 with zero origin changes, and we'll be honest about where the gains are real and where they're rounding error.

What Did Each HTTP Version Actually Fix?

Each protocol revision attacked one specific bottleneck. HTTP/2 fixed request queuing at the application layer. HTTP/3 fixed packet loss stalls at the transport layer. Per Cloudflare's traffic data, HTTP/3 already accounts for roughly 30% of human browser traffic on their network (Cloudflare Radar, 2026), so this isn't speculative technology. It's what your visitors' browsers already prefer.

HTTP/1.1: One Request at a Time

HTTP/1.1 allows one outstanding request per connection. Browsers work around this by opening six parallel TCP connections per host, but a typical Laravel page with a JS bundle, CSS, fonts, and images needs far more than six resources. Everything beyond the first six waits in a queue. Each new connection also pays a full TCP and TLS handshake, which costs two to three round trips before a single byte of content moves.

HTTP/2: Multiplexing, With a Catch

HTTP/2 (2015) multiplexes every request over a single TCP connection as independent streams. The six-connection workaround disappears, header compression (HPACK) shrinks repetitive cookie and header data, and the browser can request 40 assets at once without queuing. For asset-heavy pages this was a genuine leap.

The catch is that TCP itself doesn't know about streams. TCP guarantees ordered delivery of one byte sequence, so when a single packet is lost, every stream on the connection stalls until that packet is retransmitted. This is transport-layer head-of-line blocking, and it's exactly the failure mode of lossy networks. Ironically, on a bad connection HTTP/2 can occasionally perform worse than HTTP/1.1, because 1.1's six separate connections meant a lost packet only stalled one sixth of the downloads.

HTTP/3: QUIC Replaces TCP

HTTP/3 (RFC 9114, 2022) keeps HTTP/2's semantics but swaps the transport. QUIC runs over UDP and implements its own reliability, congestion control, and encryption with TLS 1.3 built into the handshake. Three properties matter in practice. First, streams are truly independent: a lost packet delays only the stream it carried. Second, the combined transport and TLS handshake completes in one round trip, and session resumption supports 0-RTT, so a returning visitor's first request rides along with the handshake itself. Third, connections are identified by a connection ID rather than an IP and port pair, so a phone switching from Wi-Fi to cellular keeps its connection alive instead of reconnecting. That's connection migration, and it's a feature TCP simply cannot offer.

HTTP/1.1HTTP/2HTTP/3MultiplexingNo (browsers open ~6 parallel TCP connections)Yes, streams share one TCP connectionYes, independent QUIC streamsHead-of-line blockingYes, per connectionFixed at the HTTP layer, still present at the TCP layerEliminated; loss affects only its own streamTransportTCPTCPQUIC over UDPTLS requirementOptionalRequired in practice (no browser ever implemented cleartext h2c)Mandatory, TLS 1.3 onlyBrowser supportUniversalEffectively universal since 2015Chrome, Edge, Firefox, and Safari all support it

What Does This Mean for a Laravel App Specifically?

The protocol only accelerates the part of the page load it touches: moving bytes across the network. HTTP Archive data shows the median page now ships around 70 requests and over 2 MB of assets (HTTP Archive, 2025), and that asset transfer is where HTTP/2 and HTTP/3 earn their keep. Your PHP execution time doesn't change by a single millisecond.

Let's be specific about where each type of Laravel workload lands.

Asset-heavy pages benefit most. A marketing site, a Filament admin panel, or a Livewire app loading a Vite bundle, a CSS file, web fonts, and a grid of product images is exactly the multiplexing use case. Dozens of parallel resources over one connection, no queuing, and on mobile, loss recovery that doesn't stall the whole page.

API endpoints barely notice. A JSON API serving one request per round trip has nothing to multiplex. Mobile API clients get a small win from QUIC's faster handshake and connection migration, but if your endpoint takes 180ms of PHP time, the protocol is not your problem.

TTFB is still your PHP time. No protocol upgrade fixes a slow Eloquent query or an N+1 problem. If time-to-first-byte is your bottleneck, start with our 20 quick wins for Laravel performance and PHP-FPM tuning before touching the transport layer. In our experience, teams that jump straight to HTTP/3 while running unindexed queries are optimizing the wrong 5% of their load time.

The honest framing: on a low-latency wired connection, upgrading from HTTP/2 to HTTP/3 is usually a marginal, single-digit-percent improvement. On high-latency or lossy mobile networks, it's frequently visible to the naked eye. If your analytics show 60% mobile traffic, this upgrade is worth more to you than to a B2B dashboard used from office fiber.

Is HTTP/2 Actually Enabled on Your Server?

Before chasing HTTP/3, verify the boring prerequisite. HTTP/2 in nginx has been mature for a decade and most modern provisioning tools enable it, yet we still see hand-configured servers negotiating HTTP/1.1 over TLS because a vhost was copied from a 2014 tutorial. Since browsers never implemented cleartext HTTP/2, it only works on your TLS-enabled vhosts, which is one more reason every site should have a certificate (our complete guide to SSL on Deploynix covers that end to end).

The Modern Directive Form

Nginx changed the syntax in 1.25.1. The old form put http2 on the listen line; that form still works but is deprecated and logs a warning. The current form is a standalone directive:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # ... your Laravel root, index, and PHP-FPM location blocks
}

If your config still says listen 443 ssl http2;, it works today, but move to http2 on; when you touch the file next. The old parameter form will eventually be removed.

Verifying It

Three quick checks, from fastest to most thorough:

# Ask curl which protocol it negotiated (expect "2")
curl -sI --http2 -o /dev/null -w '%{http_version}\n' https://example.com

# Confirm the config actually loaded
sudo nginx -T | grep -E 'http2|listen 443'

The third check is your browser. Open DevTools, go to the Network tab, right-click the column headers, and enable the Protocol column. Load your site and look for h2 next to your document and assets. This column becomes your best friend again in the HTTP/3 section, where you're looking for h3.

While you're in the vhost, it's a good moment to review the rest of your server block. Our guide to nginx configs that actually matter for Laravel covers gzip, static caching, and worker tuning, all of which compound with the protocol upgrade.

How Do You Enable HTTP/3 in Nginx on Ubuntu 24.04?

Here's the part that trips people up: Ubuntu 24.04's distro nginx is version 1.24, and QUIC support landed in the 1.25.x line before flowing into the current stable releases. The nginx that apt install nginx gives you on a stock 24.04 box cannot speak HTTP/3 no matter what you put in the config. You need nginx from the official nginx.org repository (or a newer distro line), and the binary must be compiled with the http_v3_module. The official docs live at nginx.org/en/docs/quic.html and are worth a read alongside this section.

The good news: this is a low-risk change. HTTP/3 discovery is advertisement-based, so if QUIC fails for any reason, browsers silently fall back to HTTP/2. You can't take your site down by getting HTTP/3 wrong; the worst case is that nobody uses it.

Step 1: Install Nginx From the Official Repo

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update
sudo apt install nginx

One caution from experience: the nginx.org package lays out configuration differently from Ubuntu's package. It uses /etc/nginx/conf.d/*.conf and has no sites-available / sites-enabled convention. Back up /etc/nginx before upgrading, and be prepared to either add an include /etc/nginx/sites-enabled/*; line to nginx.conf or move your vhosts into conf.d. Do this in a maintenance window the first time.

Step 2: Confirm the Binary Has the Module

nginx -v
# any current nginx.org stable or mainline (1.25+) has QUIC support

nginx -V 2>&1 | grep -o http_v3_module
# http_v3_module

If that grep prints nothing, your binary can't do HTTP/3, full stop. The official nginx.org packages include the module; some third-party builds don't.

Step 3: Add the QUIC Listener and Alt-Svc Header

HTTP/3 runs alongside HTTP/2, not instead of it. Every browser's first visit arrives over TCP and negotiates h2. Your server then advertises HTTP/3 availability with an Alt-Svc response header, and the browser remembers it (for ma seconds, here 24 hours) and uses QUIC for subsequent requests. That's the discovery mechanism, so the header isn't optional decoration. Without it, nobody ever finds your QUIC listener.

server {
    # HTTP/3 over QUIC (UDP)
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # HTTP/2 over TCP (first visits and fallback)
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com;

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

    # QUIC requires TLS 1.3; keep 1.2 for the TCP listener
    ssl_protocols TLSv1.2 TLSv1.3;

    # Advertise HTTP/3 to browsers; "always" includes error responses
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    root /var/www/example.com/current/public;
    index index.php;

    # ... your usual Laravel location blocks
}

Two details deserve emphasis. QUIC mandates TLS 1.3 (RFC 9001), so TLSv1.3 must be in your ssl_protocols line; your existing Let's Encrypt certificates work unchanged. And reuseport may appear on only one server block per address-and-port combination. If you host multiple sites on the server, put reuseport in your default vhost and use plain listen 443 quic; in the others, or nginx will refuse to start with a "duplicate listen options" error. That error appears at nginx -t time, which is exactly why you always test before reloading.

sudo nginx -t && sudo systemctl reload nginx

Step 4: Open UDP 443 in the Firewall

This is the most common reason HTTP/3 "doesn't work" after a textbook-perfect config. QUIC runs over UDP, and your firewall almost certainly allows only TCP on 443. On a UFW-managed server:

sudo ufw allow 443/udp
sudo ufw status

You should see 443/udp ALLOW alongside the existing 443/tcp rule. If a cloud provider firewall or security group sits in front of the box (DigitalOcean Cloud Firewalls, AWS security groups, Hetzner firewalls), add UDP 443 there too. Every layer between the browser and nginx must pass UDP.

Step 5: Verify End to End

# If your curl is built with HTTP/3 support:
curl --http3 -sI https://example.com -o /dev/null -w '%{http_version}\n'
# 3

# Stock Ubuntu curl usually lacks HTTP/3; at minimum confirm the advertisement:
curl -sI https://example.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Then the real-world check: open the site in Chrome or Firefox with the DevTools Protocol column enabled, load the page, and reload it once. The first load shows h2 (that's the discovery visit), and the reload should show h3 on the document and assets. If DevTools stubbornly shows h2 on reloads, the diagnosis order is: Alt-Svc header present, UDP 443 open at every layer, http_v3_module compiled in, and no VPN or corporate proxy on your test machine eating UDP.

Rollback Safety

Worried about shipping this on a production box? Here's the reassuring part. Because discovery happens via Alt-Svc and browsers fall back to HTTP/2 within milliseconds when QUIC doesn't respond, disabling HTTP/3 is as simple as removing the quic listen lines and the Alt-Svc header, then reloading nginx. Visitors who cached the advertisement quietly return to h2. No downtime, no stuck clients, no cache purge. We've found this makes HTTP/3 one of the lowest-risk infrastructure changes you can make: the failure mode is "nothing improved," not "the site broke."

Should You Run HTTP/3 at the Origin or at the CDN Edge?

There are two legitimate places to terminate HTTP/3, and they aren't competing. Cloudflare enabled HTTP/3 by default years ago and now serves it for a very large share of eligible traffic (Cloudflare, 2023), which means a huge fraction of the sites your users visit already do HTTP/3 at the edge with an HTTP/2 origin behind it. That architecture is completely legitimate: browsers talk h3 to the nearest edge node, and the edge talks h2 to your nginx over a warm, long-lived connection. Zero origin changes required.

CapabilityOrigin nginxCDN edge (Cloudflare in front)HTTP/2 to visitorsYes (http2 on;)Yes, by defaultHTTP/3 to visitorsRequires nginx 1.25+, config, and UDP 443 openOne dashboard toggle, zero origin changesEdge-to-origin legNot applicable (direct connection)Typically HTTP/2 over a persistent connectionStatic asset proximityYour server's region onlyHundreds of PoPs near the visitorCached asset TTFBFull round trip to your serverServed from the edge, origin untouchedWho terminates TLSYour serverThe edge (plus a cert on your origin)Effort and riskRepo migration, config, firewallMinutes, trivially reversible

Option 1: HTTP/3 at the Origin

Strengths: No third party in the request path, no extra DNS changes, full control over TLS configuration and QUIC tuning, and end-to-end HTTP/3 for every request including uncached dynamic pages. Your Laravel HTML responses themselves ride QUIC, not just static assets.

Best for: Teams that don't want a proxy in front of their app, apps with strict data-path requirements, latency-sensitive dynamic traffic to a single region, and anyone who values understanding their full stack.

Considerations: You own the nginx.org repo migration, the config-layout differences, and the firewall rule on every server. Your origin is still one physical location, so a visitor in Sydney hitting a server in Frankfurt pays the full round trip regardless of protocol.

Option 2: HTTP/3 at the Cloudflare Edge

Strengths: HTTP/3 for all visitors in about two minutes, with your origin staying on plain HTTP/2. You also pick up edge caching for static assets, which usually moves the performance needle more than the protocol itself, plus DDoS absorption. Distance is the dominant latency factor, and edges are simply closer.

Best for: Anyone already using Cloudflare, teams that want the win without touching servers, and globally distributed audiences hitting a single-region origin. Our Cloudflare with Deploynix guide walks through the full setup including SSL modes.

Considerations: A proxy now sits in the request path, so you'll want correct real-IP restoration for Laravel's rate limiting and logs. The edge-to-origin leg stays h2, which is fine in practice but means "HTTP/3" applies to the visitor-facing half. And you're adding a dependency you don't operate.

Running both is also reasonable: h3 at the edge for visitors, h3 at the origin for the day you route traffic directly. But if you only do one, and Cloudflare is already in front of your site, the edge toggle delivers 90% of the benefit for 2% of the effort.

How Do You Measure Whether It Helped?

Measure on the networks where the protocol matters, or you'll conclude it does nothing. Synthetic benchmarks against localhost or same-datacenter VMs are the classic mistake: with sub-millisecond RTT and zero packet loss, HTTP/1.1, 2, and 3 produce nearly identical numbers, because the problems these protocols solve don't exist on that link. WebPageTest's own documentation recommends testing under realistic mobile profiles precisely because throttled RTT and loss expose the differences that clean lab links hide (WebPageTest Docs, 2025).

A methodology we've found reliable:

1. Pick two or three real pages, not a synthetic endpoint. Your homepage, your heaviest dashboard, and one asset-rich content page.
2. Test before the change. Run WebPageTest with a 4G or 3G mobile profile from a location far from your server, nine runs, take the median. Save the waterfall.
3. Ship HTTP/3, confirm h3 in DevTools, then re-run the identical test. Alt-Svc caching means WebPageTest's repeat-view runs are the ones most likely to use h3.
4. Compare waterfalls, not scores. Look at connection setup time, asset download overlap, and total load time. A Lighthouse performance score can hide a 300ms network win behind unchanged PHP TTFB.
5. Watch real-user data for two weeks. If you collect Core Web Vitals via RUM, segment LCP by connection type. The improvement concentrates in your worst-connected cohort, which averages hide.

Expect an honest result to look like this: TTFB roughly unchanged (that's PHP, remember), first-visit connection setup slightly faster, repeat-visit and lossy-network loads noticeably better, and desktop-on-fiber essentially flat. If you want to understand what your server can do under load once the network layer is sorted, our load test of a $5 server shows the methodology for the capacity side of the equation.

What Are the Gotchas?

A few sharp edges are worth knowing before you flip anything on. None are dealbreakers, but each has cost someone an afternoon.

Some Networks Block QUIC Entirely

Corporate firewalls and some middleboxes drop or block UDP 443, either deliberately (so their inspection appliances can read TLS-over-TCP) or by default-deny policy. Estimates vary, but a persistent single-digit percentage of networks can't complete QUIC connections. This is precisely why the Alt-Svc fallback design matters: those users transparently stay on HTTP/2 and never notice. Don't fight it, and never build anything that assumes h3 is available.

UDP Amplification and Abuse

Any UDP service invites reflection and amplification questions. QUIC's design caps how much a server may send to an unvalidated address (about three times the bytes received), which limits amplification at the protocol level. If your server faces hostile traffic, nginx's quic_retry on; adds an extra address-validation round trip that forces clients to prove they own their source IP before the server commits resources. It costs new connections one RTT, so enable it under attack rather than by default. Standard nginx rate limiting still applies to the requests themselves, exactly as it does over TCP.

WebSockets Stay Where They Are

Running Laravel Reverb? WebSockets bootstrap through an HTTP/1.1 Upgrade (or HTTP/2 extended CONNECT), and the HTTP/3 equivalent, WebTransport, is a different protocol that Reverb doesn't target. In practice your Reverb connections continue negotiating over h1/h2 exactly as before, and that's fine. HTTP/3 on the same vhost doesn't interfere with them. Nothing to change, nothing to worry about.

0-RTT Is Opt-In for a Reason

QUIC session resumption supports 0-RTT, where a returning client sends its first request inside the handshake. Nginx keeps early data off unless you enable ssl_early_data on;, because 0-RTT requests can be replayed by an attacker. If you enable it, ensure replayed GETs are harmless (they should be, if your GETs are idempotent like the HTTP spec assumes). Skipping 0-RTT entirely costs you one round trip on resumption and zero risk. That's a fine trade.

The reuseport Constraint on Multi-Site Servers

Mentioned above, but it bites often enough to repeat: reuseport on the quic listener may appear exactly once per port across your entire config. On a server hosting six sites, five of them need listen 443 quic; without the parameter. nginx -t catches it, which is one more reason to never reload without testing.

How This Works on Deploynix

Every site Deploynix provisions gets nginx with a free Let's Encrypt certificate, and TLS-enabled vhosts ship with HTTP/2 already on using the modern http2 on; directive. So the first half of this guide is a verification exercise for Deploynix users rather than a setup task: open DevTools, confirm h2, done. The same applies whether your server runs on DigitalOcean, Hetzner, Vultr, Linode, AWS, or a custom box.

For HTTP/3 at the origin, the pieces you need are accessible without leaving the dashboard. Firewall rules are manageable per server, so adding the UDP 443 rule is a form field instead of an SSH session, and the vhost configs are editable if you want to add the quic listeners and Alt-Svc header after installing a QUIC-capable nginx build. The nginx.org repo migration itself is still a hands-on step today; it changes a system package, and we'd rather you do that deliberately in a maintenance window than have a platform do it silently.

The path we recommend to most users, though, is the edge route: put Cloudflare in front of your Deploynix site, and your visitors get h3 at the edge with zero origin changes, while your origin keeps its Deploynix-managed HTTP/2 and Let's Encrypt setup untouched. If you're running the load balancer server type, the same logic applies, since the balancer terminates SSL and speaks HTTP/2 to visitors while Cloudflare handles h3 in front. Server monitoring keeps an eye on the origin either way, and the protocol change is invisible to your deploys.

FAQ

Does HTTP/3 require new SSL certificates?

No. QUIC requires TLS 1.3, but your existing certificates work unchanged, including the free Let's Encrypt certificates Deploynix issues. Certificates authenticate your domain regardless of transport. The only TLS-related config change is confirming TLSv1.3 appears in your ssl_protocols directive, which it already does in any modern config.

Will enabling HTTP/3 break anything if it fails?

Practically no. Discovery works through the Alt-Svc header, so browsers try QUIC only after a successful HTTP/2 visit, and they fall back to HTTP/2 within milliseconds if UDP is blocked or the listener misbehaves. The realistic worst case is that HTTP/3 goes unused. Rollback is deleting two listen lines and one header, then reloading nginx.

Why does my Ubuntu 24.04 server refuse the quic directive?

Because the distro ships nginx 1.24, which predates QUIC support in the 1.25.x line. You need nginx from the official nginx.org repository or another QUIC-capable build, compiled with the http_v3_module. Verify with nginx -V 2>&1 | grep http_v3_module; if it prints nothing, no config change will help.

Is HTTP/2 to my origin plus HTTP/3 at Cloudflare a real setup or a hack?

It's a real, widely deployed architecture. Visitors speak h3 to the nearest edge, and the edge maintains warm HTTP/2 connections to your origin, where transport-level loss barely exists on datacenter links. Cloudflare serves an enormous share of the web's HTTP/3 this way (Cloudflare, 2023). Most sites should start here.

How much faster will my Laravel app actually be?

Honest answer: it depends on your audience's networks. Google's QUIC deployment measured around 8% latency improvement on search at internet scale (Google, SIGCOMM, 2017), with larger gains on poor connections. Expect visible improvement for mobile users on asset-heavy pages, near zero for wired API clients, and no change at all to your PHP TTFB.

Where to Go From Here

The protocol stack under your Laravel app is one of those things you configure once and benefit from on every request afterward. Verify HTTP/2 today; it takes one curl command and there's a real chance an old vhost is quietly serving HTTP/1.1. Then pick your HTTP/3 lane based on effort tolerance: the Cloudflare toggle if you want the win this afternoon, or the nginx.org path from Step 1 above if you want it end to end at the origin. Either way the fallback behavior makes it a low-stakes experiment with a real upside for your worst-connected visitors.

A good first check: open DevTools on your production site, enable the Protocol column, and see what your app is actually serving. If the answer surprises you, you now have the complete playbook. And once the transport layer is sorted, the bigger wins usually live one layer up, in the nginx configs covered in the optimization guide linked earlier.