Search results

I had the same experience. Once I disabled Cloudflare, the errors would go away. I have not tried disabling strict mode. I also saw the OPENSSL error above but it seemed unrelated. I think the errors are still there if I enable medium/high debug level on the server. Actually just confirmed:

I saw other posts saying the above worked for them. The only solution that works for me is defining a new context for the above files and setting it to inaccessible. I have not tried the vhost rewrite rules because they are disabled by Cyberpanel. Wondering what others' experiences are with this.

I did experience the 520 error once recently but I cannot reproduce it, even if I keep refreshing the page.

I added the following to my site .htaccess file but I can still access xlmrpc.php and wp-trackback.php: # Disable xmlrpc and trackback <IfModule mod_rewrite.c> RewriteEngine On RewriteRule ^/(xmlrpc|wp-trackback)\.php - [F,L,NC] </IfModule> What am I missing?

The documentation says not to do that if one has used 'apt install openlitespeed' before. Is it safe?

I cannot see the v1.7.6 update through apt update/upgrade on Ubuntu 20.04 yet. Hope it's coming soon :) Additionally the upgrade documentation page sometimes mentioned 'OpenLiteSpeed' with majuscules when I believe it should just be 'openlitespeed' all lowercase.

I have experienced the exact same thing. I ended up bumping up my server capacity and the errors then went away. My best guess is the server was not able to keep up. Not sure what it was responding to Cloudflare to generate the 520 errors. For the record, I was using a 2 vCPUs / 4GB server on...

The one from the documentation: <?php ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); $conn = new Memcached ; $address = '/tmp/lsmcd/lsmcd.sock' ; // set the address here $port = 0; // set the port $conn->addServer(...

Well I cannot reproduce the issue anymore. Now whatever port I use when the socket is selected does not seem to matter at all (which would make more sense). Any idea why getServerList() reported the port as 11211: for the socket, even though I have it nowhere specified in my node.conf file?

Does it make a difference that I commented out the first line?

I am using a unix socket and the necessary port for LSMCD is still 11211 in my case. 0 is correct for Redis, haven't tried memcached.

Here: https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:lsmcd:configuration ("... a 0 as the second parameter (port).") https://docs.litespeedtech.com/products/lsmcd/configuration/general/ ("... addServer and a 0 as the second parameter (port).")

I resolved part of the Redis error issue. I had two redis servers running with different (conflicting) configs, one running through systemctl and the other one through Docker. But I still saw read error after that. I bumped up the server from 2 vCPUs/4GB to 4 vCPUs/8GB and things look better...

The documentation says to use 0 though, which is incorrect, at least in my case.

I am looking into my redis object cache and it's possible there is an issue there. I switched another site to LSMCD and I am getting much better ajax request times. The site above is also showing intermittent Redis read connection error.

I am experimenting with LSMCD and configure it to use a unix socket: When trying to connect through the LSCache plugin, I tried to set port as 0 as advised in the documentation but that did not work. Somehow setting to the port to 11211 (which is the standard port when not using a unix socket)...

Okay, sounds good. Cloudflare claims they support HTTP/3 though: https://developers.cloudflare.com/http3/ As of February 25, 2020, Cloudflare supports HTTP/3 draft version 27 or is it a different draft than anyone else?

Okay will do. What is the preferred method, password or certificate? I have reinstated Cloudflare as CDN for now, which surprising does not serve HTTP/3 (at least on my sites), even though they pretend they do. I will disable the proxying before filling the ticket. I appreciate your getting...

Here is another screenshot showing a slow static asset (WNH-Logo-menu-bar.png.webp): This does not happen often but I am surprised it happens at all. Here is the first POST request information: URL: https://wednesdaynighthop.com/?wc-ajax=get_refreshed_fragments Here is the second POST...

Here are two snapshots of the same requests. Better case: Not good case: