# Solución de problemas de códigos de estado de respuesta a errores en CloudFront
Si CloudFront solicita un objeto desde su origen y el origen devuelve un código de estado HTTP 4xx o 5xx, hay un problema con la comunicación entre CloudFront y el origen.
En este tema también se incluyen pasos de solución de problemas para estos códigos de estado al utilizar Lambda@Edge o CloudFront Functions.
En los siguientes temas se proporcionan explicaciones detalladas de las posibles causas que subyacen a estas respuestas de error y se ofrece una guía paso a paso sobre cómo diagnosticar y resolver los problemas subyacentes.
**Topics**
+ [Código de estado HTTP 400 (Solicitud errónea)](http-400-bad-request.md)
+ [Código de estado HTTP 401 (sin autorización)](http-401-unauthorized.md)
+ [Código de estado HTTP 403 (método no válido)](http-403-invalid-method.md)
+ [Código de estado HTTP 403 (permiso denegado)](http-403-permission-denied.md)
+ [Código de estado HTTP 404 (no encontrado)](http-404-not-found.md)
+ [Código de estado HTTP 412 (condición previa con error)](http-412-precondition-failed.md)
+ [Código de estado HTTP 500 (error de servidor interno)](http-500-internal-server-error.md)
+ [Código de estado HTTP 502 (Puerta de enlace incorrecta)](http-502-bad-gateway.md)
+ [Código de estado HTTP 503 (Servicio no disponible)](http-503-service-unavailable.md)
+ [Código de estado HTTP 504 (Tiempo de espera de puerta de enlace agotado)](http-504-gateway-timeout.md)
# Código de estado HTTP 400 (Solicitud errónea)
CloudFront devuelve una solicitud errónea 400 cuando el cliente envía algún dato no válido en la solicitud, como la falta de contenido o contenido incorrecto en la carga útil o en los parámetros. Esto también podría representar un error de cliente genérico.
## El origen de Amazon S3 devuelve un error 400
Si utiliza un origen de Amazon S3 con la distribución de CloudFront, es posible que la distribución envíe respuestas de error con el código de estado HTTP 400 Solicitud incorrecta y un mensaje similar al siguiente:
*El encabezado de autorización tiene una estructura incorrecta; la región '**' es incorrecta; se esperaba '**'*
Por ejemplo:
*El encabezado de autorización tiene una estructura incorrecta; la región «us-east-1» es incorrecta; se esperaba «us-west-2'*
Este problema puede producirse en la siguiente situación:
1. El origen de su distribución de CloudFront es un bucket de Amazon S3.
1. Ha movido el bucket de S3 de una región de AWS a otra. Es decir, eliminó el bucket de S3 y, a continuación, creó un nuevo bucket con el mismo nombre de bucket, pero en una región de AWS diferente a la ubicación del bucket de S3 original.
Para solucionar este error, actualice la distribución de CloudFront para que encuentre el bucket de S3 en la región de AWS actual del bucket.
**Para actualizar la distribución de CloudFront**
1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Elija la distribución que produce este error.
1. Elija **Origins and Origin Groups (Orígenes y grupos de origen)**.
1. Busque el origen del bucket de S3 que movió. Seleccione la casilla de verificación situada junto a este origen y, a continuación, elija **Edit (Editar)**.
1. Elija **Yes, Edit (Sí, editar)**. No es necesario cambiar ninguna configuración antes de elegir **Yes, Edit (Sí, Editar)**.
Cuando complete estos pasos, CloudFront volverá a implementar la distribución. Mientras la distribución se está implementando, verá el estado **Implementando** en la columna **Última modificación**. Una vez finalizada la implementación, debe dejar de recibir las respuestas de error `AuthorizationHeaderMalformed`.
## El origen del equilibrador de carga de aplicación devuelve un error 400
Si está utilizando un origen de equilibrador de carga de aplicación con la distribución de CloudFront, entre las posibles causas de un error 400 se incluyen las siguientes:
+ El cliente envió una solicitud incorrecta que no se ajusta a la especificación de HTTP.
+ El encabezado de la solicitud supera los 16 KB por línea de solicitud, los 16 KB por encabezado único o los 64 KB para el encabezado completo de la solicitud.
+ El cliente cerró la conexión antes de enviar el cuerpo completo de la solicitud.
# Código de estado HTTP 401 (sin autorización)
Un código de estado de respuesta 401 sin autorización indica que la solicitud del cliente no se ha completado porque carece de credenciales de autenticación válidas para el recurso solicitado. Este código de estado se envía con un encabezado de respuesta `WWW-Authenticate` de HTTP que contiene información sobre cómo el cliente puede volver a solicitar el recurso después de pedir al usuario las credenciales de autenticación. Para obtener más información, consulte [401 sin autorización](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401).
En CloudFront, si el origen espera un encabezado `Authorization` para autenticar las solicitudes, CloudFront necesita reenviar el encabezado `Authorization` al origen para evitar un error 401 sin autorización. Cuando CloudFront reenvía una solicitud del lector a su origen, CloudFront elimina algunos encabezados de lector de forma predeterminada, incluido el encabezado `Authorization`. Para asegurarse de que su origen siempre recibe el encabezado `Authorization` en las solicitudes de origen, tiene las siguientes opciones:
+ Agregue el encabezado `Authorization` a la clave de caché mediante una política de caché. Todos los encabezados de la clave de caché se incluyen automáticamente en las solicitudes de origen. Para obtener más información, consulte [Control de la clave de caché con una política](controlling-the-cache-key.md).
+ Utilice una política de solicitud de origen que reenvíe todos los encabezados del lector al origen. No puede reenviar el encabezado `Authorization` individualmente en una política de solicitud de origen, pero, cuando reenvíe todos los encabezados del lector, CloudFront incluye el encabezado `Authorization` en las solicitudes de lector. CloudFront proporciona la política de solicitud de origen `AllViewer` administrada para este caso de uso. Para obtener más información, consulte [Uso de políticas de solicitudes de origen administradas](using-managed-origin-request-policies.md).
Para obtener más información, consulte [How can I configure CloudFront to forward the Authorization header to the origin?](https://repost.aws/knowledge-center/cloudfront-authorization-header)
# Código de estado HTTP 403 (método no válido)
CloudFront devuelve un error 403 (método no permitido) si intenta utilizar un método HTTP que no ha especificado en la distribución de CloudFront. Puede especificar una de las siguientes opciones para la distribución:
+ CloudFront solo reenvía las solicitudes `GET` y `HEAD`.
+ CloudFront solo reenvía las solicitudes `GET`, `HEAD` y `OPTIONS`.
+ CloudFront reenvía las solicitudes `GET`, `HEAD`, `OPTIONS`, `PUT`, `PATCH`, `POST` y `DELETE`. (Si selecciona esta opción, es posible que tenga que restringir el acceso al bucket de Amazon S3 o al origen personalizado para que los usuarios no puedan realizar operaciones que usted no desea. Por ejemplo, es posible que no desee que los usuarios tengan permisos para eliminar objetos de su origen.
# Código de estado HTTP 403 (permiso denegado)
Un error HTTP 403 significa que el cliente no tiene autorización para acceder al recurso solicitado. El cliente entiende la solicitud, pero no puede autorizar el acceso del lector. Las siguientes son causas comunes cuando CloudFront devuelve este código de estado:
**Topics**
+ [El CNAME alternativo está configurado incorrectamente](#alternate-cname-incorrectly-configured)
+ [AWS WAF se configura en la distribución de CloudFront o en el origen](#aws-waf-configured-on-distribution-origin)
+ [El origen personalizado devuelve un error 403](#custom-origin-returning-403)
+ [El origen de Amazon S3 devuelve un error 403](#s3-origin-403-error)
+ [Las restricciones geográficas devuelven un error 403](#geolocation-403)
+ [La configuración de URL firmada o cookie firmada devuelve un error 403](#signed-URLs-cookies-403)
+ [Las distribuciones apiladas provocan un error 403](#stacked-distributions-403)
## El CNAME alternativo está configurado incorrectamente
Compruebe que ha especificado el CNAME correcto para nuestra distribución. Para utilizar un CNAME alternativo en lugar de la URL predeterminada de CloudFront:
1. Cree un registro CNAME en el DNS para apuntar el CNAME a la URL de distribución de CloudFront.
1. Agregue el CNAME en la configuración de la distribución de CloudFront.
Si crea el registro DNS pero no agrega el CNAME en la configuración de la distribución de CloudFront, la solicitud devolverá un error 403. Para obtener más información sobre la configuración de un CNAME personalizado, consulte [Uso de URL personalizadas añadiendo nombres de dominio alternativos (CNAME)](CNAMEs.md).
## AWS WAF se configura en la distribución de CloudFront o en el origen
Cuando AWS WAF se sitúa entre el cliente y CloudFront, CloudFront no puede distinguir entre un código de error 403 devuelto por el origen y un código de error 403 devuelto por AWS WAF cuando se bloquea una solicitud.
Para encontrar el origen del código de estado 403, busque en la regla de la lista de control de acceso (ACL) web de AWS WAF una solicitud bloqueada. Para obtener más información, consulte los temas siguientes:
+ [AWS WAF Listas de control de acceso web (ACL web) de)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Prueba y ajuste de las protecciones de AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## El origen personalizado devuelve un error 403
Si utiliza un origen personalizado, es posible que aparezca un error 403 si tiene una configuración de firewall personalizada en el origen. Para solucionar el problema, efectúe la solicitud directamente al origen. Si puede reproducir el error sin CloudFront, significa que el origen está provocando el error 403.
Si el origen personalizado provoca el error, consulte los registros del origen para identificar la posible causa del error. Para obtener más información, consulte los siguientes temas de solución de problemas:
+ [Cómo soluciono los errores HTTP 403 de API Gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Cómo soluciono los errores de prohibición HTTP 403 del equilibrador de carga de aplicación?](https://repost.aws/knowledge-center/alb-http-403-error)
## El origen de Amazon S3 devuelve un error 403
Es posible que vea un error 403 por las siguientes razones:
+ CloudFront no tiene acceso al bucket de Amazon S3. Esto puede ocurrir si la identidad de acceso de origen (OAI) o el control de acceso de origen (OAC) no están habilitados para la distribución y el bucket es privado.
+ La ruta especificada en la URL solicitada no es correcta.
+ El objeto solicitado no existe.
+ El encabezado del host se ha reenviado con el punto de conexión de la API de REST. Para obtener más información, consulte [Especificación de bucket de encabezado de host HTTP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket) en la *Guía del usuario de Amazon Simple Storage Service*.
+ Ha configurado páginas de error personalizadas. Para obtener más información, consulte [Cómo CloudFront procesa los errores cuando las páginas de error personalizadas están configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Las restricciones geográficas devuelven un error 403
Si ha habilitado las restricciones geográficas (también conocidas como bloqueo geográfico) para evitar que los usuarios de ubicaciones geográficas específicas accedan al contenido que está distribuyendo a través de una distribución de CloudFront, los usuarios bloqueados recibirán un error 403.
Para obtener más información, consulte [Restricción de la distribución geográfica de su contenido](georestrictions.md).
## La configuración de URL firmada o cookie firmada devuelve un error 403
Si ha habilitado la opción **Restringir el acceso de lector** en la configuración de comportamiento de la distribución, las solicitudes que no utilicen cookies ni URL firmadas producirán un error 403. Para obtener más información, consulte los temas siguientes:
+ [Distribución de contenido privado con URL firmadas y cookies firmadas](PrivateContent.md)
+ [Cómo soluciono los problemas relacionados con una URL o cookies firmadas en CloudFront?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Las distribuciones apiladas provocan un error 403
Si tiene dos o más distribuciones en una cadena de solicitudes al punto de conexión de origen, CloudFront devuelve un error 403. No recomendamos anteponer una distribución a otra.
# Código de estado HTTP 404 (no encontrado)
CloudFront devuelve un error 404 (no encontrado) cuando el cliente intenta acceder a un recurso que no existe. Si recibe este error con la distribución de CloudFront, las causas más comunes son las siguientes:
+ El recurso no existe.
+ La URL es incorrecta.
+ El origen personalizado devuelve un error 404.
+ Las páginas de error personalizadas devuelven un error 404. (Cualquier código de error puede traducirse a 404). Para obtener más información, consulte [Cómo CloudFront procesa los errores cuando las páginas de error personalizadas están configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ La página de error personalizada se ha eliminado accidentalmente, lo que provoca un error 404 porque la solicitud busca la página de error personalizada eliminada. Para obtener más información, consulte [Cómo CloudFront procesa los errores si no ha configurado las páginas de error personalizadas](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Ruta de origen incorrecta. Si se rellena la ruta de origen, el valor se adjunta a la ruta de cada solicitud del navegador antes de que la solicitud se reenvíe al origen. Para obtener más información, consulte [Ruta de origen](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# Código de estado HTTP 412 (condición previa con error)
CloudFront devuelve un código de error 412 (condición previa con error) cuando se ha denegado el acceso al recurso de destino. En algunos casos, un servidor está configurado para aceptar solicitudes solo después de que se cumplan determinadas condiciones. Si no se cumple alguna de las condiciones especificadas, el servidor no permite que el cliente acceda al recurso indicado. En su lugar, el servidor responde con un código de error 412.
Entre las causas comunes de un error 412 en CloudFront se incluyen:
+ Solicitudes condicionales en métodos distintos de `GET` o `HEAD` cuando no se cumple la condición definida por los encabezados `If-Unmodified-Since` o `If-None-Match`. En ese caso, la solicitud, normalmente una carga o una modificación de un recurso, no se puede realizar.
+ Una condición en uno o más de los campos de solicitud de la operación de la API [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) de CloudFront se evalúa como falsa.
# Código de estado HTTP 500 (error de servidor interno)
Un código de estado HTTP 500 (error de servidor interno) indica que el servidor ha encontrado una condición inesperada que le ha impedido satisfacer la solicitud. A continuación, se indican algunas causas comunes de los errores 500 en Amazon CloudFront.
**Topics**
+ [El servidor de origen devuelve el error 500 a CloudFront](#origin-server-500-error)
## El servidor de origen devuelve el error 500 a CloudFront
Es posible que el servidor de origen esté devolviendo un error 500 a CloudFront. Consulte los siguientes temas de solución de problemas para obtener más información:
+ **Si Amazon S3 devuelve un error 500**, consulte [¿Cómo soluciono un error HTTP 500 o 503 de Amazon S3?](https://repost.aws/knowledge-center/http-5xx-errors-s3)
+ **Si API Gateway devuelve un error 500**, consulte [¿Cómo soluciono los errores 5xx de la API de REST de API Gateway?](https://repost.aws/knowledge-center/api-gateway-5xx-error)
+ **Si Elastic Load Balancing devuelve un error 500**, consulte [HTTP 500: Internal server error](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) en la *Guía del usuario para equilibradores de carga de aplicación*.
Si la lista anterior no resuelve el error 500, es posible que el problema se deba a que un punto de presencia de CloudFront devuelve un error de servidor interno. Puede contactar con [Soporte](https://console.aws.amazon.com/support/home#/) si necesita ayuda.
# Código de estado HTTP 502 (Puerta de enlace incorrecta)
CloudFront devuelve un código de estado HTTP 502 (puerta de enlace incorrecta) cuando CloudFront no ha podido servir el objeto solicitado porque no se ha podido conectar con el servidor de origen.
Si utiliza Lambda@Edge, puede que el problema sea un error de validación de Lambda. Si recibe un error HTTP 502 con el código de error `NonS3OriginDnsError`, posiblemente hay un problema de configuración de DNS que impide que CloudFront se conecte al origen.
**Topics**
+ [Error de negociación SSL/TLS entre CloudFront y un servidor de origen personalizado](#ssl-negotitation-failure)
+ [El origen no responde con protocolos ni cifrados admitidos](#origin-not-responding-with-supported-ciphers-protocols)
+ [El certificado SSL/TLS del origen ha caducado, no es válido, es autofirmado o el orden de la cadena de certificados es incorrecto](#ssl-certificate-expired)
+ [El origen no responde en puertos especificados en la configuración de origen](#origin-not-responding-on-specified-ports)
+ [Error de validación de Lambda](#http-502-lambda-validation-error)
+ [Error de validación de la función de CloudFront](#http-502-cloudfront-function-validation-error)
+ [Error de DNS (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Error 502 originado por el equilibrador de carga de aplicación](#cloudfront-alb-502-error)
+ [Error 502 de origen de API Gateway](#cloudfront-api-gateway-502-error)
## Error de negociación SSL/TLS entre CloudFront y un servidor de origen personalizado
Si utiliza un origen personalizado que requiere HTTPS entre CloudFront y el origen, los nombres de dominio no coincidentes podrían causar errores. El certificado SSL/TLS del origen *debe* incluir un nombre de dominio que coincida con el **Dominio de origen** que especificó para la distribución de CloudFront o con el encabezado `Host` de la solicitud de origen.
Si los nombres de dominio no coinciden, el protocolo SSL/TLS devuelve un error, y CloudFront devuelve un código de estado HTTP 502 (gateway incorrecta) y establece el encabezado `X-Cache` en `Error from cloudfront`.
Para determinar si los nombres de dominio del certificado coinciden con el **Dominio de origen** en la distribución o con el encabezado `Host`, utilice un comprobador de SSL en línea u OpenSSL. Si los nombres de dominio no coinciden, tiene dos opciones:
+ Obtener un nuevo certificado SSL/TLS que incluya los nombres de dominio aplicables.
Si utiliza AWS Certificate Manager (ACM), consulte [Solicitar un certificado público](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) en la *Guía del usuario de AWS Certificate Manager* para solicitar un certificado nuevo.
+ Cambie la configuración de la distribución para que CloudFront deje de intentar utilizar SSL para conectarse al origen.
### Comprobador de SSL en línea
Para encontrar una herramienta de comprobación de SSL, busque en Internet "comprobador ssl online". Por lo general, especifica el nombre de su dominio y la herramienta devuelve información acerca de su certificado SSL/TLS. Compruebe que el certificado contenga su nombre de dominio en los campos **Nombre común** o **Nombres alternativos de sujeto**.
### OpenSSL
Como ayuda para solucionar los errores HTTP 502 desde CloudFront, puede utilizar OpenSSL para intentar realizar una conexión SSL/TLS con el servidor de origen. Si OpenSSL no puede establecer una conexión, puede indicar un problema con la configuración de SSL/TLS del servidor de origen. Si OpenSSL puede establecer una conexión, devuelve información sobre el certificado del servidor de origen, incluido el nombre común (campo `Subject CN`) y el nombre alternativo del sujeto (campo `Subject Alternative Name`) del certificado.
Utilice el siguiente comando de OpenSSL para probar la conexión con el servidor de origen (sustituya *dominio de origen* por el nombre de dominio del servidor de origen, como example.com):
`openssl s_client -connect origin domain name:443`
Si se cumplen las siguientes condiciones:
+ El servidor de origen admite varios nombres de dominio con varios certificados SSL/TLS
+ Su distribución está configurada para reenviar el encabezado `Host` al origen
Agregue la opción `-servername` al comando OpenSSL, como en el siguiente ejemplo (sustituya *CNAME* por el CNAME configurado en la distribución):
`openssl s_client -connect origin domain name:443 -servername CNAME`
## El origen no responde con protocolos ni cifrados admitidos
CloudFront se conecta con servidores de origen a través de códigos cifrados y protocolos. Para obtener una lista de los algoritmos criptográficos y protocolos que CloudFront admite, consulte [Protocolos y cifrados admitidos entre CloudFront y el origen](secure-connections-supported-ciphers-cloudfront-to-origin.md). Si el origen no responde con uno de estos algoritmos criptográficos o protocolos en el intercambio SSL/TLS, CloudFront no puede conectarse. Use una herramienta en línea como [SSL Labs](https://www.ssllabs.com/ssltest) para comprobar si el origen es compatible con los cifrados y protocolos. Escriba el nombre de dominio del origen en el campo **Hostname (Nombre de host)** y, a continuación, elija **Submit (Enviar)**. Revise los campos **Common names (Nombres comunes)** y **Alternative names (Nombres alternativos)** de la prueba para ver si coinciden con el nombre de dominio del origen. Una vez finalizada la prueba, busque las secciones **Protocols (Protocolos)** y **Cipher Suites (Conjuntos de cifrado)** del resultado de las pruebas para saber qué protocolos o cifrados admite el origen. Compárelos con la lista que aparece en [Protocolos y cifrados admitidos entre CloudFront y el origen](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## El certificado SSL/TLS del origen ha caducado, no es válido, es autofirmado o el orden de la cadena de certificados es incorrecto
Si el servidor de origen devuelve lo siguiente, CloudFront interrumpe la conexión TCP, devuelve el código de estado HTTP 502 (gateway incorrecta) y establece el encabezado `X-Cache` en `Error from cloudfront`:
+ Un certificado caducado
+ Un certificado no válido
+ Un certificado autofirmado
+ Orden incorrecto en una cadena de certificados
**nota**
Si no está presente la cadena completa de certificados, incluidos los certificados intermedios, CloudFront interrumpe la conexión TCP.
Para obtener más información acerca de cómo instalar un certificado SSL/TLS en su servidor de origen personalizado, consulte [Exigencia de HTTPS para la comunicación entre CloudFront y su origen personalizado](using-https-cloudfront-to-custom-origin.md).
## El origen no responde en puertos especificados en la configuración de origen
Al crear un origen en la distribución de CloudFront, puede definir los puertos que CloudFront conecta con el origen para el tráfico HTTP y HTTPS. De forma predeterminada, estos son 80/443 TCP. Puede modificar estos puertos. Si el origen rechaza el tráfico en estos puertos por cualquier motivo, o si el servidor backend no está respondiendo en los puertos, CloudFront no se conectará.
Para solucionar estos problemas, revise los firewalls de su infraestructura y compruebe que no estén bloqueando los rangos de IP admitidos. Para obtener más información, consulte [Rangos de dirección IP de AWS](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) en la *Guía del usuario de Amazon VPC*. Compruebe también si su servidor web se ejecuta en el origen.
## Error de validación de Lambda
Si utiliza Lambda@Edge, un código de estado HTTP 502 puede indicar que la respuesta de la función Lambda tenía un formato incorrecto o incluía contenido no válido. Para obtener más información sobre la resolución de errores Lambda@Edge, consulte [Prueba y depuración de funciones de Lambda@Edge](lambda-edge-testing-debugging.md).
## Error de validación de la función de CloudFront
Si utiliza CloudFront Functions, un código de estado HTTP 502 puede indicar que la función de CloudFront intenta agregar, eliminar o cambiar un encabezado de solo lectura. Este error no aparece durante las pruebas, pero aparecerá después de implementar la función y ejecutar la solicitud. Para corregir este error, compruebe y actualice la función de CloudFront. Para obtener más información, consulte [Actualización de funciones](update-function.md).
## Error de DNS (`NonS3OriginDnsError`)
Un error HTTP 502 con el código de error `NonS3OriginDnsError` indica que hay un problema de configuración de DNS que impide que CloudFront se conecte al origen. Si recibe este error de CloudFront, asegúrese de que la configuración de DNS del origen es correcta y funciona.
Cuando CloudFront recibe una solicitud de un objeto que ha caducado o que no está en su caché, realiza una solicitud al origen para obtener el objeto. Para que la solicitud al origen se complete correctamente, CloudFront realiza una resolución de DNS en el dominio de origen. Si el servicio de DNS para el dominio tiene problemas, CloudFront no puede resolver el nombre de dominio para obtener la dirección IP, lo que se traduce en un error HTTP 502 (`NonS3OriginDnsError`). Para solucionar este problema, contacte con el proveedor de DNS o, si está utilizando Amazon Route 53, consulte [¿Por qué no puedo acceder a mi sitio web que utiliza los servicios DNS de Route 53?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)
Para solucionar este problema, asegúrese de que los [servidores de nombres autoritativos](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) del dominio raíz o ápex de zona (como `example.com`) del origen funcionan correctamente. Puede utilizar los siguientes comandos para encontrar los servidores de nombres del origen de ápex, con una herramienta como [dig](https://en.wikipedia.org/wiki/Dig_(command)) o [nslookup](https://en.wikipedia.org/wiki/Nslookup):
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
Una vez tenga los nombres de los servidores de nombres, utilice los siguientes comandos para consultar el nombre de dominio del origen ante ellos para asegurarse de que cada uno de ellos genera una respuesta:
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**importante**
Asegúrese de realizar esta solución de problemas de DNS con un equipo que esté conectado a la Internet pública. CloudFront resuelve el dominio de origen mediante un DNS público en Internet, por lo que es importante solucionar los problemas en un contexto similar.
Si el origen es un subdominio cuya autoridad de DNS está delegada en un servidor de nombres diferente al dominio raíz, asegúrese de que los registros del servidor de nombres (`NS`) y el inicio de la autoridad (`SOA`) estén configurados correctamente para el subdominio. Puede comprobar estos registros mediante comandos similares a los de los ejemplos anteriores.
Para obtener más información sobre DNS, consulte los [conceptos del sistema de nombres de dominio (DNS)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns) en la documentación de Amazon Route 53.
## Error 502 originado por el equilibrador de carga de aplicación
Si utiliza equilibrador de carga de aplicación como origen y recibe un error 502, consulte [¿Cómo soluciono los errores HTTP 502 del equilibrador de carga de aplicación?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors).
## Error 502 de origen de API Gateway
Si utiliza API Gateway y recibe un error 502, consulte [¿Cómo resuelvo los errores HTTP 502 de las API de REST de API Gateway con la integración de proxy de Lambda?](https://repost.aws/knowledge-center/malformed-502-api-gateway).
# Código de estado HTTP 503 (Servicio no disponible)
El código de estado HTTP 503 (Servicio no disponible) suele indicar un problema de desempeño en el servidor de origen. En casos excepcionales, indica que CloudFront no puede satisfacer temporalmente una solicitud debido a restricciones de recursos en una ubicación periférica.
Si utiliza Lambda@Edge o CloudFront Functions, puede que el problema se deba a un error de ejecución o a un error de superación de límite de Lambda@Edge.
**Topics**
+ [El servidor de origen no tiene capacidad suficiente para soportar la tasa de solicitudes](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront ha causado el error debido a las restricciones de recursos en la ubicación de borde](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Error de ejecución de la Lambda@Edge o CloudFront Function](#http-503-lambda-execution-error)
+ [Superación del límite de Lambda@Edge](#http-503-lambda-limit-exceeded-error)
## El servidor de origen no tiene capacidad suficiente para soportar la tasa de solicitudes
Cuando un servidor de origen no está disponible o no puede atender solicitudes entrantes, devuelve un código de estado HTTP 503 (servicio no disponible). En ese caso, CloudFront devuelve el error al usuario. Para resolver este problema, pruebe lo siguiente:
+ **Si utiliza Amazon S3 como servidor de origen**:
+ puede realizar al 3500 solicitudes PUT/COPY/POST/DELETE o 5500 solicitudes GET/HEAD por segundo y prefijo de Amazon S3 dividido. Cuando Amazon S3 devuelve una respuesta 503 Slow Down, normalmente indica una tasa de solicitudes excesiva con respecto a un prefijo de Amazon S3 específico.
Como las tasas de solicitud se aplican por prefijo en un bucket de S3, los objetos deben distribuirse entre varios prefijos. A medida que la tasa de solicitudes de los prefijos aumenta gradualmente, Amazon S3 se escala para gestionar las solicitudes de cada uno de los prefijos por separado. Como resultado, la tasa general de solicitudes que gestiona el bucket es un múltiplo del número de prefijos.
+ Para obtener más información, consulte [Optimizar el rendimiento de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) en la *Guía del usuario de Amazon Simple Storage Service*.
+ **Si utiliza Elastic Load Balancing como servidor de origen**:
+ Asegúrese de que sus instancias de backend puedan responder a las comprobaciones de estado.
+ Asegúrate de que el equilibrador de carga y las instancias de backend puedan gestionar la carga.
Para obtener más información, consulte:
+ [Cómo puedo solucionar los errores 503 devueltos al utilizar un equilibrador de carga clásico?](https://repost.aws/knowledge-center/503-error-classic)
+ [How do I troubleshoot 503 (service unavailable) errors from my Application Load Balancer?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Si utiliza un origen personalizado**:
+ Revise los registros la aplicación para garantizar que su origen cuenta con suficientes recursos, como memoria, CPU y tamaño de disco.
+ Si utiliza Amazon EC2 como backend, asegúrese de que el tipo de instancia cuente con los recursos apropiados para responder adecuadamente a las solicitudes entrantes. Para obtener más información, consulte [Tipos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la *Guía del usuario de Amazon EC2*.
+ **Si utiliza API Gateway**:
+ Este error está relacionado con la integración del backend cuando la API de API Gateway no puede recibir una respuesta. El servidor backend:
+ Podría estar sobrecargado por encima de su capacidad y no puede procesar las solicitudes de nuevos clientes.
+ Podría estar en mantenimiento temporal.
+ Para resolver este error, consulte los registros de las aplicaciones de API Gateway para determinar si hay algún problema con la capacidad del backend, la integración o algún otro problema.
## CloudFront ha causado el error debido a las restricciones de recursos en la ubicación de borde
Recibirá este error en la improbable situación de que CloudFront no pueda dirigir las solicitudes hacia la siguiente mejor ubicación periférica disponible y, por tanto, no pueda satisfacer una solicitud. Este es un error común al realizar pruebas de carga en la distribución de CloudFront. Para ayudar a evitarlo, siga las instrucciones de [Pruebas de carga de CloudFront](load-testing.md) para evitar errores 503 (Capacidad superada).
Si esto ocurre en su entorno de producción, póngase en contacto con [Soporte](https://console.aws.amazon.com/support/home#/).
## Error de ejecución de la Lambda@Edge o CloudFront Function
Si utiliza Lambda@Edge o CloudFront Functions, un código de estado HTTP 503 puede indicar que la función de ha devuelto un error de ejecución.
Para obtener más información acerca de cómo identificar y resolver errores de Lambda@Edge, consulte [Prueba y depuración de funciones de Lambda@Edge](lambda-edge-testing-debugging.md).
Para obtener más información acerca de las pruebas de CloudFront Functions, consulte [Prueba de funciones](test-function.md).
## Superación del límite de Lambda@Edge
Si utiliza Lambda@Edge, un código de estado HTTP 503 puede indicar que Lambda ha devuelto un error. Esto podría deberse a una de las siguientes causas:
+ El número de ejecuciones de la función superó una de las cuotas que Lambda establece para restringir las ejecuciones en una Región de AWS (ejecuciones simultáneas o frecuencia de invocación).
+ La función superó la cuota de tiempo de espera de la función Lambda.
Para obtener más información sobre las cuotas de Lambda@Edge, consulte [Cuotas de Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). Para obtener más información acerca de cómo identificar y resolver errores de Lambda@Edge, consulte [Prueba y depuración de funciones de Lambda@Edge](lambda-edge-testing-debugging.md). También puede consultar las [cuotas del servicio Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) en la *Guía para desarrolladores de AWS Lambda*.
# Código de estado HTTP 504 (Tiempo de espera de puerta de enlace agotado)
Un código de estado HTTP 504 (tiempo de espera de puerta de enlace superado) indica que cuando CloudFront reenvió una solicitud al origen (porque el objeto solicitado no estaba en la caché perimetral), se produjo alguna de las siguientes circunstancias:
+ El origen devolvió un código de estado HTTP 504 a CloudFront.
+ El origen no respondió antes de que la solicitud caducara.
CloudFront devolverá un código de estado HTTP 504 si un firewall o grupo de seguridad bloquea el tráfico al origen o si el origen no es accesible en Internet. Compruebe en primer lugar si ocurren estos problemas. A continuación, si el acceso no es el problema, explore los retrasos de la aplicación y los tiempos de espera del servidor para ayudarle a identificar y corregir los problemas.
**Topics**
+ [Configurar el firewall en su servidor de origen para permitir el tráfico de CloudFront](#http-504-gateway-timeout-configure-firewall)
+ [Configurar los grupos de seguridad en su servidor de origen para permitir el tráfico de CloudFront](#http-504-gateway-timeout-configure-security-groups)
+ [Hacer que su servidor de origen personalizado sea accessible en Internet](#http-504-gateway-timeout-make-origin-accessible)
+ [Buscar y corregir respuestas con retardo desde aplicaciones en su servidor de origen](#http-504-gateway-timeout-slow-application)
## Configurar el firewall en su servidor de origen para permitir el tráfico de CloudFront
Si el firewall en el servidor de origen bloquea el tráfico de CloudFront, CloudFront devuelve un código de estado HTTP 504, por lo que es recomendable asegurarse de que este no es el problema antes de comprobar otros problemas.
El método que se utiliza para determinar si se trata de un problema con su firewall depende del sistema que utiliza su servidor de origen:
+ Si utiliza un firewall IPTable en un servidor Linux, puede buscar herramientas e información para ayudarle a trabajar con IPTables.
+ Si utiliza Windows Firewall en un servidor de Windows, consulte [Agregar o editar regla de firewall](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) en la documentación de Microsoft.
Al evaluar la configuración del firewall en su servidor de origen, busque las reglas de firewalls o de seguridad que bloquean el tráfico desde ubicaciones de borde de CloudFront, en función del intervalo de direcciones IP publicado. Para obtener más información, consulte [Ubicaciones e intervalos de direcciones IP de servidores de borde de CloudFront](LocationsOfEdgeServers.md).
Si el intervalo de direcciones IP de CloudFront tiene permiso para conectarse al servidor de origen, asegúrese de actualizar las reglas de seguridad del servidor para incorporar los cambios. Puede suscribirse a un tema de Amazon SNS y recibir notificaciones cuando se actualiza el archivo del rango de direcciones IP. Después de recibir la notificación, puede utilizar código para recuperar el archivo, analizarlo y realizar ajustes para el entorno local. Para obtener más información, consulte [Suscribirse a cambios de direcciones IP públicas de AWS mediante Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/) en el blog de noticias de AWS.
## Configurar los grupos de seguridad en su servidor de origen para permitir el tráfico de CloudFront
Si su origen usa Elastic Load Balancing, revise los [grupos de seguridad de ELB](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) y asegúrese de que los grupos de seguridad permiten el tráfico de entrada desde CloudFront.
También puede utilizar AWS Lambda para actualizar de manera automática sus grupos de seguridad para permitir el tráfico entrante desde CloudFront.
## Hacer que su servidor de origen personalizado sea accessible en Internet
Si CloudFront no puede acceder al servidor de origen personalizado porque no está disponible públicamente en Internet, devuelve un error HTTP 504.
Las ubicaciones de borde de CloudFront se conectan con los servidores de origen a través de Internet. Si el origen personalizado se encuentra en una red privada, CloudFront no puede tener acceso a él. Por este motivo, no puede utilizar servidores privados, incluidos [equilibradores de carga clásicos internos](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), como servidores de origen con CloudFront.
Para comprobar que el tráfico de Internet puede conectarse a su servidor de origen, ejecute los siguientes comandos (donde *OriginDomainName* es el nombre de dominio de su servidor):
Para tráfico HTTPS:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
Para el tráfico HTTP:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## Buscar y corregir respuestas con retardo desde aplicaciones en su servidor de origen
Los tiempos de espera superados del servidor suelen deberse a que la aplicación tarda mucho en responder o a que se ha establecido un valor de tiempo de espera demasiado bajo.
Una solución rápida que ayuda a evitar errores HTTP 504 consiste sencillamente en establecer un valor de tiempo de espera de CloudFront mayor para su distribución. Sin embargo, le recomendamos que primero se asegure de corregir los problemas de desempeño y de latencia con la aplicación y el servidor de origen. A continuación, puede establecer un valor de tiempo de espera razonable que ayude a evitar errores HTTP 504 y proporcione buena capacidad de respuesta a los usuarios.
A continuación, se muestra información general de los pasos que puede seguir para buscar problemas de desempeño y corregirlos:
1. Mida la latencia típica y de carga elevada (capacidad de respuesta) de su aplicación web.
1. Añada recursos adicionales, como CPU o memoria, si es necesario. Tome otras medidas para corregir problemas como, por ejemplo, ajuste de consultas de base de datos para dar cabida a supuestos de carga elevada.
1. Si es necesario, ajuste el valor de tiempo de espera de su distribución de CloudFront.
A continuación se muestran los detalles de cada paso.
### Medir la latencia típica y de carga elevada
Para determinar si uno o más servidores de aplicación web de backend experimentan una alta latencia, ejecute el siguiente comando curl de Linux en cada servidor:
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**nota**
Si ejecuta Windows en sus servidores, puede buscar y descargar curl para Windows para ejecutar un comando similar.
A medida que mide y evalúa la latencia de una aplicación que se ejecuta en su servidor, tenga en cuenta lo siguiente:
+ Los valores de latencia son relativos a cada aplicación. Sin embargo, un valor de Tiempo hasta el primer byte en milisegundos en lugar de segundos o más, es razonable.
+ Si mide la latencia de la aplicación con carga normal y está bien, tenga en cuenta que es posible que los espectadores sigan sufriendo tiempos de espera con cargas elevadas. Cuando hay una demanda alta, es posible que los servidores tengan respuestas con retraso o que no respondan. Para ayudarle a evitar problemas de latencia de carga elevada, compruebe los recursos del servidor tales como CPU, memoria y lecturas y escrituras en disco para asegurarse de que los servidores tengan la capacidad de escalar una carga elevada.
Puede ejecutar los siguientes comandos de Linux para comprobar la memoria que utilizan los procesos de Apache:
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ Una utilización de CPU alta en el servidor puede reducir notablemente el desempeño de una aplicación. Si utiliza una instancia Amazon EC2 para su servidor backend, revise las métricas de CloudWatch del servidor para comprobar la utilización de la CPU. Para obtener más información, consulte la [Guía del usuario de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). O bien, si está utilizando un servidor propio, consulte la documentación de ayuda del servidor para obtener instrucciones sobre cómo comprobar el uso de la CPU.
+ Compruebe si hay otros posibles problemas con cargas elevadas, como, por ejemplo, consultas de base de datos que se ejecutan lentamente cuando hay un gran volumen de solicitudes.
### Agregar recursos y ajustar servidores y bases de datos
Después de evaluar la capacidad de respuesta de las aplicaciones y servidores, asegúrese de que dispone de recursos suficientes para las situaciones de tráfico normal y de carga elevada:
+ Si tiene su propio servidor, asegúrese de tener suficiente CPU, memoria y espacio en disco para gestionar las solicitudes de los espectadores, en función de su evaluación.
+ Si utiliza una instancia Amazon EC2 como servidor backend, asegúrese de que el tipo de instancia cuente con los recursos apropiados para responder adecuadamente a las solicitudes entrantes. Para obtener más información, consulte [Tipos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la *Guía del usuario de Amazon EC2*.
Además, tenga en cuenta los siguientes pasos de ajuste para ayudar a evitar tiempos de espera:
+ Si el valor Tiempo hasta el primer byte que devuelve el comando curl parece alto, tome medidas para mejorar el desempeño de su aplicación. Mejorar la capacidad de respuesta de la aplicación a su vez reduce los errores de tiempo de espera.
+ Ajuste las consultas de la base de datos para asegurarse de que puedan administrar volúmenes de solicitudes elevados sin un desempeño lento.
+ Configure conexiones [keep-alive (persistente)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) en su servidor de backend. Esta opción ayuda a evitar las latencias que se producen cuando las conexiones deben volver a establecerse para las solicitudes o usuarios posteriores.
+ **Si utiliza Elastic Load Balancing como origen**, las siguientes son las posibles causas de un error 504:
+ El equilibrador de carga no consigue establecer una conexión con el destino antes de que expire el tiempo de espera de la conexión (10 segundos).
+ El equilibrador de carga establece una conexión con el destino pero este no responde antes de que transcurra el periodo de tiempo de espera de inactividad.
+ La lista de control de acceso (ACL) de red para la subred no permite el tráfico desde los destinos a los nodos del equilibrador de carga en los puertos efímeros (1024-65535).
+ El destino devuelve un encabezado de longitud de contenido que es mayor que el cuerpo de la entidad. Se agota el tiempo del equilibrador de carga a la espera de los bytes que faltan.
+ El destino es una función de Lambda y Lambda no responde antes de que se agote el tiempo de espera de la conexión.
Para obtener más información sobre cómo reducir la latencia, consulte [¿Cómo soluciono una alta latencia en mi equilibrador de carga clásico de ELB?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)
+ **Si utiliza MediaTailor como origen**, las siguientes son las posibles causas de un error 504:
+ Si se gestionan mal las URL relativas, MediaTailor puede recibir URL con formato incorrecto de los reproductores.
+ Si MediaPackage es el origen del manifiesto para MediaTailor, los errores de manifiesto 404 de MediaPackage pueden provocar que MediaTailor devuelva un error 504.
+ La solicitud al servidor de origen MediaTailor tarda más de dos segundos en completarse.
+ **Si utiliza Amazon API Gateway como origen**, la siguiente es una posible causa de un error 504:
+ Una solicitud de integración tarda más que su parámetro de tiempo máximo de integración de la API de REST de API Gateway. Para obtener más información, consulte [¿Cómo soluciono los errores de tiempo de espera HTTP 504 de la API con API Gateway?](https://repost.aws/knowledge-center/api-gateway-504-errors)
### Si es necesario, ajuste el valor de tiempo de espera de CloudFront
Si ha evaluado y solucionado el desempeño de aplicaciones lento, la capacidad del servidor de origen y otros problemas, pero los espectadores siguen experimentando errores HTTP 504, entonces debería plantearse cambiar el tiempo especificado en su distribución para tiempo de espera de respuesta de origen. Para obtener más información, consulte [Tiempo de espera de respuesta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).