HTTPCodice di stato 504 (Gateway Timeout) - Amazon CloudFront
Configura il firewall sul tuo server di origine per consentire il traffico CloudFront Configura i gruppi di sicurezza sul tuo server di origine per consentire CloudFront il trafficoRendere accessibile su Internet il proprio server di origine personaleTrovare e correggere il ritardo nelle risposte dalle applicazioni sul server di origine

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à.

HTTPCodice di stato 504 (Gateway Timeout)

Un codice di stato HTTP 504 (gateway timeout) indica che quando viene CloudFront inoltrata una richiesta all'origine (perché 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.

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:

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 .

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. Puoi iscriverti a un SNS argomento Amazon 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 sul AWS News Blog.

Configura i gruppi di sicurezza sul tuo server di origine per consentire CloudFront il traffico

Se la tua origine utilizza Elastic Load Balancing, esamina i gruppi ELB di sicurezza e assicurati che i gruppi 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 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, come server di origine con. CloudFront

Per verificare che il traffico Internet possa connettersi al server di origine, esegui i seguenti comandi (dove OriginDomainName è il nome di dominio del tuo server):

Per il HTTPS traffico:

  • nc -zv OriginDomainName 443

  • telnet OriginDomainName 443

Per il HTTP traffico:

  • nc -zv OriginDomainName 80

  • telnet OriginDomainName 80

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 gli errori HTTP 504 consiste semplicemente nell'impostare un valore di CloudFront timeout più elevato 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 aiuti a prevenire gli errori HTTP 504 e offra 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.

  2. Se necessario, aggiungete risorse aggiuntive, CPU ad esempio memoria. Adotta altre misure per risolvere i problemi, ad esempio il tuning delle query del database in base a scenari a elevato carico.

  3. Se necessario, modifica il valore di timeout per la 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 evitare problemi di latenza elevata, controllate le risorse del server, come CPU la memoria e le operazioni di lettura e scrittura su disco, per assicurarvi che i server abbiano la capacità di scalare in caso di carichi elevati.

    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"

  • Un elevato CPU utilizzo sul server può ridurre in modo significativo le prestazioni di un'applicazione. Se utilizzi un'EC2istanza Amazon per il tuo server di backend, esamina i CloudWatch parametri del server per verificarne l'CPUutilizzo. Per ulteriori informazioni, consulta la Amazon CloudWatch User Guide. Oppure, se utilizzi il tuo server, consulta la documentazione della guida del server per istruzioni su come verificarne CPU l'utilizzo.

  • 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 server personale, assicurati che disponga di memoria e spazio su disco sufficienti CPU per gestire le richieste dei visualizzatori, in base alla tua valutazione.

  • Se utilizzi un'EC2istanza Amazon come server di backend, assicurati che il tipo di istanza disponga delle risorse appropriate per soddisfare le richieste in arrivo. Per ulteriori informazioni, consulta i tipi di istanza nella Amazon EC2 User Guide.

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) 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 possibili cause dell'errore 504 sono le seguenti:

    • Il load balancer non riesce a stabilire una connessione alla destinazione prima della scadenza del timeout di connessione (10 secondi).

    • Il load balancer stabilisce una connessione alla destinazione, ma la destinazione non risponde prima che sia trascorso il periodo di timeout di inattività.

    • La lista di controllo dell'accesso alla rete (ACL) per la sottorete non consente il traffico dalle destinazioni ai nodi di bilanciamento del carico sulle porte temporanee (1024-65535).

    • La destinazione ha restituito un'intestazione content-length più grande del corpo dell'entità. Il load balancer scade in attesa dei byte mancanti.

    • L'obiettivo è una funzione Lambda e Lambda non risponde prima della scadenza del timeout della connessione.

    Per ulteriori informazioni sulla riduzione della latenza, vedi Come posso risolvere i problemi di latenza elevata sul mio Classic Load ELB Balancer?

  • Se si utilizza MediaTailor come origine, le seguenti sono le possibili cause dell'errore 504:

    • 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 Amazon API Gateway come origine, la causa possibile dell'errore 504 è la seguente:

Se necessario, modifica il valore di timeout CloudFront

Se avete valutato e risolto il problema del rallentamento delle prestazioni delle applicazioni, della capacità del server di origine e di altri problemi, ma gli utenti continuano a riscontrare errori HTTP 504, allora dovreste prendere in considerazione la possibilità di modificare l'ora specificata nella distribuzione per il timeout della risposta di origine. Per ulteriori informazioni, consulta Timeout di risposta (solo origini personalizzate).