Fehlerbehebung bei Ihren Application Load Balancern - Elastic Load Balancing
Ein registriertes Ziel ist nicht in BetriebClients können keine Verbindung zu einem mit dem Internet verbundenen Load Balancer herstellenAnfragen, die an eine benutzerdefinierte Domain gesendet werden, werden vom Load Balancer nicht empfangenAn den Load Balancer gesendete HTTPS-Anfragen geben „NET::ERR_CERT_COMMON_NAME_INVALID“ zurückDer Load Balancer zeigt erhöhte Verarbeitungszeiten anDer Load Balancer sendet als Antwortcode „000“.Der Load Balancer generiert einen HTTP-FehlerEin Ziel generiert einen HTTP-FehlerEin AWS Certificate Manager Zertifikat kann nicht verwendet werdenHeader mit mehreren Zeilen werden nicht unterstütztBeheben Sie fehlerhafte Ziele mithilfe der Ressourcenübersicht

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.

Fehlerbehebung bei Ihren Application Load Balancern

Die folgenden Informationen können Ihnen helfen, Probleme bei Ihren Application Load Balancer zu beheben.

Ein registriertes Ziel ist nicht in Betrieb

Wenn es länger als erwartet dauert, bis ein Ziel den Zustand InService aufweist, besteht es möglicherweise Zustandsprüfungen nicht. Ihr Ziel ist erst betriebsbereit, wenn es eine Zustandsprüfung besteht. Weitere Informationen finden Sie unter Gesundheitschecks für Application Load Balancer Balancer-Zielgruppen.

Überprüfen Sie, ob Ihre Instance Zustandsprüfungen nicht besteht und prüfen Sie dann Folgendes:

Eine Sicherheitsgruppe erlaubt keinen Datenverkehr

Die mit einer Instance verbundene Sicherheitsgruppe muss mithilfe des Zustandsprüfungs-Ports und Zustandsprüfungs-Protokolls Datenverkehr vom Load Balancer zulassen. Sie können eine Regel zur Sicherheitsgruppe der Instance hinzufügen, um den gesamten Datenverkehr von der Load Balancer-Sicherheitsgruppe zuzulassen. Außerdem muss die Sicherheitsgruppe für Ihren Load Balancer Datenverkehr zu den Instances zulassen.

Eine Netzwerk-Zugriffskontrollliste (ACL) erlaubt keinen Datenverkehr

Die mit den Subnetzen verbundene Netzwerk-ACL für Ihre Instances muss eingehenden Datenverkehr am Zustandsprüfungs-Port und ausgehenden Datenverkehr an den flüchtigen Ports (1024-65535) zuzulassen. Die mit den Subnetzen verbundene Netzwerk-ACL für Ihre Load Balancer-Knoten muss eingehenden Datenverkehr an den flüchtigen Ports und ausgehenden Datenverkehr am Zustandsprüfungs-Port und an den flüchtigen Ports zulassen.

Der Ping-Pfad ist nicht vorhanden

Erstellen Sie eine Zielseite für die Zustandsprüfung und geben Sie den Pfad als den Ping-Pfad an.

Die Verbindung läuft ab

Vergewissern Sie sich zunächst, dass Sie mithilfe der privaten IP-Adresse des Ziels und des Zustandsprüfungs-Protokolls im Netzwerk eine direkt Verbindung zum Ziel herstellen können. Wenn Sie keine Verbindung herstellen können, prüfen Sie, ob die Instance überlastet ist, und fügen Sie weitere Ziele zu Ihrer Zielgruppe hinzu, wenn sie zu stark ausgelastet ist, um zu reagieren. Wenn Sie eine Verbindung herstellen können, ist es möglich, dass die Zielseite vor Ablauf des Zeitüberschreitungszeitraums der Zustandsprüfung nicht reagiert. Wählen Sie eine einfachere Zielseite für die Zustandsprüfung aus oder passen Sie die Zustandsprüfungseinstellungen an.

Das Ziel hat keinen Erfolgsmeldungscode zurückgegeben

Der Erfolgscode lautet standardmäßig 200. Sie können jedoch optional zusätzliche Erfolgscodes angeben, wenn Sie Zustandsprüfungen konfigurieren. Überprüfen Sie die Erfolgscodes, die der Load Balancer erwartet, und stellen Sie sicher, dass Ihre Anwendung so konfiguriert ist, dass sie diese Codes bei Erfolg zurückgibt.

Der Antwortcode des Ziels war fehlerhaft oder bei der Verbindung zum Ziel ist ein Fehler aufgetreten

Überprüfen Sie, ob Ihre Anwendung auf die Zustandsprüfungsanfragen des Load Balancers antwortet. Einige Anwendungen benötigen zusätzliche Konfigurationen, um auf Zustandsprüfungen zu reagieren, z. B. eine Konfiguration des virtuellen Hosts, um auf den vom Load Balancer gesendeten HTTP-Host-Header zu reagieren. Der Host-Header-Wert enthält die private IP-Adresse des Ziels, gefolgt vom Health Check-Port, wenn kein Standardport verwendet wird. Wenn das Ziel einen standardmäßigen Port für die Integritätsprüfung verwendet, enthält der Host-Header-Wert nur die private IP-Adresse des Ziels. Wenn die private IP-Adresse Ihres Ziels beispielsweise lautet 10.0.0.10 und der Port für die Zustandsprüfung lautet, lautet der HTTP-Host-Header8080, der vom Load Balancer bei Integritätsprüfungen gesendet wirdHost: 10.0.0.10:8080. Wenn die private IP-Adresse Ihres Ziels lautet 10.0.0.10 und der Port für die Zustandsprüfung der HTTP-Host-Header ist, ist 80 dies der HTTP-Host-Header, der vom Load Balancer bei Integritätsprüfungen gesendet wird. Host: 10.0.0.10 Möglicherweise ist eine virtuelle Hostkonfiguration, die auf diesen Host reagiert, oder eine Standardkonfiguration erforderlich, um den Zustand Ihrer Anwendung zu überprüfen. Anfragen für Zustandsprüfungen haben die folgenden Attribute: User-Agent ist auf ELB-HealthChecker/2.0 gesetzt, das Zeilenende für die Felder des Nachrichtenkopfes ist die Sequenz CRLF und der Header endet an der ersten leeren Zeile, gefolgt von einem CRLF.

Clients können keine Verbindung zu einem mit dem Internet verbundenen Load Balancer herstellen

Wenn der Load Balancer auf Anfragen nicht reagiert, überprüfen Sie Folgendes:

Ihr mit dem Internet verbundener Load Balancer ist mit einem privaten Subnetz verbunden.

Sie müssen öffentliche Subnetze für Ihren Load Balancer angeben. Ein öffentliches Subnetz verfügt über einen Zugang zum Internet-Gateway für Ihre Virtual Private Cloud (VPC).

Eine Sicherheitsgruppe oder Netzwerk-ACL erlaubt keinen Datenverkehr

Die Sicherheitsgruppe für den Load Balancer und jede Netzwerk-ACL für die Load Balancer-Subnetze muss an den Listener-Ports eingehenden Datenverkehr von den Clients und ausgehenden Datenverkehr zu den Clients erlauben.

Anfragen, die an eine benutzerdefinierte Domain gesendet werden, werden vom Load Balancer nicht empfangen

Wenn der Load Balancer keine Anfragen empfängt, die an eine benutzerdefinierte Domain gesendet werden, überprüfen Sie Folgendes:

Der benutzerdefinierte Domainname kann nicht in die IP-Adresse des Load Balancers aufgelöst werden

  • Bestätigen Sie mithilfe einer Befehlszeilenschnittstelle, auf welche IP-Adresse der benutzerdefinierte Domainname aufgelöst wird.

    • Linux, macOS oder Unix: Sie können den dig-Befehl im Terminal verwenden. Beispiel: dig example.com

    • Windows: Sie können den nslookup-Befehl in der Eingabeaufforderung verwenden. Beispiel: nslookup example.com

  • Bestätigen Sie die IP-Adresse, zu der der DNS-Name des Load Balancers über eine Befehlszeilenschnittstelle aufgelöst wird.

  • Vergleichen Sie die Ergebnisse der beiden Ausgaben. Die IP-Adressen müssen übereinstimmen.

Weitere Informationen zur Verwendung von Route 53 zum Hosten Ihrer benutzerdefinierten Domain finden Sie unter Meine Domain ist im Internet nicht verfügbar im Entwicklerhandbuch zu Amazon Route 53.

An den Load Balancer gesendete HTTPS-Anfragen geben „NET::ERR_CERT_COMMON_NAME_INVALID“ zurück

Wird auf HTTPS-Anfragen vom Load Balancer NET::ERR_CERT_COMMON_NAME_INVALID zurückgegeben, überprüfen Sie die folgenden möglichen Ursachen:

  • Der in der HTTPS-Anfrage verwendete Domainname stimmt nicht mit dem im ACM-Zertifikat des Listeners angegebenen alternativen Namen überein.

  • Der Standard-DNS-Name des Load Balancers wird verwendet. Der Standard-DNS-Name kann nicht für HTTPS-Anfragen verwendet werden, da für die *.amazonaws.com.rproxy.goskope.com-Domain kein öffentliches Zertifikat angefordert werden kann.

Der Load Balancer zeigt erhöhte Verarbeitungszeiten an

Der Load Balancer berechnet die Verarbeitungszeit je nach Konfiguration unterschiedlich.

  • Wenn mit Ihrem Application Load Balancer verknüpft AWS WAF ist und ein Client eine HTTP-POST-Anfrage sendet, wird die Zeit zum Senden der Daten für POST-Anfragen in dem request_processing_time Feld in den Load Balancer-Zugriffsprotokollen wiedergegeben. Dieses Verhalten wird für HTTP-POST-Anfragen erwartet.

  • Wenn AWS WAF es nicht mit Ihrem Application Load Balancer verknüpft ist und ein Client eine HTTP-POST-Anforderung sendet, wird die Zeit zum Senden der Daten für POST-Anfragen in dem target_processing_time Feld in den Load Balancer-Zugriffsprotokollen wiedergegeben. Dieses Verhalten wird für HTTP-POST-Anfragen erwartet.

Der Load Balancer sendet als Antwortcode „000“.

Wenn bei HTTP/2-Verbindungen die komprimierte Länge eines der Header 8 K überschreitet oder wenn mehr als 10 000 Anfragen über eine Verbindung übermittelt werden, sendet der Load Balancer einen GOAWAY-Frame und schließt die Verbindung mit einer TCP-FIN.

Der Load Balancer generiert einen HTTP-Fehler

Die folgenden HTTP-Fehler werden vom Load Balancer generiert. Der Load Balancer sendet den HTTP-Code an den Client, speichert die Anforderung im Zugriffsprotokoll und erhöht die HTTPCode_ELB_4XX_Count- oder HTTPCode_ELB_5XX_Count-Metrik schrittweise.

HTTP 400: Schlechte Anfrage

Mögliche Ursachen:

  • Der Client hat eine falsch formatierte Anforderung gesendet, die die HTTP-Spezifikation nicht erfüllt.

  • Der Anforderungsheader hat 16 K pro Anforderungszeile, 16 K pro einzelnem Header oder 64 K pro gesamtem Anfrage-Header überschritten.

  • Der Client hat die Verbindung beendet, bevor er den vollständigen Anfragetext gesendet hat.

HTTP 401: Unauthorized (Nicht autorisiert)

Sie haben eine Listener-Regel zum Authentifizieren von Benutzern konfiguriert, es trifft aber eine der folgenden Bedingungen zu:

  • Entweder haben Sie OnUnauthenticatedRequest so konfiguriert, dass nicht authentifizierte Benutzer abgelehnt werden, oder der Identitätsanbieter hat den Zugriff abgelehnt.

  • Die Größe der vom Identitätsanbieter zurückgegebenen Ansprüche überschreitet die maximale Größe, die vom Load Balancer unterstützt wird.

  • Ein Client hat eine HTTP/1.0-Anfrage ohne Host-Header eingereicht und der Load Balancer konnte keine Umleitungs-URL generieren.

  • Der angeforderte Bereich gibt kein ID-Token zurück.

  • Sie schließen den Anmeldevorgang nicht ab, bevor das Client-Login-Timeout abgelaufen ist. Weitere Informationen finden Sie unter Client-Login-Timeout.

HTTP 403: Forbidden (Verboten)

Sie haben eine AWS WAF Web Access Control List (Web ACL) konfiguriert, um Anfragen an Ihren Application Load Balancer zu überwachen, und dieser hat eine Anfrage blockiert.

HTTP 405: Methode nicht erlaubt

Der Client hat die TRACE-Methode verwendet, die von Application Load Balancern nicht unterstützt wird.

HTTP 408: Anfrage-Timeout

Der Client hat vor Ablauf des Zeitraums der Leerlaufzeitüberschreitung keine Daten gesendet. Durch Senden eines TCP-Keepalive-Pakets wird dieses Timeout nicht verhindert. Senden Sie mindestens 1 Datenbyte vor Ablauf jeder Leerlaufzeitüberschreitung. Erhöhen Sie bei Bedarf die Länge des Timeout-Limits.

HTTP 413: Nutzlast zu hoch

Mögliche Ursachen:

  • Das Ziel ist eine Lambda-Funktion und der Anfragekörper übersteigt 1 MB.

  • Der Anforderungsheader hat 16 K pro Anforderungszeile, 16 K pro einzelnem Header oder 64 K pro gesamtem Anfrage-Header überschritten.

HTTP 414: URI zu lang

Die Anfrage-URL oder Abfragezeichenfolgen-Parameter sind zu groß.

HTTP 460

Der Load Balancer hat eine Anforderung von einem Client erhalten, aber der Client hat die Verbindung mit dem Load Balancer getrennt, bevor die Leerlaufzeitüberschreitung abgelaufen war.

Überprüfen Sie, ob der Zeitraum der Client-Zeitüberschreitung größer ist als der Zeitraum der Leerlaufzeitüberschreitung für den Load Balancer. Stellen Sie sicher, dass Ihr Ziel eine Antwort an den Client liefert, bevor der Zeitraum der Client-Zeitüberschreitung verstreicht, oder erhöhen Sie den Zeitraum der Client-Zeitüberschreitung entsprechend der Leerlaufzeitüberschreitung des Load Balancer, wenn dies vom Client unterstützt wird.

HTTP 463

Der Load Balancer hat einen X-Forwarded-For-Anfrage-Header mit zu vielen IP-Adressen erhalten. Die Obergrenze für IP-Adressen liegt bei 30.

HTTP 464

Der Load Balancer hat ein eingehendes Anfrageprotokoll erhalten, das mit der Versionskonfiguration des Zielgruppenprotokolls nicht kompatibel ist.

Mögliche Ursachen:

  • Das Anfrageprotokoll ist ein HTTP/1.1, während die Zielgruppenprotokollversion ein gRPC oder HTTP/2 ist.

  • Das Anfrageprotokoll ist ein gRPC, während die Zielgruppenprotokollversion ein HTTP/1.1 ist.

  • Das Anfrageprotokoll ist ein HTTP/2 und die Anfrage ist nicht POST, während die Zielgruppenprotokollversion ein gRPC ist.

HTTP 500: Interner Serverfehler

Mögliche Ursachen:

  • Sie haben eine AWS WAF Web-Zugriffskontrollliste (Web-ACL) konfiguriert und bei der Ausführung der Web-ACL-Regeln ist ein Fehler aufgetreten.

  • Der Load Balancer kann nicht mit dem Identitätsanbieter-Tokenendpunkt oder mit dem Endpunkt mit den Benutzerinformationen des Identitätsanbieters kommunizieren.

    • Überprüfen Sie, ob der DNS des IdP öffentlich auflösbar ist.

    • Stellen Sie sicher, dass die Sicherheitsgruppen für Ihren Load Balancer und die Netzwerk-ACLs für Ihren VPC den ausgehenden Zugriff auf diese Endpunkte zulassen.

    • Stellen Sie sicher, dass Ihre VPC auf das Internet zugreifen kann. Wenn Sie einen internen Load Balancer verwenden, aktivieren Sie den Internetzugriff mithilfe eines NAT-Gateways.

  • Der vom IdP erhaltene Benutzeranspruch ist größer als 11 KB.

HTTP 501: Nicht implementiert

Der Load Balancer erhielt einen Transfer-Encoding (Transferverschlüsselung)-Header mit einem nicht unterstützten Wert. Die unterstützten Werte für Transfer-Encoding (Transferverschlüsselung) sind chunked und identity. Als Alternative können Sie den Content-Encoding (Inhaltsverschlüsselung)-Header verwenden.

HTTP 502: Schlechtes Gateway

Mögliche Ursachen:

  • Der Load Balancer erhielt beim Versuch, eine Verbindung herzustellen, einen TCP-RST vom Ziel.

  • Der Load Balancer hat beim Versuch, eine Verbindung herzustellen, eine unerwartete Antwort vom Ziel empfangen, z. B. "ICMP Destination unreachable (Host unreachable)" (ICMP-Ziel nicht erreichbar (Host nicht erreichbar)). Überprüfen Sie, ob Datenverkehr von den Subnetzen des Load Balancers an die Ziele im Ziel-Port zugelassen wird.

  • Das Ziel hat die Verbindung mit einem TCP-RST oder einem TCP-FIN geschlossen, während der Load Balancer eine ausstehende Anforderung an das Ziel hatte. Überprüfen Sie, ob die Keep-Alive-Dauer des Ziels kürzer ist als der Timeoutwert für die Leerlaufzeit des Load Balancers.

  • Die Zielantwort ist falsch formatiert oder enthält ungültige HTTP-Header.

  • Der Ziel-Antwort-Header hat für den gesamten Antwort-Header 32 K überschritten.

  • Die Verzögerungszeit der Registrierungsaufhebung einer Anfrage, die von einem Ziel verarbeitet wird, dessen Registrierung aufgehoben wurde, ist abgelaufen. Erhöhen Sie die Verzögerungszeit, sodass langwierige Vorgänge abgeschlossen werden können.

  • Das Ziel ist eine Lambda-Funktion und der Anfragekörper übersteigt 1 MB.

  • Das Ziel ist eine Lambda-Funktion, die nicht geantwortet hat, bevor die Zeitüberschreitung erreicht wurde.

  • Das Ziel ist eine Lambda-Funktion, die einen Fehler zurückgegeben hat, oder die Funktion wurde vom Lambda-Service gedrosselt.

  • Der Load Balancer ist beim Herstellen einer Verbindung zu einem Ziel auf einen SSL-Handshake-Fehler gestoßen.

Weitere Informationen finden Sie im AWS Support Knowledge Center unter Wie behebe ich HTTP 502-Fehler im Application Load Balancer?.

HTTP 503: Dienst nicht verfügbar

Die Zielgruppen für den Load Balancer weisen keine registrierten Ziele auf.

HTTP 504: Gateway-Timeout

Mögliche Ursachen:

  • Der Load Balancer konnte vor Ablauf des Verbindungstimeouts (10 Sekunden) keine Verbindung zum Ziel herstellen.

  • Der Load Balancer hat eine Verbindung zum Ziel hergestellt, aber das Ziel hat nicht vor Ablauf des Verbindungstimeouts reagiert.

  • Die Netzwerk-ACL oder die SecurityGroup Netzwerkrichtlinien erlaubten keinen Datenverkehr von den Zielen zu den Load Balancer-Knoten an den kurzlebigen Ports (1024-65535).

  • Das Ziel gibt einen Inhaltslängen-Header zurück, der größer ist als der Entitätskörper. Beim Warten auf die fehlenden Byte wurde das Zeitlimit des Load Balancer überschritten.

  • Das Ziel ist eine Lambda-Funktion und der Lambda-Service hat vor Ablauf des Verbindungszeitlimits nicht reagiert.

  • Der Load Balancer hat beim Herstellen einer Verbindung zu einem Ziel ein SSL-Handshake-Timeout (10 Sekunden) festgestellt.

HTTP 505: Version wird nicht unterstützt

Der Load Balancer hat eine unerwartete HTTP-Versionsanfrage erhalten. Beispielsweise hat der Load Balancer eine HTTP/1-Verbindung hergestellt, aber eine HTTP/2-Anfrage erhalten.

HTTP 507: Nicht genügend Speicherplatz

Die Weiterleitungs-URL ist zu lang.

HTTP 561: Unauthorized (Nicht autorisiert)

Sie haben eine Listener-Regel zum Authentifizieren von Benutzern konfiguriert, aber der Identitätsanbieter hat beim Authentifizieren des Benutzers einen Fehlercode zurückgegeben. Suchen Sie in Ihren Zugriffsprotokollen nach dem entsprechenden Fehlerursachencode.

Ein Ziel generiert einen HTTP-Fehler

Der Load Balancer leitet gültige HTTP-Antworten von Zielen an den Client weiter, einschließlich HTTP-Fehlern. Die von einem Ziel generierten HTTP-Fehler werden in der HTTPCode_Target_4XX_Count- und der HTTPCode_Target_5XX_Count-Metrik aufgezeichnet.

Ein AWS Certificate Manager Zertifikat kann nicht verwendet werden

Wenn Sie sich für die Verwendung eines HTTPS-Listeners mit Ihrem Application Load Balancer entscheiden, AWS Certificate Manager müssen Sie vor der Ausstellung eines Zertifikats den Domainbesitz überprüfen. Wenn dieser Schritt bei der Einrichtung versäumt wird, verbleibt das Zertifikat im Status Pending Validation und kann erst verwendet werden, wenn es validiert wurde.

  • Wenn Sie die E-Mail-Validierung verwenden, finden Sie weitere Informationen unter E-Mail-Validierung im AWS Certificate Manager -Benutzerhandbuch.

  • Weitere Informationen zur DNS-Validierung finden Sie unter DNS-Validierung im AWS Certificate Manager -Benutzerhandbuch.

Header mit mehreren Zeilen werden nicht unterstützt

Application Load Balancer unterstützen keine mehrzeiligen Header, einschließlich des message/http-Medientyp-Headers. Wenn ein mehrzeiliger Header bereitgestellt wird, hängt der Application Load Balancer einen Doppelpunkt „:“ an, bevor er ihn an das Ziel weitergibt.

Beheben Sie fehlerhafte Ziele mithilfe der Ressourcenübersicht

Wenn Ihre Application Load Balancer Balancer-Ziele die Integritätsprüfungen nicht bestehen, können Sie die Ressourcenübersicht verwenden, um fehlerhafte Ziele zu finden und auf der Grundlage des Fehlerursachencodes Maßnahmen zu ergreifen. Weitere Informationen finden Sie unter Sehen Sie sich die Application Load Balancer Balancer-Ressourcenübersicht an.

Die Ressourcenübersicht bietet zwei Ansichten: „Übersicht“ und „Ungesunde Zielübersicht“. Overview ist standardmäßig ausgewählt und zeigt alle Ressourcen Ihres Load Balancers an. Wenn Sie die Ansicht Unhealthy Target Map auswählen, werden nur die fehlerhaften Ziele in jeder Zielgruppe angezeigt, die dem Application Load Balancer zugeordnet ist.

Anmerkung

Sie müssen die Option „Ressourcendetails anzeigen“ aktivieren, um die Zusammenfassung der Integritätsprüfung und die Fehlermeldungen für alle entsprechenden Ressourcen in der Ressourcenübersicht anzuzeigen. Wenn diese Option nicht aktiviert ist, müssen Sie jede Ressource auswählen, um ihre Details anzuzeigen.

In der Spalte Zielgruppen wird eine Zusammenfassung der gesunden und ungesunden Ziele für jede Zielgruppe angezeigt. Auf diese Weise kann festgestellt werden, ob alle Ziele die Zustandsprüfungen nicht bestehen oder nur bestimmte Ziele nicht bestehen. Wenn alle Ziele in einer Zielgruppe die Integritätsprüfungen nicht bestehen, überprüfen Sie die Konfiguration der Zielgruppe. Wählen Sie den Namen einer Zielgruppe aus, um deren Detailseite in einem neuen Tab zu öffnen.

In der Spalte Ziele werden die TargetID und der aktuelle Status der Integritätsprüfung für jedes Ziel angezeigt. Wenn ein Ziel fehlerhaft ist, wird der Code für die Ursache des Fehlers bei der Integritätsprüfung angezeigt. Wenn ein einzelnes Ziel eine Integritätsprüfung nicht besteht, stellen Sie sicher, dass das Ziel über ausreichende Ressourcen verfügt, und stellen Sie sicher, dass die auf dem Ziel ausgeführten Anwendungen verfügbar sind. Wählen Sie die ID eines Ziels aus, um die zugehörige Detailseite in einer neuen Registerkarte zu öffnen.

Wenn Sie Exportieren auswählen, haben Sie die Möglichkeit, die aktuelle Ansicht der Ressourcenübersicht Ihres Application Load Balancers als PDF zu exportieren.

Stellen Sie sicher, dass Ihre Instance die Integritätsprüfungen nicht besteht, und überprüfen Sie dann anhand des Fehlerursachencodes auf die folgenden Probleme:

  • Fehlerhaft: Die HTTP-Antwort stimmt nicht überein

    • Stellen Sie sicher, dass die auf dem Ziel ausgeführte Anwendung die richtige HTTP-Antwort auf die Integritätsprüfanforderungen des Application Load Balancers sendet.

    • Alternativ können Sie die Integritätsprüfanforderung des Application Load Balancers so aktualisieren, dass sie mit der Antwort der Anwendung übereinstimmt, die auf dem Ziel ausgeführt wird.

  • Fehlerhaft: Das Zeitlimit für die Anfrage wurde überschritten

    • Stellen Sie sicher, dass die Sicherheitsgruppen und Network Access Control Lists (ACL), die Ihren Zielen und dem Application Load Balancer zugeordnet sind, die Konnektivität nicht blockieren.

    • Stellen Sie sicher, dass das Ziel über ausreichende Ressourcen verfügt, um Verbindungen vom Application Load Balancer anzunehmen.

    • Überprüfen Sie den Status aller Anwendungen, die auf dem Ziel ausgeführt werden.

    • Die Antworten des Application Load Balancers auf die Integritätsprüfung können in den Anwendungsprotokollen der einzelnen Ziele eingesehen werden. Weitere Informationen finden Sie unter Ursachencodes für Gesundheitschecks.

  • Ungesund: FailedHealthChecks

    • Überprüfen Sie den Status aller Anwendungen, die auf dem Ziel ausgeführt werden.

    • Stellen Sie sicher, dass das Ziel auf dem Health Check-Port auf Datenverkehr wartet.

      Bei Verwendung eines HTTPS-Listeners

      Sie wählen aus, welche Sicherheitsrichtlinie für Front-End-Verbindungen verwendet wird. Die für Back-End-Verbindungen verwendete Sicherheitsrichtlinie wird automatisch auf der Grundlage der verwendeten Front-End-Sicherheitsrichtlinie ausgewählt.

      • Wenn Ihr HTTPS-Listener eine TLS 1.3-Sicherheitsrichtlinie für Front-End-Verbindungen verwendet, wird die ELBSecurityPolicy-TLS13-1-0-2021-06 Sicherheitsrichtlinie für Back-End-Verbindungen verwendet.

      • Wenn Ihr HTTPS-Listener keine TLS 1.3-Sicherheitsrichtlinie für Front-End-Verbindungen verwendet, wird die ELBSecurityPolicy-2016-08 Sicherheitsrichtlinie für Back-End-Verbindungen verwendet.

      Weitere Informationen finden Sie unter Sicherheitsrichtlinien.

    • Stellen Sie sicher, dass das Ziel ein Serverzertifikat und einen Schlüssel im richtigen Format bereitstellt, das in der Sicherheitsrichtlinie angegeben ist.

    • Stellen Sie sicher, dass das Ziel eine oder mehrere übereinstimmende Chiffren und ein vom Application Load Balancer bereitgestelltes Protokoll zur Einrichtung von TLS-Handshakes unterstützt.