Mogelijke reden voor NGINX 499-foutcodes

Ik krijg veel 499 NGINX-foutcodes. Ik zie dat dit een client-side probleem is. Het is geen probleem met NGINX of mijn uWSGI-stack. Ik noteer de correlatie in uWSGI-logboeken als ik een 499 krijg.

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

Ik ben op zoek naar een meer diepgaande uitleg en hoop dat er niets mis is met mijn NGINX-configuratie voor uwsgi. Ik neem het op het eerste gezicht. Het lijkt op een probleem van een klant.

Antwoord 1, autoriteit 100%

HTTP 499 in Nginx betekent dat de client de verbinding heeft verbrokenvoordat de server het verzoek heeft beantwoord. In mijn ervaring wordt dit meestal veroorzaakt door time-out aan clientzijde. Zoals ik weet is het een Nginx-specifieke foutcode.

Antwoord 2, autoriteit 46%

In mijn geval was ik ongeduldig en heb ik het logboek uiteindelijk verkeerd geïnterpreteerd.

In feite was het echte probleem de communicatie tussen nginx en uwsgi, en niet tussen de browser en nginx. Als ik de site in mijn browser had geladen en lang genoeg had gewacht, had ik een “504 – Bad Gateway” gekregen. Maar het duurde zo lang dat ik dingen bleef proberen en daarna verversde in de browser. Dus ik heb nooit lang genoeg gewacht om de 504-fout te zien. Bij het verversen in de browser wordt het vorige verzoek gesloten en Nginx schrijft dat in het logboek als 499.

Uitwerking

Hier zal ik aannemen dat de lezer zo weinig weet als ik deed toen ik begon te spelen.

Mijn setup was een omgekeerde proxy, de NGINX-server en een applicatieserver, de UWSGI-server erachter. Alle verzoeken van de klant zouden naar de NGINX-server gaan, vervolgens doorgestuurd naar de UWSGI-server en vervolgens werd de reactie op dezelfde manier teruggestuurd. Ik denk dat dit is hoe iedereen NGINX / UWSGI gebruikt en zou het moeten gebruiken.

Mijn nginx werkte zoals het zou moeten, maar er was iets mis met de UWSGI-server. Er zijn twee manieren (misschien meer) waarin de UWSGI-server niet kan reageren op de NGINX-server.

1) UWSGI zegt: “Ik ben verwerkt, wacht gewoon en je zult snel een reactie krijgen”. NGINX heeft een bepaalde periode, dat het bereid is om te wachten, FX 20 seconden. Daarna reageert het op de klant, met een 504-fout.

2) Uwsgi is dood, of Uwsgi sterft terwijl Nginx erop wacht. NGINX ziet dat meteen en in dat geval retourneert het een 499-fout.

Ik testte mijn setup door aanvragen in de client (browser) te doen. In de browser is er niets gebeurd, bleef het gewoon opknoping. Na 10 seconden (minder dan de time-out) concludeerde ik dat er iets niet klopt (wat waar was) en sloot de UWSGI-server uit de opdrachtregel. Dan zou ik naar de UWSGI-instellingen gaan, probeer iets nieuws en start de UWSGI-server opnieuw op. Op het moment dat ik de UWSGI-server sloot, zou de NGINX-server een 499-fout retourneren.

Dus ik bleef debuggen met de 499 Erroe, wat googlen betekent voor de 499-fout. Maar als ik lang genoeg had gewacht, zou ik de 504-fout hebben gekregen. Als ik de 504-fout had gekregen, had ik het probleem beter kunnen begrijpen en dan kan debuggen.

Dus de conclusie is dat het probleem bij uWGSI zat, dat bleef hangen (“Wacht nog even, nog even, dan heb ik een antwoord voor je…”).

Hoe ik datprobleem heb opgelost, weet ik niet meer. Ik denk dat het door veel dingen kan komen.

Antwoord 3, autoriteit 15%

Cliënt heeft de verbinding verbrokenbetekent niet dat het een browserprobleem is!? Helemaal niet!

Je kunt 499 fouten in een logbestand vinden als je een LB (load balancer) voor je webserver (nginx) hebt, ofwel AWS ofwel haproxy (aangepast). Dat gezegd hebbende, zal de LB optreden als klant voor nginx.

Als u haproxy-standaardwaarden uitvoert voor:

   timeout client  60000
    timeout server  60000

Dat zou betekenen dat LB na 60000 ms een time-out krijgt als nginx niet reageert. Er kunnen time-outs optreden voor drukke websites of scripts die meer tijd nodig hebben voor uitvoering. U moet een time-out vinden die voor u werkt. Breid het bijvoorbeeld uit tot:

   timeout client  180s
    timeout server  180s

En je bent waarschijnlijk klaar.

Afhankelijk van uw instellingen ziet u mogelijk een 504 gateway time-outfout in uw browser die aangeeft dat er iets mis is met php-fpm, maar dat zal niet het geval zijn met 499 fouten in uw logbestanden.

Antwoord 4, autoriteit 8%

Terwijl je 499wijst op een verbroken verbinding die is vastgelegd door de nginx. Maar meestal wordt dit veroorzaakt wanneer uw backend-server te traag is, en eerst nog een proxy-time-out of de gebruikerssoftware de verbinding verbreekt. Controleer dus of uWSGI snel antwoordt of niet of de uWSGI/databaseserver belast is.

In veel gevallen zijn er enkele andere proxy’s tussen de gebruiker en nginx. Sommigen kunnen in je infrastructuur zijn zoals misschien een CDN, load balacer, een vernis cache enz. Anderen kunnen in de gebruikerszijde zijn als een caching proxy enz.

Als er proxies aan uw zijde zijn zoals een loadbalancer / CDN … moet u de time-outs instellen op time-out eerst uw backend en geleidelijk de andere proxy’s bij de gebruiker.

Als u:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

Ik raad u aan om in te stellen:

• nSECONDEN NAAR UWSGI TIMOUT
• n+1SECONDEN NAAR NGINX TimeOut
• n+2senconds to time-out om balancer te laden
• n+3seconden time-out naar de CDN.

Als u geen enkele time-outs (zoals CDN) kunt instellen, zoekt wat is de time-out en pas de anderen aan volgens IT (n, n-1. ..).

Dit biedt een juiste keten van time-outs. En je zult echt vinden wiens het time-out geven en de juiste antwoordcode naar de gebruiker retourneren.

Antwoord 5, Autoriteit 7%

Blijkt 499’s echt betekent “Client onderbroken verbinding.”

Ik had een client “Lees time-out” -instelling van 60s (en NGINX heeft ook een standaard proxy_read_timeout van 60s). Dus wat er in mijn geval gebeurde, is dat nginx error zou doen. Log een upstream timed out (110: Connection timed out) while reading upstreamen vervolgens NGGINX PETTEN ” geconfigureerd. ” Dat is als je meer dan één hebt.

Dan probeert het de volgende en volgende tot (door standaard) het heeft ze allemaal uitgeput. Elke keer dat er een time-out optreedt, worden ze ook verwijderd uit de lijst met “live” backend-servers. Nadat ze allemaal zijn uitgeput, retourneert het een 504 gateway timeout.

Dus in mijn geval markeerde nginx de server als “niet beschikbaar”, probeerde het opnieuw op de volgende server, en toen trad de 60stime-out van mijn klant (onmiddellijk) op, dus ik zou een upstream timed out (110: Connection timed out) while reading upstreamlog, onmiddellijk gevolgd door een 499 log. Maar het was gewoon toeval.

Gerelateerd:

Als alle servers in de groep zijn gemarkeerd als momenteel niet beschikbaar, retourneert het ook een 502 Bad Gateway.voor 10s. Zie hiermax_failsen fail_timeout. In de logs staat no live upstreams while connecting to upstream.

Als je maar één proxy-backend in je servergroep hebt, probeer het dan gewoon die ene server, en retourneert een 504 Gateway Time-outen verwijdert de enkele server niet uit de lijst met ” live”-servers, als proxy_read_timeoutwordt overschreden. Zie hier“Als er maar één server in een groep is, max_fails, fail_timeout en slow_start parameters worden genegeerd, en zo’n server zal nooit als niet beschikbaar worden beschouwd.”

Het echt lastige is dat als je proxy_pass opgeeft voor “localhost” en je box toevallig ook ipv6 en ipv4 “versies van locatie” op hetzelfde moment bevat (de meeste boxen doen dat standaard), zal het tellen als als u een “lijst” met meerdere servers in uw servergroep had, wat betekent dat u in de bovenstaande situatie kunt komen dat deze “502 voor 10s” retourneert, ook al vermeldt u alleen één server. Zie hier“Als een domeinnaam wordt omgezet in meerdere adressen, allemaal zal worden gebruikt in een round-robin mode.”
Een tijdelijke oplossing is om het te declareren als proxy_pass http://127.0.0.1:5001;(het ipv4-adres) naar vermijddat het zowel ipv6 als ipv4 is. Dan telt het als “slechts een enkele server”-gedrag.

Er zijn een paar verschillende instellingen die je kunt aanpassen om dit een “minder” probleem te maken. Zoals het verhogen van time-outs of het zo maken dat servers niet als “uitgeschakeld” worden gemarkeerd wanneer ze een time-out hebben… of de lijst repareren zodat het alleen maat 1 is, zie hierboven 🙂

Zie ook: https://serverfault.com/a/783624/27813

Antwoord 6, autoriteit 5%

In mijn geval kreeg ik 499 toen de API van de klant de verbinding verbrak voordat deze een reactie kreeg. Letterlijk een POST gestuurd en meteen de verbinding verbroken.
Dit wordt opgelost door optie:

proxy_ignore_client_abort op

Nginx-document

Antwoord 7, autoriteit 2%

Deze fout is vrij eenvoudig te reproduceren met behulp van de standaard nginx-configuratie met php-fpm.

Als u de F5-knop op een pagina ingedrukt houdt, worden tientallen vernieuwingsverzoeken naar de server verzonden. Elke eerdere aanvraag wordt geannuleerd door de browser bij nieuwe verversing. In mijn geval vond ik tientallen 499’s in het logbestand van de online winkel van mijn klant. Vanuit een nginx-oogpunt: als het antwoord niet bij de client is afgeleverd vóór het volgende vernieuwingsverzoek, registreert nginx de 499-fout.

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)

Als de php-fpm-verwerking langer duurt (zoals een zware WP-pagina), kan dit natuurlijk problemen veroorzaken. Ik heb bijvoorbeeld gehoord van php-fpm-crashes, maar ik geloof dat ze voorkomen kunnen worden door services correct te configureren, zoals het afhandelen van oproepen naar xmlrpc.php.

Antwoord 8, autoriteit 2%

… kwam hier via een Google-zoekopdracht

Ik heb het antwoord hier ergens anders gevonden –> https://stackoverflow.com/a/15621223/1093174

die de time-out voor inactiviteit van de verbinding van mijn AWS elastische load balancer zou verhogen!

(Ik had een Django-site opgezet met nginx/apache reverse proxy, en een echt heel erg log-backend-taak/-weergave had een time-out)

Antwoord 9, autoriteit 2%

Dit is geen antwoord op de OP’s-vraag, maar aangezien ik hier belandde nadat ik verwoed naar een antwoord had gezocht, wilde ik delen wat we ontdekten.

In ons geval blijken deze 499’s te worden verwacht. Wanneer gebruikers bijvoorbeeld de type-ahead-functie in sommige zoekvakken gebruiken, zien we zoiets in de logboeken.

GET /api/search?q=h [Status 499] 
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]

Dus in ons geval denk ik dat het veilig is om proxy_ignore_client_abort onte gebruiken, wat in een eerder antwoord werd gesuggereerd. Bedankt daarvoor!

Antwoord 10, autoriteit 2%

Ik weet dat dit een oud draadje is, maar het komt precies overeen met wat mij onlangs is overkomen en ik dacht het hier te documenteren. De setup (in Docker) is als volgt:

• nginx_proxy
• nginx
• php_fpm met de eigenlijke app.

Het symptoom was een “502 Gateway Timeout” op de aanmeldingsprompt van de toepassing. Onderzoek van gevonden logs:

• de knop werkt via een HTTP POSTnaar /login… en zo …
• nginx-proxy heeft het verzoek /loginontvangen en heeft uiteindelijk een time-out gemeld.
• nginx retourneerde een 499reactie, wat natuurlijk betekent “de host overleden.”
• het /login-verzoek verscheen helemaal niet(!)in de logs van de FPM-server!
• er waren geen tracebacks of foutmeldingen in FPM … nada, zero, zippo, geen.

Het bleek dat het probleem was dat er geen verbinding met de database kon worden gemaakt om de aanmelding te verifiëren. Maar hoe dat te achterhalen bleek puur giswerk.

De volledige afwezigheid van logbestanden voor het traceren van toepassingen … of zelfs een record dat het verzoek was ontvangen door FPM … was een complete (en verwoestende …)verrassing voor mij. Ja, het is de bedoeling dat de toepassing fouten registreert, maar in dit geval lijkt het erop dat het FPM-werkproces is overleden met een runtime-fout, wat leidde tot de 499-reactie van nginx. Dit is duidelijk een probleem in onze applicatie … ergens. Maar ik wilde de bijzonderheden vastleggen van wat er gebeurde ten behoeve van de volgende mensen die met zoiets te maken krijgen.

Antwoord 11

Zodra ik 499 “Verzoek is verboden door antivirus”als een AJAX http-antwoord kreeg (vals positief door Kaspersky Internet Security met lichte heuristische analyse, wist diepe heuristische analyse correct dat er niets aan de hand was).

Antwoord 12

In mijn geval heb ik een configuratie zoals

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

Ik had de verkeerde AWS-beveiligingsgroep geconfigureerd voor de ECS(php-fpm)-service, dus Nginx kon de php-fpm-taakcontainer niet bereiken.
Daarom kreeg ik fouten in het nginx-taaklogboek

499 0 - elb-healthchecker/2.0

Gezondheidscontrole is geconfigureerd om de PHP-FPM-service te controleren en te bevestigen dat het op is en een reactie opneemt.

Antwoord 13

Ik heb dit probleem tegengekomen en de oorzaak was het gevolg van Kaspersky Protection Plugin in de browser. Als u dit tegenkomt, probeer dan uw plug-ins uit te schakelen en te zien of dat uw probleem oplost.

Antwoord 14

Een van de redenen voor dit gedrag kan u zijn gebruiken httpvoor uwsgiin plaats van socket. Gebruik de onderstaande opdracht als u uwsgirechtstreeks gebruikt.

uwsgi --socket :8080 --module app-name.wsgi

Dezelfde opdracht in .ini-bestand is

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

Antwoord 15

Voor mijn deel had ik ingeschakeld ufwmaar ik ben vergeten mijn upstreams-poorten bloot te stellen.