Übersicht über benutzerdefinierte Fehlerantworten

Mit globalen externen Application Load Balancern können Sie Ihre eigenen Fehlerantworten anpassen, wenn ein HTTP-Fehlerstatuscode (4xx und 5xx) generiert wird. Sie können Fehlerantworten für Fehler anpassen, die sowohl vom Load Balancer als auch von den Backend-Instanzen generiert wurden. Sie können auch Fehlerantworten für Fehlerantwortcodes anpassen, die generiert werden, wenn der Traffic von Google Cloud Armor abgelehnt wird.

Hier sehen Sie ein Beispiel für eine benutzerdefinierte Fehlerseite, auf der Sie Fehlerantworten für Ihre nach außen gerichtete Anwendung für private Nutzer mit Ihrem eigenen Unternehmensbranding und -logo, Links zu verwandten Seiten und benutzerdefinierter Benachrichtigung konfigurieren können.

Benutzerdefinierte HTTP-Fehlerantwortseite
Benutzerdefinierte HTTP-Fehlerantwortseite

Mithilfe einer benutzerdefinierten Fehlerantwortrichtlinie können Sie unterschiedliche Fehlerantworten für verschiedene HTTP-Fehlerstatuscodes, URL-Domains, URL-Pfade sowie HTTP-Anfrageheader- und -Parameterfelder konfigurieren.

Mit benutzerdefinierten Fehlerantworten können Sie die Nutzerfreundlichkeit verbessern. Dies bietet folgende Vorteile:

  • Bietet ein einheitliches Branding
  • Liefert kontextbezogene und relevante Informationen, um die Nutzerfreundlichkeit und die Nutzererfahrung zu verbessern
  • Verminderung negativer Auswirkungen von Ausfallzeiten und clientseitigen Fehlern
  • Verbessert die Netzwerksicherheit

Wenn Sie keine benutzerdefinierte Fehlerantwortrichtlinie konfigurieren, wird ein allgemeines Fehlerobjekt ohne Markenbezug angezeigt, wie in Abbildung 2 dargestellt.

Allgemeine HTTP-Fehlerantwortseite.
Allgemeine HTTP-Fehlerantwortseite

Anwendungsfälle

Die Funktion für benutzerdefinierte Fehlerantworten ist für viele Anwendungsfälle vorgesehen. Dieser Abschnitt enthält einige allgemeine Beispiele.

Eigene Wartungsseite definieren

Wenn Ihre Backends fehlerhaft sind oder sich im Wartungsmodus befinden, können Sie eine Fehlerseite mit dem Branding und Informationen des Unternehmens zurückgeben. Sie können kontextbezogene Fehlerseiten erstellen, die hilfreiche Informationen wie Telefonnummern von Callcentern oder Informationen darüber enthalten, wann Nutzer noch einmal auf die Website zugreifen sollten. Sie haben die Möglichkeit, Fehlerseiten basierend auf der Übereinstimmung von Fehlerbedingungen wie Hostname und HTTP-Fehlercode anzupassen.

Eigene Standardfehlerseite definieren

Sie können benutzerdefinierte Fehlerantworten nach bestimmten Fehlercodes einrichten. Sie können beispielsweise eine Fehlerseite mit der Meldung „Anmelden oder registrieren“ für den HTTP-Antwortcode 401 (Unauthorized) einrichten. Sie können auch eine Standardfehlerseite einrichten, die Unternehmens-Branding und andere relevante Informationen für alle anderen HTTP-Fehlercodes der 4xx- und 5xx-Serie enthält.

Fehlerantworten für Sicherheitsregeln definieren

Sie können eine benutzerdefinierte Fehlerseite für Fehlerantwortcodes zurückgeben, die generiert werden, wenn der Traffic von Google Cloud Armor-Sicherheitsrichtlinien abgelehnt wird. Achten Sie darauf, dass Sie die Fehlerseite mit demselben HTTP-Fehlercode der 4xx- oder 5xx-Serie konfigurieren, den Sie in der Google Cloud Armor-Sicherheitsregel eingegeben haben.

Auswirkungen von Ausfallzeiten minimieren

Gegebenenfalls können Sie eine Fehlerantwort konfigurieren, um den HTTP-Statuscode 200 (OK) zurückzugeben und eine statische Webseite bereitzustellen, damit Nutzer während der Ausfallzeit kontextbezogene und hilfreiche Informationen anstelle einer Fehlerseite sehen.

Fehlerantworten basierend auf dem Clientanfragetyp anpassen

Sie können eine Fehlerantwort anhand von HTTP-Anfrageheadern und -Parametern anpassen, z. B. dem Header Content-Type. Beim Weiterleiten der ursprünglichen Anfrage an den Fehlerdienst kann das Routing den Content-Type-Header berücksichtigen, um entweder eine Webseite (für Anfragen von Browsern) oder JSON (für Anfragen von einer Web API) einzubeziehen.

Funktionsweise von benutzerdefinierten Richtlinien für Fehlerantworten

Eine benutzerdefinierte Fehlerantwortrichtlinie kann auf drei Ebenen der URL-Zuordnungsressource definiert werden: der Load Balancer-Ebene, der URL-Domainebene und der URL-Pfadebene.

  • Load Balancer-Ebene. Die Richtlinie wird auf den gesamten vom Load Balancer empfangenen Traffic angewendet.

  • URL-Domain-Ebene: Die Richtlinie wird auf Traffic angewendet, der an einen bestimmten Domainnamen oder Hostnamen weitergeleitet wird, z. B. www.example.com.

  • URL-Pfadebene. Die Richtlinie wird auf Traffic angewendet, der an einen bestimmten Pfad weitergeleitet wird, z. B. www.example.com/images/*. Auf dieser Ebene können Sie auch erweiterte Übereinstimmungsbedingungen mit HTTP-Anfrageheadern und -parametern verwenden, z. B. Content-Type:application/json.

Die folgende Tabelle zeigt eine benutzerdefinierte Fehlerantwortrichtlinie, die auf die Ebene des Load Balancers, die URL-Domainebene und die URL-Pfadebene der URL-Zuordnung angewendet wird.

Richtlinienebene API-Feld
Load-Balancer urlMaps.defaultCustomErrorResponsePolicy
URL-Domain pathMatchers[].defaultCustomErrorResponsePolicy
URL-Pfad

pathMatchers[].pathRules[].customErrorResponsePolicy

pathMatchers[].routeRules[].customErrorResponsePolicy

Wenn Sie eine benutzerdefinierte Fehlerantwortrichtlinie auf mehreren Ebenen der URL-Zuordnungsressource konfigurieren, wird das Fehlerobjekt zurückgegeben, das von der benutzerdefinierten Fehlerrichtlinie auf der untersten Ebene der URL-Zuordnung angegeben wird. Fehlerantwortrichtlinien, die auf einer niedrigeren Ebene der URL-Zuordnung definiert sind, sind spezifischer und haben Vorrang vor Fehlerantwortrichtlinien, die auf einer höheren Ebene der URL-Zuordnung definiert sind.

Beispielsweise wird eine benutzerdefinierte Fehlerantwortrichtlinie auf Ebene des Load Balancers nur angewendet, wenn die Richtlinie den Fehlerbedingungen entspricht und für den Fehlercode auf den niedrigeren Ebenen keine entsprechende Richtlinie definiert wurde: die URL-Domain oder URL-Pfad Ebenso wird eine benutzerdefinierte Fehlerantwortrichtlinie auf URL-Domainebene nur angewendet, wenn die Richtlinie den Fehlerbedingungen entspricht und für den Fehlercode auf der niedrigeren Ebene, dem URL-Pfad, keine entsprechende Richtlinie definiert wurde. Weitere Informationen zu dieser Konfiguration finden Sie unter Detaillierte benutzerdefinierte Fehlerantwortrichtlinien für verschiedene Domains, Pfade und Fehlerantwortcodes konfigurieren.

Mehrere Fehlerantwortregeln angeben, die mit HTTP-Fehlerantwortcodes übereinstimmen

Auf jeder Ebene innerhalb einer benutzerdefinierten Fehlerantwortrichtlinie können Sie mehrere Fehlerantwortregeln angeben. Diese Regeln können eine HTTP-Fehlerantwort mit bestimmten Fehlercodes oder einer Reihe von Fehlercodes abgleichen. Wenn Sie eine Regel für einen Bereich von Fehlercodes und Regeln für bestimmte Fehlercodes angeben, haben Regeln mit spezifischen Fehlercodes Vorrang.

Angenommen, Sie konfigurieren eine Regel für den Fehlercode 401 (Unauthorized) und eine weitere Regel für alle Fehlercodes der Serie 4xx. Wenn der Backend-Dienst den Fehlercode 401 zurückgibt, wird die Regel angewendet, die dem Fehler 401 entspricht. Wenn der Backend-Dienst jedoch den Fehlercode 403 zurückgibt, wird die Regel für Fehler vom Typ 4xx wirksam.

HTTP-Antwortcode überschreiben

Mit den Fehlerantwortregeln können Sie den vom Load Balancer zurückgegebenen HTTP-Antwortcode ändern. Das bedeutet im Wesentlichen, dass Sie den vom Server generierten Antwortcode überschreiben und den endgültigen Antwortcode für die Anfrage definieren können. Sie können festlegen, dass ein beliebiger HTTP-Antwortcode zurückgegeben wird, einschließlich 200 (OK), der Serie 4xx oder der Serie 5xx oder eines anderen dreistelligen Antwortcodes. Weitere Informationen zum Überschreiben des Antwortcodes finden Sie unter Fehlerseite für einen bestimmten Fehlercode für einen bestimmten Host konfigurieren.

Wenn Sie einen Antwortcode für die Ignorierung definieren, wird er in den Load Balancing-Protokollen als neues Feld overrideResponseCodeServed erfasst. Dieses Feld wird nur für Anfragen ausgefüllt, bei denen durch die Richtlinie für benutzerdefinierte Fehlerantworten ein Überschreibungsantwortcode angewendet wird.

Der im Feld httpRequest protokollierte status-Code ist nicht betroffen. Er erfasst den vom Server generierten HTTP-Antwortcode oder die HTTP-Antwort, die vom Load Balancer zurückgegeben wird. Dieser Statuscode kann sich vom tatsächlichen Code unterscheiden, der an den Client gesendet wird, wenn der Antwortcode durch eine benutzerdefinierte Richtlinie für Fehlerantworten geändert wird.

Benutzerdefinierte Fehlerantworten im Cache speichern

Eine benutzerdefinierte Fehlerantwort kann im Cache gespeichert werden, indem Sie für das Backend, das den Fehler generiert hat, eine negative Caching-Richtlinie angeben. Dies ermöglicht detaillierte Kontrolle über das Caching für häufige Fehler oder Weiterleitungen. So können Sie die Belastung am Ursprung verringern und durch die reduzierte Antwortlatenz die Abläufe für die Endnutzer verbessern.

Eine für das Back-End definierte Richtlinie für das negative Caching, das den Fehler generiert hat, hat immer Vorrang vor den Cache-Control-Metadaten, die für das Fehlerobjekt im Fehlerdienst definiert sind. Wenn der Load Balancer einen Override-Antwortcode zurückgibt, wird eine Richtlinie für das negative Caching basierend auf dem Wert des Override-Antwortcodes angewendet, nicht auf dem ursprünglichen Antwortcode, den das Backend an den Load Balancer zurückgegeben hat. Wenn ein Code ohne Fehler (HTTP 200) als Antwortcode für die Überschreibung zurückgegeben wird, gilt keine Richtlinie für das negative Caching.

Wenn die Gültigkeitsdauer (TTL) für die Fehlerantwort noch nicht abgelaufen ist, liefert der Load Balancer weiterhin im Cache gespeicherte Inhalte, ohne die Anfrage an einen Back-End-Dienst oder einen Back-End-Bucket weiterzuleiten. Dieses Verhalten hängt jedoch davon ab, ob Cloud CDN für Ihren Load Balancer aktiviert ist.

Cloud CDN ist für den Load Balancer aktiviert.

In diesem Abschnitt wird das Verhalten des Load Balancers beschrieben, wenn Cloud CDN aktiviert ist und benutzerdefinierte Fehlerantworten verwendet werden.

  1. Wenn der Load Balancer eine Anfrage erhält, wird der Cloud CDN-Cache geprüft. Wenn der Load Balancer eine im Cache gespeicherte Antwort auf die Anfrage des Nutzers findet, gibt er diese an den Nutzer zurück. Diese im Cache gespeicherte Antwort kann entweder die angeforderten Inhalte des Nutzers oder ein benutzerdefiniertes Fehlerobjekt sein.

  2. Wenn ein Cache-Fehler auftritt, wird die Anfrage vom Load Balancer verarbeitet und an das Backend gesendet.

  3. Wenn das Back-End eine Antwort ohne Fehler zurückgibt, wird diese Antwort an den Endnutzer zurückgegeben. Wenn bei einer Clientanfrage jedoch ein Fehler auftritt (ein HTTP-Antwortcode vom Typ 4xx oder 5xx), versucht der Load Balancer, das benutzerdefinierte Fehlerobjekt vom Fehlerdienst abzurufen, den Sie so angegeben haben:

    1. Der Load Balancer prüft alle benutzerdefinierten Fehlerantwortrichtlinien und ruft den entsprechenden Pfad des benutzerdefinierten Fehlerobjekts ab, der dem Fehlerstatuscode und anderen Abgleichbedingungen entspricht.

    2. Der Load Balancer leitet die Anfrage für das benutzerdefinierte Fehlerobjekt an den Fehlerdienst weiter, den Sie in der Richtlinie für benutzerdefinierte Fehlerantworten angegeben haben. Der Begriff Fehlerdienst bezieht sich auf den Backend-Bucket oder den Backend-Dienst, der den benutzerdefinierten Fehlerinhalt bereitstellt.

    3. Der Load Balancer gibt das benutzerdefinierte Fehlerobjekt an den Client zurück, der die Anfrage gestellt hat. Außerdem wird das Objekt an Cloud CDN gesendet, um es für den in cdnPolicy.negativeCachingPolicy[].ttl angegebenen Zeitraum im Cache zu speichern.

Cloud CDN ist für den Load Balancer deaktiviert

Wenn Cloud CDN deaktiviert ist, empfehlen wir, als Fehlerdienst einen Backend-Bucket und keinen Backend-Dienst zu verwenden. Das liegt daran, dass ein Back-End-Dienst keine Inhalte zwischenspeichern kann, wenn Cloud CDN deaktiviert ist. Back-End-Buckets haben jedoch eine integrierte Caching-Funktion und können Fehlerantworten auch dann im Cache speichern, wenn Cloud CDN deaktiviert ist.

Beschränkungen

  • Benutzerdefinierte Fehlerantworten werden nur mit dem globalen externen Application Load Balancer unterstützt. Der regionale und der klassische Modus werden nicht unterstützt.

  • Wenn das benutzerdefinierte Fehlerobjekt nicht aus dem Fehlerdienst abgerufen werden kann, z. B. weil der Inhaltspfad falsch konfiguriert ist, wird ein allgemeines Fehlerobjekt ohne Markenbezug angezeigt.

  • Die benutzerdefinierte Fehlerantwortrichtlinie überwacht oder filtert das vom Fehlerdienst zurückgegebene Objekt nicht auf Sicherheitsrisiken. Daher sollten Sie sorgfältig darauf achten, Sicherheitslücken zu beseitigen und die Auswirkungen einer potenziellen Gefährdung zu begrenzen.

  • Benutzerdefinierte Fehlerantworten werden nur für öffentlich lesbare Cloud Storage-Buckets unterstützt.

    Lesen Sie die allgemeinen Best Practices für Cloud Storage, um Fehlkonfigurationen bei der Verwendung eines Cloud Storage-Buckets zu vermeiden.

  • Benutzerdefinierte Fehlerantworten funktionieren nicht, wenn Ihr globaler externer Application Load Balancer nur Backend-Buckets hat. Neben dem Backend-Bucket muss mindestens ein Back-End-Dienst mit dem Load Balancer verbunden sein.

  • Benutzerdefinierte Antwortheader, die basierend auf der Quelle der benutzerdefinierten Fehlerantwort definiert sind, werden nicht auf ausgehende Antworten angewendet.

Preise

Für die Verwendung benutzerdefinierter Fehlerantworten fallen keine zusätzlichen Kosten an. Es gelten die Standardpreise für Google Cloud Load Balancing. Weitere Informationen finden Sie unter Preise.

Nächste Schritte