Listener für Ihre Application Load Balancer

Ein Listener ist ein Prozess, der mit dem Protokoll und dem Port, das bzw. den Sie konfigurieren, Verbindungsanforderungen prüft. Bevor Sie Ihren Application Load Balancer verwenden können, müssen Sie mindestens einen Listener hinzufügen. Wenn Ihr Load Balancer keine Listener hat, kann er keinen Datenverkehr von Clients empfangen. Die Regeln, die Sie für Ihre Listener definieren, bestimmen, wie der Load Balancer Anfragen an die von Ihnen registrierten Ziele weiterleitet, z. B. EC2 Instances.

Listener-Konfiguration

Listener unterstützen die folgenden Protokolle und Ports:

Sie können einen HTTPS-Listener verwenden, um die Ver- und Entschlüsselung auf Ihren Load Balancer auszulagern, damit sich Ihre Anwendungen auf die Geschäftslogik konzentrieren können. Wenn das Listener-Protokoll HTTPS ist, müssen Sie auf dem Listener mindestens ein SSL-Serverzertifikat bereitstellen. Weitere Informationen finden Sie unter Erstellen eines HTTPS-Listeners für Ihren Application Load Balancer.

Wenn Sie sicherstellen müssen, dass die Ziele den HTTPS-Verkehr anstelle des Load Balancers entschlüsseln, können Sie einen Network Load Balancer mit einem TCP-Listener an Port 443 erstellen. Bei einem TCP-Listener leitet der Load Balancer verschlüsselten Datenverkehr an die Ziele weiter, ohne ihn zu entschlüsseln. Weitere Informationen finden Sie im Benutzerhandbuch für Network Load Balancers.

Application Load Balancers bieten native Unterstützung für. WebSockets Sie können eine bestehende HTTP/1.1-Verbindung in eine WebSocket (wsoderwss) -Verbindung umwandeln, indem Sie ein HTTP-Verbindungs-Upgrade verwenden. Wenn Sie ein Upgrade durchführen, wird die für Anfragen (sowohl zum Load Balancer als auch zum Ziel) verwendete TCP-Verbindung über den Load Balancer zu einer dauerhaften WebSocket Verbindung zwischen dem Client und dem Ziel. Sie können sie sowohl WebSockets mit HTTP- als auch mit HTTPS-Listenern verwenden. Die Optionen, die Sie für Ihren Listener auswählen, gelten sowohl für WebSocket Verbindungen als auch für HTTP-Verkehr. Weitere Informationen finden Sie unter So funktioniert das WebSocket Protokoll im Amazon CloudFront Developer Guide.

Application Load Balancer verfügen über native Unterstützung für HTTP/2 mit HTTPS-Listener. Sie können mit einer einzigen HTTP/2-Verbindung bis zu 128 Anforderungen parallel senden. Sie können die Protokollversion verwenden, um die Anforderung mit HTTP/2 an die Ziele zu senden. Weitere Informationen finden Sie unter Protokollversion. Da HTTP/2 Frontend-Verbindungen effizienter verwendet, gibt es möglicherweise weniger Verbindungen zwischen Clients und dem Load Balancer. Sie können das Server-Push-Feature von HTTP/2 nicht verwenden.

Weitere Informationen finden Sie unter Weiterleitung von Anforderungen im Benutzerhandbuch zu Elastic Load Balancing.

Listener-Attribute

Im Folgenden sind die Listener-Attribute für Application Load Balancers aufgeführt

Listener-Regeln

Jeder Listener hat eine Standardaktion, auch als Standardregel bezeichnet. Die Standardregel kann nicht gelöscht werden und wird immer zuletzt ausgeführt. Es können zusätzliche Regeln erstellt werden, die aus einer Priorität, mindestens einer Aktion und mindestens einer Bedingung bestehen. Sie können jederzeit Regel hinzufügen oder bearbeiten. Weitere Informationen finden Sie unter Bearbeiten einer Regel.

Standardregeln

Beim Erstellen eines Listeners definieren Sie Aktionen für die Standardregel. Standardregeln können keine Bedingungen aufweisen. Wenn für die Regeln eines Listeners keine Bedingungen erfüllt werden, wird die Aktion für die Standardregel durchgeführt.

Es folgt ein Beispiel für eine Standardregel, wie in der Konsole dargestellt:

Priorität der Regel

Jede Regel hat eine Priorität. Regeln werden in der Reihenfolge ihrer Prioritäten bewertet, ausgehend vom niedrigsten Wert hin zum höchsten Wert. Die Standardregel wird zuletzt ausgewertet. Sie können die Priorität einer nicht standardmäßigen Regel jederzeit ändern. Sie können die Priorität der Standardregel nicht ändern. Weitere Informationen finden Sie unter Aktualisieren der Regelpriorität.

Regelaktionen

Jede Regelaktion verfügt über einen Typ, eine Priorität und die für die Durchführung der Aktion erforderlichen Informationen. Weitere Informationen finden Sie unter Regelaktionstypen.

Regelbedingungen

Jede Regelbedingung weist einen Typ und Bedingungsinformationen auf. Wenn die Bedingungen für eine Regel erfüllt sind, wird die dazugehörige Aktion durchgeführt. Weitere Informationen finden Sie unter Regelbedingungstypen.

Regelaktionstypen

Im Folgenden finden Sie die unterstützten Aktionstypen einer Listener-Regel:

Die Aktion mit der niedrigsten Priorität wird zuerst durchgeführt. Jede Regel muss genau eine der folgenden Aktionen enthalten: forward, redirect oder fixed-response. Außerdem muss es die letzte auszuführende Regel sein.

Wenn die Protokollversion gRPC oder HTTP/2 ist, sind forward-Aktionen die einzigen unterstützten Aktionen.

Aktionen mit feststehender Antwort

Verwenden Sie fixed-response-Aktionen, um Client-Anforderungen zu verwerfen und eine benutzerdefinierte HTTP-Antwort zurückzugeben. Sie können mit dieser Aktion einen 2XX-, 4XX- 5XX-Antwortcode und optional eine Nachricht zurückgeben.

Wenn eine fixed-response-Aktion ausgeführt wird, werden die Aktion und die URL des Weiterleitungsziels in den Zugriffsprotokollen aufgezeichnet. Weitere Informationen finden Sie unter Zugriffsprotokolleinträge. Die Anzahl der erfolgreichen fixed-response-Aktionen wird in der Metrik HTTP_Fixed_Response_Count erfasst. Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

Weiterleitungsaktionen

Sie können mithilfe von forward-Aktionen Anforderungen an eine oder mehrere Zielgruppen weiterleiten. Wenn Sie mehrere Zielgruppen für eine forward-Aktion angeben, müssen Sie für jede Zielgruppe eine Gewichtung angeben. Jede Zielgruppengewichtung ist ein Wert zwischen 0 und 999. Anforderungen, die einer Listener-Regel mit gewichteten Zielgruppen entsprechen, werden basierend auf ihren Gewichtungen an diese Zielgruppen verteilt. Wenn Sie beispielsweise zwei Zielgruppen mit einer Gewichtung von 10 angeben, erhält jede Zielgruppe die Hälfte der Anforderungen. Wenn Sie zwei Zielgruppen angeben, eine mit einer Gewichtung von 10 und die andere mit einer Gewichtung von 20, erhält die Zielgruppe mit der Gewichtung von 20 doppelt so viele Anforderungen wie die andere Zielgruppe.

Standardmäßig garantiert das Konfigurieren einer Regel für die Verteilung des Datenverkehrs zwischen gewichteten Zielgruppen nicht, dass Sticky Sessions eingehalten werden. Um sicherzustellen, dass Sticky Sessions eingehalten werden, aktivieren Sie die Klebrigkeit der Zielgruppe für die Regel. Wenn der Load Balancer eine Anfrage zum ersten Mal an eine gewichtete Zielgruppe weiterleitet, generiert er ein Cookie mit dem Namen AWSALBTG , das Informationen über die ausgewählte Zielgruppe kodiert, das Cookie verschlüsselt und das Cookie in die Antwort an den Client einbezieht. Der Client sollte das erhaltene Cookie in nachfolgende Anfragen an den Load Balancer aufnehmen. Wenn der Load Balancer eine Anforderung empfängt, die mit einer Regel mit aktivierter Zielgruppenklebrigkeit übereinstimmt und das Cookie enthält, wird die Anforderung an die im Cookie angegebene Zielgruppe weitergeleitet.

Application Load Balancer unterstützen keine Cookie-Werte, die URL-codiert sind.

Bei CORS (Cross-Origin Resource Sharing)-Anforderungen benötigen einige Browser SameSite=None; Secure zum Aktivieren von Stickiness. In diesem Fall generiert Elastic Load Balancing ein zweites Cookie AWSALBTGCORS, das dieselben Informationen wie das ursprüngliche Stickiness-Cookie plus dieses SameSite Attribut enthält. Kunden erhalten beide Cookies.

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

Weiterleitungsaktionen

Mithilfe von redirect-Aktionen können Sie Client-Anforderungen von einer URL an eine andere weiterleiten. Konfigurieren Sie Weiterleitungen je nach Bedarf entweder als temporär (HTTP 302) oder permanent (HTTP 301).

eine URI umfasst folgende Komponenten:

protocol://hostname:port/path?query

Sie müssen mindestens eine der folgenden Komponenten modifizieren, um eine Weiterleitungsschleife zu verhindern: Protokoll, Hostname, Port oder Pfad. Für alle Komponenten, an denen Sie keine Änderungen vornehmen, wird der ursprüngliche Wert beibehalten.

Sie können URI-Komponenten der ursprünglichen URL in der Ziel-URL weiter nutzen. Verwenden Sie dazu die folgenden reservierten Schlüsselwörter:

Wenn eine redirect-Aktion ausgeführt wird, wird diese in den Zugriffsprotokollen aufgezeichnet. Weitere Informationen finden Sie unter Zugriffsprotokolleinträge. Die Anzahl der erfolgreichen redirect-Aktionen wird in der Metrik HTTP_Redirect_Count erfasst. Weitere Informationen finden Sie unter Application-Load-Balancer-Metriken.

Beispiel für Weiterleitungsaktionen mithilfe der Konsole

Mit der folgenden Regel wird beispielsweise eine permanente Weiterleitung auf eine URL mit dem HTTPS-Protokoll und dem festgelegten Port 40443 eingerichtet. Beibehalten werden der ursprüngliche Hostname, der Pfad und die Abfrageparameter. Dieser Bildschirm entspricht "https://#{host}:40443/#{path}?#{query}".

Mit der folgenden Regel wird eine permanente Weiterleitung auf eine URL mit dem ursprünglichen Protokoll, Port, Hostnamen und Abfrageparametern eingerichtet. Der Pfad wird mit dem Schlüsselwort #{path} modifiziert. Dieser Bildschirm entspricht "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

Regelbedingungstypen

Im Folgenden finden Sie die unterstützten Bedingungstypen für eine Regel:

Jede Regel kann optional jeweils eine der folgenden Bedingungen umfassen: host-header, http-request-method, path-pattern, und source-ip. Jede Regel kann optional auch eine oder mehrere der folgenden Bedingungen enthalten: http-header und query-string.

Sie können bis zu drei Übereinstimmungsbewertungen pro Bedingung angeben. Beispiel: Für jede http-header-Bedingung können Sie bis zu drei Zeichenfolgen angeben, die mit dem Wert des HTTP-Headers in der Anforderung vergleichen werden. Die Bedingung wird erfüllt, wenn eine der Zeichenfolgen dem Wert des HTTP-Headers entspricht. Wenn alle drei Zeichenfolgen eine Übereinstimmung aufweisen sollen, erstellen Sie eine Bedingung pro Übereinstimmungsbewertung.

Sie können bis zu fünf Übereinstimmungsbewertungen pro Regel angeben. Beispiel: Sie können eine Regel mit fünf Bedingungen erstellen, wobei jede Bedingung eine Übereinstimmungsbewertung aufweist.

Sie können Platzhalterzeichen in die Übereinstimmungsbewertung für die Bedingungen http-header, host-header, path-pattern und query-string einschließen. Die Anzahl der Platzhalterzeichen pro Bedingung ist auf 5 beschränkt.

Regeln werden nur auf sichtbare ASCII-Zeichen angewendet; Steuerzeichen (0x00 bis 0x1f und 0x7f) sind ausgeschlossen.

Demos finden Sie unter Erweiterte Anfrageweiterleitung.

HTTP-Header-Bedingungen

Mit HTTP-Header-Bedingungen können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der HTTP-Header für die Anforderung weitergeleitet werden. Sie können die Namen der standardmäßigen oder benutzerdefinierten HTTP-Header-Felder angeben. Beim Headernamen und bei der Übereinstimmungsbewertung wird nicht zwischen die Groß- und Kleinschreibung unterschieden. Die folgenden Platzhalterzeichen werden in den Vergleichszeichenfolgen unterstützt: * (findet eine Übereinstimmung mit 0 oder mehr Zeichen) und ? (findet Übereinstimmungen für genau 1 Zeichen). Platzhalterzeichen werden im Header-Namen nicht unterstützt.

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

Bedingungen für HTTP-Anforderungsmethoden

Mit Bedingungen für HTTP-Anforderungsmethoden können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der HTTP-Anforderungsmethode der Anforderung weitergeleitet werden. Sie können standardmäßige oder benutzerdefinierte HTTP-Methoden angeben. Bei der Übereinstimmungsbewertung wird die Groß- und Kleinschreibung nicht beachtet, Platzhalterzeichen werden nicht unterstützt. Der Methodenname muss also eine genaue Übereinstimmung sein.

Wir empfehlen, dass Sie GET- und HEAD-Anforderungen auf die gleiche Weise weiterleiten, da die Antwort auf eine HEAD-Anforderung möglicherweise zwischengespeichert wird.

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Hostbedingungen

Mit Hostbedingungen können Sie Regeln definieren, die Anforderungen basierend auf dem Hostnamen im Host-Header weiterleiten (auch als hostbasierte Weiterleitung bezeichnet). Auf diese Weise können Sie mit einem einzigen Load Balancer mehrere Unterdomains und verschiedene Top-Level-Domains unterstützen.

Beim Hostnamen wird die Groß-/Kleinschreibung nicht berücksichtigt, er kann maximal 128 Zeichen lang sein und kann folgende Zeichen enthalten:

Sie müssen mindestens ein "."-Zeichen einschließen. Es können nur alphabethische Zeichen nach dem letzten "."-Zeichen angegeben werden.

Die Regel *.example.com entspricht test.example.com, nicht jedoch example.com.

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Pfadbedingungen

Mit Pfadbedingungen können Sie Regeln definieren, mit denen Anforderungen auf Grundlage der URL in der Anforderung weitergeleitet werden (auch bekannt als pfadbasierte Weiterleitung

Das Pfadmuster wird nur auf den Pfad der URL, nicht auf dessen Abfrageparameter, angewendet. Es wird nur auf sichtbare ASCII-Zeichen angewendet; Steuerzeichen (0x00 bis 0x1f und 0x7f) sind ausgeschlossen.

Die Regelauswertung wird erst durchgeführt, nachdem die URI-Normalisierung erfolgt ist.

Beim Pfadmuster wird die Groß-/Kleinschreibung berücksichtigt, es kann maximal 128 Zeichen lang sein und kann folgende Zeichen enthalten.

Wenn die Protokollversion gRPC ist, können Bedingungen für ein Paket, einen Dienst oder eine Methode spezifisch sein.

Das Pfadmuster wird verwendet, um Anforderungen weiterzuleiten. Die Anforderungen werden bei diesem Vorgang aber nicht geändert. Wenn eine Regel beispielsweise das Pfadmuster /img/* aufweist, leitet die Regel eine Anforderung von /img/picture.jpg an die angegebene Zielgruppe als Anforderung von /img/picture.jpg weiter.

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Abfragezeichenfolgebedingungen

Mit Abfragezeichenfolgebedingungen können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage von Schlüssel/Wert-Paaren oder Werten in der Abfragezeichenfolge weitergeleitet werden. Bei der Übereinstimmungsbewertung wird die Groß- und Kleinschreibung nicht beachtet, Die folgenden Platzhalterzeichen werden unterstützt: * (findet Übereinstimmungen mit 0 oder mehr Zeichen) und ? (findet Übereinstimmungen für genau 1 Zeichen).

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Bedingungen für die Quell-IP-Adresse

Mit Bedingungen für die Quell-IP-Adresse können Sie Regeln konfigurieren, mit denen Anforderungen auf Grundlage der Quell-IP-Adresse der Anforderung weitergeleitet werden. Die IP-Adresse muss im CIDR-Format angegeben werden. Sie können sowohl IPv6 Adressen als IPv4 auch verwenden. Platzhalterzeichen werden nicht unterstützt. Sie können den 255.255.255.255/32-CIDR für die Quell-IP-Regelbedingung nicht angeben.

Befindet sich ein Client hinter einem Proxy, ist dies die IP-Adresse des Proxys, nicht die des Clients.

Diese Bedingung wird von den Adressen in der X-Forwarded-For Kopfzeile nicht erfüllt. Verwenden Sie eine http-header Bedingung, um in der X-Forwarded-For Kopfzeile nach Adressen zu suchen.

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

HTTP-Header und Application Load Balancer

Die HTTP-Anforderungen und -Antworten verwenden Header-Felder, um Informationen über HTTP-Nachrichten zu senden. HTTP-Header werden automatisch hinzugefügt. Header-Felder sind durch einen Doppelpunkt getrennte Name/Wert-Paare, die durch eine Zeilenumschaltung und einen Zeilenvorschub getrennt sind. Ein Standardsatz von HTTP-Header-Feldern ist in RFC 2616, Nachrichten-Header definiert. Es sind auch Nicht-Standard-HTTP-Header verfügbar, die automatisch hinzugefügt und weithin von den Anwendungen verwendet werden. Einige der Nicht-Standard-HTTP-Header besitzen ein X-Forwarded-Präfix. Application Load Balancer unterstützen die folgenden X-Forwarded-Header.

Weitere Informationen zu HTTP-Verbindungen finden Sie unter Weiterleitung von Anforderungen im Benutzerhandbuch zu Elastic Load Balancing.

X-Forwarded-For

Der X-Forwarded-For-Anforderungs-Header hilft Ihnen, die IP-Adresse eines Clients zu identifizieren, wenn Sie einen HTTP- oder HTTPS-Load Balancer verwenden. Da Load Balancer Datenverkehr zwischen Clients und Servern abfangen, enthalten Ihre Server-Zugriffsprotokolle nur die IP-Adresse des Load Balancers. Verwenden Sie das routing.http.xff_header_processing.mode-Attribut, um die IP-Adresse des Clients anzuzeigen. Dieses Attribut ermöglicht das Ändern, Beibehalten oder Entfernen der X-Forwarded-For-Header in der HTTP-Anforderung, bevor der Application Load Balancer die Anforderung an das Ziel sendet. Die möglichen Werte für dieses Attribut sind append, preserve und remove. Der Standardwert für dieses Attribut ist append.

Anfügen

Der Application Load Balancer speichert die IP-Adresse des Clients standardmäßig im X-Forwarded-For-Anforderungs-Header und übergibt den Header an Ihren Server. Wenn der X-Forwarded-For-Anforderungsheader nicht in der ursprünglichen Anforderung enthalten ist, erstellt der Load Balancer einen Header mit der Client-IP-Adresse als Anforderungswert. Andernfalls hängt der Load Balancer die Client-IP-Adresse an den vorhandenen Header an und leitet den Header dann an Ihren Server weiter. Der X-Forwarded-For-Anforderungsheader kann mehrere IP-Adressen enthalten, die durch Kommas getrennt sind.

Der X-Forwarded-For-Anforderungs-Header besitzt das folgende Format:

X-Forwarded-For: client-ip-address

Nachfolgend finden Sie ein Beispiel für einen X-Forwarded-For-Anforderungs-Header für einen Client mit der IP-Adresse 203.0.113.7.

X-Forwarded-For: 203.0.113.7

Im Folgenden finden Sie ein Beispiel für einen X-Forwarded-For Anforderungsheader für einen Client mit der IPv6 Adresse. 2001:DB8::21f:5bff:febf:ce22:8a2e

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Wenn das Attribut zur Beibehaltung des Client-Ports (routing.http.xff_client_port.enabled) im Load Balancer aktiviert ist, enthält der X-Forwarded-For-Anforderungsheader die an die client-port-number angehängte client-ip-address, durch einen Doppelpunkt getrennt. Der Header nimmt dann das folgende Format an:

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number

IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

Beachten Sie IPv6 nämlich, dass der Load Balancer, wenn er den client-ip-address an den vorhandenen Header anhängt, die Adresse in eckige Klammern setzt.

Im Folgenden finden Sie ein Beispiel für einen X-Forwarded-For Anforderungsheader für einen Client mit der IPv4 Adresse 12.34.56.78 und der Portnummer von. 8080

X-Forwarded-For: 12.34.56.78:8080

Im Folgenden finden Sie ein Beispiel für einen X-Forwarded-For Anforderungsheader für einen Client mit der IPv6 Adresse 2001:db8:85a3:8d3:1319:8a2e:370:7348 und der Portnummer von8080.

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Beibehalten

Der preserve-Modus im Attribut stellt sicher, dass der X-Forwarded-For-Header in der HTTP-Anforderung in keiner Weise geändert wird, bevor er an Ziele gesendet wird.

Remove

Der remove-Modus im Attribut entfernt den X-Forwarded-For-Header in der HTTP-Anforderung, bevor er an Ziele gesendet wird.

Die folgende Tabelle zeigt Beispiele für den X-Forwarded-For-Header, den das Ziel erhält, wenn Sie entweder den Modus append, preserve oder den Modus remove auswählen. In diesem Beispiel lautet die IP-Adresse des letzten Hops 127.0.0.1.

Um das zu ändern, beizubehalten oder zu entfernen X-Forwarded-For Header mit dem AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem routing.http.xff_header_processing.mode Attribut.

X-Forwarded-Proto

Der X-Forwarded-Proto-Anforderungs-Header hilft Ihnen, das Protokoll (HTTP oder HTTPS) zu identifizieren, das ein Client für die Verbindung zu Ihrem Load Balancer verwendet hat. Ihre Server-Zugriffsprotokolle enthalten nur das Protokoll zwischen dem Server und dem Load Balancer. Sie enthalten keine Informationen über das Protokoll zwischen dem Client und dem Load Balancer. Verwenden Sie den X-Forwarded-Proto-Anforderungs-Header, um das Protokoll zwischen dem Client und dem Load Balancer zu überprüfen. Elastic Load Balancing speichert das Protokoll zwischen dem Client und dem Load Balancer im X-Forwarded-Proto-Anforderungs-Header und übergibt den Header an den Server.

Ihre Anwendung oder Website kann das im X-Forwarded-Proto-Anforderungs-Header gespeicherte Protokoll verwenden, um eine Rückmeldung auszugeben, die auf die entsprechende URL umleitet.

Der X-Forwarded-Proto-Anforderungs-Header besitzt das folgende Format:

X-Forwarded-Proto: originatingProtocol

Das folgende Beispiel enthält einen X-Forwarded-Proto-Anforderungs-Header für eine Anforderung, die vom Client als HTTPS-Anforderung ausgegeben wurde:

X-Forwarded-Proto: https

X-Forwarded-Port

Mit dem X-Forwarded-Port-Anforderungs-Header können Sie den Zielport identifizieren, den der Client für die Verbindung mit dem Load Balancer verwendet hat.