ERR_CONNECTION_RESET表示TCP堆栈出现问题，并且我们的客户端/浏览器未收到预期的数据包。在同一台服务器上还有另一个没有任何问题的WordPress实例。我和我的同事都通过使用其他互联网提供商收到了ERR_CONNECTION_RESET。这些事实使我得出的结论是，这可能不是一些奇怪的MTU问题，但Web服务器/ PHP / WordPress设置有问题。

挖掘日志文件

我手上没有任何日志，所以我不得不打开支持通知单。我希望支持服务会问我所有问题，您通常会在搜索该问题时找到问题（与您的网络提供商联系吗？）。我并不感到失望。

最后，我询问了Apache的error_log以及它是否包含Segfault的任何提示。支持人员给了我一些摘录。第一个摘录来自Apache的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.php

第二个来自PHP-FPM的日志：

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.php

这些消息一遍又一遍地重复。

因为我之前已经禁用了每个WordPress插件，所以可以排除wp-statistics插件中的一个硬错误。

掌握了这些信息后，我得出以下结论：由于PHP的注意，PHP-FPM向Apache发送了很多邮件。收到1023条线路后，该过程终止。

减少PHP的通知数

最后，解决ERR_CONNECTION_RESET问题很容易。我将WordPress的error_reporting更改为E_ALL和〜E_NOTICE：

error_reporting(E_ALL & ~E_NOTICE);

更改error_reporting后，已记录的行数减少为0，并且一切正常。