Application Load Balancer를 위한 리스너

리스너는 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스입니다. Application Load Balancer를 사용하기 전에 리스너를 최소 하나 이상 추가해야 합니다. 로드 밸런서에 리스너가 없는 경우 클라이언트로부터 트래픽을 수신할 수 없습니다. 리스너에 대해 정의하는 규칙에 따라 로드 밸런서가 등록한 대상 (예: 인스턴스) 으로 EC2 요청을 라우팅하는 방식이 결정됩니다.

리스너 구성

리스너는 다음과 같은 프로토콜 및 포트를 지원합니다.

HTTPS리스너를 사용하여 암호화 및 복호화 작업을 로드 밸런서에 오프로드하여 애플리케이션이 비즈니스 로직에 집중할 수 있도록 할 수 있습니다. 리스너 프로토콜이 HTTPS 인 경우 리스너에 하나 SSL 이상의 서버 인증서를 배포해야 합니다. 자세한 내용은 애플리케이션 로드 밸런서용 HTTPS 리스너 생성 단원을 참조하십시오.

대상이 로드 밸런서 대신 HTTPS 트래픽을 해독하도록 해야 하는 경우 포트 443에 리스너가 있는 TCP Network Load Balancer를 생성할 수 있습니다. TCP리스너를 사용하면 로드 밸런서가 암호화된 트래픽을 암호 해독하지 않고 대상으로 전달합니다. Network Load Balancer에 대한 자세한 정보는 Network Load Balancer 사용 설명서를 참조하세요.

애플리케이션 로드 밸런서는 다음을 기본적으로 지원합니다. WebSockets 연결 업그레이드를 사용하여 기존 HTTP HTTP /1.1 연결을 WebSocket (ws또는wss) 연결로 업그레이드할 수 있습니다. 업그레이드하면 요청에 사용되는 TCP 연결 (로드 밸런서와 대상 연결) 이 로드 밸런서를 통한 클라이언트와 대상 간의 영구 WebSocket 연결이 됩니다. 및 리스너 WebSockets HTTP 모두와 HTTPS 함께 사용할 수 있습니다. 리스너에 대해 선택한 옵션은 트래픽뿐만 아니라 WebSocket 연결에도 적용됩니다. HTTP 자세한 내용은 Amazon CloudFront 개발자 안내서의 WebSocket 프로토콜 작동 방식을 참조하십시오.

애플리케이션 로드 밸런서는 리스너를 포함한 HTTP /2에 대한 기본 지원을 제공합니다. HTTPS 하나의 HTTP /2 연결을 사용하여 최대 128개의 요청을 병렬로 보낼 수 있습니다. 프로토콜 버전을 사용하면 /2를 사용하여 HTTP 대상에 요청을 보낼 수 있습니다. 자세한 내용은 프로토콜 버전 단원을 참조하십시오. HTTP/2는 프런트 엔드 연결을 더 효율적으로 사용하므로 클라이언트와 로드 밸런서 간의 연결 수가 줄어들 수 있습니다. /2의 서버 푸시 기능은 사용할 수 없습니다. HTTP

자세한 내용은 Elastic Load Balancing 사용 설명서의 라우팅 요청을 참조하세요.

리스너 규칙

모든 리스너에는 기본 동작이 있으며, 이를 기본 규칙이라고도 합니다. 기본 규칙은 삭제할 수 없으며 항상 마지막에 수행됩니다. 추가 규칙을 생성할 수 있으며 추가 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성됩니다. 언제든 규칙을 추가하거나 편집할 수 있습니다. 자세한 내용은 규칙 편집 단원을 참조하세요.

기본 규칙

리스너를 생성할 때 기본 규칙에 대한 작업을 정의합니다. 기본 규칙은 조건을 가질 수 없습니다. 리스너의 규칙에 대한 조건이 충족되지 않으면 기본 규칙에 대해 작업이 수행됩니다.

다음은 콘솔에 나타난 기본 규칙을 보여줍니다.

규칙 우선 순위

각 규칙마다 우선 순위가 있습니다. 규칙은 가장 낮은 값에서 가장 높은 값에 이르기까지 우선 순위에 따라 평가됩니다. 기본 규칙은 마지막에 평가됩니다. 기본이 아닌 규칙의 우선 순위는 언제든지 변경이 가능합니다. 기본 규칙의 우선 순위는 변경할 수 없습니다. 자세한 내용은 규칙 우선 순위 업데이트 단원을 참조하세요.

규칙 작업

각 규칙 작업에는 작업을 수행하는 데 필요한 유형, 우선 순위 및 정보가 있습니다. 자세한 내용은 규칙 작업 유형 단원을 참조하십시오.

규칙 조건

각 규칙 조건에는 유형과 구성 정보가 있습니다. 규칙에 대한 조건이 충족되면 작업이 수행됩니다. 자세한 내용은 규칙 조건 형식 단원을 참조하세요.

규칙 작업 유형

리스너 규칙에 대해 지원되는 작업 유형은 다음과 같습니다.

가장 낮은 우선 순위가 있는 작업이 첫 번째로 수행됩니다. 각 규칙에는 forward, redirect 또는 fixed-response 작업 중 하나가 꼭 포함되어 있어야 하며, 이 작업이 수행할 마지막 작업이어야 합니다.

프로토콜 버전이 g RPC 또는 HTTP /2인 경우 지원되는 작업은 forward 액션뿐입니다.

고정 응답 작업

fixed-response작업을 사용하여 클라이언트 요청을 삭제하고 사용자 지정 HTTP 응답을 반환할 수 있습니다. 이 작업을 사용하여 2XX, 4XX, 5XX 응답 코드와 선택적 메시지를 반환할 수 있습니다.

fixed-response작업이 수행되면 해당 작업과 리디렉션 대상의 작업이 액세스 로그에 기록됩니다. URL 자세한 내용은 액세스 로그 항목 단원을 참조하십시오. 성공한 fixed-response 작업의 개수는 HTTP_Fixed_Response_Count 지표에 보고됩니다. 자세한 내용은 Application Load Balancer 지표 단원을 참조하십시오.

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

전달 작업

forward 작업을 사용하여 하나 이상의 대상 그룹에 요청을 라우팅할 수 있습니다. forward 작업에 대해 여러 대상 그룹을 지정하는 경우 각 대상 그룹에 대해 가중치를 지정해야 합니다. 각 대상 그룹 가중치는 0과 999 사이의 값입니다. 가중 대상 그룹이 있는 리스너 규칙과 일치하는 요청은 가중치를 기준으로 이러한 대상 그룹에 배포됩니다. 예를 들어, 각각 가중치가 10인 두 개의 대상 그룹을 지정하면 각 대상 그룹은 요청을 절반씩 받습니다. 가중치가 10인 대상 그룹과 가중치가 20인 대상 그룹 두 개를 지정하면 가중치가 20인 대상 그룹이 다른 대상 그룹보다 두 배 많은 요청을 받습니다.

기본적으로 가중 대상 그룹 간에 트래픽을 배포하도록 규칙을 구성한다고 해서 고정 세션이 반드시 적용되는 것은 아닙니다. 고정 세션이 적용되도록 하려면 규칙에 대해 대상 그룹 고정을 활성화합니다. 로드 밸런서가 먼저 가중치 기반 대상 그룹으로 요청을 라우팅하면 선택한 대상 그룹에 대한 정보를 인코딩하고 쿠키를 암호화한 다음 클라이언트에 대한 응답에 쿠키를 AWSALBTG 포함하는 이름이 지정된 쿠키를 생성합니다. 클라이언트는 로드 밸런서에 대한 후속 요청에서 수신하는 쿠키를 포함해야 합니다. 로드 밸런서가 대상 그룹 고정 기능이 활성화된 규칙과 일치하고 쿠키를 포함하는 요청을 받으면 요청이 쿠키에 지정된 대상 그룹으로 라우팅됩니다.

애플리케이션 로드 밸런서는 인코딩된 쿠키 값을 지원하지 않습니다. URL

CORS(출처 간 리소스 공유) 요청의 경우 일부 브라우저에서는 고정성을 SameSite=None; Secure 활성화해야 합니다. 이 경우 Elastic Load Balancing은 두 번째 쿠키를 생성하는데 AWSALBTGCORS, 이 쿠키에는 원래 고정성 쿠키와 동일한 정보에 이 SameSite 속성을 더한 정보가 포함됩니다. 클라이언트는 두 쿠키를 모두 수신합니다.

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

리디렉션 작업

redirect작업을 사용하여 클라이언트 요청을 다른 URL 요청으로 리디렉션할 수 있습니다. 필요에 따라 리디렉션을 임시 (HTTP302) 또는 영구 (HTTP301) 으로 구성할 수 있습니다.

A는 URI 다음과 같은 구성 요소로 구성되어 있습니다.

protocol://hostname:port/path?query

리디렉션 루프를 피하기 위해 프로토콜, 호스트 이름 포트, 경로 중 최소 하나를 수정해야 합니다. 수정하지 않은 구성 요소는 원래 값을 유지합니다.

다음과 같은 예약된 URL 키워드를 사용하여 URL 타겟에서 원본의 URI 구성 요소를 재사용할 수 있습니다.

redirect작업이 수행되면 액세스 로그에 작업이 기록됩니다. 자세한 내용은 액세스 로그 항목 단원을 참조하세요. 성공한 redirect 작업의 개수는 HTTP_Redirect_Count 지표에 보고됩니다. 자세한 내용은 Application Load Balancer 지표 단원을 참조하세요.

예 콘솔을 사용한 리디렉션 작업 예

다음 규칙은 HTTPS 프로토콜과 지정된 포트 (40443) 를 사용하지만 원래 호스트 이름, 경로 및 쿼리 매개 변수는 유지하는 URL a로의 영구 리디렉션을 설정합니다. 이 화면은 "https://#{host}:40443/#{path}?#{query}"와 동일합니다.

다음 규칙은 원래 프로토콜, 포트, 호스트 이름 및 쿼리 매개 변수를 유지하는 URL a로의 영구 리디렉션을 설정하고 키워드를 사용하여 수정된 경로를 생성합니다. #{path} 이 화면은 "#{protocol}://#{host}:#{port}/new/#{path}?#{query}"와 동일합니다.

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

규칙 조건 형식

규칙에 대해 지원되는 조건 형식은 다음과 같습니다.

각 규칙에는 선택적으로 host-header, http-request-method, path-pattern 및 source-ip 조건 중 하나 이상을 포함할 수 있습니다. 또한 각 규칙에는 선택적으로 http-header 및 query-string 조건 중 하나 이상을 포함할 수 있습니다.

조건당 최대 3개의 일치 평가를 지정할 수 있습니다. 예를 들어 각 http-header 조건에 대해 요청의 HTTP 헤더 값과 비교할 문자열을 최대 3개까지 지정할 수 있습니다. 문자열 중 하나가 HTTP 헤더 값과 일치하면 조건이 충족됩니다. 모든 문자열이 일치하도록 요구하려면 일치 평가마다 조건 하나를 만듭니다.

규칙당 최대 5개의 일치 평가를 지정할 수 있습니다. 예를 들어 조건 5개 각각에 일치 평가가 하나씩 있는 규칙을 만들 수 있습니다.

http-header, host-header, path-pattern, query-string 조건의 일치 평가에 와일드카드 문자를 포함시킬 수 있습니다. 규칙당 와일드카드 문자는 5개로 제한됩니다.

규칙은 보이는 ASCII 문자에만 적용되며 제어 문자 (0x00 ~ 0x1f 및 0x7f) 는 제외됩니다.

데모는 고급 요청 라우팅을 참조하세요.

HTTP헤더 조건

HTTP헤더 조건을 사용하여 요청 HTTP 헤더를 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. 표준 또는 사용자 지정 HTTP 헤더 필드의 이름을 지정할 수 있습니다. 헤더 이름과 일치 평가는 대/소문자를 구분하지 않습니다. 비교 문자열에서는 *(0개 이상의 문자 일치) 및 ?(정확히 1자 일치) 와일드카드 문자가 지원됩니다. 와일드카드 문자는 헤더 이름에서는 지원되지 않습니다.

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

HTTP요청 메서드 조건

HTTP요청 방법 조건을 사용하여 요청의 요청 방법을 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. HTTP 표준 또는 사용자 지정 HTTP 방법을 지정할 수 있습니다. 일치 평가는 대/소문자를 구분합니다. 와일드카드 문자는 지원되지 않으므로 메서드 이름이 정확히 일치해야 합니다.

요청에 대한 응답이 캐시될 수 있으므로 GET HEAD 요청과 요청을 같은 방식으로 라우팅하는 것이 좋습니다. HEAD

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

호스트 조건

호스트 조건을 사용하여 호스트 헤더의 호스트 이름을 기반으로 요청을 라우팅하는 규칙을 정의할 수 있습니다(호스트 기반 라우팅이라고도 함). 그러면 단일 로드 밸런서를 사용하여 여러 하위 도메인과 여러 최상위 도메인을 지원할 수 있습니다.

호스트 이름은 대/소문자를 구별하지 않고 최대 128자까지 가능하며 다음과 같은 문자를 포함할 수 있습니다.

'.' 문자를 하나 이상 포함해야 합니다. 마지막 "." 문자 다음에는 알파벳만 포함할 수 있습니다.

규칙 *.example.com은 test.example.com과 일치하나 example.com과 일치하지 않습니다.

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

경로 조건

경로 조건을 사용하여 요청의 내용을 기반으로 요청을 라우팅하는 규칙 (경로 기반 라우팅이라고도 함) 을 정의할 수 있습니다. URL

경로 패턴은 의 경로에만 적용되고 쿼리 매개 변수에는 적용되지 않습니다. URL 보이는 ASCII 문자에만 적용되며 제어 문자 (0x00 ~ 0x1f 및 0x7f) 는 제외됩니다.

규칙 평가는 정규화가 수행된 후에만 수행됩니다. URI

경로 패턴은 대/소문자를 구별하고 최대 128자이며 다음과 같은 문자를 포함할 수 있습니다.

프로토콜 버전이 g인 경우 조건은 패키지RPC, 서비스 또는 메서드별로 다를 수 있습니다.

경로 패턴은 요청을 라우팅하는 데 사용되지만 요청을 변경하지 않습니다. 예를 들어 /img/*(이)라는 경로 패턴을 가진 규칙은 /img/picture.jpg에 대한 요청을 /img/picture.jpg에 대한 요청으로서 지정된 대상 그룹에 전달합니다.

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

쿼리 문자열 조건

쿼리 문자열 조건을 사용하여 쿼리 문자열의 키/값 페어 또는 값을 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. 일치 평가는 대/소문자를 구분하지 않습니다. *(0개 이상의 문자 일치) 및 ?(정확히 1자 일치) 와일드카드 문자가 지원됩니다.

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

소스 IP 주소 조건

소스 IP 주소 조건을 사용하여 요청의 소스 IP 주소를 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. IP 주소는 CIDR 형식으로 지정해야 합니다. IPv4및 IPv6 주소를 모두 사용할 수 있습니다. 와일드카드 문자는 지원되지 않습니다. 소스 IP 규칙 조건에는 255.255.255.255/32 CIDR 를 지정할 수 없습니다.

클라이언트가 프록시 뒤에 있는 경우, 이는 클라이언트의 IP 주소가 아니라 프록시의 IP 주소입니다.

이 조건은 X-Forwarded-For 헤더의 주소에 의해 충족되지 않습니다. X-Forwarded-For 헤더에서 주소를 검색하려면 http-header 조건을 사용합니다.

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

HTTP헤더 및 애플리케이션 로드 밸런서

HTTP요청 및 HTTP 응답은 헤더 필드를 사용하여 메시지에 대한 정보를 전송합니다HTTP. HTTP헤더는 자동으로 추가됩니다. 헤더 필드는 콜론으로 구분된 이름-값 페어이며 CR(캐리지 리턴) 및 LF(줄 바꿈)로 구분됩니다. 표준 HTTP 헤더 필드 세트는 RFC 2616, 메시지 헤더에 정의되어 있습니다. 응용 프로그램에서 자동으로 추가되고 널리 사용되는 비표준 HTTP 헤더도 있습니다. 일부 비표준 HTTP 헤더에는 접두사가 있습니다. X-Forwarded Application Load Balancer는 다음 X-Forwarded 헤더를 지원합니다.

HTTP연결에 대한 자세한 내용은 Elastic Load Balancing 사용 설명서의 요청 라우팅을 참조하십시오.

X-Forwarded-For

X-Forwarded-For요청 헤더는 HTTP OR HTTPS 로드 밸런서를 사용할 때 클라이언트의 IP 주소를 식별하는 데 도움이 됩니다. 로드 밸런서가 클라이언트와 서버 간의 트래픽을 가로채기 때문에 서버 액세스 로그에 로드 밸런서의 IP 주소만 포함됩니다. 클라이언트의 IP 주소를 확인하려면 routing.http.xff_header_processing.mode 속성을 사용하십시오. 이 속성을 사용하면 Application Load Balancer가 대상으로 HTTP 요청을 보내기 전에 요청의 X-Forwarded-For 헤더를 수정, 보존 또는 제거할 수 있습니다. 이 속성에 사용 가능한 값은 append, preserve 및 remove입니다. 이 속성의 기본값은 append입니다.

Append

기본적으로, Application Load Balancer는 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-address에 추가되는 client-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 주소가 이고 포트 번호가 인 클라이언트의 X-Forwarded-For 요청 헤더 예제입니다. 12.34.56.78 8080

X-Forwarded-For: 12.34.56.78:8080

다음은 IPv6 주소가 이고 포트 번호가 인 클라이언트에 대한 예제 X-Forwarded-For 요청 8080 헤더입니다. 2001:db8:85a3:8d3:1319:8a2e:370:7348

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

Preserve

속성의 preserve 모드는 HTTP 요청의 X-Forwarded-For 헤더가 대상으로 전송되기 전에 어떤 식으로든 수정되지 않도록 합니다.

Remove

속성의 remove 모드는 HTTP 요청이 대상으로 전송되기 전에 요청의 X-Forwarded-For 헤더를 제거합니다.

다음 표에 append, preserve, 또는 remove 모드 중 하나를 선택할 때 대상이 받는 X-Forwarded-For 헤더의 예제가 나와 있습니다. 이 예제에서 마지막 홉의 IP 주소는 127.0.0.1입니다.

를 사용하여 X-Forwarded-For 헤더를 수정, 보존 또는 제거하려면 AWS CLI

modify-load-balancer-attributes명령을 routing.http.xff_header_processing.mode 속성과 함께 사용합니다.

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

다음 예제에는 클라이언트에서 X-Forwarded-Proto 요청으로 시작된 요청에 대한 요청 헤더가 포함되어 있습니다. HTTPS

X-Forwarded-Proto: https

X-Forwarded-Port

X-Forwarded-Port 요청 헤더는 클라이언트가 로드 밸런서 연결에 사용한 대상 포트를 식별하는 데 도움을 줍니다.