If you receive the error ERR_CONNECTION_RESET on one website only, it is highly likely that something went wrong on the server side.
Receiving random ERR_CONNECTION_RESETs
A few weeks ago one of my colleagues complained to me: Sometimes, when he was using the WordPress theme editor, he either received an empty HTML page or some JavaScript could not be loaded.
I were able to replicate the issue. After three to five reloads of WordPress’ theme editor, Chrome’s web developer console showed an net::ERR_CONNECTION_RESET error.
The retrieved bytes of the document always differed.
ERR_CONNECTION_RESET means, something went wrong in the TCP stack and our client/browser did not receive the expected packets.
On the same server had been also another WordPress instance running without any problems. Both my colleague and I received the ERR_CONNECTION_RESET by using different internet providers.
Those facts led me to the conclusion that it’s probably not some weird MTU problem but something was wrong with the webserver/PHP/WordPress setup.
Digging into the log files
Without any logs by my hand I had to open a support ticket. I expected the support service asked me all the question, you are usually finding when googling for the issue (Issues with your networking provider?). And I was not disappointed.
In the end I asked for Apache’s error_log and if it contained any hints of a Segfault. The support staff sent me some excerpts. The first excerpt came from Apache’s error_log:
FastCGI: too much stderr received from server /path-to-instance/php74-fpm", increase FCGI_SERVER_MAX_STDERR_LINE_LEN (1023) and rebuild or use "\\n" to terminate lines, referer: https://wordpress-instance/wordpress/wp-admin/themes.phpThe second one came from PHP-FPM’s log:
NOTICE: PHP message: PHP Notice: Trying to access array offset on value of type bool in /www/htdocs/path-to-instance/wordpress/wp-content/plugins/wp-statistics/includes/classes/class-wp-statistics-widget.php
NOTICE: PHP message: PHP Notice: Array to string conversion in /www/htdocs/path-to-instance/wordpress/wp-includes/formatting.phpThose messages repeated over and over again.
Because I had already disabled every WordPress plug-in previously, I could exclude a hard bug in the wp-statistics plug-in.
With this information in my hand I conlcuded the following: PHP-FPM spammed a lot of messages to Apache because of the PHP notices. After 1023 lines received, the process died.
Reducing the number of PHP’s notices
In the end, the solution for the ERR_CONNECTION_RESET problem was easy. I changed the error_reporting of WordPress to E_ALL & ~E_NOTICE:
error_reporting(E_ALL & ~E_NOTICE);After changing the error_reporting, the number of logged lines were reduced to 0 and everything worked fine again.
Wrapping it up
This episode was a classical example of how you can derive a solution from only having logs at your hands. Skip all of those clickbaity articles about “How to fix XYZ” and take a look at the involved systems and their log files. It’s all in there.
