WordPress at Strato – Internal Server Error 500 – Xadomir.de

The Internal Server Error 500 does not necessarily have to be due to your configurations in WordPress, settings at the hoster can also cause it.

Sometimes the solution to a problem can be just a button away. But if you don’t know it’s him, then it just takes a little longer.

On my brother’s WordPress site, the Internal Server Error 500 came up immediately after logging into the WordPress backend (www.domain.tld/wp-admin/). After the site was refreshed, it was gone again and was still logged into the WordPress dashboard. The error is therefore not that serious and you could live with it. But of course it’s better to get rid of him. The common tips on the web will probably be familiar to many WordPress users. You should either check whether the memory for PHP is sufficient or simply deactivate all plugins and activate them again individually. You can do well, but the problem has not been solved.

Finally, you can also activate the WordPress debug mode and also have the log filed. However, if WordPress is otherwise working normally, nothing will be recorded with this error either, because it comes directly from the server and does not appear to be caused by the PHP script. So, then you finally have to start asking yourself the question: Is it maybe the hoster? Especially if you install an empty WordPress as a test and the same error occurs there. In this case it really was the Hoster Strato. Fortunately, the problem can be solved in the Strato portal itself. At some point they probably introduced a function in their center that activated the PHP Boost. The problem is that this was apparently simply set to active for all customers. Another problem, the mode is not always compatible with all PHP scripts, nor does it seem to be 100% compatible with WordPress (at least not the one currently installed).

As soon as the PHP boost was deactivated, logging into WordPress worked perfectly again.
Strato-Portal: Databases and Webspace -> Set PHP version -> PHP Boost: Disabled

The error is also clear in the server log, which can be found under the statistics at Strato:

27.03.2019 11:29:10 domainname.tld [client 0.0.0.0] FastCGI: "/home/strato/http/fastcgi/rid/00/00/000000/htdocs/test/wp-admin/index.php" aborted: incomplete headers (0 bytes) received from server after 1553682550 sec
27.03.2019 11:29:48 domainname.tld [client 0.0.0.0] FastCGI: failed to connect to (dynamic) server "/home/strato/http/fastcgi/rid/00/00/000000/htdocs/test/wp-admin/index.php": something is seriously wrong, any chance the socket/named_pipe directory was removed?, see the FastCgiIpcDir directive

Maybe the boost should also work with WordPress. I don’t know. It is also possible that these errors indicate an incorrect implementation by the hoster. At least it works when it’s disabled, and any speed hits haven’t become apparent either. It should therefore be much more important to use a current PHP version on the server. You can set it there as well. However, it should also be checked beforehand whether everything on the page is functional.