如何解决phpEnv Nginx导致的504 Gateway Timeout问题?
- 内容介绍
- 文章标签
- 相关推荐
本文共计970个文字,预计阅读时间需要4分钟。
504 Gateway Timeout 错误并非 PHP 问题,而是 Nginx 在三阶段通信中任一环节先放弃等待——只需更改 fastcgi_read_timeout 大概就能解决。
为什么只加 fastcgi_read_timeout 还是 504
Nginx 和 PHP-FPM 之间是分阶段握手的:fastcgi_connect_timeout(连 socket)、fastcgi_send_timeout(发 POST 数据)、fastcgi_read_timeout(等响应)。宝塔默认只暴露最后一项,前两项仍卡在 60 秒。比如大文件上传时卡在 send 阶段,或 PHP-FPM 进程僵死导致 connect 失败,都会直接 504,根本等不到读超时。
- 必须在站点配置文件的
location ~ \.php(.*)$块内,fastcgi_pass行下方手动插入三行: fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;- 三个值保持一致,避免某一段先断;不能设为 0(Nginx 不支持)
- 改完点宝塔右上角「重载配置」,不是「重启 Nginx」
PHP-FPM 层的 request_terminate_timeout 必须同步放开
即使 Nginx 等足 300 秒,PHP-FPM 自己也可能提前 kill 掉进程。这个值在 /www/server/php/81/etc/php-fpm.d/www.conf(版本号按实际替换)里,不是 php.ini 中的 max_execution_time。
- 查当前值:
grep request_terminate_timeout /www/server/php/81/etc/php-fpm.d/www.conf - 若为
0,表示不限制,可跳过;若为60或更小,需改为300或直接注释掉(注释后以全局默认为准) - 改完执行:
service php-fpm-81 restart(版本号要匹配) - 注意:
max_execution_time是 PHP 脚本层限制,它被request_terminate_timeout包裹——后者不放宽,前者再大也没用
缓冲区太小也会触发 504,尤其返回大 JSON 或导出文件时
当 PHP 输出内容超过 Nginx 默认的 fastcgi_buffer_size(通常 64k),Nginx 会尝试写临时文件;若磁盘慢或权限不对,就卡住并最终超时。
立即学习“PHP免费学习笔记(深入)”;
- 在站点配置的
location ~ \.php(.*)$块内,添加或修改以下四行: fastcgi_buffer_size 128k;fastcgi_buffers 4 256k;fastcgi_busy_buffers_size 512k;fastcgi_temp_file_write_size 512k;- 这些值不宜盲目翻倍,建议从
128k/2/256k/256k起步,观察错误日志是否还有upstream buffer is too small类提示 - 确认
/www/wwwroot/你的站点/tmp目录对www用户可写(否则缓冲区退化为阻塞模式)
验证和定位哪一环真超时,别靠猜
改完配置别急着测业务逻辑,先用最简方式确认生效路径:
- 写一个
sleep.php:<?php sleep(200); echo 'done'; ?> - 访问它,看是返回 504 还是成功;失败则立刻查 Nginx 错误日志:
tail -f /www/wwwlogs/你的站点.error.log - 日志里出现
upstream timed out (110: Connection timed out) while connecting to upstream→ 卡在connect - 出现
while sending request to upstream→ 卡在send - 出现
while reading response header from upstream→ 卡在read - 如果日志没报错但页面白屏,可能是 PHP-FPM 进程崩溃,检查
ps aux | grep php-fpm和systemctl status php-fpm-81
真正卡点往往藏在数据库慢查询、未释放的 cURL 句柄、或 .user.ini 里偷偷覆盖的 max_execution_time —— 超时参数只是兜底,不是根治手段。
本文共计970个文字,预计阅读时间需要4分钟。
504 Gateway Timeout 错误并非 PHP 问题,而是 Nginx 在三阶段通信中任一环节先放弃等待——只需更改 fastcgi_read_timeout 大概就能解决。
为什么只加 fastcgi_read_timeout 还是 504
Nginx 和 PHP-FPM 之间是分阶段握手的:fastcgi_connect_timeout(连 socket)、fastcgi_send_timeout(发 POST 数据)、fastcgi_read_timeout(等响应)。宝塔默认只暴露最后一项,前两项仍卡在 60 秒。比如大文件上传时卡在 send 阶段,或 PHP-FPM 进程僵死导致 connect 失败,都会直接 504,根本等不到读超时。
- 必须在站点配置文件的
location ~ \.php(.*)$块内,fastcgi_pass行下方手动插入三行: fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;- 三个值保持一致,避免某一段先断;不能设为 0(Nginx 不支持)
- 改完点宝塔右上角「重载配置」,不是「重启 Nginx」
PHP-FPM 层的 request_terminate_timeout 必须同步放开
即使 Nginx 等足 300 秒,PHP-FPM 自己也可能提前 kill 掉进程。这个值在 /www/server/php/81/etc/php-fpm.d/www.conf(版本号按实际替换)里,不是 php.ini 中的 max_execution_time。
- 查当前值:
grep request_terminate_timeout /www/server/php/81/etc/php-fpm.d/www.conf - 若为
0,表示不限制,可跳过;若为60或更小,需改为300或直接注释掉(注释后以全局默认为准) - 改完执行:
service php-fpm-81 restart(版本号要匹配) - 注意:
max_execution_time是 PHP 脚本层限制,它被request_terminate_timeout包裹——后者不放宽,前者再大也没用
缓冲区太小也会触发 504,尤其返回大 JSON 或导出文件时
当 PHP 输出内容超过 Nginx 默认的 fastcgi_buffer_size(通常 64k),Nginx 会尝试写临时文件;若磁盘慢或权限不对,就卡住并最终超时。
立即学习“PHP免费学习笔记(深入)”;
- 在站点配置的
location ~ \.php(.*)$块内,添加或修改以下四行: fastcgi_buffer_size 128k;fastcgi_buffers 4 256k;fastcgi_busy_buffers_size 512k;fastcgi_temp_file_write_size 512k;- 这些值不宜盲目翻倍,建议从
128k/2/256k/256k起步,观察错误日志是否还有upstream buffer is too small类提示 - 确认
/www/wwwroot/你的站点/tmp目录对www用户可写(否则缓冲区退化为阻塞模式)
验证和定位哪一环真超时,别靠猜
改完配置别急着测业务逻辑,先用最简方式确认生效路径:
- 写一个
sleep.php:<?php sleep(200); echo 'done'; ?> - 访问它,看是返回 504 还是成功;失败则立刻查 Nginx 错误日志:
tail -f /www/wwwlogs/你的站点.error.log - 日志里出现
upstream timed out (110: Connection timed out) while connecting to upstream→ 卡在connect - 出现
while sending request to upstream→ 卡在send - 出现
while reading response header from upstream→ 卡在read - 如果日志没报错但页面白屏,可能是 PHP-FPM 进程崩溃,检查
ps aux | grep php-fpm和systemctl status php-fpm-81
真正卡点往往藏在数据库慢查询、未释放的 cURL 句柄、或 .user.ini 里偷偷覆盖的 max_execution_time —— 超时参数只是兜底,不是根治手段。

