NGINX: amont expiré (110: connexion expirée) lors de la lecture de l'en-tête de réponse depuis l'amont


130

J'ai Puma en cours d'exécution en tant que serveur d'applications en amont et Riak en tant que cluster de base de données d'arrière-plan. Lorsque j'envoie une demande qui réduit par mappage un morceau de données pour environ 25K utilisateurs et le renvoie de Riak à l'application, j'obtiens une erreur dans le journal Nginx:

amont expiré (110: connexion expirée) lors de la lecture de l'en-tête de réponse depuis 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'expiration de Nginx survient une fois le proxy installé.

**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 a un tas de directives de temporisation. Je ne sais pas si je rate quelque chose d'important. Toute aide serait très appréciée....


Il ne devrait expirer qu'après 600 secondes, n'est-ce pas? Vous pouvez le simuler pour le chronométrer en configurant un serveur tcp sur 127.0.0.1:3000 qui accepte simplement les connexions et ne fait rien avec elles, pour voir combien de temps cela prend. Ça devrait être 600s ...
rogerdpack

Réponses:


47

Cela se produit parce que votre amont prend trop de temps pour répondre à la demande et NGINX pense que l'amont a déjà échoué dans le traitement de la demande, il répond donc avec une erreur. Incluez et augmentez simplement proxy_read_timeout dans le locationbloc de configuration. La même chose m'est arrivée et j'ai utilisé un délai d'attente d'une heure pour une application interne au travail:

proxy_read_timeout 3600;

Avec cela, NGINX attendra une heure (3600s) pour que son amont renvoie quelque chose.


6
Notez qu'avoir proxy_read_timeoutdans la section http peut ne pas aider. J'ai la proxy_passdirective dans la section emplacement et c'est seulement là que le proxy_read_timeoutréglage a fait une différence. (nginx 1.16.0)
JonnyJD

Semble fonctionner dans http / serveur / emplacement pour moi ... peut-être que les choses ont changé :)
rogerdpack

39

Vous devriez toujours vous abstenir d'augmenter les délais d'expiration, je doute que le temps de réponse de votre serveur backend soit le problème ici dans tous les cas.

J'ai contourné ce problème en effaçant l'indicateur de maintien de la connexion et en spécifiant la version http selon la réponse ici: 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;
    }
}

Malheureusement, je ne peux pas expliquer pourquoi cela fonctionne et je n'ai pas réussi à le déchiffrer à partir des documents mentionnés dans la réponse liée non plus, donc si quelqu'un a une explication, je serais très intéressé de l'entendre.


1
Pourquoi n'ajusteriez-vous pas le proxy_read_timeoutsi vous savez que le proxy (même pour une URL spécifique) nécessitait plus de temps de traitement?
Josh M.

Salut! Je ne me souviens plus du problème exact, mais je pense qu'il n'était pas lié à l'heure réelle de l'URL, mais plutôt que le délai d'attente n'était pas traité correctement sans ces paramètres.
Almund

@magicbacon c'était il y a des années donc je me souviens à peine de l'affaire mais, vous avez changé le $http_hostdroit? Je suppose que cela ne volerait pas pour https. Il se peut que des paramètres supplémentaires soient également nécessaires pour le proxy des requêtes https.
Almund

+1 ... cela ressemble à un hack maladroit mais en fait cela vient de la documentation officielle :) nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive J'ai un problème légèrement différent "Connexion prématurément fermée en amont lors de la lecture de la réponse header from upstream "quand j'utilise la directive upstream avec keepalive et que l'utilisation de ces deux lignes semble résoudre le problème.
Karussell

1
@TimDavis Je vois, c'est peut-être mieux. Je suppose que cela pourrait dépendre du trafic, comme dans cet article disant qu'il est requis pour les WebSockets: serverlab.ca/tutorials/linux/web-servers-linux
...

26

Déterminez d'abord quel en amont ralentit en consultant le fichier journal des erreurs nginx et ajustez le délai de lecture en conséquence dans mon cas, c'était 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"

Je dois donc ajuster le fastcgi_read_timeout dans la configuration de mon serveur

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

Voir: article original


Voici un moyen d'ajouter des informations de synchronisation en cas d'échec pour voir combien vous "avez besoin" pour l'augmenter à: stackoverflow.com/questions/18627469 /
FWIW

10

Dans votre cas, cela aide un peu d'optimisation dans le proxy, ou vous pouvez utiliser "# paramètres de délai d'attente"

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

Pour moi, cela fait une différence d'avoir ces paramètres dans la section emplacement . Les avoir dans la section http n'a pas aidé (probablement parce que j'avais aussi proxy_passdans la section emplacement .
JonnyJD

Qu'optimisez-vous exactement avec ces déclarations?
Vlad le

9

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 vu cela en utilisant le module uwsgi, donc j'ai dû définir "uwsgi_read_timeout".


2
Je pense que uwsgi_read_timeout 3600; proxy_send_timeout 3600; proxy_read_timeout 3600; travaille pour moi.
tyan

9

Je recommanderais de regarder le error_logs, en particulier à la partie en amont où il montre en amont spécifique qui expire.

Ensuite, en fonction de cela, vous pouvez ajuster proxy_read_timeout, fastcgi_read_timeoutou uwsgi_read_timeout.

Assurez-vous également que votre configuration est chargée.

Plus de détails ici Nginx en amont a expiré (pourquoi et comment corriger)


4

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

Cependant, augmenter vos paramètres de délai d'expiration n'est peut-être pas aussi simple que la plupart de ces réponses le suggèrent. J'ai moi-même rencontré ce problème et essayé de modifier mes paramètres de délai d'expiration dans le fichier /etc/nginx/nginx.conf , comme presque tout le monde dans ces fils le suggère. Cela ne m'a pas aidé du tout; il n'y avait aucun changement apparent dans les paramètres de délai d'expiration de NGINX. Maintenant, plusieurs heures plus tard, j'ai finalement réussi à résoudre ce problème.

La solution réside dans ce fil de discussion du forum , et ce qu'il dit, c'est que vous devez mettre vos paramètres de délai d'expiration 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:

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

1

J'ai eu le même problème et j'ai abouti à une erreur «tous les jours» dans le contrôleur de rails. Je ne sais pas pourquoi, mais en production, puma exécute l'erreur encore et encore provoquant le message:

amont expiré (110: connexion expirée) lors de la lecture de l'en-tête de réponse depuis l'amont

Probablement parce que Nginx essaie de récupérer les données de puma encore et encore.

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


0

De notre côté, il utilisait spdy avec proxy cache. Lorsque le cache expire, nous obtenons cette erreur jusqu'à ce que le cache ait été mis à jour.


0

J'espère que cela aide quelqu'un: j'ai rencontré cette erreur et la cause était une mauvaise autorisation sur le dossier du journal pour phpfpm, après l'avoir modifié pour que phpfpm puisse y écrire, tout allait bien.


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.