Fehlerbehebung

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 benutzerdefinierte Ursprünge zurückzuführen ist, lesen Sie den Abschnitt Fehlerbehebung bei Problemen mit der benutzerdefinierten Ursprungs- und 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 Back-End-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 solche Antworten im Cache, die als öffentlich markiert sind und für die ein Ablaufdatum oder ein maximales Alter angegeben ist. Diese Informationen werden in HTTP-Antwort-Headern übermittelt. Wenn Antworten für eine URL nicht im Cache gespeichert werden, prüfen Sie, welche Header für diese URL zurückgegeben werden.

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

Der Vergleich dieser Header mit den Anforderungen für im Cache speicherbaren Inhalt zeigt, dass in der Antwort der erforderliche Cache-Control-Header fehlt.

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.

Nach der Neukonfiguration des Ursprungsservers für das Hinzufügen des erforderlichen Headers 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 aus dem Cache einen Age-Header hinzu. Hier gibt 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 Back-End-Instanzen ETags aktiviert sind, benötigt Cloud CDN außerdem ETags, um die Aktualität des Objekts zu bestätigen. Wenn die Back-End-Instanzen verschiedene ETags für dasselbe Objekt bereitstellen, wertet Cloud CDN Nichtübereinstimmungen als Cache-Fehler und aktualisiert das Objekt. Um dies zu verhindern, müssen entweder die Back-End-Instanzen dasselbe ETag bereitstellen oder ETags müssen deaktiviert werden.

Führen Sie zum Prüfen dieses Features curl wiederholt aus und achten Sie auf Änderungen am Wert ETag:

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

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

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 allUsers Zugriff gewähren möchten, können Sie den Zugriff auf Objektebene so prüfen:

Console

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

    Storage-Browser öffnen

  2. Klicken Sie auf einen Bucket, um die Seite Bucket-Details aufzurufen.

  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 zu 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 folgendermaßen entwerten:

  1. Sorgen Sie dafür, 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.

Cloud CDN speichert nur Antworten im Cache, die öffentlich als im Cache speicherbar gekennzeichnet sind, und stellt Antworten vom Cache nur bis zu dem in der Antwort angegebenen Ablaufdatum bereit. 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 Sie das Problem verstehen und 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

Wenn die Cache-Trefferquoten für Ihre Back-End-Dienste oder Back-End-Buckets niedriger als erwartet sind, achten Sie darauf, dass Antworten für die betreffenden URLs im Cache gespeichert werden.

Cloud CDN nimmt den vollständigen Anfrage-URI in seine Cache-Schlüssel auf, sodass http://example.com/cat.jpg?1 und http://example.com/cat.jpg?2 separate Cache-Einträge haben. Sie können die Cache-Trefferquoten verbessern, wenn Sie jeweils nur eine URL für eine angegebene Ressource verwenden.

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.

Außerdem können Sie die Cache-Trefferquoten verbessern. Verwenden Sie dazu den Vary-Antwortheader nur bei Bedarf. Weitere Informationen finden Sie unter 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 Sie bei einer Antwort mit Cache-Control: public, max-age=86400 weniger Cache-Füllungen sehen 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 zahlreiche Caches auf der ganzen Welt und alte Cache-Einträge werden routinemäßig gelöscht, 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 komprimiert oder dekomprimiert Antworten nicht selbst, kann aber Antworten bereitstellen, die vom Ursprungsserver generiert und mit Codierungen wie gzip oder DEFLATE komprimiert wurden.

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 HTTP(S)-Load-Balancing 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 zur Aktivierung 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 HTTP(S)-Load-Balancing funktioniert, 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 HTTP(S)-Load-Balancer weitergeleitet wurden.

  • Die zweite Zeile fügt den Antworten einen Vary: Accept-Encoding-Header 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.

Nach der Modifizierung von nginx.conf müssen Sie nginx neu starten, bevor es die neue Konfiguration nutzen kann. In vielen Linux-Distributionen können Sie nginx mit sudo service nginx restart oder /etc/init.d/nginx restart neu starten.

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 dieselben ETag- und Last-Modified-Werte für eine bestimmte Ressource 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 dafür sorgen, dass Ihre VM-Instanzen konsistente Werte melden, indem Sie für alle Instanzen dasselbe Image verwenden. Details dazu, wie Ihre Webserver-Software ETag- und Last-Modified-Werte bestimmt, finden Sie in der Dokumentation Ihrer Webserver-Software.

Fehlerbehebung bei signierten Cookies

Die folgenden Probleme können auftreten, wenn Sie signierte Cookies verwenden.

Encoding

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 base64 zu verwenden. Die standardmäßige base64-Codierung schlägt fehl, wenn die generierten Zeichen nicht URL-sicher sind. Padding wird akzeptiert.

Signatur

Ihre Anfrage wird von Cloud CDN abgelehnt.

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

  • Bestätigen Sie, dass der Parameter KeyName (Groß- und Kleinschreibung berücksichtigen) mit einem gültigen Schlüsselnamen für den Back-End-Dienst oder Back-End-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 maximale Anfrageheader-Limits 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 ein letztes 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

Die folgenden Probleme und Beschränkungen können sich auf Cloud CDN auswirken:

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