NGINX : upstream timed out (110 : Connection timed out) lors de la lecture de l'en-tête de réponse depuis upstream

Question

J'ai Puma comme serveur d'applications en amont et Riak comme cluster de base de données. Lorsque j'envoie une requête qui réduit un morceau de données pour environ 25 000 utilisateurs et le renvoie de Riak vers l'application, j'obtiens une erreur dans le journal de Nginx :

upstream timed out (110 : Connection timed out) lors de la lecture du l'en-tête de réponse de l'amont

Si j'interroge mon amont directement sans proxy nginx, avec la même requête, j'obtiens les données requises.

Le délai d'attente de Nginx se produit une fois que le proxy est mis en place.

**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 dispose d'un grand nombre de directives de délai d'attente. Je ne sais pas si je manque quelque chose d'important. Toute aide serait très appréciée....

Answer 1

Je pense que cette erreur peut se produire pour diverses raisons, mais elle peut être spécifique au module que vous utilisez. Par exemple, j'ai rencontré ce problème en utilisant le module uwsgi, et j'ai dû définir "uwsgi_read_timeout".

Answer 2

Comme beaucoup d'autres l'ont souligné ici, augmenter les paramètres de délai d'attente pour NGINX peut résoudre votre problème.

Cependant, augmenter les paramètres de votre délai d'attente n'est peut-être pas aussi simple que ce que beaucoup de ces réponses suggèrent. J'ai moi-même été confronté à ce problème et j'ai essayé de modifier mes paramètres de délai d'attente dans la section /etc/nginx/nginx.conf comme presque tout le monde le suggère dans ce fil de discussion. Cela ne m'a pas aidé du tout ; il n'y a eu aucun changement apparent dans les paramètres de délai de NGINX. Aujourd'hui, plusieurs heures plus tard, j'ai enfin réussi à résoudre ce problème.

La solution réside dans ce fil du forum et ce qu'il dit, c'est que vous devriez mettre vos paramètres de délai dans /etc/nginx/conf.d/timeout.conf (et si ce fichier n'existe pas, vous devez le créer). J'ai utilisé les mêmes paramètres que ceux suggérés dans le fil de discussion :

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

Answer 3

Veuillez également vérifier le keepalive_timeout du serveur en amont.

J'ai eu un problème similaire : 502 aléatoire, avec Connection reset by peer erreurs dans les journaux de nginx, qui se produisent lorsque le serveur est très sollicité. J'ai fini par découvrir que cela était dû à une incompatibilité entre le système de nginx et celui d'upstream (gunicorn dans mon cas). keepalive_timeout valeurs. Nginx était à 75s et upstream à seulement quelques secondes. Cela faisait qu'upstream tombait parfois en timeout et abandonnait la connexion, alors que nginx ne comprenait pas pourquoi.

Augmenter la valeur du serveur en amont pour qu'elle corresponde à celle de nginx a résolu le problème.

Answer 4

J'ai eu le même problème et il en est résulté une erreur "quotidienne" dans le contrôleur de rails. Je ne sais pas pourquoi, mais en production, puma exécute l'erreur encore et encore en provoquant le message :

upstream timed out (110 : Connection timed out) pendant la lecture de l'en-tête de réponse de upstream

Le plus drôle, c'est que l'erreur provoque le message de dépassement de délai même si j'appelle une action différente dans le contrôleur, donc une seule faute de frappe bloque toute l'application.

Vérifiez votre fichier log/puma.stderr.log pour voir si c'est le cas.

Answer 5

De notre côté, nous avons utilisé spdy avec le cache du proxy. Lorsque le cache expire, nous obtenons cette erreur jusqu'à ce que le cache soit mis à jour.