Laravel请求返回504的直接原因是同步阻塞而非队列本身——当本该异步的任务（如dispatch未配delay、QUEUE_CONNECTION=sync、worker未运行）被同步执行且耗时超Nginx proxy_read_timeout（默认60秒），网关即中断连接。
有关系，但不是直接因果关系——Laravel 应用本身不会因为开了队列就返回 504，而是当「本该异步处理的任务被错误地放在同步请求里执行」，且耗时超过网关超时阈值时，才会触发 504。
为什么 Laravel 请求会卡出 504，而不是进队列？
常见误区是认为“用了 dispatch() 就万事大吉”，但实际中大量 504 源于以下情况：
- 开发者写了
dispatch(new SendEmailJob())，但没加->delay()或没配好队列驱动（比如仍用sync驱动），导致 job 立即同步执行 - 控制器里混用了同步逻辑：比如在发送邮件前先做了全量数据库聚合、调用了慢速外部 API、或手动调用了
handle() -
QUEUE_CONNECTION=sync在生产环境未被覆盖，.env 里还是默认值，本地测试没问题，上线后所有 job 全部阻塞主线程 - 队列 worker 没跑起来（
php artisan queue:work未启动/崩溃/被 systemd kill 掉），而代码又没做 fallback 处理，请求就一直等下去
proxy_read_timeout 和队列 worker 的时间关系
Nginx 默认的 proxy_read_timeout 是 60 秒，而 Laravel 队列 job 的默认超时（timeout 属性）是 60 秒，但这两个超时完全不重叠：
Gateway Monitor Installer
下载
在 macOS 上通过 LaunchAgent 安装、更新、运行和移除 OpenClaw Gateway Monitor + Gateway Watchdog。适用于用户请求一键部署监控的场景。
-
proxy_read_timeout控制的是 Nginx 等待 PHP-FPM 返回 HTTP 响应的时间 - 队列 worker 的
--timeout控制的是单个 job 最长允许运行多久，它发生在响应已返回之后 - 也就是说：只要请求还没返回 HTTP 响应，哪怕你 dispatch 了 10 个 job，Nginx 仍在计时；一旦超时，直接砍断连接，worker 根本没机会启动
怎么确认是不是队列误用导致的 504？
别猜，直接查链路关键点：
- 看 Nginx 错误日志：
/var/log/nginx/error.log里搜upstream timed out，确认是不是卡在 upstream（PHP-FPM） - 看 Laravel 日志：
storage/logs/laravel.log里有没有Processing或Processedjob 记录——如果没有，说明 job 根本没发出去或被 sync 驱动当场执行了 - 临时把队列驱动切到
database或redis，然后 curl 请求接口，立刻去查jobs表：SELECT * FROM jobs ORDER BY id DESC LIMIT 5;——如果表里有新记录，说明 dispatch 成功；如果没记录，问题出在 dispatch 前 - 在控制器里加一行
Log::info('Before dispatch, memory: ' . memory_get_usage());和Log::info('After dispatch');，对比两行时间戳，看是否中间卡死
真正容易被忽略的点是：很多团队把「能用队列」当成「已解耦」，但只要 controller 里还藏着一个 foreach ($items as $item) { DB::table(...)->update(...); }，哪怕外面包着 dispatch，这个循环依然在同步阶段执行。504 不挑架构多新，只认谁在 hold response thread。
