HTTP 3/QUIC stopped working, website is now using HTTP 2

#1
I can't pass http3check.net test (https://http3check.net/?host=proseosite.com) and in the Chrome dev console (Network tab) I'm seeing HTTP/2 and not 3. I'm pretty sure that some time ago HTTP 3 was working fine.

Website: proseosite.com
OpenLiteSpeed version:
Code:
> /usr/local/lsws/bin/lshttpd -v
LiteSpeed/1.7.16 Open (BUILD built: Fri May 13 19:00:23 UTC 2022)
        module versions:
        lsquic 3.0.4
        modgzip 1.1
        cache 1.64
        mod_security 1.4
Testing to see who is listening on port 443:
Code:
> netstat -lupn | grep 443
udp        0      0 0.0.0.0:44304           0.0.0.0:*                           475181/openlitespee
udp        0      0 0.0.0.0:443             0.0.0.0:*                           475179/openlitespee
udp        0      0 0.0.0.0:443             0.0.0.0:*                           475179/openlitespee
Testing outgoing connection:
Code:
>  nc -v -u www.google.com 443
Connection to www.google.com (2a00:1450:4017:811::2004) 443 port [udp/https] succeeded!
Testing connection to the server from another machine:
Code:
> nc -z -v -u proseosite.com 443
Connection to proseosite.com (185.205.209.84) 443 port [udp/https] succeeded!
According to instructions there should be some info on incoming data:
Code:
> tcpdump -i eth0 -A -s0 port 443 and udp
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
And nothing happened after that. When I Ctrl+C to exit I got:
0 packets captured
2 packets received by filter
0 packets dropped by kernel
 
Last edited:
#3
But I allowed it via Firewall-CMD and I'm sure that's the app that manages my traffic.
And when I'm testing from another machine I'm getting:
Code:
> nc -z -v proseosite.com 443
Connection to proseosite.com (185.205.209.84) 443 port [tcp/https] succeeded!
> nc -z -v -u proseosite.com 443
Connection to proseosite.com (185.205.209.84) 443 port [udp/https] succeeded!
 
Last edited:

Exou

New Member
#4
I think I have same problem.

I wrote it to cyberpanel forum Openlitespeed not listening UDP 443 on IPv6 - Support and Discussion / Web Server - CyberPanel Community

My problem is that on IPv4 networks I pass HTTP3/QUIC test, but with IPv6 it is not going through. I have checked configs, firewall, updated everything, rebooted whole server. But I cannot figure out why it is not listening UDP 443 port on IPv6 (inbound).

And this was working before(IPv4 and IPv6, tested many times), I just don't know when it stopped working with IPv6.
 

Cold-Egg

Administrator
#5
Hi @Exou , if you can confirm it works before and does not work with the new version, feel free to report the issue to bug@litespeedtech.com.
You can upgrade or downgrade easily with following example command.
Code:
/usr/local/lsws/admin/misc/lsup.sh -v 1.7.16
 
#7
I think I have same problem.
I can't get it to work even on IPv4.
I'm on the last stable version.
In the headers I see QUIC but Chrome dev tools says I'm using HTTP 2:
Code:
alt-svc: h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"
 

Exou

New Member
#8
I can't get it to work even on IPv4.
I'm on the last stable version.
In the headers I see QUIC but Chrome dev tools says I'm using HTTP 2:
Code:
alt-svc: h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"
My problem is fixed.

First I downgraded to 1.7.15, then I just upgraded to latest and seems like it is fixed now.

Try that.
 

Exou

New Member
#9
I can't get it to work even on IPv4.
I'm on the last stable version.
In the headers I see QUIC but Chrome dev tools says I'm using HTTP 2:
Code:
alt-svc: h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"
I also noticed that my browser remembers if it has connect before with HTTP 2, so if you try to troubleshoot this problem try also clear browsers cache.
 
#10
My problem is fixed.

First I downgraded to 1.7.15, then I just upgraded to latest and seems like it is fixed now.

Try that.
Hi my install was a new install of 1.7.16.
I done as you suggested downgrade to 1.7.15 QUIC works on ipv6 and ipv4, Upgraded to 1.7.16 QUIC still working on ipv4 and ipv6.
Thank you.
 
#12
Will reverting to 1.7.15 and then upgrading to 1.7.16 reset any of my webadmin or vhosts configs?
No it should not. At least I didn't have to do any configuration. I think upgrade/downgrade script detects configs and doesn't override them.

But you should still take backup just in case something is not going as planned.
 
#18
Have you asked if your host is blocking udp 443?
with tcpdump -i eth0 -A -s0 port 443 and udp running and the packets are making it to the interface you should see lots of data fill the window, as cold egg said it appears that the packets are been dropped somewhere.
 
#19
I've asked my hosting provider and currently waiting for response.

Code:
sudo ss -tulpn
shows that OpenLiteSpeed listens to port 443.
I've tried to update Rocky Linux to 8.7. It didn't solve the issue. However when I tried to host another website on another hosting with the same vhosts configs and Alma Linux 8.7 HTTP 3 worked fine.
 
#20
If it has these ports listed

Code:
Netid     Local Address:Port     Peer Address:Port
udp     0.0.0.0:443          0.0.0.0:*
tcp     0.0.0.0:80           0.0.0.0:*
tcp     0.0.0.0:443          0.0.0.0:*
This is the start of capture of tcpdump for a incoming request this will show as long as the packets arrive at the host even with firewall set to deny meaning even if your firewall is set to deny you should still receive this output from tcp dump. In my tests tcpdump showed incoming requests with firewall set to deny.
Code:
sudo tcpdump -i enp0s3 -A -s0 port 443 and udp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
06:52:07.735045 IP remoteip.port > hostip.https: UDP, length 1250
Which leads us back to a network issue with your hosting provider or the vps.
 
Top