Risolvi i problemi di Cloud CDN

Scopri i passaggi per la risoluzione dei problemi che potrebbero esserti utili se riscontri i problemi riportati di seguito utilizzando Cloud CDN.

Se il problema che riscontri riguarda i backend esterni, consulta anche Risolvere i problemi relativi ai backend esterni e ai NEG internet.

Problemi generali e soluzioni

Questa sezione descrive alcuni problemi comuni e le relative soluzioni.

Le risposte non vengono memorizzate nella cache

Se le risposte non vengono memorizzate nella cache, controlla innanzitutto che la CDN di Cloud sia attivata per il servizio o il bucket di backend. Quando abiliti Cloud CDN, potrebbero essere necessarie minuti prima che le risposte inizino a essere memorizzate nella cache.

Cloud CDN memorizza nella cache solo le risposte con . Queste informazioni vengono trasmesse nelle intestazioni di risposta 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 tuo backend.

Esistono diversi modi per controllare le intestazioni delle risposte:

L'esempio seguente mostra l'utilizzo di curl per controllare la risposta HTTP intestazioni 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

Confrontando queste intestazioni con il comando cacheable contenuti rivelano che la risposta non ha l'intestazione Cache-Control richiesta (supponendo che la cache è impostata su USE_ORIGIN_HEADERS).

Il metodo per impostare le intestazioni dipende dal tipo di server di origine. Se un server web su Compute Engine, consulta la documentazione documentazione per i dettagli sulla configurazione delle intestazioni delle risposte. Per Cloud Storage, contrassegnando l'oggetto come condiviso pubblicamente fa sì che le intestazioni appropriate.

Dopo aver riconfigurato il server di origine per aggiungere l'intestazione richiesta, puoi utilizzare curl di nuovo per controllare 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 di questo esempio include un'intestazione Age. Cloud CDN aggiunge un'intestazione Age alle risposte che serve dalla cache. Qui, l'intestazione indica che la risposta è stata fornita correttamente da utilizzando una voce della cache creata due secondi fa.

Inoltre, se ETags sono abilitate sulle istanze di backend, Cloud CDN si basa sugli ETag per confermare l'aggiornamento dell'oggetto. Se le istanze di backend gestiscono ETag diversi sullo stesso oggetto, Cloud CDN conteggia le mancate corrispondenze come un fallimento della cache e aggiorna il . Per evitare questo problema, le istanze di backend devono gestire lo stesso ETag o gli ETag devono essere disabilitati.

Per verificarlo, esegui curl ripetutamente e controlla le modifiche nel valore ETag:

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 gli URL firmati o concedere l'accesso pubblico al bucket e a tutti i suoi oggetti per allUsers.

Se decidi di fornire l'accesso allUsers, puoi verificare l'accesso a livello di oggetto come segue:

Console

  1. Nella console Google Cloud, apri il browser Cloud Storage.

    Apri il browser Storage

  2. Fai clic su un bucket per visualizzare la pagina Dettagli bucket.

  3. Nella colonna Accesso pubblico, tieni il puntatore sopra la sull'icona a forma di punto esclamativo e fai clic su Modifica accesso.

    Per ogni oggetto nel bucket, assicurati che la seguente autorizzazione sia imposta:

    • Entità: utente
    • Nome: allUsers
    • Accesso: lettore

Per saperne di più sul controllo dell'accesso per Cloud Storage, consulta Documentazione di Identity and Access Management (IAM) per Cloud Storage.

Per scoprire di più sugli URL firmati, vedi Utilizzo di 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 o 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, invalidare le cache di Cloud CDN utilizzando la seguente procedura:

  1. Assicurati che il server di origine non restituisca più contenuti privati o errati.
  2. 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 Panoramica dell'annullamento della convalida della cache.

Cloud CDN memorizza nella cache solo le risposte con e restituisce le risposte dalla cache solo fino alla scadenza specificata nel risposta. Se non sai perché i contenuti sono stati memorizzati nella cache o non riesci a risolvere il problema in modo pratico, ti consigliamo di disattivare Cloud CDN finché non riesci a comprendere e risolvere il problema, quindi di riattivarlo. Per ulteriori informazioni su quali contenuti vengono memorizzati nella cache e per quanto tempo, consulta la panoramica della memorizzazione nella cache.

La percentuale di successi della cache è bassa

Per ottenere prestazioni e scalabilità, è importante ottimizzare i successi della cache proporzioni. Se riscontri rapporti di successo della cache inferiori a quelli previsti, assicurati di seguire le per ottimizzare i successi della cache rapporto.

Utilizza la seguente tabella per comprendere alcuni dei possibili motivi di un calo percentuale successi cache e potenziali correzioni.

Motivi Commenti Correzioni
I tuoi contenuti non sono memorizzabili nella cache. Una risposta memorizzabile nella cache è una risposta HTTP che Cloud CDN può memorizzare. Assicurati che i tuoi contenuti siano memorizzabile nella cache.
La modalità cache non è ottimale per la tua applicazione. Cloud CDN offre modalità cache. Se non utilizzi le intestazioni di controllo della cache per controllare il comportamento della memorizzazione nella cache, la best practice consigliata per consentire a Cloud CDN di memorizzare nella cache contenuti.
Il traffico è ridotto. Durante i test e la sperimentazione, la quantità di traffico che ricevi generati è probabilmente basso. Google ha un cache distribuita globale e richieste da località geografiche diverse accedono a diversi frontend Google luoghi. In ogni località frontend, Google può avere più istanze della cache.
  • Assicurati che sia stato inviato a Google un volume di traffico sufficiente a tutte le cache pertinenti.
  • Durante il test, assicurati di eseguire lo sharding del traffico in base all'URL, in modo che il traffico per ogni insieme di richieste va a Google. Non eseguire lo sharding in modo casuale ciascuna richiesta a un provider CDN diverso.
Le risposte per determinati URL non vengono memorizzate nella cache. Cloud CDN incorpora l'URI della richiesta completo nella propria cache chiavi, quindi http://example.com/cat.jpg?color=orange e http://example.com/cat.jpg?color=gray hanno una cache separata le voci corrispondenti. Usa sempre un singolo URL per una determinata risorsa.

Se devi superare a JavaScript in esecuzione su una pagina altrimenti memorizzabile nella cache, considera utilizzando identificatori di frammenti anziché stringhe di query.
La cache ha uno sharding non necessario a causa dell'intestazione Vary . Il campo dell'intestazione Vary in una risposta descrive quali parti di un messaggio di richiesta (a parte il metodo, il campo dell'intestazione Vary e il target della richiesta) potrebbero influire sul processo del server di origine per la selezione e la rappresentazione di una risposta. Ad esempio, potresti voler utilizzare l'intestazione Vary: Accept-Encoding se pubblichi contenuti diversi per i client che possono gestire le risposte compresse e per quelli che non possono. Utilizza l'intestazione della risposta Vary solo quando necessario.
Non stai utilizzando chiavi cache personalizzate. Per impostazione predefinita, Cloud CDN utilizza l'URL della richiesta completo per creare la chiave cache. Puoi personalizzare le chiavi della cache in modo da includere o omettere qualsiasi combinazione di protocollo, host e stringa di query. Ad esempio, se due usano gli stessi contenuti statici, puoi creare una chiave cache personalizzata che omette il campo host. Utilizza chiavi di cache personalizzate, se necessario.

Esistono più riempimenti della cache per gli stessi contenuti

In generale, puoi ridurre il numero di riempimenti della cache aumentando di scadenza delle risposte memorizzabili nella cache. A parità di condizioni, noti meno riempimenti della cache per una risposta con Cache-Control: public, max-age=86400 di uno con Cache-Control: public, max-age=1.

Per ulteriori informazioni sulle tempistiche di scadenza, consulta Tempi di scadenza e richieste di convalida. Per informazioni su come configurare le intestazioni appropriate delle risposte, consulta per il software del server web.

Cloud CDN gestisce numerose cache in tutto il mondo e le vecchie voci della cache vengono regolarmente eliminate per fare spazio ai nuovi contenuti. Di conseguenza, si prevedono più riempimenti della cache per risorsa durante il normale funzionamento.

La compressione non funziona

Cloud CDN offre la compressione dinamica per origini che non possono comprimere le loro risposte. Se possibile, ti consigliamo di utilizzare la compressione all'origine perché riduce la cache costi di riempimento.

Se le risposte pubblicate da Cloud CDN non sono compresse, ma dovrebbero esserlo, controlla che il software del server web in esecuzione sulle tue istanze sia configurato per comprimere le risposte. Per impostazione predefinita, alcuni software del server web disabilita 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. Proxy HTTP come Application Load Balancer esterno, aggiungi un 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 indicargli di comprimere le risposte anche se la richiesta conteneva un'intestazione Via.

Se utilizzi il software del server web nginx, modifica il file di configurazione nginx.conf per attivare la compressione. La posizione di questo file dipende da dove è installato nginx. Nel 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 e le due righe seguenti alla sezione http di nginx.conf:

gzip_proxied any;
gzip_vary on;

  • La prima riga abilita la compressione anche per le richieste inoltrate da un proxy come il bilanciatore del carico delle applicazioni esterno.

  • La seconda riga aggiunge un'intestazione Vary: Accept-Encoding alle risposte. Vary: Accept-Encoding invia una notifica ai proxy di memorizzazione nella cache come Cloud CDN deve mantenere voci di cache separate per varianti compresse e non compresse di risorse comprimibili.

Dopo aver modificato nginx.conf, devi riavviare nginx prima che utilizzi il nuovo configurazione. In molte distribuzioni Linux, puoi riavviare nginx eseguendo 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 intervalli di byte, controlla se questi intervalli provengono dalla stessa versione della risorsa confrontando le intestazioni di risposta ETag e Last-Modified. Se Cloud CDN rileva che il valore entrambe le intestazioni non sono coerenti con gli intervalli già pubblicati per il cliente interrompe la risposta.

Se noti risposte terminate inaspettate, Voci di log di Cloud Logging con byte_range_caching_aborted statusDetails, o la restituzione delle tue istanze risposte 412 Precondition Failed, verifica che il software del server web sia in esecuzione su tutte le istanze di macchine virtuali (VM) restituisce gli stessi valori ETag Last-Modified valori per una determinata risorsa.

Quando si gestiscono file dal disco, capita spesso al software del server web di ricavare i ETag e Last-Modified dalla data e ora di modifica del file. In questo caso, puoi assicurarti che le istanze VM registrino valori coerenti utilizzando la stessa immagine per tutte le istanze. Per informazioni dettagliate su come il software del web server determina i valori ETag e Last-Modified, consulta la documentazione del software del web server.

Risoluzione dei problemi relativi ai cookie firmati

Quando utilizzando cookie firmati.

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 il metodo Variante sicura per URL con base64. Standard base64 ha esito negativo quando i caratteri generati non sono URL in tutta sicurezza. È accettata la spaziatura interna.

Firma

La tua richiesta è stata rifiutata da Cloud CDN.

  • Assicurati di utilizzare HMAC-SHA-1 come algoritmo di firma e non un altro variante di HMAC.

  • Verifica che il parametro KeyName (sensibile alle maiuscole) corrisponda a un nome chiave valido per il servizio 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 che URLPrefix contenga solo i componenti schema, host e percorso (parziale) dell'URL.

  • Assicurati che il blocco della firma, ovvero URLPrefix, Expires, KeyName e il valore Signature stesso, siano le ultime sezioni delimitate da : del cookie.

  • Assicurati che URLPrefix, Expires, KeyName e Signature si verifichino in tale ordine.

  • Non includere un asterisco (*) alla fine di un URLPrefix in un 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 emetti e richiedono inviare ai tuoi client poiché molti server web hanno anche un'intestazione di richiesta massima limiti.

  • Assicurati di utilizzare i due punti (:) e il punto di codice Unicode. U+003A, come delimitatore per i parametri denominati in un cookie firmato, e non la e commerciale (&).

  • Assicurati che il timestamp Expires sui cookie che stai inviando inutilmente brevi. Periodi di validità inferiori a uno o due minuti possono essere soggetto a problemi di disallineamento orologio tra l'app emittente e l'infrastruttura Cloud CDN.

  • Assicurati di non impostare più cookie per lo stesso Domain e Path con valori diversi. Imposta un singolo cookie per utente con un URL valore di prefisso che comprende tutti i contenuti a cui l'utente deve accedere.

Messaggi di errore

Questa sezione fornisce informazioni su alcuni messaggi di errore comuni e su come risolverle.

Errori di invalidazione 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 /, non deve contenere ? o # e deve avere un solo *, che deve essere un carattere finale dopo un /.

I percorsi non devono contenere più di 1024 caratteri. Se ricevi questo controlla il valore del percorso e correggi eventuali errori di formato.

Questo errore riguarda solo il formato del percorso. Un percorso che formato valido, che però non esiste, viene comunque considerato valido.
Rate Limit Exceeded Cloud CDN limita la frequenza con cui possono essere eseguite le operazioni di annullamento della convalida della cache. È consentita una sola invalidazione al minuto. Tuttavia, ogni operazione può specificare un pattern di percorso che corrisponde a qualsiasi numero di oggetti.

Problemi noti

  • Le invalidazioni della cache sono limitate a una invalidazione per mappa URL al minuto.

    Soluzione: 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 Limitazioni.