Eroare Nginx - 110: Conexiunea a expirat în timpul conectării la amonte (django-python)

Eroarea este

2021/08/18 8:57:28 [eroare] 19915#19915: *36133 în amonte expirat (110: Conexiune a expirat) în timpul conectării la amonte, client: 10.11.12.1 (proxy-ip), server: example.com , cerere: „GET /static/css/bootstrap.min.css HTTP/1.1”, în amonte: „http://127.0.0.1:8000/static/css/bootstrap.min.css”, gazdă: „www.example .com"

descriere scurtă a erorii

Site-ul web funcționează întotdeauna bine, dar uneori există această eroare de mai sus, care cred că se datorează traficului mare către site-ul web, atunci când site-ul web se defectează, site-ul nu va apărea imediat după repornirea nginx și a supervizorului.

Uneori, va dura între 5 și 6 ore pentru ca site-ul să apară

Servere - Ubuntu-18.04 LTS

configurațiile serverului web după cum urmează

Am un server proxy și un server de aplicații

1. server proxy - nginx

2. server de aplicații - rulează nginx & (supervizor - aplicație django)

3. server proxy -nginx-config

    Server {
   
        asculta 443 ssl http2;
        ssl_certificate /etc/nginx/ssl/bundle.crt;
        ssl_certificate_key /etc/nginx/ssl/start.example.com.key;
        server_name example.com www.example.com ;
        locație = /basic_status {
        stub_status;
        access_log off;
        permite 1.2.3.4;
        nega totul;
        }
        Locație /{
   
        proxy_connect_timeout 300;
        proxy_send_timeout 300;
        proxy_read_timeout 300;
        send_timeout 300;
        proxy_pass http://10.11.12.2; #proxy la serverul de aplicații
        proxy_http_versiunea 1.1;
        proxy_set_header Conexiune „”;
        add_header Access-Control-Allow-Origin .example.com;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" întotdeauna;
        add_header X-XSS-Protection "1; mode=block";
        add_header „Pragma” „fără cache”; 
        proxy_set_header Gazdă $http_host;
        proxy_set_header Actualizare $http_upgrade;
        proxy_set_header Conexiune „upgrade”;
        proxy_set_header X-Real-IP $adresă_la distanță;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Scheme $schema;
   
        #add_header Content-Security-Policy "default-src 'unsafe-inline' 'self'; script-src 'unsafe-inline' 'self' ";
        pagina de eroare 404 /404.html;
        locație = /404.html {
        root /var/www/error;
        intern;
        }
        pagina_eroare 500 502 503 504 /500.html;
        locație = /500.html {
        root /usr/share/nginx/html;
        intern;
        }
   
    }
   

4. server de aplicații - nginx

   Server {
            asculta 80 default_server;
            asculta [::]:80 default_server;
            nume_server example.com www.example.com;
   
            Locație /{
   
                proxy_pass http://127.0.0.1:8000;
                proxy_read_timeout 180;
   
            }                                                                                                                    
     }
   

5. application-server - supervizor

    [program:portal]
    comanda =/root/portal_env/bin/gunicorn portal.wsgi:application -b 0.0.0.0:8000 --timeout 180 --workers=3 ;
    utilizator = root ; Utilizatorul să ruleze ca
    director = /root/portal_env/portal
    stdout_logfile = /root/portal_env/logs/portal.log ; Unde să scrieți mesajele de jurnal
    redirect_stderr = adevărat; Salvați stderr în același jurnal
    autostart = adevărat
    autorstart = adevărat
    mediu = LANG = en_US.UTF-8,LC_ALL = en_US.UTF-8 ; Setați UTF-8 ca codificare implicită
   

Mai întâi voi veni cu câteva feedback pentru configurarea ta.

Când construiți o aplicație Python, nu este recomandat să utilizați gunicorn ca gazdă de server, construirea sa pentru dezvoltare, închideți utilizarea uWSGI pentru aplicația dvs. Python.

În continuare, când utilizați proxy în NGINX, vă voi recomanda să dezactivați tamponarea pentru proxy

proxy_buffering dezactivat;

Când dezactivați tamponarea, faceți site-ul un pic mai lent în timpul de încărcare pentru client, demonstrând nevoia acestuia de a trimite pachetul complet de la server la client. Expiratorii mei îmi spun că nu este atât de mult când vorbim de dezvoltare web și vă protejează pe termen lung dacă doriți să rulați aplicația pe mai multe servere în spatele unui echilibrator de încărcare precum NGINX Proxy, Docker Cluster sau ceva de genul.

După feedback-ul meu, sună ca și cum ați avea ceva în codul dvs., intrați într-o buclă și nu vă opriți niciodată sau aveți o conexiune/interogare SQL lonnnnnnng acolo durează mai mult de 3 minute pentru a se executa.

Ceea ce vă voi recomanda aici, este activarea jurnalului lent pe baza de date, astfel încât să puteți obține un jurnal pentru toate interogările acolo durează mai mult de 0,5 secunde, poate fi un index lipsă în baza de date acolo, care execută site-ul.

Python normal nu a durat 3 minute pentru a executa o zonă de script/cod, așa că sună ca un serviciu extern, de ex. baza de date, API sau ceva în acest caz.

Când ați activat jurnalul lent pentru baza dvs. de date, un al doilea caz va fi crearea unui jurnal simplu pentru script-ul dvs. cu „ora de pornire” + „ora de încheiere” și descărcați-l cu metoda/pagina/url-ul care atinge această zonă și aruncați-l. la un fișier, astfel încât să îl puteți deschide cu ușurință, să ruleze cu întârziere în 5-6 ore în care vorbiți sau mai mult pentru a vă detecta eroarea.

Cred că este cel mai bun mod, prima problemă va fi să găsești de ce codul durează 3 minute pentru a se executa.