CodeKivo LogoCodeKivo

Códigos de Estado HTTP

Referencia técnica completa para todos los códigos de estado HTTP de 100 a 599. Búsqueda por número o palabra clave, definiciones RFC, causas habituales, listas de verificación y ejemplos de respuesta.

65 / 65 códigos
Filtros rápidos:
404

No encontrado(Not Found)

Error del clienteEn caché

El servidor no ha encontrado ninguna representación que coincida con la URI solicitada.

Especificación RFC:RFC 9110 §15.5.5
•
Almacenable en caché:Sí
•
Enlace directo:

Descripción y semántica del protocolo

Es el código de error más conocido en la web. Indica que el recurso solicitado no existe en la ruta especificada, fue eliminado o la URL está mal escrita. Los motores de búsqueda consideran que la ausencia puede ser temporal y volverán a rastrear la URL.

Causas habituales

  • URL con errores tipográficos en la ruta o identificadores erróneos.
  • El recurso solicitado ha sido eliminado o movido sin configurar una redirección.
  • Rutas no registradas en el enrutador de la aplicación web.

Diagnóstico y resolución

  • Compruebe la exactitud de la ruta URL y los parámetros de consulta.
  • Si el recurso se movió permanentemente, configure una redirección 301 o 308.
  • Si el recurso se eliminó intencionadamente para siempre, devuelva 410 Gone para optimizar el rastreo de motores de búsqueda.

Ejemplo de respuesta HTTP

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "Not Found",
  "message": "Resource '/api/v1/orders/987123' does not exist"
}
Códigos relacionados:

Cómo Utilizar la Guía de Referencia de Códigos de Estado HTTP

  • Utilice el campo de búsqueda para filtrar códigos por número (ej. 404, 500), palabra clave o frase en español o inglés.
  • Seleccione una pestaña de categoría (1xx, 2xx, 3xx, 4xx, 5xx) para acotar los códigos dentro de esa clase de respuesta.
  • Aplique los filtros rápidos para visualizar al instante códigos frecuentes, respuestas almacenables en caché o errores del cliente y del servidor.
  • Pulse sobre cualquier tarjeta de estado para desplegar su definición formal RFC, causas habituales, pasos de resolución y cabeceras de respuesta.
  • Utilice las acciones de copiado rápido para extraer números de código, ejemplos de respuestas HTTP o enlaces directos con ancla compartible.

Clases de Códigos de Estado HTTP de un Vistazo

ClaseCategoríaDefinición y Propósito CentralAcción Típica del ClienteEjemplos Clave
1xxInformativoRespuesta provisional que indica la recepción de la solicitud y el curso de su procesamiento.Continuar enviando cabeceras o cuerpo, o cambiar de protocolo.100, 101, 103
2xxÉxitoLa acción solicitada por el cliente fue recibida, comprendida y aceptada satisfactoriamente.Procesar la carga útil de la respuesta o confirmar la acción completada.200, 201, 204, 206
3xxRedirecciónEl agente de usuario debe emprender acciones adicionales para completar la solicitud.Seguir la URI indicada en "Location" o cargar el recurso desde la caché.301, 302, 304, 307, 308
4xxError del clienteLa solicitud contiene errores de sintaxis, accesos no autorizados o condiciones no cumplibles.Corregir los datos del cliente, aportar credenciales o regular la tasa de peticiones.400, 401, 403, 404, 422, 429
5xxError del servidorEl servidor reconoce un fallo interno imprevisto o resulta incapaz de cumplir la solicitud.Reintentar con retroceso exponencial o alertar al equipo de operaciones backend.500, 502, 503, 504

Comparativas Técnicas Fundamentales

401 Unauthorized frente a 403 Forbidden

401 Unauthorized: Fallo de autenticación. La solicitud carece de credenciales válidas (token Bearer ausente o expirado, clave de API inválida). Reautenticarse con credenciales legítimas subsana el error.

403 Forbidden: Fallo de autorización. La identidad está verificada, pero el cliente carece de privilegios (rol RBAC insuficiente, IP restringida o bloqueo de organización) para acceder al recurso solicitado.

301 / 302 frente a 307 / 308 (Preservación de Método)

301 / 302 (Históricos): Redirecciones donde los clientes tradicionalmente alteraban el método de solicitud de POST a GET al seguir el destino.

307 / 308 (RFC 9110): Redirecciones con preservación estricta de método. Tanto 307 (temporal) como 308 (permanente) obligan al cliente a reenviar exactamente el mismo verbo HTTP (un POST permanece como POST) con el cuerpo original.

500 vs 502 vs 503 vs 504 (Diagnóstico de Servidor)

500 Internal Server Error: Caída interna de la aplicación (excepción no capturada, puntero nulo, pérdida de conexión a base de datos).

502 Bad Gateway: El proxy inverso (Nginx, Cloudflare) alcanzó el backend, pero este se cerró inesperadamente o rechazó la conexión.

503 Service Unavailable: Mantenimiento temporal o saturación de capacidad; los motores de búsqueda pausan el rastreo sin penalización.

504 Gateway Timeout: El backend tardó más tiempo en responder que el umbral máximo de lectura configurado en el proxy inverso.

400 Bad Request frente a 422 Unprocessable Content

400 Bad Request: Error de sintaxis en la petición. JSON malformado (comas sobrantes, comillas abiertas), codificación errónea en parámetros de consulta o cabeceras corruptas.

422 Unprocessable Content: La sintaxis JSON es 100% válida, pero incumple las validaciones de negocio o el esquema (correo no válido, edad negativa, fecha en el pasado).

Matriz de Diseño de Códigos de Estado en APIs RESTful

Verbo HTTPSemántica CRUD¿Idempotente?¿Seguro?Estados de Éxito EstándarEstados de Error Estándar
GETLectura / ConsultaSíSí200 OK, 206 Partial404, 401, 403, 304
POSTCreación / AcciónNoNo201 Created, 202 Accepted400, 422, 409, 415
PUTReemplazo / UpsertSíNo200 OK, 204 No Content400, 404, 412, 428
PATCHActualización ParcialNoNo200 OK, 204 No Content400, 404, 422, 409
DELETEEliminación / BajaSíNo204 No Content, 202 Accepted404, 401, 403
HEADSolo CabecerasSíSí200 OK (sin cuerpo)404, 304
OPTIONSCORS / CapacidadesSíSí204 No Content, 200 OK405 Method Not Allowed

Frequently Asked Questions

¿Qué son los códigos de estado HTTP y qué representan sus cinco clases?

Los códigos de estado HTTP son respuestas numéricas estandarizadas de 3 dígitos emitidas por un servidor web ante la solicitud de un cliente (IETF RFC 9110). El primer dígito define una de las cinco clases de respuesta: 1xx Informativo (solicitud recibida, el procesamiento continúa), 2xx Éxito (la acción solicitada fue recibida, comprendida y aceptada con éxito), 3xx Redirección (el cliente debe realizar acciones adicionales para completar la petición), 4xx Error del cliente (la solicitud contiene sintaxis errónea o no puede ser cumplida) y 5xx Error del servidor (el servidor falló al intentar atender una solicitud aparentemente válida).

¿Cuál es la diferencia técnica fundamental entre 401 Unauthorized y 403 Forbidden?

La frontera clave radica en la diferencia entre autenticación (identidad) y autorización (permisos). 401 Unauthorized indica que la solicitud carece de credenciales de autenticación válidas o estas han expirado (token JWT ausente o vencido, API Key errónea); enviar credenciales legítimas resolverá el fallo. Por el contrario, 403 Forbidden significa que el servidor reconoce perfectamente la identidad del usuario, pero sus políticas de control de acceso (como roles RBAC) determinan que no posee los privilegios suficientes para acceder al recurso; reintentar la solicitud con el mismo usuario continuará arrojando un error 403.

¿Cómo difieren las redirecciones 301, 302, 307 y 308 respecto al SEO y la preservación de métodos HTTP?

Desde la perspectiva de SEO, 301 Moved Permanently y 308 Permanent Redirect son redirecciones permanentes que transfieren la totalidad de la autoridad de enlace (PageRank). En cambio, 302 Found y 307 Temporary Redirect son temporales y no transfieren dicha autoridad. En cuanto a los métodos HTTP, históricamente los navegadores mutaban indebidamente las solicitudes POST a GET tras recibir un 301 o 302. Para impedir esta alteración no deseada, RFC 9110 consolidó 307 (temporal) y 308 (permanente), los cuales prohíben estrictamente al cliente cambiar el verbo HTTP original (un POST se reenvía obligatoriamente como POST con su cuerpo intacto).

¿Cuál es la diferencia entre los errores de servidor 500, 502, 503 y 504?

500 Internal Server Error corresponde a una excepción no controlada o fallo directo en el código de la aplicación interna. 502 Bad Gateway indica que un proxy inverso (Nginx, Cloudflare, AWS ALB) intentó comunicarse con el servidor de aplicaciones backend pero este rechazó la conexión o se cerró inesperadamente. 503 Service Unavailable señala que el servidor está temporalmente sobrecargado o en mantenimiento programado (habitualmente devolviendo una cabecera Retry-After). 504 Gateway Timeout ocurre cuando el proxy inverso estableció contacto con el backend, pero este tardó más tiempo en responder que el tiempo límite configurado (por ejemplo, debido a una consulta lenta a la base de datos).

¿Cuándo debe una API REST devolver 400 Bad Request frente a 422 Unprocessable Content?

Devuelva 400 Bad Request cuando la solicitud presente un error de sintaxis subyacente que impida al servidor siquiera analizar o deserializar la carga útil (como un documento JSON malformado con comas sobrantes o cabeceras HTTP incompatibles). Por el contrario, devuelva 422 Unprocessable Content (RFC 9110 §15.5.21) cuando la sintaxis sea perfectamente válida (JSON estructurado correctamente), pero los datos incumplan reglas semánticas o validaciones de negocio (por ejemplo, formato de correo no válido, edad negativa o longitud insuficiente de contraseña).

¿Qué diferencia práctica existe entre 404 Not Found y 410 Gone para el SEO y las APIs?

404 Not Found indica que el recurso no existe actualmente en la URI solicitada; los motores de búsqueda asumen que podría tratarse de una indisponibilidad temporal o un enlace roto accidental, por lo que continuarán reintentando el rastreo en el futuro. En contraposición, 410 Gone declara explícitamente que el recurso existió en el pasado pero fue eliminado de forma deliberada y permanente sin dirección de sustitución. Rastreadores como Googlebot interpretan 410 como una instrucción definitiva para purgar la URL de los índices de búsqueda de inmediato, preservando el presupuesto de rastreo (crawl budget).

¿Qué códigos de estado HTTP se recomiendan en una API REST para POST, PUT, PATCH y DELETE?

Para POST (creación): devuelva 201 Created junto a una cabecera Location que apunte a la URI del nuevo recurso, o 202 Accepted si el procesamiento se ejecuta de manera asíncrona en una cola. Para PUT y PATCH (actualización): devuelva 200 OK con la entidad actualizada o 204 No Content si la respuesta no incluye cuerpo. Para DELETE: devuelva 204 No Content tras una eliminación exitosa o 202 Accepted si la baja se programa asíncronamente. En caso de fallos de validación en cualquier verbo de escritura, devuelva 422 Unprocessable Content con el desglose de los errores.

¿Cómo debe implementar una API el código 429 Too Many Requests para el control de velocidad (rate limiting)?

Cuando el volumen de llamadas de un cliente sobrepasa los umbrales autorizados, el servidor debe responder con 429 Too Many Requests (RFC 6585) acompañado de una cabecera "Retry-After" que especifique los segundos o la marca de tiempo GMT en que se restablecerá el acceso. Las APIs maduras proporcionan además las cabeceras estándar "X-RateLimit-Limit" (cuota total), "X-RateLimit-Remaining" (peticiones restantes) y "X-RateLimit-Reset" (tiempo de restablecimiento) para que los clientes adapten su ritmo de peticiones proactivamente.

¿Qué códigos de estado HTTP son almacenables en caché por defecto según RFC 9110 y RFC 9111?

De acuerdo con las especificaciones RFC 9110 y RFC 9111, los códigos 200 (OK), 203 (Non-Authoritative Information), 204 (No Content), 206 (Partial Content), 300 (Multiple Choices), 301 (Moved Permanently), 404 (Not Found), 405 (Method Not Allowed), 410 (Gone), 414 (URI Too Long) y 501 (Not Implemented) son almacenables en caché de manera predeterminada, a menos que directivas explícitas en la cabecera Cache-Control (como no-store o private) indiquen lo contrario.

¿Cuál es el formato estándar recomendado para emitir errores en respuestas HTTP 4xx y 5xx?

IETF RFC 9457 (que actualiza y reemplaza a RFC 7807) formaliza el estándar "Problem Details for HTTP APIs" (Content-Type: application/problem+json). En lugar de esquemas de error propietarios y heterogéneos, las APIs compatibles devuelven una estructura JSON estándar con cinco campos canónicos: "type" (URI que categoriza el tipo de fallo), "title" (resumen legible y conciso), "status" (código de estado HTTP numérico coincidente), "detail" (explicación concreta para esta incidencia específica) e "instance" (identificador URI único de la ocurrencia para fines de rastreo y depuración).