我们在Wordpress中获得了504个超时时间，并附带了一个“发布post”function，该function会将受到攻击的zip文件解压缩，将解压缩的文件移至s3，制作一个新的Zip并将其移至S3。 在更大的文件在60秒后超时。
现在我可以在这里明确这个ISNT的用户function – 当用户做任何事情时，这不会发生在网站的前端。 用户将内容图像，邮编等上传到pipe理面板中等待我们的post。 在审核之后，我们可以select删除post（删除他们同时上传的所有数据），或发布post，然后将其上传的zip，解压缩，检查病毒，删除任何不是MP3的东西，上传个人的MP3到S3，创build一个新的zip文件，并上传到S3。 这全部来自EC2。 正如你可以想象的那样，虽然这不会给服务器CPU带来太多负担，但是将所有这些数据移到S3通常需要60秒以上的时间。
所以我已经看到了如何防止与Nginx的网关超时的build议
我已经把fastcgi_read_timeout放到了我的nginx.conf中，并将其设置为2700，以避免所有超时错误。 我还添加了该页面上提到的client_body_timeout和send_timeout。 但是这个过程仍然在60秒内超时。
我可能把它们放在nginx.conf的错误的地方（它重新启动没有问题）使用错误的时间，或者有另一个function，将允许此PHP过程完成。
我只要能设置它们，我就拥有所有的php-fpm时间。
HTTP请求不能永远生活 – 无论是服务器还是客户端最终都会放弃（HTTP请求最慷慨的服务器端超时通常是5-10分钟，用户将经常放弃，然后开始重新加载button – 一个几乎保证的方式来杀死你的服务器）。
像迈克尔·汉普顿（Michael Hampton）说的，你需要重新devise你的应用程序来处理这个事实，即你有一个需要很长时间才能完成的后台处理阶段。
一个小小的AJAX有很长的路要走（后端处理客户端可以定期从服务器请求状态更新 – 这样可以让用户反馈进度，避免整个超时问题）。
还有很多其他的方法来处理这个问题。