关于在Azure应用服务(Linux应用)上运行Flask Apps的Microsoft Azure官方文档声明超时时间为600

gunicorn --bind=0.0.0.0 --timeout 600 application:app

https://learn.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app

使用——log-level debug运行Gunicorn。

它应该会给你一个应用程序堆栈跟踪。

会是这样吗? http://docs.gunicorn.org/en/latest/settings.html#timeout

其他的可能是你的回复时间太长或者被困在等待中。

检查你的工人没有被健康检查杀死。长请求可能会阻塞健康检查请求，worker会被平台杀死，因为平台认为worker没有响应。

例如，如果您有一个25秒长的请求，并且活动检查被配置为每10秒命中同一服务中的不同端点，1秒超时，并重试3次，这就给出了10+1*3 ~ 13秒，您可以看到它会触发一些时间，但并不总是如此。

如果是这种情况，解决方案是重新配置您的活动检查(或您的平台使用的任何健康检查机制)，以便它可以等待您的典型请求完成。或者允许更多的线程——这样可以确保健康检查不会阻塞足够长的时间来触发worker kill。

你可以看到，增加更多的工人可能有助于(或隐藏)这个问题。

这个端点是否花费了太多时间?

也许你使用的flask没有异步支持，所以每个请求都会阻塞调用。要创建异步支持而不让make变得困难，可以添加gevent worker。

使用gevent，一个新的调用将产生一个新的线程，你的应用程序将能够接收更多的请求

pip install gevent
gunicon .... --worker-class gevent

你需要使用另一个worker类型类，比如gevent或tornado。 第一个解释:

如果您预计应用程序代码在请求处理期间可能需要暂停较长时间，您可能还需要安装Eventlet或Gevent

第二点:

默认的同步工作线程假定您的应用程序在CPU和网络带宽方面受到资源限制。通常这意味着您的应用程序不应该执行任何花费未定义时间的操作。例如，对互联网的请求就符合这个标准。在某些时候，外部网络会出现故障，客户端会堆积在您的服务器上。