---
title: "Error 400 Bad Request: qué significa y cómo resolverlo"
description: "Error 400 bad request: el servidor recibió una solicitud que no acepta (enlace roto, cookies muy grandes, datos no válidos). Qué significa y cómo resolverlo."
url: https://proxynet.io/es/blog/400-bad-request-error
date: 2026-11-12
author: "Acar Diveroli"
category: "Tutoriales, Web scraping"
lang: es
---

# Error 400 Bad Request: qué significa y cómo resolverlo

Abres un enlace de un correo, o un sitio que usas a diario, y te sale una pantalla blanca con «400 Bad Request» en negrita. A veces una segunda línea da más detalles, como «Request Header Or Cookie Too Large», con «nginx» al pie. Chrome puede mostrar en su lugar una página gris propia: «Esta página no funciona» y HTTP ERROR 400. Los desarrolladores reciben el mismo número de una API, normalmente con un breve mensaje JSON.

Todo esto significa que el servidor recibió una solicitud que no quiso aceptar. A continuación verás qué significa el código, quién envió la página, las causas y soluciones si eres visitante, en qué se diferencia el 400 del 401, 403, 404 y 413, y qué deben revisar los desarrolladores, con un ejemplo reproducido.

> **Nota: Respuesta breve**
>
> Un error 400 Bad Request significa que el servidor del sitio recibió tu solicitud pero no la procesó, porque algo en la propia solicitud estaba mal: una dirección mal escrita o rota, demasiadas cookies o cookies demasiado grandes para ese sitio, una cookie dañada, una extensión que modificó la solicitud o, en el código, datos no válidos. Recargar envía la misma solicitud y recibe la misma respuesta. Revisa la dirección, borra solo las cookies de ese sitio y prueba una ventana de incógnito; si el error sigue, contacta con el sitio. Si eres desarrollador, lee el cuerpo de la respuesta, que suele indicar el problema.

## ¿Qué significa 400 Bad Request?

400 Bad Request significa que el servidor se niega a procesar una solicitud porque considera que la propia solicitud es defectuosa. El estándar HTTP, [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.1), da tres ejemplos: una sintaxis de solicitud mal formada, un encuadre del mensaje no válido (indicar mal dónde empieza y dónde termina el mensaje) y un enrutamiento engañoso de la solicitud. Dicho de forma sencilla, la dirección, las cabeceras o los datos incumplieron las reglas con las que trabaja el servidor.

Los códigos del grupo 400 describen problemas del lado de la solicitud, pero «error del cliente» no siempre significa que hayas hecho algo mal: una cookie que puso el propio sitio puede hacer que las solicitudes de tu navegador sean demasiado grandes. De la definición se deduce una regla. Como indica [la referencia de MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400), una solicitud repetida sin cambios falla con el mismo error, así que recargar no ayuda; cambiar la solicitud, sí.

## ¿Quién envió la página 400 que estás viendo?

La segunda línea de la página y el nombre que aparece al pie indican qué programa rechazó la solicitud y, a menudo, por qué.

| Lo que ves | Quién la envía | Causa habitual |
|---|---|---|
| «400 Bad Request», «Request Header Or Cookie Too Large», «nginx» | nginx | Demasiadas cookies o cookies demasiado grandes para el sitio |
| «400 Bad Request», «The plain HTTP request was sent to HTTPS port» | nginx | Una solicitud `http://` a un puerto que espera HTTPS |
| «Bad Request», «Your browser sent a request that this server could not understand.» | Apache | Una dirección o una cabecera mal formada |
| «HTTP 400 - Bad Request (Request header too long)» | IIS, el servidor web de Microsoft | Una cabecera por encima del límite, a menudo un token de inicio de sesión |
| «Esta página no funciona», «Si el problema persiste, ponte en contacto con el propietario del sitio web.», «HTTP ERROR 400» | Chrome | El sitio envió un 400 sin página propia |
| Un breve mensaje JSON, como `{"error":"invalid JSON"}` | Una API | Datos no válidos o un parámetro que falta |

Comprobamos la fila de Chrome con un pequeño servidor de prueba en nuestro propio equipo que responde 400 con el cuerpo vacío, abierto en Chromium 145: con la interfaz en español aparecen exactamente esas líneas y un botón **Volver a cargar**. Chrome escribe ese texto por su cuenta, así que no dice nada sobre la causa.

## ¿Cómo se produce un 400, paso a paso?

Una solicitud tiene tres partes, y el servidor las revisa en orden:

1. **La línea de solicitud.** El método y la dirección, como `GET /search?q=shoes`. Los caracteres especiales viajan como un `%` seguido de dos dígitos hexadecimales (codificación porcentual); un `%` sin esos dos dígitos no se puede decodificar.
2. **Las cabeceras.** Líneas como `Host` y `User-Agent`, además de `Cookie`, que lleva todas las cookies que el navegador guarda para ese sitio. Los servidores limitan cada línea de cabecera: 8 KB por defecto en nginx, 8.190 bytes en Apache.
3. **El cuerpo.** Datos de un formulario o de una API, a menudo JSON, cuyo formato y campos obligatorios comprueba la aplicación.
4. **El veredicto.** La primera comprobación que falla termina la solicitud con un 400, normalmente con un motivo breve.
5. **La repetición.** Nada ha cambiado, así que el siguiente intento envía la misma dirección, las mismas cookies y los mismos datos, y recibe el mismo 400.

## ¿En qué se diferencia el 400 del 401, 403, 404 y 413?

| Código | Nombre | Qué significa | Qué ayuda |
|---|---|---|---|
| `400` | Bad Request | La solicitud es defectuosa | Corregir la dirección, las cookies o los datos |
| `401` | Unauthorized | Faltan credenciales válidas | Iniciar sesión o enviar un token válido |
| `403` | Forbidden | Entendida, pero rechazada | Otra cuenta u otro permiso |
| `404` | Not Found | No hay nada en esta dirección | Revisar la dirección |
| `413` | Content Too Large | Lo que subes es demasiado grande | Enviar un archivo más pequeño |
| `431` | Request Header Fields Too Large | Las cabeceras son demasiado grandes | Borrar las cookies del sitio |

El 400 es el código general; los servidores envían uno más específico cuando encaja. Un 401 significa que el servidor leyó la solicitud pero quiere saber quién la envió, y de eso trata [Error 401 Unauthorized: qué significa y cómo resolverlo](/es/blog/401-unauthorized-error). Una subida demasiado grande recibe normalmente un 413 (nginx acepta por defecto 1 MB de cuerpo de solicitud), aunque algunas aplicaciones responden 400.

## ¿Por qué me sale el error 400 Bad Request?

Desde el lado del visitante, estas son las causas habituales:

- **Una dirección mal escrita o rota.** Los enlaces copiados de correos y apps de chat se cortan o arrastran caracteres de más; un `%` sin dos dígitos hexadecimales detrás, como en `50%off`, no se puede decodificar.
- **Demasiadas cookies o cookies demasiado grandes para ese sitio**, la causa detrás de «Request Header Or Cookie Too Large».
- **Una cookie dañada o desactualizada.** Después de que un sitio cambie su sistema de inicio de sesión, una cookie antigua puede llevar un valor que el código nuevo no sabe leer.
- **Una extensión que reescribe las solicitudes**, como una que edita cabeceras o cookies.
- **Algo intermedio**, rara vez: un software de seguridad que inspecciona el tráfico web o un proxy configurado con el esquema o el puerto equivocados.

## ¿Qué significa «Request Header Or Cookie Too Large»?

Significa que las cookies que tu navegador guarda para ese sitio, junto con las demás cabeceras, ya no caben en el límite de tamaño del servidor, así que nginx rechaza la solicitud con un 400. Tu navegador envía todas las cookies de un sitio en una sola cabecera `Cookie` con cada solicitud, y nginx rechaza cualquier línea de cabecera mayor que un búfer, 8 KB por defecto, como explica su documentación de [`large_client_header_buffers`](https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers).

Los límites de los dos lados no coinciden. El estándar de cookies, RFC 6265, pide a los navegadores que guarden al menos 4.096 bytes por cookie y al menos 50 cookies por dominio, mucho más que 8 KB en total. Un sitio con muchas cookies de analítica y de sesión puede cruzar la línea tras semanas de uso normal, y entonces el error afecta solo a ese sitio, porque solo sus cookies viajan con sus solicitudes.

IIS lo expresa como «HTTP 400 - Bad Request (Request header too long)», y algunos servidores envían el código más específico 431. La solución por tu parte es la misma: borra las cookies de ese sitio.

## ¿Cómo resolver un error 400 si eres visitante?

Sigue estos pasos en orden; los tres primeros llevan un minuto.

1. **Revisa la dirección.** Vuelve a escribirla, o abre la página principal del sitio y navega desde ahí. Si es un enlace largo de un correo, pruébalo sin la parte que va después de `?`.
2. **Borra solo las cookies de ese sitio.** Así cierras sesión solo en ese sitio y no tocas los demás.
   - Chrome: **Más > Configuración > Privacidad y seguridad > Cookies de terceros > Ver todos los datos y permisos de sitios**, busca el sitio, selecciona **Eliminar** y confirma ([los pasos de Google](https://support.google.com/chrome/answer/95647?hl=es)).
   - Edge: **Configuración y más > Configuración > Privacidad, búsqueda y servicios > Cookies > Ver todas las cookies y datos del sitio**, busca el sitio, abre la flecha hacia abajo que hay junto a él y selecciona el icono de eliminar.
   - Firefox: en el sitio, haz clic en el icono del escudo a la izquierda de la barra de direcciones y elige **Limpiar cookies y datos del sitio…**
   - Safari en un Mac: **Safari > Ajustes > Privacidad > Gestionar datos de sitios web**, selecciona el sitio y haz clic en **Eliminar**.
3. **Prueba una ventana de incógnito.** En Chrome, **Más > Nueva ventana de Incógnito**, o Ctrl + Mayús + N. Se abre sin las cookies del sitio, y las extensiones siguen desactivadas salvo que las hayas permitido ahí. Si la página se abre, la causa era una cookie o una extensión.
4. **Desactiva las extensiones una a una** en **Más > Extensiones > Gestionar extensiones** de Chrome, empezando por las que bloquean contenido o editan solicitudes.
5. **Reduce el tamaño de lo que subes** si el error aparece al enviar un archivo.
6. **Prueba sin la VPN o el proxy, o con datos móviles.** Si la página carga, algo de la primera red está modificando tus solicitudes.
7. **Contacta con el sitio** e indica la dirección, la hora y lo que pulsaste. Si el error vuelve días después de borrar las cookies, el sitio pone más cookies de las que acepta su propio servidor.

Vaciar la caché de DNS o reiniciar el router rara vez sirve: cuando un servidor responde 400, tu equipo ya lo ha encontrado.

## ¿Qué deben revisar los desarrolladores cuando su código recibe un 400?

En el código, un 400 significa que el servidor rechazó la solicitud que construyó tu programa, y el cuerpo de la respuesta suele nombrar el campo o la regla. Registra el cuerpo antes de cambiar nada. Las causas habituales:

- **JSON no válido:** una coma final, comillas simples, una cadena montada a mano. Usa el codificador de tu lenguaje, como `JSON.stringify` o `json.dumps`.
- **Un `Content-Type` que no coincide con el cuerpo**, como JSON enviado con un tipo de formulario.
- **Parámetros que faltan o son incorrectos:** un campo obligatorio omitido, un número enviado como texto, una fecha con el formato equivocado.
- **Cadenas de consulta (query strings) montadas a mano.** Los espacios, `&` y `%` dentro de los valores deben codificarse; `URLSearchParams` o `urllib.parse.urlencode` lo hacen por ti.
- **Cabeceras que el servidor no acepta.** Una cookie grande o un token largo pueden superar el límite por cabecera: 8 KB en nginx, `LimitRequestFieldSize` en Apache, `MaxFieldLength` en IIS. HTTP/1.1 exige además un 400 cuando falta la cabecera `Host` o está duplicada.
- **Costumbres de HTTP/1.1 en HTTP/2.** HTTP/2 exige nombres de cabecera en minúsculas y prohíbe cabeceras de conexión como `Connection` y `Keep-Alive`; el servidor reinicia esa solicitud o responde 400. Ocurre cuando el código o un proxy copia cabeceras de HTTP/1.1 en HTTP/2.

### Un 400 por JSON mal formado, reproducido

Ejecutamos en nuestro propio equipo un pequeño servidor Node.js que responde 400 cuando el cuerpo de un pedido no es JSON válido, y enviamos una solicitud con `curl -i` (`-i` muestra la línea de estado y las cabeceras) y una coma final en el cuerpo:

```bash
curl -i http://127.0.0.1:18400/api/orders -H "Content-Type: application/json" -d '{"product": "sku-123", "qty": 2,}'
```

La salida (curl 8.22 en Windows 11, Node.js 24):

```text
HTTP/1.1 400 Bad Request
Content-Type: application/json
Date: Thu, 12 Nov 2026 01:21:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

{"error":"invalid JSON","detail":"Expected double-quoted property name in JSON at position 32 (line 1 column 33)"}
```

`position 32` en el mensaje es la `}` que va justo después de la coma: JSON no admite una coma antes de una llave de cierre. Quita la coma y el cuerpo es válido. Una API real redacta su mensaje de otra forma, pero el patrón se mantiene: la línea de estado dice que la solicitud está mal, y el cuerpo dice dónde.

### ¿Qué cambia detrás de un proxy?

Nada en la solicitud, si el proxy está bien configurado. Para una dirección `https://`, el cliente pide al proxy que abra un túnel con una solicitud `CONNECT`, y el proxy pasa los bytes en ambos sentidos sin leerlos, así que un 400 que vuelve es el veredicto del sitio. Un error de configuración típico es un esquema que no corresponde al puerto: una solicitud `http://` sin cifrar a un puerto que espera HTTPS recibe de nginx «The plain HTTP request was sent to HTTPS port». Con los [Proxies HTTPS](https://proxynet.io/es/https-proxy), copia el host, el puerto y el esquema exactamente como los muestra el Generador de endpoints.

### ¿Cómo debe tratar un scraper un 400?

Como un fallo en su propia solicitud, no como un bloqueo. Reintentar sin cambios devuelve el mismo 400, y los [Proxies residenciales](https://proxynet.io/es/residential-proxy) cambian la dirección que ve el sitio, no la solicitud que envía tu código. Detente, registra la solicitud y el cuerpo, y corrige lo que indique.

Otros códigos sí merecen un reintento, como un 503 tras una pausa; [Códigos de estado HTTP en web scraping](/es/blog/http-status-codes-web-scraping) separa esos de los que significan parar.

## Dónde puedes encontrarte un 400

- Un sitio que visitas a diario y que de pronto muestra «Request Header Or Cookie Too Large».
- Enlaces largos de correos, apps de chat y boletines que se cortan por el camino.
- Formularios de subida con un límite de tamaño que la página no menciona.
- Botones para iniciar sesión con una cuenta de Google en apps mal configuradas, con un código «Error 400».
- Llamadas a API desde scripts, Postman y herramientas no-code después de que cambie el nombre o el tipo de un campo.

## Errores frecuentes

- **Borrar todos los datos de navegación.** Cierra tu sesión en todos los sitios; solo importan las cookies del sitio que falla.
- **Recargar una y otra vez.** La solicitud no cambia, así que la respuesta tampoco.
- **Culpar a la conexión.** Un 400 significa que la solicitud llegó.
- **Desarrolladores: reintentar un 400 en bucle** o rotar direcciones IP por su culpa, y registrar el código de estado sin el cuerpo.
- **Propietarios de sitios: subir los límites de cabecera en lugar de recortar cookies.** El propio estándar de cookies aconseja a los servidores mantener las cookies pocas y pequeñas.

## Guía de decisión

| Tu situación | Qué hacer |
|---|---|
| «Request Header Or Cookie Too Large» en un sitio | Borra las cookies de ese sitio |
| Un enlace de un correo da un 400 | Vuelve a escribirlo o empieza desde la página principal |
| La página se abre en una ventana de incógnito | Quita la cookie o la extensión responsable |
| El error aparece al subir un archivo | Envía un archivo más pequeño |
| Solo en una red, o solo con la VPN activada | Revisa la VPN, el proxy o el software de seguridad |
| Tu llamada a la API devuelve un 400 | Lee el cuerpo y corrige el JSON, la cabecera o el parámetro |

## Preguntas frecuentes

### ¿Un error 400 es culpa mía o del sitio web?

Puede ser de cualquiera de los dos; el código solo dice que la solicitud era defectuosa. Una errata o una extensión están de tu lado, una cookie demasiado grande la puso el propio sitio, y un 400 de una API es un fallo en el código que la llama.

### ¿Por qué me sale 400 Bad Request solo en un sitio?

Porque la causa suele estar en las cookies o en los límites de ese sitio: cada sitio recibe solo sus propias cookies y fija sus propios límites de tamaño. Borra las cookies de ese sitio; si una ventana de incógnito muestra el mismo error, el sitio tiene que arreglarlo.

### ¿Una VPN o un proxy pueden causar un error 400?

Rara vez. Una VPN, y un proxy que tuneliza HTTPS, transmiten tu solicitud sin cambios, así que el 400 viene del sitio. Si el error solo aparece con el proxy activado, revisa su esquema y su puerto; un software de seguridad que inspecciona el tráfico también puede alterar las cabeceras.

### ¿Cómo soluciono el 400 Bad Request en un iPhone o un teléfono Android?

En Android, abre el sitio en Chrome, toca **Información de la página** a la izquierda de la barra de direcciones, luego **Cookies y datos de sitios**, y toca **Eliminar** junto a los datos almacenados. En un iPhone, prueba primero una pestaña privada; si ahí funciona, **Ajustes > Apps > Safari > Avanzado > Datos de Sitios Web > Eliminar Todos los Datos** lo soluciona, pero cierra tu sesión en todos los sitios.

### ¿Por qué me sale 400 Bad Request en Postman?

Normalmente por el cuerpo o su tipo. Con el cuerpo en **raw** y el tipo **JSON**, Postman añade la cabecera `Content-Type` correspondiente, pero una que hayas escrito tú la sustituye. Revisa el JSON y los parámetros obligatorios, y después lee el cuerpo de la respuesta.

### ¿Qué significa «Error 400: redirect_uri_mismatch»?

Aparece cuando una app te envía a iniciar sesión con Google: la dirección de retorno (redirect URI) que la app le dio a Google no coincide con ninguna de las direcciones registradas para esa app. Solo el desarrollador de la app puede arreglarlo, en la configuración de Google Cloud de la app.

## En resumen

Un 400 Bad Request significa que el servidor recibió tu solicitud y no la aceptó tal como llegó. Si eres visitante, revisa la dirección, borra las cookies de ese sitio, prueba una ventana de incógnito y desactiva las extensiones. Si eres desarrollador, lee el cuerpo de la respuesta, corrige el JSON, las cabeceras o los parámetros, y nunca reintentes un 400 sin cambios. Si necesitas proxies para seguimiento o recopilación de datos, compara los tipos en [nuestra página de proxies](/es/proxy).