it-swarm.com.de

NGINX: Zeitlimit für Upstream (110: Zeitlimit für Verbindung), während der Antwortheader vom Upstream gelesen wird

Ich habe Puma als Upstream-App-Server und Riak als Hintergrund-DB-Cluster. Wenn ich eine Anfrage schicke, dass ein Map-Datenstück für etwa 25.000 Benutzer reduziert und von Riak an die App zurückgegeben wird, erhalte ich einen Fehler im Nginx-Protokoll:

zeitüberschreitung beim Upstream (110: Zeitüberschreitung der Verbindung) beim Lesen Antwortheader von Upstream

Wenn ich meinen Upstream ohne nginx-Proxy mit derselben Anfrage direkt abfrage, erhalte ich die erforderlichen Daten. 

Das Nginx-Timeout tritt auf, sobald der Proxy eingegeben wird. 

**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 hat eine Reihe von Timeout-Anweisungen. Ich weiß nicht, ob mir etwas Wichtiges fehlt. Jede Hilfe wäre sehr dankbar ....

78
user2768537

Sie sollten immer davon Abstand nehmen, die Zeitüberschreitungen zu erhöhen. Ich bezweifle, dass die Antwortzeit Ihres Backend-Servers in jedem Fall das Problem ist.

Ich bin dieses Problem umgangen, indem ich das Keep-Alive-Flag für die Verbindung gelöscht und die http-Version gemäß der Antwort hier angegeben habe: 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;
    }
}

Leider kann ich nicht erklären, warum dies funktioniert und es nicht geschafft hat, es aus den in der Antwort genannten Dokumenten zu entschlüsseln. Wenn also jemand eine Erklärung hat, wäre ich sehr daran interessiert, sie zu hören.

18
Almund

Dies geschieht, weil der Upstream zu viel Zeit benötigt, um die Anfrage zu beantworten, und NGINX denkt, dass der Upstream bereits bei der Verarbeitung der Anfrage fehlgeschlagen ist, und antwortet mit einem Fehler . Fügen Sie einfach proxy_read_timeout in location ..__ hinzu und ich nutzte 1 Stunde Timeout für eine interne App bei der Arbeit:

proxy_read_timeout 3600;

Damit wartet NGINX eine Stunde, bis der Upstream etwas zurückgibt.

14
Sergio Gonzalez

Stellen Sie zunächst fest, welcher Upstream sich verlangsamt, indem Sie die Nginx-Fehlerprotokolldatei Abrufen und die Lesezeit entsprechend anpassen In meinem Fall war es 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"

Ich muss also das fastcgi_read_timeout in meiner Serverkonfiguration anpassen

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

Siehe: ursprünglicher Beitrag

13

Ich denke, dass dieser Fehler aus verschiedenen Gründen auftreten kann, aber er kann für das von Ihnen verwendete Modul spezifisch sein. Zum Beispiel habe ich dies mit dem Modul uwsgi gesehen, also musste "uwsgi_read_timeout" gesetzt werden.

8
Richard

In Ihrem Fall hilft es eine kleine Optimierung im Proxy, oder Sie können "Timeout-Einstellungen" verwenden.

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;
}
7
Dimitrios

Ich würde empfehlen, die error_logs anzuschauen, insbesondere im Upstream-Bereich, wo es bestimmte Upstreams gibt, die ein Zeitlimit haben.

Auf dieser Grundlage können Sie proxy_read_timeout fastcgi_read_timeout oder uwsgi_read_timeout anpassen.

Stellen Sie außerdem sicher, dass Ihre Konfiguration geladen ist.

Weitere Details hier Nginx Upstream-Zeitüberschreitung (warum und wie zu beheben)

6
gansbrest

Wie viele andere hier bereits erwähnt haben, kann das Problem durch das Erhöhen der Timeout-Einstellungen für NGINX gelöst werden. 

Das Erhöhen der Timeout-Einstellungen ist jedoch möglicherweise nicht so unkompliziert, wie viele dieser Antworten vermuten lassen. Ich selbst bin mit diesem Problem konfrontiert und habe versucht, meine Timeout-Einstellungen in der Datei /etc/nginx/nginx.conf zu ändern, wie fast jeder in diesen Threads vermuten lässt. Das hat mir nicht ein bisschen geholfen; Es gab keine offensichtlichen Änderungen in den Timeout-Einstellungen von NGINX. Nun, viele Stunden später, konnte ich dieses Problem endlich beheben.

Die Lösung liegt in diesem Forumsthread , und es heißt, Sie sollten Ihre Timeout-Einstellungen in /etc/nginx/conf.d/timeout.conf (und if.) Eingeben Diese Datei existiert nicht, Sie sollten sie erstellen. Ich habe die gleichen Einstellungen verwendet wie im Thread vorgeschlagen:

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

Von unserer Seite aus wurde Spdy mit Proxy-Cache verwendet. Wenn der Cache abläuft, wird dieser Fehler angezeigt, bis der Cache aktualisiert wurde.

0
timhaak

Hoffentlich hilft es jemandem: Ich bin auf diesen Fehler gestoßen und die Ursache war eine falsche Berechtigung für den Log-Ordner für phpfpm.

0
Maurício Otta

Ich hatte das gleiche Problem und führte dazu, dass es sich bei dem Rails-Controller um einen Fehler jeden Tag handelte. Ich weiß nicht warum, aber bei der Produktion führt puma den Fehler erneut aus und verursacht erneut die Meldung:

Zeitlimit für Upstream (110: Zeitlimit für Verbindung) beim Lesen des Antwortheaders aus Upstream

Wahrscheinlich, weil Nginx versucht, die Daten immer wieder von puma abzurufen. Die lustige Sache ist, dass der Fehler die Zeitüberschreitungsmeldung verursacht hat, auch wenn ich im Controller eine andere Aktion aufrufe. Daher blockiert ein einzelner Tippfehler die gesamte App. 

Überprüfen Sie in Ihrer Datei log/puma.stderr.log, ob dies der Fall ist. 

0
aarkerio