我们在 Wordpress 中遇到了 504 超时，因为我们将一个功能附加到“发布帖子”，该功能会获取受攻击的 zip 文件，将其解压，将解压后的文件移动到 s3，创建一个新的 Zip 文件并将其也移动到 S3。对于较大的文件，它会在 60 秒后超时。
我现在能在这里澄清一下，这不是用户功能吗？当用户执行任何操作时，这不会从网站前端发生。用户将内容图像、zip 等上传到帖子中，该帖子在管理面板中等待我们。审核后，我们可以选择删除帖子（同时删除他们上传的所有数据）或发布帖子，然后获取他们上传的 zip 文件，解压缩，检查病毒，删除任何非 MP3 的内容，将各个 MP3 上传到 S3，创建一个新的 zip 文件并将其也上传到 S3。所有这些都是从 EC2 运行的。您可以想象，虽然这不会给服务器 CPU 带来太多负载，但将所有这些数据移动到 S3 通常需要超过 60 秒的时间。
所以我看到了关于如何使用 Nginx 防止网关超时的建议
我已将 fastcgi_read_timeout 放入 nginx.conf 中，并将其（目前）设置为 2700，以尝试避免所有超时错误。我已对所有涉及超时的操作执行此操作。我还添加了该页面上提到的 client_body_timeout 和 send_timeout。但该过程仍在 60 秒内超时。
我是否可能在错误的时间将它们放入 nginx.conf 上的错误位置（它可以毫无问题地重新启动），或者也许有另一个功能可以允许这个 php 进程完成。
我拥有所有 php-fpm 时间，只要我也可以设置它们。
答案1
HTTP 请求不可能永远存在——服务器或客户端最终都会放弃（HTTP 请求的最宽松的服务器端超时时间通常为 5-10 分钟，而用户通常会在那之前放弃并开始点击重新加载按钮——这几乎肯定会导致服务器崩溃）。
喜欢迈克尔·汉普顿也就是说，您需要重新设计您的应用程序来处理后台处理阶段可能需要很长时间才能完成的事实。
少量的 AJAX 可以发挥很大的作用（当后端正在处理时，客户端可以定期从服务器请求状态更新 - 这可以让您向用户反馈进度，并避免整个超时问题）。
还有很多其他方法可以处理这个问题。