Apache 日志怎么看？PHP 网站出现 500 错误时可以从哪里开始检查

PHP 网站出现 HTTP 500 Internal Server Error 时，很多人看到浏览器上的“500 Internal Server Error”就开始修改 PHP、重启服务器，甚至怀疑硬盘、内存或者网络设备。实际上，500 只是服务器告诉客户端“请求处理失败”的一个结果，并没有说明具体是哪一层出了问题。

排查这类问题，最有效的方法通常不是不停地改配置，而是沿着一次 HTTP 请求经过的链路逐层定位：浏览器请求进入 Web 服务器，Apache 解析配置并处理请求，如果需要执行 PHP，再交给 PHP-FPM 等后端进程，PHP 程序继续访问数据库、文件系统或者其他服务。任何一层发生异常，都可能最终表现为 500。

因此，第一步应该看 Apache 的错误日志。

Debian、Ubuntu 系统使用 Apache 时，常见位置是 /var/log/apache2/error.log；RHEL、CentOS 等系统常见位置是 /var/log/httpd/error_log。具体路径仍然取决于发行版和管理员配置，不能把某一个路径当成所有服务器的固定标准。

排查时可以先实时观察日志，例如：

tail -f /var/log/apache2/error.log

然后重新访问出现问题的页面。如果日志中同时出现新的错误信息，就可以把浏览器里的 500 与服务器端的具体时间点对应起来。

时间戳非常重要。

例如用户访问 /article.php?id=123 后立即产生 500，如果 Apache 日志同一秒出现 PHP-FPM 连接失败、权限拒绝或者配置语法错误，那么排查范围就已经大幅缩小。相比之下，只看浏览器显示的 500，几乎没有诊断价值。

如果 Apache 日志出现 PHP Fatal error、Uncaught Error、Uncaught Exception、PHP Parse error 等信息，就应该进一步检查 PHP 程序本身。

但如果网站使用的是 PHP-FPM，Apache 日志未必能够记录完整的 PHP 错误。Apache 可能只记录类似“AH01071 Got error from script”或者“Primary script unknown”这样的 FastCGI 层错误，而具体的 PHP 异常则可能出现在 PHP-FPM 或 PHP 的错误日志中。

因此第二步是确认网站到底采用什么 PHP 运行方式。

常见架构包括 Apache + mod_php，以及 Apache + PHP-FPM。现在 PHP-FPM 是非常常见的部署方式。使用 PHP-FPM 时，需要同时关注 PHP-FPM 服务状态和它自己的日志。

例如可以检查：

systemctl status php8.3-fpm

具体服务名称要根据实际安装的 PHP 版本确定。

随后检查 PHP-FPM 日志。不同 Linux 发行版、PHP 版本和安装方式的日志路径可能不同，因此不要机械地认为一定是 /var/log/php-fpm.log。应该先查看 PHP-FPM 的配置和 systemd 日志，确定实际日志位置。

如果 PHP 程序本身没有明显错误，还应该检查 PHP 的 error_log 设置。PHP 的错误记录位置由 PHP 配置决定，也可能受到 PHP-FPM pool 配置影响。

生产服务器通常不应该直接把 PHP 错误显示给访问者。display_errors 应根据生产环境需求关闭，而错误应该记录到服务器端日志中。这样既可以避免向用户泄露文件路径、SQL 查询以及内部程序结构，也方便管理员进行追踪。

第三步是检查 Apache 配置和 .htaccess。

这一步经常被忽略。

如果修改过 .htaccess、VirtualHost、RewriteRule、PHP-FPM 代理配置或者 Apache 模块，500 完全可能在 PHP 执行之前就发生。例如 .htaccess 中存在非法指令、RewriteRule 写错，或者服务器禁止在当前目录使用某些指令，都可能造成 Internal Server Error。

因此修改 Apache 配置以后，可以先进行语法检查：

apachectl -t

或者在某些系统上使用：

httpd -t

如果输出 Syntax OK，至少说明 Apache 配置文件在语法层面没有明显错误。

如果问题发生在 .htaccess 修改之后，还可以重点检查最近改动的规则。很多时候，恢复上一份已知正常的 .htaccess，比一次修改十几个参数更容易确定问题来源。

第四步是检查文件和目录权限。

PHP 网站非常依赖文件系统。如果 PHP-FPM worker 使用的账户没有权限读取 PHP 文件、写入缓存目录、创建上传文件或者访问某个配置目录，就可能产生 500。

例如程序需要写入 cache/、uploads/ 或日志目录，但目录属于另一个用户并且没有相应写权限，PHP 程序可能在运行过程中直接失败。

这里需要区分“Apache 能不能读取网页文件”和“PHP-FPM 能不能访问程序需要的文件”。如果网站采用 Apache + PHP-FPM，两个进程可能使用不同的系统账户，权限问题也因此更加复杂。

第五步才是检查 PHP 自身的运行环境。

例如程序最近从 PHP 8.1 升级到 PHP 8.3，某个旧代码或者扩展可能出现兼容性问题；也可能是某个 PHP 扩展没有安装，程序调用不存在的类或函数，最终导致 Fatal error。

可以使用：

php -v

查看 PHP 版本，也可以使用：

php -m

查看已经加载的扩展。

不过需要注意，命令行 PHP 和 PHP-FPM 不一定使用完全相同的配置。因此命令行执行 php -m 得到的结果不能自动证明 Web 请求中的 PHP-FPM 使用了完全相同的扩展环境。

第六步是检查 PHP-FPM 本身是否出现故障。

如果 PHP-FPM 服务没有运行，或者 Apache 无法连接 PHP-FPM 的 Unix Socket 或 TCP 端口，网站也可能返回 500 或其他 5xx 错误。

例如日志可能出现“connection refused”“No such file or directory”“Primary script unknown”等信息。

这时候应该检查 PHP-FPM 服务状态、监听地址、Unix Socket 路径以及 Apache VirtualHost 中对应的 FastCGI 配置是否一致。

如果 PHP-FPM 进程池已经达到 pm.max_children，或者 worker 因内存不足频繁退出，也可能造成请求失败。这时就需要结合 PHP-FPM 状态、系统内存、CPU 和日志进行判断，而不能只看 Apache。

第七步才是检查数据库和外部服务。

很多 PHP 网站表面上是“PHP 500”，实际错误可能来自 MySQL、Redis、外部 API、文件存储或者其他内部服务。例如数据库连接失败、查询超时、连接数量耗尽，PHP 程序捕获异常后可能直接返回 500。

因此，如果 Apache 和 PHP-FPM 都没有明显错误，就应该继续查看应用程序日志以及数据库日志。

这也是为什么单纯运行 curl -I 并不能解决问题。

curl -I https://example.com/test.php 可以快速确认 HTTP 状态码和响应头，但它只告诉你结果，不会自动告诉你 PHP 为什么失败。使用 curl -v 可以看到请求和响应过程，对于检查重定向、TLS、Host、代理以及响应头很有帮助，但服务器端错误仍然需要结合日志判断。

如果需要复现一个具体请求，可以使用：

curl -v https://example.com/test.php

对于 POST、Cookie、Authorization Header 或特定 API 请求，则应该尽量模拟实际请求环境。这样可以判断问题是否只出现在某一种请求条件下。

至于 mod_security，它确实可能影响请求处理，但不应该看到 500 就首先禁用它。如果服务器安装并启用了 ModSecurity，应当检查它自己的审计日志以及具体规则命中情况。如果日志明确显示某条安全规则拦截了请求，再针对规则进行测试和调整。

直接关闭整个安全模块作为长期解决办法并不可取，因为这样可能只是让错误消失，却同时失去了原有的安全防护。

strace 则应该放在更后面。

它可以跟踪进程执行的系统调用，在怀疑底层文件访问、网络调用、进程异常或者原生扩展发生崩溃时提供非常有价值的信息。但它属于高级诊断工具。对于普通的 PHP Fatal error、配置错误、权限错误或者 PHP-FPM 连接问题，没有必要一开始就使用 strace。

如果出现 Segmentation fault，尤其是 PHP-FPM worker 或某个原生扩展发生崩溃，这时才应该考虑进一步检查 PHP 扩展、动态链接库以及系统层面的错误日志。因为 PHP 本身主要由 C/C++ 等底层组件实现，某个扩展的 ABI 不兼容或者原生代码缺陷，确实可能造成普通 PHP 异常无法解释的进程崩溃。

资源问题也应该分层检查。

PHP 的 memory_limit、PHP-FPM 的进程池设置、操作系统的内存、文件描述符限制以及 CPU 都属于不同层面的限制。不能简单运行 ulimit -a，然后就认为已经完成 PHP 资源诊断。

例如 PHP 程序可能因为 memory_limit 被触发而失败，也可能是 PHP-FPM 同时启动过多 worker 导致服务器内存耗尽，还可能是磁盘空间满了，导致 PHP 无法写入 session、缓存或者日志文件。

因此可以结合：

free -h

df -h

top

或者：

htop

观察系统资源，但必须把这些数据与错误发生的时间对应起来。单纯看到 CPU 90% 并不能证明 500 就是 CPU 导致的。

排查生产网站时，还有一个容易被忽略的问题：不要为了调试而把详细错误直接输出给访问者。

例如临时增加：

error_log("Debug message");

确实可以帮助确认代码执行到了哪一步，但更合理的方式通常是写入专门的应用日志，并在问题定位完成后删除临时调试代码。生产环境不应该长期保留大量调试输出，更不能把数据库密码、用户数据、Token 等敏感信息写入日志。

一个比较有效的 500 排查顺序可以概括为：

先记录发生错误的准确时间和 URL，再看 Apache error log；随后确认 PHP 是 mod_php 还是 PHP-FPM，并检查对应的 PHP-FPM 和 PHP 错误日志；如果没有明显 PHP 错误，再检查 .htaccess、VirtualHost 和 Apache 配置；接着检查文件权限、PHP 版本和扩展；然后检查 PHP-FPM 进程池以及数据库、Redis、外部 API 等依赖；最后才考虑系统资源、原生 PHP 扩展崩溃和 strace 等高级诊断手段。

500 本身不是答案，只是一个结果。

真正有效的服务器排查，是找到“哪个组件在什么时间、因为哪一个具体原因拒绝完成这次请求”。一旦能够把一次 500 请求对应到 Apache、PHP-FPM、PHP 程序、数据库或者系统层面的具体日志，问题通常就从一个模糊的“网站打不开”，变成了一个可以验证和修复的技术问题。