PHP-FPM 一出问题，很多排查都会从错误日志开始，但真正难的往往不是“看日志”，而是不知道先看哪一段、哪一个字段最关键。本文按 Ubuntu 服务器上的实际排障流程重组内容：先确认日志文件在哪里，再用几条常用命令快速筛选，接着拆解一条日志的组成，最后对照常见错误类型和修复思路，帮助你把日志内容尽快转成可执行的排查结论。
先确认 PHP-FPM 错误日志写到了哪里
在 Ubuntu 系统里，PHP-FPM 错误日志常见的默认位置是 /var/log/php-fpm/error.log，有些版本也可能使用 /var/log/php-fpm.log。
如果你发现默认路径下没有日志文件，不要急着判断服务没报错，先去配置文件里确认日志路径是否被改过。常见配置文件位置是：
/etc/php/{version}/fpm/pool.d/www.conf重点检查其中的 error_log 指令。实际环境里，日志经常会被重定向到其他文件，例如 /var/log/php7.4-fpm.log。这一步的目标很明确：先找到“真实写日志的文件”，后面的排查才有意义。
三条最常用的日志查看命令
找到日志文件后，接下来要解决的是“怎么高效看”。相比直接打开整份日志，下面几条命令更适合排障场景。
实时观察新报错
tail -f /var/log/php-fpm/error.log这条命令适合边复现问题边看输出。比如你刷新页面、重新发起请求或重启服务后，可以马上看到是否有新的报错写入日志。
分页翻看并搜索关键字
less +F /var/log/php-fpm/error.log当日志内容比较多时，less 更适合做上下文排查。你可以上下翻页，也可以按 / 后输入关键字搜索，比如查找 Fatal，先把致命错误找出来。
先过滤出重点错误
grep "Fatal" /var/log/php-fpm/error.log如果你已经大致知道要找什么，grep 会更直接。它能快速筛出包含指定关键词的行，适合先锁定严重错误，再回头看完整上下文。
一条 PHP-FPM 错误日志通常包含什么
PHP-FPM 日志看起来杂，但大多数报错都能拆成几个固定部分。掌握这个结构之后，读日志会快很多。
时间戳
例如 [01-Sep-2023 12:34:56]。它告诉你错误发生的准确时间，便于和 Nginx、数据库、系统服务等其他日志对照，确认是不是同一时段的连锁问题。
错误级别
常见级别从严重到轻微包括：emergency、alert、critical、error、warning、notice、info、debug。排查时通常优先处理高等级项，尤其是会导致请求失败、服务异常退出的报错。
错误消息本体
这是最核心的内容，例如：
PHP Fatal error: Uncaught Error: Call to undefined function foo()这类信息通常已经直接指出了问题类型，例如未定义函数、内存耗尽、连接失败或文件无法访问。
请求上下文
部分日志还会带上请求 URI、状态码等上下文，例如 GET /index.php HTTP/1.1" 500。这能帮助你把错误和具体访问请求对应起来，判断问题是全站性的，还是只发生在某个接口、某个页面。
常见报错怎么读，问题通常出在哪
下面这几类，是 PHP-FPM 排障里最常遇到的日志类型。真正实用的阅读方法，不是死记错误文本，而是把“报错样式”和“优先排查方向”对应起来。
PHP 代码致命错误
PHP Fatal error: Uncaught Error: Call to undefined function foo() in /var/www/my_script.php:12这说明脚本调用了不存在的 foo()，执行会直接终止。常见原因包括函数名拼写错误、相关库文件没有引入，或者依赖的 PHP 扩展没有安装。
子进程崩溃
child exited on signal 7 (SIGBUS)这类日志表示 PHP-FPM 子进程因为异常信号退出，常见于非法内存访问、底层文件系统问题，或者脚本触发了更底层的运行时错误。这类问题通常比普通 PHP 代码报错更偏系统层面。
数据库连接失败
PDOException: SQLSTATE[HY000] [2002] Connection refused这通常说明 PHP 无法连接数据库。优先检查数据库服务是否已启动，以及连接参数中的 host、port、username、password 是否正确。
内存耗尽
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)这里的关键信息是脚本已超过 memory_limit 的限制，示例中的默认值是 128M。短期可以考虑提高限制，但更值得优先确认的是：是否存在大数组堆积、循环未释放资源，或者一次性处理了过大的数据集。
套接字权限不足
connect() to unix:/run/php/php7.4-fpm.sock failed (13: Permission denied)这表示 Web 服务器无法连接 PHP-FPM 的 Unix Socket。最常见原因是 listen.owner、listen.group 没有配置为 Web 服务器用户，例如 www-data，或者 Socket 所在目录权限不正确。
服务启动时无法绑定套接字
couldn't bind to socket /run/php/php7.4-fpm.sock (2: No such file or directory)这种报错往往会直接导致 PHP-FPM 启动失败。优先检查 Socket 文件所在目录是否存在、监听配置是否写错、端口是否被占用，以及配置文件本身是否存在语法问题。
看到报错后，下一步该怎么排
读懂日志只是第一步，真正有效的排障还需要把日志内容落到对应的检查动作上。
先排代码和语法问题
如果是未定义函数、类不存在、语法错误这类报错，可以先检查代码逻辑、拼写和依赖加载是否完整。基础语法检查命令如下：
php -l script.php验证 PHP-FPM 配置文件
当日志指向启动失败、Socket 异常或配置加载问题时，先测试配置语法：
php-fpm -t这一步通常能尽快发现配置文件中的明显错误。
检查目录和用户权限
如果错误与文件访问、Socket 连接或 Web 服务用户权限有关，要确认 PHP-FPM 进程用户是否能访问脚本目录、运行目录和相关文件。文中给出的常用修复命令是：
chown -R www-data:www-data /var/www处理内存与进程异常
对于内存耗尽问题，可以临时提高 memory_limit，例如改为：
memory_limit = 256M但从长期看，更重要的是优化代码，减少不必要的大数组和高内存操作。
如果 PHP-FPM 进程频繁崩溃，单看应用层日志可能不够，这时可以进一步跟踪系统调用：
strace -p 它有助于确认进程究竟卡在文件访问、网络调用还是其他系统层操作上。
性能问题可以打开慢日志
有些问题不会直接报错，而是请求越来越慢。这种情况下，可以在 www.conf 中开启慢日志：
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s这样，执行时间超过 5 秒的脚本会被记录下来，适合定位拖慢响应的具体代码。
排查 PHP-FPM 日志时的实用顺序
实际工作里，最省时间的方式通常不是从头读完整份日志，而是按固定顺序走一遍：先确认日志路径，再用 tail -f、less +F、grep 找到关键报错，然后看时间戳、错误级别、报错消息和请求上下文，最后把日志内容映射到代码、配置、权限、资源限制或慢查询这几类问题上。
只要把这个顺序固定下来，PHP-FPM 日志基本就不再是“看不懂的英文堆”，而是一份可读、可定位、可验证的故障线索表。
