Nginx+PHP5.6.30/FPM环境set_time_limit(x)触发30秒超时致命错误求助

我之前碰到过好几个类似的案例，这种set_time_limit()完全失效、总是触发30秒超时的情况，大多是PHP-FPM或者安全模块的配置在“搞事情”，咱们一步步来排查解决：

1. 先检查PHP.ini的基础时间限制 #

首先找到你的PHP5.6对应的php.ini文件——你可以通过php -i | grep php.ini命令快速定位路径，通常在/etc/php/5.6/fpm/php.ini或者编译安装的/usr/local/php/etc/php.ini这类位置。

打开后重点看两个参数：

• max_execution_time：这是PHP默认的脚本最大执行时间，默认30秒，但正常情况下set_time_limit()应该能覆盖它。如果这个参数被设置成了-1（无限制）那没问题，但如果是30且被锁定（比如用php_admin_value在FPM配置里强制设置），就会导致set_time_limit()失效。
• max_input_time：这个是脚本接收POST/GET输入的最大时间，有些时候会和执行时间混淆，也建议检查是否设为30秒，必要时调大到和你期望的时间一致。

修改后一定要重启PHP-FPM服务，比如执行service php5.6-fpm restart或者systemctl restart php5.6-fpm。

2. 重点检查PHP-FPM的request_terminate_timeout #

这是最容易被忽略的关键设置！PHP-FPM的这个参数会强制终止超过指定时间的请求，优先级比PHP的max_execution_time和set_time_limit()都高——也就是说，哪怕你在脚本里设了300秒，只要FPM的这个参数是30秒，到点就会直接杀掉进程，触发那个致命错误。

找到PHP-FPM的池配置文件（通常是/etc/php/5.6/fpm/pool.d/www.conf），搜索request_terminate_timeout：

• 如果它被设为30s，那就是问题根源，把它改成你需要的时间（比如300s），或者直接注释掉，让它继承PHP的max_execution_time设置。
• 修改后同样要重启PHP-FPM才能生效。

3. 排查是否有安全模块限制 #

有些服务器会安装suhosin这类安全扩展，它可能会直接禁用set_time_limit()或者强制覆盖执行时间限制：

• 用php -m命令查看已加载的模块，看看有没有suhosin。
• 如果存在，检查php.ini里的suhosin.executor.max_time_limit参数——这个参数会限制脚本的最大执行时间，而且会忽略set_time_limit()的设置。你可以把它调大，或者如果不需要这个安全模块的话，直接禁用它（在php.ini里注释掉加载suhosin的行）。

4. 确认测试环境的一致性 #

确保你的测试脚本是通过Nginx+PHP-FPM运行的，而不是CLI命令行模式——CLI模式下max_execution_time默认是0（无限制），和FPM环境的配置完全独立。你可以在测试脚本里加一行phpinfo();，访问后查看Server API字段，确认是FPM/FastCGI，同时检查页面里max_execution_time的实际生效值。

5. 顺带检查Nginx的超时设置 #

虽然你的错误提示明确是PHP的执行时间超时，但Nginx的fastcgi_read_timeout如果设置过短（比如30秒），可能会在PHP脚本还没执行完就断开连接，导致混淆。你可以在Nginx的server配置块里查看这个参数，把它调到和PHP设置一致的时间（比如300秒），然后重启Nginx。

修改完配置后，用这个更严谨的测试脚本验证：

<?php 
set_time_limit(300); 
// 加循环和输出刷新，确保能看到执行过程
for($i=0; $i<31; $i++){
    sleep(1);
    echo "已运行 {$i} 秒<br>";
    flush();
    ob_flush();
}
echo '测试完成！'; 
?>

如果能顺利运行到30秒以上不报错，就说明问题解决了。

内容的提问来源于stack exchange，提问作者Ales Malusek