Docker, Django, Nginx, Gunicorn sometimes showing 502 Bad gateway error, how to fix?

Question

Django

Goodnight. I deployed the project, fixed a couple of errors that I didn’t find locally, received an ssl certificate, everything became relatively normal, only now I began to notice that after 1-5 reloads of the site I get a 502 error page (the server is behind cloudflare)
A lot of sites clambered on info, more than 30 links with different options for fixing the problem, but nothing helped, everything is the same, either the page is loaded, or the error.

Due to the fact that I can’t even understand where to dig, I won’t upload the source files initially, tell me which ones you need to provide - I’ll publish it. I ask to help, who faced and solved the problem. I do not understand why SOMETIMES the error gets out. If I always climbed out, then perhaps it would be easier to decide.

nginx.conf:

Last tested version

upstream hello_server {
    server web:8000;
}

server {
    listen 443 ssl;
    listen [::]:443;
    listen 80;
    listen [::]:80;

    charset utf-8;

    #ssl on;
    ssl_certificate /etc/nginx/certs/default.crt;
    ssl_certificate_key /etc/nginx/certs/default.key;

    #error_page 497 https://$host:$server_port$request_uri;

    location / {
        proxy_pass http://hello_server;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_redirect off;

        if (!-f $request_filename) {
            proxy_pass http://hello_server;
            break;
        }
    }

    location /staticfiles/ {
        alias /usr/src/app/staticfiles/;
    }

    location /mediafiles/ {
        alias /usr/src/app/mediafiles/;
    }
}

Second tested config

server {
    listen 443 ssl;
    listen [::]:443;
    listen 80;
    listen [::]:80;

    charset utf-8;

    #ssl on;
    ssl_certificate /etc/nginx/certs/default.crt;
    ssl_certificate_key /etc/nginx/certs/default.key;

    #error_page 497 https://$host:$server_port$request_uri;

    location / {
        proxy_pass http://web:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_redirect off;
    }

    location /staticfiles/ {
        alias /usr/src/app/staticfiles/;
    }

    location /mediafiles/ {
        alias /usr/src/app/mediafiles/;
    }
}

UPD
Honestly, I don't know what happened. Removed all containers, cleaned everything. On the local machine, I made some minor changes, checked everything again - locally there is no new behavior, and the dev and pro versions of the site load perfectly. I uploaded everything back to the server, set up variables, launched iiii .... everything is ok. I will continue to monitor the situation and if I encounter the problem again and understand what is causing it, I will update the questions. There are no solutions.
From the interesting in the past:
When updating the site page, a line from the container to the database was poured into the log: I LOG: invalid length of startup packet
started to investigate this moment and found that when the container was launched during the initialization of the database, there was also some information related to packages insert here)
I came across a post:https://github.com/benoitc/gunicorn/issues/2347#is...
It says that with this error, the site can sometimes issue a 502 page. I didn't like it.
Of the interesting in the present: I did NOT observe
more errors with the new setting of the container group. LOG: invalid length of startup packetWhy the error disappeared is unknown. Although I did a lot of things with the database, and other connections, and other versions, but in the past this did not fix the problem in any way.

Answer 1

here in the first config it goes into if (!-f $request_filename) {...} sometimes. and throws an error. I need to replace it with something, I don't know what. here you go - and there will be no errors with timeouts, check

Answer 2

Your web:8000 stops responding. Look at him, maybe he's falling. Well, look at the logs. Wang that there will be a message like that web: 8000 is not available.