Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Erstellen von benutzerdefinierten Fehlerantworten
Wenn ein Objekt, über das Sie bereitstellen, aus irgendeinem Grund nicht verfügbar CloudFront ist, gibt Ihr Webserver in der Regel einen entsprechenden HTTP-Statuscode zurück, CloudFront um darauf hinzuweisen. Wenn ein Betrachter beispielsweise eine ungültige URL anfordert, gibt Ihr Webserver einen HTTP-Statuscode 404 (Not Found) CloudFront zurück und gibt diesen Statuscode dann an den Betrachter zurück. CloudFront Anstatt diese Standardfehlerantwort zu verwenden, können Sie eine benutzerdefinierte Antwort erstellen, die zum Viewer CloudFront zurückkehrt.
Wenn Sie die Rückgabe einer benutzerdefinierten Fehlerseite für einen HTTP-Statuscode konfigurieren CloudFront , die benutzerdefinierte Fehlerseite jedoch nicht verfügbar ist, wird der Statuscode, den Sie von der Quelle CloudFront erhalten haben und die benutzerdefinierten Fehlerseiten enthalten, an den Betrachter CloudFront zurückgegeben. Nehmen wir zum Beispiel an, Ihr benutzerdefinierter Ursprung gibt einen Statuscode 500 zurück und Sie haben konfiguriert CloudFront , dass eine benutzerdefinierte Fehlerseite für einen 500-Statuscode aus einem Amazon S3-Bucket abgerufen wird. Jemand hat jedoch versehentlich die benutzerdefinierte Fehlerseite aus Ihrem Amazon S3 S3-Bucket gelöscht. CloudFront gibt einen HTTP-404-Statuscode (Nicht gefunden) an den Betrachter zurück, der das Objekt angefordert hat.
Wenn eine benutzerdefinierte Fehlerseite an einen Betrachter CloudFront zurückgegeben wird, zahlen Sie die CloudFront Standardgebühren für die benutzerdefinierte Fehlerseite, nicht die Gebühren für das angeforderte Objekt. Weitere Informationen zu CloudFront Gebühren finden Sie unter [ CloudFrontAmazon-Preise](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Konfigurieren des Fehlerantwortverhaltens](custom-error-pages-procedure.md)
+ [Erstellen einer benutzerdefinierten Fehlerseite für bestimmte HTTP-Statuscodes](creating-custom-error-pages.md)
+ [Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten](custom-error-pages-different-locations.md)
+ [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md)
+ [Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden](custom-error-pages-expiration.md)
# Konfigurieren des Fehlerantwortverhaltens
Sie haben mehrere Optionen, um zu verwalten, wie CloudFront auf einen Fehler reagiert wird. Um benutzerdefinierte Fehlerantworten zu konfigurieren, können Sie die CloudFront Konsole, die CloudFront API oder verwenden CloudFormation. Unabhängig davon, wie Sie die Konfiguration aktualisieren, sollten Sie die folgenden Tipps und Empfehlungen beachten:
+ Speichern Sie Ihre benutzerdefinierten Fehlerseiten an einem Ort, auf den zugegriffen werden kann CloudFront. Wir empfehlen Ihnen, sie in einem Amazon-S3-Bucket zu speichern und [sie nicht am selben Ort wie den Rest der Inhalte Ihrer Website oder Anwendung zu speichern](custom-error-pages-different-locations.md). Wenn Sie die benutzerdefinierten Fehlerseiten auf demselben Ursprung wie Ihre Website oder Anwendung speichern und der Ursprung beginnt, 5xx-Fehler zurückzugeben, CloudFront können Sie die benutzerdefinierten Fehlerseiten nicht abrufen, da der Ursprungsserver nicht verfügbar ist. Weitere Informationen finden Sie unter [Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten](custom-error-pages-different-locations.md).
+ Stellen Sie sicher, dass dieser Benutzer berechtigt CloudFront ist, Ihre benutzerdefinierten Fehlerseiten abzurufen. Wenn die benutzerdefinierten Fehlerseiten in Amazon S3 gespeichert sind, müssen die Seiten öffentlich zugänglich sein oder Sie müssen eine CloudFront [Origin Access Control (OAC)](private-content-restricting-access-to-s3.md) konfigurieren. Wenn die benutzerdefinierten Fehlerseiten in einem benutzerdefinierten Ursprung gespeichert sind, müssen die Seiten öffentlich zugänglich sein.
+ (Optional) Konfigurieren Sie Ihren Ursprung so, dass ein `Cache-Control`- oder `Expires`-Header zusammen mit den benutzerdefinierten Fehlerseiten hinzugefügt wird, wenn Sie möchten. Sie können auch die Einstellung **Minimum TTL für Error Caching** verwenden, um zu steuern, wie lange die benutzerdefinierten Fehlerseiten CloudFront zwischengespeichert werden. Weitere Informationen finden Sie unter [Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden](custom-error-pages-expiration.md).
## Konfigurieren benutzerdefinierter Fehlerantworten
Um benutzerdefinierte Fehlerantworten in der CloudFront Konsole zu konfigurieren, benötigen Sie eine Distribution. CloudFront In der Konsole stehen die Konfigurationseinstellungen für benutzerdefinierte Fehlerantworten nur für vorhandene Verteilungen zur Verfügung. Informationen zum Erstellen einer Verteilung finden Sie unter [Beginnen Sie mit einer CloudFront Standarddistribution](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Konfigurieren benutzerdefinierter Fehlerantworten (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Seite **Verteilungen** in der CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. Wählen Sie in der Liste der Verteilungen die zu aktualisierende Verteilung aus.
1. Wählen Sie die Registerkarte **Fehlerseiten** und wählen Sie dann **Benutzerdefinierte Fehlerantwort erstellen**.
1. Geben Sie die entsprechenden Werte ein. Weitere Informationen finden Sie unter [Benutzerdefinierte Fehlerseiten und Zwischenspeicherung von Fehlern](DownloadDistValuesErrorPages.md).
1. Nachdem Sie die gewünschten Werte eingegeben haben, wählen Sie **Erstellen**.
------
#### [ CloudFront API or CloudFormation ]
Um benutzerdefinierte Fehlerantworten mit der CloudFront API oder zu konfigurieren CloudFormation, verwenden Sie den `CustomErrorResponse` Typ in einer Distribution. Weitere Informationen finden Sie hier:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) im *AWS CloudFormation -Benutzerhandbuch*
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)in der *Amazon CloudFront API-Referenz*
------
# Erstellen einer benutzerdefinierten Fehlerseite für bestimmte HTTP-Statuscodes
Wenn Sie statt der Standardmeldung lieber eine benutzerdefinierte Fehlermeldung anzeigen möchten, z. B. eine Seite, die dieselbe Formatierung wie der Rest Ihrer Website verwendet, können Sie ein Objekt (z. B. eine HTML-Datei), das Ihre benutzerdefinierte Fehlermeldung enthält, an den Viewer CloudFront zurückgeben lassen.
Um die Datei, die Sie zurückgeben möchten, und die Fehler, für die die Datei zurückgegeben werden soll, anzugeben, aktualisieren Sie Ihre CloudFront Distribution, sodass diese Werte angegeben werden. Weitere Informationen finden Sie unter [Konfigurieren des Fehlerantwortverhaltens](custom-error-pages-procedure.md).
Zum Beispiel ist das Folgende eine benutzerdefinierte Fehlerseite:
![\[Screenshot einer benutzerdefinierten AWS 404-Beispielseite.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Sie können ein anderes Objekt für jeden unterstützten HTTP-Statuscode festlegen oder Sie können dasselbe Objekt für alle unterstützten Statuscodes verwenden. Es ist möglich, benutzerdefinierte Fehlerseiten für einige Statuscodes festzulegen und für andere nicht.
Die Objekte, über die Sie bereitstellen, CloudFront können aus verschiedenen Gründen nicht verfügbar sein. Diese gliedern sich in zwei große Kategorien:
+ *Client-Fehler* weisen auf ein Problem mit der Anfrage hin. Beispielsweise ist ein Objekt mit dem angegebenen Namen nicht verfügbar oder der Benutzer verfügt nicht über die erforderlichen Berechtigungen, um ein Objekt in Ihrem Amazon S3-Bucket abzurufen. Wenn ein Client-Fehler auftritt, gibt der Ursprung einen HTTP-Statuscode im Bereich 4xx bis CloudFront zurück.
+ *Server-Fehler* weisen auf ein Problem mit dem Ursprungs-Server hin. Beispielsweise ist der HTTP-Server ausgelastet oder nicht verfügbar. Wenn ein Serverfehler auftritt, gibt Ihr Ursprungsserver entweder einen HTTP-Statuscode im Bereich 5xx zurück oder CloudFront er erhält für einen bestimmten Zeitraum keine Antwort von Ihrem Ursprungsserver und nimmt den Statuscode 504 an (Gateway Timeout). CloudFront
Zu den HTTP-Statuscodes, für die eine benutzerdefinierte Fehlerseite zurückgegeben werden CloudFront kann, gehören die folgenden:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Hinweise**
Wenn CloudFront erkannt wird, dass die Anfrage möglicherweise unsicher ist, wird anstelle einer benutzerdefinierten Fehlerseite ein 400-Fehler (Bad Request) CloudFront zurückgegeben.
Sie können eine benutzerdefinierte Fehlerseite für den HTTP-Statuscode 416 (Requested Range Not Satisfiable) erstellen und Sie können den HTTP-Statuscode ändern, der den Zuschauern CloudFront zurückgegeben wird, wenn Ihr Absender den Statuscode 416 an zurückgibt. CloudFront Weitere Informationen finden Sie unter [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md). Status-Code 416-Antworten werden jedoch CloudFront nicht zwischengespeichert, sodass dieser auch dann nicht verwendet wird, wenn Sie für den Statuscode 416 einen Wert für **Error Caching Minimum TTL** angeben. CloudFront
In einigen Fällen CloudFront gibt es keine benutzerdefinierte Fehlerseite für den HTTP-Statuscode 503 zurück, selbst wenn Sie dies konfigurieren CloudFront . Wenn der CloudFront Fehlercode `Capacity Exceeded` oder ist`Limit Exceeded`, wird ein 503-Statuscode an den Viewer CloudFront zurückgegeben, ohne Ihre benutzerdefinierte Fehlerseite zu verwenden.
Wenn Sie eine benutzerdefinierte Fehlerseite erstellt haben, CloudFront wird `Connection: keep-alive` für die folgenden Antwortcodes `Connection: close` oder zurückgegeben:
CloudFront gibt `Connection: close` für Statuscodes zurück: 400, 405, 414, 416, 500, 501
CloudFront gibt `Connection: keep-alive` für Statuscodes zurück: 403, 404, 502, 503, 504
Eine ausführliche Erläuterung, wie CloudFront mit Fehlerantworten aus Ihrem System umgegangen wird, finden Sie unter[Wie CloudFront werden die HTTP-Statuscodes 4xx und 5xx von Ihrem Ursprung verarbeitet](HTTPStatusCodes.md).
# Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten
Wenn Sie Ihre Objekte und Ihre benutzerdefinierten Fehlerseiten an verschiedenen Orten speichern möchten, muss Ihre Verteilung ein Cache-Verhalten mit den folgenden Eigenschaften enthalten:
+ Der Wert von **Path Pattern** stimmt mit dem Pfad zu Ihren benutzerdefinierten Fehlermeldungen überein. Angenommen, Sie haben benutzerdefinierte Fehlerseiten für 4xx-Fehler in einem Amazon S3-Bucket in einem Verzeichnis mit dem Namen gespeicher `/4xx-errors`. Ihre Verteilung muss ein Cache-Verhalten beinhalten, für welches das Pfadmuster Anfragen für Ihre benutzerdefinierten Fehlerseiten an diesen Ort weiterleitet, z. B, `/4xx-errors/*`.
+ Der Wert von **Origin** legt den Wert von **Origin ID** für den Ursprung fest, der Ihre benutzerdefinierten Fehlerseiten enthält.
Weitere Informationen finden Sie unter [Einstellungen für das Cache-Verhalten](DownloadDistValuesCacheBehavior.md).
# Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront
Sie können so konfigurieren CloudFront , dass dem Betrachter ein anderer HTTP-Statuscode zurückgegeben wird als der, den CloudFront er vom Absender erhalten hat. Wenn Ihr Absender beispielsweise den Statuscode 500 an zurückgibtCloudFront, CloudFront möchten Sie möglicherweise eine benutzerdefinierte Fehlerseite und den Statuscode 200 (OK) an den Betrachter zurückgeben. Es gibt eine Vielzahl von Gründen, warum Sie dem Betrachter möglicherweise einen Statuscode zurückgeben CloudFront möchten, der sich von dem unterscheidet, zu dem Ihr Ursprung zurückgekehrt istCloudFront:
+ Einige Internetgeräte (beispielsweise einige Firewalls und Unternehmens-Proxys) fangen HTTP 4xx- und 5xx-Statuscodes ab und verhindern, dass die Antwort an den Betrachter zurückgegeben wird. Wenn Sie in diesem Szenario `200` ersetzen, wird die Antwort nicht abgefangen.
+ Wenn Sie nicht zwischen verschiedenen Client- oder Serverfehlern unterscheiden möchten, können Sie `400` oder `500` als den Wert angeben, der für alle 4xx- oder 5xx-Statuscodes CloudFront zurückgegeben wird.
+ Möglicherweise möchten Sie einen `200`-Statuscode (OK) und eine statische Website zurückgeben, sodass Ihre Kunden nicht wissen, dass die Website nicht verfügbar ist.
Wenn Sie [CloudFront Standardprotokolle](AccessLogs.md) aktivieren und so konfigurierenCloudFront , dass der HTTP-Statuscode in der Antwort geändert wird, enthält der Wert der `sc-status` Spalte in den Protokollen den von Ihnen angegebenen Statuscode. Der Wert der `x-edge-result-type`-Spalte wird jedoch nicht beeinflusst. Sie enthält den Ergebnistyp der Antwort vom Ursprung. Nehmen wir zum Beispiel an, Sie konfigurieren CloudFront , dass der Statuscode von `200` an den Betrachter zurückgegeben wird, wenn der Ursprung `404` (Not Found) zu zurückkehrt CloudFront. Wenn der Ursprung auf eine Anfrage mit dem Statuscode `404` antwortet, ist der Wert in der Spalte `sc-status` im Protokoll `200`, der Wert in der Spalte `x-edge-result-type` jedoch `Error`.
Sie können so konfigurieren CloudFront , dass jeder der folgenden HTTP-Statuscodes zusammen mit einer benutzerdefinierten Fehlerseite zurückgegeben wird:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden
CloudFront speichert Fehlerantworten für eine Standarddauer von 10 Sekunden im Cache. CloudFront sendet dann die nächste Anfrage für das Objekt an Ihre Quelle, um zu überprüfen, ob das Problem, das den Fehler verursacht hat, behoben wurde und das angeforderte Objekt verfügbar ist.
Sie können für jeden 4xx- und 5xx-Statuscode, der zwischengespeichert wird, die Dauer des **Fehler-Cachings — die Mindest-TTL für das Fehler-Caching** angeben. CloudFront (Weitere Informationen finden Sie unter [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Wenn Sie eine Dauer angeben, beachten Sie Folgendes:
+ Wenn Sie eine kurze Dauer für das Zwischenspeichern von Fehlern angeben, werden mehr Anfragen an Ihren Ursprung weitergeleitet, CloudFront als wenn Sie eine längere Dauer angeben. Bei 5xx-Fehlern verschlimmert dies möglicherweise das Problem, das ursprünglich dazu geführt hat, dass Ihr Ursprung einen Fehler zurückgibt.
+ Wenn Ihr Absender einen Fehler für ein Objekt zurückgibt, CloudFront beantwortet er Anfragen für das Objekt entweder mit der Fehlerantwort oder mit Ihrer benutzerdefinierten Fehlerseite, bis die Dauer der Fehlerzwischenspeicherung abgelaufen ist. Wenn Sie eine lange Dauer für das Zwischenspeichern von Fehlern angeben, reagiert das CloudFront Objekt möglicherweise noch lange auf Anfragen mit einer Fehlerantwort oder Ihrer benutzerdefinierten Fehlerseite, nachdem das Objekt wieder verfügbar ist.
**Anmerkung**
Sie können eine benutzerdefinierte Fehlerseite für HTTP-Statuscode 416 (Requested Range Not Satisfiable) erstellen und Sie können den HTTP-Statuscode ändern, den CloudFront an Betrachter zurückgibt, wenn Ihr Ursprung einen Statuscode 416 an CloudFront zurückgibt. (Weitere Informationen finden Sie unter [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md).) Status-Code 416-Antworten werden jedoch CloudFront nicht zwischengespeichert. Selbst wenn Sie einen Wert für **Error Caching Minimum TTL** für den Statuscode 416 angeben, wird dieser Wert nicht verwendet. CloudFront
Wenn Sie steuern möchten, wie lange Fehler für einzelne Objekte CloudFront zwischengespeichert werden, können Sie Ihren Ursprungsserver so konfigurieren, dass er der Fehlerantwort für dieses Objekt den entsprechenden Header hinzufügt.
Wenn der Ursprung eine `Cache-Control: s-maxage` OR-Direktive `Cache-Control: max-age` oder einen `Expires` Header hinzufügt, werden Fehlerantworten CloudFront zwischengespeichert, je nachdem, welcher Wert im Header oder der Mindest-TTL für **Error Caching gilt**.
**Anmerkung**
Beachten Sie, dass die Werte für `Cache-Control: max-age` und `Cache-Control: s-maxage` nicht größer als der Wert für **Maximum TTL** sein können, der für das Cache-Verhalten festgelegt wurde, für das die Fehlerseite abgerufen wird.
Wenn der Ursprung eine `Cache-Control: private` Direktive `Cache-Control: no-store``Cache-Control: no-cache`, oder für die Fehlercodes 404, 410, 414 oder 501 hinzufügt, wird die CloudFront Fehlerantwort nicht zwischengespeichert. CloudFront Ignoriert bei allen anderen Fehlercodes die `private` Direktiven `no-store``no-cache`, und und speichert die Fehlerantwort für den Wert **Error Caching** Minimum TTL zwischen.
**Wenn der Ursprung weitere `Cache-Control` Direktiven hinzufügt oder keine Header hinzufügt, werden die Fehlerantworten für den Wert von Error CloudFront Caching Minimum TTL zwischengespeichert.**
Wenn die Ablaufzeit für einen 4xx- oder 5xx-Statuscode für ein Objekt länger ist, als Sie warten möchten, und das Objekt wieder verfügbar ist, können Sie den zwischengespeicherten Fehlercode mit der URL des angefragten Objekts aufheben. Wenn Ihr Ursprung eine Fehlermeldung für mehrere Objekte zurückgibt, müssen Sie die Gültigkeit aller Objekte einzeln aufheben. Weitere Informationen zur Aufhebung der Gültigkeit von Objekten finden Sie unter [Aufheben der Gültigkeit von Dateien zum Entfernen von Inhalten](Invalidation.md).
Wenn Sie das Caching für einen S3-Bucket-Ursprung aktiviert haben und Sie in Ihrer CloudFront Distribution einen Fehler beim Zwischenspeichern einer Mindest-TTL von 0 Sekunden konfigurieren, wird immer noch ein Fehler beim Zwischenspeichern einer Mindest-TTL von 1 Sekunde für Fehler mit S3-Ursprung angezeigt. CloudFront tut dies, um Ihren Origin vor S-Angriffen zu schützen. DDo Dies gilt nicht für andere Arten von Ursprüngen.