500 Internal Server Error（内部服务器错误）是一个 HTTP 状态码，表示 Web 服务器遇到了意外情况，无法完成请求。它是一种通用的服务器端错误：服务器知道出了问题，但无法更具体地说明原因。

本指南将说明 500 错误的成因、如何使用服务器日志进行诊断，以及针对 Apache、Nginx 等 Web 服务器最常见的修复方法。

快速参考

什么是 HTTP 500 错误

当你打开一个网页时，浏览器会向托管该站点的服务器发送请求。服务器处理请求后，会返回 HTTP 响应码以及所请求的内容。200 段的响应码表示成功，而 500 段的响应码表示服务器错误。

500 状态码是最通用的服务器错误。当没有更具体的错误码（如 502、503 或 504）适用时，服务器会返回它。

访客可以做什么

如果在浏览网站时遇到 500 错误，问题出在服务器端，而不是你的浏览器或网络连接。你可以尝试以下方法：

• 重新加载页面：错误可能只是暂时的。等待几秒后刷新。
• 清除浏览器缓存：如果错误页被缓存，浏览器可能一直显示它。清除缓存后再试。
• 换一个浏览器或设备：这有助于排除特定浏览器的缓存问题。
• 稍后再来：服务器管理员可能已经在修复了。
• 联系网站所有者：如果错误持续存在，请告知他们以便排查。

常见原因与修复方法

如果你是服务器管理员，以下是 500 Internal Server Error 最常见的几个成因及对应的修复方法。

文件权限问题

Web 服务器进程需要对站点文件有读取权限，对目录有执行权限。文件权限设置不正确是 500 错误最常见的成因之一。

要为典型的 Web 根目录修复权限，可执行：

sudo find /var/www/html -type d -exec chmod 755 {} +

sudo find /var/www/html -type f -exec chmod 644 {} +

sudo chown -R www-data:www-data /var/www/html

请将 www-data 替换为你 Web 服务器实际运行的用户（例如 nginx 或 apache）。

.htaccess 语法错误

如果你使用的是 Apache，.htaccess 文件中存在无效指令或语法错误都会导致 500 错误。常见错误包括拼写错误、引用了未加载的模块，以及不正确的重写规则。

要测试，可临时重命名该文件：

sudo mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

如果重命名后站点能够正常加载，说明问题出在 .htaccess 文件中。请逐行检查该文件，或查看 Apache 错误日志中记录的具体失败指令。

PHP 错误

致命的 PHP 错误（例如语法错误、缺少扩展，或超出内存限制）会导致服务器返回 500 错误，而不是正常渲染页面。

查看 PHP 错误日志或 Web 服务器错误日志：

sudo tail -50 /var/log/apache2/error.log

对于使用 PHP-FPM 的 Nginx：

sudo tail -50 /var/log/nginx/error.log

如果错误源于内存限制，请增大当前 PHP 运行时所用 php.ini 文件中的 memory_limit 值。PHP CLI 与 PHP-FPM 可能加载不同的配置文件，因此不要用 php --ini 来定位 Web 请求所读取的文件。在 Ubuntu 和 Debian 上，FPM 的配置文件通常位于 /etc/php/<version>/fpm/php.ini；Fedora 和 RHEL 通常直接使用 /etc/php.ini。

编辑对应的 PHP-FPM 配置文件：

sudo nano /path/to/php.ini

找到 memory_limit 这一行并调大数值：

memory_limit = 256M

修改完成后重启 PHP 服务。

Nginx 与 PHP-FPM 故障

当 Nginx 为 PHP 应用提供服务时，500 响应通常源自应用程序而非 Nginx 本身。Nginx 通过套接字将请求交给 PHP-FPM，当 PHP-FPM 返回 500 响应时，Nginx 通常会将该状态透传给浏览器。Nginx 错误日志可能记录 FastCGI 输出或传输失败，而文件名、行号和异常等细节通常位于 PHP 错误日志中。

如果出错的页面显示一段裸错误，下方带有类似 nginx/1.24.0 (Ubuntu) 的字样，那段页脚来自 Nginx 的默认错误页。它确认了错误页由 Nginx 提供并标明了构建版本，但并未说明任何原因。在 http 块中设置 server_tokens off; 可让错误页和 Server 响应头不再显示版本与构建信息，不过 Nginx 名称本身仍然保留。

首先从 PHP-FPM 日志入手。在 Ubuntu 和 Debian 上，日志路径包含 PHP 版本号：

sudo tail -50 /var/log/php8.3-fpm.log

在 Fedora、RHEL 及其衍生发行版上，PHP-FPM 会写入自己的目录：

sudo tail -50 /var/log/php-fpm/www-error.log

PHP-FPM 日志为空并不代表没有错误。PHP 可能正在写入另一个配置好的目标，或者工作进程的输出未被捕获。下一节将说明如何检查这两项设置。

Nginx 在以下两种值得注意的情况下会自行返回 500。第一种是重写循环（rewrite loop），即 try_files 或 rewrite 指令持续将请求发回给它自身。错误日志会直接指出问题：

rewrite or internal redirection cycle while internally redirecting to "/index.php"

第二种是无法写入临时文件。当 /var/lib/nginx 或 /var/cache/nginx 下的缓冲目录不能被 Nginx 工作进程用户写入时，缓存上游响应就会失败，请求最终以 500 结束。

在重启 Nginx 之前，先测试配置：

sudo nginx -t

配置有效时会输出：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

如果测试通过，说明 Nginx 语法有效且能打开配置所引用的文件。但这并不能排除运行时问题，例如重写循环、上游设置不正确或工作进程权限失败。请复现该请求并检查 Nginx 与应用两方面的日志。将 Nginx 错误日志的严重级别从默认的 error 调低到 info，可记录更多与上游的交互。debug 级别会显示一切信息，但它仅在 Nginx 编译时启用 --with-debug 才可用，你可以通过 nginx -V 的输出确认。

数据库连接失败

依赖数据库（MySQL、MariaDB、PostgreSQL）的 Web 应用，如果无法连接数据库就会返回 500 错误。这可能发生在数据库服务停止、凭据错误或数据库损坏时。

检查数据库服务是否正在运行：

sudo systemctl status mysql

如果未运行，则启动它：

sudo systemctl start mysql

在你的应用配置文件（例如 WordPress 的 wp-config.php）中核对数据库凭据。

损坏的插件或主题

像 WordPress、Joomla 和 Drupal 这类内容管理系统，在更新或安装插件、主题后可能会抛出 500 错误。

要诊断，可重命名插件目录以一次性禁用所有插件：

sudo mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins.bak

如果站点能够加载，则逐个重新启用插件，以找出引发错误的那一个。

服务器资源耗尽

内存或磁盘空间耗尽会导致服务器在处理请求时失败。检查可用内存和磁盘空间：

free -h

df -h

如果内存耗尽，找出占用内存最多的进程：

ps aux --sort=-%mem | head -10

如果磁盘空间已满，找出并删除不必要的大文件，或清理体积过大的日志文件。

部署后文件所有者不正确

通过 SCP、rsync 或 Git 部署文件后，上传的文件可能归属于错误的用户。Web 服务器进程无法读取不属于它的文件。

检查文件所有者：

ls -la /var/www/html/

通过设置正确的所有者来修复：

sudo chown -R www-data:www-data /var/www/html

在 Fedora、RHEL 及其衍生发行版上，仅修正所有者往往还不够。SELinux 会给每个文件打上安全上下文标签，而从用户主目录复制进 Web 根目录、或从归档中解压出来的文件通常保留着错误的标签。首先检查 SELinux 是否处于强制模式：

getenforce

如果输出为 Enforcing，请恢复 Web 根目录应有的上下文：

sudo restorecon -Rv /var/www/html

SELinux 会将拒绝（denial）记录到审计日志而非 Web 服务器日志中，这正是原因可能一直隐藏的原因。用以下命令列出最近的拒绝记录：

sudo ausearch -m avc -ts recent

根据被拦截的内容不同，拒绝可能表现为 403 或 500。对于需要发起出站连接（连向远程数据库或外部 API）的应用，需要显式授予该权限：

sudo setsebool -P httpd_can_network_connect on

检查服务器日志

判断 500 错误成因最快的方法，就是查看 Web 服务器错误日志。日志文件的位置取决于你的发行版和 Web 服务器：

在 Nginx + PHP-FPM 技术栈上，两个日志都要看。Nginx 日志记录代理与传输失败，并可能捕获 FastCGI 输出，而 PHP 日志通常包含应用错误。如果某个日志文件缺失或被重定向到了 journal，则改用 journalctl 读取：

sudo journalctl -u php8.3-fpm -n 50

要查看最近的日志条目：

sudo tail -50 /var/log/nginx/error.log

在复现错误时进行实时监控：

sudo tail -f /var/log/nginx/error.log

日志通常会包含确切的错误消息、导致失败的文件路径以及行号。如果你想把每个站点分别发送到各自的文件，或更改严重级别，我们关于配置 Nginx 日志的指南会详细讲解 error_log 指令。

找到真正的错误消息

日志为空却出现 500 错误，是这类问题中最令人头疼的情况。服务器报告了失败，浏览器显示通用页面，而 /var/log/nginx/error.log 中却没有任何解释。应用可能正在写入另一个日志，或者 PHP-FPM 没有捕获工作进程的输出。检查当前生效的 FPM 配置和日志目标，就能让错误显现出来。

首先找到由 PHP-FPM（而非 PHP CLI）加载的配置文件。在 Ubuntu 和 Debian 上，运行带版本号的 FPM 二进制文件，将 8.3 替换为你已安装的 PHP 版本：

sudo php-fpm8.3 -i | grep 'Loaded Configuration File'

在 Fedora、RHEL 及其衍生发行版上，使用不带版本号的二进制文件：

sudo php-fpm -i | grep 'Loaded Configuration File'

编辑输出中显示的文件，并确认 PHP 会记录错误但不向访客显示：

log_errors = On

error_reporting = E_ALL

display_errors = Off

保留发行版原有的 error_log 目标位置。如果你配置了自定义路径，请先创建该文件并使其可被 PHP-FPM 进程池用户写入。在浏览器中打印错误文本会把文件路径、查询片段和配置细节暴露给每一位访客，而日志能在没有这种风险的情况下提供相同的信息。我们的 PHP 错误报告指南会逐步讲解这些指令以及生产环境中应取的值。

PHP-FPM 默认将工作进程的标准输出和错误流发送到 /dev/null。请在进程池配置中启用捕获，该文件在 Ubuntu 和 Debian 上位于 /etc/php/8.3/fpm/pool.d/www.conf，在 Fedora 和 RHEL 上位于 /etc/php-fpm.d/www.conf。保留任何已有的 php_admin_value[error_log] 设置：

catch_workers_output = yes

php_admin_flag[log_errors] = on

在 Ubuntu 和 Debian 上，重新加载带版本号的 PHP-FPM 服务，使进程池生效：

sudo systemctl reload php8.3-fpm

在 Fedora、RHEL 及其衍生发行版上，重新加载不带版本号的服务：

sudo systemctl reload php-fpm

WordPress 还有自己的一层处理，会把致命错误隐藏在通用消息之后。标准的 wp-config.php 已经将 WP_DEBUG 定义为 false。请将该已有值改为 true，而不要新增第二个定义，然后在标记可编辑区域结束的注释之前加入另外两个常量。最终代码块应如下所示：

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

之后错误会落到 wp-content/debug.log。一旦找到问题，请将 WP_DEBUG 改回 false，并移除 WP_DEBUG_LOG 和 WP_DEBUG_DISPLAY 两行。调试日志若在生产站点上一直开启，会不断增大并记录本不应被读取的安装细节。

配置好日志后，用 tail 跟踪该发行版的 PHP-FPM 日志，并在浏览器中重新加载出错的页面。在 Ubuntu 和 Debian 上，将 8.3 替换为你已安装的 PHP 版本：

sudo tail -f /var/log/php8.3-fpm.log

在 Fedora、RHEL 及其衍生发行版上，跟踪默认的进程池错误日志：

sudo tail -f /var/log/php-fpm/www-error.log

页面出错那一刻出现的日志条目通常就能定位原因。将其时间戳和请求路径与失败的请求进行比对，以免被无关的后台错误干扰。

故障排查

部署后出现了 500 → 检查 Web 根目录下的所有者和权限。部署工具经常以错误的用户写入文件。用 ls -la 核实所有者/组，并用 chown 以及安全的文件/目录权限模式进行修正。

仅动态页面出现 500 → 这通常指向 PHP 或应用层面的故障。检查 Web 服务器日志和 PHP-FPM 日志，然后核实扩展、内存限制和应用配置项。

编辑 .htaccess 后出现 500 → 临时重命名 .htaccess 再测试。如果站点恢复正常，请恢复该文件并逐个段落修复指令。

配置变更后出现 500 → 运行 sudo nginx -t 或 sudo apachectl configtest，它们会报告出错指令所在的文件和行号。测试通过可排除语法错误，但重写循环、上游设置和权限等运行时配置问题仍可能导致 500 响应。

Web 服务器日志中无明确错误 → 启用更详细的应用日志，并在实时跟踪日志（tail -f）的同时复现错误。同时用 systemctl status 检查 Web 服务器、PHP-FPM 和数据库的服务状态。

常见问题解答

作为访客，500 错误是我造成的吗？ 不是。500 错误是服务器端问题，与你的浏览器、设备或网络连接都无关。需要由服务器管理员来修复。

500、502、503 错误有什么区别？ 500 错误表示服务器遇到了意外情况。502（Bad Gateway，错误网关）表示反向代理从上游服务器收到了无效响应。503（Service Unavailable，服务不可用）表示服务器暂时过载或正在维护。

如何在 WordPress 中修复 500 错误？ 最常见的原因是损坏的插件、损坏的 .htaccess 文件，或 PHP 内存限制。重命名插件目录以禁用所有插件，重命名 .htaccess 以重新生成它，并调大 php.ini 中的 memory_limit。如果页面空白而不是显示错误，请参考我们修复 WordPress 白屏死机（White Screen of Death）的指南。

为什么 Nginx 返回 500 而不是 502？ 这两个状态码指向不同的层。当 Nginx 完全无法连通上游时（例如 PHP-FPM 已停止，或 fastcgi_pass 中的套接字路径错误），它会返回 502。当上游已连通却以错误作答时，它会返回 500，这几乎总是意味着 PHP 已运行并抛出了致命错误。502 会指引你去查看服务状态，而 500 会指引你去查看应用日志。

500 错误会由流量过大引起吗？ 会。如果服务器因高流量而耗尽内存或工作进程，就会返回 500 错误。增加服务器资源、启用缓存或使用 CDN 都能有所帮助。

如何预防 500 错误？ 定期监控服务器日志，为错误激增设置告警，在部署到生产环境前于临时环境中测试变更，并保持软件和依赖项处于最新状态。

结语

500 Internal Server Error 表示服务器遇到了它无法处理的问题。最常见的原因是文件权限问题、.htaccess 错误、PHP 故障和数据库连接问题。请始终先检查 Web 服务器错误日志，其中包含触发 500 响应的具体错误。