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

¿Qué es el error 400 Bad Request?

400 Bad Request es un código de estado HTTP que significa que el servidor recibió tu petición pero no la va a procesar porque algo en la propia petición parece incorrecto. El estándar HTTP (RFC 9110, sección 15.5.1) lo define como la situación en la que el servidor no puede o no quiere procesar una petición "due to something that is perceived to be a client error" (por algo que se percibe como un error del cliente), como una sintaxis mal formada, un encuadre de mensaje no válido o un enrutamiento engañoso de la petición.

A diferencia de un error 500, que significa que el servidor falló, un 400 señala a la petición: la URL, las cabeceras, las cookies o los datos que envió tu navegador o tu aplicación. Normalmente el sitio web funciona bien para todos los demás.

Es una buena noticia para los visitantes, porque la solución suele estar de tu lado y lleva un minuto: detrás de la mayoría de los errores 400 hay un enlace mal escrito o una cookie dañada.

Cómo se ve un error 400

El mensaje depende del software del servidor, y el texto adicional suele ser la mejor pista sobre la causa:

¿Qué causa un error 400 Bad Request?

• Una URL mal formada. Un signo % suelto, un espacio, un carácter que debería haberse codificado, o un enlace que se cortó o se pegó dos veces.

• Cookies dañadas o demasiado grandes. Los sitios que crean muchas cookies (inicios de sesión, tests A/B, analítica) pueden hacer que la cabecera Cookie supere el límite del servidor. Una cookie que se dañó durante una actualización también puede ser rechazada.

• Cabeceras de petición demasiado grandes. Además de las cookies, los tokens de autenticación largos o las cabeceras que añaden las extensiones y los proxies van sumando.

• Datos no válidos enviados a una API. Faltan campos obligatorios, el JSON está mal formado o la cabecera Content-Type es incorrecta.

• HTTP enviado a un puerto HTTPS. Es habitual detrás de balanceadores de carga y proxies inversos.

• Un archivo demasiado grande. Muchos servidores responden 413 Content Too Large, pero algunas aplicaciones y frameworks devuelven 400 en su lugar.

Solución 1: revisa la URL

Mira con atención la barra de direcciones. Estos son los problemas a los que conviene estar atento:

• Un % que no va seguido de dos caracteres hexadecimales (%20 es correcto; %2 o %zz no).

• Espacios, { }, |, \ u otros caracteres poco habituales, sobre todo en enlaces copiados de correos, PDF o aplicaciones de chat.

• Un enlace que se pegó dos veces (https://example.com/https://example.com/...) o que quedó cortado a medias.

• Una URL muy larga con parámetros de seguimiento. Borra todo a partir del ? y vuelve a intentarlo.

Si llegaste desde un enlace de otro sitio, ve a la página de inicio del sitio y navega desde allí hasta la página.

Solución 2: borra las cookies solo de ese sitio

Esto resuelve la mayoría de los errores 400 en sitios que ya habías usado, sobre todo los mensajes que hablan de cookies o cabeceras "too large" o "too long" (demasiado grandes o demasiado largas). No hace falta borrar las cookies de todos los sitios, solo las de este:

• Chrome / Edge: haz clic en el icono a la izquierda de la barra de direcciones → Cookies y datos de sitios (o Configuración del sitio) → elimina los datos del sitio y recarga.

• Firefox: haz clic en el candado → Limpiar cookies y datos del sitio…

• Safari (Mac): Safari → Ajustes → Privacidad → Gestionar datos de sitios web… → busca el sitio → Eliminar.

• iPhone: Ajustes → Apps → Safari → Avanzado → Datos de sitios web → desliza el sitio hacia la izquierda para eliminarlo.

Solución 3: prueba en modo incógnito y luego borra la caché

Abre la página en una ventana de incógnito/privada (Ctrl + Shift + N en Chrome y Edge, Ctrl + Shift + P en Firefox, Cmd + Shift + N en Safari). Las ventanas privadas empiezan sin cookies y sin extensiones, así que si la página funciona ahí, la solución 2 o la 4 lo resolverán de forma definitiva.

Si el modo incógnito también falla, borra la caché del navegador (Ctrl + Shift + Supr → Imágenes y archivos almacenados en caché) y, como último paso, vacía la caché DNS. El DNS rara vez causa un 400, pero cuando un sitio cambia de servidores, una dirección desactualizada puede llevarte a un servidor que rechaza tu petición.

Solución 4: desactiva las extensiones y revisa el tamaño de los archivos

Las extensiones que modifican las peticiones, como las herramientas de privacidad, los editores de cabeceras, los buscadores de cupones y algunos bloqueadores de anuncios, pueden añadir o cambiar cabeceras de una forma que el servidor rechaza. Desactívalas todas, recarga y luego vuelve a activarlas de una en una para encontrar a la culpable.

Si el error aparece al subir un archivo, prueba con uno más pequeño. Comprime las imágenes o divide los archivos grandes. Así sabrás si el servidor está rechazando el tamaño, aunque lo notifique como un 400 en lugar de un 413.

Para propietarios de sitios web: cómo encontrar la causa de los errores 400

Si los usuarios te informan de errores 400 en tu sitio, empieza por el mensaje exacto que ven y por los logs del servidor. nginx y Apache registran el motivo en el nivel info, así que sube temporalmente el nivel del log de errores si no lo ves; el log de acceso muestra qué URL devuelven 400. La herramienta Cabeceras HTTP de DNS Robot muestra el código de estado, el software del servidor y todas las cabeceras Set-Cookie que envía una página, lo que te ayuda a detectar cookies que no paran de crecer.

# ¿Qué peticiones reciben un 400? (formato de log combined de nginx)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Los motivos que registró nginx (requiere error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large"

nginx lee las cabeceras de la petición en búferes definidos por large_client_header_buffers, que por defecto son 4 búferes de 8 KB. Una sola línea de cabecera que no cabe en un búfer, normalmente la cabecera Cookie, provoca este 400. El límite equivalente en Apache es LimitRequestFieldSize, de 8190 bytes por defecto.

La solución correcta es enviar menos: elimina las cookies que ya no necesitas, mantén pequeñas las cookies de sesión y limita cada cookie a las rutas y subdominios que la usan. Si de verdad necesitas cabeceras más grandes, por ejemplo para tokens grandes de inicio de sesión único (SSO), sube el límite:

# nginx (bloque http o server)
large_client_header_buffers 4 16k;

# Equivalente en Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port"

nginx devuelve este 400 cuando algo envía HTTP sin cifrar a un puerto en el que nginx espera TLS, normalmente el 443. Las causas típicas son un balanceador de carga o un proxy que reenvía tráfico http:// al puerto 443, un enlace con http://example.com:443 o una antigua directiva ssl on; que hace que un puerto espere TLS cuando no debería.

Asegúrate de que cada línea listen coincide con lo que llega a ella: listen 443 ssl; para HTTPS y listen 80; para HTTP sin cifrar, con una redirección del 80 al 443. Asegúrate también de que el proxy que tienes delante habla HTTPS con el 443 (o HTTP con el 80).

Errores 400 de las API

Las API usan el 400 para las peticiones que no superan la validación. Si estás llamando a una API, lee el cuerpo de la respuesta, porque la mayoría de las API explican qué campo es incorrecto. Después comprueba que envías un JSON válido, la cabecera Content-Type: application/json correcta y todos los parámetros obligatorios.

Si estás creando una API, devuelve un cuerpo que indique el problema (por ejemplo, {"error": "email is required"}), y plantéate usar 422 Unprocessable Content para las peticiones bien formadas pero semánticamente no válidas, reservando el 400 para las peticiones que ni siquiera se pueden interpretar.

400 frente a 401, 403, 404, 413, 429 y 431

Nuestras guías de los códigos vecinos: 403 Forbidden, 401 Unauthorized y 429 Too Many Requests. Para redirecciones que entran en bucle en lugar de fallar, consulta ERR_TOO_MANY_REDIRECTS; el Verificador de Redirecciones muestra cada salto.