web-dev-qa-db-fra.com

Proxy inverse Nginx provoquant l'expiration du délai d'inactivité de la passerelle 504

J'utilise Nginx en tant que proxy inverse qui accepte les demandes, puis effectue un proxy_pass pour obtenir l'application Web réelle à partir du serveur en amont s'exécutant sur le port 8001.

Si je vais sur mywebsite.com ou si je fais un wget, je reçois un délai d'attente de la passerelle 504 après 60 secondes ... Cependant, si je charge mywebsite.com:8001, l'application se charge comme prévu!

Donc, quelque chose empêche Nginx de communiquer avec le serveur en amont.

Tout cela a commencé après que mon hébergeur a réinitialisé la machine sur laquelle mon matériel était en cours d'exécution, sans aucun problème auparavant.

Voici mon bloc serveur vhosts: 

server {
    listen   80;
    server_name mywebsite.com;

    root /home/user/public_html/mywebsite.com/public;

    access_log /home/user/public_html/mywebsite.com/log/access.log upstreamlog;
    error_log /home/user/public_html/mywebsite.com/log/error.log;

    location / {
        proxy_pass http://xxx.xxx.xxx.xxx:8001;
        proxy_redirect off;
        proxy_set_header Host $Host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Et la sortie de mon journal d'erreurs Nginx: 

2014/06/27 13:10:58 [error] 31406#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: xxx.xx.xxx.xxx, server: mywebsite.com, request: "GET / HTTP/1.1", upstream: "http://xxx.xxx.xxx.xxx:8001/", Host: "mywebsite.com"
nginxreverse-proxyproxypasshttp-status-code-504
73
Dave Roma

Peut probablement ajouter quelques lignes de plus pour augmenter le délai d’expiration en amont. Les exemples ci-dessous définissent le délai d'expiration à 300 secondes:

proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          300;
send_timeout                300;
118
user2540984

Augmenter le délai d'attente ne résoudra probablement pas votre problème car, comme vous le dites, le serveur Web cible répond parfaitement.

J'ai eu ce même problème et j'ai trouvé qu'il s'agissait de ne pas utiliser de persistance sur la connexion. Je ne peux pas vraiment vous dire pourquoi, mais en effaçant l'en-tête de connexion, j'ai résolu le problème et la requête a été envoyée correctement:

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_Host;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://localhost:5000;
    }
}

Jetez un coup d'œil à ces messages qui l'expliquent plus en détail: nginx ferme la connexion en amont après la demandeclarification de l'en-tête Keep-alivehttp://nginx.org /en/docs/http/ngx_http_upstream_module.html#keepalive

41
Almund

Si vous souhaitez augmenter ou ajouter une limite de temps à tous les sites, vous pouvez ajouter des lignes ci-dessous au fichier nginx.conf.

Ajoutez les lignes ci-dessous à la section http du fichier /usr/local/etc/nginx/nginx.conf ou /etc/nginx/nginx.conf.

fastcgi_read_timeout 600;
proxy_read_timeout 600;

Si les lignes ci-dessus n'existent pas dans le fichier conf, ajoutez-les, sinon augmentez fastcgi_read_timeout et proxy_read_timeout pour vous assurer que nginx et php-fpm n'ont pas expiré.

Pour augmenter la limite de temps pour un seul site, vous pouvez éditer dans vim /etc/nginx/sites-available/example.com

location ~ \.php$ {
    include /etc/nginx/fastcgi_params;
        fastcgi_pass  unix:/var/run/php5-fpm.sock;
    fastcgi_read_timeout 300; 
}

et après avoir ajouté ces lignes dans nginx.conf, n'oubliez pas de redémarrer nginx.

service php7-fpm reload 
service nginx reload

ou, si vous utilisez un valet, tapez simplement valet restart.

8
Adeel

Vous pouvez également faire face à cette situation si votre serveur en amont utilise un nom de domaine et que Son adresse IP change (par exemple: votre amont se dirige vers un AWS Elastic Load Balancer).

Le problème est que nginx résoudra l’adresse IP une fois et la conservera en cache Pour les demandes suivantes jusqu’à ce que la configuration soit rechargée.

Vous pouvez indiquer à nginx d'utiliser un serveur de noms pour resoudre le domaine une fois que l'entrée Mise en cache expire:

location /mylocation {
    # use google dns to resolve Host after IP cached expires
    resolver 8.8.8.8;
    set $upstream_endpoint http://your.backend.server/;
    proxy_pass $upstream_endpoint;
}

Les docs sur proxy_pass expliquent pourquoi cette astuce fonctionne:

La valeur du paramètre peut contenir des variables. Dans ce cas, si une adresse est spécifiée en tant que nom de domaine, le nom est recherché parmi les groupes de serveurs décrits, et, s'il n'est pas trouvé, est déterminé à l'aide d'un résolveur.

Félicitations à "Nginx avec amont dynamique" (tenzer.dk) pour l'explication détaillée , Qui contient également des informations pertinentes sur une mise en garde de cette approche Concernant les adresses URI transmises.

2
el.atomo

Avait le même problème. Il s’est avéré que cela était dû au suivi de connexion iptables sur le serveur en amont. Après avoir supprimé --state NEW,ESTABLISHED,RELATED du script de pare-feu et vidé avec conntrack -F, le problème avait disparu. 

2
mindlab

user2540984 , ainsi que beaucoup d'autres ont fait remarquer que vous pouvez essayer d'augmenter vos paramètres de délai d'attente. J'ai moi-même rencontré un problème similaire à celui-ci et essayé de modifier mes paramètres de délai d'attente dans le fichier /etc/nginx/nginx.conf, comme le suggèrent presque tous les utilisateurs de ces discussions. Ceci, cependant, ne m'a pas aidé un peu; il n'y avait aucun changement apparent dans les paramètres de délai d'attente de NGINX. Après de nombreuses heures de recherche, j'ai finalement réussi à résoudre mon problème.

La solution réside dans ce fil de discussion , et il indique que vous devez définir vos paramètres de délai d'attente dans /etc/nginx/conf.d/timeout.conf (et si ce fichier n'existe pas, vous devriez 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;

Ce n'est peut-être pas la solution à votre problème particulier, mais si quelqu'un d'autre remarque que le délai d'attente change dans /etc/nginx/nginx.conf ne faites rien, j'espère que cette réponse vous aidera!

1
Andreas Forslöw