504错误是Nginx在等待PHP-FPM响应时超时所致，仅调大php.ini的max_execution_time无效；必须同步配置Nginx的fastcgi_read_timeout、PHP-FPM的request_terminate_timeout及PHP的max_execution_time，且三者需逐层递增或相等，并分别重载Nginx与重启PHP-FPM服务。
504 Gateway Timeout 不是 PHP 脚本没跑完，而是 Nginx 在等 PHP 回应时先放弃了——只调大 max_execution_time 没用，必须同步改三处：Nginx 的 fastcgi_read_timeout、PHP-FPM 的 request_terminate_timeout、PHP 的 max_execution_time，且数值要逐层递增或相等。
为什么改了 php.ini 的 max_execution_time 还是 504？
因为 PHP 层的超时只是“脚本能活多久”，而 Nginx 和 PHP-FPM 各自还有更早的“断连开关”：
-
fastcgi_read_timeout是 Nginx 等 PHP-FPM 返回响应的最大时间，超时直接返回 504 -
request_terminate_timeout是 PHP-FPM 主动 kill 请求的硬限制，优先级高于max_execution_time -
max_execution_time只在 PHP 脚本内部起作用；如果前两者已触发，它根本没机会执行到判断逻辑
常见错误现象：改完 php.ini 里 max_execution_time = 600，但请求卡在 30 秒就报 504——大概率是 fastcgi_read_timeout 还是默认的 30 或 60。
必须同步修改的三个关键参数（以 600 秒为例）
三者关系不是“随便设一样就行”，而是要有明确层级：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 配置中，在站点【配置文件】→
location ~ \.php(.*)$ {块内加：fastcgi_read_timeout 600;<br>fastcgi_send_timeout 600;<br>fastcgi_connect_timeout 600;
三个值建议一致，且 ≥ PHP-FPM 的request_terminate_timeout - PHP-FPM 配置中，编辑
/www/server/php/80/etc/php-fpm.conf（版本号按实际替换），确认：request_terminate_timeout = 600
若被注释掉，需取消注释；该值不能小于max_execution_time - PHP 配置中，进【软件商店】→ 对应 PHP 版本 → 【设置】→ 【配置修改】，改：
max_execution_time = 600<br>max_input_time = 600<br>memory_limit = 512M
注意：memory_limit必须同步加大，否则大数据处理可能在超时前先 OOM
改完后必须分别操作：重载 Nginx 配置 + 重启对应 PHP-FPM 服务（不是“重载”，是完整重启）。
.user.ini 方式只对单站生效，但有两个硬前提
想只给 WordPress 后台导出或 Laravel 队列任务放宽限制？用 .user.ini 更安全，但容易踩坑：
- 文件必须放在网站根目录（如
/www/wwwroot/my-site/），名字是.user.ini（开头带点） - 内容只能写 ini 格式，不能有空格或引号：
max_execution_time = 600<br>max_input_time = 600
- 权限必须是
644，否则 PHP 直接忽略该文件 - 最关键：PHP 必须启用
user_ini.filename。去phpinfo()页面搜这个词，如果值是none或空，说明被禁用了——得回 PHP 设置里手动打开，或直接改php.ini加上：user_ini.filename = ".user.ini"
别漏掉 CLI 场景和框架层的独立超时
大数据处理常走计划任务或命令行（比如 wp cron event run 或 php artisan queue:work），这些走的是 CLI 模式，读的不是 FPM 的 php.ini：
- 查 CLI 使用的配置：
/www/server/php/80/bin/php --ini（路径按实际版本替换） - CLI 的
max_execution_time默认是 0（不限制），但某些宝塔模板会显式设为 30——得单独改对应 CLI 的php.ini - WordPress 的
wp_remote_post()、Laravel 的Http::timeout()、cURL 的CURLOPT_TIMEOUT都是应用层超时，和 PHP 执行总时长无关，也要检查
真正复杂的地方在于：你看到的“超时”，可能是 cURL 报 curl error 28，也可能是 MySQL 报 SQLSTATE[HY000]: General error: 2013，还可能是 OPcache 缓存失效导致反复编译卡住——得先看错误日志里那行具体报错，再决定动哪一层。
