Website Intermittently Returns 502 Bad Gateway Errors on Virtualmin

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu 24.04 LTS
Webmin version 2.303
Virtualmin version 7.8-2
Webserver version Apache 2.4.58
Related packages PHP 8.3, PHP-FPM 8.3, MariaDB 10.11

I’m currently dealing with an intermittent 502 Bad Gateway problem on one of the websites hosted through Virtualmin. The website loads normally most of the time, but occasionally a page request fails with a 502 response instead of returning the expected content. What makes this difficult to troubleshoot is that the failure is not consistent enough to reproduce on every request. I can refresh the same page several times and get a normal response, and then without making any change to the website, another request may suddenly return the gateway error. The problem seems more noticeable when the website is handling dynamic PHP requests rather than when simply serving static files, although I have not yet been able to establish exactly what triggers the failure. There are no obvious application-level errors displayed to the visitor, so from the browser it simply looks as though the web server temporarily cannot communicate with the backend responsible for processing the request. I am trying to determine whether this behavior is related to the way Virtualmin is configuring the website’s PHP environment and webserver communication, rather than being an issue within the website’s application code itself.

I have already checked the website configuration in Virtualmin and confirmed that the virtual server is active and that the domain resolves correctly to the server. The website can serve normal pages successfully, which makes me hesitant to treat this as a basic DNS or virtual-host configuration problem. I have also restarted the relevant web services during troubleshooting, and the website works again afterward, but the intermittent 502 behavior eventually returns. Because restarting services only appears to provide temporary relief, I do not want to keep using that as a workaround without understanding what is actually causing the backend request to fail. I am particularly interested in determining whether the PHP process handling the request is becoming unavailable for short periods, reaching a process or connection limit, or otherwise failing to respond within the time expected by the webserver. I have looked through the available logs but have not yet found one clear message that consistently appears at the same time as every 502 response. If there is a specific Virtualmin or Webmin log location that should be checked first for this type of intermittent gateway error, I would appreciate guidance on what entries or timestamps I should compare with the failed requests.

The issue is especially noticeable when the website performs operations that require PHP to process a request rather than simply returning a cached or static resource. For example, a visitor can sometimes open the website normally and navigate through several pages without any problem, but a subsequent dynamic request may fail and display the 502 error. After waiting briefly or refreshing the request, the same page can become available again without any change to the URL or application data. This makes me suspect that something in the server-side request chain is temporarily unavailable, but I am not sure whether the correct place to investigate is the webserver, PHP handler, or the limits configured for the virtual server. I have avoided making several unrelated configuration changes at once because I want to isolate the actual cause instead of accidentally masking the problem. I would like to know whether Virtualmin has recommended settings or diagnostic commands for checking the health and availability of the PHP backend associated with a particular virtual server. It would also be helpful to understand whether a 502 generated in this situation should normally leave a corresponding entry in the webserver error log, PHP log, or another system log, because correlating those records with the exact time of a failed browser request may reveal which component is terminating or refusing the connection.

Another thing I am trying to establish is whether the problem could be related to resource or process handling on the server. The website does not necessarily fail completely when the 502 occurs; instead, the error appears to affect individual requests and then the site can return to normal behavior. Because of that pattern, I am wondering whether the PHP handler could be temporarily exhausting an available worker, hitting a configured process limit, or taking longer than the webserver is willing to wait for a response. I have not changed the website code specifically to work around the issue because I want to first confirm whether the server environment is reporting a corresponding condition. I am also interested in whether Virtualmin’s per-domain PHP configuration can differ from the global PHP configuration in a way that would cause only one virtual server to experience this behavior. If there are commands or Virtualmin interface pages that can show the currently active PHP version, handler mode, process limits, timeout values, or other relevant settings for the affected domain, I would appreciate recommendations for what information should be collected. My main goal is to identify the component responsible for the failed request before changing server-wide settings that could potentially affect the other virtual servers hosted on the machine.

For troubleshooting purposes, I am trying to collect information from the exact moment a 502 response occurs rather than relying only on the fact that the page eventually works again. I can reproduce the issue occasionally by using the website normally and monitoring the requests, but because it is intermittent, I have not been able to create a simple sequence that causes it every time. I would therefore like to compare the webserver error log, PHP-related logs, and system information around the timestamp of a failed request. I am also interested in knowing whether Virtualmin or Webmin provides any built-in diagnostic information that can show whether the virtual server’s PHP service was available when the request failed. If there is a recommended way to distinguish a backend connection failure from a PHP timeout or resource exhaustion condition, that would help narrow the investigation considerably. I am including the current system information below because I understand that the exact Webmin, Virtualmin, webserver, operating-system, and PHP-related package versions can be important when diagnosing this type of issue. I would prefer to provide the relevant version information up front so that anyone familiar with a similar Virtualmin configuration can tell me whether there are known configuration considerations or compatibility issues I should investigate.

I would appreciate advice on the best way to diagnose this as a single request-handling problem from the Virtualmin side. In particular, I want to understand what evidence I should collect when the next 502 response occurs and which logs should be checked first to determine whether Apache is unable to communicate with PHP-FPM or whether PHP itself is failing to respond correctly. Since the same website can work normally immediately before and after the error, I am trying to avoid assuming that the application is responsible without confirming what the server reports at the exact time of failure. If there are specific Virtualmin settings, Apache directives, PHP-FPM configuration values, or diagnostic commands that are commonly relevant to intermittent 502 responses, I would be grateful for suggestions on which ones to inspect and what their expected values should look like. I am particularly interested in a troubleshooting approach that can identify the underlying cause without simply increasing every timeout or process limit as a workaround. Any guidance on how to correlate the browser’s 502 response with the Virtualmin/webserver/PHP logs and determine which component is actually responsible would help me get to the root of the problem and keep the website stable without making unnecessary changes to the rest of the server. Thanks!

2

Intermittent that recovers on its own indicates overload.

It may be that increasing the number of max_children will help if it’s only getting a little backed up now and then, but that really depends on how overloaded things are, and if memory is implicated, you might make things worse by increasing number of processes running to serve requests. As far as I recall, you’ve reported slowness in the past…you’ll need to follow the exact same process of elimination for this problem.

And, yes, there should be an error in at least the error_log for the domain; that may just be the 502, or it may include the PHP errors, depending on configuration (it’s possible to split the PHP log into its own file, which might be found in the domain’s home logs directory).

Virtualmin has a menu item for viewing PHP logs, in addition to viewing web server logs. And, logs are always the first place to look for an explanation.

So, figure out which domain, which specific page/script, and which specific query (it’s pretty much always database usage that’s the problem when “slow” is the symptom). Unless you have pathologically slow disk reads/writes, then you need to assume you have pathologically slow database reads/writes and that could be as simple as a poorly written plugin.

3

Thanks, that gives me a much clearer direction. I’ll avoid increasing max_children blindly, especially since adding more PHP processes could make the situation worse if memory is already under pressure. I’ll first identify the exact domain, page/script, and request that produces the 502, then compare the domain’s error_log and PHP logs with the timestamp of the failure. I’ll also check the Virtualmin PHP logs and web server logs rather than relying on the browser response alone.

The database angle is interesting because the affected requests are mainly dynamic ones. When I capture the next 502, is there a particular log message or PHP-FPM symptom that would help distinguish a worker/process-limit problem from a request that is simply getting stuck on a slow database query? I’d like to establish which of those is happening before changing any PHP-FPM limits.

4

Same as last time.

Look at top for the user that is using the most CPU, which identifies the domain.

Then look for errors in that specific domain’s logs. That will generally tell you the most likely page (errors usually tell you what page and what the error is).

If it’s a database timeout, it’s a slow query, probably a poorly implemented plugin. The solution is to fix that query or remove that plugin. It’s extremely rare that database tuning alone can fix a pathological query (though adding an index on the problem table might help). You can also turn on slow query logging to identify specific slow queries. Slow Query Log Overview | Server | MariaDB Documentation (This is the most precise and useful tool when you have reason to suspect a problematic query.)

If it’s some other resource exhaustion, that may point to the need to increase some limits for PHP.

It always comes down to reading the logs from around the time when a problem is happening.