NGINX: upstream scaduto (110: connessione scaduta) durante la lettura dell'intestazione della risposta dall'upstream

Ho Puma in esecuzione come server di app upstream e Riak come cluster db in background. Quando invio una richiesta che riduce la mappa di un blocco di dati per circa 25.000 utenti e lo restituisce da Riak all'app, ricevo un errore nel registro di Nginx:

upstream scaduto (110: connessione scaduta) durante la lettura dell'intestazione della risposta dall'upstream

Se interrogo il mio upstream direttamente senza proxy nginx, con la stessa richiesta, ottengo i dati richiesti.

Il timeout di Nginx si verifica una volta inserito il proxy.

**nginx.conf**

http {
    keepalive_timeout 10m;
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;
    include /etc/nginx/sites-enabled/*.conf;
}

**virtual host conf**

upstream ss_api {
  server 127.0.0.1:3000 max_fails=0  fail_timeout=600;
}

server {
  listen 81;
  server_name xxxxx.com; # change to match your URL

  location / {
    # match the name of upstream directive which is defined above
    proxy_pass http://ss_api; 
    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_cache cloud;
    proxy_cache_valid  200 302  60m;
    proxy_cache_valid  404      1m;
    proxy_cache_bypass $http_authorization;
    proxy_cache_bypass http://ss_api/account/;
    add_header X-Cache-Status $upstream_cache_status;
  }
}

Nginx ha un sacco di direttive di timeout. Non so se mi sto perdendo qualcosa di importante. Qualsiasi aiuto sarebbe molto apprezzato ....

Ciò accade perché l'upstream impiega troppo tempo per rispondere alla richiesta e NGINX pensa che l'upstream non sia già riuscito nell'elaborazione della richiesta, quindi risponde con un errore. Basta includere e aumentare proxy_read_timeout nel locationblocco di configurazione. La stessa cosa è successa a me e ho utilizzato 1 ora di timeout per un'app interna al lavoro:

proxy_read_timeout 3600;

Con questo, NGINX attenderà un'ora (3600s) affinché il suo upstream restituisca qualcosa.

Dovresti sempre evitare di aumentare i timeout, dubito che il tuo tempo di risposta del server di backend sia il problema qui in ogni caso.

Ho aggirato questo problema cancellando il flag di mantenimento della connessione e specificando la versione http come da risposta qui: https://stackoverflow.com/a/36589120/479632

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;

        # these two lines here
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        proxy_pass http://localhost:5000;
    }
}

Sfortunatamente non riesco a spiegare perché funziona e non sono riuscito a decifrarlo dai documenti menzionati nella risposta collegata, quindi se qualcuno ha una spiegazione sarei molto interessato a ascoltarla.

Per prima cosa scopri quale upstream sta rallentando consultando il file di log degli errori nginx e regola il timeout di lettura di conseguenza nel mio caso è stato fastCGI

2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"

Quindi devo regolare fastcgi_read_timeout nella configurazione del mio server

 location ~ \.php$ {
     fastcgi_read_timeout 240;
     ...
 }

Vedi: post originale

Nel tuo caso aiuta un po 'di ottimizzazione nel proxy, oppure puoi utilizzare "# impostazioni di timeout"

location / 
{        

  # time out settings
  proxy_connect_timeout 159s;
  proxy_send_timeout   600;
  proxy_read_timeout   600;
  proxy_buffer_size    64k;
  proxy_buffers     16 32k;
  proxy_busy_buffers_size 64k;
  proxy_temp_file_write_size 64k;
  proxy_pass_header Set-Cookie;
  proxy_redirect     off;
  proxy_hide_header  Vary;
  proxy_set_header   Accept-Encoding '';
  proxy_ignore_headers Cache-Control Expires;
  proxy_set_header   Referer $http_referer;
  proxy_set_header   Host   $host;
  proxy_set_header   Cookie $http_cookie;
  proxy_set_header   X-Real-IP  $remote_addr;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Penso che questo errore possa verificarsi per vari motivi, ma può essere specifico per il modulo che stai utilizzando. Per esempio l'ho visto usando il modulo uwsgi, quindi ho dovuto impostare "uwsgi_read_timeout".

Consiglierei di guardare error_logs, in particolare a monte parte a dove mostra uno specifico a monte che è scaduto.

Quindi in base a ciò puoi regolare proxy_read_timeout, fastcgi_read_timeoutouwsgi_read_timeout .

Assicurati anche che la tua configurazione sia caricata.

Maggiori dettagli qui Timeout upstream di Nginx (perché e come risolvere)

Come molti altri hanno sottolineato qui, aumentare le impostazioni di timeout per NGINX può risolvere il tuo problema.

Tuttavia, aumentare le impostazioni di timeout potrebbe non essere così semplice come suggeriscono molte di queste risposte. Io stesso ho affrontato questo problema e ho provato a modificare le mie impostazioni di timeout in /etc/nginx/nginx.conf file , come suggeriscono quasi tutti in questi thread. Questo non mi ha aiutato neanche un po '; non ci sono stati cambiamenti apparenti nelle impostazioni di timeout di NGINX. Ora, molte ore dopo, sono finalmente riuscito a risolvere questo problema.

La soluzione sta in questo thread del forum , e quello che dice è che dovresti mettere le tue impostazioni di timeout in /etc/nginx/conf.d/timeout.conf (e se questo file non esiste, dovresti crearlo). Ho usato le stesse impostazioni suggerite nel thread:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Ho avuto lo stesso problema e il risultato è stato un errore "quotidiano" nel controller dei binari. Non so perché, ma in produzione, puma esegue l'errore ancora e ancora causando il messaggio:

upstream scaduto (110: connessione scaduta) durante la lettura dell'intestazione della risposta dall'upstream

Probabilmente perché Nginx cerca di ottenere i dati da puma ancora e ancora. La cosa divertente è che l'errore ha causato il messaggio di timeout anche se sto chiamando un'azione diversa nel controller, quindi un singolo errore di battitura blocca tutta l'app.

Controlla il tuo file log / puma.stderr.log per vedere se questa è la situazione.

Da parte nostra stava usando spdy con cache proxy. Quando la cache scade, otteniamo questo errore finché la cache non è stata aggiornata.

Spero che aiuti qualcuno: mi sono imbattuto in questo errore e la causa era un'autorizzazione sbagliata sulla cartella dei log per phpfpm, dopo averla modificata in modo che phpfpm potesse scriverci, tutto andava bene.

Per il proxy_upstreamtimeout, ho provato le impostazioni precedenti ma non hanno funzionato.

L'impostazione ha resolver_timeoutfunzionato per me, sapendo che ci volevano 30 secondi per produrre il messaggio di timeout a monte. Ad esempio, me.atwibble.com non può essere risolto (110: operazione scaduta) .

http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout