如果僅在一個網站上收到錯誤ERR_CONNECTION_RESET，則很可能伺服器端出了點問題。
接收隨機ERR_CONNECTION_RESET
幾周前，我的一位同事向我抱怨：有時，當他使用WordPress主題編輯器時，他要麼收到一個空HTML頁面，要麼無法載入某些JavaScript。
我能夠重複這個問題。在重新載入WordPress主題編輯器三到五次後，Chrome的Web開發人員控制台顯示了net :: ERR_CONNECTION_RESET錯誤。
文檔的檢索位元組總是不同的。
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，並且一切正常。
總結
這一集是一個經典示例，說明了如何僅通過手握日誌就可以得出解決方案。跳過所有有關「如何修復XYZ」的clickbaity文章，並查看所涉及的系統及其日誌文件。全部都在那裡。