Automated HTTP/3 (QUIC) support via Nginx hybrid alongside Apache

Blue Skies
1

Ubuntu Server LTS Pro 24.04.4 | Webmin 2.641 | Virtualmin 8.1.0 GPL | Apache Webserver 2.4.58 | BIND DNS Server 9.18.39 | MariaDB Database Server 10.11.14 | PHP-FPM Server 8.5.6 | Postfix Mail Server 3.8.6 | Dovecot IMAP / POP3 Server 2.3.21 | Cyrus SASL Authentication Server 2.1.28 | ConfigServer Security & Firewall (CSF) 15.10 | ClamAV Virus Scanning Server 1.4.4 | SSH Server (OpenSSH) 9.6 | OpenSSL 3.0.13 | Certbot 2.9.0

I’m opening this as a feature request for the developers’ awareness rather than expecting an immediate implementation — I fully understand the complexity involved.

Background

The Nextcloud community recently published a comprehensive, well-tested guide (March 2026) on enabling HTTP/3 alongside Apache using a hybrid Apache + Nginx architecture. While written around Nextcloud, the pattern applies equally to any application managed by Virtualmin — WordPress, OpenCart, or any standard LAMP stack:

The architecture in brief

Since Apache has no native HTTP/3 support (architectural limitation, not a missing module), the hybrid approach keeps Apache handling all TCP traffic unchanged, while Nginx (≥ 1.25.0) is added exclusively for UDP/443 (QUIC), forwarding requests to Apache on 127.0.0.1:8080. TCP and UDP do not conflict on the same port. Nothing in the existing Apache configuration changes.

Why this matters for Virtualmin

The manual steps are well-documented. The problem in a Virtualmin environment is that every new Virtual Server automatically gets an Apache VirtualHost — but there is no corresponding automation for the Nginx QUIC config, SSL cert sync, or the internal loopback listener. Every domain requires manual intervention, which defeats the purpose of Virtualmin.

What this proposes

An optional feature that, when enabled, automates per-VirtualHost:

  • Nginx QUIC-only config generation
  • Internal Apache listener on 127.0.0.1:8080
  • SSL certificate path synchronization
  • Alt-Svc header in the Apache VirtualHost

Acknowledged complexity

This is not a quick win — it requires Nginx mainline package management, lifecycle hooks (create, delete, SSL renew), and a system-wide kernel UDP tuning. I’m raising it primarily so it’s on the radar, with the Nextcloud guide as a solid reference implementation.

Thank you for considering it.

Finally, a personal note: Virtualmin has been an exceptional learning experience. The way it is designed — transparent, structured, and exposing the underlying system rather than hiding it — has taught me more about server administration than any other tool I have used. That is rare, and genuinely appreciated. Thank you for building something this good.

2

Hello,

Thanks for your suggestion!

It does seem like a complicated setup for us to provide.

Could you briefly explain the benefits of such a configuration, though?

1 Like
3

Don’t get too carried away with HTTP/3 here. For most sites, solid HTTP/2, proper caching, decent PHP-FPM tuning, optimised images and a database that isn’t having a wobble will make a much bigger difference.

HTTP/3 won’t magically turn a sluggish app into a quick one. It mainly improves the transport layer, connection handling, latency, packet loss and that sort of thing.

It’s a nice bit of kit, especially for mobile users or poor network conditions, but it’s not a silver bullet. If the backend is slow, HTTP/3 just delivers the waiting around slightly more efficiently.

1 Like
4

I would discourage use of two web servers.

If you want to do something that only nginx can do, I recommend you just use nginx.

We absolutely will never ship a GUI for configuring two full-featured web servers at once. There’s no good reason to ever do that.

2 Likes
5

Thank you all for taking the time to look at this — I genuinely appreciate it.

To answer @Ilia’s question: the main benefits I had in mind were reduced latency for mobile users and improved connection handling under packet loss, which QUIC handles better at the transport layer than TCP. That said, @Steini’s point is well taken — HTTP/3 is an incremental transport improvement, not a fix for application-layer slowness. Solid HTTP/2, good caching and tuned PHP-FPM will almost always matter more in practice.

@Joe — understood completely, and thank you for the clear answer. Running two full-featured web servers in parallel is an architectural mess, and I can see why it’s a non-starter from a GUI and maintenance perspective.

My honest motivation for posting this was curiosity more than anything else. Rebuilding an entire server from scratch just to switch to Nginx felt like a mountain to climb, and I’ve grown comfortable with Apache. When I came across the Nextcloud guide showing the hybrid approach, I found the idea interesting and thought it was worth raising — not really expecting it to be implemented, but more so that it was on the radar.

If the right path forward is simply migrating to Nginx, that’s good to know. At least for now, I’ll focus on getting the most out of what I already have.

Thanks again — this kind of direct, experienced feedback is exactly what makes this community valuable.

6

I think most of this gets back to some of the really HUGE sites where these small things can potentially add up. For most of us I’m not sure where the ‘break even’ point would be in terms of the extra overhead/effort vs benefit.

Quick search for Debian support of http3 seems to indicate it is pretty much ‘curl’ command line.

Redhat wants me to sign in for an answer. :frowning:

Basically, for the rest of us, we wait until the packagers decide it is time. :wink:

7

I remember quic on technitium DNS.

Seems cool to do the whole UDP thing.

Apparently it is not as straight forward:

QUIC is not Quick Enough over Fast Internet

Also I think it is rare to have bad network connection even on mobile at least in my country.

maybe on next install I will use nginx instead of apache and have it, but for now I am continueing with apache and http2. Also I dont have heavy traffic websites anyways.

8

It is very rare that adding hops to the connection makes something faster. And, it’s not free, even if it doesn’t hurt performance to add more hops. Memory and CPU usage necessarily goes up when introducing more plumbing between your clients and your applications.

1 Like