ToolActToolAct

Consulta de Códigos de Estado HTTP

Referencia rápida de códigos de estado HTTP con descripciones

Todos: 62 个状态码

1xx Información(4)

100Continue

Continuar. Cliente debe continuar enviando el resto de la solicitud.

101Switching Protocols

Cambiando protocolos. El servidor entiende y cambiará a otro protocolo.

102Processing

Procesando. Servidor recibió la solicitud y está procesando.

103Early Hints

Pistas tempranas. Devuelve headers antes de la respuesta final.

2xx Éxito(10)

200OK

Éxito. Solicitud procesada correctamente.

201Created

Creado. Solicitud exitosa y nuevo recurso creado. Común para POST.

202Accepted

Aceptado. Solicitud aceptada pero no completada aún.

203Non-Authoritative Information

Información no autoritativa. Información puede ser de terceros.

204No Content

Sin contenido. Solicitud exitosa sin cuerpo de respuesta. Común para DELETE.

205Reset Content

Restablecer contenido. Cliente debe restablecer vista del documento.

206Partial Content

Contenido parcial. Servidor entregó contenido parcial. Para descargas.

207Multi-Status

Multi-estado. Múltiples códigos en respuesta (WebDAV).

208Already Reported

Ya reportado. Enlaces DAV ya listados antes (WebDAV).

226IM Used

IM Usado. Servidor completó GET usando manipulación de instancia.

3xx Redirección(8)

300Multiple Choices

Múltiples opciones. Varias representaciones disponibles.

301Moved Permanently

Movido permanentemente. Usar nueva URL permanentemente.

302Found

Encontrado. Recurso temporalmente en otra URL.

303See Other

Ver otro. Usar GET para obtener recurso de otra URL.

304Not Modified

No modificado. Usar versión en caché.

305Use Proxy

Usar proxy (obsoleto).

307Temporary Redirect

Redirección temporal con mismo método y cuerpo.

308Permanent Redirect

Redirección permanente con mismo método.

4xx Error Cliente(29)

400Bad Request

Solicitud incorrecta. Servidor no puede entender el formato.

401Unauthorized

No autorizado. Requiere autenticación.

402Payment Required

Pago requerido. Reservado para uso futuro.

403Forbidden

Prohibido. Servidor entiende pero rechaza autorizar.

404Not Found

No encontrado. Recurso no existe. Código más común.

405Method Not Allowed

Método no permitido. Método no soportado.

406Not Acceptable

No aceptable. No puede devolver contenido según header Accept.

407Proxy Authentication Required

Autenticación proxy requerida.

408Request Timeout

Tiempo de espera agotado. Servidor esperó demasiado.

409Conflict

Conflicto. Solicitud conflictúa con estado del servidor.

410Gone

Eliminado. Recurso eliminado permanentemente.

411Length Required

Longitud requerida. Falta header Content-Length.

412Precondition Failed

Precondición fallida. Headers condicionales no cumplidos.

413Payload Too Large

Carga útil demasiado grande.

414URI Too Long

URI demasiado larga.

415Unsupported Media Type

Tipo de medio no soportado.

416Range Not Satisfiable

Rango no satisfactorio.

417Expectation Failed

Expectativa fallida. Header Expect no cumplido.

418I'm a teapot

Soy una tetera. Código de bromas RFC 2324.

421Misdirected Request

Solicitud mal dirigida. Enviada a servidor incorrecto.

422Unprocessable Entity

Entidad no procesable. Sintaxis correcta pero errores semánticos.

423Locked

Bloqueado. Recurso bloqueado (WebDAV).

424Failed Dependency

Dependencia fallida. Solicitud anterior falló (WebDAV).

425Too Early

Demasiado temprano. El servidor no está dispuesto a procesar.

426Upgrade Required

Actualización requerida. Cambiar a TLS.

428Precondition Required

Precondición requerida. Necesita headers condicionales.

429Too Many Requests

Demasiadas solicitudes. Límite de tasa excedido.

431Request Header Fields Too Large

Headers de solicitud demasiado grandes.

451Unavailable For Legal Reasons

No disponible por razones legales.

5xx Error Servidor(11)

500Internal Server Error

Error interno del servidor. Condición inesperada.

501Not Implemented

No implementado. Funcionalidad no soportada.

502Bad Gateway

Gateway incorrecto. Respuesta inválida del upstream.

503Service Unavailable

Servicio no disponible. Servidor temporalmente no puede manejar solicitud.

504Gateway Timeout

Tiempo de espera de gateway agotado.

505HTTP Version Not Supported

Versión HTTP no soportada.

506Variant Also Negotiates

Variante también negocia. Error de configuración.

507Insufficient Storage

Almacenamiento insuficiente. No puede almacenar recurso (WebDAV).

508Loop Detected

Bucle detectado (WebDAV).

510Not Extended

No extendido. Requiere extensiones adicionales.

511Network Authentication Required

Autenticación de red requerida.

¿Qué son los códigos HTTP?

La herramienta de códigos de estado HTTP explica las respuestas que un servidor devuelve a un navegador, rastreador, aplicación o cliente API después de una solicitud. Los códigos 2xx suelen indicar éxito, los 3xx redirección, los 4xx problemas del cliente y los 5xx fallos del servidor, pero los matices importan. Un 401 no equivale a un 403, un 404 no significa lo mismo que un 410, y un 301 tiene implicaciones SEO distintas a un 302. Esta referencia ayuda a desarrolladores, equipos de soporte y responsables de sitios a interpretar errores y decidir la siguiente comprobación.

Cómo usar

Referencia rápida

  1. Haz clic en cualquier tarjeta de código de estado para copiarla
  2. Usa el cuadro de búsqueda para encontrar rápidamente códigos específicos
  3. Haz clic en las etiquetas de categoría para filtrar por tipo de estado
  4. Pasa el cursor sobre los códigos para ver descripciones detalladas

Notas de depuración

  • Lee primero la familia del estado: 2xx éxito, 3xx redirección, 4xx problema del cliente, 5xx problema del servidor.
  • Para depurar una API, combina el código de estado con el cuerpo de la respuesta, los encabezados, el método de solicitud y los registros del servidor; el código por sí solo rara vez explica el problema completo.

Casos de uso

Consultar un código de estado mientras se depura una APIBusca por número, nombre o descripción y filtra por informativo, éxito, redirección, error de cliente o error de servidor para comprender una respuesta sin abrir una referencia separada. Cada tarjeta de código incluye la familia IETF y una breve descripción, que suele ser suficiente para elegir el siguiente paso de depuración antes de consultar una referencia más profunda.
Copiar códigos en tickets y respuestas de soporteHaz clic en una tarjeta de estado para copiar el código numérico al redactar informes de errores, logs, explicaciones al cliente, reglas de gateway o anotaciones de monitorización. Copia el código con una breve explicación para que el ticket conserve el contexto HTTP.
Separar clases de fallo del lado cliente y del lado servidorUsa la disposición agrupada para distinguir los problemas de solicitud 4xx de los problemas de backend 5xx, y el comportamiento de redirección 3xx de las respuestas exitosas 2xx. Esto ayuda a dirigir los incidentes al responsable adecuado antes de iniciar un análisis de logs más profundo.
Verificar un código con su definición RFC del IETF antes de citarloAbre la tarjeta detallada del código en cuestión para comprobar si la redacción del RFC del IETF coincide con tu interpretación, especialmente para pares matizados como 401 vs. 403, 404 vs. 410, o 301 vs. 308. La misma precaución vale para códigos más recientes como 425 Too Early, 451 Unavailable For Legal Reasons o 421 Misdirected Request, que se comportan de forma diferente en las pilas HTTP/2 y HTTP/3 que los clásicos 4xx y 3xx. Ten en cuenta que el RFC 9110, el registro actual de semántica HTTP, desaconseja 305 Use Proxy y 306, reclasifica 418 como código de broma y reorganiza los 1xx de modo que 100 Continue y 101 Switching Protocols son los únicos que un navegador o proxy debe implementar; 102, 103 y las extensiones WebDAV son opcionales y rara vez los muestran los nodos de borde CDN.
Usar listas agrupadas al revisar paneles de monitorizaciónExplora los grupos de redirección, error de cliente y error de servidor en una sola vista al explicar picos a compañeros, elegir umbrales de alerta o decidir qué clases de respuesta merecen entradas de runbook separadas. Cuando aparece un pico de 429, captura el valor del header Retry-After por separado en lugar de tratar todos los 4xx igual, ya que Retry-After es el contrato que el servidor ofrece a los clientes y es el único campo que distingue una respuesta de límite de tasa correcta de una que se comporta mal.

Principio técnico

Los códigos de estado HTTP son enteros de 3 dígitos devueltos en la línea de inicio de la respuesta, definidos por la especificación de semántica HTTP. La referencia normativa actual es RFC 9110 (HTTP Semantics, junio 2022), que obsoleta la serie anterior RFC 7231, con extensiones en RFC 9111 (Caching), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2) y RFC 9114 (HTTP/3). El primer dígito define la clase de respuesta, por lo que los códigos no reconocidos aún tienen un manejo predecible: 1xx informativo (interino, la respuesta final sigue), 2xx exitoso, 3xx redirección (se requiere acción adicional del agente de usuario), 4xx error del cliente (la solicitud está mal formada o no puede cumplirse) y 5xx error del servidor. Las cachés y los intermediarios deben tratar los códigos desconocidos como el código genérico de clase x00 (por ejemplo, un 4xx desconocido se maneja como 400), lo que hace que la familia de estados sea significativa incluso para códigos propietarios o de extensión. Los códigos de redirección llevan semántica de preservación de método que históricamente divergió de la intención. La sección RFC 9110 §15.4 hace explícita la distinción: 301 Moved Permanently y 302 Found pueden reescribir un POST a un GET (el comportamiento de facto en el que todos los navegadores se asentaron a finales de los años 90, codificado en RFC 7231); 307 Temporary Redirect y 308 Permanent Redirect requieren que el agente de usuario repita el mismo método y cuerpo. Las herramientas SEO típicamente transfieren el peso equivalente a PageRank en 301 y 308 y tratan 302/307 como preservadores de la señal de la URL original. Los códigos condicionales 304 Not Modified y 412 Precondition Failed dependen de las cabeceras If-None-Match / If-Modified-Since / ETag / Last-Modified de la solicitud, y 206 Partial Content responde a una cabecera Range con una cabecera Content-Range y un cuerpo multipart/byteranges cuando se solicitan múltiples rangos. Las clases 4xx y 5xx llevan detalles de contrato en las cabeceras. 401 Unauthorized debe incluir un desafío WWW-Authenticate que liste los esquemas aceptados (Bearer, Basic, Digest, Negotiate); sin esto la respuesta está técnicamente mal formada. 405 Method Not Allowed debe incluir una cabecera Allow que liste los métodos soportados. 429 Too Many Requests, 503 Service Unavailable y 301/307/308 con Retry-After permiten al servidor señalar un retraso ya sea en segundos (Retry-After: 120) o como una fecha HTTP (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) según RFC 9110 §10.2.3. RFC 9110 obsoleta 305 Use Proxy y 306 (reservado/sin uso), mantiene 418 I'm a teapot como el código de broma documentado RFC 2324 / RFC 7168, y reorganiza los 1xx de modo que solo 100 Continue y 101 Switching Protocols son obligatorios en la capa HTTP/1.1; 102 Processing y 103 Early Hints (RFC 8297) son extensiones opcionales que se manifiestan principalmente a través de la lógica de borde de CDN.

  • Referencia normativa: RFC 9110 (HTTP Semantics, junio 2022) obsoleta RFC 7230-7235; las extensiones viven en RFC 9111 (Caching), 9112 (formato de transmisión HTTP/1.1), 9113 (HTTP/2), 9114 (HTTP/3).
  • Códigos desconocidos degradan al código de clase (x00): un 4xx desconocido se cachea y renderiza como 400, un 5xx desconocido como 500 - esto es lo que hace del primer dígito un contrato.
  • Preservación de método: 301/302 históricamente permiten la reescritura POST → GET (codificada tras la divergencia de navegadores de principios de los 90); 307/308 requieren que el mismo método y cuerpo se reenvíen - usa 308 para movimientos permanentes de endpoints API.
  • 401 Unauthorized debe llevar WWW-Authenticate; 405 Method Not Allowed debe llevar Allow; la ausencia de estas cabeceras es una violación de la especificación que rompe clientes HTTP bien implementados.
  • Retry-After (RFC 9110 §10.2.3) en 429/503/301/307/308: acepta tanto segundos delta (Retry-After: 120) como fecha HTTP (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) - los clientes deben analizar ambas formas.
  • Caché condicional: 304 Not Modified responde a coincidencias de If-None-Match / If-Modified-Since sin cuerpo; 206 Partial Content responde a Range con Content-Range y ya sea el cuerpo parcial o un documento multipart/byteranges.
  • RFC 9110 obsoleta 305 Use Proxy y 306 (reservado), preserva 418 I'm a teapot de RFC 2324 / RFC 7168 como una broma, y trata 102 Processing / 103 Early Hints (RFC 8297) como extensiones 1xx opcionales que muchos proxies eliminan.

Ejemplos

2xx Éxito - 200 OK y 204 No Content

200 OK            GET /api/users -> se devuelve cuerpo de respuesta
201 Created       POST /api/posts -> nuevo recurso en la cabecera Location
204 No Content    DELETE /api/posts/42 -> éxito, cuerpo vacío
206 Partial       Solicitud Range para streaming de video o descargas reanudables

RFC: RFC 7231 sección 6.3 define los códigos de éxito 2xx

3xx Redirecciones - 301 vs 302 vs 304

301 Moved Permanently  -> seguro para SEO, los navegadores almacenan en caché la nueva URL para siempre
302 Found              -> redirección temporal, no almacenar en caché el destino
304 Not Modified       -> la copia en caché sigue vigente (coincidencia de ETag/Last-Modified)
307 Temporary Redirect -> como 302 pero el método NO debe cambiar (POST sigue siendo POST)
308 Permanent Redirect -> como 301 pero preserva el método de la solicitud

RFC: RFC 7231 sección 6.4 define los códigos de redirección 3xx
RFC: RFC 7232 sección 4.1 define la semántica de 304 Not Modified

4xx Errores del cliente - autenticación vs permisos

400 Bad Request    JSON mal formado, falta un campo requerido
401 Unauthorized   Token ausente o no válido - el llamador debe autenticarse
403 Forbidden      Autenticado pero sin permiso para acceder a este recurso
404 Not Found      El recurso no existe (o pretendemos que no existe, por seguridad)
409 Conflict       Clave duplicada, desfase de versión en bloqueo optimista
429 Too Many Reqs  Límite de tasa alcanzado - ver cabecera Retry-After

RFC: RFC 7231 sección 6.5 define los códigos de error 4xx del cliente
RFC: RFC 6585 sección 4 define 429 Too Many Requests

5xx Errores del servidor - depurando un upstream

500 Internal Server Error  Excepción no manejada en el código de la app - revisa los logs
502 Bad Gateway            Nginx/upstream recibió una respuesta no válida del backend
503 Service Unavailable    Mantenimiento, sobrecarga o app arrancando
504 Gateway Timeout        El upstream no respondió dentro del timeout del proxy

RFC: RFC 7231 sección 6.6 define los códigos de error 5xx del servidor
Diagnóstico rápido: 5xx = culpa nuestra, 4xx = culpa del llamador

Sesión real de curl mostrando varios códigos

$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page

$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"

$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json

Nota: 422 Unprocessable Entity es una extensión WebDAV (RFC 4918) usada para errores de validación

Preguntas frecuentes

¿Qué significan las clases 1xx, 2xx, 3xx, 4xx y 5xx?

1xx es informativo (raro en la práctica). 2xx significa que la petición tuvo éxito. 3xx es redirección: el cliente debería ir a otra URL. 4xx es problema del cliente (petición errónea, falta de auth, recurso inexistente). 5xx es problema del servidor (la petición se veía bien pero el servidor no pudo cumplirla). Al leer una línea de log, mira siempre primero la clase.

¿Cuál es la diferencia entre 301 y 302?

301 Moved Permanently dice a clientes y buscadores que el recurso se mudó de forma permanente: los navegadores cachean la redirección con fuerza y el SEO transfiere el «link equity» a la nueva URL. 302 Found es una redirección temporal; los clientes no deberían cachearla a largo plazo. Usa 308 para redirecciones permanentes cuando debas conservar el método HTTP, y 307 para temporales bajo la misma restricción.

¿Cuándo devuelvo 401 frente a 403?

401 Unauthorized significa que el cliente no se autenticó o las credenciales que envió son inválidas; la respuesta debería incluir una cabecera WWW-Authenticate. 403 Forbidden significa que el servidor sabe quién es el cliente y se niega a servir el recurso de todos modos. Hacer login arregla el 401; hacer login no arregla el 403.

¿Debería usar 404 o 410 para recursos que ya no existen?

404 Not Found significa «no lo encuentro; podría existir en algún sitio o volver más tarde». 410 Gone significa «este recurso estaba aquí, se eliminó intencionadamente, no lo busques de nuevo». Los buscadores quitan las URLs 410 del índice más rápido que las 404, así que 410 es la elección correcta para páginas retiradas que no quieres que vuelvan a rastrearse.

¿Cómo debo leer un código de estado al depurar una API?

Lee primero la clase (4xx vs 5xx te dice de qué lado mirar), luego el código concreto y luego el cuerpo de la respuesta. El cuerpo suele llevar el mensaje de error real y un código interno; el estado HTTP es solo la categoría. Inspecciona siempre cabeceras como Retry-After, WWW-Authenticate y Location junto al estado.

¿Los códigos no-2xx perjudican el SEO?

Algunos sí, otros no. Las respuestas 5xx prolongadas indican un sitio poco fiable y los buscadores acabarán reduciendo la frecuencia de rastreo. Las redirecciones 301/308 transmiten link equity; 302/307 no. 410 saca páginas del índice; los 404 aguantan más tiempo. Un 200 con un cuerpo de soft-404 (una página real de «no encontrado» que devuelve 200) es peor para SEO que un 404 real, porque llena el índice de páginas vacías.

¿Para qué sirven el 418, el 451 y otros códigos poco habituales?

418 «I'm a teapot» es el famoso código del April Fools de la RFC 2324: ningún servicio real debería devolverlo en producción. 451 Unavailable For Legal Reasons indica que el recurso está bloqueado por una orden legal (en honor a Fahrenheit 451 de Bradbury). 429 Too Many Requests señala límite de tasa y debería ir acompañado de una cabecera Retry-After. 503 Service Unavailable es el código adecuado para mantenimiento programado.