Fehlerbehebung bei Cloud CDN

Auf dieser Seite werden die Schritte zur Behebung von Problemen beschrieben, die bei der Verwendung von Cloud CDN auftreten können.

Wenn das Problem auf externe Back-Ends zurückzuführen ist, lesen Sie den Abschnitt Fehlerbehebung bei Problemen mit dem externen Back-End und der Internet-NEG.

Allgemeine Probleme und Lösungen

Antworten werden nicht im Cache gespeichert

Wenn Antworten nicht im Cache gespeichert werden, prüfen Sie zuerst, ob für Ihren Backend-Dienst oder -Bucket Cloud CDN aktiviert ist. Wenn Sie Cloud CDN aktivieren, kann es einige Minuten dauern, bis Antworten im Cache gespeichert werden.

Cloud CDN speichert nur Antworten mit cache-fähigen Inhalten. Diese Informationen werden in HTTP-Antwortheadern zusammen mit der Back-End-Konfiguration gesendet. Wenn Antworten für eine URL nicht im Cache gespeichert werden, prüfen Sie, welche Header für diese URL zurückgegeben werden und wie die Cache-Fähigkeit für Ihr Back-End konfiguriert ist.

Es gibt mehrere Möglichkeiten zum Prüfen von Antwortheadern:

Das folgende Beispiel zeigt, wie Sie die HTTP-Antwortheader für http://example.com/style.css mithilfe von curl prüfen:

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

Ausgabe:

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

Ein Vergleich dieser Header mit den Anforderungen an den Cache-fähigen Inhalt zeigt, dass in der Antwort der erforderliche Cache-Control-Header fehlt (vorausgesetzt, der Cache-Modus ist auf USE_ORIGIN_HEADERS gesetzt).

Die Methode zum Festlegen von Headern hängt vom Typ des Ursprungsservers ab. Wenn Sie einen Webserver in Compute Engine ausführen, lesen Sie die Informationen zum Konfigurieren von Antwortheadern in der Dokumentation zur Webserver-Software. Wenn Sie das Objekt in Cloud Storage als öffentlich freigegeben kennzeichnen, werden die entsprechenden Header gesendet.

Nachdem Sie den Ursprungsserver neu konfiguriert haben, um den erforderlichen Header hinzuzufügen, können Sie curl noch einmal verwenden, um das Ergebnis zu prüfen:

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

Ausgabe:

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

Ausgabe:

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

Ausgabe:

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

Die letzte Antwort in diesem Beispiel enthält einen Age-Header. Cloud CDN fügt den Antworten, die es aus dem Cache bezieht, einen Age-Header hinzu. Hier zeigt der Header an, dass die Antwort mithilfe eines Cache-Eintrags, der zwei Sekunden zuvor erstellt wurde, erfolgreich aus dem Cache übernommen wurde.

Wenn auf den Backend-Instanzen ETags aktiviert sind, benötigt Cloud CDN außerdem ETags, um die Aktualität des Objekts zu bestätigen. Wenn die Backend-Instanzen verschiedene ETags für dasselbe Objekt bereitstellen, wertet Cloud CDN Nichtübereinstimmungen als Cache-Fehler und aktualisiert das Objekt. Damit dies verhindert wird, müssen entweder die Backend-Instanzen dasselbe ETag bereitstellen oder ETags deaktiviert werden.

Dies können Sie prüfen. Führen Sie dazu curl wiederholt aus und achten Sie auf Änderungen im ETag-Wert.

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

Ausgabe:

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

Ausgabe:

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

Cloud Storage-Objekte können nicht aufgerufen werden

Um Zugriff auf Objekte in Cloud Storage zu gewähren, müssen Sie entweder signierte URLs konfigurieren oder den Bucket und alle seine Objekte für allUsers öffentlich zugänglich machen.

Wenn Sie Zugriff für allUsers gewähren möchten, können Sie den Zugriff auf Objektebene so prüfen:

Console

  1. Öffnen Sie in der Google Cloud Console den Cloud Storage-Browser.

    Storage-Browser öffnen

  2. Klicken Sie auf den Bucket, damit die Seite Bucket-Details geöffnet wird.

  3. Bewegen Sie den Mauszeiger in der Spalte Öffentlicher Zugriff über das Ausrufezeichen und klicken Sie auf Zugriff bearbeiten.

    Prüfen Sie bei allen Objekten, ob die folgende Berechtigung eingestellt ist:

    • Entität: Nutzer
    • Name: allUsers
    • Zugriff: Leser

Weitere Informationen zur Zugriffssteuerung für Cloud Storage finden Sie in der Dokumentation zum Cloud Identity and Access Management (IAM) für Cloud Storage.

Weitere Informationen über signierte URLs finden Sie unter Signierte URLs verwenden.

Wenn die Objekte aufgerufen werden können, jedoch nicht im Cache gespeichert werden, lesen Sie Antworten werden nicht im Cache gespeichert.

Private oder falsche Inhalte werden im Cache gespeichert

Wenn Sie wissen, warum der Ursprungsserver einen privaten oder falschen Inhalt bereitgestellt hat, und sich das Problem beheben lässt, können Sie Cloud CDN-Caches auf folgende Weise entwerten:

  1. Achten Sie darauf, dass der Ursprungsserver den privaten oder falschen Inhalt nicht mehr zurückgibt.
  2. Fordern Sie eine Cache-Entwertung an, um Cloud CDN anzuweisen, den im Cache gespeicherten Inhalt nicht mehr bereitzustellen.

Weitere Informationen finden Sie unter Cache-Entwertung – Überblick.

Cloud CDN speichert nur Antworten mit cache-fähigen Inhalten im Cache und liefert Antworten nur aus dem Cache, bis die in der Antwort angegebene Ablaufzeit erreicht ist. Wenn Sie nicht wissen, warum der Inhalt im Cache gespeichert wurde, oder Sie das Problem nicht zügig lösen können, sollten Sie Cloud CDN deaktivieren, bis die Ursache erkannt ist und Sie das Problem lösen können. Aktivieren Sie Cloud CDN anschließend wieder. Weitere Informationen dazu, welche Inhalte wie lange im Cache gespeichert werden, finden Sie unter Caching.

Niedrige Cache-Trefferquote

Für Leistung und Skalierbarkeit ist es wichtig, Cache-Trefferquoten zu optimieren. Wenn die Cache-Trefferquoten niedriger als erwartet sind, achten Sie darauf, dass Sie die Best Practices zur Optimierung der Cache-Trefferquote befolgen.

In der folgenden Tabelle sind einige der möglichen Gründe für eine niedrige Cache-Trefferquote und die potenziellen Korrekturen aufgeführt.

Gründe Kommentare Diverse Fehlerkorrekturen
Ihre Inhalte können nicht im Cache gespeichert werden. Eine im Cache speicherbare Antwort ist eine HTTP-Antwort, die von Cloud CDN gespeichert werden kann. Achten Sie darauf, dass Ihre Inhalte im Cache gespeichert werden können.
Der Cache-Modus ist für Ihre Anwendung nicht optimal. Cloud CDN hat mehrere Cache-Modi. Wenn Sie keine Cache-Control-Header verwenden, um das Caching-Verhalten zu steuern, empfiehlt es sich, Cloud CDN alle statischen Inhalte im Cache speichern zu lassen.
Es gibt ein wenig Traffic. Während des Tests und der Experimente ist die Menge des Traffics, den Sie generieren, wahrscheinlich niedrig. Google hat einen globalen verteilten Cache und Anfragen von verschiedenen geografischen Standorten werden an verschiedene Google-Frontend-Standorte gesendet. An jedem Frontend-Speicherort kann Google mehrere separate Instanzen des Cache haben.
  • Achten Sie darauf, dass genügend Traffic an Google gesendet wird, um alle relevanten Caches zu füllen.
  • Achten Sie beim Testen darauf, den Traffic nach URL zu fragmentieren, damit der gesamte Traffic für jedes Set von Anfragen an Google gesendet wird. Fragmentieren und senden Sie die einzelnen Anfragen nicht zufällig an einen anderen CDN-Anbieter.
Antworten bestimmter URLs werden nicht im Cache gespeichert. Cloud CDN nimmt den vollständigen Anfrage-URI in seine Cache-Schlüssel auf, sodass http://example.com/cat.jpg?color=orange und http://example.com/cat.jpg?color=gray separate Cache-Einträge haben. Verwenden Sie immer nur eine URL für eine bestimmte Ressource.

Wenn Sie Parameter an JavaScript-Code weiterleiten müssen, der auf einer ansonsten im Cache speicherbaren Seite ausgeführt wird, können Sie Fragmentbezeichner anstelle von Abfragestrings verwenden.
Der Cache wird aufgrund des Header-Felds Vary unnötig fragmentiert. Das Header-Feld Vary in einer Antwort beschreibt, welche Teile einer Anfragenachricht (neben der Methode, dem Header-Feld Host und dem Anfrageziel) den Prozess des Ursprungsservers beeinflussen können, bei dem die Auswahl und Repräsentation einer Antwort erfolgt. Sie können beispielsweise den Header Vary: Accept-Encoding verwenden, wenn Sie Clients, die komprimierte Antworten verarbeiten können, andere Inhalte bereitstellen möchten, als Clients, die dies nicht tun können. Verwenden Sie den Antwortheader Vary nur bei Bedarf.
Sie verwenden keine benutzerdefinierten Cache-Schlüssel. Cloud CDN nutzt standardmäßig die vollständige Anfrage-URL, um den Cache-Schlüssel zu erstellen. Sie können Cache-Schlüssel anpassen, um eine beliebige Kombination aus Protokoll-, Host- und Anfrage-Strings ein- oder auszuschließen. Wenn z. B. zwei Domains denselben statischen Inhalt verwenden, können Sie einen benutzerdefinierten Cache-Schlüssel erstellen, bei dem das Hostfeld weggelassen wird. Verwenden Sie bei Bedarf benutzerdefinierte Cache-Schlüssel.

Für denselben Inhalt sind mehrere Cache-Füllungen vorhanden

Im Allgemeinen können Sie die Anzahl an Cache-Füllungen verringern, indem Sie die Ablaufzeiten Ihrer cache-fähigen Antworten erhöhen. Da alles andere gleich bleibt, werden bei einer Antwort mit Cache-Control: public, max-age=86400 weniger Cache-Füllungen erzeugt als bei einer Antwort mit Cache-Control: public, max-age=1.

Weitere Informationen zu Ablaufzeiten finden Sie unter Ablaufzeiten und Validierungsanfragen. Informationen zum Konfigurieren der entsprechenden Antwortheader finden Sie in der Dokumentation zu Ihrer Webserver-Software.

Cloud CDN betreibt weltweit viele Caches und alte Cache-Einträge werden regelmäßig entfernt, um Platz für neue Inhalte zu schaffen. Dementsprechend gehören mehrere Cache-Füllungen pro Ressource zum Normalbetrieb von Cloud CDN.

Komprimierung funktioniert nicht

Cloud CDN bietet eine dynamische Komprimierung für Ursprünge, die ihre Antworten nicht komprimieren können. Es empfiehlt sich, nach Möglichkeit die Komprimierung am Ursprung zu verwenden, da die Kosten für die Cache-Füllung reduziert werden.

Wenn die von Cloud CDN bereitgestellten Antworten nicht komprimiert sind, obwohl sie dies sein sollten, prüfen Sie, ob die Webserver-Software für Ihre Instanzen so konfiguriert ist, dass Antworten komprimiert werden. Einige Arten von Webserver-Software deaktivieren standardmäßig die Komprimierung für Anfragen, die einen Via-Header enthalten. Das Vorhandensein eines Via-Headers weist darauf hin, dass die Anfrage von einem Proxy weitergeleitet wurde. Bei HTTP-Proxys wie dem externen Application Load Balancer wird jeder Anfrage gemäß HTTP-Spezifikation der Via-Header hinzugefügt. Um die Komprimierung zu aktivieren, müssen Sie womöglich die Standardkonfiguration des Webservers überschreiben, um diesen anzuweisen, Antworten auch dann zu komprimieren, wenn die Anfrage einen Via-Header beinhaltet.

Wenn Sie die Webserver-Software nginx nutzen, müssen Sie zum Aktivieren der Komprimierung die Konfigurationsdatei nginx.conf ändern. Der Speicherort dieser Datei hängt davon ab, wo nginx installiert ist. In vielen Linux-Distributionen ist die Datei unter /etc/nginx/nginx.conf gespeichert.

Damit die nginx-Komprimierung mit Ihrem externen Application Load Balancer zusammenarbeitet, fügen Sie dem Abschnitt http der Datei nginx.conf die folgenden beiden Zeilen hinzu:

gzip_proxied any;
gzip_vary on;

  • Die erste Zeile aktiviert die Komprimierung auch für Anfragen, die von einem Proxy wie dem externen Application Load Balancer weitergeleitet wurden.

  • Die zweite Zeile fügt den Antworten den Header Vary: Accept-Encoding hinzu. Vary: Accept-Encoding informiert Caching-Proxys wie etwa Cloud CDN darüber, dass sie separate Cache-Einträge für komprimierte und nicht komprimierte Varianten komprimierbarer Ressourcen pflegen sollen.

Nachdem Sie nginx.conf geändert haben, müssen Sie nginx neu starten, damit es die neue Konfiguration verwendet. In vielen Linux-Distributionen können Sie nginx neu starten, indem Sie sudo service nginx restart oder /etc/init.d/nginx restart ausführen.

Antworten enden mit byte_range_caching_aborted-Fehlern

Wenn Cloud CDN eine Antwort aus mehreren Bytebereichsanfragen zusammenstellt, wird durch den Vergleich der Antwortheader ETag und Last-Modified geprüft, ob diese Bereiche von derselben Version der Ressource stammen. Wenn Cloud CDN feststellt, dass der Wert eines Headers nicht mit Bereichen übereinstimmt, die bereits für den Client bereitgestellt wurden, wird die Antwort abgebrochen.

Wenn Sie unerwartete abgebrochene Antworten, Logeinträge von Stackdriver Logging mit byte_range_caching_aborted als Statusdetails oder Antworten der Art 412 Precondition Failed von Ihren Instanzen feststellen, prüfen Sie, ob die auf allen VM-Instanzen ausgeführte Webserver-Software für eine bestimmte Ressource dieselben ETag- und Last-Modified-Werte zurückgibt.

Bei der Bereitstellung von Dateien von einem Laufwerk ist es üblich, dass die Webserver-Software die ETag- und Last-Modified-Werte aus der Änderungszeit der Datei ableitet. In diesem Fall können Sie für alle Instanzen dasselbe Image verwenden, um zu gewährleisten, dass die VM-Instanzen konsistente Werte melden. Details dazu, wie Ihre Webserver-Software ETag- und Last-Modified-Werte bestimmt, finden Sie in der Dokumentation Ihrer Webserver-Software.

Fehlerbehebung bei signierten Cookies

Wenn Sie signierte Cookies verwenden, können folgende Probleme auftreten.

Codierung

Beim Generieren einer Signatur wird die Anfrage aufgrund einer nicht übereinstimmenden Signatur unerwartet abgelehnt.

Achten Sie bei der Codierung der Werte URL und Signature darauf, die URL-sichere Variante von base64 zu verwenden. Die standardmäßige base64-Codierung schlägt fehl, wenn die generierten Zeichen nicht URL-sicher sind. Der Abstand wird akzeptiert.

Signatur

Die Anfrage wird von Cloud CDN abgelehnt.

  • Achten Sie darauf, dass Sie HMAC-SHA-1 als Signaturalgorithmus und nicht eine andere Variante von HMAC verwenden.

  • Prüfen Sie, ob der Parameter KeyName (Groß- und Kleinschreibung berücksichtigen) mit einem gültigen Schlüsselnamen für den Backend-Dienst oder Backend-Bucket übereinstimmt, der von Cloud CDN verwendet wird.

  • Signieren Sie beim Generieren und Signieren eines URLPrefix keine Abfrageparameter. URLPrefix darf nur die Schema-, Host- und (teilweise) Pfadkomponenten der URL enthalten.

  • Achten Sie darauf, dass der Signaturblock – URLPrefix, Expires, KeyName und Signature selbst – die letzten :-begrenzten Abschnitte des Cookies sind.

  • Achten Sie darauf, dass URLPrefix, Expires, KeyName und Signature in dieser Reihenfolge vorkommen.

  • Verwenden Sie in einem signierten Cookie kein Sternchen (*) am Ende von URLPrefix.

Cookies

  • Browser beschränken Cookies in der Regel auf 4 KB pro Domain und insgesamt auf 50 Cookies pro Domain. Beachten Sie auch andere Cookies, die Sie senden und die von Ihren Clients gesendet werden müssen, da viele Webserver auch Höchstgrenzen für die Anzahl der Anfrageheader haben.

  • Achten Sie darauf, dass Sie in einem signierten Cookie das Doppelpunktzeichen (:), den Unicode-Codepunkt U+003A, und nicht das kaufmännische Und-Zeichen (&) als Trennzeichen verwenden.

  • Achten Sie darauf, dass der Zeitstempel Expires für die von Ihnen ausgegebenen Cookies nicht zu kurz ist. Gültigkeitszeiträume von weniger als 1–2 Minuten können anfällig für Zeitverzögerungen zwischen der ausstellenden Anwendung und der Cloud CDN-Infrastruktur sein.

  • Achten Sie darauf, nicht mehrere Cookies für die gleiche Domain und den gleichen Path mit unterschiedlichen Werten zu setzen. Legen Sie ein einzelnes Cookie pro Nutzer mit einem URL-Präfixwert fest, das den gesamten Inhalt umfasst, auf den der Nutzer zugreifen muss.

Fehlermeldungen

Cache-Entwertungsfehler

Fehlercode Hinweise
Invalid value for field 'resource.path'

Der Pfadwert hat ein ungültiges Format. Pfade müssen mit einem / beginnen, dürfen kein ? oder # enthalten und dürfen nur ein einzelnes * enthalten, das das letzte Zeichen nach einem / sein muss.

Pfade dürfen nicht mehr als 1.024 Zeichen haben. Wenn Sie diesen Fehler erhalten, prüfen Sie den Pfadwert und korrigieren Sie etwaige Formatfehler.

Dieser Fehler bezieht sich nur auf das Pfadformat. Ein Pfad mit gültigem Format, der aber nicht vorhanden ist, wird trotzdem als gültig behandelt.
Rate Limit Exceeded In Cloud CDN ist die Rate beschränkt, mit der Cache-Entwertungen ausgeführt werden können. Es ist nur eine Entwertung pro Minute zulässig. Bei jeder Entwertung kann jedoch ein Pfadmuster angegeben werden, das einer beliebigen Anzahl von Objekten entspricht.

Bekannte Probleme

  • Cache-Entwertungen sind auf eine Entwertung pro URL-Zuordnung und Minute beschränkt.

    Lösung: Warten Sie mindestens eine Minute, bevor Sie versuchen, eine andere URL-Zuordnung zu entwerten.

    Weitere Informationen zur Begrenzung der Cache-Entwertungsrate finden Sie unter Einschränkungen.