Application Load Balancer 的侦听器 - Elastic Load Balancing
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Application Load Balancer 的侦听器

侦听器是一个使用您配置的协议和端口检查连接请求的进程。在开始使用 Application Load Balancer 之前,必须添加至少一个侦听器。如果您的负载均衡器没有侦听器,则无法接收来自客户端的流量。您为侦听器定义的规则确定负载均衡器如何将请求路由到您注册的目标。例如 EC2 实例。

侦听器配置

侦听器支持以下协议和端口:

  • 协议:HTTP、HTTPS

  • 端口:1-65535

可以使用 HTTPS 侦听器将加密和解密的工作交给负载均衡器完成,以便应用程序可以专注于其业务逻辑。如果侦听器协议为 HTTPS,您必须在侦听器上部署至少一个 SSL 服务器证书。有关更多信息,请参阅 为您的 Application Load Balancer 创建 HTTPS 侦听器

如果必须确保目标解密 HTTPS 流量而不是负载均衡器,则可以在端口 443 上使用 TCP 侦听器创建网络负载均衡器。通过 TCP 侦听器,负载均衡器将加密流量传递到目标,而不会对其进行解密。有关 Network Load Balancer 的更多信息,请参阅 Network Load Balancers 用户指南

Application Load Balancer 为 WebSockets 提供本机支持。您可以使用 HTTP 连接升级将现有 HTTP/1.1 连接升级为 WebSocket(wswss)连接。升级时,用于(向负载均衡器和目标)请求的 TCP 连接将通过负载均衡器成为客户端和目标之间的永久性 WebSocket 连接。您可以对 HTTP 和 HTTPS 侦听器同时使用 WebSocket。您为侦听器选择的选项适用于 WebSocket 连接以及 HTTP 流量。有关更多信息,请参阅 Amazon CloudFront 开发人员指南中的 WebSocket 协议的工作原理

Application Load Balancer 为将 HTTP/2 与 HTTPS 侦听器一起使用提供本机支持。使用一个 HTTP/2 连接最多可以并行发送 128 个请求。您可以通过协议版本使用 HTTP/2 将请求发送到目标。有关更多信息,请参阅 协议版本。由于 HTTP/2 可以更高效地使用前端连接,您可能注意到客户端与负载均衡器之间的连接较少。无法使用 HTTP/2 的服务器推送功能。

有关更多信息,请参阅 Elastic Load Balancing 用户指南中的请求路由

侦听器规则

每个侦听器都有默认操作,也称为默认规则。默认规则无法删除,并且始终在最后执行。可以创建其他规则,这些规则由优先级、一个或多个操作以及一个或多个条件组成。您可以随时添加或编辑规则。有关更多信息,请参阅 编辑规则

默认规则

创建侦听器时,请为默认规则定义操作。默认规则不能有条件。如果未满足侦听器的任一规则条件,则将执行默认规则的操作。

下面是控制台中所示的默认规则的示例:

侦听器的默认规则。

规则优先级

每个规则都有一个优先级。规则是按优先级顺序 (从最低值到最高值) 计算的。最后评估默认规则。您可以随时更改非默认规则的优先级。您不能更改默认规则的优先级。有关更多信息,请参阅 更新规则优先级

规则操作

每个规则操作都具有执行操作所需的类型、优先级和信息。有关更多信息,请参阅 规则操作类型

规则条件

每个规则条件都有类型和配置信息。当规则的条件满足时,将执行其操作。有关更多信息,请参阅 规则条件类型

规则操作类型

以下是侦听器规则支持的操作类型:

authenticate-cognito

[HTTPS 侦听器] 使用 Amazon Cognito 验证用户身份。有关更多信息,请参阅 使用 Application Load Balancer 验证用户身份

authenticate-oidc

[HTTPS 侦听器] 使用符合 OpenID Connect (OIDC) 条件的身份提供商验证用户身份。

fixed-response

返回自定义 HTTP 响应。有关更多信息,请参阅 固定响应操作

forward

将请求转发到指定目标组。有关更多信息,请参阅 转发操作

redirect

将请求从一个 URL 重定向到另一个。有关更多信息,请参阅 重定向操作

先执行优先级最低的操作。每条规则必须包含以下操作之一:forwardredirectfixed-response,并且其必须为要执行的最后一个操作。

如果协议版本是 gRPC 或 HTTP/2,则唯一支持的操作是 forward 操作。

固定响应操作

您可以使用 fixed-response 操作删除客户端请求并返回自定义 HTTP 响应。您可以使用此操作返回 2XX、4XX 或 5XX 响应代码和可选的消息。

采取 fixed-response 操作时,操作和重定向目标的 URL 记录在访问日志中。有关更多信息,请参阅 访问日志条目。成功 fixed-response 操作的计数在 HTTP_Fixed_Response_Count 指标中报告。有关更多信息,请参阅 Application Load Balancer 指标

例 Amazon CLI 固定响应操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作发送具有指定状态代码和消息正文的固定响应。

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

转发操作

您可以使用 forward 操作,将请求路由到一个或多个目标组。如果为某个 forward 操作指定多个目标组,您必须为每个目标组指定权重。每个目标组权重都是一个介于 0 到 999 之间的值。对于将侦听器规则与加权目标组匹配的请求,会根据这些目标组的权重分配给这些目标组。例如,如果指定两个目标组,每个目标组的权重为 10,则每个目标组将接收一半的请求。如果指定两个目标组,一个权重为 10,另一个权重为 20,则权重为 20 的目标组接收的请求将是另一个目标组的两倍。

默认情况下,配置规则以便在加权目标组之间分配流量时,并不能保证支持粘性会话。为了确保支持粘性会话,请为规则启用目标组粘性。当负载均衡器首次将请求路由到加权目标组时,它会生成一个名为 AWSALBTG 的 Cookie,该 Cookie 对选定目标组的信息进行编码,对 Cookie 进行加密,并且在返回给客户端的响应中包含该 Cookie。客户端应该在向负载均衡器的后续请求中包含它收到的 cookie。当负载均衡器收到与启用目标组粘性的规则匹配并且包含 Cookie 的请求时,请求将路由到 Cookie 中指定的目标组。

Application Load Balancer 不支持 URL 编码的 Cookie 值。

对于 CORS(跨源资源共享)请求,某些浏览器需要 SameSite=None; Secure 来启用粘性。在这种情况下,Elastic Load Balancing 会生成第二个 Cookie(即 AWSALBTGCORS),该 Cookie 中包含原始粘性 Cookie 中的信息加上此 SameSite 属性。客户端会同时收到这两个 Cookie。

例 带有一个目标组的转发操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作将请求转发到指定的目标组。

[ { "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 } ] } } ]
例 启用粘性的转发操作示例

如果您具有一个包含多个目标组的转发操作,并且一个或多个目标组已启用了粘性会话,则必须启用目标组粘性。

下面的操作将请求转发到两个指定的目标组,并启用了目标组粘性。对于不包含粘性 Cookie 的请求,将根据每个目标组的权重进行传输。

[ { "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 } } } ]

重定向操作

您可以使用 redirect 操作将客户端请求从一个 URL 重定向到另一个。根据需要,您可以将重定向配置为临时 (HTTP 302) 或永久 (HTTP 301)。

URI 包括以下组成部分:

protocol://hostname:port/path?query

您必须修改以下至少一个组成部分以避免重定向循环:协议、主机名、用户名、端口或路径。未修改的任何组成部分将保留其原始值。

协议

协议(HTTP 或 HTTPS)。您可以将 HTTP 重定向到 HTTP、将 HTTP 重定向到 HTTPS 以及将 HTTPS 重定向到 HTTPS。不能将 HTTPS 重定向到 HTTP。

hostname

主机名。主机名不区分大小写,长度最多为 128 个字符,由字母数字字符、通配符(* 和 ?)及连字符 (-) 组成。

port (远程调试端口)

端口(1 到 65535)。

path

绝对路径,以前导“/”开头。路径区分大小写,长度最多为 128 个字符,由字母数字字符、通配符(* 和 ?)、&(使用 &)及以下特殊字符组成:_-.$/~"'@:+。

查询

查询参数。最大长度为 128 个字符。

您可以通过以下保留关键字,在目标 URL 中重用原始 URL 的 URI 组成部分:

  • #{protocol} – 保留协议。在协议和查询组成部分中使用。

  • #{host} – 保留域。在主机名、路径和查询组成部分中使用。

  • #{port} – 保留端口。在端口、路径和查询组成部分中使用。

  • #{path} – 保留路径。在路径和查询组成部分中使用。

  • #{query} – 保留查询参数。在查询组成部分中使用。

执行 redirect 操作时,操作记录在访问日志中。有关更多信息,请参阅 访问日志条目。成功 redirect 操作的计数在 HTTP_Redirect_Count 指标中报告。有关更多信息,请参阅 Application Load Balancer 指标

例 使用控制台的重定向操作的示例

以下规则设置永久重定向到一个 URL,该 URL 使用 HTTPS 协议和指定的端口 (40443),但保留原始主机名、路径和查询参数。此屏幕等同于“https://#{host}:40443/#{path}?#{query}”。

将请求重定向到一个 URL 的规则,该 URL 使用 HTTPS 协议和指定的端口 (40443),但保留原始域、路径和原始 URL 的查询参数。

以下规则设置永久重定向到一个 URL,该 URL 包含原始协议、端口、主机名和查询参数,并使用 #{path} 关键字来创建修改的路径。此屏幕等同于“#{protocol}://#{host}:#{port}/new/#{path}?#{query}”。

将请求重定向到一个 URL 的规则,该 URL 包含原始协议、端口、主机名和查询参数,并使用 #{path} 关键字来创建修改的路径。
例 Amazon CLI 重定向操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作将 HTTP 请求重定向为端口 443 上的 HTTPS 请求,其主机名、路径和查询字符串与 HTTP 请求相同。

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

规则条件类型

以下是规则支持的条件类型:

host-header

基于每个请求的主机名进行路由。有关更多信息,请参阅 主机条件

http-header

基于每个请求的 HTTP 标头进行路由。有关更多信息,请参阅 HTTP 标头条件

http-request-method

基于每个请求的 HTTP 请求方法路由。有关更多信息,请参阅 HTTP 请求方法条件

path-pattern

基于请求 URL 中的路径模式进行路由。有关更多信息,请参阅 路径条件

query-string

基于查询字符串中的键/值对或值进行路由。有关更多信息,请参阅 查询字符串条件

source-ip

基于每个请求的源 IP 地址进行路由。有关更多信息,请参阅 源 IP 地址条件

每个规则可以有选择地最多包含以下条件之一:host-headerhttp-request-methodpath-patternsource-ip。每个规则还可以有选择地包含以下每个条件中的一个或多个:http-headerquery-string

您可以为每个条件指定最多三个匹配评估。例如,对于每个 http-header 条件,您最多可以指定三个字符串,以与请求中的 HTTP 标头的值进行比较。如果其中一个字符串与 HTTP 标头的值匹配,则满足条件。若要要求所有字符串都匹配,请为每个匹配评估创建一个条件。

您可以为每条规则指定最多五个匹配评估。例如,您可以创建一个具有五个条件的规则,其中每个条件都有一个匹配评估。

您可以在 http-headerhost-headerpath-patternquery-string 条件的匹配评估中包含通配符。每条规则的通配符上限为五个。

规则仅应用于可见的 ASCII 字符;不包括控制字符(0x00 到 0x1f 和 0x7f)。

有关演示,请参阅高级请求路由

HTTP 标头条件

您可以使用 HTTP 标头条件来配置基于请求的 HTTP 标头路由请求的规则。您可以指定标准或自定义 HTTP 标头字段的名称。标头名称和匹配评估不区分大小写。比较字符串支持以下通配符:*(匹配 0 个或多个字符)和 ?(完全匹配 1 个字符)。标头名称不支持通配符。

例 Amazon CLI HTTP 标头条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有与指定字符串之一匹配的 User-Agent 标头的请求满足以下条件。

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

HTTP 请求方法条件

您可以使用 HTTP 请求方法条件来配置基于请求的 HTTP 请求方法路由请求的规则。您可以指定标准或自定义 HTTP 方法。匹配评估区分大小写。不支持通配符;因此,方法名称必须完全匹配。

我们建议您以相同的方式路由 GET 和 HEAD 请求,因为这样可以缓存对 HEAD 请求的响应。

例 Amazon CLI HTTP 方法条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。使用指定方法的请求满足以下条件。

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

主机条件

您可以使用主机条件来定义基于主机标头中的主机名路由请求的规则(也称为基于主机的路由)。这使您能够使用单个负载均衡器支持多个子域和不同的顶级域。

主机名不区分大小写,长度上限为 128 个字符,并且可包含以下任何字符:

  • A-Z、a-z、0-9

  • - .

  • *(匹配 0 个或多个字符)

  • ?(完全匹配 1 个字符)

您必须包含至少一个“.”字符。在最后一个“.”字符之后只能包含字母数字字符。

主机名示例
  • example.com

  • test.example.com

  • *.example.com

规则 *.example.comtest.example.com 匹配,但与 example.com 不匹配。

例 Amazon CLI 主机标头条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有与指定字符串匹配的主机标头的请求满足以下条件。

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

路径条件

您可以使用路径条件来定义基于请求中的 URL 路由请求的规则(也称为基于路径的路由)。

路径模式仅应用于 URL 的路径,而不应用于其查询参数。它仅应用于可见的 ASCII 字符;不包括控制字符(0x00 到 0x1f 和 0x7f)。

仅当 URI 规范化之后才执行规则评估。

路径模式区分大小写,长度最多为 128 个字符,并且可包含以下任何字符。

  • A-Z、a-z、0-9

  • _ - . $ / ~ " ' @ : +

  • &(使用 &)

  • *(匹配 0 个或多个字符)

  • ?(完全匹配 1 个字符)

如果协议版本是 gRPC,则条件可特定于程序包、服务或方法。

示例 HTTP 路径模式
  • /img/*

  • /img/*/pics

示例 gRPC 路径模式
  • /package

  • /package.service/

  • /package.service/method

路径模式用于路由请求,而不是更改请求。例如,如果一个规则的路径模式为 /img/*,此规则会将 /img/picture.jpg 的请求作为 /img/picture.jpg 的请求转发给指定目标组。

例 Amazon CLI 路径模式条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有包含指定字符串的 URL 的请求满足以下条件。

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

查询字符串条件

您可以使用查询字符串条件来配置基于查询字符串中的键/值对或值路由请求的规则。匹配评估不区分大小写。支持以下通配符:*(匹配 0 个或多个字符)和 ?(完全匹配 1 个字符)。

例 Amazon CLI 查询字符串条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有包括键/值对“version=v1”或任意键设置为“example”的查询字符串的请求满足以下条件。

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

源 IP 地址条件

您可以使用源 IP 地址条件来配置基于请求的源 IP 地址路由请求的规则。必须以 CIDR 格式指定 IP 地址。可以使用 IPv4 和 IPv6 地址。不支持通配符。不能为源 IP 规则条件指定 255.255.255.255/32 CIDR。

如果客户端位于代理之后,则这是代理的 IP 地址,而不是客户端的 IP 地址。

X-Forwarded-For 标头中的地址不满足此条件。要搜索 X-Forwarded-For 标头中的地址,请使用 http-header 条件。

例 Amazon CLI 源 IP 条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。源 IP 地址位于某个指定的 CIDR 块中的请求满足以下条件。

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

HTTP 标头和 Application Load Balancer

HTTP 请求和 HTTP 响应使用标头字段发送有关 HTTP 消息的信息。HTTP 标头会自动添加。标头字段为冒号分隔的名称值对,各个值对之间由回车符 (CR) 和换行符 (LF) 进行分隔。RFC 2616 信息标头中定义了标准 HTTP 标头字段集。此外还有应用程序广泛使用和自动添加的非标准 HTTP 标头。某些非标准 HTTP 标头具有 X-Forwarded 前缀。Application Load Balancer 支持以下 X-Forwarded 标头。

有关 HTTP 连接的更多信息,请参阅 Elastic Load Balancing 用户指南中的请求路由

X-Forwarded-For

在您使用 HTTP 或 HTTPS 负载均衡器时,X-Forwarded-For 请求标头可帮助您识别客户端的 IP 地址。由于负载均衡器会拦截客户端和服务器之间的流量,因此您的服务器访问日志中将仅包含负载均衡器的 IP 地址。要查看客户端的 IP 地址,请使用 routing.http.xff_header_processing.mode 属性。借助此属性,您可以在应用程序负载均衡器将请求发送到目标之前修改、保留或移除 HTTP 请求中的 X-Forwarded-For 标头。此属性的可能值为 appendpreserveremove。此属性的默认值为 append

重要

由于存在安全风险,应谨慎使用 X-Forwarded-For 标头。只有由网络内得到妥善保护的系统添加的条目才被视为可信。

Append

默认情况下,应用程序负载均衡器会在 X-Forwarded-For 请求标头中存储客户端的 IP 地址,并将该标头传递到您的服务器。如果 X-Forwarded-For 请求标头未包含在原始请求中,则负载均衡器会创建一个以客户端 IP 地址作为请求值的标头。否则,负载均衡器会将客户端 IP 地址附加到现有标头,然后将该标头传递到您的服务器。X-Forwarded-For 请求标头可能包含多个以逗号分隔的 IP 地址。

X-Forwarded-For 请求标头采用以下形式:

X-Forwarded-For: client-ip-address

下面是 IP 地址为 203.0.113.7 的客户端的 X-Forwarded-For 请求标头的示例。

X-Forwarded-For: 203.0.113.7

下面是 IPv6 地址为 X-Forwarded-For 的客户端的 2001:DB8::21f:5bff:febf:ce22:8a2e 请求标头的示例。

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

在负载均衡器上启用客户端端口保留属性(routing.http.xff_client_port.enabled)后,X-Forwarded-For 请求标头包括附加到 client-ip-addressclient-port-number(以冒号分隔)。然后标头采用以下形式:

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

对于 IPv6,请注意,当负载均衡器将 client-ip-address 附加到现有标头时,会将地址放在方括号内。

下面是 IPv4 地址为 12.34.56.78、端口号为 8080 的客户端的 X-Forwarded-For 请求标头示例。

X-Forwarded-For: 12.34.56.78:8080

下面是 IPv6 地址为 2001:db8:85a3:8d3:1319:8a2e:370:7348、端口号为 8080 的客户端的 X-Forwarded-For 请求标头示例。

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

Preserve

属性中的 preserve 模式会确保在将 HTTP 请求发送到目标之前不会以任何方式进行修改其中的 X-Forwarded-For 标头。

删除

属性中的 remove 模式会在将 HTTP 请求发送到目标之前移除其中的 X-Forwarded-For 标头。

注意

如果您启用了客户端端口保留属性(routing.http.xff_client_port.enabled),同时还为 routing.http.xff_header_processing.mode 属性选择了 preserveremove,则应用程序负载均衡器将覆盖客户端端口保留属性。它会将 X-Forwarded-For 标头保留不变,或者根据您选择的模式将其移除,然后再将请求发送到目标。

当您选择 appendpreserve 或者 remove 模式时目标将收到的 X-Forwarded-For 标头示例见下表。在此例中,最后一跳的 IP 地址为 127.0.0.1

请求描述

示例请求

append 模式中的 XFF preserve 模式中的 XFF remove 模式中的 XFF
发送请求时没有 XFF 标头 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.1 不存在 不存在
发送请求时包含一个 XFF 标头和一个客户端 IP 地址。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4 X-Forwarded-For: 127.0.0.4, 127.0.0.1 X-Forwarded-For: 127.0.0.4 不存在
发送请求时包含一个 XFF 标头和多个客户端 IP 地址。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4, 127.0.0.8 X-Forwarded-For: 127.0.0.4, 127.0.0.8, 127.0.0.1 X-Forwarded-For: 127.0.0.4, 127.0.0.8 不存在
使用控制台修改、保留或移除 X-Forwarded-For 标头
  1. 通过以下网址打开 Amazon EC2 控制台:https://console.aws.amazon.com/ec2/

  2. 在导航窗格中,选择负载均衡器

  3. 选择负载均衡器。

  4. 属性选项卡上,选择编辑

  5. 流量配置部分的数据包处理下,对于 X-Forwarded-For 标头,选择附加(默认)、保留移除

  6. 选择 Save changes(保存更改)

使用 Amazon CLI 修改、保留或移除 X-Forwarded-For 标头

使用带 routing.http.xff_header_processing.mode 属性的 modify-load-balancer-attributes 命令。

X-Forwarded-Proto

X-Forwarded-Proto 请求标头可帮助您识别客户端与您的负载均衡器连接时所用的协议 (HTTP 或 HTTPS)。您的服务器访问日志仅包含在服务器和负载均衡器之间使用的协议;不含任何关于在客户端和负载均衡器之间使用的协议之信息。如需判断在客户端和负载均衡器之间使用的协议,使用 X-Forwarded-Proto 请求标题。Elastic Load Balancing 会在 X-Forwarded-Proto 请求标头中存储客户端和负载均衡器之间使用的协议,并将标头传递到您的服务器。

您的应用程序或网站可以使用存储在 X-Forwarded-Proto 请求标头中的协议来呈现重新定向至适用 URL 的响应。

X-Forwarded-Proto 请求标头采用以下形式:

X-Forwarded-Proto: originatingProtocol

以下示例包含以 HTTPS 请求形式源自客户端的请求的 X-Forwarded-Proto 请求标头:

X-Forwarded-Proto: https

X-Forwarded-Port

X-Forwarded-Port 请求标头可帮助您识别客户端与您的负载均衡器连接时所用的目标端口。