Random 502 Error

We've been fighting to find the solution to random and frequent 502 Bad Gateway errors on many of our websites on one of our servers. They would generate entries like this in the site's proxy_error_log:

1687991#0: *436031 upstream prematurely closed connection while reading response header from upstream

This occurred on sites with or without Nginx enabled in the Plesk control panel, and with FPM served by Apache, FastCGI served by Apache, but not FPM served by NGINX. This ultimately led us to "upstream" meaning Apache (i.e., an Apache issue).

What fixed it COMPLETELY was us switching Apache's MPM mode from "Event" to "Prefork" (which can be done in the Plesk control panel).

xplanation WHY your "solution" works, is quite simple.

Apache has some MPMs (Multi-Processing Module), the most important of them being

a) Prefork: non-threaded, pre-forking web server

b) Worker: hybrid multi-threaded multi-process web server

c) Event: a variant of the Worker MPM, consuming threads for connections with active processing


In essence, Prefork MPM is the most stable one and should be preferred in general, even though some (minor) performance penalties can be present.

Whenever performance is an issue, the Worker MPM should be preferred, but that is not available on a Plesk instance.

In fact, Plesk compensates by allowing for PHP-FPM, which is an ability to run PHP as a FastCGI process server and address the FastCGI server directly from within Apache (via modules).

Given the

- close relation between the Worker and Event MPM,
- nature of multi-threaded MPMs,
- lack of processing of inactive connections when using Event MPM,
- presence of PHP-FPM on Plesk,

any error on one site can result in (processing) errors on many (or all) sites, when having activated the Event MPM.

And simply the nature of the Event MPM (only threads for connections with active processing) implies that processing errors are leading to problems, which are multiplicated in the end.

In short, not choosing the Event MPM is one option.

The latter naturally means that we have to choose Prefork MPM, since an alternative MPM is not present in Plesk.

However, another alternative solution is present: debugging code that leads to processing errors.

The latter alternative solution is not always a serious option, since many correlated issues can be the root cause of one processing error.

In conclusion, choosing the Prefork MPM is often a safe choice.

  • 0 A felhasználók hasznosnak találták ezt
Hasznosnak találta ezt a választ?

Kapcsolódó cikkek

How to get/reset lost Plesk Administrator password in Plesk for Linux

Login as root.  # plesk bin admin --set-admin-password -passwd '*****' Run the command below...

How to Generate 1 Time Link for Plesk (to login without password)

For security reasons, the command to retrieve a Plesk "admin" password has been removed in Plesk...

Unknown "no_cache" variable nginx

The issue might be caused by outdated custom vhost templates created on 17.5. Plesk 17.8 brings...

How to enable/disable gzip compression in nginx on a Plesk server

Enabling gzip compression for a domain in Plesk Log in to Plesk. Go to Domains >...