We had to turn off APO because it was caching everything - even members profile pages when logged in (users were seeing page of other members when logged in!)
NOW we are seeing 524 errors - delays - for everything from page editing to page views. MINUTES for a load - even the Cloudflare plugin takes 2-3 minutes to load.
Nothing else has been changed on the site - why would turning off APO cause a 2-3 minute delay?
Sid
Hi Sid,
There’s very little anyone in this community can help in case of a 524 error other than to point you to our community tutorial on the subject, which you can find here: 524.
As far as having to turn APO off because it was caching everything, please make sure your APO installation follow the documented best-practices. APO is meant to cache everything (for up to 30 days), while revalidating and refreshing content within 30 seconds after it is changed.
APO is supposed to bypass requests under certain conditions. One of them is the presence of any query string, except for a few that are used mostly by marketing and analytics (utm_*, fbclid etc.). It is also supposed to bypass requests with certain cookies (please see Query parameters and cached responses · Cloudflare Automatic Platform Optimization docs for a list of cookie prefixes.)
If your developers set any of these cookies, or make use of a (non-marketing or analytics) query string to identify requests for logged-in content, these requests should not be cached. If that’s happening, please open a ticket and post the number here for further investigation.
When I visit my APO test site using a regular Chrome tab, I always get BYPASS (as I’m logged in). So I need to visit using incognito to see the cached response. Now, if your site has other user identification than the cookie set by WordPress, you’d need to talk to your developer about making sure Cloudflare APO has some element (cookie or query string) to make the decision not to cache.
I did raise a issue with CF about APO about it caching what it wasn’t supposed to cache, but it still does it. A large number of people on the s2member forum had the same issue. They stopped using APO,some stopped using Cloudflare!
As to the 524 - maybe its a coincidence, but 90 seconds after we turned it off (we had it on for a few days to see if it still did the cache thing) is when pages started timing out - and ONLY time out on that site. (only site with the CF plugin)
I am not a great believe in coincidence - turning that off was all we did -, but it’s possible something else broke at that same 2 minute interval.
Sid
Oh, and only the domain and subdomains on deadeasyapps.com with WordPress are affected! subdomains without it (only HTML pages) work fine.
Even backup WordPress sub-domains that have never been used and were not touched in over a week also have delay!
Wordpress sites on different domains also load fine.
That is just weird. It would indicate the server is fine, subdomains on the same main domain - that are without WP - are fine, but even old, unused subdomains of the main domain WITH WP crash?
server is not overloaded - less than 5% at max usage of ram and CPU (duel Xeon processors, 36 cores, 128G of RAM, 6TB of SSD drives)
Restarts of Apache, mysql (nariadb) had no effect.
We did yesterday have a domain with an AAAA record and used a redirect rule (beta feature) to redirect a domain to the deadeasyapps.com domain but we removed that)
Sid
APO was probably masking server/WordPress issues that when it’s turned off become apparent. While your site was under APO, in all likelihood there were several plugin/theme/core updates, anyone of which could cause server/WordPress issues.
HTML is a much lighter content, as it’s probably already cached, than PHP/WordPress pages.
All my sites are WordPress sites and have seen many issues over the years caused by a single plugin update. The most recent one being a plugin update that simply removed the trailing slash from all pages!
Troubleshooting WordPress issues is beyond the scope of this Community. If you have APO on and have issues beyond the ones for which I already suggested a possible solution, please feel free to post them here for further consideration.
understand what you say, but to clarify - we cleared ALL caches from CF and APO was off for 24 hours when we did the access tests. WP sites on other domains, same server and IP, and HTML on subdomains of the domain WITH the problem also loaded fast.
Did find a “The storage engine for the table doesn’t support check” on one of the old DB (ran a check on all of them) NO idea why that would be.or what it really means
That may be the root of your problems, and nothing we can troubleshoot, I’m afraid. But here’s a helper: "The storage engine for the table doesn’t support check" - Google Search
Actually no - I discovered that is a WordFence temporary table that sometimes doesn’t get deleted, and the DB check will not delete tables, just flags as an error.
Nice try though, thanks! 
Fixed.
The problem started with a Cloudflare feature under “Rules” called redirect rules.
On direction from someone else helping with another problem, We had set an AAAA record for a domain we wanted to point to an existing domain. We set the IP for the AAAA domain to 100:: and then set a CF “redirect rule” to our main domain deadeasyapps.com.
But the rule was redirecting EVERYTHING at the main domain.We removed the rule and DNS but something somewhere didn’t get the word we had - : even after restarting mysql.we ended up, somehow, with a mysql process with a “redirection request to 100::” THAT locked up mysql, so connections timed out.
We killed that process, shut down mysql, cleared ever cache even opcache and object cache, cleared temp directory, shut down Apache, made sure APO was still off, restarted everything.
No more problem.
Also going to restart the server itself, start clean. All in all we killed another day and pissed off about 100 customers.
Is this Friday the 13th? 
We discussed setting that redirect on one of your client domains. As designed it only should have sent any traffic destined for any URL in the vanity client domain to the base URL of the custom client subdomain. I’m not sure how it could have been implemented in a manner that would have had any effect on your mysql instance.
WE don’t either, but there it was, big as day, I probably should have taken a screen shot, but at that point I was over it. This all started yesterday. Been a long day.
Thanks for your help 
It appears that turning off APO has caused delays and 524 errors on your website. APO was previously caching everything, including members’ profile pages when logged in, which was causing issues. However, after turning off APO, you are now experiencing delays and errors that were not present before.
There could be multiple reasons why turning off APO has caused delays. For example, it is possible that APO was masking an underlying issue on your website, and now that it has been turned off, that issue is causing delays. Additionally, the delay could be caused by a change in server configuration or settings that occurred when APO was turned off.
To resolve the issue, you could try troubleshooting the server and website configuration to identify any potential issues. You could also consider reaching out to your web hosting provider or Cloudflare support for assistance in resolving the issue.
If you actually read the thread, you would know that the problem was NOT
on our site. It was a feature we used on Cloudflare that is beta test mode.
And it is amazing how many people tell us completely different things about APO
and what it does and doesn’t do. Most of them conflicting. All I know is everything
worked when we turned it off, till we tried to use a CF feature to deal with the fact
that none of our 300 clients would be able to use CNAME records to send their
TLD domains of our sites.
Thanks for your help
Sid
In the Following Case Study, the Same Issue Was Faced by Me!
So How I Did You You Can Also Do A Try!
http://www.allminecraftapk.com/
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.