Nginx 499 codes d'erreur
Je reçois beaucoup de 499 nginx codes d'erreur. Je vois que c'est un problème. Il n'est pas un problème avec Nginx ou mon uWSGI de la pile. Je note la corrélation uWSGI journaux lorsqu'un obtenir 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 suis à la recherche d'une explication plus approfondie et en espérant qu'il n'ya rien de mal avec ma config nginx pour uwsgi. Je suis prendre sur le visage de la valeur...ce n'est pas un de m'problème..c'est un client en question.
Grâce
- Avez-vous jamais trouver une solution à cela? Je vois exactement le même problème avec les deux uWSGI et de nginx.
- - Je l'obtenir lors de l'avortement un jQuery ajax demande.
- Je sais que c'est une très vieille question, mais le montant des égarés questions sur DONC est stupéfiant. Cela appartient clairement à la SF.
Vous devez vous connecter pour publier un commentaire.
HTTP 499 dans Nginx signifie que le client a fermé la connexion avant que le serveur a répondu à la demande. Dans mon expérience, est habituellement causée par côté client délai. Comme je sais que c'est un Nginx code d'erreur spécifique.
Dans mon cas, j'étais impatiente et finit par une mauvaise interprétation de la bûche.
En fait, le vrai problème était la communication entre nginx et uwsgi, et non pas entre le navigateur et de nginx. Si j'avais chargé le site dans mon navigateur, et avait attendu assez longtemps que j'aurais obtenu un "504 - Bad Gateway". Mais il a fallu si longtemps, que j'ai continué à essayer des trucs, et puis rafraîchissez-les dans le navigateur. Donc je n'ai jamais attendu assez longtemps pour voir l'erreur 504. Lors de l'actualisation dans le navigateur, c'est lorsque la demande antérieure est fermé, et Nginx écrit que dans le journal comme 499.
Élaboration
Ici, je vais supposer que le lecteur sait que littele comme je l'ai fait, quand j'ai commencé à jouer.
Ma configuration était un reverse proxy, le serveur nginx, et un serveur d'application, le uWSGI serveur derrière elle. Toute demande du client irait à l'nginx serveur, puis transmis à la uWSGI serveur, puis une réponse a été envoyée le même chemin pour le retour. Je pense que c'est la façon dont tout le monde utilise nginx/uwsgi, et sont censés l'utiliser.
Mon nginx travaillé comme il se doit, mais quelque chose n'allait pas avec le uwsgi serveur. Il y a deux façons (peut-être plus), dans lequel la uwsgi server peut échouer à répondre à la nginx serveur.
1) uWSGI dit, "je suis le traitement, il suffit d'attendre et vous allez bientôt obtenir une réponse". nginx a une certaine période de temps, qu'il est prêt à attendre, fx 20 secondes. Après cela, il va répondre au client, avec une erreur 504.
2) uWSGI est mort, ou uWSGi meurt alors que nginx est en attente pour elle. nginx voit tout de suite, et dans ce cas, elle renvoie à 499 erreur.
J'ai été le tester ma configuration en faisant des demandes du client (navigateur). Dans le navigateur, rien n'est arrivé, il a tout simplement continué à traîner. Après peut-être 10 secondes (à moins que le délai d'attente), j'ai conclu que quelque chose n'allait pas (ce qui était vrai), et fermé le uWSGI serveur à partir de la ligne de commande. Ensuite, je voudrais aller à la uWSGI paramètres, essayez quelque chose de nouveau, puis redémarrez l'uWSGI serveur. Le moment où j'ai fermé la uWSGI serveur, le serveur nginx serait de retour à 499 erreur.
J'ai donc gardé le débogage avec l'499 erroe, cela signifie que googler pour les 499 erreur. Mais si j'avais attendu assez longtemps, j'aurais obtenu l'erreur 504. Si j'avais fait l'erreur 504, j'aurais été en mesure de mieux comprendre le problème, et ensuite être capable de débogage.
Donc la conclusion est, que le problème était avec uWGSI, qui a gardé la pendaison ("Attendre un peu plus longtemps, juste un peu plus, alors j'aurai une réponse pour vous...").
Comment je fixe que problème, je ne m'en souviens pas. Je suppose que cela pourrait être causé par beaucoup de choses.
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 (équilibrage de charge) en face de votre serveur web (nginx) soit AWS ou haproxy (personnalisé). Que dit la LB va agir comme un client de nginx.
Si vous exécutez haproxy des valeurs par défaut pour:
Cela voudrait dire que la LB vais de temps après 60000ms si il n'y a pas de réponse à partir de nginx. Les sorties de temps peut se produire pour des sites très fréquentés ou des scripts qui ont besoin de plus de temps pour l'exécution. Vous aurez besoin de trouver timeout qui va travailler pour vous. Par exemple l'étendre à d':
Et vous sera probablement ensemble.
Selon votre configuration, vous pouvez voir une 504 gateway timeout erreur dans votre navigateur, ce qui indique que quelque chose est incorrect avec php-fpm, mais qui ne sera pas le cas avec 499 erreurs dans vos fichiers de log.
Dans mon cas, j'ai eu 499 lorsque le client de l'API a fermé la connexion avant qu'il ne reçoit aucune réponse. Littéralement envoyé un message et immédiatement fermer la connexion.
Ce problème est résolu par l'option:
Nginx doc
Cette erreur est assez facile à reproduire en utilisant la norme de configuration de nginx avec php-fpm.
En gardant la touche F5 sur une page va créer des dizaines de demandes d'actualisation pour le serveur. Chaque demande est annulée par le navigateur à nouveau d'actualisation. Dans mon cas, j'ai trouvé des dizaines de 499 dans mon client de la boutique en ligne de fichier journal. À partir d'un nginx point de vue: Si la réponse n'a pas été remis au client avant la prochaine actualisation de la demande de nginx journaux de l'499 erreur.
Si le php-fpm traitement prend plus de temps (comme un heavyish WP page) il peut causer des problèmes, bien sûr. J'ai entendu parler de php-fpm se bloque, par exemple, mais je crois qu'ils peuvent être empêchés de configurer correctement les services comme la gestion des appels à xmlrpc.php.
...est venu ici, à partir d'une recherche sur google
J'ai trouvé la réponse ailleurs ici --> https://stackoverflow.com/a/15621223/1093174
qui était de faire la connexion du délai d'inactivité de mon AWS elastic load balancer!
(J'ai eu l'installation d'un site Django avec nginx/apache en reverse proxy, et un vraiment vraiment vraiment se connecter backend travail/point de vue a été temporisation)
Une fois je me suis 499 "la Demande a été interdit par antivirus" comme AJAX de la réponse http (faux positifs par Kaspersky Internet Security avec la lumière de l'analyse heuristique, profondeur de l'analyse heuristique savait correctement, il n'y avait rien de mal).
L'une des raisons de ce comportement pourrait être vous utilisez
httppouruwsgiau lieu desocket. Utilisez la commande ci-dessous si vous utilisezuwsgidirectement.Même commande .fichier ini est
J'ai rencontré ce problème et la cause est due à Kaspersky Protection plugin sur le navigateur. Si vous rencontrez ce, essayez de désactiver vos plugins et voir si cela résout votre problème.
De nombreux cas, provoquer 499 erreur，l'un de mes cas, c'est le Contenu de champ de Longueur manqué dans la requête http à partir d'un pocco client