HTTP 499 Client Closed Request: Solucionat

HTTP 499 Client Closed Request: Solucionat

T’ajudem a entendre l’error HTTP 499 Client Closed Request: quines són les causes i com solucionar-lo.

Table of Contents

Què és l’error 499 Client Closed Request?

El 499 HTTP és un codi d’estat no estàndard introduït per Nginx i es produeix quan un client, per exemple un navegador, tanca la connexió mentre Nginx encara està processant la sol·licitud.

Com corregir l’error 499 Client Closed Request

Hi ha diverses raons per les quals el client no processa la petició o “request” i acaba mostrant-se el codi d’error 499. En els apartats següents t’ajudarem a identificar les diferents causes i com solucionar-ho en cada cas.

Error 499 quan la web està darrera d’un servidor intermediari

Pots trobar errors 499 quan tens un servei de balanceig de càrrega “Load Balancer” entre els teus usuaris i el teu Nginx. Una situació similar passa quan la teva web servida amb Nginx està treballant amb un CDN o està darrere d’un tallafocs WAF (Web Application Firewall).

L’error 499, en aquest cas, es dóna quan el servidor frontal que atén la sol·licitud del navegador és un servidor Nginx en mode de proxy invers “reverse proxy” i envia la sol·licitud al teu web server, però el procés de la pàgina és lent i se supera el temps d’espera del servidor frontal.

el balancejador de càrrega proxy dóna lerror 499 esperant el servidor de WordPress
L’Error 499 apareix en aquest esquema quan el “Load Balancer” Nginx s’esgota esperant la resposta del servidor de WordPress.

Per corregir aquest error, pots:

  • Augmentar la capacitat de processament del teu servidor. En augmentar el “poder de processament”, reduiràs el temps d’espera dels proxies Nginx que estan davant del teu server.
  • Si no pots augmentar la potència del teu servidor, augmenta els temps d’espera “timeouts” dels teus servidors intermediaris (Load Balancer, CDN, Firewall, …).

A Wetopi pots augmentar la mida del teu servidor amb un sol clic.

★ Configuració zero: els fitxers de configuració per a tots els serveis del servidor s’ajusten de forma transparent a la potència.

La seqüència correcta per a configurar els temps d’espera

Si hi ha proxies a la teva configuració, com un “Load Balancer”, un Tallafocs, un CDN, etc., has de configurar els temps d’espera perquè el “timeout” succeeixi primer al teu servidor i després als altres proxies per ordre, a mida que ens apropem a l’usuari. D’aquesta manera, tindrem un missatge clar de l’error i en quina capa de servei passa.

Exemple:

Usuari → CDN → Nginx Load Balancer → Aplicació Nginx → Php_fpm

Es recomana establir els temps d’espera així:

  • n segons per al temps d’espera de Php_fpm.
    Configura el php.inimax_execution_timei
    el request_terminate_timeout al fitxer de configuració de php_fpm.
  • n+1 segons per al temps despera de laplicació Nginx.
    Configura fastcgi_read_timeout a la configuració de nginx.
  • n+2 segons per al temps d’espera de Nginx Load Balancer
    Al location, on esteu fent el proxy_pass, establiu els temps d’espera de:
    proxy_connect_timeout
    proxy_send_timeout
    proxy_read_timeout
  • n+3 segons de temps d’espera per al CDN.
    NOTA: Si no pots configurar els temps d’espera del teu CDN, investiga quin és el seu temps d’espera i ajusta els altres temps d’acord amb ell.

Proporciona una cadena correcta de temps d’espera.
Establir una cadena incremental de temps d’espera us permet trobar el problema i en quina capa de servei passa.

499 quan el servidor va tancar la connexió

Aquest podria ser el teu cas, si:

  1. la teva web o aplicació s’està executant en un servidor Nginx i,
  2. la sol·licitud es passa per un processador d’aplicacions “CGI”, per exemple, php_fpm, o
  3. la sol·licitud es passa a una API externa.

Aquest codi derror 499 es produeix quan el teu servidor és massa lent executant codi.

per exemple, el procés de la teva pàgina de WordPress triga massa o es queda penjat.

NOTA: Pots identificar el cas si a la configuració de Nginx fas servir la directiva fastcgi_pass.

Per corregir aquest error, pots:

  • Augmentar la capacitat de processament del teu servidor. En augmentar el “poder de processament”, reduiràs el temps despera del teu Nginx.
  • Si no pots augmentar la potència del servidor, augmenta el temps d’espera de Nginx amb la directiva: fastcgi_read_timeout.

A Wetopi, tens configuració zero: els fitxers de configuració per a tots els serveis del servidor s’ajusten de forma transparent a la potència.

Com corregir l’error 499 quan mor la teva aplicació

Si la teva aplicació mor sense una resposta, la solució podria estar al codi de la teva API, CGI o gestor de continguts.

NOTA: Aquest és el cas menys comú. PHP i altres processadors sempre retornen un missatge notificant el problema. Si l’aplicació llançava un error, Nginx us passaria un codi d’error 5XX, no un 499.

Si la vostra aplicació es congela, teniu 2 opcions:

  • Primer, configura el teu Nginx perquè esperi més temps. Augmenta els temps d’espera de l’Nginx modificant fastcgi_read_timeout.
  • Si esperar més no resol el problema, augmenta la capacitat de processament del servidor.
  • Si l’error 499 es produeix en alguna pàgina o petició en concret, podria tractar-se d’un bloqueig o “code freeze” a la teva aplicació o gestor de continguts. Si utilitzes WordPress, revisa la compatibilitat dels connectors. Si es realitzen consultes a Base de Dades, revisa el bon estat de taules i índexs.

499 quan el teu servidor està sota un atac DoS o DDoS

Es pot donar el cas en què algú atac i intencionalment consumeixi els recursos del servidor. Això fa que el servidor no pugui processar les sol·licituds i no se serveixin les peticions a temps.

Per verificar si aquest és el vostre cas: mira a la teva eina d’anàlisi de “logs” i busca pics en el trànsit amb sol·licituds que donin el codi d’estat 499:

pics de trànsit amb 499 errors al registre de trànsit
Llistat de peticions utilitzant el panell de Kibana contra Elastic Search

Com corregir l’error 499 quan patim un atac DoS/DDoS:

En aquest cas, la millor solució és una combinació de mesures de seguretat:

A Wetopi, com a especialistes en WordPress , sabem com és d’important disposar de fortes mesures de seguretat.

Apliquem tres tècniques per filtrar el trànsit :

Aprenentatge heurístic compartit,
Llistes negres de fonts externes i
Mitigació d’atacs DDoS.

Resumidament, som uns techies apassionats per WordPress que hem creat Wetopi, un Allotjament WordPress Gestionat, per minimitzar la fricció a la que tot professional s’enfronta en treballar i allotjar projectes WordPress.

No tens un compte a wetopi?

Inclou servidors de desenvolupament Gratis.
No cal tarjeta de crèdit.

Tots els Codis d’estat HTTP

200 OK

201 Created

202 Accepted

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status

208 Already Reported

226 IM Used

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

307 Temporary Redirect

308 Permanent Redirect

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Payload Too Large

414 Request-URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m A Teapot

421 Misdirected Request

422 Unprocessable Entity

423 Locked

424 Failed Dependency

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

444 Connection Closed Without Response

451 Unavailable For Legal Reasons

499 Client Closed Request

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

510 Not Extended

511 Network Authentication Required

599 Network Connect Timeout Error