以我为例，我在向服务器发送较大(10MB)文件时遇到了这个问题。我的开发服务器(app.run())收到他们没有问题，但gunicorn无法处理他们。

和我遇到同样问题的人。我的解决方案是像这样把它分成块发送: 参考/ HTML的例子，单独的大文件参考

def upload_to_server():
    upload_file_path = location

    def read_in_chunks(file_object, chunk_size=524288):
        """Lazy function (generator) to read a file piece by piece.
        Default chunk size: 1k."""
        while True:
            data = file_object.read(chunk_size)
            if not data:
                break
            yield data

    with open(upload_file_path, 'rb') as f:
        for piece in read_in_chunks(f):
            r = requests.post(
                url + '/api/set-doc/stream' + '/' + server_file_name,
                files={name: piece},
                headers={'key': key, 'allow_all': 'true'})

我的烧瓶服务器:

@app.route('/api/set-doc/stream/<name>', methods=['GET', 'POST'])
def api_set_file_streamed(name):
    folder = escape(name)  # secure_filename(escape(name))
    if 'key' in request.headers:
        if request.headers['key'] != key:                
            return 404
    else:
        return 404
    for fn in request.files:
        file = request.files[fn]
        if fn == '':
            print('no file name')
            flash('No selected file')
            return 'fail'
        if file and allowed_file(file.filename):
            file_dir_path = os.path.join(app.config['UPLOAD_FOLDER'], folder)
            if not os.path.exists(file_dir_path):
                os.makedirs(file_dir_path)
            file_path = os.path.join(file_dir_path, secure_filename(file.filename)) 
            with open(file_path, 'ab') as f:
                f.write(file.read())
            return 'sucess'
    return 404

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

proxy_connect_timeout 120s;
proxy_read_timeout 120s;

我们在使用Django+nginx+gunicorn时也遇到了同样的问题。从Gunicorn文档中，我们配置了优雅的超时，几乎没有什么不同。

经过一些测试，我们找到了解决方案，要配置的参数是:timeout(并且不是优雅超时)。它走得像时钟一样快。

所以,做:

1)打开gunicorn配置文件

2)将TIMEOUT设置为您需要的任何值-以秒为单位

NUM_WORKERS=3
TIMEOUT=120

exec gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE

这招对我很管用:

gunicorn app:app -b :8080 --timeout 120 --workers=3 --threads=3 --worker-connections=1000

如果你有eventlet，添加:

--worker-class=eventlet

如果你有gevent添加:

--worker-class=gevent

在谷歌云 只需在app.yaml的入口点添加——timeout 90

entrypoint: gunicorn -b :$PORT main:app --timeout 90

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

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