502 bad gateway on the /wp-admin panel, goes away after a refresh

I was curious if anyone else had experienced this. Every now and then I refresh my wp-admin panels on my websites to check for traffic stats, comments, etc.

Since moving my main blog over to a pure EasyEngine server, I have noticed this error every now and then. I’ve only seen it a handful of times in the 3-4 days since I migrated to the server and it goes away when I do a refresh.

Are there any log files that I can check when I see this to find out the culprit. Should I restart the ee stack? restart the server? any hints would be created appreciated

i will say that I have two other websites on the same server (2 core 4GB RAM 4GB swap). cpus seem to be at about an 8th usage normally, spiking up to about a quarter when traffic really starts to flow in. swap is rarely hit

I haven’t ever seen this on my other two servers

I was getting 502’s when running --wpredis, version 4 (which is the only one I tested beside latest stable of --wpfc). However I ran it on small gcloud instance with 640mb ram. –wpfc is playing nice for now. Memcached is also being nice, I do not see any reason to use redis over wpfc.

That’s so strange. The blog I was having this tiny issue with was created with --wpfc but again, 2 cores and 4GB of RAM) and would go away without a simple refresh. I hadn’t seen it happen on the front page, just the wp-admin panel, so I’m not sure if any real visitors have faced the issue.

However, I was also having an issue with --wpfc on two Woocommerce sites where things weren’t caching properly. I got the recommendation to switch those to Redis and to use simple cache to handle the page caching and the object caching.

Since switching the Woocommerce sites, I haven’t had any caching issues, all are a hit when I check. So I decided to switch the main blog over to it as well. That, plus the fact that v4 will be using Redis anyway. And since then I haven’t seen a 502 bad gateway error on the main blog.

I think I can do better than this Simple Cache plugin with some modifications to the w3total cache plugin in combination with the default redis plugin. But so far things are running smoothly. Resources are good, haven’t seen any errors but I’m still keeping my eye out.

You should check recommended settings for each setup: Standard WordPress Sites

So, if you are using --wpfc you shouldn’t use any page caching plugin, that part is covered by Nginx helper. Also try to DEFINE the max wp memory limit,
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

That part is for the backend. Also a good idea is to use Heartbeat Control plugin to easily manage the frequency of the WordPress heartbeat API.

…also, if using WooCommerce, do not remove query strings, do not minify (except for html) and, just in case, use WP Bruiser plugin which will cover all the security parts if you are getting many attacks on backend. It’s a powerful plugin, even it seems simple.

Only allow http/https ports in your firewall and w/e EE needs. Also take a look at this:
Better wp-cron using linux’s crontab and try to set it up. Because as far as I know WP cron is running everytime someone visits your website. Don’t know if caching stops it, but anyway it is better to use a real cron. It is easier for your resources big time if you have a lot of visitors.

1 Like

Why in the world would I need to set WordPress’ max memory limit to 512? NGINX is supposed to be easier on RAM than Apache and I’ve barely seen people recommend a max memory limit of 128MB when using Apache.

I have mine set to 256MB by the way.

Except when you install EE with this parameter, it automatically installs W3 Total Cache. When using this flag, the caching part isn’t handled by NGINX Helper (although that app does purge the cache for you, Some of your cache is handled by FastCGI.

That’s why the installer tells you to set two options in W3 Total cache to memcached (object cache and database cache iirc) and to disable two others (page cache and browser cache iirc).

That is interesting as I do keep the wp-admin panel open for a few of my most popular websites. Thanks for that tip.

What’s the reasoning behind this? I haven’t heard this tip before, nor have I heard about this Bruiser security plugin. What does it do that Wordfence doesn’t do?

NP.

Well I am not an expert but I have server status info plugin which tells me about memory usage in the beck-end. Sometimes it jumps to a 100mb. Sometimes is at 2 or 4 or 10mb, depends, and I am running a blog. So when you said that “Sometimes” you get 502, I figured maybe that “sometimes” is when your memory cap gets piked. If you have multiple windows opened it does use more ram, I dunno how much but it does.
512M was just an example. 256 sounds ok, but still it won’t hurt setting it to 512, it is just a limit, it will not reserve that amount from RAM.

As for the page caching I do not see a point in page caching by W3tc if Nginx does that for you, and nginx helper works there. One don’t need another caching. It is redundant, there is no point. That’s why there is --wpfc, --wpredis, -wp --w3tc etc etc.

If using Woo-commerce it can’t function properly without query strings, at least from my experience, so if there is a smoke there is a fire. I had big problems, especially if I used with additional caching. Therefore one should be careful.

(at the moment I am having trouble using separate cache for mobile users… always something with the EE.)

The Bruiser plugin is a much safer option, for me. Wordfence is messing too much with the website. It is heavier too. From my experience neither the Wordfence, ithemesSecurity Pro or w/e is necessary. All you need is a server-side firewall and a light plugin to protect you from spam and protect your login page.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.