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
In diesem Abschnitt werden einige häufige Probleme und ihre Lösungen beschrieben.
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 die betreffende URL und wie die Cache-Fähigkeit für Ihre Website konfiguriert wird Back-End.
Es gibt mehrere Möglichkeiten zum Prüfen von Antwortheadern:
- In Google Chrome im Bereich DevTools-Netzwerk
- In Mozilla Firefox im Netzwerkmonitor für Entwicklertools
- Mit einem Befehlszeilentool wie curl oder GNU Wget
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 außerdem ETags auf den Back-End-Instanzen aktiviert sind, Cloud CDN nutzt 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
Öffnen Sie in der Cloud Console den Cloud Storage-Browser.
Klicken Sie auf den Bucket, damit die Seite Bucket-Details geöffnet wird.
Halten Sie in der Spalte Öffentlicher Zugriff den Mauszeiger über das 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:
- Achten Sie darauf, dass der Ursprungsserver den privaten oder falschen Inhalt nicht mehr zurückgibt.
- 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 wenn Sie das Problem schnell beheben, möchten Sie vielleicht Cloud CDN deaktivieren bis Sie das Problem verstehen und lösen können. können Sie es wieder aktivieren. 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. |
|
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. HTTP-Proxys
wie dem externen Application Load Balancer, fügen Sie ein Via
hinzu.
als Header für jede Anfrage
gemäß der HTTP-Spezifikation erforderlich.
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 Schnittstelle nginx
Webserver-Software, ändern Sie zum Aktivieren die Konfigurationsdatei nginx.conf
Komprimierung. 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 dem externen Application Load Balancer zusammenarbeitet, fügen Sie den Parameter
folgenden zwei Zeilen zum Abschnitt http
von nginx.conf hinzu:
gzip_proxied any; gzip_vary on;
Die erste Zeile aktiviert die Komprimierung auch für Anfragen, die von einem Proxy den externen Application Load Balancer.
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 Methode
URL-sichere Variante
von base64. 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
undSignature
selbst – die letzten:
-begrenzten Abschnitte des Cookies sind.Achten Sie darauf, dass
URLPrefix
,Expires
,KeyName
undSignature
in dieser Reihenfolge vorkommen.Verwenden Sie in einem signierten Cookie kein Sternchen (
*
) am Ende vonURLPrefix
.
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-CodepunktU+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 gleichenPath
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
Dieser Abschnitt enthält Informationen zu einigen häufigen Fehlermeldungen und dazu, wie Sie und sie zu lösen.
Cache-Entwertungsfehler
Fehlercode | Hinweise |
---|---|
Invalid value for field 'resource.path' |
Der Pfadwert hat ein ungültiges Format. Pfade müssen mit einem 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 beschränkt pro Minute.
Lösung: Warten Sie mindestens eine Minute, bevor Sie versuchen, eine weitere URL-Zuordnung ungültig zu machen.
Weitere Informationen zur Begrenzung der Rate der Cache-Entwertung finden Sie unter Einschränkungen.