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.
# Behebung von Statuscodes für die Fehlerantwort in CloudFront
Wenn CloudFront ein Objekt von Ihrem Absender angefordert wird und der Absender einen HTTP-Statuscode 4xx oder 5xx zurückgibt, liegt ein Problem mit der Kommunikation zwischen Ihnen CloudFront und Ihrem Absender vor.
Dieses Thema enthält auch Schritte zur Fehlerbehebung für diese Statuscodes bei der Verwendung von Lambda @Edge oder CloudFront Functions.
Die folgenden Themen enthalten detaillierte Erläuterungen zu den möglichen Ursachen für diese Fehlerreaktionen und bieten step-by-step Anleitungen zur Diagnose und Lösung der zugrunde liegenden Probleme.
**Topics**
+ [HTTP 400-Statuscode (Bad Request)](http-400-bad-request.md)
+ [HTTP-Statuscode 401 (Nicht autorisiert)](http-401-unauthorized.md)
+ [HTTP-Statuscode 403 (Ungültige Methode)](http-403-invalid-method.md)
+ [HTTP-Statuscode 403 (Genehmigung verweigert)](http-403-permission-denied.md)
+ [HTTP-Statuscode 404 (Nicht gefunden)](http-404-not-found.md)
+ [HTTP-Statuscode 412 (Vorbedingung fehlgeschlagen)](http-412-precondition-failed.md)
+ [HTTP-Statuscode 500 (Interner Serverfehler)](http-500-internal-server-error.md)
+ [HTTP 502-Statuscode (Bad Gateway)](http-502-bad-gateway.md)
+ [HTTP 503-Statuscode (Service nicht verfügbar)](http-503-service-unavailable.md)
+ [HTTP 504-Statuscode (Gateway Timeout)](http-504-gateway-timeout.md)
# HTTP 400-Statuscode (Bad Request)
CloudFront gibt eine ungültige 400-Anforderung zurück, wenn der Client einige ungültige Daten in der Anfrage sendet, z. B. fehlende oder falsche Inhalte in der Nutzlast oder in den Parametern. Es kann sich auch um einen generischen Client-Fehler handeln.
## Amazon-S3-Ursprung gibt einen 400-Fehler zurück
Wenn Sie mit Ihrer CloudFront Distribution einen Amazon S3 S3-Ursprung verwenden, sendet Ihre Distribution möglicherweise Fehlerantworten mit dem HTTP-Statuscode 400 Bad Request und eine Meldung ähnlich der folgenden:
*Der Autorisierungsheader ist falsch; die Region '**' ist falsch; '' ** wird erwartet*
Beispiel:
*Der Autorisierungs-Header ist fehlerhaft; die Region "us-east-1" ist falsch; erwartet wird "us-west-2"*
Dieses Problem kann im folgenden Szenario auftreten:
1. Der Ursprung Ihrer CloudFront Distribution ist ein Amazon S3 S3-Bucket.
1. Sie haben den S3-Bucket von einer AWS Region in eine andere verschoben. Das heißt, Sie haben den S3-Bucket gelöscht und später einen neuen Bucket mit demselben Bucket-Namen erstellt, aber in einer anderen AWS Region als der, in der sich der ursprüngliche S3-Bucket befand.
Um diesen Fehler zu beheben, aktualisieren Sie Ihre CloudFront Distribution so, dass sie den S3-Bucket in der aktuellen AWS Region des Buckets findet.
**Um Ihre CloudFront Distribution zu aktualisieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie die Distribution aus, die diesen Fehler verursacht.
1. Wählen Sie **Ursprünge und Ursprungsgruppen** aus.
1. Suchen Sie den Ursprung für den S3-Bucket, den Sie verschoben haben. Aktivieren Sie das Kontrollkästchen neben diesem Ursprung und wählen Sie dann **Bearbeiten** aus.
1. Wählen Sie **Yes, Edit** aus. Sie müssen keine Einstellungen ändern, bevor Sie **Yes, Edit (Ja, Bearbeiten)** auswählen.
Wenn Sie diese Schritte abgeschlossen haben, stellt Ihre CloudFront Distribution erneut bereit. Während die Distribution bereitgestellt wird, wird in der Spalte **Letzte Änderung** der Status **Bereitgestellt** angezeigt. Einige Zeit nach Abschluss der Bereitstellung sollten Sie die Fehlerantwort `AuthorizationHeaderMalformed` nicht mehr erhalten.
## Der als Ursprung verwendete Application Load Balancer gibt einen 400-Fehler zurück
Wenn Sie mit Ihrer CloudFront Distribution einen Application Load Balancer Balancer-Ursprung verwenden, kann ein 400-Fehler unter anderem folgende Ursachen haben:
+ Der Client hat eine falsch formatierte Anforderung gesendet, die die HTTP-Spezifikation nicht erfüllt.
+ Der Anforderungsheader überschreitet 16 KB pro Anforderungszeile, 16 KB pro einzelnem Header oder 64 KB für den gesamtem Anforderungsheader.
+ Der Client hat die Verbindung beendet, bevor er den vollständigen Anfragetext gesendet hat.
# HTTP-Statuscode 401 (Nicht autorisiert)
Der Statuscode 401 „Nicht autorisiert“ gibt an, dass die Client-Anforderung nicht abgeschlossen wurde, da sie keine gültigen Authentifizierungsdaten für die angeforderte Ressource enthält. Dieser Statuscode wird mit dem HTTP-Antwortheader `WWW-Authenticate` gesendet, der Informationen darüber enthält, wie der Client die Ressource erneut anfordern kann, nachdem er den Benutzer zur Eingabe von Authentifizierungsdaten aufgefordert hat. Weitere Informationen finden Sie unter [401 Nicht autorisiert](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401).
Wenn Ihr Absender erwartet CloudFront, dass ein `Authorization` Header die Anfragen authentifiziert, CloudFront muss er den `Authorization` Header an den Ursprung weiterleiten, um einen 401-Unauthorized-Fehler zu vermeiden. Wenn Sie CloudFront eine Viewer-Anfrage an Ihren Ursprung weiterleiten, CloudFront werden standardmäßig einige Viewer-Header entfernt, einschließlich des Headers. `Authorization` Um sicherzustellen, dass Ihr Ursprung immer den `Authorization`-Header in Ursprungsanforderungen erhält, haben Sie folgende Möglichkeiten:
+ Fügen Sie den `Authorization`-Header mithilfe einer Cache-Richtlinie zum Cache-Schlüssel hinzu. Alle Header im Cache-Schlüssel werden automatisch in Ursprungsanforderungen eingeschlossen. Weitere Informationen finden Sie unter [Steuern des Cache-Schlüssels mit einer Richtlinie](controlling-the-cache-key.md).
+ Verwenden Sie eine Herkunftsanforderungsrichtlinie, die alle Betrachter-Header an den Ursprung weiterleitet. Sie können den `Authorization` Header in einer ursprünglichen Anforderungsrichtlinie nicht einzeln weiterleiten. Wenn Sie jedoch alle Viewer-Header weiterleiten, wird der `Authorization` Header in Viewer-Anfragen CloudFront einbezogen. CloudFrontstellt die Richtlinie für verwaltete `AllViewer` Ursprungsanfragen für diesen Anwendungsfall bereit. Weitere Informationen finden Sie unter [Verwenden verwalteter Ursprungsanforderungsrichtlinien](using-managed-origin-request-policies.md).
Weitere Informationen finden Sie unter [Wie kann ich so konfigurieren, CloudFront dass der Autorisierungsheader an den Ursprung weitergeleitet wird?](https://repost.aws/knowledge-center/cloudfront-authorization-header)
# HTTP-Statuscode 403 (Ungültige Methode)
CloudFront gibt einen 403-Fehler (Ungültige Methode) zurück, wenn Sie versuchen, eine HTTP-Methode zu verwenden, die Sie nicht in der CloudFront Distribution angegeben haben. Sie können für Ihre Distribution eine der folgenden Optionen auswählen:
+ CloudFront Nur Weiterleitungen `GET` und `HEAD` Anfragen.
+ CloudFront nur Weiterleitungen `GET` und `HEAD` `OPTIONS` Anfragen.
+ CloudFront leitet`GET`,,`HEAD`, `OPTIONS` `PUT` `PATCH``POST`, und `DELETE` Anfragen weiter. (Wenn Sie diese Option auswählen, müssen Sie möglicherweise den Zugriff auf Ihren Amazon-S3-Bucket bzw. auf Ihren benutzerdefinierten Ursprung beschränken, um zu verhindern, dass Benutzer Operationen ausführen, für die sie nicht befugt sind. Möglicherweise möchten Sie nicht, dass Benutzer über Berechtigungen zum Löschen von Objekten von Ihrem Ursprung verfügen.
# HTTP-Statuscode 403 (Genehmigung verweigert)
Der HTTP-Fehler 403 bedeutet, dass der Client nicht berechtigt ist, auf die angeforderte Ressource zuzugreifen. Der Client versteht die Anforderung, kann den Viewer-Zugriff jedoch nicht autorisieren. Im Folgenden sind die häufigsten Ursachen aufgeführt, wenn dieser Statuscode CloudFront zurückgegeben wird:
**Topics**
+ [Alternativer CNAME ist falsch konfiguriert](#alternate-cname-incorrectly-configured)
+ [AWS WAF ist bei der CloudFront Verteilung oder am Ursprung konfiguriert](#aws-waf-configured-on-distribution-origin)
+ [Benutzerdefinierter Ursprung gibt einen 403-Fehler zurück](#custom-origin-returning-403)
+ [Amazon-S3-Ursprung gibt einen 403-Fehler zurück](#s3-origin-403-error)
+ [Geografische Einschränkungen geben einen 403-Fehler zurück](#geolocation-403)
+ [Die Konfiguration einer signierten URL oder eines signierten Cookies gibt einen 403-Fehler zurück](#signed-URLs-cookies-403)
+ [Gestapelte Distributionen verursachen einen 403-Fehler](#stacked-distributions-403)
## Alternativer CNAME ist falsch konfiguriert
Stellen Sie sicher, dass Sie den richtigen CNAME für die Distribution angegeben haben. Um einen alternativen CNAME anstelle der CloudFront Standard-URL zu verwenden:
1. Erstellen Sie einen CNAME-Eintrag in Ihrem DNS, um den CNAME auf die Verteilungs-URL zu CloudFront verweisen.
1. Fügen Sie den CNAME zu Ihrer CloudFront Verteilungskonfiguration hinzu.
Wenn Sie den DNS-Eintrag erstellen, aber den CNAME nicht zu Ihrer CloudFront Verteilungskonfiguration hinzufügen, gibt die Anfrage einen 403-Fehler zurück. Weitere Informationen zum Konfigurieren eines benutzerdefinierten CNAME finden Sie unter [Verwenden Sie Benutzerdefiniert, URLs indem Sie alternative Domainnamen hinzufügen (CNAMEs)](CNAMEs.md).
## AWS WAF ist bei der CloudFront Verteilung oder am Ursprung konfiguriert
Wenn AWS WAF sich zwischen dem Client und befindet CloudFront, CloudFront kann nicht zwischen einem 403-Fehlercode, der von Ihrem Ursprung zurückgegeben wird, und einem 403-Fehlercode, der zurückgegeben wird, AWS WAF wenn eine Anfrage blockiert wird, unterschieden werden.
Um die Quelle des 403-Statuscodes zu finden, überprüfen Sie Ihre ACL-Regel ( AWS WAF Web Access Control List) auf eine blockierte Anfrage. Weitere Informationen finden Sie unter den folgenden Themen:
+ [AWS WAF Web-Zugriffskontrolllisten (WebACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Testen und Optimieren Ihrer AWS WAF -Schutzmaßnahmen](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## Benutzerdefinierter Ursprung gibt einen 403-Fehler zurück
Wenn Sie einen benutzerdefinierten Ursprung verwenden, wird möglicherweise ein 403-Fehler angezeigt, wenn am Ursprung eine benutzerdefinierte Firewall-Konfiguration vorhanden ist. Um diesen Fehler zu beheben, richten Sie die Anforderung direkt an den Ursprung. Wenn Sie den Fehler auch ohne replizieren können CloudFront, verursacht der Ursprung den 403-Fehler.
Wenn der benutzerdefinierte Ursprung den Fehler verursacht, überprüfen Sie die Ursprungsprotokolle, um die Ursache des Fehlers herauszufinden. Weitere Informationen zur Behebung von Fehlern finden Sie in den folgenden Themen:
+ [Wie behebe ich den HTTP-Fehler 403 von API Gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Wie behebe ich den HTTP-Fehler 403 „Verboten“ im Application Load Balancer?](https://repost.aws/knowledge-center/alb-http-403-error)
## Amazon-S3-Ursprung gibt einen 403-Fehler zurück
Der 403-Fehler wird möglicherweise aus folgenden Gründen angezeigt:
+ CloudFront hat keinen Zugriff auf den Amazon S3 S3-Bucket. Dies kann passieren, wenn die Ursprungszugriffsidentität (OAI) oder Ursprungszugriffskontrolle (OAC) für Ihre Distribution nicht aktiviert ist und der Bucket privat ist.
+ Der angegebene Pfad in der angeforderten URL ist nicht korrekt.
+ Das angeforderte Objekt ist nicht vorhanden.
+ Der Host-Header wurde mit dem REST-API-Endpunkt weitergeleitet. Weitere Informationen finden Sie unter [Angabe des Buckets mit dem HTTP-Host-Header](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ Sie haben benutzerdefinierte Fehlerseiten konfiguriert. Weitere Informationen finden Sie unter [Wie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Geografische Einschränkungen geben einen 403-Fehler zurück
Wenn Sie geografische Einschränkungen (auch als Geoblocking bezeichnet) aktiviert haben, um zu verhindern, dass Benutzer an bestimmten geografischen Standorten auf Inhalte zugreifen, die Sie über eine CloudFront Distribution verteilen, erhalten blockierte Benutzer die Fehlermeldung 403.
Weitere Informationen finden Sie unter [Einschränken der geografischen Distribution Ihrer Inhalte](georestrictions.md).
## Die Konfiguration einer signierten URL oder eines signierten Cookies gibt einen 403-Fehler zurück
Wenn Sie für die Verhaltenskonfiguration Ihrer Distribution die Option **Zuschauerzugriff einschränken** aktiviert haben, URLs führen Anfragen, die keine signierten Cookies verwenden oder signiert sind, zu einem 403-Fehler. Weitere Informationen finden Sie unter den folgenden Themen:
+ [Stellen Sie private Inhalte mit signierten URLs und signierten Cookies bereit](PrivateContent.md)
+ [Wie behebe ich Probleme im Zusammenhang mit einer signierten URL oder signierten Cookies CloudFront?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Gestapelte Distributionen verursachen einen 403-Fehler
Wenn Sie zwei oder mehr Verteilungen innerhalb einer Kette von Anfragen an den ursprünglichen Endpunkt haben, wird ein 403-Fehler CloudFront zurückgegeben. Wir empfehlen nicht, eine Distribution vor einer anderen zu platzieren.
# HTTP-Statuscode 404 (Nicht gefunden)
CloudFront gibt einen 404-Fehler (Nicht gefunden) zurück, wenn der Client versucht, auf eine Ressource zuzugreifen, die nicht existiert. Wenn Sie diesen Fehler bei Ihrer CloudFront Distribution erhalten, kann dies unter anderem folgende Ursachen haben:
+ Die Ressource ist nicht vorhanden.
+ Die URL ist nicht korrekt.
+ Der benutzerdefinierte Ursprung gibt einen 404-Fehler zurück.
+ Benutzerdefinierte Fehlerseiten geben einen 404-Fehler zurück. (Jeder Fehlercode kann in 404 übersetzt werden.) Weitere Informationen finden Sie unter [Wie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ Die benutzerdefinierte Fehlerseite wurde versehentlich gelöscht, was zu einem 404-Fehler führt, da die Anforderung nach der gelöschten benutzerdefinierten Fehlerseite sucht. Weitere Informationen finden Sie unter [Wie CloudFront werden Fehler verarbeitet, wenn Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Falscher Ursprungspfad. Wenn der Ursprungspfad ausgefüllt ist, wird sein Wert an den Pfad jeder Anforderung vom Browser angehängt, bevor die Anforderung an den Ursprung weitergeleitet wird. Weitere Informationen finden Sie unter [Ursprungspfad](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# HTTP-Statuscode 412 (Vorbedingung fehlgeschlagen)
CloudFront gibt den Fehlercode 412 (Precondition Failed) zurück, wenn der Zugriff auf die Zielressource verweigert wurde. In einigen Fällen ist ein Server so konfiguriert, dass er Anforderungen erst akzeptiert, wenn bestimmte Bedingungen erfüllt sind. Wenn eine der angegebenen Bedingungen nicht erfüllt ist, erlaubt der Server dem Client nicht, auf die angegebene Ressource zuzugreifen. Stattdessen antwortet der Server mit dem Fehlercode 412.
Zu den häufigsten Ursachen für einen 412-Fehler in CloudFront gehören:
+ Bedingte Anforderungen für andere Methoden als `GET` oder `HEAD`, wenn die durch die Header `If-None-Match` oder `If-Unmodified-Since` definierte Bedingung nicht erfüllt ist. In diesem Fall kann die Anforderung, normalerweise ein Upload oder die Änderung einer Ressource, nicht gestellt werden.
+ Eine Bedingung in einem oder mehreren Anforderungsfeldern des CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)API-Vorgangs wird als falsch ausgewertet.
# HTTP-Statuscode 500 (Interner Serverfehler)
Der HTTP-Statuscode 500 (Interner Serverfehler) gibt an, dass der Server auf einen unerwarteten Zustand gestoßen ist, der ihn daran gehindert hat, die Anforderung zu bearbeiten. Im Folgenden sind einige der häufigsten Ursachen für 500-Fehler bei Amazon aufgeführt CloudFront.
**Topics**
+ [Der Origin-Server gibt den Fehler 500 zurück an CloudFront](#origin-server-500-error)
## Der Origin-Server gibt den Fehler 500 zurück an CloudFront
Ihr Ursprungsserver gibt möglicherweise einen Fehler 500 an zurück CloudFront. Weitere Informationen zur Fehlerbehebung erhalten Sie in folgenden Themen:
+ **Wenn Amazon S3 einen 500-Fehler zurückgibt**, finden Sie weitere Informationen unter [Wie behebe ich den HTTP-Fehler 500 oder 503 von Amazon S3?](https://repost.aws/knowledge-center/http-5xx-errors-s3)
+ **Wenn API Gateway einen 500-Fehler zurückgibt**, finden Sie weitere Informationen unter [Wie behebe ich 5xx-Fehler für die REST-API in API Gateway?](https://repost.aws/knowledge-center/api-gateway-5xx-error)
+ **Wenn Elastic Load Balancing einen 500-Fehler zurückgibt**, finden Sie weitere Informationen unter [HTTP 500: Interner Serverfehler](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) im *Benutzerhandbuch für Application Load Balancer*.
Wenn die obige Liste den 500-Fehler nicht behebt, liegt das Problem möglicherweise daran, dass ein CloudFront Point of Presence einen internen Serverfehler zurückgibt. Sie können sich an [Support](https://console.aws.amazon.com/support/home#/) wenden, um Unterstützung zu erhalten.
# HTTP 502-Statuscode (Bad Gateway)
CloudFront gibt einen HTTP 502-Statuscode (Bad Gateway) zurück, wenn das angeforderte Objekt CloudFront nicht bedient werden konnte, weil es keine Verbindung zum Ursprungsserver herstellen konnte.
Wenn Sie Lambda@Edge verwenden, ist das Problem möglicherweise ein Lambda-Validierungsfehler. Wenn Sie einen HTTP 502-Fehler mit dem `NonS3OriginDnsError` Fehlercode erhalten, liegt wahrscheinlich ein DNS-Konfigurationsproblem vor, das CloudFront verhindert, dass eine Verbindung zum Ursprung hergestellt werden kann.
**Topics**
+ [Fehler bei der SSL/TLS-Aushandlung zwischen CloudFront und einem benutzerdefinierten Ursprungsserver](#ssl-negotitation-failure)
+ [Ursprungsserver ist über die unterstützten Verschlüsselungsverfahren/Protokolle nicht erreichbar](#origin-not-responding-with-supported-ciphers-protocols)
+ [SSL-/TLS-Zertifikat auf dem Ursprungsserver ist abgelaufen, ungültig oder selbstsigniert oder die Zertifikatkette weist die falsche Reihenfolge auf](#ssl-certificate-expired)
+ [Ursprungsserver ist über die eingestellten Ports in den Ursprungseinstellungen nicht erreichbar](#origin-not-responding-on-specified-ports)
+ [Lambda-Validierungsfehler](#http-502-lambda-validation-error)
+ [CloudFront Fehler bei der Funktionsvalidierung](#http-502-cloudfront-function-validation-error)
+ [DNS-Fehler (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [502-Fehler des als Ursprung verwendeten Application Load Balancer](#cloudfront-alb-502-error)
+ [API Gateway Ursprung 502-Fehler](#cloudfront-api-gateway-502-error)
## Fehler bei der SSL/TLS-Aushandlung zwischen CloudFront und einem benutzerdefinierten Ursprungsserver
Wenn Sie einen benutzerdefinierten Ursprung verwenden, der HTTPS zwischen CloudFront und Ihrem Ursprung erfordert, können nicht übereinstimmende Domainnamen zu Fehlern führen. Das SSL/TLS Zertifikat für Ihren Ursprung *muss* einen Domainnamen enthalten, der entweder mit der **Ursprungsdomain**, die Sie für den CloudFront Vertrieb angegeben haben, oder mit dem `Host` Header der Ursprungsanfrage übereinstimmt.
Wenn die Domainnamen nicht übereinstimmen, schlägt der SSL/TLS Handshake fehl und es wird der HTTP-Statuscode 502 (Bad Gateway) CloudFront zurückgegeben und der `X-Cache` Header auf `Error from cloudfront` gesetzt.
Sie können bestimmen, ob die Domainnamen im Zertifikat der **Ursprungsdomain** in der Distribution oder dem `Host`-Header entsprechen, indem Sie eine Online-SSL-Prüfung vornehmen oder OpenSSL verwenden. Wenn die Domain-Namen nicht übereinstimmen, haben Sie zwei Optionen:
+ Besorgen Sie sich ein neues SSL/TLS Zertifikat, das die entsprechenden Domainnamen enthält.
Wenn Sie AWS Certificate Manager (ACM) verwenden, finden Sie im *AWS Certificate Manager Benutzerhandbuch* unter [Anfordern eines öffentlichen Zertifikats](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) Informationen zum Anfordern eines neuen Zertifikats.
+ Ändern Sie die Verteilungskonfiguration, sodass nicht CloudFront mehr versucht wird, SSL für die Verbindung mit Ihrem Ursprung zu verwenden.
### Online-SSL-Prüfung
Sie finden ein Test-Tool für SSL-Verbindungen, indem Sie im Internet nach den Begriffen "online ssl checker" suchen. In der Regel geben Sie den Namen Ihrer Domain an, und das Tool gibt eine Vielzahl von Informationen zu Ihrem SSL/TLS Zertifikat zurück. Vergewissern Sie sich, dass das Zertifikat Ihren Domänennamen aus den Feldern **Allgemeiner Name** oder **Alternative Antragstellernamen** enthält.
### OpenSSL
Um HTTP 502-Fehler von zu beheben CloudFront, können Sie OpenSSL verwenden, um zu versuchen, eine SSL/TLS Verbindung zu Ihrem Ursprungsserver herzustellen. Wenn OpenSSL keine Verbindung herstellen kann, kann dies auf ein Problem mit der SSL/TLS-Konfiguration Ihres Ursprungsservers hinweisen. Wenn OpenSSL eine Verbindung herstellen kann, gibt es Informationen über das Zertifikat des Ursprungsservers zurück, einschließlich des allgemeinen Namens (Feld `Subject CN`) des Zertifikats und des alternativen Antragstellernamens (Feld `Subject Alternative Name`).
Verwenden Sie den folgenden OpenSSL-Befehl, um die Verbindung zu Ihrem Ursprungsserver zu testen (*origin domain*ersetzen Sie ihn durch den Domainnamen Ihres Ursprungsservers, z. B. example.com):
`openssl s_client -connect origin domain name:443`
Wenn Folgendes zutrifft:
+ Ihr Ursprungsserver unterstützt mehrere Domänennamen mit mehreren SSL/TLS-Zertifikaten.
+ Ihre Distribution ist so konfiguriert, dass der `Host`-Header an den Ursprung weitergeleitet wird.
Fügen Sie dann die `-servername` Option wie im folgenden Beispiel zum OpenSSL-Befehl hinzu (*CNAME*ersetzen Sie sie durch den CNAME, der in Ihrer Distribution konfiguriert ist):
`openssl s_client -connect origin domain name:443 -servername CNAME`
## Ursprungsserver ist über die unterstützten Verschlüsselungsverfahren/Protokolle nicht erreichbar
CloudFront stellt mithilfe von Chiffren und Protokollen eine Verbindung zu Originalservern her. Eine Liste der Verschlüsselungen und Protokolle, die unterstützt werden, CloudFront finden Sie unter. [Unterstützte Protokolle und Chiffren zwischen und dem Ursprung CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md) Wenn Ihr Absender nicht mit einer dieser Chiffren oder Protokolle im SSL/TLS-Austausch antwortet, schlägt die Verbindung fehl. CloudFront Sie können überprüfen, ob Ihr Ursprungsserver diese Verschlüsselungsverfahren und Protokolle unterstützt, indem Sie ein Online-Tool wie [SSL-Labs](https://www.ssllabs.com/ssltest) verwenden. Geben Sie den Domain-Namen Ihres Ursprungs-Servers in das Feld **Hostname** ein und wählen Sie anschließend **OK** aus. Überprüfen Sie die Felder **Common names** (Allgemeine Namen) und **Alternative names** (Alternative Namen) in dem Test; entspricht ihr Inhalt dem Domain-Namen Ihres Ursprungs-Servers? Nachdem der Test beendet ist, suchen Sie die Abschnitte **Protocols** und **Cipher Suites** in den Testergebnissen; welche Verschlüsselungsverfahren oder Protokolle werden von Ihrem Ursprungs-Server unterstützt? Vergleichen Sie die Produkte mit der Liste von [Unterstützte Protokolle und Chiffren zwischen und dem Ursprung CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## SSL-/TLS-Zertifikat auf dem Ursprungsserver ist abgelaufen, ungültig oder selbstsigniert oder die Zertifikatkette weist die falsche Reihenfolge auf
Wenn der Ursprungsserver Folgendes zurückgibt, CloudFront bricht er die TCP-Verbindung ab, gibt den HTTP-Statuscode 502 (Bad Gateway) zurück und setzt den Header auf: `X-Cache` `Error from cloudfront`
+ Abgelaufenes Zertifikat
+ Ungültiges Zertifikat
+ Selbstsigniertes Zertifikat
+ Zertifikatkette in der falschen Reihenfolge
**Anmerkung**
Wenn die gesamte Zertifikatskette, einschließlich des Zwischenzertifikats, nicht vorhanden ist, wird CloudFront die TCP-Verbindung unterbrochen.
Hinweise zur Installation eines SSL/TLS Zertifikats auf Ihrem benutzerdefinierten Ursprungsserver finden Sie unter[Erfordern Sie HTTPS für die Kommunikation zwischen CloudFront und Ihrem benutzerdefinierten Ursprung](using-https-cloudfront-to-custom-origin.md).
## Ursprungsserver ist über die eingestellten Ports in den Ursprungseinstellungen nicht erreichbar
Wenn Sie in Ihrer CloudFront Distribution einen Ursprung erstellen, können Sie die Ports festlegen, über die eine CloudFront Verbindung zum Ursprung für HTTP- und HTTPS-Verkehr hergestellt wird. Standardmäßig sind das die TCP-Ports 80 und 443. Sie haben die Möglichkeit, diese Ports zu ändern. Wenn Ihr Absender den Datenverkehr auf diesen Ports aus irgendeinem Grund ablehnt oder wenn Ihr Backend-Server nicht auf die Ports reagiert, kann keine Verbindung CloudFront hergestellt werden.
Sie können diese Probleme zu beheben, indem Sie alle Firewalls überprüfen, die in Ihrer Infrastruktur ausgeführt werden, und sich vergewissern, dass sie die unterstützten IP-Bereiche nicht blockieren. Weitere Informationen finden Sie unter [AWS -IP-Adressbereiche](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) im *Benutzerhandbuch für Amazon VPC*. Überprüfen Sie außerdem, ob Ihr Webserver auf dem Ursprungsserver ausgeführt wird.
## Lambda-Validierungsfehler
Wenn Sie Lambda@Edge verwenden, kann der HTTP-Statuscode 502 anzeigen, dass Ihre Lambda-Funktionsantwort falsch gebildet wurde oder ungültigen Inhalt enthielt. Weitere Informationen zur Behebung von Lambda@Edge-Fehlern finden Sie unter [Testen und Debuggen von Lambda@Edge-Funktionen](lambda-edge-testing-debugging.md).
## CloudFront Fehler bei der Funktionsvalidierung
Wenn Sie CloudFront Funktionen verwenden, kann ein HTTP-502-Statuscode darauf hinweisen, dass die CloudFront Funktion versucht, einen schreibgeschützten Header hinzuzufügen, zu löschen oder zu ändern. Dieser Fehler tritt beim Testen nicht auf, sondern erst, nachdem Sie die Funktion bereitgestellt und die Anforderung ausgeführt haben. Um diesen Fehler zu beheben, überprüfen und aktualisieren Sie Ihre CloudFront Funktion. Weitere Informationen finden Sie unter [Aktualisieren von Funktionen](update-function.md).
## DNS-Fehler (`NonS3OriginDnsError`)
Ein HTTP 502-Fehler mit dem `NonS3OriginDnsError` Fehlercode weist auf ein DNS-Konfigurationsproblem hin, das CloudFront verhindert, dass eine Verbindung zum Ursprung hergestellt werden kann. Wenn Sie diesen Fehler von erhalten CloudFront, stellen Sie sicher, dass die DNS-Konfiguration des Ursprungs korrekt ist und funktioniert.
Wenn es eine Anfrage für ein Objekt CloudFront erhält, das abgelaufen ist oder sich nicht in seinem Cache befindet, sendet es eine Anfrage an den Ursprung, um das Objekt abzurufen. Um eine erfolgreiche Anfrage an den Ursprung zu stellen, CloudFront führt eine DNS-Auflösung in der Ursprungsdomäne durch. Wenn beim DNS-Dienst für Ihre Domain Probleme auftreten, CloudFront kann der Domainname nicht aufgelöst werden, um die IP-Adresse abzurufen, was zu einem HTTP 502-Fehler (`NonS3OriginDnsError`) führt. Sie können dieses Problem beheben, indem Sie sich an Ihren DNS-Anbieter wenden. Wenn Sie Amazon Route 53 verwenden, finden Sie weitere Informationen unter [Warum kann ich nicht auf meine Website zugreifen, die Route-53-DNS-Services verwendet?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)
Sie können dieses Problem weiterhin beheben, indem Sie sicherstellen, dass die [autoritativen Name-Server](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) für die Stamm-Domäne bzw. den Zone Apex (z. B. `example.com`) Ihres Ursprungs-Servers richtig funktionieren. Sie können die folgenden Befehle verwenden, um die Nameserver für Ihren Ursprungsserver-Apex zu finden, zum Beispiel mit einem Tool wie [dig](https://en.wikipedia.org/wiki/Dig_(command)) oder [nslookup](https://en.wikipedia.org/wiki/Nslookup):
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
Wenn Sie die Namen Ihrer Name-Server erhalten haben, verwenden Sie die folgenden Befehle, um den Domain-Namen Ihres Ursprungsservers von ihnen abzufragen; so können Sie sicherstellen, dass alle eine Antwort zurückgeben:
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**Wichtig**
Stellen Sie sicher, dass Sie diese DNS-Fehlerbehebung auf einem Computer durchführen, der mit dem öffentlichen Internet verbunden ist. CloudFront löst die Ursprungsdomäne mithilfe von öffentlichem DNS im Internet auf. Daher ist es wichtig, die Fehlerbehebung in einem ähnlichen Kontext durchzuführen.
Wenn der Ursprung eine Subdomäne ist, deren DNS-Berechtigung an einen anderen Nameserver als die Stammdomäne delegiert ist, stellen Sie sicher, dass die Datensätze für den Nameserver (`NS`) und Autoritätsursprung (`SOA`) für die Subdomäne korrekt konfiguriert sind. Sie können mit Befehlen, die den vorherigen Beispielen ähneln, nach diesen Datensätzen suchen.
Weitere Informationen zu DNS finden Sie unter [DNS-Konzepte (Domain Name System)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns) in der Dokumentation zu Amazon Route 53.
## 502-Fehler des als Ursprung verwendeten Application Load Balancer
Wenn Sie Application Load Balancer als Ursprung verwenden und einen 502-Fehler erhalten, finden Sie weitere Informationen unter [Wie behebe ich den HTTP-Fehler 502 des Application Load Balancer?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors)
## API Gateway Ursprung 502-Fehler
Wenn Sie API Gateway verwenden und einen 502-Fehler erhalten, finden Sie weitere Informationen unter [Wie behebe ich HTTP 502-Fehler von API Gateway REST APIs mit Lambda-Proxyintegration](https://repost.aws/knowledge-center/malformed-502-api-gateway)? .
# HTTP 503-Statuscode (Service nicht verfügbar)
Ein HTTP-Statuscode 503 (Service nicht verfügbar) zeigt in der Regel an, dass es auf dem Ursprungsserver ein Leistungsproblem gibt. In seltenen Fällen weist dies darauf hin, dass eine Anfrage aufgrund von Ressourcenbeschränkungen an einem Edge-Standort CloudFront vorübergehend nicht bearbeitet werden kann.
Wenn Sie Lambda @Edge oder CloudFront Functions verwenden, ist das Problem möglicherweise ein Ausführungsfehler oder ein Fehler, dass das Lambda @Edge -Limit überschritten wurde.
**Topics**
+ [Ursprungsserver verfügt nicht über ausreichend Kapazitäten für die vorliegende Anfragerate](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront hat den Fehler aufgrund von Ressourcenbeschränkungen am Edge-Standort verursacht](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda @Edge oder Fehler bei der Ausführung der CloudFront Funktion](#http-503-lambda-execution-error)
+ [Lambda@Edge-Grenzwert überschritten](#http-503-lambda-limit-exceeded-error)
## Ursprungsserver verfügt nicht über ausreichend Kapazitäten für die vorliegende Anfragerate
Wenn ein Ursprungsserver nicht verfügbar ist oder eingehende Anfragen nicht bearbeiten kann, gibt er den HTTP-Statuscode 503 (Service Unavailable) zurück. CloudFront leitet den Fehler dann an den Benutzer zurück. Sie lösen dieses Problem, indem Sie die folgenden Schritte ausführen:
+ **Wenn Sie Amazon S3 als Ihren Ursprungsserver verwenden**:
+ Sie können 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD Anfragen pro Sekunde pro partitioniertem Amazon S3 S3-Präfix senden. Wenn Amazon S3 die Antwort 503 „Slow Down“ zurückgibt, deutet dies in der Regel auf eine zu hohe Anforderungsrate für ein bestimmtes Amazon-S3-Präfix hin.
Da die Anforderungsraten pro Präfix in einem S3-Bucket gelten, sollten Objekte auf mehrere Präfixe verteilt werden. Mit steigender Anforderungsrate für die Präfixe skaliert Amazon S3 hoch, um Anforderungen für jedes der Präfixe separat zu bearbeiten. Infolgedessen ist die Gesamtanforderungsrate, die der Bucket verarbeitet, ein Vielfaches der Anzahl der Präfixe.
+ Weitere Informationen zu Amazon-S3-Berechtigungen finden Sie unter [Optimieren der Amazon-S3-Leistung](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
+ **Wenn Sie Elastic Load Balancing als Ursprungsserver verwenden**:
+ Stellen Sie sicher, dass Ihre Backend-Instances auf Zustandsprüfungen reagieren können.
+ Stellen Sie sicher, dass Ihr Load Balancer und Ihre Backend-Instances die Last bewältigen können.
Weitere Informationen finden Sie unter:
+ [Wie behebe ich 503-Fehler, die bei der Verwendung von Classic Load Balancer zurückgegeben werden?](https://repost.aws/knowledge-center/503-error-classic)
+ [Wie behebe ich 503-Fehler (Service nicht verfügbar) von meinem Application Load Balancer?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Wenn Sie einen benutzerdefinierten Ursprung verwenden**:
+ Prüfen Sie die Anwendungsprotokolle, um sicherzustellen, dass Ihr Ursprung über ausreichend Ressourcen verfügt, wie z. B. Arbeitsspeicher, CPU und Festplattengröße.
+ Wenn Sie Amazon EC2 als Backend verwenden, stellen Sie sicher, dass der Instance-Typ über die entsprechenden Ressourcen verfügt, um die eingehenden Anfragen zu bearbeiten. Weitere Informationen finden Sie unter [Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) im * EC2 Amazon-Benutzerhandbuch*.
+ **Wenn Sie API Gateway verwenden**:
+ Dieser Fehler steht im Zusammenhang mit der Backend-Integration, wenn die API in Gateway API keine Antwort empfangen kann. Der Backend-Server ist möglicherweise:
+ über die Kapazität hinaus überlastet und kann keine neuen Client-Anforderungen verarbeiten;
+ gerade im Wartungszustand.
+ Um diesen Fehler zu beheben, schauen Sie sich die Protokolle Ihrer API-Gateway-Anwendung an, um festzustellen, ob ein Problem mit der Backend-Kapazität, der Integration oder etwas anderem vorliegt.
## CloudFront hat den Fehler aufgrund von Ressourcenbeschränkungen am Edge-Standort verursacht
Dieser Fehler tritt in dem seltenen Fall auf, dass CloudFront Anfragen nicht an den nächstbesten verfügbaren Edge-Standort weitergeleitet werden können und somit eine Anfrage nicht erfüllt werden kann. Dieser Fehler tritt häufig auf, wenn Sie in Ihrer CloudFront-Verteilung Belastungstests durchführen. Um dies zu vermeiden, befolgen Sie die [Belastungstests CloudFront](load-testing.md)-Richtlinien zum Vermeiden des Fehlers 503 (Kapazität überschritten).
Wenn dieser Fehler in Ihrer Produktionsumgebung auftritt, wenden Sie sich an [Support](https://console.aws.amazon.com/support/home#/).
## Lambda @Edge oder Fehler bei der Ausführung der CloudFront Funktion
Wenn Sie Lambda @Edge oder CloudFront Functions verwenden, kann ein HTTP-Statuscode 503 darauf hinweisen, dass Ihre Funktion einen Ausführungsfehler zurückgegeben hat.
Weitere Informationen zur Identifizierung und Behebung von Lambda@Edge-Fehlern finden Sie unter [Testen und Debuggen von Lambda@Edge-Funktionen](lambda-edge-testing-debugging.md).
Weitere Hinweise zum Testen von CloudFront Funktionen finden Sie unter[Testfunktionen](test-function.md).
## Lambda@Edge-Grenzwert überschritten
Wenn Sie Lambda@Edge verwenden, kann der HTTP-Statuscode 503 anzeigen, dass Lambda einen Fehler zurückgegeben hat. Der Fehler kann durch eine der folgenden Ursachen bedingt sein.
+ Die Anzahl der Funktionsausführungen hat eines der Quoten überschritten, die Lambda festlegt, um Ausführungen in einem zu drosseln AWS-Region (gleichzeitige Ausführungen oder Aufrufthäufigkeit).
+ Die Funktion hat das Timeout-Kontingent für die Lambda-Funktion überschritten.
Weitere Informationen zu den Lambda@Edge-Kontingenten finden Sie unter [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). Weitere Informationen zur Identifizierung und Behebung von Lambda@Edge-Fehlern finden Sie unter [Testen und Debuggen von Lambda@Edge-Funktionen](lambda-edge-testing-debugging.md). Die [Lambda-Servicekontingente](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) finden Sie auch im *Entwicklungshandbuch für AWS Lambda *.
# HTTP 504-Statuscode (Gateway Timeout)
Ein HTTP 504-Statuscode (Gateway-Timeout) gibt an, dass bei der CloudFront Weiterleitung einer Anfrage an den Ursprung (weil sich das angeforderte Objekt nicht im Edge-Cache befand) einer der folgenden Fälle eingetreten ist:
+ Der Ursprung hat einen HTTP 504-Statuscode an CloudFront zurückgegeben.
+ Der Ursprung reagierte nicht, bevor die Anforderung ablief.
CloudFront gibt einen HTTP 504-Statuscode zurück, wenn der Datenverkehr zum Ursprung durch eine Firewall oder Sicherheitsgruppe blockiert wird oder wenn der Ursprung im Internet nicht zugänglich ist. Überprüfen Sie diese Punkte zuerst. Wenn der Zugriff nicht das Problem ist, sehen Sie sich Anwendungsverzögerungen und Server-Timeouts an, um die Probleme zu ermitteln und zu beheben.
**Topics**
+ [Konfigurieren Sie die Firewall auf Ihrem Ursprungsserver so, dass CloudFront Datenverkehr zugelassen wird](#http-504-gateway-timeout-configure-firewall)
+ [Konfigurieren Sie die Sicherheitsgruppen auf Ihrem Ursprungsserver, um Datenverkehr zuzulassen CloudFront](#http-504-gateway-timeout-configure-security-groups)
+ [Erlauben des Zugriffs auf Ihren benutzerdefinierten Ursprungsserver über das Internet](#http-504-gateway-timeout-make-origin-accessible)
+ [Suchen und Beheben verzögerter Antworten von Anwendungen auf Ihrem Ursprungsserver](#http-504-gateway-timeout-slow-application)
## Konfigurieren Sie die Firewall auf Ihrem Ursprungsserver so, dass CloudFront Datenverkehr zugelassen wird
Wenn die Firewall auf Ihrem Ursprungsserver den CloudFront Datenverkehr blockiert, wird ein HTTP-504-Statuscode CloudFront zurückgegeben. Stellen Sie daher sicher, dass dies nicht das Problem ist, bevor Sie nach anderen Problemen suchen.
Die Methode, die Sie nutzen, um zu bestimmen, ob es sich um ein Problem mit Ihrer Firewall handelt, hängt davon ab, welches System Ihr Ursprungs-Server verwendet:
+ Wenn Sie eine IPTable Firewall auf einem Linux-Server verwenden, können Sie nach Tools und Informationen suchen, die Ihnen bei der Arbeit helfen IPTables.
+ Wenn Sie die Windows-Firewall auf einem Windows-Server verwenden, finden Sie weitere Informationen unter [Hinzufügen oder Bearbeiten einer Firewallregel](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) in der Microsoft-Dokumentation.
Wenn Sie die Firewall-Konfiguration auf Ihrem Ursprungsserver auswerten, sollten Sie auf der Grundlage des veröffentlichten IP-Adressbereichs nach Firewalls oder Sicherheitsregeln Ausschau halten, die den Datenverkehr von CloudFront Edge-Standorten blockieren. Weitere Informationen finden Sie unter [Standorte und IP-Adressbereiche von CloudFront-Edge-Servern](LocationsOfEdgeServers.md).
Wenn der CloudFront IP-Adressbereich eine Verbindung zu Ihrem Ursprungsserver herstellen darf, stellen Sie sicher, dass Sie die Sicherheitsregeln Ihres Servers aktualisieren, um die Änderungen zu berücksichtigen. Sie können ein Amazon-SNS-Thema abonnieren und Benachrichtigungen erhalten, wenn die IP-Adressbereichsdatei aktualisiert wird. Nachdem Sie die Benachrichtigung erhalten haben, können Sie Code verwenden, um die Datei abzurufen, sie zu analysieren und ggf. Anpassungen Ihrer lokalen Umgebung vorzunehmen. Weitere Informationen finden [Sie im AWS News-Blog unter AWS Öffentliche IP-Adressänderungen über Amazon SNS abonnieren](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).
## Konfigurieren Sie die Sicherheitsgruppen auf Ihrem Ursprungsserver, um Datenverkehr zuzulassen CloudFront
Wenn Ihr Origin Elastic Load Balancing verwendet, überprüfen Sie die [ELB-Sicherheitsgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) und stellen Sie sicher, dass die Sicherheitsgruppen eingehenden CloudFront Datenverkehr zulassen.
Sie können es auch verwenden AWS Lambda , um Ihre Sicherheitsgruppen automatisch zu aktualisieren, um eingehenden Datenverkehr von zuzulassen. CloudFront
## Erlauben des Zugriffs auf Ihren benutzerdefinierten Ursprungsserver über das Internet
Wenn Sie nicht auf Ihren benutzerdefinierten Ursprungsserver zugreifen CloudFront können, weil er nicht öffentlich im Internet verfügbar ist, wird ein HTTP 504-Fehler CloudFront zurückgegeben.
CloudFront Edge-Standorte stellen über das Internet eine Verbindung zu den Ursprungsservern her. Wenn sich Ihr benutzerdefinierter Ursprung in einem privaten Netzwerk befindet, CloudFront kann er nicht erreicht werden. Aus diesem Grund können Sie private Server, einschließlich [interner Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), nicht als Ursprungsserver mit CloudFront verwenden.
Um zu überprüfen, ob der Internetverkehr eine Verbindung zu Ihrem Ursprungsserver herstellen kann, führen Sie die folgenden Befehle aus (wo *OriginDomainName* ist der Domainname für Ihren Server):
Für HTTPS-Datenverkehr:
+ nc -zv 443 *OriginDomainName*
+ Telnet 443 *OriginDomainName*
Für HTTP-Datenverkehr:
+ NC-ZV 80 *OriginDomainName*
+ Telnet 80 *OriginDomainName*
## Suchen und Beheben verzögerter Antworten von Anwendungen auf Ihrem Ursprungsserver
Server-Timeouts sind häufig das Ergebnis einer Anwendung, die recht lange braucht, um zu reagieren, oder eines Timeout-Werts, der zu niedrig eingestellt ist.
Eine schnelle Abhilfe zum Vermeiden des HTTP-Fehlers 504 besteht darin, einen höheren CloudFront-Timeout-Wert für Ihre Verteilung festzulegen. Wir empfehlen jedoch, dass Sie zunächst sicherstellen, dass Sie alle Leistungs- und Latenzprobleme mit der Anwendung und dem Ursprungs-Server beheben. Anschließend können Sie einen angemessenen Timeout-Wert festlegen, der zur Vermeidung des HTTP-Fehlers 504 beiträgt und eine gute Reaktionsfähigkeit für Benutzer bietet.
Im Folgenden finden Sie eine Übersicht über die Schritte, die Sie ausführen können, um Leistungsprobleme zu ermitteln und zu beheben:
1. Messen Sie die normale Latenz und die Latenz bei hoher Last (Reaktionsfähigkeit) Ihrer Webanwendung.
1. Fügen Sie weitere Ressourcen, z. B. CPU oder Speicher (bei Bedarf) hinzu. Führen Sie andere Schritte aus, um die Probleme zu beheben, z. B. Optimierung von Datenbankabfragen für Szenarien mit hoher Last.
1. Passen Sie bei Bedarf den Timeout-Wert für Ihre CloudFront Distribution an.
Im Folgenden finden Sie Details zu jedem einzelnen Schritt.
### Messen der normalen Latenz und der Latenz bei hoher Last
Um festzustellen, ob auf einem oder mehreren Backend-Webanwendungsservern eine hohe Latenz vorliegt, führen Sie den folgenden Linux curl-Befehl auf jedem Server aus:
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**Anmerkung**
Wenn Sie Windows auf Ihren Servern ausführen, können Sie curl für Windows suchen und herunterladen, um einen entsprechenden Befehl auszuführen.
Beachten Sie beim Messen und Auswerten der Latenz einer Anwendung, die auf Ihrem Server ausgeführt wird, folgende Punkte:
+ Latenzwerte sind für jede Anwendung relativ. Allerdings ist eine Zeit bis zum ersten Byte in Millisekunden statt Sekunden oder mehr sinnvoll.
+ Wenn Sie die Anwendungslatenz unter normalen Lastbedingungen messen und das Ergebnis in Ordnung ist, sollten Sie daran denken, dass bei Viewern dennoch Timeouts bei hoher Last auftreten können. Wenn eine hohe Nachfrage besteht, können Server Antworten verzögert senden oder gar nicht reagieren. Überprüfen Sie zur Vermeidung von Latenzproblemen bei hoher Last Ihre Serverressourcen wie CPU, Arbeitsspeicher sowie Lese- und Schreibvorgänge auf Speichermedien, um sicherzustellen, dass Ihre Server über die Kapazitäten zur Skalierung für hohe Auslastung verfügen.
Sie können den folgenden Linux-Befehl zum Überprüfen des Speichers ausführen, der von Apache-Prozessen verwendet wird:
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ Eine hohe CPU-Auslastung auf dem Server kann die Leistung einer Anwendung erheblich reduzieren. Wenn Sie eine EC2 Amazon-Instance für Ihren Backend-Server verwenden, überprüfen Sie die CloudWatch Metriken für den Server, um die CPU-Auslastung zu überprüfen. Weitere Informationen finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). Wenn Sie Ihre eigenen Server verwenden, finden Sie in der Hilfedokumentation des Servers Anleitungen zum Prüfen der CPU-Auslastung.
+ Überprüfen Sie, ob andere potenzielle Probleme unter hoher Last vorliegen, wie beispielsweise Datenbankabfragen, die bei einem hohen Volume von Anfragen langsam ausgeführt werden.
### Hinzufügen von Ressourcen und Optimieren von Servern und Datenbanken
Nachdem Sie die Reaktionsfähigkeit Ihrer Anwendungen und Server bewertet haben, stellen Sie sicher, dass Sie über ausreichend Ressourcen für normalen Datenverkehr und Situationen mit hoher Auslastung verfügen:
+ Wenn Sie einen eigenen Server nutzen, stellen Sie basierend auf Ihrer Bewertung sicher, dass dieser über ausreichend CPU, Arbeitsspeicher und Festplattenspeicher für die Verarbeitung von Viewer-Anfragen verfügt.
+ Wenn Sie eine EC2 Amazon-Instance als Backend-Server verwenden, stellen Sie sicher, dass der Instance-Typ über die entsprechenden Ressourcen verfügt, um eingehende Anfragen zu bearbeiten. Weitere Informationen finden Sie unter [Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) im * EC2 Amazon-Benutzerhandbuch*.
Außerdem sollten Sie ggf. die folgenden Optimierungsschritte ausführen, um Timeouts zu vermeiden:
+ Wenn der Wert für die Zeit bis zum ersten Byte, der vom curl-Befehl zurückgegeben wird, hoch erscheint, ergreifen Sie Maßnahmen zur Verbesserung der Leistung Ihrer Anwendung. Durch Verbessern der Anwendungsreaktionsfähigkeit lassen sich wiederum Timeout-Fehler reduzieren.
+ Optimieren Sie Datenbankabfragen, um sicherzustellen, dass sie hohe Abfragezahlen verarbeiten können, ohne dass die Leistung beeinträchtigt wird.
+ Richten Sie (persistente) [ Keepalive](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01)-Verbindungen auf Ihrem Backend-Server ein. Mit dieser Option lassen sich Latenzen vermeiden, die auftreten, wenn Verbindungen für nachfolgende Anfragen oder Benutzer erneut hergestellt werden müssen.
+ **Wenn Sie Elastic Load Balancing als Ursprung verwenden**, hat der 504-Fehler möglicherweise folgende Ursachen:
+ Der Load Balancer kann vor Ablauf des Verbindungstimeouts (10 Sekunden) keine Verbindung zum Ziel herstellen.
+ Der Load Balancer stellt eine Verbindung zum Ziel her, aber das Ziel reagiert nicht vor Ablauf des Verbindungstimeouts.
+ Die Netzwerk-Zugriffssteuerungsliste (ACL) für das Subnetz lässt an den flüchtigen Ports (1024-65535) keinen Datenverkehr von den Zielen zu den Load-Balancer-Knoten zu.
+ Das Ziel gibt einen Inhaltslängen-Header zurück, der größer ist als der Entitätskörper. Beim Warten auf die fehlenden Byte wird das Zeitlimit des Load Balancer überschritten.
+ Das Ziel ist eine Lambda-Funktion und Lambda reagiert vor Ablauf des Verbindungstimeouts nicht.
Weitere Informationen zur Reduzierung der Latenz finden Sie unter [Wie behebe ich Probleme mit hoher Latenz auf meinem ELB Classic Load Balancer](https://repost.aws/knowledge-center/elb-latency-troubleshooting)?
+ **Wenn Sie MediaTailor als Ihren Ursprung verwenden**, sind die folgenden möglichen Ursachen für einen 504-Fehler:
+ Wenn Verwandte falsch behandelt URLs werden, MediaTailor kann es zu Fehlbildungen URLs von Spielern kommen.
+ Wenn dies der offensichtliche Ursprung für MediaPackage ist MediaTailor, können offensichtliche MediaPackage 404-Fehler MediaTailor dazu führen, dass ein 504-Fehler zurückgegeben wird.
+ Es dauert mehr als 2 Sekunden, bis die Anfrage an den MediaTailor Ursprungsserver abgeschlossen ist.
+ **Wenn Sie Amazon API Gateway als Ursprung verwenden**, hat der 504-Fehler möglicherweise folgende Ursachen:
+ Eine Integrationsanforderung dauert länger als der maximale Integrationstimeout-Parameter Ihrer REST-API von API Gateway. Weitere Informationen finden Sie unter [Wie kann ich den HTTP-Fehler 504 zum API-Gateway-Timeout beheben?](https://repost.aws/knowledge-center/api-gateway-504-errors)
### Passen Sie bei Bedarf den CloudFront Timeout-Wert an
Wenn Sie eine langsame Anwendungsleistung, Ursprungs-Serverkapazität und weitere Probleme festgestellt und behoben haben, die Viewer aber weiterhin den HTTP-Fehler 504 erhalten, sollten Sie in Betracht ziehen, die Zeit, die in Ihrer Distribution als Ursprungs-Reaktions-Timeout angegeben ist, zu ändern. Weitere Informationen finden Sie unter [Antwort-Timeout](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).