504错误是nginx网关超时，非php自身超时；需优先检查php错误日志确认是否触发max_execution_time，再同步调整nginx的fastcgi_read_timeout等参数与php超时值一致，并确保重载配置和重启服务生效。
直接改 max_execution_time 通常没用，504 是 Nginx 主动放弃等待的结果，不是 PHP 自己“超时退出”——PHP 可能还在跑，只是 Nginx 先断了连接。
先确认是不是真被 max_execution_time 卡住
别一上来就改配置。打开 PHP 错误日志（通常是 /www/wwwlogs/php_error.log），搜 Maximum execution time of。如果没这句，说明脚本根本没触发 PHP 层超时，改 max_execution_time 白费劲。
同时用 php -i | grep max_execution_time 查当前生效值，注意它可能被 .user.ini 或宝塔界面覆盖，优先级顺序是：.user.ini > 宝塔「PHP 设置」> php.ini 文件本身。
- 没日志报错 +
max_execution_time值合理（比如 300），问题大概率在 Nginx 或网络层 - 有报错 + 值太小（比如 30），才值得往下调
宝塔里改 max_execution_time 必须同步三处
宝塔的 PHP 配置是分层的，漏改任何一层都会失效：
- 网站 → 对应站点 → 「PHP版本」→ 「设置」→ 「配置修改」：改这里影响该站点使用的 PHP-FPM 池默认值
- 软件商店 → 找到对应 PHP 版本 → 「设置」→ 「配置文件」：手动改
php.ini，但会被上层界面操作覆盖（重启前临时有效） - 项目根目录或子目录下的
.user.ini：优先级最高，会覆盖前两者，常见于多环境共存场景
改完必须点「重载配置」+「重启 PHP 服务」，只点「保存」不生效。顺手执行 ps aux | grep php-fpm 看进程启动时间是否更新。
fastcgi_read_timeout 比 max_execution_time 更关键
Nginx 默认 fastcgi_read_timeout 是 60 秒，它比 PHP 的 max_execution_time 更早放弃等待。哪怕你把 PHP 设成 600 秒，Nginx 在第 61 秒就断开了，照样 504。
在宝塔「网站」→「设置」→「配置文件」里，找到 location ~ \.php(.*)$ 块，在 include fastcgi.conf 之前加：
fastcgi_read_timeout 300; fastcgi_send_timeout 300; fastcgi_connect_timeout 300;
这三项必须和 max_execution_time 一致，且不能低于它。否则 Nginx 先退场，PHP 白忙活。
设成 0 或 set_time_limit(0) 是危险操作
max_execution_time = 0 在生产环境极不推荐——一个死循环或卡住的远程请求会拖垮整个 PHP-FPM 进程池，引发雪崩。
更关键的是：set_time_limit(0) 在 PHP-FPM 模式下基本无效，FPM 层有自己的 request_terminate_timeout 控制（路径类似 /www/server/php/80/etc/php-fpm.conf），硬写这句没用。
真正要查卡点，用 strace -p $(pgrep php-fpm) -e trace=connect,sendto,recvfrom 抓系统调用，比盲目调参靠谱得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
