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

Rinart73 · Nov 9, 2022

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

QUIC enabled via GUI on all levels
Using the latest version of Chrome
Using Lets Encrypt certificate
In the settings I specified path to the fullchain certificate and enabled "Chained Certificate" (https://www.litespeedtech.com/suppo...wiki:config:letsencrypt-ssl#setup_ssl_on_lsws)
SSL test passed: https://www.ssllabs.com/ssltest/analyze.html?d=proseosite.com&hideResults=on

Port 443 for UDP is open:

Code:

> firewall-cmd --list-all
  services: cockpit dhcpv6-client http https
  ports: 443/udp

I'm not using Cloudflare

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

Cold-Egg · Nov 11, 2022

It seems Outbound UDP port 443 works but inbound UDP port 443 is not working.

Rinart73 · Nov 11, 2022

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!

Exou · Nov 15, 2022

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 · Nov 16, 2022

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

Exou · Nov 16, 2022

Cold-Egg said:

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

Thanks for this info, I have to try downgrade and I will post when I have tested this. Maybe I have time this weekend to test.

Rinart73 · Nov 21, 2022

Exou said:

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 · Nov 21, 2022

Rinart73 said:

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 · Nov 22, 2022

Rinart73 said:

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.

ratbag359 · Nov 23, 2022

Exou said:

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.

Rinart73 · Nov 24, 2022

Will reverting to 1.7.15 and then upgrading to 1.7.16 reset any of my webadmin or vhosts configs?

Exou · Nov 24, 2022

Rinart73 said:

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.

Rinart73 · Nov 24, 2022

I reverted to 1.7.15 and upgraded to 1.7.16 again. HTTP 3 still doesn't work and https://http3check.net/?host=https://proseosite.com/ still says connection couldn't be established (honestly they could've given more info there).

Cold-Egg · Nov 25, 2022

hi @Rinart73 ,
The tcpdump indicates the inbound UDP 443 is not working, it still seems like a firewall issue somewhere, maybe at the network layer or data center layer.

ratbag359 · Nov 25, 2022

Rinart73 said:

Hi sorry i thought your issue was ipv6 I see it is ipv4 is your host behind a NAT router?
Edit I can nc to you on udp 443.

Cold-Egg · Nov 25, 2022

nc is not pretty accurate in testing the inbound, that's why we put the tcpdumpt method on the document.

Rinart73 · Nov 25, 2022

Cold-Egg said:

I tried completely disabling iptables and firewalld. It didn't solve the issue.

ratbag359 · Nov 25, 2022

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.

Rinart73 · Nov 27, 2022

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.

ratbag359 · Nov 27, 2022

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.

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

New Member

Administrator

New Member

New Member

Administrator

New Member

New Member

New Member

New Member

New Member

New Member

New Member

New Member

Administrator

New Member

Administrator

New Member

New Member

New Member

New Member