La solicitud está mal formada o no es válida.
Cuándo usarlo
JSON que no se puede analizar, campos obligatorios ausentes, tipos incorrectos.
Causas habituales y soluciones
Causas habituales: JSON mal formado, como una coma final o cadenas entre comillas simples, un cuerpo que no coincide con el Content-Type declarado, campos obligatorios que faltan o parámetros de consulta no válidos. Antes de culpar al servidor, mira los bytes exactos que se enviaron, con curl -v o con el payload de la solicitud en la pestaña Network de DevTools. La mayoría de las API explican el problema en el cuerpo de la respuesta, así que léelo.
La infraestructura también produce 400: nginx devuelve “Request Header Or Cookie Too Large” cuando las cookies desbordan large_client_header_buffers, y “The plain HTTP request was sent to HTTPS port” cuando usas http:// en el puerto 443. Los balanceadores de carga rechazan cabeceras o valores de Host mal formados. Borrar las cookies del sitio soluciona muchos 400 que solo ocurren en el navegador. En tu propio servidor, reserva 400 para entradas que no se pueden analizar y usa 422 cuando falla la validación.
Error del cliente (4xx)
Los códigos 4xx son errores del cliente: la solicitud en sí es incorrecta, no está autorizada o apunta a algo que no existe. Repetir la misma solicitud no servirá de nada.
Cómo se ve
HTTP/1.1 400 Bad RequestCómo enviarlo
| Node.js / Express | res.status(400).end() |
|---|---|
| Python / Flask | return '', 400 |
| nginx | return 400; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/