504 gateway timeout本质是nginx在三段等待（连接、发送、读取）中任一环节超时主动断连，需同步调大fastcgi_connect_timeout、fastcgi_send_timeout和fastcgi_read_timeout，并检查php-fpm的request_terminate_timeout等限制。
504 Gateway Timeout 本质是 Nginx 等不到 PHP-FPM 的响应，不是 PHP 执行慢本身的问题，而是 Nginx 主动断开了连接 —— 所以调 fastcgi_read_timeout 是对的，但只调它常不够。
为什么只改 fastcgi_read_timeout 还会 504
Nginx 到 PHP-FPM 是“三段等待”：建立连接（fastcgi_connect_timeout）、发送请求（fastcgi_send_timeout）、读取响应（fastcgi_read_timeout）。任一环节超时都会触发 504，而宝塔默认只暴露了 fastcgi_read_timeout 的配置入口。
-
fastcgi_connect_timeout默认 60s，若 PHP-FPM 进程卡死或 socket 文件不可达，可能在此阶段就失败 -
fastcgi_send_timeout默认 60s，大文件上传或 POST 数据体过大时容易触达 -
fastcgi_read_timeout默认 60s，对应你遇到的“PHP 处理时间长但 Nginx 先放弃”的典型场景
在宝塔里正确修改这三项 timeout 参数
宝塔 Web 界面不提供 fastcgi_connect_timeout 和 fastcgi_send_timeout 的输入框，必须手动编辑配置。位置在：/www/server/panel/vhost/nginx/你的站点.conf，找到 location ~ \.php(.*)$ 块内部，在 fastcgi_pass 行下方插入：
fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300;
注意：这三个值建议设为相同（如 300），避免某一段先超时；不要设成 0（Nginx 不支持无限等待）；改完必须点击宝塔面板右上角「重载配置」，不是「重启 Nginx」。
还要同步检查 PHP-FPM 自身的超时限制
即使 Nginx 等很久，PHP-FPM 也可能自己 kill 掉长任务。检查 /www/server/php/版本/etc/php-fpm.d/www.conf 中这两项：
-
request_terminate_timeout = 0（推荐设为 0，表示不限制单请求执行时间） -
request_slowlog_timeout = 10s（可选，用于记录慢请求，不影响超时逻辑）
改完需执行 service php-fpm-版本 restart（例如 service php-fpm-81 restart），否则 PHP 层限制仍生效。
验证是否真正生效 & 容易踩的坑
改完别急着测业务，先用最简方式验证 Nginx 层 timeout 是否提升：
- 写一个
sleep.php：，访问它，看是否返回 504 或成功 - 检查 Nginx 错误日志：
/www/wwwlogs/你的站点.error.log，出现upstream timed out后带具体 timeout 类型（connect/send/read），就能定位是哪一环卡住 - 宝塔「网站」→「设置」→「配置文件」里改的只是当前站点，如果用了反向代理或子目录部署，可能要查全局配置
/www/server/nginx/conf/nginx.conf
最常被忽略的是：PHP-FPM 子进程数（pm.max_children）不足导致新请求排队，看起来像超时 —— 实际是等不到 worker，而不是等响应。
