HTTP 499 Client Closed Request: Les 3 causes més freqüents i com solucionar-les

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?
• Com corregir l’error 499 Client Closed Request
  • Error 499 quan la web està darrera d’un servidor intermediari
    • La seqüència correcta per a configurar els temps d’espera
  • 499 quan el servidor va tancar la connexió
    • Com corregir l’error 499 quan mor la teva aplicació
  • 499 quan el teu servidor està sota un atac DoS o DDoS
    • Com corregir l’error 499 quan patim un atac DoS/DDoS:
• Tots els Codis d’estat HTTP

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.

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:

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

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

• Prevenció: evita el trànsit no legítim. Pots filtrar el trànsit maliciós amb una combinació de llistes negres públiques i privades.
• Afegir protecció d’infraestructura contra DOS (Denegació de servei) i DDOS (Denegació de servei Distribuïda). Troba un proveïdor d’allotjament amb infraestructura llesta per mitigar aquest tipus d’atacs.
• Afegir una capa de protecció, un servidor intermediari de seguretat, davant del teu servidor, o
• Contracta un servei de seguretat extern. Un de molt conegut és Cloudflare. Cloudlare desplega una infraestructura distribuïda davant del teu servidor per lluitar contra els atacs DDOS.

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 Hosting WordPress Gestionat, per minimitzar la fricció a la que tot professional s’enfronta en treballar i allotjar projectes WordPress.

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

Tots els Codis d’estat HTTP