400 Bad Request: qué significa y cómo solucionarlo

Qué significa el 400 Bad Request

El RFC 9110 define el 400 como la forma que tiene el servidor de decir que no pudo entender la petición por una sintaxis mal formada. La palabra clave es sintaxis: el servidor no está evaluando quién eres, qué tienes permitido hacer, o si el recurso existe. Está diciendo que la propia petición, como bytes en el cable, no se interpreta como una petición HTTP válida. Eso puede ser la línea de la petición, las cabeceras o el cuerpo, según en qué punto se rinda el analizador.

Cómo aparece el error

Los navegadores muestran la página de error genérica que el servidor devuelva para un 400; no existe una página propia del navegador como sí la hay para un fallo de DNS o de certificado, ya que la conexión tuvo éxito y llegó una respuesta. Una variante habitual dice exactamente "400 Bad Request - request header or cookie too large", que nombra la causa directamente. Desde la línea de comandos:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Los registros del servidor son la prueba más útil aquí, porque a diferencia de un fallo del handshake TLS, la petición sí llegó a la capa de la aplicación y queda registrada, a menudo con la cabecera o línea concreta que falló al interpretarse.

Qué causa un 400 Bad Request

Para un visitante, en el orden en que es más probable que te lo encuentres:

• Cookies demasiado grandes o corruptas. Años de cookies acumuladas para un dominio, o una cookie dañada por una extensión o una mala redirección, producen habitualmente el mensaje exacto "400 Bad Request - request header or cookie too large" en cuanto el tamaño total de las cabeceras supera el límite del servidor.
• Una URL mal escrita o mal codificada. Un carácter suelto, un espacio sin codificar o una secuencia de codificación por porcentaje rota en la barra de direcciones o en un enlace pegado puede fallar al interpretarse como sintaxis válida.
• Una extensión del navegador que modifica peticiones. Los bloqueadores de anuncios, las herramientas de privacidad y algunas extensiones de VPN reescriben cabeceras o la línea de la petición, y un fallo en una de ellas puede entregar al servidor algo mal formado.
• Una redirección en caché que apunta a una URL rota. El navegador sigue una redirección obsoleta hacia una URL que en sí misma no es válida, y el 400 aparece en el destino, no en el enlace que realmente pulsaste.
• Una subida de archivo mayor de lo que permite el servidor. Algunas configuraciones de servidor responden a una subida demasiado grande con un 400 en lugar del más específico 413 Payload Too Large.

Para el propietario del sitio, aproximadamente en el orden en que merece la pena comprobarlo primero:

• Límites de tamaño de cabeceras o cookies fijados demasiado bajos para lo que la aplicación realmente envía, sobre todo después de añadir cookies de seguimiento, JWT en cabeceras o un mecanismo de sesión que crece con el tiempo.
• Una cabecera Host inválida o ausente, que puede producir un proxy inverso o un cliente mal configurado, y que la mayoría de los servidores necesitan para poder enrutar la petición.
• Un Content-Length que no coincide con el cuerpo realmente enviado, lo que puede causar un cliente roto o un proxy defectuoso en medio del camino.
• Reglas de firewall de aplicaciones web o ModSecurity que rechazan una petición cuya sintaxis parece correcta a un humano pero que coincide con un patrón defensivo que el WAF trata como mal formado.
• Una API que rechaza deliberadamente un JSON mal formado con un 400. Este caso es un comportamiento correcto, no un fallo: un cuerpo de petición que no se interpreta como JSON válido, o al que le falta un campo obligatorio que la API valida a nivel de sintaxis, debería devolver 400 por diseño.

Cómo saber de quién es la culpa

Reproduce la misma petición desde un entorno limpio: una ventana de navegación privada sin extensiones ni cookies acumuladas, o una llamada sencilla con curl a la misma URL. Si la petición limpia funciona, la causa era local, casi siempre cookies o una extensión. Si falla igual desde un cliente limpio y desde otro sitio completamente distinto, los propios límites o reglas del servidor están rechazando una petición legítimamente formada, y la forma más rápida de confirmarlo a gran escala es ejecutar una comprobación HTTP desde varias ubicaciones a la vez y comparar el código de estado que devuelve cada una.

Cómo corregir un 400 Bad Request

Si eres el visitante

1. Borra las cookies del sitio primero, ya que las cookies demasiado grandes o corruptas son con diferencia la causa más habitual. La mayoría de los navegadores permiten borrar las cookies de un solo sitio sin cerrar sesión en todos los demás.
2. Vuelve a intentarlo en una ventana privada o de incógnito. Una ventana limpia no tiene cookies acumuladas y, según el navegador, desactiva la mayoría de las extensiones por defecto, lo que aísla ambas causas habituales a la vez.
3. Revisa la URL en busca de erratas o caracteres sueltos, especialmente después de pegar un enlace de algún sitio que pueda haber añadido parámetros de seguimiento o roto la codificación.
4. Desactiva las extensiones una a una si el error persiste en una ventana normal pero no en la navegación privada, para encontrar cuál está reescribiendo la petición.
5. Prueba con otro dispositivo o red para descartar un portal cautivo o un proxy local que no tenga nada que ver con el sitio.

Si administras el sitio

1. Aumenta los límites de cabeceras y búfer si la aplicación realmente los necesita más grandes. En nginx:

   large_client_header_buffers 4 16k;

   En Apache:

   LimitRequestFieldSize 16384

   En IIS, revisa tanto maxRequestLength en web.config para el cuerpo de la petición como el valor del registro MaxFieldLength de HTTP.sys para las cabeceras individuales.
2. Reduce lo que realmente envías en cookies y cabeceras en lugar de limitarte a subir el límite. Eliminar cookies obsoletas, sacar los tokens grandes de las cabeceras y fijar tiempos de vida de cookie más cortos evita que el problema reaparezca a medida que crece el uso.
3. Revisa el tratamiento de la cabecera Host en el proxy inverso o el balanceador de carga, y confirma que reenvía un valor válido y esperado a la aplicación.
4. Lee los registros del WAF o ModSecurity para ver qué regla concreta se disparó, si hay uno delante de la aplicación; un falso positivo ahí necesita una excepción acotada, no desactivar todo el conjunto de reglas.
5. Confirma que un 400 de tu API es intencionado antes de "arreglarlo". Un cuerpo JSON mal formado o un campo que falla la validación a nivel de sintaxis debería devolver 400; en ese caso, la solución son mensajes de error más claros del lado del cliente, no cambiar el código de estado.

400 frente a códigos similares

• 401 Unauthorized significa que la petición se entendió bien, pero faltan credenciales válidas o fueron rechazadas.
• 403 Forbidden significa que la petición se entendió bien, pero el servidor se niega a autorizarla al margen de las credenciales.
• 404 Not Found significa que la petición se entendió bien y ningún recurso coincidió con la ruta.
• 413 Payload Too Large es el código específico para un cuerpo que supera un límite de tamaño, aunque en la práctica algunos servidores responden 400 en su lugar.
• 414 URI Too Long es el código específico para una línea de petición que supera un límite de longitud.
• 422 Unprocessable Content significa que la sintaxis se interpretó bien pero la semántica no, por ejemplo un JSON válido con un valor que falla la validación de negocio, una distinción más fina que la mayoría de las API no se molestan en hacer frente al 400.

Cómo evitar que un error 400 tumbe una página

Un 400 introducido por un despliegue que endureció los límites de cabeceras, o una actualización de una regla del WAF que empieza a coincidir con tráfico legítimo, no se manifestará como una caída ni como un tiempo de espera agotado, ya que el servidor responde al instante y correctamente según sus propias reglas. Una comprobación HTTP programada con una aserción sobre el código de estado esperado detecta esto en el momento en que empieza a ocurrir, en lugar de esperar a que se acumulen los tickets de soporte. Combinado con la monitorización desde varias ubicaciones, también te dice si el 400 es general o está ligado a la configuración de borde de una sola región.

Errores relacionados

La familia más amplia de códigos de error de cliente y servidor está cubierta en la guía de la familia 4xx. Consulta también 403 Forbidden para peticiones que el servidor entendió y rechazó, 404 Not Found para peticiones dirigidas a un recurso que no existe, y 429 Too Many Requests para peticiones rechazadas por límite de tasa en lugar de por sintaxis.

Preguntas frecuentes

¿Por qué borrar las cookies arregla un error 400?

Porque las cookies viajan como cabeceras en cada petición, y un servidor impone un tamaño total máximo de cabeceras. Años de cookies acumuladas, o una sola cookie corrupta, pueden llevar el total por encima de ese límite, y el servidor responde 400 antes de leer nada más de la petición.

¿Es igual un error 400 en todos los sitios web que visito?

El código y la causa general, una sintaxis de petición mal formada, son iguales en todas partes, pero el límite exacto que se superó y el texto exacto de la página de error los fija la configuración de servidor propia de cada sitio.

¿Debería mi API devolver 400 para una entrada inválida?

Sí, cuando la entrada no se puede interpretar o le falta un campo que la API comprueba a nivel de sintaxis. Eso es el 400 funcionando como debe, no un fallo que arreglar relajando la validación.

¿Puede un WAF causar un error 400 en una petición que parece completamente normal?

Sí. Una regla de WAF puede marcar un patrón en una URL, cabecera o cuerpo que es técnicamente HTTP válido pero coincide con una firma defensiva, y algunas configuraciones de WAF responden con un 400 genérico en lugar de una página de bloqueo más específica.

¿Cuál es la diferencia entre el 400 y el 413?

El 413 es el código específico para un cuerpo de petición que supera un límite de tamaño configurado. Muchos servidores lo usan correctamente, pero algunos responden 400 en su lugar para esa misma condición de cuerpo demasiado grande, así que no asumas que el código por sí solo te dice la causa exacta sin revisar la documentación o los registros propios del servidor.