🚀 AI-Assisted NGINX HTTP/3 and QUIC Setup

I turned on HTTP/3 for a side project last month and spent forty minutes convinced it was working before I checked the protocol my browser actually negotiated. It was still on HTTP/2. The config looked perfect, nginx -t passed, and the page loaded fine — but the one thing I hadn’t done was open UDP 443 on the firewall, so every client tried QUIC, got nothing, and silently fell back. That’s the whole story of HTTP/3 on NGINX in miniature: the config is the easy part, and AI will draft it competently, but the failure modes live outside the config file where nginx -t can’t see them.

This guide walks through enabling HTTP/3 the way I do it now, using an AI assistant to draft the directives and explain the moving parts, while keeping myself firmly in charge of the firewall, the build, and the verification.

What HTTP/3 actually changes

HTTP/3 runs over QUIC, which runs over UDP, not TCP. That single fact is the source of almost every surprise. Your existing TLS still applies, your routing still applies, but the transport is different, and anything in your stack that assumes “web traffic means TCP 443” — firewalls, security groups, load balancers — needs to learn about UDP 443 too.

The second thing to know is that HTTP/3 is opportunistic. A browser doesn’t start a connection in h3; it connects over HTTP/2, sees an Alt-Svc header advertising h3, and only then tries QUIC on its next visit. If that QUIC attempt fails, it falls back to HTTP/2 without complaint. This is great for resilience and terrible for debugging, because a broken HTTP/3 setup looks exactly like a working site.

Confirm your build supports it first

Before any config, you need an NGINX built with the HTTP/3 module. This has been mainline since 1.25.0, but stock distro packages often lag. I ask the AI to give me the check rather than trusting it:

Give me the command to confirm my installed NGINX was built with HTTP/3 (QUIC) support, and tell me what string to look for in the output.

nginx -V 2>&1 | tr ' ' '\n' | grep -i http_v3
# Look for: --with-http_v3_module

If that comes back empty, no amount of config will help — you need a newer build. This is exactly the kind of claim worth verifying yourself, because an AI will happily draft HTTP/3 directives for a binary that can’t run them.

Drafting the listen directives

Here’s a prompt that gets a solid first draft. Note how specific it is — vague prompts produce vague configs:

Draft an NGINX server block that serves HTTPS over both HTTP/2 (TCP 443) and HTTP/3/QUIC (UDP 443) for example.com. Include the Alt-Svc header to advertise h3, reuse my existing TLS cert paths, and comment each HTTP/3-specific line. Output only the config.

The result, after I read and tightened it:

server {
    # HTTP/2 and HTTP/1.1 over TCP
    listen 443 ssl;
    http2 on;

    # HTTP/3 over QUIC (UDP)
    listen 443 quic reuseport;

    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # QUIC requires TLS 1.3
    ssl_protocols TLSv1.3;

    location / {
        root /var/www/example;

        # Tell clients h3 is available so they upgrade next visit
        add_header Alt-Svc 'h3=":443"; ma=86400' always;
    }
}

A few things to verify in any AI-generated version of this, because they’re commonly wrong:

• reuseport belongs on exactly one listen quic directive per address, not on every server block. Duplicate it and nginx -t complains.
• ssl_protocols TLSv1.3 — QUIC mandates TLS 1.3. If your config still lists older protocols for the TCP listener, that’s fine, but QUIC itself won’t negotiate below 1.3.
• The Alt-Svc header is what advertises h3. Without it, browsers never try QUIC, and you’ve enabled HTTP/3 that nobody uses.

The firewall step AI keeps forgetting

This is the one that cost me forty minutes. The config above is correct and complete, and it still won’t serve a single HTTP/3 request if UDP 443 is blocked. AI assistants draft the config and stop, because the firewall lives outside the file they were asked about. So I make it an explicit follow-up:

# Open UDP 443 for QUIC (ufw example)
sudo ufw allow 443/udp

# On a cloud host, also add UDP 443 to the security group / firewall rule

If you run in AWS, GCP, or behind any managed load balancer, check there too — a security group that only allows TCP 443 will swallow every QUIC packet, and your clients will fall back to HTTP/2 forever without a single error in your logs.

Validate before you reload

The config goes through the same gate as everything else:

sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo nginx -s reload

nginx -t confirms the directives are valid and the module is loaded. It does not — cannot — confirm that QUIC packets reach the box or that a browser successfully negotiated h3. That’s the verification step people skip, and it’s the only one that proves the feature works.

Prove it actually negotiated h3

Don’t trust the page loading. Trust the protocol. The cleanest check is curl with HTTP/3 support, or your browser’s network panel showing h3 in the protocol column:

# Requires a curl built with HTTP/3 support
curl --http3 -I https://example.com
# Look for: HTTP/3 200

# Or confirm the advertisement is present over HTTP/2:
curl -I https://example.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

If curl --http3 returns an HTTP/3 status line, QUIC is genuinely working end to end. If you only see the Alt-Svc header but --http3 fails, the advertisement is fine but the UDP path is broken — go back to the firewall.

Where AI helped and where it didn’t

The AI drafted the listen directives correctly, explained the TLS 1.3 requirement, and reminded me about reuseport when I asked it to review. What it did not do on its own was open UDP 443, check my binary actually had the module, or confirm a real h3 negotiation — and those three things are the entire difference between “HTTP/3 enabled” and “HTTP/3 working.” Treat the config as a knowledgeable first draft and own the parts that live outside the file.

If you want more of these patterns, the AI for NGINX category collects them, the TLS/SSL hardening prompt pairs naturally with a QUIC rollout since both hinge on your TLS config, and the broader prompt library has the reverse-proxy building blocks you’ll layer on top. Draft with AI, validate with nginx -t, and verify the protocol yourself before you call it done.