Qué significan los errores HTTP 400, 401, 403, 404, 429 y 500
Publicado el 2026-10-21 por frfrand
Guía práctica de códigos de respuesta HTTP para saber qué falla entre navegador, API, autenticación y servidor.
Los códigos de estado HTTP indican cómo respondió un servidor a una solicitud. Un 404 suele significar que no encontró el recurso solicitado; un 500 indica un error interno al procesarla. Comprenderlos permite diagnosticar una web sin adivinar qué componente falló.
El número importa menos que la familia
Los códigos 2xx indican éxito. Los 3xx se relacionan con redirecciones. Los 4xx señalan problemas relacionados con la solicitud del cliente, y los 5xx indican que el servidor no pudo cumplirla.
Eso no significa que cualquier 4xx sea culpa de una persona: una API mal diseñada también puede responder con un código incorrecto.
400: solicitud incorrecta
Un 400 Bad Request aparece cuando el servidor no puede o no quiere procesar una solicitud por un problema que considera del cliente.
Imaginá que enviás un JSON con sintaxis inválida o parámetros imposibles de interpretar. El servidor puede devolver 400, idealmente con un mensaje que explique qué campo revisar.
Pero no utilices 400 como respuesta genérica a cualquier error. Distinguir situaciones ayuda muchísimo a quienes utilizan tu API.
401 frente a 403: una confusión habitual
401 Unauthorized tiene un nombre histórico algo engañoso: suele indicar que la solicitud carece de credenciales válidas para acceder al recurso.
403 Forbidden indica que el servidor comprendió la solicitud, pero se niega a realizarla. Una persona podría estar identificada correctamente y no tener permisos para consultar una factura.
Pensalo así: 401 es «necesito credenciales válidas» y 403 es «no tenés acceso a esta operación». En ambos casos hay matices y mecanismos de autenticación particulares.
404: recurso no encontrado
El clásico 404 Not Found no demuestra que todo el servidor esté caído. Puede faltar una ruta, haberse eliminado una página o utilizarse una URL equivocada.
A veces una API devuelve 404 deliberadamente para no revelar si existe un recurso privado al que alguien no tiene acceso. Eso puede ser apropiado si está contemplado por la política de seguridad.
Antes de perseguir un error de despliegue, comprobá la URL exacta, el método HTTP y las rutas que realmente registró la aplicación.
429: demasiadas solicitudes
Un 429 Too Many Requests aparece cuando se ha superado un límite de solicitudes. Puede ser temporal y estar acompañado de información sobre cuándo reintentar.
No significa necesariamente que la web tenga un bug. Puede ser la respuesta esperada de un sistema que protege recursos.
Una integración responsable reduce la frecuencia, respeta las indicaciones del servidor y evita reintentar cientos de veces por segundo.
500: el servidor falló
Un 500 Internal Server Error indica que ocurrió un problema inesperado mientras el servidor atendía la solicitud.
Puede ser un error de código, una dependencia incorrecta, una configuración incompleta o muchas otras causas. El código por sí solo no dice cuál.
Para investigarlo hay que revisar los logs de la aplicación y la petición correspondiente. Evita mostrar trazas completas con contraseñas o variables secretas a los visitantes.
¿Y los famosos 502, 503 y 504?
Un 502 Bad Gateway suele indicar que un proxy o intermediario recibió una respuesta inválida de otro servidor. Un 503 Service Unavailable señala indisponibilidad temporal o sobrecarga. Un 504 Gateway Timeout indica que el intermediario no recibió a tiempo la respuesta necesaria.
Estas diferencias importan cuando utilizas Nginx delante de un backend. Un 502 puede apuntar a un proceso caído, mientras que un 504 puede aparecer cuando el backend tarda demasiado.
Cómo investigar sin perder tiempo
Primero reproduce el problema y anota URL, método, código y momento. Después identifica qué componente generó la respuesta: navegador, proxy, backend o servicio externo.
Si utilizas varios servicios, correlaciona registros y peticiones. Un error HTTP es una pista, no el diagnóstico completo.
¿Cómo se ve esto en ArduMaker?
En una aplicación desplegada en un VPS de ArduMaker, los códigos HTTP pueden ayudarte a decidir si revisar permisos, rutas, Nginx o procesos del backend. La plataforma facilita operar los servicios, pero interpretar el código sigue siendo esencial.
En resumen: 401 no es 403, y 502 no es 504. Entender esas diferencias evita corregir la parte equivocada del sistema.
Fuentes: Códigos HTTP en MDN · Semántica HTTP RFC 9110.