Я вот уже неделю застрял на этой ошибке. Я официально затрудняюсь с этим.
У меня есть веб-приложение React / Django, в которое пользователи могут загружать аудиофайлы (.WAV) (через React Dropzone). React и Django полностью разделены на папки frontend / и backend /, взаимодействующие через вызовы fetch (). По какой-то причине я могу загружать файлы размером менее 100 МБ, но если я загружаю файл большего размера, например, 180 МБ, возникает Nginx ошибки со следующим:
2020/07/14 02:29:18 [error] 21023#21023: *71 upstream prematurely closed connection while reading response header from upstream, client: 50.***.***.***, server: api.example.com, request: "POST /api/upload_audio HTTP/1.1", upstream: "http://unix:/home/exampleuser/AudioUploadApp/AudioUploadApp.sock:/api/upload_audio", host: "api.example.com”, referrer: "https://example.com/profile/audio/record"
Мой журнал ошибок Gunicorn ошибок не показывает. Я вижу, что запускается каждый из 5 рабочих, но я не вижу ошибок РАБОЧЕГО таймаута или чего-либо еще.
Мой файл guniocorn.service:
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=exampleuser
Group=www-data
WorkingDirectory=/home/exampleuser/AudioUploadApp/Backend
ExecStart=/home/exampleuser/virtualenvs/uploadenv/bin/gunicorn --access-logfile "/tmp/gunicorn_access.log" --error-logfile "/tmp/gunicorn_error.log" --capture-output --workers 5 --worker-class=gevent --timeout=900 --bind unix/home/exampleuser/AudioUploadApp/AudioUploadApp.sock AudioUploadApp.wsgi:application --log-level=error
[Install]
WantedBy=multi-user.target
server {
server_name api.example.com;
location / {
include proxy_params;
proxy_pass http://unix:/home/exampleuser/AudioUploadApp/AudioUploadApp.sock;
client_max_body_size 200M;
}
location /static {
autoindex on;
alias /home/exampleuser/AudioUploadApp/Backend/static/;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
client_max_body_size 200M;
}
server {
server_name www.example.com example.com;
root /home/exampleuser/AudioUploadApp/build;
index index.html index.html;
location / {
try_files $uri /index.html;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
client_max_body_size 200M;
}
server {
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name www.example.com example.com;
listen 80;
return 404; # managed by Certbot
}server {
if ($host = api.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name api.example.com;
client_max_body_size 200M;
return 404; # managed by Certbot
}
Nginx параметры прокси:
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 900s;
proxy_send_timeout 900s;
proxy_read_timeout 900s;
Я понимаю, что мой тайм-аут для Gunicorn и Nginx слишком велик, но у меня не самая лучшая скорость загрузки там, где я живу, поэтому я просто хочу гарантирует, что таймауты из-за скорости загрузки не являются проблемой.
Вот то, что я пробовал, но безуспешно:
- Увеличьте время ожидания для Gunicorn и Nginx. В какой-то момент я получал ошибку 504, что увеличивало время ожидания исправлено.
- Увеличено количество рабочих
- client_max_body_size 0; (Чтобы не ограничивать размер загрузки)
- Увеличьте переменную maxFile в компоненте React Dropzone
- Обновите тип инстанса Amazon EC2, чтобы получить больше ЦП и ОЗУ
- Убедитесь, что Django не дает сбоев
- Я включил операторы печати прямо в начало первого метода, который Django запускается по запросу. Насколько я могу судить, запрос не заходит так далеко по какой-то причине
Повторяю, это, похоже, происходит только с размером файла wav более 100 МБ. Я успешно смог загрузить файлы размером, например, 80 МБ, но не смог загрузить файлы размером 150 МБ.
Я занимаюсь этим около недели. Я довольно застрял. Был бы очень признателен за любую помощь. Я могу включить любую дополнительную информацию, если я пропустил какую-либо полезную информацию