Diagnosticar errores de una API
Cuando veas un 401, 403, 409 o 422, consulta rápidamente qué significa y en qué contextos suele aparecer.
Cargando…
Guide
La página de códigos de estado HTTP es una tabla de consulta integrada en la aplicación: puedes buscar por código, por nombre en inglés, por su significado o por la descripción, y filtrar por 1xx (información), 2xx (éxito), 3xx (redirección), 4xx (error del cliente) y 5xx (error del servidor). Es conocimiento estático y no envía ninguna petición HTTP al dominio o a la API que escribas.
Actualizado el 2026-09-102 min read
404, "tiempo de espera", el nombre del estado o cualquier palabra clave, o deja el campo vacío para verlo todo.| Entrada | Salida | Notas |
|---|---|---|
404 |
la ficha de 404 Not Found | búsqueda exacta por número |
| "redirección" | descripciones 3xx relacionadas | búsqueda de texto |
| Filtro 5xx | solo errores del servidor | filtrado local |
HTTP_STATUS incluida en la aplicación; su cobertura cambia con las versiones y no se sincroniza en línea con el registro de la IANA.fetch, así que no puede decirte qué código devuelve ahora mismo un sitio web.Cuando veas un 401, 403, 409 o 422, consulta rápidamente qué significa y en qué contextos suele aparecer.
Explora las agrupaciones 2xx/3xx/4xx/5xx para fijar los conceptos básicos del protocolo.
No. Esta página no tiene ninguna capacidad de red: solo consulta la tabla local de códigos.
No, son datos incluidos en la propia versión de la aplicación.
Los términos de búsqueda solo filtran una tabla estática en local y no generan ninguna petición de red.
Actualizado el 2026-09-10
Referencia rápida de todos los códigos 1xx–5xx con su significado y casos de uso
Esta herramienta no está traducida por completo; parte del contenido usa el idioma de origen o uno de reserva.
El servidor ha recibido las cabeceras de la petición y el cliente debe seguir enviando el cuerpo. Habitual en subidas grandes precedidas por Expect: 100-continue.
El servidor acepta cambiar de protocolo, sobre todo en el handshake de WebSocket (Upgrade: websocket).
Extensión WebDAV: la petición se ha recibido y se está procesando, pero aún no hay respuesta. Evita que el cliente agote el tiempo de espera.
Devuelve parte de las cabeceras antes de la respuesta final, a menudo con una cabecera Link para que el navegador precargue recursos CSS/JS.
La petición se ha realizado correctamente. GET devuelve el contenido del recurso y POST el resultado del procesamiento. El código más habitual.
El recurso se ha creado correctamente; es habitual tras un POST/PUT, normalmente con una cabecera Location que apunta al nuevo recurso.
La petición se ha aceptado pero aún no se ha procesado; adecuado para tareas asíncronas como colas o importaciones masivas.
Los metadatos devueltos proceden de una copia local o de terceros (por ejemplo de un proxy que los modifica), no del servidor de origen.
Procesado correctamente pero sin contenido en la respuesta; típico tras un DELETE correcto o al guardar un formulario sin cambiar de página.
Procesado correctamente; el cliente debe restablecer su vista (por ejemplo, vaciar un formulario). Apenas se usa en la práctica.
Una petición de rango se ha resuelto correctamente y se devuelve parte del recurso. De ella dependen la reproducción con salto en vídeos y las descargas reanudables (cabecera Range).
Extensión WebDAV: una petición incluye varias operaciones y el cuerpo XML indica el estado de cada una.
Extensión WebDAV: los miembros vinculados ya se enumeraron en una respuesta anterior, así que no se vuelven a listar.
El servidor ha completado una petición GET del recurso y la respuesta es el resultado de aplicar manipulaciones de instancia (codificación delta).
El recurso tiene varias representaciones (por ejemplo, versiones de idioma) y el cliente o el usuario deben elegir una.
El recurso se ha trasladado de forma permanente a una nueva dirección y los buscadores actualizarán su índice. Habitual al cambiar de dominio o pasar de HTTP a HTTPS.
El recurso está temporalmente en otra dirección. En implementaciones antiguas el cliente puede convertir POST en GET; si hay que conservar el método, usar 307.
El cliente debe obtener el resultado con GET en otra dirección; típico del salto a la página de resultados tras enviar un formulario (patrón PRG).
El recurso no ha cambiado desde la última petición, así que puede reutilizarse la caché local. Funciona con ETag / Last-Modified.
(Obsoleto) Exige acceder al recurso a través del proxy indicado. Los navegadores modernos ya no lo admiten por motivos de seguridad.
Como 302, pero el método y el cuerpo de la petición no deben cambiar durante la redirección (POST sigue siendo POST).
Como 301, pero conserva el método y el cuerpo de la petición; adecuado para trasladar una API de forma permanente.
El servidor no puede entender la petición: falta algún parámetro, el JSON está mal formado, la sintaxis no es válida. El cliente debe revisar la petición.
Faltan credenciales o no son válidas (por ejemplo, un token caducado). En semántica equivale a «sin iniciar sesión», así que conviene llevar al usuario a autenticarse.
Código reservado que algunas API usan para indicar que se ha agotado la cuota o que hace falta una suscripción de pago.
La identidad está confirmada, pero no tiene permiso para acceder al recurso (por ejemplo, un usuario normal en una interfaz de administración). A diferencia del 401, aquí se trata de autorización.
El recurso solicitado no existe: URL incorrecta o recurso eliminado. El código más conocido.
El recurso no admite este método HTTP (por ejemplo, POST contra una interfaz de solo lectura). La respuesta debe incluir la cabecera Allow con los métodos permitidos.
El servidor no puede generar un formato que cumpla la cabecera Accept (el cliente solo acepta XML y el servidor solo tiene JSON).
Como el 401, pero primero hay que autenticarse en el servidor proxy.
El servidor agotó el tiempo de espera mientras se enviaba la petición (red lenta o cliente interrumpido). El cliente puede reintentarlo más tarde.
La petición entra en conflicto con el estado actual del recurso: creación duplicada, ediciones simultáneas, etc.
El recurso existió, pero se ha eliminado de forma permanente y no volverá. Es más explícito que un 404 y ayuda a los buscadores a retirarlo del índice.
El servidor exige que la petición incluya la cabecera Content-Length.
No se cumple una condición de las cabeceras como If-Match; se usa para bloqueo optimista y evitar sobrescribir un recurso modificado por otra persona.
El cuerpo de la petición supera el límite del servidor, típico en subidas demasiado grandes (por ejemplo, client_max_body_size de nginx).
La URL solicitada supera la longitud que admite el servidor, normalmente por acumular demasiados parámetros GET; conviene usar POST.
No se admite el formato del cuerpo de la petición: por ejemplo, se envía un formulario a una API que espera application/json.
El rango solicitado en la cabecera Range supera el tamaño real del recurso; es habitual cuando los datos locales de una descarga reanudable no coinciden con el archivo del servidor.
El servidor no puede satisfacer lo que pide la cabecera Expect (por ejemplo, no admite 100-continue).
Una inocentada de 1998 (protocolo HTCPCP): la tetera se niega a preparar café. Algunos sitios lo usan como respuesta anti-scraping divertida.
La petición llegó a un servidor que no puede generar una respuesta, a menudo por reutilizar una conexión HTTP/2 hacia un host virtual equivocado.
La petición es correcta en sintaxis pero inválida en semántica: falla la validación de un campo (por ejemplo, un correo mal formado). Las API REST lo usan para errores de formulario.
Extensión WebDAV: el recurso está bloqueado y la operación actual no se puede ejecutar.
Extensión WebDAV: como una petición anterior ha fallado, la actual tampoco se puede completar.
El servidor no quiere procesar datos tempranos que podrían reenviarse (TLS 1.3 0-RTT) para evitar ataques de repetición.
El servidor rechaza procesar con el protocolo actual y pide al cliente que se actualice; la cabecera Upgrade indica el protocolo de destino.
El servidor exige una cabecera condicional (como If-Match) para obligar al cliente a usar bloqueo optimista y no perder actualizaciones.
Se ha activado la limitación de tasa. La respuesta puede incluir Retry-After para indicar cuándo reintentar; es el código estándar de limitación de API.
El tamaño total de las cabeceras o de un campo concreto supera el límite, a menudo porque las cookies han crecido demasiado.
El recurso se deniega por motivos legales (derechos de autor, bloqueo regulatorio). El número homenajea a la novela Fahrenheit 451.
El servidor ha sufrido un error inesperado (excepción no capturada, error de código). Hay que revisar los registros del servidor.
El servidor no admite este método o función, por ejemplo PATCH contra un servidor que solo admite GET/POST.
La pasarela o el proxy inverso han recibido una respuesta no válida del servidor de origen; habitual si el backend se cae o nginx rechaza la conexión.
El servidor está sobrecargado o en mantenimiento temporal; puede acompañarse de Retry-After. Habitual al escalar, desplegar o abrir el circuit breaker.
La pasarela o el proxy agotaron el tiempo de espera de la respuesta del servidor de origen, a menudo por un backend lento o una consulta lenta a la base de datos.
El servidor no admite la versión del protocolo HTTP usada en la petición.
Error de configuración de la negociación de contenido: la variante elegida participa a su vez en la negociación y se crea un bucle.
Extensión WebDAV: el servidor no tiene espacio suficiente para lo que la petición necesita guardar (por ejemplo, disco lleno).
Extensión WebDAV: se ha detectado un bucle infinito al procesar la petición (por ejemplo, un ciclo de vínculos).
A la petición le faltan extensiones que el servidor exige; hay que ampliarla antes de reintentar (muy poco frecuente).
Hace falta autenticarse en la capa de red antes de navegar; el caso típico es el portal cautivo del Wi-Fi de hotel o aeropuerto.