Consulta cualquier código de estado HTTP: qué significa, cuándo lo envían los servidores y qué especificación lo define. Busca por número o palabra clave, filtra por clase y enlaza directamente a un código.
El servidor recibió los encabezados de la solicitud y el cliente puede enviar el cuerpo. Se ve cuando un cliente envía «Expect: 100-continue» antes de subir un cuerpo grande.
Se envía antes de la respuesta final para que el navegador pueda empezar a precargar los recursos indicados en los encabezados Link. CDN y servidores lo usan para acelerar la carga de las páginas.
La solicitud se completó correctamente y la respuesta contiene el resultado. Es la respuesta habitual al cargar una página o realizar una llamada API correctamente.
La solicitud se completó correctamente y creó un recurso nuevo, normalmente identificado por el encabezado Location. Es habitual tras un POST que crea un registro.
La solicitud se aceptó para su procesamiento, pero aún no ha terminado. Lo usan las API que ponen tareas en cola, como exportaciones o procesos por lotes.
La solicitud se completó correctamente y no hay contenido que devolver. Es habitual en solicitudes DELETE y al guardar datos cuando el cliente no necesita un cuerpo de respuesta.
El servidor devuelve solo el rango de bytes solicitado por el cliente. Se ve al reproducir videos en streaming, reanudar descargas o cuando un cliente envía un encabezado Range.
El recurso se trasladó permanentemente a la URL indicada en el encabezado Location. Los navegadores y motores de búsqueda actualizan sus enlaces; algunos clientes cambian POST por GET al seguir la redirección.
El recurso está temporalmente en otra URL, indicada en el encabezado Location. Es habitual después de iniciar sesión y en redirecciones de corta duración; los navegadores suelen seguirla con GET.
El cliente debe obtener el resultado desde otra URL con GET. Se usa después de un POST de formulario para redirigir a una página de confirmación (el patrón Post/Redirect/Get).
La copia en caché sigue siendo válida, así que el servidor no envía un cuerpo. Se ve cuando un navegador vuelve a validar un archivo en caché con If-None-Match o If-Modified-Since.
El recurso está temporalmente en otra URL y el cliente debe repetir la solicitud con el mismo método y cuerpo. También lo usan los navegadores para redirecciones internas de HSTS a HTTPS.
El recurso se ha trasladado de forma permanente y el cliente debe usar el mismo método y cuerpo en la nueva URL. Es la contraparte permanente del código 307 y permite redirigir solicitudes POST de forma segura.
El servidor no puede procesar la solicitud porque está mal formada; por ejemplo, contiene un JSON no válido, un parámetro de consulta incorrecto o una cookie dañada.
La solicitud no incluye credenciales de autenticación válidas. Pese a su nombre, significa «no autenticado»; el servidor envía un encabezado WWW-Authenticate que indica cómo iniciar sesión.
El servidor entiende la solicitud, pero la rechaza; volver a iniciar sesión no servirá de ayuda. Puede aparecer si faltan permisos, la lista de directorios está desactivada o un firewall bloquea al cliente.
El servidor no encuentra el recurso solicitado. Suele deberse a un enlace mal escrito o desactualizado, una página eliminada o una ruta de API incorrecta.
El recurso existe, pero no admite el método HTTP utilizado; por ejemplo, una solicitud POST a una URL de solo lectura. La respuesta indica los métodos permitidos en el encabezado Allow.
Es parecido al código 401, pero el cliente debe autenticarse primero con un proxy. Puede aparecer en redes corporativas que usan un proxy con autenticación.
El servidor agotó el tiempo de espera mientras esperaba que el cliente terminara de enviar la solicitud. Puede ocurrir con conexiones lentas o interrumpidas.
La solicitud entra en conflicto con el estado actual del recurso; por ejemplo, debido a un conflicto al editar o a que se intenta crear algo que ya existe.
El recurso se ha eliminado de forma permanente y no volverá a estar disponible. A diferencia del código 404, indica a los motores de búsqueda que eliminen la URL más rápido.
No se cumplió una condición de los encabezados de la solicitud, como If-Match. Se usa para evitar sobrescribir un recurso que ha cambiado desde la última vez que lo consultó el cliente.
El cuerpo de la solicitud supera el tamaño que acepta el servidor. Puede ocurrir al subir un archivo que supera un límite, como client_max_body_size de nginx.
La URL es demasiado larga para que el servidor la procese. Suele deberse a que un formulario envía demasiados datos con GET o a un bucle de redirección que sigue añadiendo parámetros.
Una broma del Día de los Inocentes de 1998, basada en el protocolo Hyper Text Coffee Pot Control: una tetera que se niega a preparar café. HTTP reserva el código como no utilizado, pero algunos servidores lo devuelven como guiño o para rechazar bots no deseados.
La solicitud llegó a un servidor que no puede generar una respuesta para este host; por ejemplo, cuando se reutiliza una conexión HTTP/2 para otro dominio.
La solicitud está bien formada, pero su contenido no es válido; por ejemplo, un formulario que no supera las reglas de validación. Las API lo usan ampliamente para indicar errores de validación.
El cliente ha enviado demasiadas solicitudes en un periodo determinado. Las API lo usan para limitar la frecuencia de solicitudes y suelen incluir un encabezado Retry-After que indica cuándo volver a intentarlo.
Los encabezados de la solicitud son demasiado grandes, a menudo porque hay demasiadas cookies o son demasiado pesadas. Borrar las cookies del sitio suele resolver el problema.
No es un código estándar. nginx lo usa internamente para cerrar la conexión sin enviar respuesta, a menudo para descartar tráfico no deseado; los clientes nunca lo reciben realmente.
El recurso no está disponible por motivos legales, como una orden judicial o censura gubernamental. El número hace referencia a la novela Fahrenheit 451.
No es un código estándar. Es una variante propia de nginx del código 431, que se registra cuando los encabezados de la solicitud superan los límites de sus búferes.
No es un código estándar. nginx lo registra cuando el cliente cierra la conexión antes de que responda el servidor; por ejemplo, si un usuario cancela la carga de una página lenta o se agota el tiempo de espera del cliente.
El servidor encontró un error inesperado y no pudo completar la solicitud. Es un error genérico que puede deberse a un fallo de programación, una caída o una configuración incorrecta; los detalles están en los registros del servidor.
Una pasarela o un proxy recibió una respuesta no válida del servidor ascendente. Es habitual cuando la aplicación detrás de nginx o de un balanceador de carga se ha caído o se está reiniciando.
El servidor no puede atender la solicitud temporalmente porque está sobrecargado o en mantenimiento. Un encabezado Retry-After puede indicar cuándo volver a intentarlo.
Una puerta de enlace o un proxy no recibió a tiempo una respuesta del servidor ascendente. Se produce cuando una solicitud al backend tarda demasiado, por ejemplo, por una consulta larga a la base de datos.
No es un código estándar. Algunos servicios de alojamiento compartido (módulos de Apache, cPanel) lo usan cuando un sitio supera el límite de ancho de banda.
El cliente debe autenticarse para obtener acceso a la red. Lo envían los portales cautivos de redes Wi-Fi de hoteles, aeropuertos o cafeterías antes de iniciar sesión.
No es un código estándar. Cloudflare lo devuelve cuando el servidor de origen rechaza la conexión, normalmente porque el servidor web está caído o bloquea las direcciones IP de Cloudflare.
No es un código estándar. Cloudflare lo devuelve cuando no puede conectarse con el servidor de origen, por ejemplo, debido a un problema de DNS o de enrutamiento.
No es un código estándar. Cloudflare lo devuelve cuando se conecta con el servidor de origen, pero no recibe una respuesta HTTP dentro del tiempo de espera (100 segundos de forma predeterminada).
No es un código estándar. Cloudflare lo devuelve cuando el certificado SSL del servidor de origen no es válido y está activado el modo SSL Full (strict).
Definido en Cloudflare
Cómo usarla
Escribe un número de código (como 404 o solo 5 para todos los errores del servidor) o una palabra clave, como «redirección» o «tiempo de espera agotado».
Filtra la lista por clase: informativo, éxito, redirección, error del cliente o error del servidor.
Usa «Copiar enlace» en cualquier código para compartir un enlace directo, por ejemplo, en un informe de errores.
Cómo funciona
Toda respuesta HTTP empieza con un código de estado de tres dígitos. El primer dígito determina la clase: respuestas informativas 1xx, respuestas satisfactorias 2xx, redirecciones 3xx, errores causados por la solicitud 4xx y errores del servidor 5xx. Los clientes que no reconocen un código concreto lo tratan como el código x00 de su clase; por tanto, un código 4xx desconocido se gestiona como 400.
Los códigos principales se definen en RFC 9110 (HTTP Semantics, 2022), que sustituyó a la versión anterior, RFC 7231. Otros proceden de extensiones: WebDAV (RFC 4918), RFC 6585 para 428, 429, 431 y 511, RFC 7725 para 451 y RFC 8470 para 425. RFC 9110 también cambió el nombre de dos códigos: 413 ahora es “Content Too Large” y 422, “Unprocessable Content”. Es posible que todavía los veas con sus nombres anteriores: “Payload Too Large” y “Unprocessable Entity”.
Algunos códigos que aparecen en los registros no son estándares. nginx usa internamente 444 y 494–499 (499 indica que el cliente dejó de esperar), y Cloudflare devuelve 520–526 cuando no puede obtener una respuesta adecuada del servidor de origen. En la lista, estos aparecen marcados como «No estándar». Los textos descriptivos (como “Not Found”) se muestran en inglés, tal como aparecen en las especificaciones; HTTP/2 y HTTP/3 solo envían el número.
Ejemplos
301 o 308 al cambiar de sitio
Ambos son permanentes. Usa 301 para los cambios habituales de página; usa 308 cuando los clientes deban repetir las solicitudes POST o PUT en la nueva URL, ya que algunos clientes cambian POST por GET después de un 301.
401 frente a 403
Una API devuelve 401 cuando no se envía ningún token o se envía uno caducado, por lo que el cliente debe iniciar sesión. Devuelve 403 cuando el token es válido, pero el usuario no tiene permiso; en ese caso, volver a iniciar sesión no servirá de nada.
Diagnosticar un 502 detrás de nginx
Un error 502 Bad Gateway de nginx significa que la aplicación que hay detrás no respondió correctamente. Comprueba si el proceso de la aplicación está en ejecución y qué aparece en sus registros; un 504 significa que tardó demasiado en responder.
Preguntas frecuentes
¿Cuál es la diferencia entre 404 y 410?
404 significa que el servidor no encuentra el recurso y no indica nada sobre el futuro. 410 indica que el recurso se eliminó deliberadamente y no volverá, lo que ayuda a los motores de búsqueda a retirar la URL antes.
¿Un error de validación debe devolver 400 o 422?
Se usan ambos. 400 corresponde a solicitudes que el servidor no puede analizar, como un JSON mal formado. 422 corresponde a solicitudes que se analizan correctamente, pero contienen valores no válidos, como un campo de correo electrónico sin @.
¿418 I'm a teapot es un código de estado real?
Proviene de una RFC del Día de los Inocentes de 1998. La RFC 9110 reserva el código 418 para que no se asigne a otra cosa, y algunos servidores lo devuelven en broma, pero no tiene un significado estándar.
¿De dónde viene el código 499?
499 es específico de nginx. Aparece en los registros de nginx cuando el cliente cierra la conexión antes de que el servidor envíe una respuesta. El cliente nunca recibe un 499; normalmente indica respuestas lentas o tiempos de espera agotados en el cliente.
¿Los motores de búsqueda tratan un 302 igual que un 301?
Un 302 indica un cambio temporal, por lo que, al principio, los motores de búsqueda suelen mantener indexada la URL original. Si un 302 se mantiene durante mucho tiempo, Google puede tratarlo como una redirección permanente. Usa 301 o 308 para cambios permanentes.
Privacidad
La lista forma parte de la página. Las búsquedas y los filtros se aplican en tu navegador; los términos de búsqueda no se envían a ningún sitio ni se incluyen en las analíticas.