Scopri i passaggi per la risoluzione dei problemi, utili nel caso in cui si verifichi uno dei seguenti problemi con Cloud CDN.
Se il problema che stai riscontrando è relativo ai backend esterni, consulta anche Risoluzione dei problemi di backend esterno e NEG internet.
Problemi generici e soluzioni
Le risposte non vengono memorizzate nella cache
Se le risposte non vengono memorizzate nella cache, verifica innanzitutto che Cloud CDN sia abilitato per il servizio di backend o il bucket di backend. Quando attivi Cloud CDN, potrebbero essere necessari alcuni minuti prima che le risposte inizino a essere memorizzate nella cache.
Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache. Queste informazioni vengono fornite nelle intestazioni delle risposte HTTP, in combinazione con la configurazione del backend. Se le risposte per un URL non vengono memorizzate nella cache, controlla quali intestazioni vengono restituite per quell'URL e come è configurata la memorizzazione nella cache per il backend.
Esistono diversi modi per controllare le intestazioni delle risposte:
- In Google Chrome, il riquadro Rete di DevTools
- In Mozilla Firefox, lo strumento Developer Tools Network Monitor
- Uno strumento a riga di comando come curl o GNU Wget
Il seguente esempio mostra l'utilizzo di curl
per verificare le intestazioni della risposta HTTP per http://example.com/style.css
:
curl -s -D - -o /dev/null http://example.com/style.css
Output:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google
Il confronto tra queste intestazioni e i requisiti del contenuto memorizzabile nella cache rivela che nella risposta manca l'intestazione Cache-Control
richiesta (supponendo che la modalità cache sia impostata su USE_ORIGIN_HEADERS
).
Il metodo per impostare le intestazioni dipende dal tipo di server di origine. Se esegui un server web su Compute Engine, consulta la documentazione del software del server web per i dettagli sulla configurazione delle intestazioni delle risposte. Per Cloud Storage, se l'oggetto viene contrassegnato come condiviso pubblicamente, vengono inviate le intestazioni appropriate.
Dopo aver riconfigurato il server di origine per aggiungere l'intestazione richiesta, puoi utilizzare di nuovo curl
per verificare il risultato:
curl -s -D - -o /dev/null http://example.com/style.css
Output:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
curl -s -D - -o /dev/null http://example.com/style.css
Output:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
curl -s -D - -o /dev/null http://example.com/style.css
Output:
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2
L'ultima risposta in questo esempio include un'intestazione Age
.
Cloud CDN aggiunge un'intestazione Age
alle risposte che fornisce dalla cache. Qui l'intestazione indica che la risposta è stata fornita correttamente dalla cache utilizzando una voce della cache creata due secondi fa.
Inoltre, se gli ETags sono abilitati sulle istanze di backend, Cloud CDN si affida agli ETag per confermare l'aggiornamento dell'oggetto. Se le istanze di backend pubblicano ETag diversi sullo stesso oggetto, Cloud CDN conteggia le mancate corrispondenze come fallimento della cache e aggiorna l'oggetto. Per evitare questo problema, le istanze di backend devono gestire lo stesso ETag oppure gli ETag devono essere disabilitati.
Per verificare, esegui curl
ripetutamente e controlla se il valore di ETag
è cambiato:
curl -s -D - -o /dev/null http://example.com/image.png
Output:
HTTP/2 200 date: Fri, 20 Mar 2020 15:02:30 GMT server: Apache strict-transport-security: max-age=31536000; includeSubDomains last-modified: Mon, 16 Mar 2020 04:20:59 GMT etag: "10f-5a0f1256f1402" accept-ranges: bytes content-length: 271 cache-control: public, max-age=864000 expires: Mon, 30 Mar 2020 15:02:30 GMT vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff content-type: image/png via: 1.1 google alt-svc: clear
curl -s -D - -o /dev/null http://example.com/image.png
Output:
HTTP/2 200 date: Fri, 20 Mar 2020 15:03:11 GMT server: Apache strict-transport-security: max-age=31536000; includeSubDomains last-modified: Mon, 16 Mar 2020 04:18:31 GMT etag: "10f-5a0f11ca09b7a" accept-ranges: bytes content-length: 271 cache-control: public, max-age=864000 expires: Mon, 30 Mar 2020 15:03:11 GMT vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff content-type: image/png via: 1.1 google alt-svc: clear
Impossibile accedere agli oggetti Cloud Storage
Per fornire l'accesso agli oggetti in Cloud Storage, devi configurare URL firmati o concedere l'accesso pubblico al bucket e a tutti i suoi oggetti per allUsers
.
Se decidi di concedere l'accesso a allUsers
, puoi verificare l'accesso a livello di oggetto
nel seguente modo.
Console
Nella console Google Cloud, apri il browser Cloud Storage.
Fai clic su un bucket per visualizzare la pagina Dettagli bucket.
Nella colonna Accesso pubblico, passa il mouse sopra l'icona a forma di punto esclamativo e fai clic su Modifica accesso.
Per ogni oggetto nel bucket, assicurati che sia impostata la seguente autorizzazione:
- Entità: utente
- Nome: allUsers
- Accesso: lettore
Per ulteriori informazioni sul controllo dell'accesso per Cloud Storage, consulta la documentazione di Identity and Access Management (IAM) per Cloud Storage.
Per scoprire di più sugli URL firmati, consulta la pagina relativa all'utilizzo degli URL firmati.
Se gli oggetti sono accessibili ma non vengono memorizzati nella cache, consulta Le risposte non vengono memorizzate nella cache.
I contenuti privati sono stati memorizzati nella cache oppure i contenuti memorizzati nella cache non sono corretti
Se sai perché il server di origine ha pubblicato contenuti privati o errati e puoi risolvere il problema, puoi invalidare le cache di Cloud CDN utilizzando la seguente procedura:
- Assicurati che il server di origine non restituisca più i contenuti privati o errati.
- Richiedi un'annullamento della convalida della cache per indicare a Cloud CDN di interrompere la pubblicazione dei contenuti memorizzati nella cache.
Per ulteriori informazioni, consulta la panoramica dell'annullamento della convalida della cache.
Cloud CDN memorizza nella cache solo le risposte con contenuti memorizzabili nella cache e fornisce le risposte dalla cache solo fino alla scadenza specificata nella risposta. Se non sai perché i contenuti sono stati memorizzati nella cache o non riesci a risolvere il problema rapidamente, ti consigliamo di disattivare Cloud CDN finché non riesci a comprendere e risolvere il problema, quindi riattivalo. Per ulteriori informazioni su quali contenuti vengono memorizzati nella cache e per quanto tempo, consulta la Panoramica della memorizzazione nella cache.
Il rapporto di successo della cache è basso
Per prestazioni e scalabilità, è importante ottimizzare i report di hit della cache. Se riscontri rapporti di successo della cache inferiori al previsto, assicurati di seguire le best practice per ottimizzare il successo della cache cache.
Utilizza la seguente tabella per comprendere alcuni dei possibili motivi di un rapporto basso di hit della cache e le potenziali correzioni.
Motivi | Commenti | Correzioni |
---|---|---|
I tuoi contenuti non possono essere memorizzati nella cache. | Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può archiviare. | Assicurati che i contenuti possano essere memorizzati nella cache. |
La modalità cache non è ottimale per la tua applicazione. | Cloud CDN offre diverse modalità cache. | Se non utilizzi le intestazioni di controllo della cache per controllare il comportamento della memorizzazione nella cache, la best practice consigliata prevede che Cloud CDN memorizzi nella cache tutti i contenuti statici. |
Il traffico è ridotto. | Durante i test e gli esperimenti, la quantità di traffico generata potrebbe essere bassa. Google dispone di una cache distribuita globale e le richieste provenienti da diverse località geografiche vengono indirizzate a diverse località di frontend di Google. In ogni località di frontend, Google potrebbe avere più istanze discrete della cache. |
|
Le risposte per determinati URL non vengono memorizzate nella cache. | Cloud CDN incorpora l'URI della richiesta completo nelle sue chiavi cache, pertanto http://example.com/cat.jpg?color=orange e
http://example.com/cat.jpg?color=gray hanno voci di cache
separate. |
Utilizza sempre un unico URL per una determinata risorsa. Se devi passare parametri a JavaScript in esecuzione su una pagina che altrimenti è possibile memorizzare nella cache, valuta l'utilizzo di identificatori di frammenti anziché stringhe di query. |
Lo sharding della cache non è necessario a causa del campo di intestazione Vary . |
Il campo di intestazione Vary in una risposta descrive quali parti di un messaggio di richiesta (a parte il metodo, il campo di intestazione Host e la destinazione della richiesta) potrebbero influenzare il processo del server di origine per la selezione e la rappresentazione di una risposta. Ad esempio, potresti utilizzare l'intestazione Vary: Accept-Encoding se pubblichi contenuti diversi per i clienti in grado di gestire risposte compresse e quelle che non possono gestire. |
Utilizza l'intestazione della risposta Vary solo se necessario. |
Non utilizzi chiavi cache personalizzate. | Per impostazione predefinita, Cloud CDN utilizza l'URL della richiesta completo per creare la chiave cache. Puoi personalizzare le chiavi cache in modo da includere o omettere qualsiasi combinazione di protocollo, host e stringa di query. Ad esempio, se due domini utilizzano gli stessi contenuti statici, puoi creare una chiave cache personalizzata che ometta il campo host. | Utilizzare chiavi cache personalizzate, dove necessario. |
Esistono più riempimenti della cache per gli stessi contenuti
In generale, puoi ridurre il numero di riempimenti della cache aumentando i tempi di scadenza delle risposte memorizzabili nella cache. Stando tutto il resto, vedrai meno riempimenti della cache per una risposta con Cache-Control: public, max-age=86400
rispetto a una con Cache-Control: public, max-age=1
.
Per ulteriori informazioni sulle scadenze, consulta Tempi di scadenza e richieste di convalida. Per informazioni sulla configurazione delle intestazioni di risposta appropriate, consulta la documentazione del software del server web.
Cloud CDN gestisce numerose cache in tutto il mondo e le vecchie voci della cache vengono eliminate regolarmente per fare spazio a nuovi contenuti. Di conseguenza, nel normale funzionamento sono previsti più riempimenti della cache per risorsa.
La compressione non funziona
Cloud CDN offre la compressione dinamica per le origini che non possono comprimere le loro risposte. Se possibile, ti consigliamo di utilizzare la compressione all'origine perché riduce i costi di riempimento della cache.
Se le risposte fornite da Cloud CDN non sono compresse, ma dovrebbero
essere, verifica che il software del server web in esecuzione sulle tue istanze sia configurato
per comprimere le risposte. Per impostazione predefinita, alcuni software per server web disattivano automaticamente
la compressione per le richieste che includono un'intestazione Via
. La presenza di un'intestazione Via
indica che la richiesta è stata inoltrata da un proxy. I proxy HTTP come l'Application Load Balancer esterno aggiungono un'intestazione Via
a ogni richiesta come richiesto dalla specifica HTTP.
Per attivare la compressione, potrebbe essere necessario eseguire l'override della configurazione predefinita del server web per indicare di comprimere le risposte anche se la richiesta aveva un'intestazione Via
.
Se utilizzi il software del server web nginx, modifica il file di configurazione nginx.conf
per abilitare la compressione. La posizione di questo file dipende da dove è installato nginx. In molte distribuzioni Linux, il file è archiviato in /etc/nginx/nginx.conf
.
Per consentire il funzionamento della compressione nginx con il bilanciatore del carico delle applicazioni esterno, aggiungi le seguenti due righe alla sezione http
di nginx.conf:
gzip_proxied any; gzip_vary on;
La prima riga consente la compressione anche per le richieste inoltrate da un proxy come l'Application Load Balancer esterno.
La seconda riga aggiunge un'intestazione
Vary: Accept-Encoding
alle risposte.Vary: Accept-Encoding
notifica ai proxy di memorizzazione nella cache come Cloud CDN che devono mantenere voci di cache separate per le varianti compresse e non compresse di risorse comprimibili.
Dopo aver modificato nginx.conf, devi riavviare nginx prima che utilizzi la nuova
configurazione. In molte distribuzioni Linux puoi riavviare nginx
eseguendo l'esecuzione di sudo service nginx restart
o /etc/init.d/nginx restart
.
Le risposte terminano con errori byte_range_caching_aborted
Quando Cloud CDN assembla una risposta da più richieste di intervallo di byte, controlla se questi intervalli provengono dalla stessa versione della risorsa confrontando le intestazioni della risposta ETag
e Last-Modified
. Se Cloud CDN rileva che il valore di un'intestazione non è coerente con gli intervalli che ha già pubblicato per il client, interrompe la risposta.
Se noti risposte terminate impreviste, voci di log di Cloud Logging con byte_range_caching_aborted
statusDetails o le tue istanze che restituiscono risposte 412 Precondition Failed
, assicurati che il software del server web in esecuzione su tutte le istanze di macchine virtuali (VM) restituisca gli stessi valori ETag
e Last-Modified
per una determinata risorsa.
Durante la pubblicazione di file dal disco, di solito il software del server web ricava i valori ETag
e Last-Modified
dalla data e ora di modifica del file. In questo caso, puoi assicurarti che le istanze VM riportino valori coerenti utilizzando la stessa immagine per tutte le istanze. Per informazioni dettagliate su come il software del server web determina i valori ETag
e Last-Modified
, consulta la documentazione del software del server web.
Risoluzione dei problemi relativi ai cookie firmati
Quando utilizzi cookie firmati, possono verificarsi i seguenti problemi.
Codifica
Quando generi una firma, la richiesta viene rifiutata inaspettatamente a causa di una mancata corrispondenza della firma.
Quando codifichi i valori URL
e Signature
, assicurati di utilizzare la variante sicura per l'URL di base64. Il formato base64 standard ha esito negativo quando i caratteri generati non sono sicuri per l'URL. La spaziatura interna è accettata.
Firma
La tua richiesta è stata rifiutata da Cloud CDN.
Assicurati di utilizzare HMAC-SHA-1 come algoritmo di firma e non un'altra variante di HMAC.
Conferma che il parametro
KeyName
(sensibile alle maiuscole) corrisponde a un nome chiave valido per il servizio di backend o il bucket di backend in uso da Cloud CDN.Non firmare parametri di ricerca durante la generazione e la firma di un
URLPrefix
. Assicurati cheURLPrefix
contenga solo i componenti dello schema, dell'host e del percorso (parziali) dell'URL.Assicurati che il blocco della firma (
URLPrefix
,Expires
,KeyName
eSignature
stesso) siano le ultime sezioni del cookie delimitate da:
.Assicurati che i valori
URLPrefix
,Expires
,KeyName
eSignature
vengano eseguiti in questo ordine.Non includere un asterisco (
*
) alla fine diURLPrefix
in un cookie firmato.
Cookie
In genere i browser limitano i cookie a 4 kB per dominio, con un limite di 50 cookie per dominio in totale. Prendi nota degli altri cookie che invii e che i tuoi client devono inviare, in quanto molti server web hanno anche limiti massimi di intestazione delle richieste.
Assicurati di utilizzare i due punti (
:
), il punto di codice UnicodeU+003A
, come delimitatore per i parametri denominati in un cookie firmato, non la e commerciale (&
).Assicurati che il timestamp
Expires
sui cookie che stai inviando non sia inutilmente breve. I periodi di validità inferiori a uno o due minuti potrebbero essere soggetti a problemi di disallineamento tra l'app emittente e l'infrastruttura Cloud CDN.Assicurati di non impostare più cookie per gli stessi valori
Domain
ePath
con valori diversi. Imposta un singolo cookie per utente con un valore del prefisso URL che includa tutti i contenuti a cui l'utente deve accedere.
Messaggi di errore
Errori di annullamento della convalida della cache
Codice di errore | Note |
---|---|
Invalid value for field 'resource.path' |
Il formato del valore del percorso non è valido. I percorsi devono iniziare con un
I percorsi non devono contenere più di 1024 caratteri. Se ricevi questo errore, controlla il valore del percorso e correggi eventuali errori di formato. Questo errore riguarda solo il formato del percorso. Un percorso in formato valido, ma che non esiste, viene comunque considerato valido. |
Rate Limit Exceeded |
Cloud CDN limita la frequenza con cui possono essere eseguite le operazioni di invalidazione della cache. È consentita una sola annullamento della convalida al minuto. Tuttavia, ogni operazione può specificare un pattern del percorso che corrisponde a un numero qualsiasi di oggetti. |
Problemi noti
Le invalidazioni della cache sono limitate a un'annullamento per mappa URL al minuto.
Risoluzione: attendi almeno un minuto prima di provare a invalidare un'altra mappa URL.
Per ulteriori informazioni sulla limitazione di frequenza di invalidazione della cache, consulta la sezione Limitazioni.