How to: NGINX with QUIC/HTTP3 

Let me know if you run into any issues! Good luck with that 😄

@@brconsultingsrl Thank you so much for your response and offer of assistance. I successfully installed Nginx by following all the steps you used. However, I cannot access my webserver using my domain name. Localhost loads my page but my domain doesn't. I configured DNS with my public IP and yet. Checking for further tip

I was able to replicate your steps all everything works as you showed us but H3 does not display when I select >> Network >> Protocol under developer tools. It still resort to H2. However, the header shows that it does support H3 just as in your case. I discovered that the issue is that OpenSSL doesnt support QUIC for H3 users at the moment and Nginx recommends the following libraries: BoringSSL, quicTLS, and LibreSSL.

@@ezekielndubisi541 Hi Ezekiel. A few questions: - What browsers are you testing this on? - What NGINX Version are you running, did you install the one provided in the NGINX Linux Repositories? - Are you using an FQDN? - Is the SSL Certificate valid for that FQDN? Bear in mind HTTP3/QUIC will not be "fully" enabled on first load (only on second page refresh), as the first packets are transferred through HTTP1.1/HTTP2 until the QUIC Headers are read by the browser. Current known behavior is: Initial Page load is on HTTP2 (1.1 if HTTP2 not enabled), next page reloads are all in HTTP3 if QUIC port functional.

@@ezekielndubisi541 I just spent 2 days trying to make this work and I finally RTFM lol. No, it does not work for me either and I'm guessing OpenSSL is the reason why.

QUIC will not work properly with self-signed certificates (may be intentional and part of the standard). You need an actual legitimate SSL cert from an entity like Let's Encrypt.

Hey, I'm not entirely sure but I believe I tried it with a self-signed cert and it didn't work. Feel free to test it out but it might not work.

It's not necessary, just doing it in the video for whoever is watching in the event they might forget to exec the command as root/sudo. Regards, Dylan

i got error after updating the conf file, i access my site got security policy called HTTP Strict Transport Security (HSTS), ssl i use letsencrypt before using the http3

The video is based on the official nginx docs, and trial and error, so it includes many things from the docs. If you want to build NGINX from the source-code (which our video clearly doesn't include) you should check the official documentation! Otherwise it's pretty much the same, ymmv based on what settings you need for your own use cases. Cheers, -D

That is most likely a server block issue, QUIC/HTTP3 should not affect server block direction/redirection any more than HTTP2 would, so it's likely unrelated. Also, don't test in production. Edit: Feel free to share the config, I can lend a hand. Also, I've left some NGINX Reverse Proxy snippets in the description, might be useful for you.

@@dblanqueI've given it another go and I still have the same issue, my modsecurity logs shows that a host header was never sent by the client (puzzling) and all HTTP/3 request are being sent to the default_server block instead of the correct server block.

@@dblanque found the issue, it was indeed a server block configuration issue I had to specify a listen quic and listen ssl directive for each server block but I'm still seeing empty/missing host headers, is that normal? ModSecurity doesn't like empty host headers and will try and block the request.

@@jacksoncremean1664 Awesome :) Yes, listen quic has to be specified per block, what needs to be specified only once is the reuseport socket option. As for the headers, I left snippets on the desc but you'll basically have to add them per each server block root location. Edit: Empty headers is not normal.

​@@dblanqueI should clarify, I mean the host header is missing and not empty, I group these together in my mind. I don't think it's a header config issue, I've tried your code snippets and they didn't fix the host header missing in HTTP/3 requests (Which I didn't expect them to). ModSecurity is running on my reverse proxy, I won't be able to use ModSecurity CRS properly since all my rule exclusions depend on host headers. Maybe it's a bug in Nginx or ModSecurity that's somehow stripping the host header?