¿Qué es un error 400 Bad Request y cómo se soluciona?

Un error 400 Bad Request es un código de estado HTTP/1.1 de error del cliente definido en RFC 9110 que indica al servidor que recibió una solicitud que no puede o no procesará porque la solicitud en sí está mal formada. A diferencia de los errores 5xx, que se originan en el lado del servidor, un error 400 sitúa la culpa directamente en el cliente, lo que significa que el problema está en la solicitud enviada, no en la capacidad del servidor para responder.

En términos prácticos, un error 400 se produce antes de que el servidor intente siquiera cumplir la solicitud. El servidor analiza el mensaje HTTP entrante, detecta algo estructural o semánticamente inválido — un encabezado corrupto, una URI mal formada, una carga útil demasiado grande, una cookie incorrecta — y devuelve inmediatamente 400 Bad Request en lugar de continuar. Conocer esta distinción es el camino más rápido hacia un diagnóstico correcto.

Qué significa realmente el código de estado 400 a nivel de protocolo

HTTP opera bajo un estricto contrato de solicitud-respuesta. Cada solicitud debe ajustarse a la gramática definida en la especificación HTTP. Cuando un cliente envía un mensaje que viola esta gramática, el servidor tiene permitido y se espera que lo rechace con una respuesta 400.

El servidor no registra un 400 como su propio fallo. Lo registra como una solicitud de cliente rechazada. Por eso reiniciar ciegamente un servidor o limpiar la caché de un CDN rara vez soluciona un 400 genuino — la causa raíz casi siempre está en la construcción de la solicitud.

Las variantes más comunes de este error renderizadas por el navegador incluyen:

• 400 Bad Request
• HTTP Error 400
• Bad Request — Invalid URL
• 400. That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request. The server cannot or will not process the request due to something that is perceived to be a client error.

Todas estas corresponden al mismo código de estado HTTP subyacente. La redacción varía según el software del servidor (Apache, Nginx, IIS, Cloudflare) y el framework de la aplicación.

Causas raíz de un error 400 Bad Request

Comprender el desencadenante preciso es esencial antes de intentar cualquier solución. Las causas se dividen en dos categorías: del lado del cliente y mala configuración del lado del servidor.

Causas del lado del cliente

URL mal formada o codificada incorrectamente

Una URL que contiene espacios sin codificar, caracteres ilegales o secuencias de codificación porcentual rotas será rechazada inmediatamente. La especificación HTTP requiere que todos los caracteres fuera del conjunto no reservado (A–Z, a–z, 0–9, -, _, ., ~) estén codificados en porcentaje antes de la transmisión.

Cookies corruptas o demasiado grandes

Las cookies se transmiten en el encabezado de solicitud Cookie. Si el valor de una cookie está mal formado, supera el límite de tamaño por cookie del navegador (normalmente 4096 bytes), o contiene caracteres que violan RFC 6265, el servidor puede rechazar toda la solicitud. Esta es una de las causas más frecuentemente ignoradas de errores 400 intermitentes en sitios que el usuario ha visitado previamente sin problemas.

Encabezados de solicitud inválidos o requeridos ausentes

Algunas APIs y aplicaciones web aplican una validación estricta de encabezados. Un Content-Type ausente en una solicitud POST, un encabezado Authorization mal formado, o un encabezado Accept con un tipo de medio no compatible pueden desencadenar un 400.

Carga útil de solicitud demasiado grande

Los servidores web y los proxies inversos aplican límites máximos de tamaño del cuerpo. Nginx usa client_max_body_size (predeterminado: 1 MB); Apache usa LimitRequestBody. Superar estos umbrales produce una respuesta 400 o 413 según la configuración.

Caché DNS obsoleta o incorrecta

Aunque los fallos de resolución DNS normalmente producen errores de conexión en lugar de errores HTTP 400, una caché DNS envenenada u obsoleta que enruta una solicitud al servidor incorrecto — uno que no reconoce el encabezado Host — puede resultar en que el origen incorrecto devuelva un 400.

Extensiones del navegador que interfieren con los encabezados de solicitud

Ciertos bloqueadores de anuncios, herramientas de privacidad y extensiones de desarrollador modifican los encabezados HTTP salientes. Si una extensión inyecta un encabezado mal formado o duplicado, el servidor puede rechazar la solicitud.

Causas del lado del servidor

Reglas .htaccess mal configuradas (Apache)

Las reglas de reescritura, directivas de redirección o entradas de control de acceso con errores de sintaxis pueden hacer que Apache genere un 400 antes de que la solicitud llegue a la capa de la aplicación.

Errores de configuración de Nginx

Directivas server_name inválidas, bloques location rotos o configuraciones proxy_pass incorrectas pueden hacer que Nginx devuelva un 400 para solicitudes que no puede enrutar.

Bloqueo excesivo de WAF o plugin de seguridad

Los Firewalls de Aplicaciones Web — ya sea a nivel de servidor (ModSecurity), a nivel de CDN (Cloudflare WAF) o a nivel de aplicación (plugins de seguridad de WordPress) — pueden marcar solicitudes legítimas como maliciosas y devolver un 400 o 403. Esto es común cuando los parámetros de la solicitud contienen cadenas que coinciden con firmas de inyección SQL o XSS.

Fallos de validación a nivel de aplicación

Frameworks como Laravel, Django o Express.js devuelven 400 cuando falla la validación de entrada — por ejemplo, un campo JSON requerido está ausente, un campo de fecha tiene el formato incorrecto, o un parámetro numérico recibe un valor de cadena.

Cómo solucionar un error 400 Bad Request: pasos del lado del cliente

1. Validar y corregir la URL

Inspeccione la URL carácter por carácter. Preste especial atención a:

• Espacios sin codificar: Un espacio debe ser %20, no un espacio literal o + (fuera de datos de formulario).
• Barras dobles o barras faltantes: https://example.com//path o https://example.com/path? con un signo de interrogación colgante.
• Codificación porcentual rota: Un % no seguido de exactamente dos dígitos hexadecimales es ilegal.
• Caracteres no ASCII: Los nombres de dominio con caracteres Unicode deben usar Punycode; los segmentos de ruta con Unicode deben estar codificados en porcentaje en UTF-8.

Una URL correctamente codificada tiene este aspecto:

https://example.com/search?q=hello%20world&lang=en

No así:

https://example.com/search?q=hello world&lang=en

2. Limpiar cookies y caché del navegador

Esto resuelve la mayoría de los errores 400 encontrados en sitios que el usuario ha visitado previamente.

Google Chrome:

1. Abra chrome://settings/clearBrowserData
2. Establezca el intervalo de tiempo en Todo el tiempo
3. Marque Cookies y otros datos de sitios e Imágenes y archivos en caché
4. Haga clic en Borrar datos

Mozilla Firefox:

1. Abra about:preferences#privacy
2. En Cookies y datos del sitio, haga clic en Limpiar datos
3. Seleccione ambas opciones y confirme

Safari (macOS):

1. Vaya a Safari > Configuración > Privacidad
2. Haga clic en Gestionar datos de sitios web, luego en Eliminar todo

Para un enfoque más específico — especialmente útil cuando no desea perder todos los datos de sesión — use las herramientas de desarrollador del navegador para eliminar solo las cookies del dominio específico:

1. Abra DevTools (F12 o Cmd+Option+I)
2. Navegue a Aplicación > Almacenamiento > Cookies
3. Seleccione el dominio y elimine las cookies individuales

3. Vaciar la caché DNS

Windows:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Linux (nscd):

sudo service nscd restart

Después de vaciar, verifique que la resolución sea correcta antes de volver a intentarlo:

nslookup example.com

4. Deshabilitar extensiones del navegador

Las extensiones que modifican encabezados HTTP son las más probables culpables. En lugar de deshabilitar todas las extensiones simultáneamente, use primero el modo incógnito o privado del navegador — la mayoría de las extensiones están deshabilitadas por defecto en ventanas privadas. Si la página carga correctamente en incógnito, una extensión es la responsable.

Para aislar la extensión específica en Chrome:

1. Navegue a chrome://extensions/
2. Deshabilite todas las extensiones
3. Vuelva a habilitarlas una a una, recargando la página después de cada una

5. Probar en un navegador, dispositivo o red diferente

Este paso determina rápidamente si el problema es específico del entorno. Si la página carga en un dispositivo móvil usando datos móviles pero falla en su escritorio, el problema es probablemente local — ya sea la configuración del navegador, un proxy a nivel de red o un firewall corporativo que modifica los encabezados de solicitud.

Cómo solucionar un error 400 Bad Request: pasos del lado del servidor

Estos pasos se aplican a propietarios de sitios web, desarrolladores y administradores de sistemas con acceso al servidor o al panel de control de alojamiento.

6. Analizar los registros de acceso y errores del servidor

Los registros del servidor son la herramienta de diagnóstico definitiva. Una entrada 400 en el registro de acceso mostrará la línea de solicitud sin procesar que fue rechazada.

Registro de errores de Nginx (ruta predeterminada):

tail -n 100 /var/log/nginx/error.log | grep " 400 "

Registro de errores de Apache:

tail -n 100 /var/log/apache2/error.log

Registro de acceso de Nginx — filtrar respuestas 400:

awk '$9 == 400' /var/log/nginx/access.log | tail -20

Busque patrones: ¿los errores 400 provienen de un endpoint específico, un agente de usuario específico o un parámetro específico? Esto reduce drásticamente la causa raíz.

Si está ejecutando un entorno de Alojamiento VPS, tiene acceso SSH directo a estos registros. En Alojamiento Web Compartido administrado, los registros de acceso generalmente están disponibles a través de la sección Errores de cPanel o mediante la descarga del registro de Acceso sin procesar.

7. Auditar el archivo .htaccess (Apache)

Un solo error de sintaxis en .htaccess puede hacer que Apache devuelva errores 400 o 500 para cada solicitud. Valide la sintaxis del archivo sin reiniciar Apache:

apachectl -t

Problemas comunes de .htaccess que producen errores 400:

• Patrones RewriteRule con caracteres especiales sin escapar

LimitRequestBody establecido en un valor inesperadamente bajo
Directivas Header mal formadas

Ejemplo de una directiva problemática:
# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""
Versión corregida:
RequestHeader set X-Custom-Header "value with escaped quotes"
8. Verificar la configuración de Nginx
Valide toda la configuración de Nginx antes de aplicar cambios:
nginx -t
Preste atención a client_max_body_size si los usuarios están subiendo archivos:
http {
    client_max_body_size 50M;
}
También revise large_client_header_buffers — si los encabezados de solicitud (incluidas las cookies) superan el tamaño del búfer, Nginx devuelve un 400:
http {
    large_client_header_buffers 4 16k;
}
Después de editar, recargue sin tiempo de inactividad:
nginx -s reload
9. Aumentar los límites de carga de archivos
Si el error 400 ocurre específicamente durante la carga de archivos, el cuerpo de la solicitud probablemente está superando el límite configurado del servidor.
PHP (php.ini):
upload_max_filesize = 50M
post_max_size = 55M
Apache (httpd.conf o .htaccess):
LimitRequestBody 52428800
Nginx (nginx.conf):
client_max_body_size 50M;
Tenga en cuenta que post_max_size en PHP siempre debe ser mayor que upload_max_filesize, o PHP descartará silenciosamente la carga y la aplicación puede devolver un 400.
10. Revisar las reglas WAF y los plugins de seguridad
Si está ejecutando ModSecurity, Cloudflare WAF o un plugin de seguridad de WordPress (Wordfence, iThemes Security), deshabilite temporalmente el conjunto de reglas WAF y pruebe si el 400 desaparece. Si es así, revise el registro de auditoría del WAF para identificar qué regla está activando:
tail -f /var/log/modsec_audit.log
No deshabilite el WAF permanentemente. En su lugar, cree una excepción específica para el patrón de solicitud legítima que está siendo bloqueada.
400 Bad Request vs. códigos de error HTTP relacionados
Comprender dónde se sitúa el 400 en la taxonomía de errores HTTP previene diagnósticos erróneos.



Código de estado
Nombre
Ubicación del fallo
Causa típica








—
—
—
—








400
Bad Request
Cliente
Sintaxis de solicitud mal formada, encabezados inválidos, codificación incorrecta








401
Unauthorized
Cliente
Credenciales de autenticación ausentes o inválidas








403
Forbidden
Política del servidor
Solicitud válida, pero el acceso es denegado por las reglas del servidor








404
Not Found
Servidor
El recurso no existe en la URI solicitada








413
Content Too Large
Cliente
El cuerpo de la solicitud supera el límite de tamaño configurado del servidor








414
URI Too Long
Cliente
La URI de solicitud supera la longitud máxima de URI del servidor








422
Unprocessable Content
Cliente
Sintácticamente válido pero semánticamente incorrecto (común en APIs REST)








431
Request Header Fields Too Large
Cliente
El tamaño individual o total de los encabezados supera los límites del servidor








500
Internal Server Error
Servidor
Excepción no manejada o mala configuración en el servidor








502
Bad Gateway
Servidor/Proxy
El servidor upstream devolvió una respuesta inválida





Una distinción operativa clave: 413 (Content Too Large) es el código semánticamente más preciso para cargas demasiado grandes, pero muchos servidores — en particular configuraciones antiguas de Apache y Nginx — devuelven 400 en su lugar. Si ve un 400 al cargar archivos, compruebe siempre primero los límites de tamaño del cuerpo.
Errores 400 en contextos de API
Las APIs REST y GraphQL usan el 400 ampliamente como respuesta estándar para fallos de validación de entrada. Si está construyendo o consumiendo una API, el cuerpo de una respuesta 400 normalmente contendrá una carga útil de error estructurada:
{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}
Al depurar errores 400 de API:

Verifique que el encabezado Content-Type coincida con el formato del cuerpo (application/json para cargas útiles JSON, multipart/form-data para cargas de archivos)
Confirme que los campos y encabezados requeridos estén presentes y correctamente tipados
Compruebe que los valores de cadena no superen las restricciones de longitud máxima
Valide los formatos de fecha y hora según la especificación de la API (ISO 8601 es estándar: 2024-01-15T10:30:00Z)
Inspeccione el formato del encabezado Authorization — los tokens Bearer deben ir prefijados con Bearer , no pasarse en bruto

Para equipos que ejecutan servicios de API en Servidores Dedicados, habilitar el registro detallado de solicitudes a nivel de aplicación (no solo a nivel del servidor web) es fundamental para diagnosticar patrones de 400 a escala.
Diagnóstico de errores 400 con las herramientas de desarrollador del navegador
El panel de Red del navegador es la herramienta de diagnóstico del lado del cliente más precisa disponible.

Abra DevTools (F12)
Navegue a la pestaña Red
Reproduzca la solicitud que desencadena el 400
Haga clic en la solicitud fallida en la cascada
Inspeccione la pestaña Encabezados — revise tanto los Encabezados de solicitud como los Encabezados de respuesta
Compruebe la pestaña Respuesta para ver cualquier detalle de error devuelto por el servidor

El panel de Encabezados de solicitud mostrará exactamente lo que el navegador envió. Compare esto con lo que el servidor espera. Preste especial atención a:

Valor del encabezado Host

Prevención de errores 400 en aplicaciones web

Para desarrolladores y administradores de servidores, las medidas proactivas reducen significativamente la incidencia de errores 400.

Saneamiento y validación de entrada en la capa de aplicación — Valide toda la entrada suministrada por el usuario antes de que llegue a la capa de enrutamiento del servidor. Devuelva respuestas 400 descriptivas con mensajes de error a nivel de campo en lugar de fallos genéricos.

Implemente la codificación de URL adecuada en el código del cliente — Use funciones de codificación integradas en lugar de manipulación manual de cadenas:

// JavaScript — correct approach
const query = encodeURIComponent("hello world & more");
const url = `https://example.com/search?q=${query}`;

# Python — correct approach
from urllib.parse import urlencode
params = urlencode({"q": "hello world & more"})
url = f"https://example.com/search?{params}"

Establezca límites de tamaño del cuerpo explícitos y razonables — No deje client_max_body_size en el valor predeterminado de 1 MB si su aplicación acepta cargas de archivos. Igualmente, no lo establezca como ilimitado — esto crea un vector de denegación de servicio.

Monitoree las tasas de 400 en producción — Un pico repentino en errores 400 es a menudo el primer indicador de un bot que escanea en busca de vulnerabilidades, un formulario del lado del cliente roto o un despliegue que introdujo un cambio de API incompatible. Configure alertas sobre su tasa de errores 4xx en su stack de monitoreo (Grafana, Datadog, CloudWatch).

Use HTTPS con un certificado SSL válido — Algunos errores 400 surgen cuando los clientes envían solicitudes HTTPS a un servidor que no está correctamente configurado para TLS, o cuando una discrepancia de certificado hace que el handshake TLS falle antes de que se alcance siquiera la capa HTTP. Asegurarse de que sus Certificados SSL sean válidos, estén correctamente instalados y cubran todos los subdominios requeridos elimina completamente esta clase de error.

Configure correctamente los entornos del panel de control — Si gestiona múltiples sitios a través de un panel de control, las definiciones de host virtual mal configuradas son una fuente común de errores 400. Los entornos que usan VPS con cPanel deben verificar que la raíz del documento de cada dominio, el enlace SSL y las reglas de reescritura estén correctamente delimitados para evitar la contaminación de solicitudes entre dominios.

Matriz de decisión: diagnóstico de un error 400 por síntoma

Lista de verificación técnica: resolución de un error 400 Bad Request

Para usuarios finales:

• Inspeccione y vuelva a escribir manualmente la URL, corrigiendo cualquier problema de codificación
• Limpie las cookies y la caché específicamente para el dominio afectado
• Pruebe en una ventana privada/incógnito para descartar extensiones
• Vacíe la caché DNS local
• Pruebe en un navegador, dispositivo y conexión de red diferente

Para desarrolladores y consumidores de API:

• Valide que Content-Type coincida con el formato del cuerpo de la solicitud
• Confirme que todos los campos y encabezados requeridos estén presentes y correctamente tipados
• Compruebe que los valores de cadena, fechas y tipos numéricos se ajusten al contrato de la API
• Use curl con salida detallada para inspeccionar el intercambio HTTP sin procesar:

curl -v -X POST https://api.example.com/endpoint 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d '{"key": "value"}'

Para administradores de servidores:

• Extraiga y filtre los registros de errores del servidor para entradas 400
• Valide la sintaxis de configuración del servidor web (nginx -t / apachectl -t)
• Verifique client_max_body_size (Nginx) y LimitRequestBody (Apache)
• Revise large_client_header_buffers en Nginx si las solicitudes con muchas cookies están fallando
• Audite las reglas WAF y verifique el registro de auditoría de ModSecurity
• Verifique la validez y cobertura del certificado SSL/TLS
• Confirme que las reglas de reescritura de .htaccess sean sintácticamente correctas

—

Preguntas frecuentes

¿Cuál es la diferencia entre un error 400 y un error 404?

Un error 400 significa que el servidor no pudo entender la solicitud porque estaba mal formada — el fallo está en cómo se construyó la solicitud. Un error 404 significa que la solicitud era válida y fue entendida, pero el recurso solicitado simplemente no existe en el servidor. Requieren soluciones completamente diferentes.

¿Puede un error 400 Bad Request ser causado por el servidor y no por el cliente?

Sí, indirectamente. Una mala configuración del servidor — como una regla WAF demasiado restrictiva, una configuración incorrecta de large_client_header_buffers en Nginx, o una directiva .htaccess rota — puede hacer que el servidor rechace solicitudes que son técnicamente válidas. En estos casos, la especificación HTTP sigue cumpliéndose (el servidor rechaza lo que percibe como una solicitud incorrecta), pero el fallo real está en la configuración del servidor, no en la solicitud del cliente.

¿Por qué limpiar las cookies soluciona un error 400?

Las cookies se envían en el encabezado de solicitud Cookie en cada solicitud al dominio relevante. Si una cookie almacenada en el navegador está mal formada, ha expirado de una manera que el servidor no acepta, o ha crecido demasiado (superando los límites de large_client_header_buffers en Nginx), el servidor rechaza toda la solicitud con un 400 antes de procesarla. Eliminar la cookie corrupta elimina los datos incorrectos del encabezado.

¿Cómo soluciono un error 400 al cargar archivos en mi sitio web?

La carga está superando el límite de tamaño del cuerpo del servidor web o el límite de tamaño de carga de PHP. En Nginx, aumente client_max_body_size en nginx.conf. En Apache, ajuste LimitRequestBody en .htaccess o httpd.conf. Para aplicaciones PHP, actualice upload_max_filesize y post_max_size en php.ini, asegurándose de que post_max_size sea mayor que upload_max_filesize. Reinicie los servicios relevantes después de realizar los cambios.

¿Cómo puedo saber si un error 400 proviene de un CDN o WAF en lugar de mi servidor de origen?

Compruebe los encabezados de respuesta. Cloudflare añade encabezados cf-ray y server: cloudflare. AWS CloudFront añade x-amz-cf-id. Si estos encabezados están presentes en la respuesta 400, el rechazo ocurrió en el edge, no en su origen. Revise los registros WAF del CDN o el panel de eventos del firewall para identificar qué regla desencadenó el bloqueo, luego cree una excepción específica para el patrón de tráfico legítimo.