除了已经建议的gunicorn超时设置，因为你在前面使用nginx，你可以检查这两个参数是否有效，proxy_connect_timeout和proxy_read_timeout默认为60秒。可以在nginx配置文件中这样设置它们，

proxy_connect_timeout 120s;
proxy_read_timeout 120s;

对我来说，最简单的方法是在你的app.py存在的文件夹中创建一个新的config.py文件，并在其中放入超时和所有你想要的特殊配置:

timeout = 999

然后在指向这个配置文件的同时运行服务器

gunicorn -c config.py --bind 0.0.0.0:5000 wsgi:app

注意，要使这条语句工作，还需要将wsgi.py放在具有以下内容的同一目录中

from myproject import app

if __name__ == "__main__":
    app.run()

干杯!

WORKER TIMEOUT表示应用程序不能在规定的时间内响应请求。你可以使用gunicorn超时设置来设置。一些应用程序需要比另一个应用程序更多的时间来响应。

另一个可能影响这一点的因素是员工类型的选择

The default synchronous workers assume that your application is resource-bound in terms of CPU and network bandwidth. Generally this means that your application shouldn’t do anything that takes an undefined amount of time. An example of something that takes an undefined amount of time is a request to the internet. At some point the external network will fail in such a way that clients will pile up on your servers. So, in this sense, any web application which makes outgoing requests to APIs will benefit from an asynchronous worker.

当我遇到与您相同的问题时(我试图使用Docker Swarm部署我的应用程序)，我尝试增加超时并使用另一种类型的工人类。但都失败了。

然后我突然意识到我的资源限制太低在我的撰写文件中的服务。在我的例子中，这就是减慢应用程序的原因

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

所以我建议你先检查一下是什么减慢了你的应用程序

如果使用GCP，则必须为每个实例类型设置worker。

链接到GCP最佳实践https://cloud.google.com/appengine/docs/standard/python3/runtime

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

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

除了已经建议的gunicorn超时设置，因为你在前面使用nginx，你可以检查这两个参数是否有效，proxy_connect_timeout和proxy_read_timeout默认为60秒。可以在nginx配置文件中这样设置它们，

proxy_connect_timeout 120s;
proxy_read_timeout 120s;