Búsqueda de Códigos HTTP Status

Códigos HTTP Status — Referencia Completa de 100 a 511

Cada respuesta HTTP de un servidor incluye un código de tres dígitos que indica al cliente qué pasó. Los códigos se agrupan en cinco categorías: 1xx (informativos), 2xx (éxito), 3xx (redirección), 4xx (error cliente) y 5xx (error servidor). Esta referencia lista los más de 60 códigos registrados con nombres, descripciones, casos de uso comunes y enlaces a los RFC que los definen. Cada tarjeta también lleva distintivos de ingeniería — Cacheable (según el conjunto cacheable heurístico del RFC 9111), Reintentable (seguro para reintentar con backoff), Conserva método y Transfiere SEO — para que los ingenieros que escriben capas de reintento, caché o redirección sepan de un vistazo si un código es seguro de reintentar o cachear. Filtra por categoría o por Cacheable/Reintentable, busca por número o palabra clave pensando en flujos con curl/Postman/observabilidad, y revisa la guía de Retry-After, X-RateLimit y RFC 7807 Problem Details en las preguntas frecuentes.

¿Qué son los códigos de estado HTTP y cómo se organizan?

Los códigos de estado HTTP son números de tres dígitos devueltos por un servidor en respuesta a una solicitud del cliente, definidos principalmente en RFC 9110 (HTTP Semantics, 2022) que reemplazó al RFC 7231. Se agrupan en cinco clases por el primer dígito: 1xx informacional (solicitud recibida, continuando), 2xx éxito (solicitud recibida, entendida y aceptada correctamente), 3xx redirección (se necesita acción adicional para completar la solicitud), 4xx error del cliente (la solicitud contiene sintaxis incorrecta o no puede cumplirse) y 5xx error del servidor (el servidor falló al cumplir una solicitud válida). El registro completo lo mantiene IANA, y actualmente incluye alrededor de 70 códigos. Los clientes deben tratar códigos desconocidos como el x00 genérico de su clase — así un código nuevo 499 debería tratarse como 400 por un cliente que no lo reconozca.

¿Cuál es la diferencia entre 401 Unauthorized y 403 Forbidden?

Estos se confunden de forma rutinaria. 401 Unauthorized significa "no te has autenticado — proporciona credenciales." La respuesta debe incluir una cabecera WWW-Authenticate diciendo al cliente qué esquema de auth usar (Basic, Bearer, Digest). La misma solicitud con credenciales válidas tendría éxito. 403 Forbidden significa "sé quién eres, y no tienes permiso." Re-autenticar no ayudará; las credenciales son reconocidas pero carecen de permiso para este recurso. El nombre 401 es históricamente engañoso — "unauthorized" debería ser realmente "unauthenticated." En la práctica, muchas APIs devuelven incorrectamente 401 para errores de permiso. RFC 9110 establece explícitamente que 403 debe usarse cuando el servidor entendió la solicitud pero se niega a autorizarla. Un código relacionado sutil es 407 Proxy Authentication Required, idéntico a 401 pero para un servidor proxy en la cadena.

¿Cuándo debo usar redirecciones 301 vs 302 vs 307 vs 308?

Las cuatro redirigen, pero difieren en dos dimensiones: permanente vs temporal, y si el método de la solicitud puede cambiar. 301 Moved Permanently y 308 Permanent Redirect ambos señalan que el recurso se movió permanentemente — los motores de búsqueda transfieren la autoridad de enlaces. 302 Found y 307 Temporary Redirect señalan un movimiento temporal. La diferencia de preservación de método es crítica: 301 y 302 históricamente permiten a los clientes cambiar POST a GET en la redirección (por ambigüedad de cumplimiento RFC), mientras que 307 y 308 requieren estrictamente el mismo método y cuerpo. Para migraciones SEO, use 301. Para endpoints POST que se mueven, use 308 para preservar el cuerpo. Para balanceo de carga o pruebas A/B, use 302 o 307. Bing y Google han declarado explícitamente que 308 se trata equivalentemente a 301 para fines de ranking.

¿Qué significa 429 Too Many Requests y cómo manejarlo?

429 (RFC 6585) significa que el cliente ha enviado demasiadas solicitudes en un tiempo dado y está siendo limitado. La respuesta debe incluir una cabecera Retry-After — un entero de segundos-delta ("Retry-After: 60") o una HTTP-date — diciendo al cliente cuándo reintentar. Los clientes bien comportados deben implementar retroceso exponencial con jitter: no reintente exactamente en el tiempo Retry-After (cada cliente golpearía a la vez), reintente entre Retry-After y Retry-After + jitter aleatorio. Cabeceras adicionales comunes pero no en RFC: X-RateLimit-Limit (el techo), X-RateLimit-Remaining (llamadas restantes en ventana actual), X-RateLimit-Reset (timestamp Unix cuando se reinicia la ventana). El borrador IETF draft-ietf-httpapi-ratelimit-headers propone cabeceras RateLimit y RateLimit-Policy estandarizadas. Muchas APIs también devuelven 503 con Retry-After para el mismo propósito; la señal clave es Retry-After.

¿Qué es 418 I'm a teapot y es real?

418 I'm a teapot es el huevo de pascua más famoso en HTTP. Origina del RFC 2324 (Hyper Text Coffee Pot Control Protocol), una broma del Día de los Inocentes publicada el 1 de abril de 1998. El significado pretendido era que una tetera, cuando se le pidiera preparar café, debe responder con este estado. No es parte de la especificación real de HTTP (RFC 9110 no lo incluye), y IANA no lo registra. Sin embargo, muchos frameworks web y bibliotecas (Node.js, Go, Python, Rust) incluyen constantes para HTTP 418 porque los desarrolladores genuinamente lo usan para endpoints caprichosos u ocultos. El robots.txt de Google durante años devolvía 418 para ciertos agentes de usuario. Reserve 418 para chistes y honeypots — nunca lo use para semántica de error real, porque los clientes explícitamente no están obligados a manejarlo.

¿Cuál es la diferencia entre 500, 502, 503 y 504?

Los cuatro son errores del lado del servidor pero indican distintos modos de fallo. 500 Internal Server Error es el atrapa-todos genérico cuando ocurrió una excepción inesperada en el código de la aplicación — un NullPointerException, un rechazo de promesa no manejado, una consulta a base de datos que explotó. 502 Bad Gateway significa que un servidor upstream devolvió una respuesta inválida a un gateway/proxy (como NGINX hablando con un backend mal portado). 503 Service Unavailable significa que el servidor está temporalmente sobrecargado o en mantenimiento y rechaza solicitudes intencionalmente; debe incluir Retry-After. 504 Gateway Timeout significa que un gateway/proxy esperó a un servidor upstream y agotó el tiempo antes de obtener respuesta. La distinción importa para ops: 500 significa "arreglar el código," 502 significa "revisar el servicio backend," 503 significa "escalar arriba," y 504 significa "revisar timeouts de red/upstream." Cloudflare añade códigos no estándar 520-527 para fallos de borde más granulares.

¿Qué significa 422 Unprocessable Entity vs 400 Bad Request?

400 Bad Request significa que la sintaxis es incorrecta: JSON malformado, cabeceras requeridas faltantes, formato de query string inválido — el servidor ni siquiera puede parsear lo que enviaste. 422 Unprocessable Entity (originalmente de WebDAV RFC 4918, popularizado por APIs REST) significa que la sintaxis es correcta pero la semántica es incorrecta: el JSON parsea limpiamente, pero "email" no es una dirección de correo válida, o "edad" es -5, o "endDate" es antes de "startDate". RFC 9110 reafirma 422 para la audiencia HTTP más amplia. La mayoría de APIs REST modernas (Stripe, GitHub, Rails) usan 422 para errores de validación, lo que permite a los clientes distinguir "mi código generó JSON inválido" de "mi código generó JSON válido con valores inválidos." Empareje 422 con un cuerpo JSON listando los errores a nivel de campo (RFC 7807 Problem Details es el formato estándar). 409 Conflict es un código relacionado para conflictos de estado como creación de recurso duplicado.

¿Cuáles son los códigos de estado menos conocidos que debería saber?

Más allá de los comunes, varios códigos de nicho resuelven problemas reales. 100 Continue se usa con Expect: 100-continue para evitar enviar un cuerpo grande si el servidor lo rechazará. 103 Early Hints (RFC 8297) permite a servidores enviar cabeceras Link antes de la respuesta final, permitiendo precarga del navegador. 226 IM Used es para codificación delta (raro). 308 Permanent Redirect es el 301 que preserva método. 410 Gone señala que un recurso fue removido deliberadamente y es improbable que vuelva — más fuerte que 404 y bueno para desindexación SEO. 451 Unavailable For Legal Reasons (RFC 7725, nombrado por Fahrenheit 451) se usa para remoción de contenido ordenada por corte. 425 Too Early previene ataques de repetición en TLS 1.3 0-RTT. 428 Precondition Required fuerza a clientes a usar If-Match para solicitudes condicionales. 511 Network Authentication Required es lo que portales cautivos deberían devolver. Conocer estos le permite comunicar intención con precisión.

¿Qué códigos HTTP son cacheables por defecto?

El RFC 9111 (HTTP Caching) define un conjunto específico de respuestas heurísticamente cacheables por defecto — es decir, una caché compartida puede almacenarlas incluso sin un header Cache-Control o Expires explícito. Ese conjunto es: 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 308 Permanent Redirect, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long y 451 Unavailable For Legal Reasons. La herramienta marca cada uno con un distintivo Cacheable, y el filtro Solo cacheables reduce la cuadrícula a exactamente esta lista. Tres advertencias: (1) esto es el comportamiento por defecto — cualquier respuesta puede hacerse cacheable o no con directivas Cache-Control explícitas; (2) las respuestas con no-store, private o un header Vary: * nunca se almacenan; y (3) errores como 404 y 410 se cachean solo brevemente usando frescura heurística (típicamente una fracción del tiempo desde Last-Modified). Ante la duda, define Cache-Control explícitamente en lugar de confiar en el conjunto heurístico.

¿Qué códigos 4xx y 5xx son seguros para reintentar automáticamente?

La seguridad del reintento depende de si la solicitud es idempotente y si el fallo es transitorio. Los códigos que vale la pena reintentar automáticamente — siempre con backoff exponencial y jitter, y respetando cualquier header Retry-After — son: 408 Request Timeout, 425 Too Early, 429 Too Many Requests, 500 Internal Server Error (solo para métodos idempotentes como GET/PUT/DELETE), 502 Bad Gateway, 503 Service Unavailable y 504 Gateway Timeout. La herramienta los marca con un distintivo Reintentable y el filtro Solo reintentables los aísla. Nunca reintentes a ciegas 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict ni 422 Unprocessable Content — la solicitud en sí está mal y reintentarla fallará igual. Para un 500 en un POST no idempotente, reintentar arriesga crear duplicados; usa una clave de idempotencia (como hacen Stripe y la mayoría de APIs de pago) para que el reintento sea seguro. Para 429 y 503, prefiere el Retry-After del servidor sobre tu propio temporizador, y añade jitter para que una flota de clientes no reintente en sincronía (efecto manada) justo cuando se reinicia la ventana.

Características Principales

• Todos los códigos HTTP status registrados en IANA (60+) cubriendo 100 a 511
• Descripciones detalladas para los 25 códigos más comunes (200, 301, 304, 401, 403, 404, 429, 500, 503, etc.)
• Búsqueda por número de código o palabra clave en nombres y descripciones
• Filtro por categoría: 1xx Informativo, 2xx Éxito, 3xx Redirección, 4xx Error Cliente, 5xx Error Servidor
• Indicadores de categoría codificados por color para reconocimiento visual instantáneo
• Enlaces directos al RFC definitorio de cada código (RFC 9110, RFC 6585, etc.)
• Botones de salto rápido para los cuatro códigos más buscados (200, 301, 404, 500)
• Copia cualquier código al portapapeles con un clic para reportes de bugs y documentación
• Ejemplos de casos de uso explicando cuándo es apropiado cada código
• Cubre adiciones modernas: 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
• Incluye el 418 I'm a teapot del RFC 2324 para completar
• JavaScript puro — sin bibliotecas externas
• Funciona offline tras la primera carga
• Diseño de cuadrícula responsive para móvil y escritorio
• 100% del lado del cliente — la búsqueda no hace peticiones