Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Risoluzione dei problemi relativi ai codici di stato della risposta agli errori in CloudFront
Se CloudFront richiede un oggetto dall'origine e l'origine restituisce un codice di stato HTTP 4xx o 5xx, c'è un problema di comunicazione tra CloudFront e l'origine.
Questo argomento include anche i passaggi per la risoluzione dei problemi relativi a questi codici di stato quando si utilizza Lambda @Edge o CloudFront Functions.
Gli argomenti seguenti forniscono spiegazioni dettagliate delle potenziali cause alla base di queste risposte di errore e offrono step-by-step indicazioni su come diagnosticare e risolvere i problemi sottostanti.
**Topics**
+ [Codice di stato HTTP 400 (richiesta errata)](http-400-bad-request.md)
+ [Codice di stato HTTP 401 (Non autorizzato)](http-401-unauthorized.md)
+ [Codice di stato HTTP 403 (Metodo non valido)](http-403-invalid-method.md)
+ [Codice di stato HTTP 403 (Autorizzazione negata)](http-403-permission-denied.md)
+ [Codice di stato HTTP 404 (Non trovato)](http-404-not-found.md)
+ [Codice di stato HTTP 412 (Precondizione non riuscita)](http-412-precondition-failed.md)
+ [Codice di stato HTTP 500 (Errore interno del server)](http-500-internal-server-error.md)
+ [Codice di stato HTTP 502 (Gateway non valido)](http-502-bad-gateway.md)
+ [Codice stato HTTP 503 (Servizio non disponibile)](http-503-service-unavailable.md)
+ [Codice di stato HTTP 504 (Timeout del gateway)](http-504-gateway-timeout.md)
# Codice di stato HTTP 400 (richiesta errata)
CloudFront restituisce una richiesta non valida 400 quando il client invia alcuni dati non validi nella richiesta, ad esempio contenuti mancanti o errati nel payload o nei parametri. Questo potrebbe anche rappresentare un errore generico del client.
## L’origine Amazon S3 restituisce un errore 400
Se utilizzi un'origine Amazon S3 con la tua CloudFront distribuzione, questa potrebbe inviare risposte di errore con il codice di stato HTTP 400 Bad Request e un messaggio simile al seguente:
*L'intestazione di autorizzazione non è valida; la regione '' è sbagliata; è prevista ** '' ***
Esempio:
*The authorization header is malformed; the region 'us-east-1' is wrong; expecting 'us-west-2'* (Intestazione di autorizzazione non corretta; la regione 'us-east-1' è errata; attesa 'us-west-2')
Questo problema può verificarsi nel seguente scenario:
1. L'origine della tua CloudFront distribuzione è un bucket Amazon S3.
1. Hai spostato il bucket S3 da una regione all'altra AWS . Cioè, hai eliminato il bucket S3, quindi successivamente hai creato un nuovo bucket con lo stesso nome di bucket, ma in una AWS regione diversa da quella in cui si trovava il bucket S3 originale.
Per correggere questo errore, aggiorna la CloudFront distribuzione in modo che trovi il bucket S3 nella regione corrente del bucket. AWS
**Per aggiornare la tua distribuzione CloudFront**
1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Scegliere la distribuzione che causa questo errore.
1. Scegliere **Origins and Origin Groups (Origini e gruppi di origini)**.
1. Individuare l'origine del bucket S3 spostato. Selezionare la casella di controllo accanto a questa origine, quindi scegliere **Edit (Modifica)**.
1. Seleziona **Yes, Edit (Sì, modifica)**. Non è necessario modificare alcuna impostazione prima di scegliere **Yes, Edit (Sì, modifica)**.
Una volta completati questi passaggi, CloudFront ridistribuisce la distribuzione. Durante l’implementazione della distribuzione, nella colonna **Data ultima modifica** viene visualizzato lo stato **Implementazione in corso**. Qualche tempo dopo il completamento dell’implementazione, non si dovrebbero più ricevere risposte di errore `AuthorizationHeaderMalformed`.
## L’origine Application Load Balancer restituisce un errore 400
Se utilizzi un'origine Application Load Balancer con la tua CloudFront distribuzione, le possibili cause di un errore 400 includono le seguenti:
+ Il client ha inviato una richiesta con un formato errato che non soddisfa le specifiche HTTP.
+ L’intestazione della richiesta supera il limite di 16 KB per riga di richiesta, 16 KB per singola intestazione o 64 KB per l’intera intestazione della richiesta.
+ Il client ha chiuso la connessione prima di inviare l'intero corpo della richiesta.
# Codice di stato HTTP 401 (Non autorizzato)
Un codice di stato della risposta 401 Non autorizzato indica che la richiesta del client non è stata completata perché mancano credenziali di autenticazione valide per la risorsa richiesta. Questo codice di stato viene inviato con un’intestazione di risposta `WWW-Authenticate` HTTP che contiene informazioni su come il client può richiedere nuovamente la risorsa dopo aver eseguito il prompt all’utente delle credenziali di autenticazione. Per ulteriori informazioni, consulta [401 Non autorizzato](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401).
In CloudFront, se l'origine prevede che un'`Authorization`intestazione autentichi le richieste, CloudFront deve inoltrare l'`Authorization`intestazione all'origine per evitare un errore 401 Unauthorized. Quando CloudFront inoltra una richiesta di visualizzazione all'origine, per impostazione predefinita CloudFront rimuove alcune intestazioni del visualizzatore, inclusa l'intestazione. `Authorization` Per assicurarti che l'origine riceva sempre l'intestazione `Authorization` nelle richieste di origine, sono disponibili le seguenti opzioni:
+ Aggiungi l’intestazione `Authorization` alla chiave della cache utilizzando una policy della cache. Tutte le intestazioni nella chiave cache vengono incluse automaticamente nelle richieste di origine. Per ulteriori informazioni, consulta [Controllo della chiave della cache con una policy](controlling-the-cache-key.md).
+ Utilizzare una policy di richiesta di origine che inoltra tutte le intestazioni del visualizzatore all'origine. Non puoi inoltrare l'`Authorization`intestazione singolarmente in una policy di richiesta di origine, ma quando inoltri tutte le intestazioni del visualizzatore, CloudFront include l'intestazione nelle richieste dei `Authorization` visualizzatori. CloudFrontfornisce la politica di richiesta di `AllViewer` origine gestita per questo caso d'uso. Per ulteriori informazioni, consulta [Utilizzo delle policy di richiesta origine gestite](using-managed-origin-request-policies.md).
Per ulteriori informazioni, vedi [Come posso configurare CloudFront per inoltrare l'intestazione di autorizzazione all'origine](https://repost.aws/knowledge-center/cloudfront-authorization-header)?
# Codice di stato HTTP 403 (Metodo non valido)
CloudFront restituisce un errore 403 (metodo non valido) se stai cercando di utilizzare un metodo HTTP che non hai specificato nella distribuzione. CloudFront Puoi specificare una delle seguenti opzioni per la distribuzione:
+ CloudFront solo `GET` inoltri e richieste. `HEAD`
+ CloudFront solo inoltri `GET` e `HEAD` `OPTIONS` richieste.
+ CloudFront inoltri`GET`,`HEAD`,`OPTIONS`, `PUT` `PATCH``POST`, e `DELETE` richieste. Se selezioni questa opzione, potrebbe essere necessario limitare l’accesso al bucket Amazon S3 o all’origine personalizzata in modo che gli utenti non possano eseguire operazioni non desiderate. Ad esempio, è possibile che gli utenti non sia autorizzati a eliminare oggetti dall'origine.
# Codice di stato HTTP 403 (Autorizzazione negata)
Un errore HTTP 403 indica che il client non è autorizzato ad accedere alla risorsa richiesta. Il client comprende la richiesta, ma non può autorizzare l’accesso del visualizzatore. Di seguito sono riportate le cause più comuni della CloudFront restituzione di questo codice di stato:
**Topics**
+ [Il CNAME alternativo è configurato in modo errato](#alternate-cname-incorrectly-configured)
+ [AWS WAF è configurato sulla CloudFront distribuzione o all'origine](#aws-waf-configured-on-distribution-origin)
+ [L’origine personalizzata restituisce un errore 403](#custom-origin-returning-403)
+ [L’origine Amazon S3 restituisce un errore 403](#s3-origin-403-error)
+ [Le restrizioni geografiche restituiscono un errore 403](#geolocation-403)
+ [La configurazione dell’URL o del cookie firmato restituisce un errore 403](#signed-URLs-cookies-403)
+ [Le distribuzioni in pila causano un errore 403](#stacked-distributions-403)
## Il CNAME alternativo è configurato in modo errato
Verifica di aver specificato il CNAME corretto per la distribuzione. Per utilizzare un CNAME alternativo anziché l'URL predefinito CloudFront :
1. Crea un record CNAME nel tuo DNS per indirizzare il CNAME all'URL di distribuzione. CloudFront
1. Aggiungi il CNAME nella tua configurazione di distribuzione. CloudFront
Se crei il record DNS ma non aggiungi il CNAME nella configurazione di CloudFront distribuzione, la richiesta restituisce un errore 403. Per ulteriori informazioni sulla configurazione di un CNAME personalizzato, consulta [Utilizza la funzionalità personalizzata URLs aggiungendo nomi di dominio alternativi () CNAMEs](CNAMEs.md).
## AWS WAF è configurato sulla CloudFront distribuzione o all'origine
Quando si AWS WAF trova tra il client e CloudFront, non è CloudFront possibile distinguere tra un codice di errore 403 restituito dall'origine e un codice di errore 403 restituito da AWS WAF quando una richiesta viene bloccata.
Per trovare l'origine del codice di stato 403, controlla la regola della lista di controllo degli accessi AWS WAF Web (ACL) per una richiesta bloccata. Per ulteriori informazioni, consulta i seguenti argomenti:
+ [AWS WAF elenchi di controllo degli accessi web (web) ACLs](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Test e ottimizzazione delle protezioni AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## L’origine personalizzata restituisce un errore 403
Se utilizzi un’origine personalizzata, potresti ricevere un errore 403 se disponi di una configurazione firewall personalizzata a livello di origine. Per risolvere il problema, invia la richiesta direttamente all’origine. Se riesci a replicare l'errore senza farlo CloudFront, allora l'origine sta causando l'errore 403.
Se l’origine personalizzata causa l’errore, controlla i log dell’origine per identificare la causa dell’errore. Per ulteriori informazioni, consulta i seguenti argomenti relativi alla risoluzione dei problemi:
+ [Come posso risolvere gli errori HTTP 403 da Gateway API?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Come posso risolvere gli errori vietati HTTP 403 di Application Load Balancer?](https://repost.aws/knowledge-center/alb-http-403-error)
## L’origine Amazon S3 restituisce un errore 403
L’errore 403 può essere visualizzato per i seguenti motivi:
+ CloudFront non ha accesso al bucket Amazon S3. Questo può accadere se l’identità di accesso origine (OAI) o il controllo di accesso origine (OAC) non sono abilitati per la distribuzione e il bucket è privato.
+ Il percorso specificato nell’URL richiesto non è corretto.
+ L’oggetto richiesto non esiste.
+ L’intestazione dell’host è stata inoltrata con l’endpoint REST API. Per ulteriori informazioni, consulta [Specifica del bucket nell’intestazione HTTP Host](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket) nella *Guida per l’utente di Amazon Simple Storage Service*.
+ Hai configurato le pagine di errore personalizzate. Per ulteriori informazioni, consulta [In che modo CloudFront elabora gli errori quando sono state configurate pagine di errore personalizzate](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Le restrizioni geografiche restituiscono un errore 403
Se hai abilitato le restrizioni geografiche (note anche come geoblocking) per impedire agli utenti in aree geografiche specifiche di accedere ai contenuti che stai distribuendo tramite una CloudFront distribuzione, gli utenti bloccati ricevono un errore 403.
Per ulteriori informazioni, consulta [Limitazione della distribuzione geografica del contenuto](georestrictions.md).
## La configurazione dell’URL o del cookie firmato restituisce un errore 403
Se hai abilitato l'opzione **Limita l'accesso degli spettatori** per la configurazione del comportamento della tua distribuzione, le richieste che non utilizzano cookie firmati o firmati generano un URLs errore 403. Per ulteriori informazioni, consulta i seguenti argomenti:
+ [Offri contenuti privati con cookie firmati URLs e firmati](PrivateContent.md)
+ [Come posso risolvere i problemi relativi a un URL firmato o ai cookie registrati? CloudFront](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Le distribuzioni in pila causano un errore 403
Se sono presenti due o più distribuzioni all'interno di una catena di richieste all'endpoint di origine, CloudFront restituisce un errore 403. Si sconsiglia di posizionare una distribuzione davanti a un’altra.
# Codice di stato HTTP 404 (Non trovato)
CloudFront restituisce un errore 404 (Not Found) quando il client tenta di accedere a una risorsa che non esiste. Se ricevete questo errore con la vostra CloudFront distribuzione, le cause più comuni includono le seguenti:
+ La risorsa non esiste.
+ L’URL non è corretto.
+ Origine personalizzata che restituisce un errore 404.
+ Pagine di errore personalizzate che restituiscono un errore 404. Qualsiasi codice di errore potrebbe essere tradotto in 404. Per ulteriori informazioni, consulta [In che modo CloudFront elabora gli errori quando sono state configurate pagine di errore personalizzate](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ Pagina di errore personalizzata eliminata accidentalmente, con conseguente errore 404 perché la richiesta cerca la pagina di errore personalizzata eliminata. Per ulteriori informazioni, consulta [Come CloudFront elabora gli errori se non hai configurato pagine di errore personalizzate](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Percorso di origine errato. Se il percorso di origine è compilato, il relativo valore viene aggiunto al percorso di ciascuna richiesta proveniente dal browser prima che la richiesta venga inoltrata all’origine. Per ulteriori informazioni, consulta [Percorso origine](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# Codice di stato HTTP 412 (Precondizione non riuscita)
CloudFront restituisce un codice di errore 412 (Precondition Failed) quando l'accesso alla risorsa di destinazione è stato negato. In alcuni casi, un server è configurato per accettare richieste solo dopo che sono state soddisfatte determinate condizioni. Se una delle condizioni specificate non è soddisfatta, il server non consente al client di accedere alla risorsa specificata. Invece, il server risponde con un codice di errore 412.
Le cause più comuni di un errore 412 includono: CloudFront
+ Richieste condizionali su metodi diversi da `GET` o `HEAD` quando la condizione definita dalle intestazioni `If-Unmodified-Since` o `If-None-Match` non è soddisfatta. In tal caso, la richiesta, in genere un caricamento o una modifica di una risorsa, non può essere effettuata.
+ Una condizione in uno o più campi di richiesta nell'operazione CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)API viene valutata come falsa.
# Codice di stato HTTP 500 (Errore interno del server)
Un codice di stato HTTP 500 (Errore interno del server) indica che il server ha riscontrato una condizione imprevista che gli ha impedito di soddisfare la richiesta. Di seguito sono riportate alcune delle cause più comuni di 500 errori in Amazon CloudFront.
**Topics**
+ [Il server Origin restituisce l'errore 500 a CloudFront](#origin-server-500-error)
## Il server Origin restituisce l'errore 500 a CloudFront
Il tuo server di origine potrebbe restituire un errore 500 a CloudFront. Per ulteriori informazioni, consulta i seguenti argomenti relativi alla risoluzione dei problemi:
+ **Se Amazon S3 restituisce un errore 500**, consulta [Come faccio a risolvere un errore HTTP 500 o 503 di Amazon S3?](https://repost.aws/knowledge-center/http-5xx-errors-s3)
+ **Se Gateway API restituisce un errore 500**, consulta [Come posso risolvere gli errori 5xx per REST API di Gateway API?](https://repost.aws/knowledge-center/api-gateway-5xx-error).
+ **Se Elastic Load Balancing restituisce un errore 500**, consulta [HTTP 500: Internal server error](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) nella *Guida per l’utente di Application Load Balancer*.
Se l'elenco precedente non risolve l'errore 500, il problema potrebbe riguardare un CloudFront punto di presenza che restituisce un errore interno del server. Puoi contattare [Supporto](https://console.aws.amazon.com/support/home#/) per ricevere assistenza.
# Codice di stato HTTP 502 (Gateway non valido)
CloudFront restituisce un codice di stato HTTP 502 (Bad Gateway) quando CloudFront non è stato in grado di servire l'oggetto richiesto perché non è riuscito a connettersi al server di origine.
Se utilizzi Lambda@Edge, il problema potrebbe essere un errore di convalida Lambda. Se ricevi un errore HTTP 502 con il codice di `NonS3OriginDnsError` errore, probabilmente c'è un problema di configurazione DNS che CloudFront impedisce la connessione all'origine.
**Topics**
+ [Errore di negoziazione SSL/TLS tra e un server di origine personalizzato CloudFront](#ssl-negotitation-failure)
+ [L'origine non risponde con crittografie/protocolli supportati](#origin-not-responding-with-supported-ciphers-protocols)
+ [Il certificato SSL/TLS sull'origine è scaduto, non valido, autofirmato oppure l'ordine della catena di certificati non è corretto](#ssl-certificate-expired)
+ [L'origine non risponde sulle porte specificate nelle impostazioni dell'origine](#origin-not-responding-on-specified-ports)
+ [Errore di convalida Lambda](#http-502-lambda-validation-error)
+ [CloudFront errore di convalida della funzione](#http-502-cloudfront-function-validation-error)
+ [Errore DNS (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Errore 502 dell’origine Application Load Balancer](#cloudfront-alb-502-error)
+ [Errore 502 dell’origine Gateway API](#cloudfront-api-gateway-502-error)
## Errore di negoziazione SSL/TLS tra e un server di origine personalizzato CloudFront
Se utilizzi un'origine personalizzata che richiede HTTPS tra CloudFront e la tua origine, i nomi di dominio non corrispondenti potrebbero causare errori. Il SSL/TLS certificato di origine *deve* includere un nome di dominio che corrisponda al **dominio di origine** specificato per la CloudFront distribuzione o all'`Host`intestazione della richiesta di origine.
Se i nomi di dominio non corrispondono, l' SSL/TLS handshake ha esito negativo e CloudFront restituisce un codice di stato HTTP 502 (Bad Gateway) e imposta l'`X-Cache`intestazione su. `Error from cloudfront`
Per determinare se i nomi di dominio nel certificato corrispondono a **Dominio origine** nella distribuzione o nell’intestazione `Host`, puoi utilizzare uno strumento di verifica SSL online o OpenSSL. Se i nomi di dominio non corrispondono, hai due opzioni:
+ Ottieni un nuovo SSL/TLS certificato che includa i nomi di dominio applicabili.
Se utilizzi AWS Certificate Manager (ACM), consulta [Richiesta di un certificato pubblico](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) nella *Guida per l'AWS Certificate Manager utente* per richiedere un nuovo certificato.
+ Modifica la configurazione di distribuzione in modo che CloudFront non tenti più di utilizzare SSL per connetterti con la tua origine.
### Strumento di verifica SSL online
Per trovare uno strumento di verifica SSL, cerca "online ssl checker" su Internet. In genere, si specifica il nome del dominio e lo strumento restituisce una serie di informazioni sul SSL/TLS certificato. Conferma che il certificato contiene il tuo nome di dominio nel campo **Nomi comuni** o **Nomi alternativi oggetto**.
### OpenSSL
Per risolvere gli errori HTTP 502 di CloudFront, puoi usare OpenSSL per provare a stabilire una connessione al tuo server di origine. SSL/TLS Se OpenSSL non è in grado di effettuare una connessione è possibile che vi sia un problema con la configurazione SSL/TLS del server di origine. Se OpenSSL è in grado di stabilire una connessione, restituisce le informazioni sul certificato del server di origine, inclusi il nome comune (campo `Subject CN`) del certificato e il nome alternativo dell'oggetto (campo `Subject Alternative Name`).
Usa il seguente comando OpenSSL per testare la connessione al tuo server di origine (*origin domain*sostituiscilo con il nome di dominio del server di origine, ad esempio example.com):
`openssl s_client -connect origin domain name:443`
Se sono vere le seguenti condizioni:
+ Il server di origine supporta più nomi di dominio con più certificati SSL/TLS
+ La distribuzione è configurata per inoltrare l'intestazione `Host` all'origine
Quindi aggiungi l'`-servername`opzione al comando OpenSSL, come nell'esempio seguente (*CNAME*sostituisci con il CNAME configurato nella tua distribuzione):
`openssl s_client -connect origin domain name:443 -servername CNAME`
## L'origine non risponde con crittografie/protocolli supportati
CloudFront si connette ai server di origine utilizzando cifrari e protocolli. Per un elenco dei cifrari e dei protocolli supportati CloudFront , vedere. [Protocolli e cifrari supportati tra e l'origine CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md) Se l'origine non risponde con uno di questi codici o protocolli nello scambio SSL/TLS, non riesce a connettersi. CloudFront Puoi verificare che la tua origine supporta protocolli e le crittografie utilizzando un tool online come [SSL Labs](https://www.ssllabs.com/ssltest). Digita il nome di dominio dell'origine nel campo **Hostname (Nome host)**, quindi scegli **Submit (Invia)**. Esamina i campi **Common names (Nomi comuni)** e **Alternative names (Nomi alternativi)** del test per sapere se corrispondono al nome di dominio dell'origine. Al termine del test, trova le sezioni **Protocols (Protocolli)** e **Cipher Suites (Pacchetti crittografia)** nei risultati del test per sapere quali crittografie o protocolli sono supportati dalla tua origine. Confrontali con l'elenco in [Protocolli e cifrari supportati tra e l'origine CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## Il certificato SSL/TLS sull'origine è scaduto, non valido, autofirmato oppure l'ordine della catena di certificati non è corretto
Se il server di origine restituisce quanto segue, CloudFront interrompe la connessione TCP, restituisce il codice di stato HTTP 502 (Bad Gateway) e imposta l'intestazione su: `X-Cache` `Error from cloudfront`
+ Certificato scaduto
+ Certificato non valido
+ Certificato autofirmato
+ Ordine della catena di certificati non corretto
**Nota**
Se l'intera catena di certificati, incluso il certificato intermedio, non è presente, la connessione TCP viene interrotta CloudFront .
Per informazioni sull'installazione di un SSL/TLS certificato sul server di origine personalizzato, consulta. [Richiedi HTTPS per la comunicazione tra CloudFront e la tua origine personalizzata](using-https-cloudfront-to-custom-origin.md)
## L'origine non risponde sulle porte specificate nelle impostazioni dell'origine
Quando crei un'origine sulla tua CloudFront distribuzione, puoi impostare le porte con cui CloudFront si connette all'origine per il traffico HTTP e HTTPS. Per impostazione predefinita, queste porte sono TCP 80/443. Hai comunque la possibilità di modificare queste porte. Se la tua origine rifiuta il traffico su queste porte per qualsiasi motivo o se il tuo server di backend non risponde sulle porte, non CloudFront riuscirà a connettersi.
Per risolvere questi problemi, verifica tutti i firewall in esecuzione nell'infrastruttura e assicurati che non blocchino gli intervalli di indirizzi IP. Per ulteriori informazioni, consulta [Intervalli di indirizzi IP AWS](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) nella *Guida per l’utente di Amazon VPC*. Inoltre, verifica se il server Web è in esecuzione sull'origine.
## Errore di convalida Lambda
Se utilizzi Lambda@Edge, un codice di stato HTTP 502 può indicare che la risposta della funzione Lambda non è stata correttamente formata o che include contenuti non validi. Per ulteriori informazioni sulla risoluzione di errori Lambda@Edge, consulta [Test e debug delle funzioni Lambda@Edge](lambda-edge-testing-debugging.md).
## CloudFront errore di convalida della funzione
Se utilizzi CloudFront funzioni, un codice di stato HTTP 502 può indicare che la CloudFront funzione sta tentando di aggiungere, eliminare o modificare un'intestazione di sola lettura. Questo errore non viene visualizzato durante il test, ma verrà visualizzato dopo aver distribuito la funzione ed eseguito la richiesta. Per risolvere questo errore, controlla e aggiorna la tua funzione. CloudFront Per ulteriori informazioni, consulta [Aggiornamento delle funzioni](update-function.md).
## Errore DNS (`NonS3OriginDnsError`)
Un errore HTTP 502 con il codice `NonS3OriginDnsError` di errore indica che esiste un problema di configurazione DNS che CloudFront impedisce la connessione all'origine. Se ricevi questo errore da CloudFront, assicurati che la configurazione DNS dell'origine sia corretta e funzionante.
Quando CloudFront riceve una richiesta per un oggetto scaduto o non presente nella cache, invia una richiesta all'origine per ottenere l'oggetto. Per effettuare una richiesta corretta all'origine, CloudFront esegue una risoluzione DNS sul dominio di origine. Se il servizio DNS per il tuo dominio presenta problemi, non CloudFront riesci a risolvere il nome di dominio per ottenere l'indirizzo IP, generando un errore HTTP 502 (). `NonS3OriginDnsError` Per risolvere il problema, contatta il tuo provider DNS oppure, se utilizzi Amazon Route 53, consulta [Perché non riesco ad accedere al mio sito Web che utilizza i servizi DNS di Route 53?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)
Per risolvere il problema, accertati inoltre che i [server dei nomi autorevoli](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) del dominio root o dell'apex di zona dell'origine (ad esempio `example.com`) funzionino correttamente. Puoi usare i seguenti comandi per trovare i server dei nomi per l'origine apex, con uno strumento come [dig](https://en.wikipedia.org/wiki/Dig_(command)) o [nslookup](https://en.wikipedia.org/wiki/Nslookup):
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
Quando disponi dei nomi del server dei nomi, utilizza i comandi seguenti per eseguire una query sul nome di dominio dell'origine in base a tali nomi per assicurarti che ognuno risponda:
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**Importante**
Assicurati di eseguire questa risoluzione dei problemi DNS utilizzando un computer connesso alla rete Internet pubblica. CloudFront risolve il dominio di origine utilizzando DNS pubblico su Internet, quindi è importante risolvere i problemi in un contesto simile.
Se l'origine è un dominio secondario la cui autorità DNS è delegata a un server di nomi diverso dal dominio principale, assicurati che il record del server dei nomi (`NS`) e il record di origine di autorità (`SOA`) siano configurati correttamente per il dominio secondario. È possibile verificare la presenza di questi record utilizzando comandi simili agli esempi precedenti.
Per ulteriori informazioni sul DNS, consulta i [concetti del sistema dei nomi di dominio (DNS)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns) nella documentazione di Amazon Route 53.
## Errore 502 dell’origine Application Load Balancer
Se utilizzi Application Load Balancer come origine e ricevi un errore 502, consulta [Come posso risolvere i problemi relativi agli errori HTTP 502 del mio Application Load Balancer?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors).
## Errore 502 dell’origine Gateway API
Se utilizzi API Gateway e ricevi un errore 502, vedi [Come posso risolvere gli errori HTTP 502 da API Gateway REST con l'integrazione del proxy APIs Lambda](https://repost.aws/knowledge-center/malformed-502-api-gateway)? .
# Codice stato HTTP 503 (Servizio non disponibile)
Un codice di stato HTTP 503 (Servizio non disponibile) in genere indica un problema di prestazioni sul server di origine. In rari casi, indica che CloudFront temporaneamente non è possibile soddisfare una richiesta a causa di vincoli di risorse in una posizione periferica.
Se utilizzi Lambda @Edge o CloudFront Functions, il problema potrebbe essere un errore di esecuzione o un errore Lambda @Edge in cui è stato superato il limite.
**Topics**
+ [Il server di origine non dispone di capacità sufficiente per supportare la frequenza delle richieste](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront ha causato l'errore a causa di vincoli di risorse nell'edge location](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda @Edge o errore di esecuzione CloudFront della funzione](#http-503-lambda-execution-error)
+ [Limite Lambda@Edge superato](#http-503-lambda-limit-exceeded-error)
## Il server di origine non dispone di capacità sufficiente per supportare la frequenza delle richieste
Quando un server di origine non è disponibile o non è in grado di soddisfare le richieste in arrivo, restituisce un codice di stato HTTP 503 (servizio non disponibile). CloudFront quindi inoltra l'errore all'utente. Per risolvere questo problema, prova le seguenti soluzioni:
+ **Se utilizzi Amazon S3 come server di origine**:
+ Puoi inviare 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD richieste al secondo per prefisso Amazon S3 partizionato. Quando Amazon S3 restituisce una risposta 503 Slow Down, ciò indica in genere un tasso di richieste eccessivo rispetto a un prefisso Amazon S3 specifico.
Poiché le frequenze di richieste si applicano per prefisso in un bucket S3, gli oggetti devono essere distribuiti su più prefissi. Man mano che la frequenza di richieste sui prefissi aumenta gradualmente, Amazon S3 aumenta verticalmente per gestire separatamente le richieste per ciascuno dei prefissi. Di conseguenza, la frequenza di richieste complessiva gestita dal bucket è un multiplo del numero di prefissi.
+ Per maggiori informazioni, consulta la sezione [Ottimizzazione delle prestazioni di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
+ **Se utilizzi Elastic Load Balancing come server di origine**:
+ Assicurati che le istanze di backend siano in grado di rispondere ai controlli dell’integrità.
+ Assicurati che il bilanciatore del carico e le istanze di backend siano in grado di gestire il carico.
Per ulteriori informazioni, consulta:
+ [Come posso risolvere gli errori 503 che ricevo quando utilizzo un Classic Load Balancer?](https://repost.aws/knowledge-center/503-error-classic)
+ [Come posso risolvere gli errori 503 (servizio non disponibile) dal mio Application Load Balancer?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Se utilizzi un’origine personalizzata**:
+ Esamina i log dell’applicazione per accertarti che l’origine disponga di risorse sufficienti, ad esempio CPU, memoria e spazio su disco.
+ Se utilizzi Amazon EC2 come back-end, assicurati che il tipo di istanza disponga delle risorse appropriate per soddisfare le richieste in entrata. Per maggiori informazioni, consulta [ Tipi di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) nella *Guida per l'utente di Amazon EC2*.
+ **Se utilizzi Gateway API**:
+ Questo errore è correlato all’integrazione backend quando l’API di Gateway API non è in grado di ricevere una risposta. Il server di backend potrebbe essere:
+ Sovraccaricato oltre la capacità e incapace di elaborare nuove richieste client.
+ In manutenzione temporanea.
+ Per risolvere questo errore, esamina i log dell’applicazione Gateway API per determinare se esiste un problema con la capacità backend, l’integrazione o altro.
## CloudFront ha causato l'errore a causa di vincoli di risorse nell'edge location
Riceverai questo errore nella rara situazione in cui non è CloudFront possibile indirizzare le richieste alla successiva migliore edge location disponibile e quindi non è in grado di soddisfare una richiesta. Questo errore è comune quando si eseguono test di carico sulle distribuzioni CloudFront. Per impedire che ciò accada, segui le linee guida [Test di carico CloudFront](load-testing.md) per evitare gli errori 503 (Capacità superata).
Se ciò dovesse verificarsi nell’ambiente di produzione, contatta il [Supporto](https://console.aws.amazon.com/support/home#/).
## Lambda @Edge o errore di esecuzione CloudFront della funzione
Se utilizzi Lambda @Edge o CloudFront Functions, un codice di stato HTTP 503 può indicare che la funzione ha restituito un errore di esecuzione.
Per ulteriori dettagli su come identificare e risolvere gli errori Lambda@Edge, consulta [Test e debug delle funzioni Lambda@Edge](lambda-edge-testing-debugging.md).
Per ulteriori informazioni sul test delle CloudFront funzioni, consulta. [Test delle funzioni](test-function.md)
## Limite Lambda@Edge superato
Se utilizzi Lambda@Edge, un codice di stato HTTP 503 può indicare che Lambda ha restituito un errore. Questo errore potrebbe essere causato da uno dei seguenti motivi.
+ Il numero di esecuzioni di funzioni ha superato una delle quote impostate da Lambda per limitare le esecuzioni in un Regione AWS (esecuzioni simultanee o frequenza di invocazione).
+ La funzione ha superato la quota di timeout della funzione Lambda.
Per ulteriori informazioni sulle quote Lambda@Edge, consulta [Quote di Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). Per ulteriori dettagli su come identificare e risolvere gli errori Lambda@Edge, consulta [Test e debug delle funzioni Lambda@Edge](lambda-edge-testing-debugging.md). Puoi anche consultare le [Service Quotas Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) nella *Guida per gli sviluppatori di AWS Lambda *.
# Codice di stato HTTP 504 (Timeout del gateway)
Un codice di stato HTTP 504 (timeout del gateway) indica che quando viene CloudFront inoltrata una richiesta all'origine (poiché l'oggetto richiesto non era nella cache edge), si verificava una delle seguenti situazioni:
+ L'origine ha restituito un codice di stato HTTP 504 a. CloudFront
+ L'origine non ha risposto prima della scadenza della richiesta.
CloudFront restituirà un codice di stato HTTP 504 se il traffico verso l'origine è bloccato da un firewall o da un gruppo di sicurezza o se l'origine non è accessibile su Internet. Verifica prima se ci sono questi problemi. Quindi, se il problema non è l'accesso, concentrati sui ritardi delle applicazioni e i timeout dei server per identificare e risolvere i problemi.
**Topics**
+ [Configura il firewall sul tuo server di origine per consentire il traffico CloudFront](#http-504-gateway-timeout-configure-firewall)
+ [Configura i gruppi di sicurezza sul tuo server di origine per consentire il traffico CloudFront](#http-504-gateway-timeout-configure-security-groups)
+ [Rendere accessibile su Internet il proprio server di origine personale](#http-504-gateway-timeout-make-origin-accessible)
+ [Trovare e correggere il ritardo nelle risposte dalle applicazioni sul server di origine](#http-504-gateway-timeout-slow-application)
## Configura il firewall sul tuo server di origine per consentire il traffico CloudFront
Se il firewall sul server di origine blocca il CloudFront traffico, CloudFront restituisce un codice di stato HTTP 504, quindi è bene assicurarsi che non sia questo il problema prima di verificare la presenza di altri problemi.
Il metodo utilizzato per determinare se si tratta di un problema con il tuo firewall dipende da quale sistema utilizza il tuo server di origine:
+ Se utilizzi un IPTable firewall su un server Linux, puoi cercare strumenti e informazioni con IPTables cui lavorare.
+ Se utilizzi Windows Firewall su un server Windows, consulta [Add or Edit Firewall Rule (Aggiungere o modificare una regola del firewall)](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) nella documentazione Microsoft.
Quando valuti la configurazione del firewall sul tuo server di origine, cerca eventuali firewall o regole di sicurezza che blocchino il traffico proveniente dalle CloudFront edge location, in base all'intervallo di indirizzi IP pubblicato. Per ulteriori informazioni, consulta [Posizioni e intervalli di indirizzi IP dei server periferici CloudFront](LocationsOfEdgeServers.md).
Se l'intervallo di indirizzi CloudFront IP può connettersi al server di origine, assicurati di aggiornare le regole di sicurezza del server per incorporare le modifiche. È possibile eseguire la sottoscrizione a un argomento Amazon SNS e ricevere notifiche quando il file dell'intervallo di indirizzi IP viene aggiornato. Dopo avere ricevuto la notifica, puoi utilizzare il codice per recuperare il file, analizzarlo e apportare le modifiche necessarie per l'ambiente locale. Per ulteriori informazioni, consulta [Abbonarsi alle modifiche degli indirizzi IP AWS pubblici tramite Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/) nel AWS News Blog.
## Configura i gruppi di sicurezza sul tuo server di origine per consentire il traffico CloudFront
Se la tua origine utilizza Elastic Load Balancing, esamina i gruppi di [sicurezza ELB e assicurati che i gruppi](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) di sicurezza consentano il traffico in entrata da. CloudFront
Puoi anche utilizzarli AWS Lambda per aggiornare automaticamente i tuoi gruppi di sicurezza per consentire il traffico in entrata da. CloudFront
## Rendere accessibile su Internet il proprio server di origine personale
Se non CloudFront riesci ad accedere al tuo server di origine personalizzato perché non è disponibile pubblicamente su Internet, CloudFront restituisce un errore HTTP 504.
CloudFront le edge location si connettono ai server di origine tramite Internet. Se l'origine personalizzata si trova su una rete privata, non è CloudFront possibile raggiungerla. Per questo motivo, non puoi utilizzare server privati, compresi i [Classic Load Balancer interni](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), come server di origine con. CloudFront
Per verificare che il traffico Internet possa connettersi al server di origine, esegui i seguenti comandi (*OriginDomainName*dov'è il nome di dominio del server):
Per il traffico HTTPS:
+ nc -zv 443 *OriginDomainName*
+ *OriginDomainName*telnet 443
Per il traffico HTTP:
+ cnc -zv 80 *OriginDomainName*
+ telnet 80 *OriginDomainName*
## Trovare e correggere il ritardo nelle risposte dalle applicazioni sul server di origine
I timeout del server sono spesso il risultato di un tempo di risposta molto lungo da parte di un'applicazione o di un valore di timeout impostato troppo basso.
Una soluzione rapida per evitare errori HTTP 504 è semplicemente quella di impostare un valore di timeout CloudFront più alto per la distribuzione. Tuttavia, ti consigliamo di verificare innanzitutto come risolvere eventuali problemi di prestazioni e latenza con l'applicazione e il server di origine. Quindi puoi impostare un valore di timeout ragionevole che aiuta a prevenire gli errori HTTP 504 e fornisce una buona reattività agli utenti.
Ecco una panoramica delle fasi che puoi eseguire per individuare i problemi di prestazioni e correggerli:
1. Misura la latenza tipica e a elevato carico (reattività) della tua applicazione Web.
1. Aggiungi risorse aggiuntive, ad esempio CPU o memoria, se necessario. Adotta altre misure per risolvere i problemi, ad esempio il tuning delle query del database in base a scenari a elevato carico.
1. Se necessario, regolate il valore di timeout per la vostra CloudFront distribuzione.
Di seguito sono riportati i dettagli di ciascuna fase.
### Misura la latenza tipica e a elevato carico
Per determinare se uno o più server di applicazioni Web back-end riscontri elevata latenza, esegui il seguente comando curl Linux su ciascun server:
```
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**
Se esegui Windows sui server, puoi cercare e scaricare curl per Windows per eseguire un comando simile.
Quando misuri e valuti la latenza di un'applicazione che viene eseguita sul server, tieni presente quanto segue:
+ I valori di latenza sono relativi a ogni applicazione. Tuttavia, un Time to First Byte (Tempo per il primo byte) in millisecondi anziché secondi o più, è più sensato.
+ Se misuri la latenza dell'applicazione sotto carico normale e non presenta problemi, tieni presente che i visualizzatori potrebbero ancora avere timeout sotto carico elevato. Quando la richiesta è elevata, i server possono avere risposte ritardate o non rispondere affatto. Per prevenire problemi di latenza a causa di un elevato carico, verifica le risorse del server, quali CPU, memoria e letture e scritture sul disco per assicurarti che i server abbiano la capacità di dimensionarsi per un carico elevato.
Puoi eseguire il seguente comando Linux per verificare la memoria utilizzata dai processi Apache:
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ L'elevato utilizzo della CPU sul server può ridurre in modo significativo le prestazioni di un'applicazione. Se utilizzi un'istanza Amazon EC2 per il tuo server di backend, esamina i CloudWatch parametri del server per verificare l'utilizzo della CPU. Per ulteriori informazioni, consulta la [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). Oppure, se utilizzi il tuo server, fai riferimento alla documentazione della Guida del server per istruzioni su come verificare l’utilizzo della CPU.
+ Verifica la presenza di altri potenziali problemi in presenza di carichi elevati, ad esempio query del database che vengono eseguite lentamente in presenza di un elevato volume di richieste.
### Aggiungi le risorse e ottimizza i server e i database
Dopo aver valutato la reattività delle applicazioni e dei server, assicurati di disporre di risorse sufficienti per le situazioni di traffico tipiche e a elevato carico:
+ Se disponi di un tuo server, assicurati che abbia CPU, memoria e spazio su disco sufficiente per gestire le richieste del visualizzatore, in base alla tua valutazione
+ Se utilizzi un'istanza Amazon EC2 come server back-end, assicurati che il tipo di istanza disponga delle risorse appropriate per soddisfare le richieste in entrata. Per maggiori informazioni, consulta [ Tipi di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) nella *Guida per l'utente di Amazon EC2*.
Inoltre, considera le seguenti fasi di tuning per evitare timeout:
+ Se il valore Time to First Byte (Tempo per il primo byte) restituito dal comando curl sembra alto, adotta le misure necessarie per migliorare le prestazioni dell'applicazione. Il miglioramento della reattività delle applicazioni contribuirà a sua volta a ridurre gli errori di timeout.
+ Esegui il tuning delle query del database per assicurarti che siano in grado di gestire volumi di richieste elevate senza rallentare le prestazioni.
+ Configura le connessioni [keep-alive (persistenti)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) sul tuo server di back-end. Questa opzione aiuta a evitare le latenze che si verificano quando le connessioni devono essere ristabilite per le richieste o per gli utenti successivi.
+ **Se utilizzi Elastic Load Balancing come origine**, le seguenti sono le possibili cause di un errore 504:
+ Il bilanciatore del carico non è in grado di stabilire una connessione con la destinazione prima dello scadere del timeout della connessione (10 secondi).
+ Il bilanciatore del carico ha stabilito una connessione con la destinazione, ma la destinazione non ha risposto prima dello scadere del timeout di inattività.
+ La lista di controllo degli accessi alla rete (ACL) nella sottorete non ha consentito il traffico dalle destinazioni ai nodi del bilanciatore del carico sulle porte temporanee (1024-65535).
+ La destinazione ha restituito un'intestazione content-length più grande del corpo dell'entità. Il bilanciatore del carico è scaduto in attesa di byte mancanti.
+ La destinazione è una funzione Lambda e Lambda non ha risposto prima della scadenza del timeout della connessione.
Per ulteriori informazioni sulla riduzione della latenza, consulta [Come posso risolvere i problemi di latenza elevata sul mio ELB Classic Load Balancer?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)
+ **Se utilizzi MediaTailor come origine**, le possibili cause dell'errore 504 sono le seguenti:
+ Se un parente URLs viene maltrattato, MediaTailor può ricevere dei malformati URLs dai giocatori.
+ Se MediaPackage è l'origine manifesta di MediaTailor, MediaPackage 404 errori manifest possono causare MediaTailor la restituzione di un errore 504.
+ Il completamento della richiesta al server di MediaTailor origine richiede più di 2 secondi.
+ **Se utilizzi Gateway Amazon API come origine**, le seguenti sono le possibili cause di un errore 504:
+ Una richiesta di integrazione richiede più tempo rispetto al parametro di timeout massimo di integrazione della REST API di Gateway API. Per ulteriori informazioni, consulta [Come posso risolvere gli errori di timeout con codice di stato HTTP 504 di Gateway API?](https://repost.aws/knowledge-center/api-gateway-504-errors)
### Se necessario, modifica il valore di CloudFront timeout
Se hai valutato e risolto rallentamenti di prestazioni delle applicazioni, anomalie nella capacità del server di origine e altri problemi, ma i visualizzatori riscontrano ancora errori HTTP 504, considera la possibilità di modificare il tempo specificato nella distribuzione per il timeout della risposta del server di origine. Per ulteriori informazioni, consulta [Timeout di risposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).