🌐 Web

Códigos de estado HTTP

Significado y diferencias de los códigos de respuesta HTTP del rango 100 al 500
Leer los datos

Lee los códigos de estado HTTP por grupos de centenas

Los códigos de estado HTTP son respuestas estándar que indican cómo ha gestionado el servidor una solicitud. Entender primero el significado de los grupos 1xx, 2xx, 3xx, 4xx y 5xx ayuda a distinguir con más facilidad errores concretos como 404, 429, 451 y 500.

Cómo leerla

Busca por número de código, nombre en inglés, descripción en español o palabras clave relacionadas, y acota el alcance con filtros por grupo de centenas o por códigos destacados/especiales. Al pulsar un número de código, saltarás directamente a esa fila.

Qué muestra esta página
  • Códigos registrados y reason phrases estándar según el HTTP Status Code Registry de IANA
  • Significado por clase de centenas, situaciones habituales, puntos a revisar y códigos relacionados
  • Explicaciones detalladas de códigos muy buscados como 451, 429, 404, 500 y 503
Base de los datos

Se organiza con base en el IANA HTTP Status Code Registry y documentos de IETF como RFC 9110, RFC 7725 y RFC 6585.

Esta página es una referencia sobre el significado del protocolo HTTP; para decisiones legales, de seguridad u operativas, revisa también el entorno de cada servicio y su documentación oficial.

Códigos registrados 64
Clases de estado 5
Códigos destacados 25
Códigos especiales 21
1xx Informativo 5 2xx Correcto 10 3xx Redirección 9 4xx Error de cliente 29 5xx Error de servidor 11
103 Early Hints 200 OK 206 Partial Content 301 Moved Permanently 302 Found 304 Not Modified 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 410 Gone 413 Content Too Large 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Content 425 Too Early 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 511 Network Authentication Required
🌐 Lista completa de códigos de estado HTTP
64 códigos en total

1xx Informativo

Respuestas intermedias que indican que la solicitud se recibió y que el procesamiento continúa.

5
Significado Situación principal Qué revisar
100 Continue RFC 9110 El servidor recibió los encabezados de la solicitud y el cliente puede seguir enviando el cuerpo. Se usa cuando un servidor confirma si puede continuar una solicitud con un cuerpo grande antes de que el cliente lo envíe. Revise el encabezado Expect: 100-continue y el flujo de manejo de cargas del servidor. Relacionado: 417
101 Switching Protocols RFC 9110 El servidor aceptó el cambio de protocolo solicitado por el cliente. Se ve cuando una conexión HTTP se actualiza a otro protocolo, como WebSocket. Revise el encabezado Upgrade, el encabezado Connection y si los proxies reenvían correctamente la actualización. Relacionado: 426
102 Processing RFC 2518 La solicitud se recibió y sigue en procesamiento, pero la respuesta final aún no está lista. Puede usarse en solicitudes WebDAV de larga duración para reducir el riesgo de timeout del cliente. Compruebe si llega una respuesta final por separado y si el cliente ignora de forma segura las respuestas intermedias. Relacionado: 207, 208
104 Temporal Upload Resumption Supported IANA temporary registration Un código de estado registrado temporalmente que indica soporte para reanudar cargas. Puede aparecer en flujos experimentales que negocian la reanudación por rangos después de interrumpirse una carga grande. Como es un registro temporal de IANA, confirme el soporte de cliente y servidor antes de usarlo en producción. Relacionado: 100, 201

2xx Correcto

Respuestas que indican que la solicitud se entendió y se procesó correctamente.

10
Significado Situación principal Qué revisar
200 OK RFC 9110 La solicitud tuvo éxito y el cuerpo de la respuesta contiene el resultado. Se usa en la mayoría de respuestas correctas ordinarias, incluidas vistas de página, lecturas de API y resultados de formularios. Compruebe que la caché, el formato del cuerpo y Content-Type coincidan con el resultado real. Relacionado: 201, 204
201 Created RFC 9110 La solicitud tuvo éxito y se creó un nuevo recurso. Es adecuado para solicitudes POST que crean publicaciones, pedidos, cuentas, archivos o recursos similares. Compruebe si la ubicación del nuevo recurso se entrega mediante el encabezado Location o el cuerpo de la respuesta. Relacionado: 200, 202, 204
202 Accepted RFC 9110 La solicitud fue aceptada, pero el procesamiento aún no se completó. Se usa para trabajos asíncronos, tareas en cola y operaciones batch cuyo resultado se decide más tarde. Incluya una URL de estado, un ID de trabajo o una guía de reintento en la respuesta cuando sea posible. Relacionado: 200, 201, 204
203 Non-Authoritative Information RFC 9110 Un proxy o una capa de transformación modificó y reenvió la respuesta 200 del servidor de origen. Puede usarse cuando un intermediario entrega una representación o metadatos transformados. Revise juntos la respuesta original, la política de transformación, los encabezados Warning y los encabezados de caché. Relacionado: 200, 214
204 No Content RFC 9110 La solicitud tuvo éxito, pero la respuesta no tiene cuerpo. Se usa cuando acciones como eliminar, guardar o alternar tienen éxito sin necesitar cuerpo de respuesta ni navegación. No envíe cuerpo con una respuesta 204 y confirme que el cliente no trate una respuesta vacía como error. Relacionado: 200, 205
205 Reset Content RFC 9110 La solicitud tuvo éxito y el cliente puede restablecer la vista de entrada. Puede usarse después de enviar un formulario para indicar al cliente que limpie los campos en la misma pantalla. Se usa rara vez en la práctica; confirme que restablecer la interfaz sea realmente la experiencia deseada. Relacionado: 204
206 Partial Content RFC 9110 Solo se devuelve una parte del recurso como respuesta a una solicitud Range. Es común en streaming de video, descargas reanudables y solicitudes parciales de archivos grandes. Revise los encabezados Range, Content-Range y Accept-Ranges junto con el comportamiento de caché del CDN. Relacionado: 200, 416
207 Multi-Status RFC 4918 Una respuesta WebDAV que transporta estados de varias suboperaciones en una sola solicitud. Se usa cuando se procesan varios recursos juntos y cada recurso necesita su propio resultado de éxito o fallo. Analice los estados por recurso desde el cuerpo de la respuesta; las API REST comunes suelen usar su propio formato de resultado. Relacionado: 102, 208
208 Already Reported RFC 5842 Indica que un recurso de enlace WebDAV ya fue informado y no se repite. Se usa para reducir listados duplicados cuando el mismo recurso se referencia por varias rutas en una respuesta WebDAV. Confirme que el cliente WebDAV pueda manejar 208 junto con el cuerpo de respuesta 207. Relacionado: 207
226 IM Used RFC 3229 El servidor devolvió un resultado después de aplicar una manipulación de instancia (IM). Está definido para delta encoding y otras respuestas basadas en cambios. Requiere un flujo especial de caché y transferencia con encabezados A-IM e IM, por lo que rara vez se usa en sitios ordinarios. Relacionado: 200, 206

3xx Redirección

Respuestas que indican que se necesita otra ubicación o una acción adicional para completar la solicitud.

9
Significado Situación principal Qué revisar
300 Multiple Choices RFC 9110 El recurso solicitado tiene varias representaciones u opciones. Puede usarse cuando el usuario o el cliente debe elegir entre alternativas de idioma, formato o versión para el mismo recurso. En la práctica son más comunes las redirecciones con un encabezado Location claro, como 301, 302, 303, 307 y 308. Relacionado: 301, 302
301 Moved Permanently RFC 9110 El recurso se movió permanentemente a una nueva URL. Se usa para reestructuraciones de sitio, cambios de dominio y canonicalización de URL cuando los buscadores deben aprender un traslado permanente. Revise el encabezado Location, la duración de caché y si los enlaces internos se actualizaron desde la URL anterior. Relacionado: 302, 308
302 Found RFC 9110 El recurso está disponible temporalmente en otra URL. Se usa para movimientos no permanentes, como navegación posterior al login, campañas temporales y pruebas A/B. Si el objetivo es indicar a los buscadores un traslado permanente, considere si 301 o 308 es más apropiado. Relacionado: 301, 303, 307
303 See Other RFC 9110 El resultado de la solicitud debe recuperarse con GET desde otra URL. Es útil en el patrón POST/Redirect/GET después de procesar formularios, cuando se envía al usuario a una página de resultado o finalización. Tenga claro que el método cambia a GET y verifique el flujo que evita envíos duplicados del formulario. Relacionado: 302, 307
304 Not Modified RFC 9110 Una solicitud condicional determinó que el recurso no cambió, por lo que puede usarse la copia en caché. Es común cuando navegadores o CDNs revalidan caché con If-None-Match o If-Modified-Since. Compruebe que ETag, Last-Modified y Cache-Control se comporten como se espera. Relacionado: 200, 412
305 Use Proxy RFC 9110 Un código heredado que indica al cliente usar un proxy; hoy está obsoleto por razones de seguridad. Lo más seguro es tratarlo como no usado en la web moderna. No lo use en implementaciones nuevas; gestione la política de proxy mediante configuración o la capa de red. Relacionado: 407
306 Unused RFC 9110 Un código de estado que se definió en el pasado, pero ahora está reservado y no se usa. No lo use como respuesta normal del servidor. Si aparece en logs, revise intermediarios, código de prueba o implementaciones no estándar. Relacionado: 305
307 Temporary Redirect RFC 9110 Una redirección temporal que debe conservar el método y el cuerpo de la solicitud. Es más claro que 302 cuando POST, PUT u otro método deben conservarse al enviar la solicitud a una ubicación temporal. Confirme que el cliente no cambie el método a GET y que el destino de Location pueda manejar la misma solicitud. Relacionado: 302, 308
308 Permanent Redirect RFC 9110 Una redirección permanente que debe conservar el método y el cuerpo de la solicitud. Es apropiada al mover permanentemente endpoints de API o URLs donde importa conservar el método. Defina Location con cuidado, porque los buscadores y las cachés de cliente pueden recordarlo durante mucho tiempo. Relacionado: 301, 307

4xx Error de cliente

Respuestas que indican que la solicitud no puede procesarse por condiciones del lado del cliente, como sintaxis, autenticación, autorización o estado del recurso.

29
Significado Situación principal Qué revisar
400 Bad Request RFC 9110 El servidor no puede procesar la solicitud porque la sintaxis, los parámetros, los encabezados o el cuerpo no son válidos. Es común con JSON inválido, valores obligatorios ausentes, URLs mal formadas o encabezados anómalos. Revise el formato del cuerpo, Content-Type, los parámetros de consulta y los logs de validación del servidor. Relacionado: 422
401 Unauthorized RFC 9110 Se requiere autenticación o las credenciales proporcionadas no son válidas. Se usa cuando falta un token de login, una clave de API expiró o el encabezado Authorization es incorrecto. Revise el encabezado WWW-Authenticate, la expiración del token, el esquema de autenticación y si se envían cookies. Relacionado: 403, 407
402 Payment Required RFC 9110 Reservado para escenarios que requieren pago, aunque su significado estándar no está ampliamente establecido. Algunas API y servicios de pago lo usan de forma no oficial para problemas de pago, crédito o suscripción. Revise la documentación específica del servicio para conocer el significado real de 402 y la ruta de recuperación. Relacionado: 403, 429
403 Forbidden RFC 9110 El servidor entendió la solicitud, pero rechaza permitir el acceso. Es común con permisos insuficientes, bloqueos de IP, políticas administrativas o acceso a recursos privados. Revise por separado la política de autorización, ACLs, reglas WAF, permisos de archivo y reglas de enrutamiento. Relacionado: 401, 404, 451
404 Not Found RFC 9110 El recurso solicitado no se encuentra, o el servidor no revela si existe. Es más común con errores de URL, páginas eliminadas, rutas incorrectas o recursos ocultos deliberadamente. Revise enlaces internos, sitemaps, redirecciones, tablas de rutas y URLs de reemplazo para contenido eliminado. Relacionado: 410, 403, 451
405 Method Not Allowed RFC 9110 El recurso existe, pero el método HTTP solicitado no está permitido. Ocurre cuando se envía POST a una URL solo GET o cuando una ruta de API está configurada para otros métodos. Revise el encabezado Allow, las definiciones de método del router y las políticas de restricción de método del proxy. Relacionado: 404, 501
406 Not Acceptable RFC 9110 El servidor no puede ofrecer una representación que coincida con los encabezados Accept del cliente. Puede ocurrir cuando el cliente solicita únicamente tipos de medios, idiomas o codificaciones no admitidos. Revise los encabezados Accept, Accept-Language y Accept-Encoding, y la configuración de negociación de contenido del servidor. Relacionado: 415
407 Proxy Authentication Required RFC 9110 Se requiere autenticación antes de que el cliente pueda usar el proxy. Se ve en redes corporativas, proxies de seguridad y entornos de autenticación de gateway. Revise los encabezados Proxy-Authenticate y Proxy-Authorization, y la configuración del proxy de red. Relacionado: 401, 305
408 Request Timeout RFC 9110 El servidor no recibió la solicitud completa del cliente dentro del tiempo que estaba dispuesto a esperar. Puede ocurrir con redes lentas, cargas grandes, timeouts de keep-alive o timeouts de balanceadores de carga. Revise el comportamiento de reintento del cliente, el tamaño de carga, la configuración keep-alive y los valores de timeout del proxy. Relacionado: 504
409 Conflict RFC 9110 La solicitud entra en conflicto con el estado actual del recurso. Suele usarse para creación duplicada, conflictos de versión, ediciones concurrentes o transiciones de estado inválidas. Revise versiones del recurso, ETags, claves duplicadas y reglas de transición de estado del negocio. Relacionado: 412, 422
410 Gone RFC 9110 El recurso existía antes, pero fue eliminado permanentemente. Es más específico que 404 cuando se quiere indicar claramente a buscadores y clientes que una página fue eliminada. Use 301 si existe una URL de reemplazo; use 410 con limpieza de sitemap cuando la eliminación permanente sea correcta. Relacionado: 404, 301
411 Length Required RFC 9110 El servidor rechaza la solicitud porque no incluye Content-Length. Puede ocurrir cuando un servidor o gateway necesita conocer de antemano la longitud del cuerpo de la solicitud. Revise Content-Length, Transfer-Encoding y el comportamiento de streaming de la biblioteca cliente. Relacionado: 413
412 Precondition Failed RFC 9110 Falló una precondición de una solicitud condicional, como If-Match. Se usa para prevenir ediciones concurrentes, revalidar caché y realizar actualizaciones basadas en ETag. Compare If-Match, If-None-Match e If-Unmodified-Since con la versión actual del recurso. Relacionado: 304, 409, 428
413 Content Too Large RFC 9110 El cuerpo de la solicitud es más grande de lo que el servidor está dispuesto a aceptar. Es común con límites de carga de archivos, límites de tamaño de cuerpos JSON y restricciones de tamaño en proxies. Revise los límites de carga en servidor, proxy, CDN y aplicación. Relacionado: 411, 431
414 URI Too Long RFC 9110 La URI de la solicitud es más larga de lo que el servidor puede procesar. Puede ocurrir con cadenas de consulta muy largas, bucles de redirección defectuosos o datos excesivos colocados en una URL GET. Mueva datos largos al cuerpo de un POST y revise los límites de longitud de URI en proxies y servidores. Relacionado: 400, 431
415 Unsupported Media Type RFC 9110 El servidor no admite el tipo de medio del cuerpo de la solicitud. Ocurre cuando una API JSON recibe un Content-Type incorrecto o se carga un formato de archivo no admitido. Revise Content-Type, la extensión del archivo, la configuración multipart y si el parser del servidor está registrado. Relacionado: 406, 422
416 Range Not Satisfiable RFC 9110 El Range solicitado no puede servirse porque no encaja con el tamaño del recurso. Ocurre en descargas reanudables o streaming cuando el rango solicitado queda fuera del tamaño del archivo. Revise el encabezado Range, Content-Range, el tamaño del archivo y metadatos de caché obsoletos. Relacionado: 206
417 Expectation Failed RFC 9110 El servidor no puede cumplir la expectativa indicada en el encabezado Expect. Puede ocurrir cuando un servidor o proxy no admite expectativas como Expect: 100-continue. Quite el encabezado Expect o confirme que el servidor admita el manejo de 100 Continue. Relacionado: 100
422 Unprocessable Content RFC 9110 La sintaxis de la solicitud es válida, pero el contenido no puede procesarse semánticamente. Es común en fallos de validación de API, violaciones de reglas de negocio y valores de campo inválidos. Defina en las reglas de su API si 400 significa errores de formato y 422 errores semánticos o de validación. Relacionado: 400, 409, 415
423 Locked RFC 4918 El recurso objetivo está bloqueado, por lo que la solicitud no puede procesarse. Se usa para bloqueos de edición de archivos, documentos colaborativos y locks de recursos WebDAV. Revise el propietario del lock, su expiración, la API de desbloqueo y la política de manejo de conflictos. Relacionado: 409, 424
424 Failed Dependency RFC 4918 La solicitud actual no puede realizarse porque falló una operación dependiente previa. Se usa cuando varias operaciones dependen entre sí y el fallo de una operación anterior provoca el fallo de una posterior. Deje clara en el cuerpo de la respuesta la operación previa fallida y la relación de dependencia. Relacionado: 207, 423
426 Upgrade Required RFC 9110 El servidor exige que el cliente actualice protocolos antes de procesar la solicitud. Se usa cuando se requiere una actualización concreta, como versión HTTP, TLS o WebSocket. Revise el encabezado Upgrade, los protocolos admitidos y si los proxies reenvían solicitudes de actualización. Relacionado: 101
428 Precondition Required RFC 6585 El servidor exige un encabezado de solicitud condicional. Se usa para evitar actualizaciones perdidas en ediciones concurrentes mediante una condición como If-Match. Proporcione documentación de API y mensajes de error que indiquen al cliente leer el ETag y actualizar con If-Match. Relacionado: 412, 409
429 Too Many Requests RFC 6585 El cliente envió demasiadas solicitudes en un periodo determinado. Es común con límites de tasa de API, límites de intentos de login, bloqueo de bots y recargas excesivas. Revise Retry-After, encabezados de rate limit, límites por usuario o token y estrategia de backoff. Relacionado: 403, 503
431 Request Header Fields Too Large RFC 6585 Los encabezados de solicitud en conjunto, o un campo de encabezado específico, son demasiado grandes. Puede ocurrir cuando las cookies crecen demasiado o se acumulan tokens de autenticación, encabezados de seguimiento o encabezados añadidos por proxies. Reduzca el tamaño de Cookie, del encabezado Authorization y de los encabezados añadidos por cadenas de proxies. Relacionado: 400, 413, 414

5xx Error de servidor

Respuestas que indican que el servidor o la pasarela no pudo procesar una solicitud que, por lo demás, era válida.

11
Significado Situación principal Qué revisar
500 Internal Server Error RFC 9110 Un error general del servidor que indica que la solicitud no pudo procesarse por un fallo interno. Se usa cuando no deben exponerse al cliente errores detallados como excepciones, configuración ausente, fallos de base de datos o de renderizado de plantillas. Revise logs de aplicación, seguimiento de errores, despliegues recientes y salud de servicios dependientes. Relacionado: 502, 503, 504
501 Not Implemented RFC 9110 El servidor no admite la funcionalidad requerida para procesar la solicitud. Se usa cuando se solicita un método HTTP no admitido o una funcionalidad de servidor que no se ha implementado. 405 significa que el método está prohibido para ese recurso; 501 se acerca más a que el servidor no conoce esa capacidad. Relacionado: 405
502 Bad Gateway RFC 9110 Una pasarela o proxy recibió una respuesta inválida de un servidor upstream. Es común con problemas de conexión al servidor de origen detrás de un CDN, balanceador de carga o proxy inverso. Revise la salud del origen, DNS, TLS, configuración upstream del proxy y tamaño y formato de encabezados de respuesta. Relacionado: 500, 503, 504
503 Service Unavailable RFC 9110 El servidor no puede procesar temporalmente la solicitud. Es común durante mantenimiento, sobrecarga, despliegues, caídas de backend y retrasos de autoscaling. Revise Retry-After, health checks, autoscaling, cola acumulada y configuración de página de mantenimiento. Relacionado: 429, 500, 502, 504
504 Gateway Timeout RFC 9110 Una pasarela o proxy no recibió a tiempo una respuesta de un servidor upstream. Es común con latencia del servidor de origen, consultas lentas de base de datos, demoras de APIs externas y timeouts de balanceadores de carga. Revise valores de timeout upstream, tiempo de procesamiento de la aplicación, tiempo de respuesta de base de datos o API externa y política de reintentos. Relacionado: 408, 502, 503
505 HTTP Version Not Supported RFC 9110 El servidor no admite la versión HTTP usada en la solicitud. Puede ocurrir con clientes antiguos, proxies defectuosos o restricciones de versión HTTP del lado del servidor. Revise la versión HTTP del cliente, la negociación TLS/ALPN y la configuración de traducción de protocolo del proxy. Relacionado: 426
506 Variant Also Negotiates RFC 2295 Un error de configuración de negociación transparente de contenido causó un bucle interno de negociación. Se usa cuando la negociación de contenido del servidor está mal configurada y la variante elegida también está configurada para negociar. Revise la configuración de negociación de contenido, los mapeos de variantes y los archivos de configuración del servidor. Relacionado: 300, 406
507 Insufficient Storage RFC 4918 El servidor no puede asignar el almacenamiento necesario para completar la solicitud. Puede ocurrir con WebDAV, cargas de archivos, agotamiento de cuota de almacenamiento o falta de espacio en disco. Revise uso de disco, almacenamiento de archivos temporales, cuotas de usuario y errores de object storage. Relacionado: 413, 500
508 Loop Detected RFC 5842 El servidor detectó un bucle infinito al procesar la solicitud. Puede usarse cuando una solicitud WebDAV Depth o una estructura interna de referencias contiene un ciclo. Revise el grafo de referencias de recursos, enlaces simbólicos, bindings WebDAV y límites de recursión. Relacionado: 508
510 Not Extended RFC 2774 Se requieren extensiones adicionales para que la solicitud pueda procesarse. Está definido por el framework de extensiones HTTP, pero rara vez se usa en servicios web ordinarios. Revise la documentación de los requisitos de extensión de la API o del servidor involucrado. Relacionado: 501

Detalles de códigos HTTP frecuentes

Después de localizarlos rápidamente en la tabla, consulta abajo las diferencias con códigos similares.

HTTP 451 No disponible por razones legales

451 es un código 4xx que indica claramente que el acceso no está disponible por razones legales.

HTTP 451 se usa cuando un servidor, buscador, proxy o intermediario no puede proporcionar un recurso por una exigencia legal. No es solo falta de permiso: señala que detrás de la restricción hay un requisito legal externo, como una orden judicial, una solicitud gubernamental, una acción de copyright o una regulación local.

Cuando aparece 451 en resultados de búsqueda o en un navegador, es más preciso entender que la página no se entrega por razones legales en la ubicación de la solicitud o según la política del servicio, en lugar de asumir que desapareció técnicamente. Cuando sea posible, los proveedores deberían explicar en el cuerpo de la respuesta la parte que bloquea o la exigencia legal para que los usuarios comprendan la situación.

Diferencia con 403 403 significa que el acceso está prohibido por permisos o política del servidor; 451 se usa cuando la razón de esa restricción es una exigencia legal.
Diferencia con 404 404 significa que el recurso no se encuentra o que se oculta su existencia; 451 indica con más fuerza que el recurso existe o se conoce, pero no puede proporcionarse por razones legales.
Diferencia con 410 410 significa que el recurso fue eliminado permanentemente; 451 significa que el acceso está restringido, independientemente de si el recurso fue eliminado.

HTTP 429 Demasiadas solicitudes

429 significa que se superó un límite de solicitudes y es especialmente común en APIs y protección de login.

429 se usa cuando un cliente envía demasiadas solicitudes en poco tiempo. Está vinculado a políticas de estabilidad del servicio y prevención de abuso, como límites de uso, defensa contra bots, límites de intentos de login y cuotas de API en planes gratuitos.

Los servidores deberían proporcionar Retry-After o encabezados de rate limit cuando sea posible para que los clientes sepan cuándo reintentar. Los clientes deberían usar backoff exponencial y colas en lugar de repetir solicitudes de inmediato.

Diferencia con 403 403 significa que el acceso en sí está prohibido, mientras que 429 puede volver a permitirse cuando pase el tiempo o se recupere el uso.
Diferencia con 503 503 significa que el servidor no puede manejar solicitudes temporalmente; 429 indica con más precisión que un cliente o token concreto superó una cuota de solicitudes.

HTTP 404 No encontrado

404 es el código de error web más común; conviene revisar primero la URL y el estado del contenido.

404 significa que el servidor no pudo encontrar el recurso solicitado. Los usuarios suelen interpretarlo como un error de URL o una página eliminada, pero los servidores también pueden devolver 404 para no revelar si existe un recurso protegido.

Para visibilidad en buscadores, revise enlaces internos rotos, sitemaps antiguos y páginas de reemplazo ausentes para contenido eliminado. Si existe un reemplazo claro, 301 puede ser apropiado; si el recurso se eliminó permanentemente, 410 también es una opción.

Diferencia con 410 404 es una respuesta general de no encontrado, mientras que 410 señala que el recurso existía antes y desapareció permanentemente.
Diferencia con 403 403 significa que el servidor encontró el recurso pero rechaza el acceso; 404 significa que no se encontró o que el servidor no revela si existe.

HTTP 500 Error interno del servidor

500 es un error amplio del lado del servidor que significa que ocurrió una excepción o fallo al procesar la solicitud.

500 se usa cuando ocurre un problema en la lógica del servidor, la configuración, servicios dependientes o el procesamiento de datos, más que en el formato de la solicitud del cliente. A menudo se devuelve como código de error general para no exponer excepciones detalladas a los usuarios.

En operaciones, revise primero despliegues recientes, logs de aplicación, seguimiento de errores, conexiones de base de datos y variables de entorno ausentes. Si la misma solicitud produce 500 repetidamente, inspeccione también las rutas de validación de entrada y manejo de excepciones.

Diferencia con 502 500 es un error interno del servidor actual, mientras que 502 significa que una pasarela recibió una respuesta inválida de un servidor upstream.
Diferencia con 503 503 encaja mejor con indisponibilidad temporal, como mantenimiento o sobrecarga.

HTTP 503 Servicio no disponible

503 significa que el servidor no puede procesar temporalmente la solicitud.

503 se usa cuando un servicio no puede aceptar solicitudes temporalmente por mantenimiento, sobrecarga, despliegue, fallos de backend o retraso de autoscaling. Para buscadores, puede señalar un problema temporal, por lo que el mantenimiento programado suele representarse mejor con 503 que con 500.

Incluya un encabezado Retry-After cuando sea posible para indicar cuándo debe reintentar el cliente. Revise también health checks del balanceador de carga, cola acumulada, número de instancias y fallos de servicios dependientes.

Diferencia con 500 500 cubre errores internos de forma amplia, mientras que 503 indica más claramente que el servidor no puede procesar solicitudes temporalmente.
Diferencia con 429 429 significa que el cliente solicitante envió demasiadas solicitudes, mientras que 503 se acerca más a que el servicio completo, o una parte de él, perdió capacidad de procesamiento.

Los códigos de estado HTTP son señales que estandarizan el significado de la comunicación. La causa real debe confirmarse junto con los logs de la aplicación, la configuración de proxy/CDN, las políticas de autenticación, los encabezados de caché y el historial de despliegues.

Fuentes y licencias

Fuentes de datos y condiciones de uso

Esta página se basa en datos públicos de los proveedores originales indicados abajo. Cada conjunto de datos se rige por la licencia o las condiciones de uso del proveedor original.

Fuente Datos/API Condiciones Procesamiento de Onul Works
IANA HTTP Status Code Registry Condiciones Reorganiza los códigos registrados por IANA y las descripciones de RFC de IETF en grupos de centenas, etiquetas de búsqueda y explicaciones de códigos principales.
IETF / RFC Editor HTTP Semantics and status code RFCs Condiciones Reorganiza los códigos registrados por IANA y las descripciones de RFC de IETF en grupos de centenas, etiquetas de búsqueda y explicaciones de códigos principales.

La normalización, traducción, combinación, caché o conversión de unidades realizada por Onul Works no implica garantía ni aprobación por parte de los proveedores originales.