ThinkPHP 6.0 解决Nginx与PHP-FPM超时传导504

核心判断：504错误的原因不在ThinkPHP框架本身，而是Nginx、PHP-FPM和PHP脚本三层之间的超时配置未对齐。简单来说，某一层先断开连接，上层误判为网关超时，返回504。

ThinkPHP 6.0 不接管HTTP请求的超时控制，因此无需在框架代码中排查。问题链路清晰：Nginx等待PHP-FPM响应，PHP-FPM等待PHP脚本执行，任一环节超时，整个链条中断。

Nginx层：超时参数必须同步调整

504常见原因是fastcgi_read_timeout被触发——Nginx等待PHP-FPM返回响应时间过长。但仅调整此参数不够，需考虑以下四个：

• fastcgi_read_timeout 300; —— Nginx等待PHP-FPM输出响应的空闲总时间。建议设为PHP最大执行时间的1.2倍，留有余量。
• fastcgi_connect_timeout 60; —— 建立到PHP-FPM的连接超时，尤其使用TCP监听时需注意。
• fastcgi_send_timeout 300; —— Nginx向PHP-FPM发送完整请求体（如大文件上传）期间的写入间隔超时。
• 若使用proxy_pass转发而非fastcgi_pass，则需改用proxy_read_timeout等参数。

这些参数应放在location ~ .php$ { ... }块内或server级别，避免被其他配置覆盖。

PHP-FPM层：手动对齐是关键

PHP-FPM不会自动感知Nginx的超时设置，需手动对齐。编辑/etc/php/*/fpm/pool.d/www.conf，确认以下三项：

• request_terminate_timeout = 300 —— 强制终止超时请求。注意：该值必须≥Nginx的fastcgi_read_timeout。
• request_slowlog_timeout = 10s —— 配合slowlog定位卡点，建议开启。
• slowlog = /var/log/php-fpm/www-slow.log —— 日志路径需可写。

需警惕：request_terminate_timeout默认值为0（不限制）。若不显式设置，PHP-FPM可能无限等待，而Nginx先超时返回504。

PHP脚本层：主动兜底，避免干等

ThinkPHP 6.0无法自动中断超时脚本，但可通过以下方式提前响应，避免拖累整个请求：

• 在全局中间件handle()开头记录起始时间：$start = microtime(true);
• 在关键业务逻辑前插入判断：若执行时间超过280秒（留20秒余量给Nginx/FPM处理），直接返回504响应。
• 对数据库查询加会话级超时，例如MySQL 5.7.8+可使用SET SESSION max_execution_time = 250000（250秒）。

验证与排查要点

配置修改完成后，需验证：

• 执行sudo nginx -t && sudo systemctl reload nginx和sudo systemctl restart php*-fpm（注意服务名，如php8.1-fpm）。
• 查看Nginx error log中是否有upstream timed out记录；PHP-FPM slowlog中是否有长耗时记录。
• 使用curl -v http://your-domain/test-timeout.php模拟慢请求，观察返回状态码和耗时。
• 确保max_execution_time（php.ini）、request_terminate_timeout（FPM）、fastcgi_read_timeout（Nginx）三者数值梯度合理，且FPM的值≥Nginx的值。

此事不复杂，但容易忽略。希望本文能助你少走弯路。