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.
