• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue HTTP3 does not work in NGINX only server

Paulo_o

Basic Pleskian
Server operating system version
Ubuntu 20.04.6 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.61 #5
I have activated the HTTP3, however I can not see "h3" with any browser inspection. Only see "h2" protocol.

Some checks done:



It was not possible to use curl for testing, since our Plesk version does not offer http3 support.
However, using http3 online tests we have got several diferent results, like for example:

domsignal shows couldn't connect over http3
http3check shows http3 active

We have tested several other sites with google chrome inspection. Some of them shows always protocol "h3". So its not related to google chrome, but it seems we have something wrong with the server.

Any sugestion would be appreciated!
Thank you.
 
  • nginx -V shows --with-http_v3_module
  • nc -vuzw 3 domain.com 443 shows "Connection to domain.com 443 port [udp/*] succeeded!"
  • firewall its configured to allow 443/UDP
  • plesk bin http3_pref --enable -nginx shows "HTTP/3 support was activated for nginx. Make sure your firewall allows 443/UDP [in/out]. You can use the Firewall extension to manage HTTP/3 ports in Plesk."
  • Header h3 is Alt-Svc: h3=":443"; ma=86400
  • At the access logs on the server, we may see a very few requests with HTTP3. Sometimes seems using h3, but we never could see it on any browser.
 
I have checked this post. It seems that started to work after 18.0.61 #5 update.
HTTP/3 has been effective from 18.0.61 - https://docs.plesk.com/release-notes/obsidian/change-log/#plesk-18061

Plesk then revoked HTTP/3 on 18.0.61 #3 but only on the Plesk Panel itself - https://docs.plesk.com/release-notes/obsidian/change-log/#plesk-18061-mu3

HTTP/3 is fully functional on domains etc that you're hosting (via Plesk) - IF - you wish to enable it and use it, as it has been since the 18.0.61 release

You can follow all of this, if you read all of this other thread (a 18.0.61 #3 specific reference, is made near the end) Resolved - http/3 supported by plesk?
FWIW you'll also see other config reasons that prevented HTTP/3 being functional in this thread, but you're already passed that stage now (as per your own post #1 in this thread and your HTTP/3 result from HTTP/3 Check )

The 18.0.61 #5 release wasn't relevant to HTTP/3 suddenly becoming functional within Plesk. It was just a timing coincidence (of some of the test results) in the example that you've read in the Resolved - HTTP 3 is not used despite NGINX Only hosting thread
But this its the version we have and the issue remain.
Your issue appears to HTTP/3 browser test results, NOT Plesk HTTP/3 functionality itself - See below
It was not possible to use curl for testing, since our Plesk version does not offer http3 support.
It IS possible to run curl tests and they WILL confirm the true HTTP/3 status of your server, more accurately that various browser tests will do (currently)
However, using http3 online tests we have got several diferent results, like for example:
domsignal shows couldn't connect over http3
http3check shows http3 active
We have tested several other sites with google chrome inspection. Some of them shows always protocol "h3". So its not related to google chrome, but it seems we have something wrong with the server.
You may not have fully grasped the HTTP/3 "browser tests" subtleties yet, but they are referred to in this post: Resolved - HTTP 3 is not used despite NGINX Only hosting Excluding any misconfigs, it's unlikely that you have anything wrong with your server, as you've already got a HTTP/3 result from HTTP/3 Check
Any sugestion would be appreciated!
Thank you.
Please post your Curl test results on here (having previously ensure the Curl release you use, does support HTTP/3)
You can sanitize them, by redacting your domain name. Several examples of this already exist in different threads (some of which are referenced here)
Posts #14 and #15 in Resolved - HTTP 3 is not used despite NGINX Only hosting might assist you, if you're unsure
 
HTTP/3 has been effective from 18.0.61 - https://docs.plesk.com/release-notes/obsidian/change-log/#plesk-18061

Plesk then revoked HTTP/3 on 18.0.61 #3 but only on the Plesk Panel itself - https://docs.plesk.com/release-notes/obsidian/change-log/#plesk-18061-mu3

HTTP/3 is fully functional on domains etc that you're hosting (via Plesk) - IF - you wish to enable it and use it, as it has been since the 18.0.61 release

You can follow all of this, if you read all of this other thread (a 18.0.61 #3 specific reference, is made near the end) Resolved - http/3 supported by plesk?
FWIW you'll also see other config reasons that prevented HTTP/3 being functional in this thread, but you're already passed that stage now (as per your own post #1 in this thread and your HTTP/3 result from HTTP/3 Check )

The 18.0.61 #5 release wasn't relevant to HTTP/3 suddenly becoming functional within Plesk. It was just a timing coincidence (of some of the test results) in the example that you've read in the Resolved - HTTP 3 is not used despite NGINX Only hosting thread

Your issue appears to HTTP/3 browser test results, NOT Plesk HTTP/3 functionality itself - See below

It IS possible to run curl tests and they WILL confirm the true HTTP/3 status of your server, more accurately that various browser tests will do (currently)

You may not have fully grasped the HTTP/3 "browser tests" subtleties yet, but they are referred to in this post: Resolved - HTTP 3 is not used despite NGINX Only hosting Excluding any misconfigs, it's unlikely that you have anything wrong with your server, as you've already got a HTTP/3 result from HTTP/3 Check

Please post your Curl test results on here (having previously ensure the Curl release you use, does support HTTP/3)
You can sanitize them, by redacting your domain name. Several examples of this already exist in different threads (some of which are referenced here)
Posts #14 and #15 in Resolved - HTTP 3 is not used despite NGINX Only hosting might assist you, if you're unsure

@learning_curve Many thanks for your detailed reply.

I have checked several external websites with browser inspection tool (like google, edge and firefox), and some of them always shows "h3" as protocol (after the 1st refresh). This is not hapening with our plesk server.

So, I wonder why with the website we have enabled the http3 (plesk server) I only saw once the "h3", beeing always "h2". Until now we couldn't compare our NGINX configuration with a website that always shows "h3". But I suspect should be something diferent at the server config level.

Since we expect some performance improvement, under the end user point of view, we should have it working better.
 
I have checked several external websites with browser inspection tool (like google, edge and firefox), and some of them always shows "h3" as protocol (after the 1st refresh). This is not hapening with our plesk server.
It appears that unwittingly, you might still be temporarily, 'blinded by HTTP/3 browser tests' but now, with added 'comparison browser tests' too.
Please refer back to all of the previous posts / threads to fully understand the potential for false results...
So, I wonder why with the website we have enabled the http3 (plesk server) I only saw once the "h3", beeing always "h2". Until now we couldn't compare our NGINX configuration with a website that always shows "h3". But I suspect should be something diferent at the server config level.

Since we expect some performance improvement, under the end user point of view, we should have it working better.
Where are your Curl test results that were suggested earlier?
Those are what what will clearly illustrate everything that's already been posted by others (not yourself - so far)
 
I have undestood that its normal some sites show always "h3" and some sites only show "h2", correct?

Please note that on the server access logs we have less than 0,1% lines under HTTP3.0 protocol.

Regarding Curl tests, we are still working, because sometimes we get

curl --http3 https://domain.com -I
HTTP/3 200
server: nginx
date: Sat, 15 Jun 2024 12:09:12 GMT
content-type: text/html; charset=UTF-8
vary: accept-encoding
last-modified: Sat, 15 Jun 2024 12:00:02 GMT
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=15768000; includeSubDomains

however, most times we are just getting the following error

curl --http3 https://domain.com -I
curl: (55) ngtcp2_conn_writev_stream returned error: ERR_DRAINING
 
It appears that unwittingly, you might still be temporarily, 'blinded by HTTP/3 browser tests' but now, with added 'comparison browser tests' too.
Please refer back to all of the previous posts / threads to fully understand the potential for false results...

Where are your Curl test results that were suggested earlier?
Those are what what will clearly illustrate everything that's already been posted by others (not yourself - so far)


We have made several tests with Curl and several Curl versions however, we are still getting the previous errors.

Also, we have tested the following command

openssl s_client -connect yourserver.com:443 -alpn h3

CONNECTED(00000003)
140579260147008:error:14094460:SSL routines:ssl3_read_bytes:reason(1120):../ssl/record/rec_layer_s3.c:1543:SSL alert number 120
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 313 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

The command openssl s_client -connect yourserver.com:443 -alpn h2 works fine.

It seems that something its still not working to get the http3 feature.
 
@learning_curve

We have solved the HTTP3 issue now!

We have changed at the nginx.conf the line worker_processes auto; to worker_processes 1;

Now all the user request trough browser are being done with "h3" protocol. Also the Curl is no longer show any error.

I have understood that to have worker_processes auto; we must set reuseport on the quic port. Meaning that something like listen IP:443 quic reuseport; But plesk its using listen IP:443 quic;

The plesk is generating automaticly the NGINX config without reuseport.

How can I change this?

Thank you.
 
I have undestood that its normal some sites show always "h3" and some sites only show "h2", correct?
Not always... But yes
Apologies for the delay in replying (just returned back from a short vacation!)
~~
curl --http3 https://domain.com -I
curl: (55) ngtcp2_conn_writev_stream returned error: ERR_DRAINING
~~
Also, we have tested the following command
openssl s_client -connect yourserver.com:443 -alpn h3
~~
The command openssl s_client -connect yourserver.com:443 -alpn h2 works fine.
It seems that something its still not working to get the http3 feature.
This is one benefit of testing with Curl (and / or other independent tests e.g. Openssl as per your post)
i.e. Error reports that you can't always see with browser tests only (and all of their own setup variables)
We have solved the HTTP3 issue now!
We have changed at the nginx.conf the line worker_processes auto; to worker_processes 1;
Now all the user request trough browser are being done with "h3" protocol. Also the Curl is no longer show any error.
I have understood that to have worker_processes auto; we must set reuseport on the quic port. Meaning that something like listen IP:443 quic reuseport; But plesk its using listen IP:443 quic; The plesk is generating automaticly the NGINX config without reuseport.
Understood. You've now posted this, both HERE then continued further.
Then even more importantly you've posted HERE which is very helpful for all and/or Plesk too

Happenstance, meant that we had unintentionally, blindsided ourselves (and you) with this, because:
We already had worker_processes values that are numeric, not auto
Plus, we already had these files: /etc/nginx/conf.d/directives.conf that do include ' ~ quic reuseport;' as part of their content
Some time ago, we'd seen this discussed in detail in StackOverflow, so we'd made it into an included item, prior to the Plesk HTTP/3 updates being released
However, you've rectified our 'omissions' now with these latest posts and your posts / other threads too. Appreciated!
How can I change this?
Thank you.
You've already competed this with the 2nd of the links above. Job done!
 
Back
Top