Guide
La referencia completa de códigos HTTP reúne 72 códigos de estado: todos los estándar definidos en el RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), los extendidos de los RFC 6585, 7725, 8297 y 8470 y de la serie WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) y también los no estándar que no aparecen en ningún RFC pero se ven a diario al depurar sistemas en producción: el 444 y el 499 de nginx y el 520–526 de Cloudflare.
Actualizado el 2026-09-094 sources10 min read
La referencia completa de códigos HTTP reúne 72 códigos de estado: todos los estándar definidos en el RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), los extendidos de los RFC 6585, 7725, 8297 y 8470 y de la serie WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) y también los no estándar que no aparecen en ningún RFC pero se ven a diario al depurar sistemas en producción: el 444 y el 499 de nginx y el 520–526 de Cloudflare.
A diferencia de las tablas que solo dan el «significado», aquí cada código se explica en cuatro bloques: cuál es su semántica; en qué situaciones lo verás; qué debería hacer el frontend / cliente al recibirlo (¿reintentar? ¿ir al inicio de sesión? ¿leer qué cabecera?); y cuándo debe devolverlo el backend y con qué cabeceras. Los códigos más frecuentes añaden un bloque de «errores de uso habituales», porque la mayoría de los problemas con códigos en producción no vienen de no conocerlos, sino de usarlos mal: devolver 200 cuando falla el negocio, 403 cuando falta iniciar sesión o 503 cuando se está limitando el tráfico.
Arriba de la página hay además siete comparativas de códigos que se confunden entre sí: 401 vs 403, 301/302/307/308, 400 vs 422, 404 vs 410, 502/503/504, 200/201/202/204 y 429 vs 503. Son las combinaciones que más salen en entrevistas, revisiones de código y diagnósticos.
502) y la tarjeta que coincide exactamente aparece arriba del todo.Contenido de la tarjeta que aparece al buscar «429» (extracto):
Y la respuesta del servidor correspondiente sería así:
429 Too Many Requests demasiadas peticiones RFC 6585
Semántica se han enviado demasiadas peticiones en un periodo determinado (límite de tasa).
Cuándo límites de frecuencia de una API, demasiados intentos de inicio de sesión, rastreadores frenados, API de IA que supera la cuota por minuto.
Cliente lee la cabecera Retry-After (segundos o fecha) y reintenta con retroceso exponencial; avisa al usuario de que lo intente más tarde; no reintentes de inmediato.
Servidor devuélvelo con las cabeceras Retry-After y RateLimit-*; cuenta por usuario / IP / API key.
Mal uso devolver 403 o 503 al limitar el tráfico: el cliente no distingue si es un problema de permisos o si debe esperar.HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"máximo 60 peticiones por minuto; vuelve a intentarlo en 30 segundos"}El primer dígito del código determina la clase, y es deliberado: aunque el cliente no conozca un código concreto (por ejemplo el nuevo 425), puede tratarlo bien por su clase —4xx siempre significa «no reintentes tal cual, el problema está en la petición», 5xx significa «puedes reintentar más tarde» y 3xx significa «mira la cabecera Location»—. El RFC 9110 exige que el cliente entienda la semántica de la clase y permite que no entienda el código concreto. Por eso los códigos personalizados deben caer en el rango de centenas correcto.
Un error histórico de nomenclatura. En los primeros tiempos de HTTP no se distinguía entre authentication (quién eres) y authorization (qué puedes hacer); el 401 se llamó Unauthorized, pero la cabecera WWW-Authenticate que lo acompaña y su semántica de «puede funcionar si vuelves a enviar credenciales» hablan de autenticación. El RFC 9110, en el §15.5.2, ya lo redacta como "lacks valid authentication credentials". Recuerda una frase: 401 = inicia sesión, 403 = aunque inicies sesión, no puedes. Con eso, el frontend decide si redirige al login o muestra «sin permiso»; si se usa al revés, aparecen los «ya había iniciado sesión y me devuelve al login una y otra vez».
Los cuatro códigos de redirección habituales forman una matriz de 2×2. El 301 y el 308 son permanentes (el navegador y los buscadores recuerdan la nueva dirección); el 302 y el 307 son temporales. Históricamente, el navegador convertía el POST en GET al tratar 301/302; el RFC 9110 reconoce esa realidad y ofrece con 307/308 versiones estrictas que «deben conservar el método y el cuerpo». Para redirigir una web a https, el 301 está bien; para migrar un endpoint de API, las peticiones POST necesitan 307 o 308, o el cuerpo se perderá.
Mucha gente cree que el 304 «ahorra una petición». En realidad, el navegador sí envió al servidor una petición condicional con If-None-Match / If-Modified-Since, el servidor la comparó y respondió 304 sin cuerpo: lo que se ahorra es la transferencia, no el viaje de ida y vuelta. Ahorrar peticiones de verdad depende de Cache-Control: max-age (dentro de su validez el navegador no pregunta al servidor). Los dos trabajan juntos: dentro de max-age se usa directamente y, al caducar, una petición condicional renueva con un 304. En DevTools, "200 (from disk cache)" es lo primero y "304" es lo segundo.
Son la combinación de 5xx más habitual en producción y distinguirlos reduce directamente el ámbito del diagnóstico. El proxy inverso (Nginx, una pasarela, una CDN) no consigue conectar con el origen o el origen devuelve algo no válido: 502, mira si el proceso de la aplicación se ha caído; el origen indica claramente que está ocupado o en mantenimiento: 503, normalmente devuelto a propósito, revisa el health check y el cortocircuito; el origen tarda en responder: 504, revisa las consultas lentas y los tiempos de espera. Cloudflare divide estos tres casos en 520–526, donde 521 ≈ 502 (conexión rechazada), 522/524 ≈ 504 (tiempo de espera de conexión o de lectura) y 525/526 son problemas de la capa TLS.
El antipatrón más común es devolver 200 en todas las peticiones y poner el error en el campo code del cuerpo. Eso hace que la CDN cachee páginas de error, que las alertas de 5xx del sistema de monitorización no salten, que fetch().ok del navegador pierda sentido y que la política de reintentos no sepa qué hacer. Lo correcto es que el código HTTP exprese «qué ha pasado a nivel de petición» (la semántica del RFC 9110) y que el código de negocio del cuerpo exprese «el detalle a nivel de negocio»: reparto de tareas, no sustitución. Sin existencias es 422 + {"code":"OUT_OF_STOCK"}, no 200 + {"code":500}.
La comparativa 502 / 503 / 504 te dice si la aplicación se ha caído, si le han retirado el tráfico o si va lenta; las tarjetas 52x de Cloudflare apuntan directamente a «revisa el firewall del origen / el certificado / los tiempos de espera».
Escribe el interceptor según la columna «frontend / cliente» de cada tarjeta: el 401 renueva el token o lleva al login, el 403 avisa de que no hay permiso, el 429 lee Retry-After y espera, y los 5xx reintentan un número limitado de veces y lo registran.
¿Al crear un recurso se devuelve 201 + Location? ¿Al borrar, 204? ¿Un fallo de validación de negocio es 400 o 422? ¿El límite de peticiones incluye Retry-After? Las columnas «backend» y «errores de uso» son la lista de comprobación.
Las siete comparativas cubren las preguntas de «diferencias» más habituales; «cómo funciona» explica el nombre del 401, por qué existen 307/308 y para qué sirve de verdad el 304.
El servidor de entrada del sitio (la pasarela) no consigue conectar con el backend que procesa la petición, normalmente porque el proceso del backend se ha caído o se está reiniciando. Del lado del usuario solo queda refrescar más tarde; si el sitio es tuyo, revisa el proceso del backend y los registros de errores de la pasarela.
Cliente: lee la cabecera Retry-After, espera el tiempo indicado y vuelve a intentarlo; si falla varias veces, aplica retroceso exponencial (1 s, 2 s, 4 s…) y avisa al usuario de que hay demasiadas operaciones. Servidor: al devolver 429 incluye siempre Retry-After y, a ser posible, también cabeceras RateLimit-* para que el cliente pueda frenar antes.
Depende del objeto de la petición. GET /users/123 y el 123 no existe: 404. GET /users?name=xxx con resultado vacío: 200 + un array vacío. Un resultado vacío en un endpoint de lista es un «hay resultado, y está vacío» legítimo, no un error.
El 204 no tiene cuerpo de respuesta y json() lanza un SyntaxError al intentar analizar una cadena vacía. Comprueba antes response.status === 204 (o response.headers.get('content-length') === '0') y decide si analizas o no.
Son códigos internos que nginx escribe en su registro de accesos: el 444 indica que nginx cerró la conexión sin responder nada y el 499, que el cliente se desconectó antes de que nginx respondiera. En el navegador lo que se ve es «conexión restablecida» o ninguna respuesta.
Los datos de los códigos se descargan con la página; buscar, filtrar, copiar y guardar favoritos se hace en el navegador y no envía ninguna petición. Los favoritos se guardan en el localStorage de este equipo. Los enlaces externos apuntan a la documentación del RFC Editor, la IANA y Cloudflare, y al pulsarlos los gestiona el sitio de destino.
Actualizado el 2026-09-09
72 códigos HTTP de RFC 9110, extensiones y códigos no estándar de nginx/Cloudflare, con semántica, escenarios, tratamiento en frontend y backend y errores frecuentes; 7 comparativas de códigos que se confunden; búsqueda, copia y favoritos
Esta herramienta no está traducida por completo; parte del contenido usa el idioma de origen o uno de reserva.
La solicitud se ha recibido y el procesamiento continúa; los navegadores casi nunca exponen estos códigos a los scripts de la página.
Se han recibido las cabeceras de la solicitud; el cliente puede seguir enviando el cuerpo.
RFC 9110 §15.2.1
El servidor acepta cambiar de protocolo mediante la cabecera Upgrade.
RFC 9110 §15.2.2
El servidor ha recibido la solicitud y la está procesando, pero aún no hay respuesta final.
RFC 2518 (WebDAV, obsoleto)
Se envían algunas cabeceras antes de la respuesta final —sobre todo Link: preload— para que el navegador cargue recursos antes.
RFC 8297
La solicitud se recibió, se entendió y se procesó correctamente.
La solicitud ha tenido éxito; el cuerpo contiene el recurso solicitado o el resultado de la operación.
RFC 9110 §15.3.1
La solicitud ha tenido éxito y se ha creado un recurso nuevo.
RFC 9110 §15.3.2
La solicitud se ha aceptado pero aún no se ha procesado — el recibo de una tarea asíncrona.
RFC 9110 §15.3.3
La respuesta es correcta, pero su contenido ha sido modificado por un proxy intermedio.
RFC 9110 §15.3.4
Correcto, pero sin cuerpo de respuesta.
RFC 9110 §15.3.5
Correcto, y se pide al cliente que restablezca la vista del documento (por ejemplo, vaciar un formulario).
RFC 9110 §15.3.6
Solo se devuelve una parte del recurso (solicitud Range correcta).
RFC 9110 §15.3.7
El cuerpo es XML y cada subrecurso informa de su propio estado.
RFC 4918 (WebDAV)
Dentro de una respuesta 207, el mismo recurso ya se había informado antes y no se repite.
RFC 5842 (WebDAV)
El servidor ha aplicado manipulaciones de instancia (codificación delta) a la instancia actual y ha devuelto la diferencia.
RFC 3229
El cliente debe realizar una acción adicional —normalmente solicitar otra dirección— antes de que la solicitud finalice.
El recurso tiene varias representaciones; el cliente debe elegir una.
RFC 9110 §15.4.1
El recurso se ha trasladado de forma permanente a la nueva URL de Location; usar esa URL a partir de ahora.
RFC 9110 §15.4.2
El recurso está temporalmente en otro sitio; la próxima vez, pedir la URL original.
RFC 9110 §15.4.3
Obtener el resultado desde Location con GET, sea cual sea el método de esta solicitud.
RFC 9110 §15.4.4
El recurso no ha cambiado: usar la copia de la caché.
RFC 9110 §15.4.5
Solo se puede acceder al recurso a través del proxy indicado en Location.
RFC 9110 §15.4.6 (obsoleto)
En un borrador significaba cambiar de proxy; el código está reservado y sin uso.
RFC 9110 §15.4.7
Redirección temporal, y el cliente debe reenviar con el mismo método y cuerpo.
RFC 9110 §15.4.8
Redirección permanente que además conserva método y cuerpo (la versión estricta de 301).
RFC 9110 §15.4.9
La solicitud en sí tiene un problema: sintaxis, autenticación, recurso inexistente o frecuencia excesiva… repetir la misma solicitud no funcionará.
El servidor no entiende la solicitud: sintaxis incorrecta, parámetros ausentes o mal formados, o JSON que no se puede analizar.
RFC 9110 §15.5.1
Faltan credenciales o no son válidas — «¿quién eres?» (el nombre Unauthorized en realidad significa no autenticado).
RFC 9110 §15.5.2
Reservado para futuros pagos digitales; la especificación no define una semántica concreta.
RFC 9110 §15.5.3 (reservado)
El servidor sabe quién eres, pero no tienes permiso — «no puedes». Volver a autenticarse no sirve.
RFC 9110 §15.5.4
El servidor no encuentra el recurso solicitado y no dice si es temporal o permanente.
RFC 9110 §15.5.5
El recurso existe, pero no admite este método HTTP.
RFC 9110 §15.5.6
El servidor no tiene ninguna representación que cumpla Accept / Accept-Language.
RFC 9110 §15.5.7
Primero hay que autenticarse ante el servidor proxy (la versión proxy del 401).
RFC 9110 §15.5.8
El servidor esperó demasiado la solicitud (el cliente nunca terminó de enviarla).
RFC 9110 §15.5.9
La solicitud entra en conflicto con el estado actual del recurso; el usuario puede resolverlo modificando la solicitud.
RFC 9110 §15.5.10
El recurso existió y ahora se ha eliminado de forma permanente, sin dirección de reenvío.
RFC 9110 §15.5.11
El servidor exige que la solicitud lleve Content-Length.
RFC 9110 §15.5.12
Una condición de las cabeceras (If-Match, If-Unmodified-Since) no se cumple.
RFC 9110 §15.5.13
El cuerpo de la solicitud supera el tamaño permitido por el servidor.
RFC 9110 §15.5.14 (antes Payload Too Large)
La URL es demasiado larga para que el servidor la procese.
RFC 9110 §15.5.15
El servidor no admite el formato (Content-Type) del cuerpo.
RFC 9110 §15.5.16
El rango de bytes pedido en la cabecera Range supera el tamaño del recurso.
RFC 9110 §15.5.17
El servidor no puede cumplir la cabecera Expect.
RFC 9110 §15.5.18
Una broma de un RFC del 1 de abril de 1998; no debe usarse en HTTP real.
RFC 2324 (RFC del día de los inocentes); marcado como sin uso por la RFC 9110
La solicitud llegó a un servidor que no puede responder por esa autoridad (dominio).
RFC 9110 §15.5.20
La sintaxis y el formato son correctos, pero no se puede procesar semánticamente (fallo de validación de negocio).
RFC 9110 §15.5.21 (antes Unprocessable Entity)
El recurso está bloqueado.
RFC 4918 (WebDAV)
Esta operación falló porque antes falló una operación de la que depende.
RFC 4918 (WebDAV)
El servidor no quiere procesar una solicitud que podría reproducirse (datos tempranos TLS 1.3 0-RTT).
RFC 8470
El servidor rechaza procesar en el protocolo actual y pide cambiar al indicado en Upgrade.
RFC 9110 §15.5.22
El servidor exige una cabecera condicional (como If-Match) para evitar actualizaciones perdidas.
RFC 6585
Se enviaron demasiadas solicitudes en una ventana de tiempo (limitación de tasa).
RFC 6585
Una cabecera de solicitud (un campo o el total) es demasiado grande.
RFC 6585
El recurso se retiene por motivos legales (derechos de autor, órdenes gubernamentales). El número homenajea a la novela Fahrenheit 451.
RFC 7725
El servidor sabe que ha fallado o que no puede satisfacer una solicitud válida; reintentar más tarde puede funcionar.
El servidor se encontró con una condición inesperada y no pudo completar la solicitud.
RFC 9110 §15.6.1
El servidor no admite la funcionalidad necesaria para completar la solicitud (normalmente un método desconocido).
RFC 9110 §15.6.2
Un servidor que actúa como pasarela o proxy recibió una respuesta no válida de su upstream.
RFC 9110 §15.6.3
El servidor no puede atender la solicitud temporalmente (sobrecarga o mantenimiento), normalmente solo por un tiempo.
RFC 9110 §15.6.4
La pasarela o el proxy agotó el tiempo esperando una respuesta del upstream.
RFC 9110 §15.6.5
El servidor no admite la versión principal de HTTP usada por la solicitud.
RFC 9110 §15.6.6
Una mala configuración de negociación de contenido crea un bucle.
RFC 2295
El servidor no puede almacenar el contenido necesario para la solicitud.
RFC 4918 (WebDAV)
Se detectó un bucle infinito al procesar la solicitud.
RFC 5842 (WebDAV)
La solicitud debe ampliarse más antes de que el servidor pueda procesarla.
RFC 2774 (histórico)
El cliente debe autenticarse a nivel de red (portal cautivo) antes de navegar.
RFC 6585
No aparecen en ninguna RFC y solo salen en los registros de determinados servidores o en las páginas de error de CDN; conocerlos ahorra mucho tiempo de diagnóstico.
nginx cierra la conexión sin enviar respuesta; solo aparece en los logs de nginx.
específico de nginx
El cliente se desconectó antes de que el servidor respondiera; solo aparece en los logs de nginx.
específico de nginx
La respuesta del origen a Cloudflare estaba vacía, mal formada o sus cabeceras eran demasiado grandes.
específico de Cloudflare
Cloudflare no puede alcanzar el origen (conexión TCP rechazada).
específico de Cloudflare
La conexión TCP de Cloudflare al origen agotó su tiempo.
específico de Cloudflare
Cloudflare no puede enrutar hacia el origen (problema de DNS o de enrutamiento de red).
específico de Cloudflare
TCP se conectó, pero el origen no devolvió una respuesta HTTP en 100 segundos.
específico de Cloudflare
El handshake TLS entre Cloudflare y el origen falló.
específico de Cloudflare
En modo Full (strict), el certificado del origen está caducado, es autofirmado o no coincide con el dominio.
específico de Cloudflare