如何修復 WordPress 網站上的 500 內部服務器錯誤
已發表: 2017-12-25可怕的 500 內部服務器錯誤。 它似乎總是在最不合時宜的時候出現,而您突然間就開始爭先恐後地想辦法讓您的 WordPress 網站重新上線。 相信我們,我們都去過那裡。 您可能還看到過類似行為的其他錯誤,包括建立數據庫連接的可怕錯誤和可怕的白屏死機。 但是從您的網站出現故障的那一刻起,您就會失去訪問者和客戶。 更不用說它看起來對您的品牌不利。
今天我們將深入探討 500 內部服務器錯誤,並引導您通過一些方法讓您的網站快速恢復在線。 閱讀下面的更多信息,了解導致此錯誤的原因以及將來可以採取哪些措施來防止它發生。
- 什麼是 500 內部服務器錯誤?
- 如何修復 500 內部服務器錯誤
500 內部服務器錯誤(最常見的原因):
WordPress 中的 500 內部服務器錯誤可能由多種原因引起。 如果您遇到這種情況,則很有可能是以下一種(或多種)因素導致了問題:
- 瀏覽器緩存。
- 數據庫登錄憑據不正確。
- 損壞的數據庫。
- WordPress 安裝中的文件損壞。
- 您的數據庫服務器出現問題。
- 損壞的 WordPress 核心文件。
- 損壞的 .htaccess 文件和 PHP 內存限制。
- 第三方插件和主題的問題。
- 第三方插件的 PHP 超時或致命的 PHP 錯誤。
- 錯誤的文件和文件夾權限。
- 服務器上的 PHP 內存限制已用盡
- .htaccess 文件損壞或損壞。
- CGI 和 Perl 腳本中的錯誤。
查看我們修復 500 內部服務器錯誤的終極指南
什麼是 500 內部服務器錯誤?
Internet 工程任務組 (IETF) 將 500 Internal Server Error 定義為:
500(內部服務器錯誤)狀態代碼表示服務器遇到了阻止它完成請求的意外情況。
當您訪問網站時,您的瀏覽器會向託管該網站的服務器發送請求。 服務器接收該請求,對其進行處理,然後將請求的資源(PHP、HTML、CSS 等)連同 HTTP 標頭一起發回。 HTTP 還包括他們所謂的 HTTP 狀態代碼。 狀態碼是一種通知您請求狀態的方法。 它可能是 200 狀態代碼,表示“一切正常”,也可能是 500 狀態代碼,表示出現問題。
有很多不同類型的 500 狀態錯誤代碼(500、501、502、503、504 等),它們的含義都不同。 在這種情況下,500 內部服務器錯誤表示服務器遇到了阻止它完成請求的意外情況(RFC 7231,第 6.6.1 節)。

500 個內部服務器錯誤變化
由於各種 Web 服務器、操作系統和瀏覽器,500 內部服務器錯誤可能以多種不同的方式出現。 但他們都在交流同樣的事情。 以下只是您可能在網絡上看到的許多不同變體中的幾個:
- “500內部服務器錯誤”
- “HTTP 500”
- “內部服務器錯誤”
- “HTTP 500 – 內部服務器錯誤”
- “500 錯誤”
- “HTTP 錯誤 500”
- “500內部服務器錯誤”
- “500內部服務器錯誤。 抱歉,出了一些問題。”
- “500。 那是一個錯誤。 有一個錯誤。 請稍後再試。 我們知道的就這些。”
- “該網站無法顯示該頁面 - HTTP 500。”
- “目前無法處理這個請求。 HTTP 錯誤 500。”
您可能還會看到以下消息:
服務器遇到內部錯誤或配置錯誤,無法完成您的請求。 請聯繫服務器管理員,[email protected] 並告知他們錯誤發生的時間,以及您可能所做的任何可能導致錯誤的事情。 服務器錯誤日誌中可能提供有關此錯誤的更多信息。

其他時候,您可能只會看到一個空白的白色屏幕。 在處理 500 個內部服務器錯誤時,這實際上在 Firefox 和 Safari 等瀏覽器中很常見。

更大的品牌甚至可能有自己的自定義 500 條內部服務器錯誤消息,例如來自 Airbnb 的這條消息。

這是自述文件中的另一個創意 500 服務器錯誤示例。

即使是強大的 YouTube 也無法避免 500 個內部服務器錯誤。

如果它是 IIS 7.0 (Windows) 或更高版本的服務器,它們有額外的 HTTP 狀態代碼來更準確地指示 500 錯誤的原因:
- 500.0 – 發生模塊或 ISAPI 錯誤。
- 500.11 – Web 服務器上的應用程序正在關閉。
- 500.12 – 應用程序正忙於在 Web 服務器上重新啟動。
- 500.13 – Web 服務器太忙。
- 500.15 – 不允許直接請求 global.asax。
- 500.19 – 配置數據無效。
- 500.21 – 模塊無法識別。
- 500.22 – ASP.NET httpModules 配置不適用於託管管道模式。
- 500.23 – ASP.NET httpHandlers 配置不適用於託管管道模式。
- 500.24 – ASP.NET 模擬配置不適用於託管管道模式。
- 500.50 – 在 RQ_BEGIN_REQUEST 通知處理期間發生重寫錯誤。 發生配置或入站規則執行錯誤。
- 500.51 – GL_PRE_BEGIN_REQUEST 通知處理期間發生重寫錯誤。 發生全局配置或全局規則執行錯誤。
- 500.52 – 在 RQ_SEND_RESPONSE 通知處理期間發生重寫錯誤。 發生出站規則執行。
- 500.53 – 在 RQ_RELEASE_REQUEST_STATE 通知處理期間發生重寫錯誤。 發生出站規則執行錯誤。 該規則配置為在更新輸出用戶緩存之前執行。
500.100 – 內部 ASP 錯誤。
500 個錯誤對 SEO 的影響
與用於 WordPress 維護模式並告訴 Google 稍後再檢查的 503 錯誤不同,如果不立即修復,500 錯誤會對 SEO 產生負面影響。 如果您的網站僅停機了 10 分鐘,並且它被持續抓取了很多次,那麼抓取工具只會從緩存中獲取頁面。 或者,谷歌甚至可能沒有機會在它備份之前重新抓取它。 在這種情況下,你完全沒問題。
但是,如果網站長時間關閉,比如超過 6 小時,那麼 Google 可能會將 500 錯誤視為需要解決的網站級別問題。 這可能會影響您的排名。 如果您擔心重複 500 個錯誤,您應該從一開始就弄清楚它們發生的原因。 下面的一些解決方案可以提供幫助。
如何修復 500 內部服務器錯誤
當您在 WordPress 網站上看到 500 內部服務器錯誤時,您應該從哪裡開始進行故障排除? 有時您甚至可能不知道從哪裡開始。 通常 500 錯誤是在服務器本身,但根據我們的經驗,這些錯誤源於兩件事,第一是用戶錯誤(客戶端問題),第二是服務器有問題。 所以我們將深入研究兩者。
這絕不是煩人的 pic.twitter.com/pPKxbkvI9K
— Dare Obasanjo (@Carnage4Life) 2019 年 9 月 26 日
查看這些常見原因和修復 500 內部服務器錯誤並立即恢復運行的方法。
1.嘗試重新加載頁面
這對某些人來說似乎有點明顯,但是當遇到 500 內部服務器錯誤時,您應該嘗試的最簡單和首要的事情之一就是等待一分鐘左右並重新加載頁面(F5 或 Ctrl + F5)。 可能是主機或服務器只是過載了,該站點將立即恢復。 在等待期間,您也可以快速嘗試使用其他瀏覽器來排除問題。
您可以做的另一件事是將網站粘貼到 downforeveryoneorjustme.com。 該網站會告訴您該網站是否已關閉或您是否有問題。 像這樣的工具會檢查從服務器返回的 HTTP 狀態代碼。 如果它不是 200 “一切正常”,那麼它將返回一個向下指示。

我們還注意到,有時這可能會在您更新 WordPress 網站上的插件或主題後立即發生。 通常這是在未正確設置的主機上。 發生的事情是他們在之後經歷了一個臨時的超時。 但是,事情通常會在幾秒鐘內自行解決,因此您只需要刷新即可。
2.清除瀏覽器緩存
在深入調試站點之前,清除瀏覽器緩存始終是另一個很好的故障排除步驟。 以下是有關如何在各種瀏覽器中清除緩存的說明:
- 如何為所有瀏覽器強制刷新單個頁面
- 如何清除谷歌瀏覽器的瀏覽器緩存
- 如何清除 Mozilla Firefox 的瀏覽器緩存
- 如何清除 Safari 的瀏覽器緩存
- 如何清除 Internet Explorer 的瀏覽器緩存
- 如何清除 Microsoft Edge 的瀏覽器緩存
- 如何清除 Opera 的瀏覽器緩存
3. 檢查您的服務器日誌
您還應該利用錯誤日誌。 如果您是 Kinsta 客戶,您可以在 MyKinsta 儀表板的日誌查看器中輕鬆查看錯誤。 這可以幫助您快速縮小問題範圍,特別是如果它是由您網站上的插件引起的。

如果您的主機沒有日誌記錄工具,您還可以通過將以下代碼添加到 wp-config.php 文件來啟用 WordPress 調試模式以啟用日誌記錄:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );日誌通常位於 /wp-content 目錄中。 其他人,比如 Kinsta 的這裡,可能有一個名為“logs”的專用文件夾。

您還可以查看 Apache 和 Nginx 中的日誌文件,它們通常位於此處:
- 阿帕奇: /var/log/apache2/error.log
- Nginx: /var/log/nginx/error.log
如果您是 Kinsta 客戶,您還可以利用我們的分析工具來細分 500 個錯誤的總數,並查看它們發生的頻率和時間。 如果這是一個持續存在的問題,或者可能已經自行解決,這可以幫助您進行故障排除。

在功能強大的集中式 MyKinsta 儀表板的日誌查看器中輕鬆識別和解決錯誤。 免費試用 Kinsta。
如果由於致命的 PHP 錯誤而顯示 500 錯誤,您還可以嘗試啟用 PHP 錯誤報告。 只需將以下代碼添加到引發錯誤的文件中。 通常,您可以在 Google Chrome DevTools 的控制台選項卡中縮小文件範圍。
ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL);您可能還需要使用以下內容修改 php.ini 文件:
display_errors = on4.建立數據庫連接時出錯
500 內部服務器錯誤也可能因數據庫連接錯誤而發生。 根據您的瀏覽器,您可能會看到不同的錯誤。 但無論在您的服務器日誌中,兩者都會生成 500 HTTP 狀態代碼。
下面是一個“建立數據庫連接錯誤”消息的示例,它看起來像您的瀏覽器。 整個頁面是空白的,因為無法檢索任何數據來呈現頁面,因為連接無法正常工作。 這不僅會破壞您網站的前端,還會阻止您訪問您的 WordPress 儀表板。


那麼究竟為什麼會發生這種情況呢? 好吧,以下是一些常見的原因。
- 最常見的問題是您的數據庫登錄憑據不正確。 您的 WordPress 站點使用單獨的登錄信息連接到其 MySQL 數據庫。
- 您的 WordPress 數據庫已損壞。 有這麼多帶有主題、插件和用戶不斷刪除和安裝它們的移動部件,有時數據庫會損壞。 這可能是由於表丟失或個別損壞,或者某些信息可能被意外刪除。
- 您的 WordPress 安裝中可能有損壞的文件。 這有時甚至可能由於黑客而發生。
- 您的數據庫服務器出現問題。 Web 主機端可能出現許多問題,例如數據庫因流量高峰而過載或因太多並發連接而無響應。 這實際上在共享主機中很常見,因為它們為同一服務器上的許多用戶使用相同的資源。
查看我們關於如何修復在 WordPress 中建立數據庫連接的錯誤的深入文章。
5. 檢查你的插件和主題
第三方插件和主題很容易導致 500 內部服務器錯誤。 我們已經在 Kinsta 看到了所有類型,從滑塊插件到廣告輪播插件。 很多時候,您應該在安裝新內容或運行更新後立即看到錯誤。 這就是為什麼我們總是建議使用暫存環境進行更新或至少一個一個地運行更新的原因之一。 否則,如果您遇到 500 內部服務器錯誤,您會突然爭先恐後地找出導致它的原因。
解決此問題的幾種方法是停用所有插件。 請記住,如果您只是停用插件,您不會丟失任何數據。 如果您仍然可以訪問您的管理員,一個快速的方法是瀏覽到“插件”並從批量操作菜單中選擇“停用”。 這將禁用所有插件。

如果這解決了問題,您將需要找到罪魁禍首。 開始一一激活,每次激活後重新加載站點。 當您看到 500 內部服務器錯誤返回時,您已經找到了行為不端的插件。 然後,您可以聯繫插件開發人員尋求幫助或在 WordPress 存儲庫中發布支持票。
如果您無法登錄 WordPress 管理員,您可以通過 FTP 進入您的服務器並將您的插件文件夾重命名為 plugins_old 之類的名稱。 然後再次檢查您的網站。 如果它有效,那麼您將需要一個一個地測試每個插件。 將您的插件文件夾重命名為“plugins”,然後將其中的每個插件文件夾一一重命名,直到找到它為止。 您也可以嘗試先在臨時站點上複製它。

始終確保您的插件、主題和 WordPress 核心是最新的。 並檢查以確保您正在運行受支持的 PHP 版本。 如果結果證明與插件中的錯誤代碼衝突,您可能需要聘請 WordPress 開發人員來解決問題。
6.重新安裝WordPress核心
有時 WordPress 核心文件可能會損壞,尤其是在舊網站上。 實際上,在不影響您的插件或主題的情況下重新上傳 WordPress 的核心非常容易。 我們有一個深入的指南,其中包含 5 種不同的方式來重新安裝 WordPress。 當然,請確保在繼續之前進行備份。 跳至以下部分之一:
- 如何在保留現有內容的同時從 WordPress 儀表板重新安裝 WordPress
- 如何在保留現有內容的同時通過 FTP 手動重新安裝 WordPress
- 如何在保留現有內容的同時通過 WP-CLI 手動重新安裝 WordPress
7.權限錯誤
服務器上的文件或文件夾的權限錯誤也可能導致發生 500 內部服務器錯誤。 以下是關於 WordPress 中文件和文件夾權限的一些典型權限建議:
- 所有文件應為 644 (-rw-r–r–) 或 640。
- 所有目錄應為 755 (drwxr-xr-x) 或 750。
- 任何目錄都不應該被賦予 777,即使是上傳目錄。
- 加固: wp-config.php 也可以設置為 440 或 400 以防止服務器上的其他用戶讀取它。
有關更深入的說明,請參閱有關更改文件權限的 WordPress Codex 文章。
您可以使用 FTP 客戶端輕鬆查看您的文件權限(如下所示)。 您還可以聯繫您的 WordPress 主機支持團隊,要求他們快速 GREP 對您的文件夾和文件的文件權限,以確保它們設置正確。

8. PHP 內存限制
500 內部服務器錯誤也可能是由於服務器上的 PHP 內存限制用盡而引起的。 您可以嘗試增加限制。 請按照以下說明在 cPanel、Apache、您的 php.ini 文件和wp-config.php文件中更改此限制。
增加 cPanel 中的 PHP 內存限制
如果您在使用 cPanel 的主機上運行,則可以從 UI 輕鬆更改此設置。 在軟件下單擊“選擇 PHP 版本”。

單擊“切換到 PHP 選項”。

然後,您可以單擊memory_limit屬性並更改其值。 然後點擊“保存”。

增加 Apache 中的 PHP 內存限制
.htaccess文件是一個特殊的隱藏文件,其中包含可用於修改服務器行為的各種設置,一直到目錄特定級別。 首先通過 FTP 或 SSH 登錄到您的站點,查看您的根目錄,看看那裡是否有.htaccess文件。

如果有,您可以編輯該文件以添加必要的代碼以增加 PHP 內存限制。 最有可能設置為64M或以下,您可以嘗試增加此值。
php_value memory_limit 128M在 php.ini 文件中增加 PHP 內存限制
如果上述方法不適合您,可以嘗試編輯您的php.ini文件。 通過 FTP 或 SSH 登錄到您的站點,轉到您站點的根目錄並打開或創建一個php.ini文件。

如果該文件已經存在,請搜索這三個設置並在必要時對其進行修改。 如果您剛剛創建了文件,或者找不到設置,您可以粘貼下面的代碼。 您當然可以修改這些值以滿足您的需要。
memory_limit = 128M 一些共享主機可能還要求您在.htaccess文件中添加 suPHP 指令,以使上述php.ini文件設置生效。 為此,請編輯您的.htaccess文件,該文件也位於您網站的根目錄,並在文件頂部添加以下代碼:
<IfModule mod_suphp.c> suPHP_ConfigPath /home/yourusername/public_html </IfModule> 如果上述方法對您不起作用,則可能是您的主機鎖定了全局設置,而是將其配置為使用.user.ini文件。 要編輯您的.user.ini文件,請通過 FTP 或 SSH 登錄到您的站點,轉到您站點的根目錄並打開或創建一個.user.ini文件。 然後,您可以粘貼以下代碼:
memory_limit = 128M在 wp-config.php 中增加 PHP 內存限制
最後一個選項不是我們的粉絲,但如果所有其他方法都失敗了,你可以試一試。 首先,通過 FTP 或 SSH 登錄到您的站點,然後找到您的 wp-config.php 文件,該文件通常位於您站點的根目錄中。

將以下代碼添加到wp-config.php文件的頂部:
define('WP_MEMORY_LIMIT', '128M');您還可以詢問您的主機是否遇到內存限制問題。 我們在 Kinsta 使用 Kinsta APM 工具和其他故障排除方法來幫助客戶縮小可能超出限制的插件、查詢或腳本的範圍。 您還可以使用您自己的許可證中的自定義 New Relic 密鑰。

9. .htaccess 文件有問題
Kinsta 僅使用 Nginx,但如果您使用的是運行 Apache 的 WordPress 主機,則很可能是您的.htaccess文件有問題或已損壞。 請按照以下步驟從頭開始重新創建一個新的。
首先,通過 FTP 或 SSH 登錄到您的站點,並將您的.htaccess文件重命名為.htaccess_old 。

通常要重新創建此文件,您只需在 WordPress 中重新保存您的永久鏈接。 但是,如果您遇到 500 個內部服務器錯誤,您很可能無法訪問您的 WordPress 管理員,所以這不是一個選項。 因此,您可以創建一個新的.htaccess文件並輸入以下內容。 然後上傳到你的服務器。
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress 有關更多示例,請參閱 WordPress Codex,例如用於多站點的默認.htaccess文件。
10. CGI/Perl 腳本中的編碼或語法錯誤
由 CGI 和 Perl 中的錯誤引起的 500 錯誤比以前少了很多。 雖然它仍然值得一提,尤其是對於那些使用 cPanel 的人來說,仍然有很多一鍵式 CGI 腳本仍在使用。 正如 Stack Overflow 上的 AEM 所說:
CGI 已被各種 Web 編程技術所取代,包括 PHP、各種 Apache 擴展(如 mod_perl)、各種風格的 Java 和框架(包括 Java EE、Struts、Spring 等)、基於 Python 的框架(如 Django、Ruby on Rails 等)其他 Ruby 框架和各種 Microsoft 技術。
以下是使用 CGI 腳本時的一些提示:
- 編輯時,總是使用純文本編輯器,例如 Atom、Sublime 或 Notepad++。 這可確保它們保持 ASCII 格式。
- 確保在 CGI 腳本和目錄上使用 chmod 755 的正確權限。
- 以 ASCII 模式(您可以在 FTP 編輯器中選擇)將您的 CGI 腳本上傳到服務器上的 cgi-bin 目錄。
- 確認您的腳本所需的 Perl 模塊已安裝並受支持。
在功能強大的集中式 MyKinsta 儀表板的日誌查看器中輕鬆識別和解決錯誤。 免費試用 Kinsta。
11. 服務器問題(與您的主機核實)
最後,由於PHP 超時或第三方插件的致命 PHP 錯誤也可能發生 500 個內部服務器錯誤,因此您可以隨時與您的 WordPress 主機聯繫。 有時,如果沒有專家,這些錯誤可能很難解決。 以下只是一些常見錯誤示例,這些錯誤會在服務器上觸發 500 個 HTTP 狀態代碼,可能會讓您摸不著頭腦。
PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_error()... PHP message: PHP Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in /www/folder/web/shared/content/plugins/plugin/functions.php:525我們在 Kinsta 監控所有客戶的站點,並在發生這些類型的錯誤時自動通知。 這使我們能夠積極主動並立即開始解決問題。 我們還為每個站點使用 LXD 託管主機和編排的 LXC 軟件容器。 這意味著每個 WordPress 站點都位於其自己的隔離容器中,該容器具有運行它所需的所有軟件資源(Linux、Nginx、PHP、MySQL)。 這些資源是 100% 私有的,不會與其他任何人甚至您自己的網站共享。
PHP 超時也可能由於缺少 PHP 工作者而發生,儘管這些通常會導致 504 錯誤,而不是 500 錯誤。 這些決定了您的站點在給定時間可以處理多少並發請求。 簡而言之,您網站的每個未緩存請求都由 PHP Worker 處理。
當 PHP 工作者已經在一個站點上忙碌時,他們開始建立一個隊列。 一旦達到 PHP 工作人員的限制,隊列就會開始推出較舊的請求,這可能會導致 500 個錯誤或不完整的請求。 閱讀我們關於 PHP 工作者的深入文章。
監控您的網站
如果您擔心將來會在您的網站上發生這些類型的錯誤,您還可以使用 updown.io 之類的工具來監控並在它們發生時立即通知您。 它會定期向您選擇的 URL 發送 HTTP HEAD 請求。 您可以簡單地使用您的主頁。 該工具允許您設置以下檢查頻率:
- 15 秒
- 30秒
- 1分鐘
- 2分鐘
- 5分鐘
- 10分鐘
如果您的網站出現故障,它將向您發送一封電子郵件。 下面是一個例子。

如果您正在嘗試調試有故障的插件或在共享主機上,這可能特別有用,這些主機往往會過度擁擠他們的服務器。 這可以讓您證明您的網站實際上可能多久關閉一次(即使是在半夜)。 這就是為什麼我們總是建議使用託管 WordPress 主機。 請務必查看我們的帖子,其中探討了選擇託管 WordPress 託管的 9 大理由。
概括
500 個內部服務器錯誤總是令人沮喪,但希望現在您知道了一些其他方法來解決它們,以快速讓您的網站恢復運行。 請記住,這些類型的錯誤通常是由第三方插件、致命的 PHP 錯誤、數據庫連接問題、您的 .htaccess 文件或 PHP 內存限制問題以及有時 PHP 超時引起的。
我們錯過了什麼嗎? 也許您有另一個解決 500 個內部服務器錯誤的技巧。 如果是這樣,請在下面的評論中告訴我們。
