Dépannage

Découvrez les étapes de dépannage pouvant être utiles si vous rencontrez les problèmes suivants avec Cloud CDN.

Si le problème que vous rencontrez est lié aux origines personnalisées, consultez également la section Résoudre les problèmes liés à l'origine personnalisée et aux NEG Internet.

Problèmes d'ordre général et solutions

Les réponses ne sont pas mises en cache

Si les réponses ne sont pas mises en cache, vérifiez d'abord que Cloud CDN est activé pour le service ou bucket de backend. Lorsque vous activez Cloud CDN, la mise en cache des réponses peut prendre quelques minutes.

Cloud CDN met en cache uniquement les réponses marquées comme publiques et spécifiant un délai d'expiration ou un âge maximum. Cette information est transmise dans les en-têtes de réponse HTTP. Si les réponses ne sont pas mises en cache pour une URL, vérifiez les en-têtes renvoyés pour cette URL.

Il existe plusieurs façons de vérifier les en-têtes de réponse :

L'exemple suivant montre comment utiliser curl pour vérifier les en-têtes de réponse HTTP pour http://example.com/style.css :

curl -s -D - -o /dev/null http://example.com/style.css

Sortie :

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

La comparaison de ces en-têtes avec les exigences du contenu pouvant être mis en cache montre que l'en-tête Cache-Control requis est absent de la réponse.

La méthode de définition des en-têtes dépend du type de serveur d'origine. Si vous exécutez un serveur Web sur Compute Engine, consultez la documentation du logiciel du serveur Web pour en savoir plus sur la configuration des en-têtes de réponse. Pour Cloud Storage, le marquage de l'objet comme étant partagé en mode public entraîne l'envoi des en-têtes appropriés.

Après avoir reconfiguré le serveur d'origine pour ajouter l'en-tête requis, vous pouvez à nouveau utiliser curl pour vérifier le résultat :

curl -s -D - -o /dev/null http://example.com/style.css

Sortie :

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

Sortie :

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

Sortie :

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

Dans cet exemple, la dernière réponse inclut l'en-tête Age. Cloud CDN ajoute un en-tête Age aux réponses qu'il diffuse à partir du cache. Ici, l'en-tête indique que la réponse a été diffusée avec succès depuis le cache à l'aide d'une entrée de cache créée il y a deux secondes.

En outre, si les ETags sont activés sur les instances backend, Cloud CDN s'appuie dessus pour confirmer l'actualisation de l'objet. Si les instances backend diffusent différents ETags pour le même objet, Cloud CDN comptabilise les erreurs de correspondance comme un défaut de cache (miss) et actualise l'objet. Pour éviter ce comportement, les instances backend doivent diffuser le même ETag ou les ETags doivent être désactivés.

Pour vérifier cela, exécutez curl plusieurs fois et observez les modifications de la valeur ETag :

curl -s -D - -o /dev/null http://example.com/image.png

Sortie :

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
<em>etag: "10f-5a0f1256f1402"</em>
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

Sortie :

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
<em>etag: "10f-5a0f11ca09b7a"</em>
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

Les objets Cloud Storage ne sont pas accessibles

Pour fournir un accès aux objets dans Cloud Storage, vous devez configurer des URL signées ou accorder au bucket et à tous ses objets un accès public à allUsers.

Si vous décidez d'accorder un accès à allUsers, vous pouvez vérifier l'accès au niveau de l'objet comme suit :

Console

  1. Dans Cloud Console, ouvrez le navigateur Cloud Storage.

    Ouvrir le navigateur Storage

  2. Cliquez sur un bucket pour afficher la page Détails du bucket.

  3. Dans la colonne Accès public, passez la souris sur l'icône de point d'exclamation et cliquez sur Modifier l'accès.

    Pour chaque objet du bucket, vérifiez que les autorisations suivantes sont définies :

    • Entité : utilisateur
    • Nom : allUsers
    • Accès : lecteur

Pour en savoir plus sur le contrôle des accès pour Cloud Storage, consultez la documentation sur la gestion de l'authentification et des accès (IAM) pour Cloud Storage.

Pour en savoir plus sur les URL signées, consultez la page Utiliser des URL signées.

Si les objets sont accessibles, mais ne sont pas mis en cache, reportez-vous à la section Les réponses ne sont pas mises en cache.

Du contenu privé a été mis en cache ou le contenu mis en cache est incorrect

Si vous savez pourquoi le serveur d'origine a diffusé le contenu privé ou incorrect et que vous pouvez résoudre le problème, vous pouvez invalider les caches Cloud CDN comme suit :

  1. Assurez-vous que le serveur d'origine ne renvoie plus le contenu privé ou incorrect.
  2. Demandez une invalidation de cache pour indiquer à Cloud CDN de cesser de diffuser le contenu mis en cache.

Pour en savoir plus, consultez la Présentation de l'invalidation de cache.

Cloud CDN ne met en cache que les réponses marquées comme pouvant être mises en cache en mode public et diffuse les réponses du cache allant uniquement jusqu'à la date et l'heure d'expiration spécifiées dans la réponse. Si vous ne savez pas pourquoi le contenu a été mis en cache ou ne pouvez pas résoudre le problème rapidement, vous pouvez désactiver Cloud CDN jusqu'à ce que vous puissiez comprendre et résoudre le problème, puis le réactiver. Pour plus d'informations sur le contenu mis en cache et sa durée de conservation en cache, consultez la section Présentation de la mise en cache.

Le taux d'accès au cache est faible

Si les taux d'accès au cache des services ou buckets de backend sont inférieurs aux prévisions, assurez-vous que les réponses des URL concernées sont mises en cache.

Cloud CDN incorpore l'URI de requête complet dans ses clés de cache. http://example.com/cat.jpg?1 et http://example.com/cat.jpg?2 disposent donc d'entrées de cache distinctes. Vous pouvez améliorer les taux d'accès au cache en utilisant toujours une seule URL pour une ressource donnée.

Si vous devez transmettre des paramètres à un script JavaScript exécuté sur une page pouvant être mise en cache, utilisez des identificateurs de fragment plutôt que des chaînes de requête.

En outre, vous pouvez améliorer les taux d'accès au cache en n'utilisant l'en-tête de réponse Vary que si nécessaire. Pour en savoir plus, consultez la section Clés de cache.

Plusieurs remplissages de cache existent pour le même contenu

En général, vous pouvez réduire le nombre de remplissages en cache en augmentant les délais d'expiration des réponses pouvant être mises en cache. Toutes choses égales par ailleurs, vous constaterez moins de remplissages de cache avec une réponse comportant Cache-Control: public, max-age=86400 qu'avec une réponse comportant Cache-Control: public, max-age=1.

Pour en savoir plus sur les délais d'expiration, consultez la section Délais d'expiration et requêtes de validation. Pour plus d'informations sur la configuration des en-têtes de réponse appropriés, consultez la documentation de votre logiciel serveur Web.

Cloud CDN exploite de nombreux caches dans le monde entier et que les anciennes entrées de cache sont systématiquement supprimées pour laisser la place à de nouveaux contenus. Par conséquent, plusieurs remplissages de cache par ressource sont attendus dans le cadre d'un fonctionnement normal.

La compression ne fonctionne pas

Cloud CDN n'effectue pas lui-même la compression et la décompression des réponses, mais il peut diffuser des réponses générées par le serveur d'origine qui ont été compressées à l'aide d'algorithmes d'encodage tels que gzip et DEFLATE.

Si les réponses diffusées par Cloud CDN ne sont pas compressées alors qu'elles doivent l'être, vérifiez que le logiciel serveur Web exécuté sur les instances est configuré pour compresser les réponses. Par défaut, certains logiciels serveur Web désactivent automatiquement la compression pour les requêtes comportant l'en-tête Via. La présence d'un en-tête Via indique que la requête a été transmise par un proxy. Les proxys HTTP comme l'équilibrage de charge HTTP(S) ajoutent un en-tête Via à chaque requête, comme requis par la spécification HTTP. Pour activer la compression, vous devrez peut-être remplacer la configuration par défaut de votre serveur Web pour lui indiquer de compresser les réponses même si la requête comporte un en-tête Via.

Si vous utilisez le logiciel serveur Web nginx, modifiez le fichier de configuration nginx.conf pour activer la compression. L'emplacement de ce fichier dépend de l'emplacement d'installation de nginx. Dans de nombreuses distributions Linux, ce fichier est stocké dans /etc/nginx/nginx.conf.

Pour permettre le fonctionnement de la compression nginx avec l'équilibrage de charge HTTP(S), ajoutez les deux lignes suivantes à la section http de nginx.conf :

gzip_proxied any;
gzip_vary on;
  • La première ligne permet la compression même pour les requêtes transmises par un proxy, comme l'équilibrage de charge HTTP(S).

  • La deuxième ligne ajoute un en tête Vary: Accept-Encoding aux réponses. Vary: Accept-Encoding indique aux proxys de mise en cache tels que Cloud CDN de conserver des entrées de cache distinctes pour les variantes compressées et non compressées des ressources compressibles.

Une fois que vous avez modifié nginx.conf, vous devez redémarrer nginx pour utiliser la nouvelle configuration. Dans de nombreuses distributions Linux, vous pouvez redémarrer nginx en exécutant sudo service nginx restart ou /etc/init.d/nginx restart.

Les réponses se terminent par des erreurs byte_range_caching_aborted

Lorsque Cloud CDN assemble une réponse à partir de plusieurs requêtes de plage d'octets, il vérifie si ces plages proviennent de la même version de la ressource en comparant les en-têtes de réponse ETag et Last-Modified. Si Cloud CDN détecte que la valeur de l'un des en-têtes est incohérente par rapport aux plages déjà fournies au client, la réponse sera abandonnée.

Si vous remarquez des réponses terminées de manière inattendue, des entrées de journal Cloud Logging avec un état statusDetails byte_range_caching_aborted ou que vos instances renvoyant des réponses 412 Precondition Failed, assurez-vous que le logiciel serveur Web s'exécutant sur toutes vos instances de machine virtuelle (VM) renvoie les mêmes valeurs ETag et Last-Modified pour une ressource donnée.

Lors de la diffusion de fichiers à partir d'un disque, il est courant que le logiciel serveur Web extrait les valeurs ETag et Last-Modified à partir de l'heure de modification du fichier. Dans ce cas, vous pouvez vous assurer que vos instances de VM signalent des valeurs cohérentes en utilisant la même image pour toutes les instances. Pour savoir comment votre logiciel serveur Web détermine les valeurs ETag et Last-Modified, consultez la documentation de votre logiciel serveur Web.

Résoudre les problèmes liés aux cookies signés

Les problèmes suivants peuvent se produire lorsque vous utilisez des cookies signés.

Encodage

Lors de la génération d'une signature, la requête est rejetée de manière inattendue en raison d'une erreur de correspondance de signature.

Lorsque vous encoder les valeurs URL et Signature, assurez-vous que vous utilisez la variante sécurisée pour l'URL de base64. L'encodage base64 standard échoue lorsque les caractères générés ne sont pas sécurisés pour les URL. Le padding est accepté.

Signature

Votre requête est rejetée par Cloud CDN.

  • Assurez-vous d'utiliser l'algorithme de signature HMAC-SHA-1, et non une autre variante de HMAC.

  • Vérifiez que le paramètre KeyName (sensible à la casse) correspond à un nom de clé valide pour le service de backend ou le bucket backend utilisé par Cloud CDN.

  • Ne signez pas de paramètres de requête lorsque vous générez et signez un élément URLPrefix. Assurez-vous que URLPrefix ne contient que les composants de schéma, d'hôte et de chemin d'accès (partiel) de l'URL.

  • Assurez-vous que le bloc de signature (URLPrefix, Expires, KeyName et Signature) correspond bien aux dernières sections du cookie, délimitées par :.

  • Assurez-vous que URLPrefix, Expires, KeyName et Signature apparaissent dans cet ordre.

  • N'incluez pas d'astérisque (*) à la fin d'un élément URLPrefix dans un cookie signé.

Cookies

  • Les navigateurs limitent généralement les cookies à 4 Ko par domaine et le nombre maximal de cookies à 50 par domaine. Prenez note des autres cookies que vous émettez et que vous demandez à vos clients d'envoyer, car de nombreux serveurs Web appliquent également des limites maximales d'en-tête de requête.

  • Assurez-vous d'utiliser le caractère deux-points (:) (point de code Unicode U+003A) comme délimiteur des paramètres nommés dans un cookie signé, et non le caractère esperluette (&).

  • Assurez-vous que l'horodatage Expires des cookies que vous distribuez n'est pas nécessairement court. Les périodes de validité inférieures à une ou deux minutes peuvent entraîner des problèmes de variation d'horloge entre l'application émettrice et l'infrastructure de Cloud CDN.

  • Assurez-vous de ne pas définir plusieurs cookies pour les mêmes attributs Domain et Path avec des valeurs différentes. Définissez un cookie unique par utilisateur avec une valeur de préfixe d'URL qui englobe tout le contenu auquel l'utilisateur doit accéder.

Messages d'erreur

Erreurs d'invalidation de cache

Code d'erreur Notes
Invalid value for field 'resource.path'

La valeur du chemin a un format non valide. Les chemins d'accès doivent commencer par / et ne doivent pas contenir ? ou #. Ils ne doivent comporter qu'un seul *, qui doit être un caractère final après /.

Les chemins ne doivent pas dépasser 1024 caractères. Si vous recevez cette erreur, vérifiez la valeur du chemin et corrigez les erreurs de format.

Cette erreur ne concerne que le format du chemin. Un chemin de format valide, mais inexistant, est toujours considéré comme valide.

Rate Limit Exceeded Cloud CDN limite la vitesse à laquelle les opérations d'invalidation de cache peuvent être effectuées. Une seule invalidation par minute est autorisée. Cependant, chaque opération peut spécifier un format de chemin correspondant à un nombre quelconque d'objets.

Problèmes connus

Les problèmes et limitations connus suivants concernent Cloud CDN :

  • Les invalidations de cache sont limitées à une invalidation par mappage d'URL par minute.