如何修复 WordPress 500 Internal Server Error

WordPress 中的 500 Internal Server Error 是一个兜底的 HTTP 状态码：当 PHP 或 Web 服务器出了问题、却无法（或不愿意）告诉你具体原因时，就会抛出它。和 404（页面未找到）或 WordPress 数据库连接错误不同，500 不给你任何直接线索。页面只是显示“Internal Server Error”，在很多情况下，甚至连这点文字都没有——只剩一片空白。

正是这种模糊性让 500 错误如此令人头疼。根本原因可能是损坏的 .htaccess 文件、耗尽的 PHP 内存限制、行为异常的插件、主题里的 PHP 致命错误、损坏的核心文件、错误的文件权限，或 PHP 版本不兼容。好消息是：WordPress 的 500 错误遵循一组可预测的原因，而每一种都有已知的修复方法。

本指南按照你应当排查的顺序，依次讲解 WordPress 500 Internal Server Error 最常见的七个原因。先开启调试模式让 PHP 说出真正的错误，然后顺着清单往下走——大多数站长在前三步之内就能找到答案。

WordPress 中的 500 Internal Server Error 是什么？

500 Internal Server Error 是一个通用的服务器端错误。“500”这个状态码表示服务器遇到了一个意外状况，无法完成请求，并且没有更具体的状态码来描述发生了什么。

在 WordPress 的语境下，一个请求从浏览器到达 Web 服务器（Apache 或 Nginx），再交给 PHP。PHP 随后执行 WordPress 应用代码——加载 wp-config.php、当前活动主题、所有已激活的插件，以及数据库连接。如果这条链路中的任何一环抛出致命错误且 PHP 无法恢复，服务器就会向浏览器返回 500 状态码。

由于 WordPress 在生产环境默认抑制 PHP 错误（WP_DEBUG 为 false），你通常看不到真正的错误信息——只有通用的 500 响应。这就是为什么每一次修复 WordPress 500 错误的第一步都是开启 WP_DEBUG，让 PHP 暴露出底层致命错误，无论它是内存耗尽、调用未定义函数、语法错误，还是缺少文件。

常见原因

下表将 WordPress 500 错误的七个根本原因与各自的识别方式、对应修复方法一一对应。在深入分步指南之前，先用它做一次快速分诊。

原因	如何识别	修复方法
.htaccess 损坏	在保存固定链接或迁移后全站出现 500	重命名 .htaccess 并重新生成默认文件
PHP 内存限制耗尽	调试日志显示 "Allowed memory size of ... exhausted"	将 memory_limit 提升至 256M 或更高
插件冲突	安装或更新某个插件后立即出现 500	停用所有插件，然后逐一重新启用
主题错误	仅当前主题出现 500；切换默认主题后消失	切换到 Twenty Twenty-Four 并修复主题
核心文件损坏	排除插件、主题和数据库后 500 仍持续	重新安装 WordPress 核心文件
文件权限错误	服务器日志显示 PHP 文件 "Permission denied"	目录设为 755，文件设为 644
PHP 版本不兼容	调试显示 "Call to undefined function" 或版本警告	升级到插件所支持的 PHP 版本

分步修复指南

按顺序执行以下七个步骤。一旦 500 错误解决就停下来——你几乎不需要走完全部七步。

步骤 1：在 wp-config.php 中启用 WP_DEBUG

在盲目猜测之前，先让 PHP 告诉你哪里出了问题。打开 WordPress 根目录下的 wp-config.php，在 /* That's all, stop editing! */ 注释上方添加以下几行。重新加载站点，阅读它现在打印出的 PHP 致命错误——它会指出确切的文件和行号。如果开启调试后 500 仍然存在，说明错误发生在 WordPress 加载之前，请继续步骤 2。

步骤 2：检查并重命名 .htaccess

损坏的 .htaccess 是 WordPress 500 错误最常见的单一原因，尤其是在迁移或更改固定链接之后。通过重命名文件来临时禁用它，然后重新加载站点。如果 500 消失，重新生成一份干净的 .htaccess：

# 备份并禁用当前 .htaccess
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# 重新加载站点。如果恢复正常，创建一份全新的默认 .htaccess

# 默认 WordPress .htaccess
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

你也可以从后台重新生成 .htaccess：进入设置 > 固定链接，不做任何修改直接点击“保存更改”。

步骤 3：增加 PHP 内存限制

如果调试日志显示 Allowed memory size of ... bytes exhausted，说明 PHP 内存耗尽。这在安装了大量插件、处理大型图片任务，或使用重型页面构建器的站点上很常见。将限制提升到至少 256M。下方专门的 PHP 内存限制修复 一节展示了全部三种方法（wp-config.php、php.ini 和 .htaccess）。

步骤 4：停用所有插件

插件冲突是第二大常见原因。一次性测试所有插件的最快方法是重命名 plugins 目录，让 WordPress 找不到它们：

cd /var/www/html/wp-content
mv plugins plugins.disabled

重新加载站点。如果 500 消失，说明某个插件是罪魁祸首。把目录改回去，然后逐个重新启用插件——在 500 再次出现前最后启用的那个就是问题所在。更新它、换掉它，或联系开发者。

步骤 5：切换到默认主题

如果停用插件没有效果，当前活动主题可能存在 PHP 致命错误——语法错误、调用未定义函数，或调用了已弃用的 API。重命名活动主题目录，让 WordPress 回退到自带的默认主题（如 Twenty Twenty-Four）：

cd /var/www/html/wp-content/themes
mv your-theme your-theme.disabled

如果站点用默认主题能正常加载，检查原主题的 functions.php 是否有语法错误或调用已不存在的函数。你也可以通过 wp-config.php 强制指定默认主题：

define('WP_DEFAULT_THEME', 'twentytwentyfour');

步骤 6：重新安装 WordPress 核心文件

如果已排除 .htaccess、内存、插件和主题，500 仍然存在，那么某个 WordPress 核心文件可能已损坏或被部分覆盖。如果后台能访问，进入仪表盘 > 更新并点击重新安装——这会覆盖核心文件，但不会动你的主题、插件和数据库。如果后台无法访问，从 wordpress.org 下载全新的 WordPress 安装包，删除压缩包中的 wp-content 目录和 wp-config.php，然后把剩余的核心文件上传覆盖现有安装。

步骤 7：检查文件权限

不正确的属主或权限会阻止 PHP 读取或执行 WordPress 文件，从而产生 500。Web 服务器用户（通常是 www-data 或 nginx）必须拥有这些文件，目录为 755，文件为 644。绝不要使用 777——它既是安全隐患，也极少是正确的修复方法。具体命令见下方专门小节。

wp-config.php 调试配置

开启调试模式是最重要的一步诊断操作。这些常量应放在 wp-config.php 中，位于 /* That's all, stop editing! */ 行上方。在正式的生产站点上，请保持 WP_DEBUG_DISPLAY 为 false，这样错误会被记录到 wp-content/debug.log，而不会显示给访客。

// 添加到 wp-config.php 中，在 "stop editing" 行上方
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // 将错误写入 wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // 生产环境保持 false；设为 true 可在屏幕上打印
define('SCRIPT_DEBUG', true);      // 调试时使用未压缩的 JS/CSS

保存后，重新加载出错的页面，然后查看 wp-content/debug.log。致命错误条目会指出文件名和行号，把一个模糊的 500 在几秒内变成可操作的修复。

PHP 内存限制修复

当 WordPress 耗尽 PHP 内存限制时，PHP 会以致命错误终止脚本，服务器返回 500。使用下面三种方法中的任意一种来提升限制——选择你的主机环境所允许的那一种。wp-config.php 方法几乎适用于所有主机；php.ini 提供服务器级的值；.htaccess 仅对 Apache 生效。

方法 A：通过 wp-config.php 提升

// 添加到 wp-config.php，在 "stop editing" 行上方
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // 后台仪表盘使用更高的限制

方法 B：通过 php.ini 提升

# 找到你的 php.ini 位置
php -i | grep "Loaded Configuration File"
# 常见路径:
# /etc/php/8.2/fpm/php.ini   (PHP-FPM)
# /etc/php/8.2/cli/php.ini   (CLI)

; 在 php.ini 中
memory_limit = 256M

# 编辑 FPM 的 ini 后，重启 PHP-FPM
sudo systemctl restart php8.2-fpm

方法 C：通过 .htaccess 提升

# 添加到 .htaccess（仅 Apache 有效；Nginx 忽略此指令）
php_value memory_limit 256M

验证新限制是否生效：

php -r "echo ini_get('memory_limit');"
# 应该输出: 256M

如果提升到 256M 仍未解决错误，很可能是某个插件或主题在泄漏内存。请用步骤 4 隔离它，而不是无休止地继续提高限制。

快速参考表

WordPress 的 500 错误很容易和其他服务器错误混淆。下表区分了你最可能遇到的五种错误，以便你应用正确的修复方法。

错误	含义	首先检查
500 Internal Server Error	通用的 PHP/服务器错误；请求意外失败	启用 WP_DEBUG 并阅读致命错误
502 Bad Gateway	Web 服务器从 PHP 上游收到了无效响应	PHP-FPM 是否在运行且可通过 socket/端口访问？
503 Service Unavailable	服务器临时过载或处于维护模式	服务器负载、.maintenance 文件或 PHP-FPM 容量
白屏死机（WSOD）	PHP 致命错误且输出被抑制；空白页面，无状态提示	启用 WP_DEBUG；检查内存限制和插件
Parse Error	主题或插件文件中的 PHP 语法错误	阅读错误中的文件/行号；修复语法

进阶提示：500 与白屏死机是近亲。500 返回一个明确的状态码；白屏死机返回 200 加一个空响应体，因为 PHP 在输出任何内容之前就已终止。两者本质上都是 PHP 致命错误——诊断步骤完全相同。

常见问题

总结

WordPress 的 500 Internal Server Error 在设计上就是模糊的——它告诉你 PHP 失败了，却不说原因。修复方法几乎总是让 PHP 开口说话：开启 WP_DEBUG，在 wp-content/debug.log 里阅读致命错误。从这里出发，本指南的七个原因几乎覆盖了现实中的每一种 500：损坏的 .htaccess、耗尽的内存限制、插件或主题冲突、损坏的核心文件，或错误的文件权限。

按顺序执行各步骤，站点一恢复就停下来，并记得在生产环境把 WP_DEBUG_DISPLAY 重新设为 false，让错误继续静默记录而不向访客暴露内部信息。有了调试模式这把利器和这份清单，WordPress 的 500 错误就从一道谜题变成了五分钟就能解决的小事。

相关指南

• 如何修复 500 Internal Server Error：完整指南
• WordPress 白屏死亡：系统化修复方法
• WordPress 数据库连接错误：完整修复指南
• 如何修复 503 Service Unavailable 错误