Search results

Just do /usr/local/lsws/admin/misc/lsup.sh -f -v 5.2.3 to get the latest build of 5.2.3 .

We had lost a few clients to varnish based cache solutions a while ago, and we have got them back because LSCache is much better.

It was a lie and it was done a few years ago. before our cache solution getting ready. basically, it compares non-cache pages vs blindly cached pages in varnish.

Please create a ticket with temp root access if available. we will take care of the bug with FCGI backend, even though, it is not the recommended communicating protocol between litespeed and php. We wont let any BUG slipping through.

Have done some test through root access from your support ticket with cPanel. we found that the IP fails QUIC cannot send UDP packet back to client. I did tcpdump on both end. the client can see UDP packet from the IP with working QUIC, but cannot get packet from IP fails. iptables looks fine...

https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:wordpress-protection

the brute force request going through Railgun, LSWS throttle it, Railgun detects that request timed out, Railgun failed the request, the client sending the abuse request see a failure. That's all suppose to happen in this setup. It IS the desire effect of this feature. Only if the throttle...

that's as expected, as all traffic proxy through railgun, LSWS does not talk to the abusive client IP directly. However, only request for the specific client IP is throttled. other visitors through railgun wont be affected.

Please update to the latest build of 5.2.3 with command /usr/local/lsws/admin/misc/lsup.sh -f -v 5.2.3 the cloudflare IP is not the IP being throttled. the log message has been updated with the correct IP.

the frontend proxy should send "X-Forwarded-Proto: https", and litespeed backend will treated it as HTTPS connections. the redirect to http:// ... is like a configuration bug in the backend, if the site should be served with HTTPS.

tcpdump -i eth0 udp and host 127.0.0.1 and port 9445 you need to replace eth0 with the NIC name showing in "ifconfig".

I think there is a UDP connectivity issue, can you use tcpdump on the server side to check if UDP packet can go through reach 177.11.48.56.

netstat -anup | grep 443 make sure 177.11.48.56 is there.

please check netstat, see if the IP for https://classificadospatrocinio.com.br/ has been listened on for UDP. make sure the site is not going through another frontend proxy.

unfortunately, no. the binary will check the license update expire time and its own build time.

you can compile from source with following patch diff --git a/src/spdy/h2connection.cpp b/src/spdy/h2connection.cpp index 99bf72f81..45cb045e6 100644 --- a/src/spdy/h2connection.cpp +++ b/src/spdy/h2connection.cpp @@ -1226,7 +1226,7 @@ int H2Connection::sendSettingsFrame() {...

Not possible now, but it is on our to-do list.

maybe you have `IncludesNOEXEC` enabled http://httpd.apache.org/docs/current/mod/core.html#options

port 80 is likely another web server, you cannot use litemage with that, have to install LSWS on port 80/443, replace the other web server.

Please turn on debug logging then reproduce the problem.