Knowledge Center Monthly Newsletter - March 2025
Stay up to date with the latest from the Knowledge Center. See all new and updated Knowledge Center articles published in the last month and re:Post’s top contributors.
Wie behebe ich 504-Fehler, die bei der Verwendung eines Classic Load Balancers zurückgegeben wurden?
Ich sehe HTTP 504-Fehler in den Classic Load Balancer-Zugriffsprotokollen, Amazon CloudWatch-Metriken oder wenn ich über einen Classic Load Balancer eine Verbindung zu meinem Service herstelle.
Behebung
Ein HTTP 504-Fehler ist ein HTTP-Statuscode, der anzeigt, dass ein Gateway oder Proxy eine Zeitüberschreitung verursacht hat. Untersuchen Sie bei der Problembehandlung Folgendes:
Überprüfen Sie das Leerlauf-Timeout Ihres Load Balancers und ändern Sie es bei Bedarf
Der häufigste Grund für einen HTTP 504-Fehler ist, dass eine entsprechende Instanz nicht innerhalb der konfigurierten Leerlaufzeit auf die Anfrage geantwortet hat. Standardmäßig beträgt das Leerlauf-Timeout für Classic Load Balancer 60 Sekunden.
Wenn CloudWatch-Metriken aktiviert sind, überprüfen Sie die CloudWatch-Metriken für Ihren Load Balancer. Wenn die Latenzdatenpunkte gleich dem konfigurierten Timeout-Wert des Load Balancers sind und HTTPCode_ELB_5XX Datenpunkte hat, ist mindestens eine Anforderung in die Zeit gefallen.
Um dieses Problem zu lösen, können Sie eines von zwei Dingen tun:
- Ändern Sie das Leerlauf-Timeout für Ihren Load Balancer so, dass die HTTP-Anfrage innerhalb des Leerlaufzeitlimits abgeschlossen wird.
- Passen Sie Ihre Anwendung an, um schneller zu reagieren.
Stellen Sie sicher, dass Ihre Backend-Instanzen die Verbindungen offen halten
Wenn die Backend-Instanz eine TCP-Verbindung zum Load Balancer schließt, bevor sie ihren Idle-Timeout-Wert erreicht, wird möglicherweise ein HTTP 504-Fehler angezeigt.
Um dies zu beheben, aktivieren Sie die Keepalive-Einstellungen auf Ihren Backend-Instanzen und stellen Sie das Keepalive-Timeout auf einen Wert ein, der größer ist als das Idle-Timeout des Load Balancers.
(nur Apache) Schalten Sie TCP\ _DEFER\ _ACCEPT aus
Wenn TCP\ _DEFER\ _ACCEPT für Apache-Backend-Instanzen aktiviert ist, initiiert der Load Balancer eine Verbindung, indem er ein SYN an die Backend-Instanz sendet. Die Backend-Instanz antwortet dann mit einem SYN-ACK, und der Load Balancer sendet ein leeres ACK an die Backend-Instanz.
Da das letzte ACK leer ist, akzeptiert das Backend das **ACK ** nicht und sendet stattdessen erneut ein SYN-ACK an den Load Balancer. Dies kann zu einem nachfolgenden SYN-Timeout für Wiederholungen führen. Wenn FIN oder RST nicht gesendet werden, bevor die Backend-Instance die Verbindung schließt, betrachtet der Load Balancer die Verbindung als hergestellt, ist es aber nicht. Wenn der Load Balancer dann Anfragen über diese TCP-Verbindung sendet, antwortet das Backend mit einem RST und generiert einen 504-Fehler.
Um dieses Problem zu lösen, setzen Sie sowohl AcceptFilter http als auch AcceptFilter https auf none.
(Nur Apache) Schalten Sie das Event-MPM aus und konfigurieren Sie die Prefork- und Worker-MPMs optimal
Es hat sich bewährt, Event-MPM auf Backend-Instances zu deaktivieren, die bei einem Load Balancer registriert sind. Da das Apache-Backend Verbindungen dynamisch schließt, können diese geschlossenen Verbindungen zu HTTP 504-Fehlern führen. Weitere Informationen finden Sie unter Apache MPM event auf der Apache-Website.
Verwenden Sie die folgenden Werte, um eine optimale Leistung zu erzielen, wenn Sie die Prefork - und Worker-MPMs verwenden und davon ausgehen, dass der Load Balancer mit einem Leerlauf-Timeout von 60 Sekunden konfiguriert ist:
mod\ _prefork MPM | mod_worker MPM | |
Auszeit | 65 | 65 |
Keep Alive Timeout | 65 | 65 |
Bleib am Leben | An | An |
KeepAlive-Anfragen maximieren | 10000 | 0 |
AkzeptierenFilter http | keine | keine |
AkzeptierenFilter https | keine | keine |
Weitere Informationen finden Sie unter Apache MPM Worker und Apache MPM Prefork auf der Apache-Website.
Ähnliche Informationen
Überwachen Sie Ihren Classic Load Balancer

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 6 Monaten
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Monaten