PK Systems PK Systems
Web y marketing

Referencia de Códigos de Estado HTTP

Busca y aprende el significado, causa típica y uso de cada código de estado HTTP común, con fragmentos en cURL/Python/JS/PHP.

Referencia de Códigos de Estado HTTP

100 Continue #

Respuesta provisional que indica que el servidor ha recibido las cabeceras y el cliente puede enviar el cuerpo. RFC 9110 §15.2.1.

Causa común

El cliente envió Expect: 100-continue para comprobar si el servidor aceptará un cuerpo grande antes de mandarlo.

Cuándo usarlo

Se utiliza entre cabeceras y cuerpo de subidas largas (PUT, POST) para que el cliente no malgaste ancho de banda.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 100 Continue
101 Switching Protocols #

El servidor acepta cambiar a otro protocolo de aplicación sobre la misma conexión TCP, listado en Upgrade. RFC 9110 §15.2.2.

Causa común

El cliente pidió Upgrade (normalmente WebSocket o HTTP/2 sobre h2c) y el servidor aceptó.

Cuándo usarlo

Handshakes de WebSocket es el caso dominante hoy. Tras 101 la conexión deja de ser HTTP.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 101 Switching Protocols
200 OK #

Respuesta estándar de éxito — la petición se atendió y el cuerpo lleva la representación pedida. RFC 9110 §15.3.1.

Causa común

La petición es válida, autorizada y se completó sin redirigir.

Cuándo usarlo

GETs que devuelven datos, POSTs/PUTs procesados al instante, respuestas sanas de API.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 200 OK
201 Created #

La petición tuvo éxito y se creó un recurso nuevo. El header Location DEBERÍA apuntar al recurso creado. RFC 9110 §15.3.2.

Causa común

Un POST o PUT creó un recurso (fila en BD, archivo, usuario, etc.).

Cuándo usarlo

Tras crear recursos REST. Devuelve la representación en el cuerpo y Location en la cabecera.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 201 Created
202 Accepted #

La petición se aceptó para procesar pero aún no se ha completado. El procesamiento puede acabar fallando. RFC 9110 §15.3.3.

Causa común

Procesamiento asíncrono encolado. El trabajo se hace después.

Cuándo usarlo

Jobs en segundo plano, importación por lotes, cualquier cosa que devuelva una URL de estado mientras corre.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 202 Accepted
204 No Content #

La petición tuvo éxito; la respuesta no lleva cuerpo a propósito. Las cabeceras pueden traer metadatos. RFC 9110 §15.3.5.

Causa común

Una actualización o borrado que no necesita devolver representación.

Cuándo usarlo

Respuestas DELETE, PUT/PATCH donde el cliente ya tiene la nueva representación, endpoints save-and-stay.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 204 No Content
206 Partial Content #

El servidor devolvió solo parte de la representación en respuesta a una petición con Range. RFC 9110 §15.3.7.

Causa común

El cliente pidió un rango de bytes con la cabecera Range.

Cuándo usarlo

Descargas reanudables, streaming de vídeo con seek y descargas en trozos paralelos.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 206 Partial Content
301 Moved Permanently #

El recurso destino tiene un nuevo URI permanente. Los clientes DEBERÍAN actualizar marcadores y los buscadores el índice. RFC 9110 §15.4.2.

Causa común

Cambio de URL canónica — renombrado de dominio, slug, migración a HTTPS.

Cuándo usarlo

Redirecciones de largo plazo. Evita 301 para redirecciones cortas por la cacheo agresivo.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 301 Moved Permanently
302 Found #

El recurso reside temporalmente en otro URI. Los clientes deberían pedir el nuevo URI sin cambiar el método, pero históricamente reescriben POST a GET. RFC 9110 §15.4.3.

Causa común

Redirección temporal con comportamiento de cambio de método heredado, mantenido por compatibilidad.

Cuándo usarlo

Código legado. En APIs nuevas prefiere 303 o 307 para evitar ambigüedad.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 302 Found
303 See Other #

Redirige a un recurso que debe obtenerse con GET, sea cual sea el método original. RFC 9110 §15.4.4.

Causa común

Tras un POST no idempotente, el servidor envía al cliente a una página de confirmación o al recurso recién creado.

Cuándo usarlo

Patrón Post/Redirect/Get. Siempre reescribe a GET, ideal tras enviar un formulario.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 303 See Other
304 Not Modified #

La representación cacheada por el cliente sigue siendo válida; no se envía cuerpo. RFC 9110 §15.4.5.

Causa común

El cliente envió If-None-Match o If-Modified-Since y los validadores coincidieron con el recurso actual.

Cuándo usarlo

Respuestas condicionales para cacheo. Ahorra ancho de banda en estáticos y APIs sin cambios.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 304 Not Modified
307 Temporary Redirect #

Como 302, pero conserva explícitamente método y cuerpo. RFC 9110 §15.4.8.

Causa común

Redirección breve en que el POST/PUT original debe reproducirse en el nuevo URI.

Cuándo usarlo

Redirecciones de mantenimiento, enrutado A/B o geográfico que deben preservar el método.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 307 Temporary Redirect
308 Permanent Redirect #

Como 301, pero conserva explícitamente método y cuerpo. RFC 9110 §15.4.9.

Causa común

Cambio canónico de URI para métodos no-GET (upgrade a HTTPS para APIs POST, renombrado de ruta).

Cuándo usarlo

Redirecciones permanentes en APIs REST. Usa en vez de 301 cuando no se debe reescribir el método.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 308 Permanent Redirect
400 Bad Request #

El servidor no puede procesar la petición por error del cliente: sintaxis incorrecta, framing inválido, enrutado engañoso. RFC 9110 §15.5.1.

Causa común

JSON roto, campo obligatorio ausente, cabecera mal formada, cookie demasiado grande.

Cuándo usarlo

Error genérico de cliente. Prefiere códigos más específicos (422, 411, 415) cuando apliquen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 400 Bad Request
401 Unauthorized #

La petición carece de credenciales válidas. La respuesta DEBE incluir WWW-Authenticate con los esquemas aceptados. RFC 9110 §15.5.2.

Causa común

Token ausente, expirado o inválido; falta de header Authorization donde se exige.

Cuándo usarlo

Endpoints tras autenticación. Distinto de 403 — 401 es "no autenticado", 403 es "autenticado pero sin permiso".

curl -i -X HEAD https://example.com/path
# HTTP/1.1 401 Unauthorized
403 Forbidden #

El servidor entendió la petición pero se niega a autorizarla. RFC 9110 §15.5.4.

Causa común

Usuario autenticado sin permiso o recurso bloqueado por IP/región.

Cuándo usarlo

Errores de autorización, listas de IP, control basado en roles.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 403 Forbidden
404 Not Found #

El servidor no halla representación actual del recurso. Puede usarse para ocultar un 403. RFC 9110 §15.5.5.

Causa común

URL mal escrita, recurso eliminado o que nunca existió.

Cuándo usarlo

Respuesta por defecto para rutas y recursos ausentes. Se cachea menos agresivamente que 410.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 404 Not Found
405 Method Not Allowed #

El método no se admite en el recurso. La respuesta DEBE incluir Allow con los métodos soportados. RFC 9110 §15.5.6.

Causa común

DELETE en una colección de solo lectura, POST en un recurso singleton, etc.

Cuándo usarlo

APIs REST que quieren ser explícitas sobre los verbos permitidos.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 405 Method Not Allowed
406 Not Acceptable #

El servidor no puede producir representación compatible con las cabeceras Accept-*. RFC 9110 §15.5.7.

Causa común

El cliente pidió application/xml pero solo hay application/json.

Cuándo usarlo

Negociación estricta de contenido. Muchas APIs devuelven JSON por defecto en lugar de 406.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 406 Not Acceptable
408 Request Timeout #

El servidor dejó de esperar a que el cliente completara la petición. RFC 9110 §15.5.9.

Causa común

Conexión lenta, subida a medias, keep-alive inactivo más allá del timeout.

Cuándo usarlo

Proxies inversos y balanceadores frente a clientes lentos.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 408 Request Timeout
409 Conflict #

La petición entra en conflicto con el estado actual del recurso. RFC 9110 §15.5.10.

Causa común

Dos clientes editan el mismo registro a la vez; violación de unicidad; PUT con ETag desfasado.

Cuándo usarlo

Control de concurrencia optimista, creación idempotente.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 409 Conflict
410 Gone #

El recurso se eliminó intencionadamente y no volverá. RFC 9110 §15.5.11.

Causa común

Contenido borrado de forma permanente; endpoint de API descontinuado.

Cuándo usarlo

Páginas retiradas en las que quieres que los crawlers retiren el URL antes que con 404.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 410 Gone
411 Length Required #

La petición carece de Content-Length cuando el servidor lo exige. RFC 9110 §15.5.12.

Causa común

Cliente en streaming que no buferizó el cuerpo ni usó chunked transfer encoding.

Cuándo usarlo

Servidores que prohíben subidas chunked en ciertos endpoints.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 411 Length Required
413 Content Too Large #

El cuerpo es mayor de lo que el servidor admite. RFC 9110 §15.5.14. Renombrado de "Payload Too Large" en RFC 9110.

Causa común

Subida por encima del límite configurado, archivo más allá del tamaño máximo del formulario.

Cuándo usarlo

Endpoints de subida, APIs JSON con tope de cuerpo.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 413 Content Too Large
414 URI Too Long #

El URI de la petición es más largo de lo que el servidor admite interpretar. RFC 9110 §15.5.15.

Causa común

Query strings enormes (a menudo de formularios enviados con method=GET) o tokens embebidos en la URL.

Cuándo usarlo

Cuando los usuarios golpean el endpoint con URLs anormalmente largas — pasa el formulario a POST.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 414 URI Too Long
415 Unsupported Media Type #

El servidor rechaza el cuerpo en el formato descrito por Content-Type. RFC 9110 §15.5.16.

Causa común

Enviar application/xml a un endpoint solo JSON, o Content-Type incorrecto/ausente.

Cuándo usarlo

APIs REST que aceptan estrictamente uno o dos media types.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 415 Unsupported Media Type
418 I’m a teapot #

Broma de inocentes de la RFC 2324 (HTCPCP). Algunos servidores lo devuelven como error genérico de "me niego". No es status real de producción.

Causa común

Software que devuelve 418 a propósito, en trampas anti-abuso o easter eggs.

Cuándo usarlo

Solo easter eggs. No usar en APIs reales — muchos proxies y clientes no lo reconocen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 418 I’m a teapot
422 Unprocessable Content #

La sintaxis está bien pero el servidor no puede procesar el contenido semántico. RFC 9110 §15.5.21. Originalmente en WebDAV (RFC 4918).

Causa común

Errores de validación sobre un payload JSON estructuralmente válido — campo obligatorio vacío, valor fuera de rango.

Cuándo usarlo

Validación de formularios en APIs modernas. Más limpio que 400 porque la petición es sintácticamente válida.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 422 Unprocessable Content
423 Locked #

El recurso está bloqueado. RFC 4918 (WebDAV).

Causa común

Recurso WebDAV con un lock exclusivo de otro usuario.

Cuándo usarlo

Servidores de colaboración documental, frontends de control de versiones.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 423 Locked
425 Too Early #

El servidor no quiere procesar una petición que pueda repetirse, normalmente porque viajó en TLS 1.3 0-RTT (early data). RFC 8470.

Causa común

Petición en TLS 1.3 0-RTT que el servidor considera insegura para replay.

Cuándo usarlo

Proteger endpoints no idempotentes frente a replays durante handshakes 0-RTT.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 425 Too Early
428 Precondition Required #

El servidor de origen exige que la petición sea condicional. RFC 6585.

Causa común

El servidor quiere que los clientes usen If-Match / If-Unmodified-Since para evitar conflictos de actualización perdida.

Cuándo usarlo

APIs con bloqueo optimista que rechazan escrituras incondicionales.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 428 Precondition Required
429 Too Many Requests #

El usuario ha enviado demasiadas peticiones en un intervalo. RFC 6585.

Causa común

Límite de tasa alcanzado; la respuesta suele incluir Retry-After.

Cuándo usarlo

APIs con rate limit, throttling de login, mitigación de abuso.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 429 Too Many Requests
431 Request Header Fields Too Large #

El servidor rechaza la petición porque las cabeceras son demasiado grandes. RFC 6585.

Causa común

Cookie desmedida, Referer o Authorization muy largos.

Cuándo usarlo

Cuando las cookies de sesión crecen más allá del buffer del proxy inverso; recórtalas o mueve estado al cuerpo.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 431 Request Header Fields Too Large
451 Unavailable For Legal Reasons #

El recurso no está disponible por razones legales — orden de retirada, bloqueo geográfico o DMCA. RFC 7725.

Causa común

Orden judicial, retirada regulatoria, respuesta a derecho de borrado del RGPD.

Cuándo usarlo

Equipos de cumplimiento que necesitan ser transparentes con el motivo del bloqueo.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 451 Unavailable For Legal Reasons
500 Internal Server Error #

El servidor encontró una condición inesperada que le impidió completar la petición. RFC 9110 §15.6.1.

Causa común

Excepción no controlada, bug, dependencia rota, consulta desbocada.

Cuándo usarlo

Cajón de sastre. Registra siempre stack trace e ID de petición para que los usuarios lo citen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 500 Internal Server Error
501 Not Implemented #

El servidor no admite la funcionalidad necesaria para atender la petición. RFC 9110 §15.6.2.

Causa común

Método desconocido, feature flag deshabilitada, ruta sin implementar.

Cuándo usarlo

Endpoints existentes pero aún no construidos. Prefiere 405 si otros métodos funcionan.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 501 Not Implemented
502 Bad Gateway #

El gateway o proxy recibió respuesta inválida del servidor upstream. RFC 9110 §15.6.3.

Causa común

El upstream devolvió HTTP malformado, la conexión cayó a mitad de respuesta o la aplicación reventó.

Cuándo usarlo

Proxies inversos (Nginx, Cloudflare, ALB) cuando la aplicación detrás falla.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 502 Bad Gateway
503 Service Unavailable #

El servidor no puede atender la petición ahora, normalmente por mantenimiento o sobrecarga. RFC 9110 §15.6.4.

Causa común

Ventana de mantenimiento, cola llena, autoscaler retrasado, brown-out deliberado.

Cuándo usarlo

Indisponibilidad planificada o protección frente a sobrecarga. Define siempre Retry-After para que el cliente reculée.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 503 Service Unavailable
504 Gateway Timeout #

El gateway o proxy no recibió respuesta a tiempo del servidor upstream. RFC 9110 §15.6.5.

Causa común

El upstream tardó más que el timeout configurado en el proxy.

Cuándo usarlo

Código lento, consultas atascadas, APIs externas colgadas.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 504 Gateway Timeout
505 HTTP Version Not Supported #

El servidor no admite la versión mayor de HTTP de la petición. RFC 9110 §15.6.6.

Causa común

Cliente que habla HTTP/2 a un servidor que solo maneja HTTP/1.0, o envía un token de versión desconocido.

Cuándo usarlo

Raro en la práctica. Bordes mal configurados o clientes muy antiguos.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 505 HTTP Version Not Supported
511 Network Authentication Required #

El cliente debe autenticarse para usar la red — típicamente un portal cautivo. RFC 6585.

Causa común

Wi-Fi de hotel o aeropuerto interceptando el tráfico hasta el login.

Cuándo usarlo

Portales cautivos en redes de paso. Los servidores normalmente no lo devuelven por sí mismos.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 511 Network Authentication Required

¿Qué son los códigos de estado HTTP?

Un código de estado HTTP es el número de tres dígitos que el servidor devuelve al inicio de cada respuesta. Se agrupan en cinco familias: 1xx informativo, 2xx éxito, 3xx redirección, 4xx error de cliente y 5xx error de servidor. Los códigos están definidos en la RFC 9110 (la especificación consolidada de 2022 que reemplaza la serie 7230–7235), con extensiones en la RFC 6585 (4xx/5xx adicionales), RFC 7725 (451), RFC 4918 (WebDAV) y RFC 8470 (425). Leer bien el estado es la diferencia entre corregir un bug en cinco minutos y perseguir un fantasma toda la tarde: un 404 del CDN indica que la ruta es errónea, un 502 del proxy indica que la aplicación cayó y un 401 sin WWW-Authenticate es un backend mal configurado. Esta página es una chuleta buscable — cada tarjeta incluye el nombre oficial, descripción basada en la RFC, causa típica y fragmentos listos para pegar en curl, Python, JavaScript o PHP.

Cómo usar la referencia

Escribe un código o parte de un nombre en la búsqueda, o filtra por familia con los chips. Cada tarjeta se abre y muestra la descripción técnica, causas comunes y un snippet por pestañas adaptable. Cada código tiene su propio ancla (p. ej. #404) para enlazar la documentación de tu equipo a un estado concreto.

Familias de estado de un vistazo

Rango Familia Significado
1xxInformativoRespuestas provisionales; rara vez se ven en la capa de aplicación.
2xxÉxitoLa petición se recibió, entendió y aceptó.
3xxRedirecciónHace falta una acción adicional (URL distinta, validación de caché, etc.).
4xxError de clienteLa petición tuvo un problema (entrada incorrecta, sin auth, método equivocado).
5xxError de servidorEl servidor no pudo cumplir una petición aparentemente válida.

Preguntas frecuentes

¿De dónde salen estos códigos?
La RFC 9110 es la especificación canónica de 2022 que consolida la serie RFC 7231. Los códigos adicionales están en RFC 6585 (428, 429, 431, 511), RFC 7725 (451), RFC 4918 (WebDAV) y RFC 8470 (425).
¿Uso 401 o 403?
401 significa "no estás autenticado". 403 significa "estás autenticado pero no tienes permiso". El 401 debe incluir cabecera WWW-Authenticate con esquemas aceptados; el 403 no debería porque las credenciales no son el problema.
¿Diferencia entre 301 y 308?
Ambos indican redirección permanente. El 301 históricamente reescribe POST a GET en muchos clientes; el 308 conserva método y cuerpo. Usa 308 en APIs nuevas.
¿Cuándo devuelve mi CDN 502 frente a 504?
502 (Bad Gateway) significa que el upstream devolvió datos malformados o cerró la conexión. 504 (Gateway Timeout) significa que el upstream tardó demasiado. CloudFront, Cloudflare y Nginx los etiquetan distinto en los logs — ambos indican un problema en la aplicación.
¿404 o 410 para contenido borrado?
Usa 410 cuando el recurso se retiró a propósito y de forma permanente y quieres que los crawlers lo descarten rápido. 404 sirve para erratas o contenido que puede volver; también es una respuesta defendible cuando no quieres confirmar la existencia del recurso.
¿Es seguro copiar los fragmentos?
Son plantillas mínimas para leer y adaptar. Valida entradas, trata errores y respeta la semántica HTTP en tu código real — los ejemplos se la saltan por brevedad.