Codes d'erreur Nginx 499
Je reçois beaucoup de 499 codes d'erreur Nginx. Je vois qu'il s'agit d'un problème côté client. Ce n'est pas un problème avec Nginx ou ma pile uWSGI. Je note la corrélation dans les journaux uWSGI lorsqu’on obtient un 499.
address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error
Je cherche une explication plus approfondie et j'espère qu'il n'y a aucun problème avec ma configuration nginx pour uwsgi. Je le prends pour argent comptant… ce n'est pas un problème qui me concerne… c'est un problème de client.
Merci
HTTP 499 dans Nginx signifie que le client a fermé la connexion avant que le serveur ne réponde à la demande. D'après mon expérience, cela est généralement causé par temporisation côté client . Comme je le sais, il s’agit d’un code d’erreur spécifique à Nginx.
Dans mon cas, j'étais impatient et j'ai fini par mal interpréter le journal.
En fait, le vrai problème était la communication entre nginx et uwsgi, et non entre le navigateur et nginx. Si j'avais chargé le site dans mon navigateur et attendu assez longtemps, j'aurais obtenu un "504 - Bad Gateway". Mais cela a pris si longtemps que j'ai continué d'essayer des trucs, puis d'actualiser le navigateur. Donc, je n'ai jamais attendu assez longtemps pour voir l'erreur 504. Lors de l'actualisation dans le navigateur, la demande précédente est fermée et Nginx l'écrit dans le journal sous la forme 499.
Élaboration
Ici, je suppose que le lecteur sait aussi littéralement que moi, quand j'ai commencé à jouer.
Ma configuration était un proxy inverse, le serveur nginx, et un serveur d'applications, le serveur uWSGI derrière. Toutes les demandes du client iraient au serveur nginx, puis seraient transférées au serveur uWSGI, puis une réponse serait renvoyée de la même manière. Je pense que c’est ainsi que tout le monde utilise nginx/uwsgi et qu’il est supposé l’utiliser.
Mon nginx a fonctionné comme il se doit, mais quelque chose n'allait pas avec le serveur uwsgi. Le serveur uwsgi peut ne pas répondre au serveur nginx de deux manières (peut-être davantage).
1) uWSGI dit: "Je traite, attendez et vous obtiendrez bientôt une réponse". nginx a une certaine période de temps, il est prêt à attendre, fx 20 secondes. Après cela, il répondra au client, avec une erreur 504.
2) uWSGI est mort ou uWSGi meurt pendant que nginx l'attend. nginx le voit tout de suite et, dans ce cas, il renvoie une erreur 499.
Je testais ma configuration en effectuant des demandes dans le client (navigateur). Dans le navigateur, rien ne s'est passé, il est resté accroché. Après peut-être 10 secondes (moins que l'expiration du délai), j'ai conclu que quelque chose n'allait pas (ce qui était vrai) et j'ai fermé le serveur uWSGI à partir de la ligne de commande. Ensuite, je voudrais aller dans les paramètres uWSGI, essayer quelque chose de nouveau, puis redémarrer le serveur uWSGI. Au moment où j'ai fermé le serveur uWSGI, le serveur nginx renverrait une erreur 499.
J'ai donc continué à déboguer avec le 499 erroe, ce qui signifie googler pour l'erreur 499. Mais si j'avais attendu assez longtemps, j'aurais eu l'erreur 504. Si j'avais eu l'erreur 504, j'aurais pu mieux comprendre le problème et ensuite pouvoir déboguer.
La conclusion est donc que le problème venait de uWGSI, qui restait en suspens ("Attends un peu plus longtemps, un peu plus longtemps, j'aurai une réponse pour toi ...").
Comment j'ai résolu ce problème, je ne m'en souviens pas. Je suppose que cela pourrait être causé par beaucoup de choses.
Le client a fermé la connexion ne veut pas dire que c'est un problème de navigateur!? Pas du tout!
Vous pouvez trouver 499 erreurs dans un fichier journal si vous avez un LB (équilibreur de charge) devant votre serveur Web (nginx) AWS ou haproxy (personnalisé). Cela dit, le LB agira en tant que client de nginx.
Si vous exécutez les valeurs par défaut haproxy pour:
timeout client 60000
timeout server 60000
Cela signifierait que LB expirera après 60000ms s'il n'y a pas de réponse de nginx. Des délais d'attente peuvent survenir pour les sites Web ou les scripts chargés nécessitant plus de temps d'exécution. Vous aurez besoin de trouver un délai qui fonctionnera pour vous. Par exemple, étendez-le à:
timeout client 180s
timeout server 180s
Et vous serez probablement prêt.
En fonction de votre configuration, il est possible qu'une erreur de délai d'attente de la passerelle 504 apparaisse dans votre navigateur, ce qui indique que quelque chose ne va pas avec php-fpm mais ce ne sera pas le cas des erreurs 499 dans vos fichiers journaux.
Dans mon cas, j'ai reçu 499 lorsque l'API du client a fermé la connexion avant qu'elle ne reçoive une réponse. Envoyez littéralement un POST et ferme immédiatement la connexion . Ceci est résolu par l'option:
proxy_ignore_client_abort le
Lorsque vous pointez 499 un avortement de connexion enregistré par le nginx. Mais généralement, cela se produit lorsque votre serveur principal est trop lent, et un autre délai d'attente du proxy commence ou le logiciel utilisateur abandonne la connexion. Vérifiez donc si uWSGI répond rapidement ou non, ou s’il ya une charge quelconque sur le serveur uWSGI/Database.
Dans de nombreux cas, il existe d'autres proxies entre l'utilisateur et nginx. Certains peuvent être dans votre infrastructure, comme un CDN, Load Balacer, un cache Varnish, etc. D'autres peuvent être du côté utilisateur, comme un proxy de mise en cache, etc.
S'il existe des proxies de votre côté, comme un LoadBalancer/CDN ..., vous devez définir le délai d'expiration de façon à ce que le backend expire en premier, puis progressivement aux autres proxys adressés à l'utilisateur.
Si tu as:
user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI
Je vous recommande de définir:
nsecondes pour l'expiration du délai uWSGIn+1secondes pour l'expiration de nginx- `n + 2 'à expiration du délai imparti à Load Balancer
n+3secondes de délai d'attente pour le CDN.
Si vous ne pouvez pas définir certains délais (comme CDN), trouvez ce qui correspond à son délai et ajustez les autres en fonction (n, n-1...).
Cela fournit une chaîne correcte de délais d'attente. et vous trouverez vraiment à qui donner le délai et retourner le bon code de réponse à l'utilisateur.
... est venu ici d'une recherche google
J'ai trouvé la réponse ailleurs ici -> https://stackoverflow.com/a/15621223/1093174
qui consistait à augmenter le délai d'inactivité de la connexion de mon équilibreur de charge élastique AWS!
(J'avais configuré un site Django avec un proxy inverse nginx/Apache, et un journal/un travail d'arrière-plan vraiment vraiment connecté se terminait)
Cette erreur est assez facile à reproduire à l’aide de la configuration standard de Nginx avec php-fpm.
Si vous maintenez le bouton F5 enfoncé sur une page, des dizaines de demandes d'actualisation seront envoyées au serveur. Chaque requête précédente est annulée par le navigateur à la nouvelle actualisation. Dans mon cas, j'ai trouvé des dizaines de 499 dans le fichier journal de la boutique en ligne de mon client. D'un point de vue nginx: Si la réponse n'a pas été remise au client avant la prochaine demande d'actualisation, nginx enregistre l'erreur 499.
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
Si le traitement php-fpm prend plus de temps (comme une page lourde WP), cela peut poser problème, bien sûr. J'ai entendu parler des plantages php-fpm, par exemple, mais je pense qu'ils peuvent être empêchés de configurer les services correctement, comme gérer les appels à xmlrpc.php.
J'ai rencontré ce problème et la cause en était due au plugin Kaspersky Protection sur le navigateur. Si vous rencontrez cela, essayez de désactiver vos plugins et voyez si cela résout votre problème.
Une des raisons de ce problème pourrait être que vous utilisez http pour uwsgi au lieu de socket. Utilisez la commande ci-dessous si vous utilisez directement uwsgi.
uwsgi --socket :8080 --module app-name.wsgi
La même commande dans le fichier .ini est
chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi
Une fois que j’ai eu 499 "La requête a été interdite par un antivirus" comme réponse AJAX http (faux positif de Kaspersky Internet Security avec une analyse heuristique légère, une analyse heuristique approfondie savait correctement qu’il n’y avait rien de mal).