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 Arbeit der Verschlüsselung und Entschlüsselung auf Ihren Load Balancer auszulagern, sodass sich Ihre Anwendungen auf ihre Geschäftslogik konzentrieren können. Wenn das Listener-Protokoll verwendet wirdHTTPS, müssen Sie mindestens ein SSL Serverzertifikat auf dem Listener bereitstellen. Weitere Informationen finden Sie unter Erstellen Sie einen HTTPS Listener für Ihren Application Load Balancer.

Wenn Sie sicherstellen müssen, dass die Ziele den HTTPS Datenverkehr anstelle des Load Balancers entschlüsseln, können Sie einen Network Load Balancer mit einem TCP Listener an Port 443 erstellen. Mit 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 Balancer 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 es sowohl WebSockets mit als auch mit HTTP Listenern HTTPS verwenden. Die Optionen, die Sie für Ihren Listener auswählen, gelten sowohl für WebSocket Verbindungen als auch für den HTTP Datenverkehr. Weitere Informationen finden Sie unter So funktioniert das WebSocket Protokoll im Amazon CloudFront Developer Guide.

Application Load Balancers bieten native Unterstützung für HTTP /2 mit HTTPS Listenern. Sie können über eine HTTP /2-Verbindung bis zu 128 Anfragen parallel senden. Sie können die Protokollversion verwenden, um die Anfrage mit HTTP /2 an die Ziele zu senden. Weitere Informationen finden Sie unter Protokollversion. Da HTTP /2 Frontend-Verbindungen effizienter verwendet, stellen Sie möglicherweise fest, dass weniger Verbindungen zwischen Clients und dem Load Balancer bestehen. Sie können die Server-Push-Funktion von /2 nicht verwenden. HTTP

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 g RPC oder HTTP /2 ist, sind die einzigen unterstützten Aktionen forward Aktionen.

Aktionen mit feststehender Antwort

Sie können fixed-response Aktionen verwenden, um Client-Anfragen zu löschen 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 Umleitungsziels 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 codierten Cookie-Werte. URL

Bei Anfragen CORS (ursprungsübergreifende gemeinsame Nutzung von Ressourcen) müssen einige Browser Stickiness aktivierenSameSite=None; Secure. 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

Sie können redirect Aktionen verwenden, um Client-Anfragen von einer URL zur anderen weiterzuleiten. Sie können Weiterleitungen je nach Bedarf entweder temporär (HTTP302) oder permanent (HTTP301) konfigurieren.

A URI besteht aus den folgenden 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 des Originals URL im Ziel wiederverwenden, URL indem Sie die folgenden reservierten Schlüsselwörter verwenden:

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

Die folgende Regel richtet eine permanente Umleitung zu einer einURL, die das HTTPS Protokoll und den angegebenen Port (40443) verwendet, aber den ursprünglichen Hostnamen, Pfad und Abfrageparameter beibehält. Dieser Bildschirm entspricht "https://#{host}:40443/#{path}?#{query}".

Die folgende Regel richtet eine permanente Umleitung zu a einURL, die das ursprüngliche Protokoll, den Port, den Hostnamen und die Abfrageparameter beibehält und das #{path} Schlüsselwort verwendet, um einen geänderten Pfad zu erstellen. 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. Beispielsweise können Sie für jede http-header Bedingung bis zu drei Zeichenketten angeben, die mit dem Wert des HTTP Headers in der Anforderung verglichen werden sollen. Die Bedingung ist erfüllt, wenn eine der Zeichenketten mit dem Wert des HTTP Headers übereinstimmt. 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.

HTTPHeader-Bedingungen

Sie können HTTP Header-Bedingungen verwenden, um Regeln zu konfigurieren, die Anfragen auf der Grundlage der HTTP Header für die Anfrage weiterleiten. Sie können die Namen von Standard- oder benutzerdefinierten HTTP Header-Feldern 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*"]
      }
  }
]

HTTPBedingungen der Anforderungsmethode

Sie können Bedingungen für HTTP Anforderungsmethoden verwenden, um Regeln zu konfigurieren, die Anfragen auf der Grundlage der HTTP Anforderungsmethode der Anfrage weiterleiten. Sie können Standard- 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 HEAD Anfragen auf dieselbe Weise weiterleitenGET, da die Antwort auf eine HEAD Anfrage 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

Sie können Pfadbedingungen verwenden, um Regeln zu definieren, die Anfragen auf der Grundlage der URL in der Anfrage enthaltenen weiterleiten (auch bekannt als pfadbasiertes Routing).

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

Die Regelauswertung wird erst nach der Normalisierung durchgeführt. URI

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

Wenn die Protokollversion g istRPC, können die 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 die Bedingung 255.255.255.255/32 CIDR für die Quell-IP-Regel 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 im X-Forwarded-For Header 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"]
      }
  }
]

HTTPHeader und Application Load Balancer

HTTPAnfragen und HTTP Antworten verwenden Header-Felder, um Informationen zu den HTTP Nachrichten zu senden. HTTPHeader 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, Nachrichtenkopfzeilen, definiert. Es sind auch nicht standardmäßige HTTP Header verfügbar, die automatisch hinzugefügt werden und von den Anwendungen häufig verwendet werden. Einige der nicht standardmäßigen HTTP Header haben ein Präfix. X-Forwarded Application Load Balancer unterstützen die folgenden X-Forwarded-Header.

Weitere Informationen zu HTTP Verbindungen finden Sie unter Anforderungsrouting im Elastic Load Balancing User Guide.

X-Forwarded-For

Der X-Forwarded-For Anforderungsheader hilft Ihnen dabei, die IP-Adresse eines Clients zu identifizieren, wenn Sie einen HTTP OR Load HTTPS 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. Mit diesem Attribut können Sie den X-Forwarded-For Header in der HTTP Anfrage ändern, beibehalten oder entfernen, bevor der Application Load Balancer die Anfrage 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 Anfrage 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 Anfrage, 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 Anforderungsheader hilft Ihnen dabei, das Protokoll (HTTPoderHTTPS) zu identifizieren, das ein Client verwendet hat, um eine Verbindung zu Ihrem Load Balancer herzustellen. 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 Anforderungsheader gespeicherte Protokoll verwenden, um eine Antwort zu rendern, die an das entsprechende URL Objekt weitergeleitet wird.

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

X-Forwarded-Proto: originatingProtocol

Das folgende Beispiel enthält einen X-Forwarded-Proto Anforderungsheader für eine Anfrage, die vom Client als HTTPS Anfrage stammt:

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.