# CloudFront의 오류 응답 상태 코드 문제 해결
CloudFront가 오리진에 객체를 요청했는데 오리진에서 HTTP 4xx 또는 5xx 상태 코드를 반환하는 경우, CloudFront와 오리진 사이에 통신 문제가 있는 것입니다.
이 주제에는 Lambda@Edge 또는 CloudFront Functions를 사용할 때 이러한 상태 코드에 대한 문제 해결 단계도 포함되어 있습니다.
다음 주제에서는 이러한 오류 응답의 이면에 있는 잠재적 원인을 자세히 설명하고 근본적인 문제를 진단하고 해결하는 방법에 대한 단계별 지침을 제공합니다.
**Topics**
+ [HTTP 400 상태 코드(잘못된 요청)](http-400-bad-request.md)
+ [HTTP 401 상태 코드(승인되지 않음)](http-401-unauthorized.md)
+ [HTTP 403 상태 코드(잘못된 메서드)](http-403-invalid-method.md)
+ [HTTP 403 상태 코드(권한 거부됨)](http-403-permission-denied.md)
+ [HTTP 404 상태 코드(찾을 수 없음)](http-404-not-found.md)
+ [HTTP 412 상태 코드(사전 조건 실패)](http-412-precondition-failed.md)
+ [HTTP 500 상태 코드(내부 서버 오류)](http-500-internal-server-error.md)
+ [HTTP 502 상태 코드(잘못된 게이트웨이)](http-502-bad-gateway.md)
+ [HTTP 503 상태 코드(Service Unavailable)](http-503-service-unavailable.md)
+ [HTTP 504 상태 코드(게이트웨이 제한 시간)](http-504-gateway-timeout.md)
# HTTP 400 상태 코드(잘못된 요청)
CloudFront는 클라이언트가 요청에서 일부 유효하지 않은 데이터(예: 페이로드 또는 파라미터의 누락되거나 잘못된 콘텐츠)를 전송할 때 400 잘못된 요청을 반환합니다. 이는 일반적인 클라이언트 오류일 수도 있습니다.
## Amazon S3 오리진에서 400 오류를 반환함
CloudFront 배포와 함께 Amazon S3 오리진을 사용하는 경우, 배포가 HTTP 상태 코드 400 잘못된 요청 및 다음과 유사한 메시지와 함께 오류 응답을 보낼 수 있습니다.
*권한 부여 헤더 형식이 잘못되었습니다. 리전 '**'이 잘못되었습니다. '**'이어야 합니다.*
예:
*권한 부여 헤더 형식이 잘못되었습니다. 리전 'us-east-1'이 잘못되었습니다. 'us-west-2'여야 합니다.*
다음과 같은 시나리오에서 이 문제가 발생할 수 있습니다.
1. CloudFront 배포의 오리진은 Amazon S3 버킷입니다.
1. S3 버킷을 특정 AWS 리전에서 다른 리전으로 이전했습니다. 즉, S3 버킷을 삭제한 후 나중에 동일한 버킷 이름을 가진 새 버킷을 만들었지만 원래 S3 버킷이 있던 AWS 리전과 다릅니다.
이 오류를 수정하려면 버킷의 현재 AWS 리전에서 S3 버킷을 찾도록 CloudFront 배포를 업데이트하세요.
**CloudFront 배포를 업데이트하려면**
1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.
1. 이 오류를 일으키는 배포를 선택합니다.
1. **Origins and Origin Groups(오리진 및 오리진 그룹)**를 선택합니다.
1. 이동한 S3 버킷의 오리진을 찾습니다. 이 오리진 옆의 확인란을 선택한 후 **편집**을 선택합니다.
1. **예, 편집합니다**를 선택합니다. **Yes, Edit(예, 편집합니다.)**을 선택하기 전 설정을 변경할 필요가 없습니다.
이 단계를 끝내면 CloudFront가 배포를 다시 배포합니다. 배포가 진행되는 동안 **마지막 수정일** 열 아래에 **배포 중** 상태가 표시됩니다. 배포가 완료된 후 일정 시간이 지나면 `AuthorizationHeaderMalformed` 오류 응답을 더 이상 받지 않아야 합니다.
## Application Load Balancer 오리진이 400 오류를 반환함
Application Load Balancer 오리진을 CloudFront 배포와 함께 사용하는 경우, 400 오류의 가능한 원인은 다음과 같습니다.
+ 클라이언트가 HTTP 사양을 충족하지 않는 잘못된 형식의 요청을 전송했습니다.
+ 요청 헤더가 요청 줄당 16K, 단일 헤더당 16K 또는 전체 요청 헤더에서 64K를 초과했습니다.
+ 클라이언트가 전체 요청 본문을 보내기 전에 연결을 종료했습니다.
# HTTP 401 상태 코드(승인되지 않음)
401 승인되지 않음 응답 상태 코드는 요청된 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 클라이언트 요청이 완료되지 않았음을 나타냅니다. 이 상태 코드는 클라이언트가 사용자에게 인증 자격 증명을 요청한 후 리소스를 다시 요청할 수 있는 방법에 대한 정보가 포함된 HTTP `WWW-Authenticate` 응답 헤더와 함께 전송됩니다. 자세한 내용은 [401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401)를 참조하세요.
CloudFront에서 오리진이 요청을 인증하기 위한 `Authorization` 헤더를 기대하는 경우 CloudFront는 `Authorization` 헤더를 오리진에 전달해야 401 승인되지 않음 오류가 발생하지 않습니다. CloudFront에서 최종 사용자 요청을 오리진에 전달할 때 `Authorization` 헤더를 포함한 일부 최종 사용자 헤더는 기본적으로 제거됩니다. 오리진 요청의 `Authorization` 헤더가 오리진에 항상 수신되도록 하려면 다음 옵션을 선택할 수 있습니다.
+ 캐시 정책을 사용하여 캐시 키에 `Authorization` 헤더를 추가합니다. 캐시 키의 모든 헤더가 오리진 요청에 자동으로 포함됩니다. 자세한 내용은 [정책으로 캐시 키 제어](controlling-the-cache-key.md) 섹션을 참조하세요.
+ 모든 최종 사용자 헤더를 오리진으로 전달하는 오리진 요청 정책을 사용합니다. 오리진 요청 정책에서 `Authorization` 헤더를 개별적으로 전달할 수는 없지만 모든 뷰어 헤더를 전달하면 CloudFront에서 뷰어 요청에 `Authorization` 헤더를 포함합니다. CloudFront는 이 사용 사례에 `AllViewer` 관리형 오리진 요청 정책을 제공합니다. 자세한 내용은 [관리형 오리진 요청 정책 사용](using-managed-origin-request-policies.md) 섹션을 참조하세요.
자세한 내용은 [권한 부여 헤더를 오리진에 전달하도록 CloudFront를 구성하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/cloudfront-authorization-header)를 참조하세요.
# HTTP 403 상태 코드(잘못된 메서드)
CloudFront 배포에서 지정하지 않은 HTTP 메서드를 사용하려고 하면 CloudFront는 403(잘못된 메서드) 오류를 반환합니다. 배포에 대해 다음 옵션 중 하나를 지정할 수 있습니다.
+ CloudFront가 `GET` 및 `HEAD` 요청만 전달합니다.
+ CloudFront가 `GET`, `HEAD`, `OPTIONS` 요청만 전달합니다.
+ CloudFront가 `GET`, `HEAD`, `OPTIONS`, `PUT`, `PATCH`, `POST`, `DELETE` 요청을 전달합니다. 이 옵션을 선택할 경우, 허용하지 않을 작업을 사용자가 수행하지 못하도록 Amazon S3 버킷 또는 사용자 지정 오리진에 대한 액세스를 제한해야 할 수 있습니다. 예를 들어, 사용자가 오리진에서 객체를 삭제할 수 있는 권한을 사용자에게 허용하지 않을 수 있습니다.
# HTTP 403 상태 코드(권한 거부됨)
HTTP 403 오류는 클라이언트가 요청된 리소스에 액세스할 권한이 없음을 의미합니다. 클라이언트는 요청을 이해하지만 뷰어 액세스를 승인할 수는 없습니다. 다음은 CloudFront에서 이 상태 코드를 반환하는 일반적인 원인입니다.
**Topics**
+ [대체 CNAME이 잘못 구성됨](#alternate-cname-incorrectly-configured)
+ [AWS WAF가 CloudFront 배포 또는 오리진에서 구성됨](#aws-waf-configured-on-distribution-origin)
+ [사용자 지정 오리진이 403 오류를 반환함](#custom-origin-returning-403)
+ [Amazon S3 오리진에서 403 오류를 반환함](#s3-origin-403-error)
+ [지리적 제한으로 인해 403 오류가 반환됨](#geolocation-403)
+ [서명된 URL 또는 서명된 쿠키 구성이 403 오류를 반환함](#signed-URLs-cookies-403)
+ [누적 배포로 인해 403 오류가 발생함](#stacked-distributions-403)
## 대체 CNAME이 잘못 구성됨
배포에 올바른 CNAME을 지정했는지 확인하세요. 기본 CloudFront URL 대신 대체 CNAME을 사용하려면 다음 단계를 따르세요.
1. DNS에 CNAME 레코드를 생성하여 CNAME이 CloudFront 배포 URL을 가리키도록 합니다.
1. CloudFront 배포 구성에 CNAME을 추가합니다.
DNS 레코드를 생성하지만 CloudFront 배포 구성에 CNAME을 추가하지 않는 경우 요청은 403 오류를 반환합니다. 고객 CNAME 구성에 대한 자세한 정보는 [대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용](CNAMEs.md) 섹션을 참조하세요.
## AWS WAF가 CloudFront 배포 또는 오리진에서 구성됨
AWS WAF가 클라이언트와 CloudFront 사이에 위치하는 경우, 오리진에서 반환하는 403 오류 코드와 요청이 차단될 때 AWS WAF에서 반환하는 403 오류 코드를 구별할 수 없습니다.
403 상태 코드의 출처를 찾으려면 AWS WAF 웹 액세스 제어 목록(ACL) 규칙에서 차단된 요청을 확인하세요. 자세한 내용은 다음 항목을 참조하세요.
+ [AWS WAF 웹 액세스 제어 목록(웹 ACL)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [AWS WAF 보호 기능 테스트 및 튜닝](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## 사용자 지정 오리진이 403 오류를 반환함
사용자 지정 오리진을 사용하는 경우 오리진에 사용자 지정 방화벽을 구성하면 403 오류가 표시될 수 있습니다. 문제를 해결하려면 오리진에 직접 요청하세요. CloudFront 없이 오류를 재현할 수 있다면 오리진에서 403 오류가 발생하는 것입니다.
사용자 지정 오리진으로 인해 오류가 발생한 경우 오리진 로그를 확인하여 오류의 원인을 파악하세요. 자세한 내용은 다음 문제 해결 주제를 참조하세요.
+ [API Gateway의 HTTP 403 오류를 해결하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Application Load Balancer HTTP 403 금지됨 오류 문제는 어떻게 해결하나요?](https://repost.aws/knowledge-center/alb-http-403-error)
## Amazon S3 오리진에서 403 오류를 반환함
다음과 같은 이유로 403 오류가 발생할 수 있습니다.
+ CloudFront에 Amazon S3 버킷에 대한 액세스 권한이 없습니다. 배포에 오리진 액세스 ID(OAI) 또는 오리진 액세스 제어(OAC)가 활성화되지 않았고 버킷이 프라이빗인 경우 이런 상황이 발생할 수 있습니다.
+ 요청된 URL의 지정된 경로가 올바르지 않습니다.
+ 요청된 객체가 존재하지 않습니다.
+ 호스트 헤더가 REST API 엔드포인트와 함께 전달되었습니다. 자세한 내용은 **Amazon Simple Storage Service 사용 설명서의 [HTTP Host header bucket specification](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket)을 참조하세요.
+ 사용자 지정 오류 페이지를 구성했습니다. 자세한 내용은 [사용자 지정 오류 페이지를 구성했을 때 CloudFront에서 오류를 처리하는 방법](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages) 섹션을 참조하세요.
## 지리적 제한으로 인해 403 오류가 반환됨
특정 지리적 위치에 있는 사용자가 CloudFront 배포를 통해 배포한 콘텐츠에 액세스하는 것을 차단하기 위해 지리적 차단이라고도 하는 지리적 제한을 활성화한 경우, 차단된 사용자에게 403 오류가 발생합니다.
자세한 내용은 [콘텐츠의 지리적 배포 제한](georestrictions.md) 섹션을 참조하세요.
## 서명된 URL 또는 서명된 쿠키 구성이 403 오류를 반환함
배포의 동작 구성에 대해 **뷰어 액세스 제한**을 활성화한 경우, 서명된 쿠키 또는 서명된 URL을 사용하지 않는 요청에 대해 403 오류가 발생합니다. 자세한 내용은 다음 항목을 참조하세요.
+ [서명된 URL과 서명된 쿠키를 사용하여 프라이빗 콘텐츠 제공](PrivateContent.md)
+ [CloudFront의 서명된 URL 또는 서명된 쿠키와 관련된 문제를 해결하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## 누적 배포로 인해 403 오류가 발생함
오리진 엔드포인트에 대한 요청 체인 내에 두 개 이상의 배포가 있는 경우 CloudFront는 403 오류를 반환합니다. 한 배포를 다른 배포 앞에 배치하지 않는 것이 좋습니다.
# HTTP 404 상태 코드(찾을 수 없음)
클라이언트가 존재하지 않는 리소스에 액세스를 시도하면 CloudFront는 404(찾을 수 없음) 오류를 반환합니다. CloudFront 배포에서 이 오류가 발생하는 경우 일반적인 원인은 다음과 같습니다.
+ 리소스가 존재하지 않습니다.
+ URL이 올바르지 않습니다.
+ 사용자 지정 오리진이 404를 반환합니다.
+ 사용자 지정 오류 페이지가 404를 반환합니다. (어떤 오류 코드든 404로 변환될 수 있습니다.) 자세한 내용은 [사용자 지정 오류 페이지를 구성했을 때 CloudFront에서 오류를 처리하는 방법](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages) 섹션을 참조하세요.
+ 사용자 지정 오류 페이지가 실수로 삭제되어 요청이 삭제된 사용자 지정 오류 페이지를 찾기 때문에 404가 발생합니다. 자세한 내용은 [사용자 지정 오류 페이지를 구성하지 않은 경우 CloudFront에서 오류를 처리하는 방법](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages) 섹션을 참조하세요.
+ 오리진 경로가 잘못되었습니다. 오리진 경로를 입력하면 요청이 오리진에 전달되기 전에 브라우저의 각 요청 경로에 오리진 값이 추가됩니다. 자세한 내용은 [오리진 경로](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath) 섹션을 참조하세요.
# HTTP 412 상태 코드(사전 조건 실패)
대상 리소스에 대한 액세스가 거부되면 CloudFront는 412(사전 조건 실패) 오류 코드를 반환합니다. 경우에 따라 서버는 특정 조건이 충족된 후에만 요청을 수락하도록 구성되어 있습니다. 지정된 조건 중 하나라도 충족되지 않으면 서버는 클라이언트가 지정된 리소스에 액세스하는 것을 허용하지 않습니다. 대신 서버는 412 오류 코드로 응답합니다.
CloudFront에서 발생하는 412 오류의 일반적인 원인은 다음과 같습니다.
+ `If-Unmodified-Since` 또는 `If-None-Match` 헤더로 정의된 조건이 충족되지 않을 때 `GET` 또는 `HEAD` 외 다른 메서드에 대한 조건부 요청. 이 경우 요청(일반적으로 리소스 업로드 또는 수정)을 수행할 수 없습니다.
+ CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) API 작업의 요청 필드 중 하나 이상에 있는 조건이 거짓으로 평가됨
# HTTP 500 상태 코드(내부 서버 오류)
HTTP 500 상태 코드(내부 서버 오류)는 서버가 요청을 이행하지 못하게 하는 예기치 않은 상황이 발생했음을 나타냅니다. Amazon CloudFront에서 500 오류가 발생하는 일반적인 원인은 다음과 같습니다.
**Topics**
+ [오리진 서버가 CloudFront에 500 오류를 반환함](#origin-server-500-error)
## 오리진 서버가 CloudFront에 500 오류를 반환함
오리진 서버가 CloudFront에 500 오류를 반환하고 있을 수 있습니다. 자세한 내용은 다음 문제 해결 주제를 참조하세요.
+ **Amazon S3에서 500 오류를 반환하는 경우**, [Amazon S3에서 발생하는 HTTP 500 또는 503 오류 문제를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/http-5xx-errors-s3)를 참조하세요.
+ **API Gateway에서 500 오류를 반환하는 경우**, [API Gateway의 5xx 오류를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/api-gateway-5xx-error)를 참조하세요.
+ **Elastic Load Balancing에서 500 오류를 반환하는 경우**, **애플리케이션 로드 밸런서 사용 설명서의 [HTTP 500: Internal server error](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues)를 참조하세요.
위 목록의 방법으로 500 오류가 해결되지 않으면 CloudFront 상호 접속 지점(POP)에서 내부 서버 오류를 반환하는 문제일 수 있습니다. [지원](https://console.aws.amazon.com/support/home#/)에 지원을 문의할 수 있습니다.
# HTTP 502 상태 코드(잘못된 게이트웨이)
CloudFront는 오리진 서버에 연결할 수 없기 때문에 요청된 객체를 제공할 수 없을 때 HTTP 502 상태 코드(잘못된 게이트웨이)를 반환합니다.
Lambda@Edge를 사용하는 경우 Lambda 검증 오류가 문제일 수 있습니다. `NonS3OriginDnsError` 오류 코드와 함께 HTTP 502 오류가 발생하는 경우 CloudFront가 오리진에 연결할 수 없는 DNS 구성 문제가 있을 가능성이 있습니다.
**Topics**
+ [CloudFront와 사용자 지정 원본 서버 간의 SSL/TLS 협상 실패](#ssl-negotitation-failure)
+ [오리진이 지원되는 암호화/프로토콜에 응답하지 않음](#origin-not-responding-with-supported-ciphers-protocols)
+ [오리진의 SSL/TLS 인증서가 만료되었거나 잘못되었거나 자체 서명되었거나, 인증서 체인의 순서가 잘못됨](#ssl-certificate-expired)
+ [오리진이 오리진 설정의 지정된 포트에서 응답하지 않음](#origin-not-responding-on-specified-ports)
+ [Lambda 검증 오류](#http-502-lambda-validation-error)
+ [CloudFront Functions 검증 오류](#http-502-cloudfront-function-validation-error)
+ [DNS 오류(`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Application Load Balancer 오리진 502 오류](#cloudfront-alb-502-error)
+ [API Gateway 오리진 502 오류](#cloudfront-api-gateway-502-error)
## CloudFront와 사용자 지정 원본 서버 간의 SSL/TLS 협상 실패
CloudFront와 오리진 사이에 HTTPS가 위치하도록 요구하는 사용자 지정 오리진을 사용하는 경우, 도메인 이름 불일치로 인해 오류가 발생할 수 있습니다. 오리진의 SSL/TLS 인증서에는 CloudFront 배포용으로 지정한 **오리진 도메인** 또는 오리진 요청의 `Host` 헤더와 일치하는 도메인 이름이 포함되어야 합니다.**
도메인 이름이 일치하지 않으면 SSL/TLS 핸드쉐이크가 실패하고, CloudFront는 HTTP 상태 코드 502(잘못된 게이트웨이)를 반환하고 `X-Cache` 헤더를 `Error from cloudfront`로 설정합니다.
온라인 SSL 확인 프로그램 또는 OpenSSL을 사용하여 인증서의 도메인 이름이 배포의 **오리진 도메인** 또는 `Host` 헤더와 일치하는지 여부를 파악할 수 있습니다. 도메인 이름이 일치하지 않는 경우, 다음 두 가지 옵션이 있습니다.
+ 해당하는 도메인 이름이 포함된 새 SSL/TLS 인증서를 받습니다.
AWS Certificate Manager(ACM)를 사용하는 경우 새 인증서를 요청하려면 *AWS Certificate Manager 사용 설명서*에서 [퍼블릭 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)을 참조하세요.
+ CloudFront가 더 이상 SSL을 사용하여 오리진 연결을 시도하지 않도록 배포 구성을 변경합니다.
### 온라인 SSL 확인 프로그램
SSL 테스트 도구를 찾으려면 인터넷에서 "online ssl checker"를 검색합니다. 일반적으로, 도메인 이름을 지정하면 SSL/TLS 인증서에 대한 다양한 정보가 도구에 표시됩니다. 인증서의 **일반 이름** 또는 **주제 대체 이름** 필드에 도메인 이름이 나와 있는지 확인합니다.
### OpenSSL
CloudFront에서 HTTP 502 오류를 해결하기 위해 OpenSSL을 사용하여 오리진 서버에 SSL/TLS 연결을 시도할 수 있습니다. OpenSSL을 연결할 수 없는 경우 이는 오리진 서버의 SSL/TLS 구성에 문제가 있음을 나타낼 수 있습니다. OpenSSL을 연결할 수 있는 경우 인증서의 일반 이름(`Subject CN` 필드) 및 주체 대체 이름(`Subject Alternative Name` 필드)을 포함하여 오리진 서버의 인증서에 대한 정보를 반환합니다.
다음 OpenSSL 명령을 사용하여 오리진 서버에 대한 연결을 테스트합니다(*origin domain*을 example.com과 같은 오리진 서버의 도메인 이름으로 변경).
`openssl s_client -connect origin domain name:443`
다음이 참인 경우:
+ 오리진 서버는 여러 SSL/TLS 인증서를 사용하여 여러 도메인 이름을 지원합니다.
+ 배포가 `Host` 헤더를 오리진에 전달하도록 구성되어 있습니다.
이후 다음 예제와 같이 OpenSSL 명령에 `-servername` 옵션을 추가합니다(*CNAME*을 배포에 구성된 CNAME으로 변경).
`openssl s_client -connect origin domain name:443 -servername CNAME`
## 오리진이 지원되는 암호화/프로토콜에 응답하지 않음
CloudFront는 암호화 및 프로토콜을 사용하여 오리진 서버에 연결합니다. CloudFront에서 지원하는 암호화 및 프로토콜 목록은 [CloudFront와 오리진 간에 지원되는 프로토콜 및 암호](secure-connections-supported-ciphers-cloudfront-to-origin.md) 섹션을 참조하세요. 오리진이 SSL/TLS 교환에서 이러한 암호화 또는 프로토콜 중 하나에 응답하지 않는 경우, CloudFront가 연결되지 않은 것입니다. [SSL Labs](https://www.ssllabs.com/ssltest)와 같은 온라인 도구를 사용하면, 오리진에서 암호화 및 프로토콜을 지원하는지 확인할 수 있습니다. **호스트 이름** 필드에 오리진의 도메인 이름을 입력한 다음 **제출**을 선택합니다. 테스트에서 **일반 이름** 및 **대체 이름** 필드를 검토하여 오리진의 도메인 이름과 일치하는지 확인합니다. 테스트가 완료되면 테스트 결과에서 **프로토콜** 및 **암호 글부** 섹션을 찾아 오리진에서 암호화 또는 프로토콜을 지원하는지 확인합니다. 이를 [CloudFront와 오리진 간에 지원되는 프로토콜 및 암호](secure-connections-supported-ciphers-cloudfront-to-origin.md)의 목록과 비교합니다.
## 오리진의 SSL/TLS 인증서가 만료되었거나 잘못되었거나 자체 서명되었거나, 인증서 체인의 순서가 잘못됨
오리진 서버에서 다음을 반환하면, CloudFront는 TCP 연결을 끊고 HTTP 상태 코드 502(잘못된 게이트웨이)를 반환하며, `X-Cache` 헤더를 `Error from cloudfront`로 설정합니다.
+ 만료된 인증서
+ 잘못된 인증서
+ 자체 서명된 인증서
+ 인증서 체인의 순서가 잘못됨
**참고**
중간 인증서를 포함하여 인증서의 전체 체인이 없는 경우, CloudFront는 TCP 연결을 끊습니다.
사용자 지정 원본 서버에 SSL/TLS 인증서를 설치하는 데 대한 자세한 내용은 [CloudFront와 사용자 지정 오리진 간의 통신에 HTTPS 요구](using-https-cloudfront-to-custom-origin.md) 섹션을 참조하세요.
## 오리진이 오리진 설정의 지정된 포트에서 응답하지 않음
CloudFront 배포에 오리진을 만드는 경우, CloudFront가 HTTP 및 HTTPS 트래픽을 통해 오리진에 연결하는 포트를 설정할 수 있습니다. 기본적으로 TCP 80/443이 있습니다. 이러한 포트를 수정할 수 있습니다. 오리진이 어떤 이유로 이러한 포트의 트래픽을 거부하거나 백엔드 서버가 포트에서 응답하지 않는 경우, CloudFront가 연결되지 않습니다.
이러한 문제를 해결하려면 인프라에서 실행 중인 방화벽을 확인하고, 방화벽이 지원되는 IP 범위를 차단하지 않는지 확인하십시오. 자세한 내용은 **Amazon VPC 사용 설명서의 [AWS IP 주소 범위](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)를 참조하세요. 또한 웹 서버가 오리진에서 실행되는지 확인하십시오.
## Lambda 검증 오류
Lambda@Edge를 사용하는 경우 HTTP 502 상태 코드는 Lambda 함수 응답이 잘못 구성되어 있거나 잘못된 내용을 포함하고 있음을 나타낼 수 있습니다. Lambda@Edge 오류 문제 해결에 대한 자세한 내용은 [Lambda@Edge 함수 테스트 및 디버깅](lambda-edge-testing-debugging.md) 단원을 참조하십시오.
## CloudFront Functions 검증 오류
CloudFront Functions를 사용하는 경우 HTTP 502 상태 코드는 CloudFront Functions가 읽기 전용 헤더를 추가, 삭제 또는 변경하려고 시도 중임을 나타낼 수 있습니다. 이 오류는 테스트 중에는 표시되지 않지만 함수를 배포하고 요청을 실행한 후에 표시됩니다. 이 오류를 해결하려면 CloudFront Functions를 확인하고 업데이트하세요. 자세한 내용은 [함수 업데이트](update-function.md) 섹션을 참조하세요.
## DNS 오류(`NonS3OriginDnsError`)
`NonS3OriginDnsError` 오류 코드가 있는 HTTP 502 오류는 CloudFront가 오리진에 연결할 수 없는 DNS 구성 문제가 있음을 나타냅니다. CloudFront에서 이 오류가 발생하는 경우 오리진의 DNS 구성이 올바르고 제대로 작동하는지 확인합니다.
만료되었거나 캐시에 없는 객체에 대한 요청을 수신하면 CloudFront는 객체를 가져오기 위해 오리진에 요청합니다. 성공적으로 오리진에 요청하기 위해 CloudFront는 오리진 도메인에 대해 DNS 확인을 수행합니다. 도메인의 DNS 서비스에 문제가 있는 경우 CloudFront가 도메인 이름을 확인하여 IP 주소를 가져올 수 없어 HTTP 502 오류(`NonS3OriginDnsError`)가 발생합니다. 이 문제를 해결하려면 DNS 공급자에게 문의하세요. 또는 Amazon Route 53을 사용하는 경우 [Route 53 DNS 서비스를 사용하는 웹 사이트에 액세스할 수 없는 이유는 무엇입니까?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)를 참조하세요.
이 문제를 추가로 해결하려면 오리진 루트 도메인 또는 zone apex(예: `example.com`)의 [권한 있는 이름 서버](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server)가 올바르게 작동 중인지 확인하십시오. [dig](https://en.wikipedia.org/wiki/Dig_(command)) 또는 [nslookup](https://en.wikipedia.org/wiki/Nslookup) 같은 툴과 함께 다음 명령을 사용하여 apex 오리진의 이름 서버를 찾습니다
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
이름 서버의 이름을 아는 경우 다음 명령을 사용하여 해당 이름에 대해 오리진의 도메인 이름을 쿼리하여 각각 다음 답변으로 응답하는지 확인합니다.
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**중요**
퍼블릭 인터넷에 연결된 컴퓨터를 사용하여 이 DNS 문제 해결을 수행해야 합니다. CloudFront는 인터넷의 퍼블릭 DNS를 사용하여 오리진 도메인을 확인하므로 비슷한 컨텍스트에서 문제를 해결하는 것이 중요합니다.
오리진이 루트 도메인이 아닌 다른 이름 서버에 DNS 권한이 위임된 하위 도메인인 경우, 해당 하위 도메인에 대해 이름 서버(`NS`) 및 권한 시작(`SOA`) 레코드가 올바르게 구성되었는지 확인합니다. 이전 예와 비슷한 명령을 사용하여 이러한 레코드를 확인할 수 있습니다.
DNS에 대한 자세한 내용은 Amazon Route 53 설명서의 [도메인 이름 시스템(DNS) 개념](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns)을 참조하세요.
## Application Load Balancer 오리진 502 오류
Application Load Balancer를 오리진으로 사용하고 502 오류가 발생하는 경우 [Application Load Balancer HTTP 502 오류를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors)를 참조하세요.
## API Gateway 오리진 502 오류
API Gateway를 사용하고 502 오류가 발생하는 경우 [Lambda 프록시 통합을 사용하는 API Gateway REST API에서 HTTP 502 오류를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/malformed-502-api-gateway)를 참조하세요.
# HTTP 503 상태 코드(Service Unavailable)
HTTP 503 상태 코드(Service Unavailable)는 일반적으로 오리진 서버의 성능 문제를 나타냅니다. 드물지만 이 상태 코드가 엣지 로케이션의 리소스 제한 때문에 CloudFront가 일시적으로 요청을 충족할 수 없음을 나타냅니다.
Lambda@Edge 또는 CloudFront Functions를 사용하는 경우 문제는 실행 오류 또는 Lambda@Edge 제한 초과 오류일 수 있습니다.
**Topics**
+ [Origin server does not have enough capacity to support the request rate](#http-503-service-unavailable-not-enough-origin-capacity)
+ [엣지 위치에서의 리소스 제약 조건으로 인해 CloudFront에서 오류가 발생함](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda@Edge 또는 CloudFront Functions 실행 오류](#http-503-lambda-execution-error)
+ [Lambda @Edge 제한 초과](#http-503-lambda-limit-exceeded-error)
## Origin server does not have enough capacity to support the request rate
오리진 서버를 사용할 수 없거나 수신된 요청을 처리할 수 없는 경우, HTTP 503 상태 코드(서비스 사용 불가)가 반환됩니다. 그런 다음 CloudFront가 다시 사용자에게 오류를 전달합니다. 이 문제를 해결하려면 다음 솔루션을 시도해 보십시오.
+ **Amazon S3를 오리진 서버로 사용하는 경우**:
+ 분할된 Amazon S3 접두사별로 초당 최소 3,500개의 PUT/COPY/POST/DELETE 또는 5,500개의 GET/HEAD 요청을 전송할 수 있습니다. Amazon S3에서 503 Slow Down 응답을 반환하는 경우 이는 일반적으로 특정 Amazon S3 접두사에 대한 요청 빈도가 너무 높음을 나타냅니다.
요청 요금은 S3 버킷의 접두사별로 적용되므로 객체를 여러 접두사에 분산해야 합니다. 접두사의 요청 빈도가 점차 증가함에 따라 Amazon S3는 각 접두사에 대한 요청을 개별적으로 처리하도록 스케일 업니다. 결과적으로, 버킷이 처리하는 전체 요청 빈도는 접두사 수의 배수입니다.
+ 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 성능 최적화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)를 참조하세요.
+ **Elastic Load Balancing을 오리진 서버로 사용하는 경우**:
+ 백엔드 인스턴스가 상태 확인에 응답할 수 있는지 확인합니다.
+ 로드 밸런서와 백엔드 인스턴스가 부하를 처리할 수 있는지 확인합니다.
자세한 내용은 다음을 참조하세요.
+ [Classic Load Balancer 사용 중 반환되는 503 오류를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/503-error-classic)
+ [Application Load Balancer에서 발생하는 503(서비스 사용 불가) 오류를 해결하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **사용자 지정 오리진을 사용하는 경우**:
+ 애플리케이션 로그를 검사하여 오리진에 메모리, CPU, 디스크 크기 등의 리소스가 충분한지 확인합니다.
+ Amazon EC2를 백엔드로 사용하는 경우 인스턴스 유형에 수신 요청을 충족하는 적절한 리소스가 있는지 확인합니다. 자세한 내용을 알아보려면 *Amazon EC2 사용 설명서*의 [인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요.
+ **API Gateway를 사용하는 경우**:
+ 이 오류는 API Gateway API가 응답을 받을 수 없는 경우의 백엔드 통합과 관련이 있습니다. 백엔드 서버는 다음과 같을 수 있습니다.
+ 용량을 초과하여 과부하가 걸려 새 클라이언트 요청을 처리할 수 없습니다.
+ 임시 유지 관리 중입니다.
+ 이 오류를 해결하려면 API Gateway 애플리케이션 로그를 살펴보고 백엔드 용량, 통합 등에 문제가 있는지 확인합니다.
## 엣지 위치에서의 리소스 제약 조건으로 인해 CloudFront에서 오류가 발생함
드문 경우지만 CloudFront가 사용 가능한 차선의 엣지 로케이션으로 요청을 라우팅할 수 없어서 요청을 충족할 수 없는 경우에 이 오류가 발생합니다. 이 오류는 CloudFront 배포에 대한 로드 테스트를 수행할 때 흔히 발생합니다. 이러한 오류를 방지하려면 503(용량 초과) 오류 방지를 위한 [CloudFront 로드 테스트](load-testing.md) 지침을 따르세요.
프로덕션 환경에서 이러한 오류가 발생하면 [지원](https://console.aws.amazon.com/support/home#/)에 문의하세요.
## Lambda@Edge 또는 CloudFront Functions 실행 오류
Lambda@Edge 또는 CloudFront 함수를 사용하는 경우, HTTP 503 상태 코드는 함수가 실행 오류를 반환했음을 나타낼 수 있습니다.
Lambda@Edge 오류를 식별하고 해결하는 방법에 대한 자세한 내용은 [Lambda@Edge 함수 테스트 및 디버깅](lambda-edge-testing-debugging.md) 섹션을 참조하세요.
CloudFront Functions 테스트에 대한 자세한 내용은 [함수 테스트](test-function.md) 섹션을 참조하세요.
## Lambda @Edge 제한 초과
Lambda@Edge를 사용하는 경우 HTTP 503 상태 코드는 Lambda가 오류를 반환했음을 나타낼 수 있습니다. 오류는 다음 중 하나로 인해 발생할 수 있습니다.
+ 함수 실행 수가 AWS 리전에서 실행을 제한하기 위해 Lambda가 설정한 할당량(동시 실행 또는 간접 호출 빈도) 중 하나를 초과했습니다.
+ 함수가 Lambda 함수의 제한 시간 할당량을 초과했습니다.
Lambda@Edge 할당량에 대한 자세한 내용은 [Lambda@Edge에 대한 할당량](cloudfront-limits.md#limits-lambda-at-edge) 섹션을 참조하세요. Lambda@Edge 오류를 식별하고 해결하는 방법에 대한 자세한 내용은 [Lambda@Edge 함수 테스트 및 디버깅](lambda-edge-testing-debugging.md) 섹션을 참조하세요. **AWS Lambda 개발자 안내서에서도 [Lambda 서비스 할당량](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)을 확인할 수 있습니다.
# HTTP 504 상태 코드(게이트웨이 제한 시간)
HTTP 504 상태 코드(게이트웨이 시간 초과)는 CloudFront가 오리진에 요청을 전달했을 때(요청된 객체가 엣지 캐시에 없었기 때문에) 다음 중 하나가 발생했음을 나타냅니다.
+ 오리진이 CloudFront에 HTTP 504 상태 코드를 반환했습니다.
+ 요청이 만료되기 전에 오리진이 응답하지 않았습니다.
방화벽 또는 보안 그룹에 의해 오리진에 대해 트래픽이 차단된 경우나 오리진이 인터넷에서 액세스가 불가능한 경우에 CloudFront는 HTTP 504 상태 코드를 반환합니다. 이러한 문제들이 있는지 먼저 확인합니다. 그런 다음, 액세스 문제가 아닌 경우에는 애플리케이션 지연 및 서버 제한 시간을 탐색하여 문제를 확인하고 시정합니다.
**Topics**
+ [CloudFront 트래픽을 허용하도록 원본 서버에서 방화벽 구성](#http-504-gateway-timeout-configure-firewall)
+ [CloudFront 트래픽을 허용하도록 원본 서버에서 보안 그룹 구성](#http-504-gateway-timeout-configure-security-groups)
+ [사용자 지정 원본 서버를 인터넷에서 액세스할 수 있도록 설정](#http-504-gateway-timeout-make-origin-accessible)
+ [원본 서버의 애플리케이션에서 지연된 응답을 찾아서 수정](#http-504-gateway-timeout-slow-application)
## CloudFront 트래픽을 허용하도록 원본 서버에서 방화벽 구성
오리진 서버의 방화벽에 의해 CloudFront 트래픽이 차단되는 경우에 CloudFront는 HTTP 504 상태 코드를 반환하는데, 다른 문제를 확인하기 전에 먼저 이 문제가 아닌지 확인하는 것이 좋습니다.
이것이 방화벽 문제인지를 판단하기 위해 사용하는 방법은 오리진 서버가 사용하는 시스템에 따라 다릅니다.
+ Linux 서버에서 IPTable 방화벽을 사용하는 경우에는 IPTable에서의 작업에 도움이 되는 도구 및 정보를 검색할 수 있습니다.
+ Windows 서버에서 Windows 방화벽을 사용하는 경우에는 Microsoft 설명서의 [방화벽 규칙 추가 또는 편집](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx)을 참조하세요.
오리진 서버에서 방화벽 구성을 평가할 때는 게시된 IP 주소 범위를 토대로 CloudFront 엣지 로케이션에서의 트래픽을 차단하는 방화벽이나 보안 규칙이 있는지 찾아봅니다. 자세한 내용은 [CloudFront 엣지 서버의 위치 및 IP 주소 범위](LocationsOfEdgeServers.md) 섹션을 참조하세요.
CloudFront IP 주소 범위가 오리진 서버에 연결하도록 허용되는 경우, 변경 사항이 포함되도록 서버의 보안 규칙을 업데이트합니다. Amazon SNS 주제를 구독하면 IP 주소 범위 파일이 업데이트될 때 알림을 수신할 수 있습니다. 알림을 수신한 후에는 코드를 사용하여 파일을 찾아서 구문 분석하고 로컬 환경에 맞게 조정할 수 있습니다. 자세한 내용은 AWS 뉴스 블로그에서 [Amazon SNS를 통한 AWS 퍼블릭 IP 주소 변경 사항 구독](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/)을 참조하세요.
## CloudFront 트래픽을 허용하도록 원본 서버에서 보안 그룹 구성
오리진이 Elastic Load Balancing을 사용하는 경우에는 [ELB 보안 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html)을 검토해서 보안 그룹이 CloudFront에서의 인바운드 트래픽을 허용하는지 확인합니다.
또한 AWS Lambda를 사용하여 보안 그룹을 자동 업데이트함으로써 CloudFront에서의 인바운드 트래픽을 허용할 수도 있습니다.
## 사용자 지정 원본 서버를 인터넷에서 액세스할 수 있도록 설정
인터넷에서 공개적으로 사용할 수 없기 때문에 CloudFront가 사용자 지정 오리진 서버를 액세스할 수 없는 경우, CloudFront는 HTTP 504 오류를 반환합니다.
CloudFront 엣지 로케이션은 인터넷을 통해 오리진 서버에 연결됩니다. 사용자 지정 오리진이 사설 네트워크에 있는 경우에는 CloudFront가 이를 액세스할 수 없습니다. 따라서 [내부 Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html)를 포함한 프라이빗 서버를 CloudFront에서 오리진 서버로 사용할 수 없습니다.
인터넷 트래픽을 오리진 서버에 연결할 수 있는지 확인하려면 다음 명령(*OriginDomainName*은 서버의 도메인 이름)을 실행하세요.
HTTPS 트래픽의 경우:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
HTTP 트래픽의 경우:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## 원본 서버의 애플리케이션에서 지연된 응답을 찾아서 수정
애플리케이션에서 응답에 너무 많은 시간이 소요되거나 제한 시간 값이 너무 낮게 설정된 결과로 인해 서버 제한 시간이 발생하는 경우가 종종 있습니다.
HTTP 504 오류를 방지하기 위한 일시적인 해결책으로 배포 시 CloudFront 제한 시간 값을 더 높게 설정하는 방법이 있기는 합니다. 그러나 애플리케이션 및 오리진 서버에서 성능 및 지연 문제가 해결되었는지 먼저 확인하는 것이 좋습니다. 제한 시간 값을 적당하게 설정하면 HTTP 504 오류를 방지하고 사용자에게 뛰어난 응답성을 제공할 수 있습니다.
여기에는 성능 문제를 찾아서 해결할 때 거치게 되는 단계들이 개략적으로 나와 있습니다.
1. 정상 부하 및 고부하에서 웹 애플리케이션의 지연 시간(응답성)을 측정합니다.
1. 필요할 경우 CPU나 메모리 같은 리소스를 추가합니다. 고부하 상황을 지원하도록 데이터베이스 쿼리를 튜닝하는 등 문제 해결을 위한 기타 조치를 취합니다.
1. 필요할 경우 CloudFront 배포의 제한 시간 값을 조정합니다.
아래에는 각 단계에 대한 세부 정보가 나와 있습니다.
### 정상 부하 및 고부하에서 지연 시간 측정
하나 이상의 백엔드 웹 애플리케이션 서버가 고부하를 경험하고 있는지 판단하려면 각 서버에서 아래의 Linux curl 명령을 실행합니다.
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**참고**
서버에서 Windows를 실행하는 경우에는 유사한 명령을 실행하도록 Windows용 cURL을 검색 및 다운로드할 수 있습니다.
서버에서 실행되는 애플리케이션의 지연 시간을 측정 및 평가할 때는 다음 사항에 유의하십시오.
+ 지연 값은 각 애플리케이션에 상대적입니다. 하지만 초 단위가 아니라 밀리초 단위의 TTFB(Time To First Byte)가 적당합니다.
+ 정상 부하에서 애플리케이션 지연 시간을 측정한 결과 문제가 없었더라도 고부하에서는 최종 사용자가 제한 시간을 경험할 수 있다는 점에 유의하세요. 수요가 높으면 서버에서 응답이 지연되거나 아예 응답이 없을 수 있습니다. 고부하 지연 문제를 방지하려면 CPU, 메모리, 디스크 읽기/쓰기 같은 서버의 리소스를 확인하여 고부하에 맞게 서버 용량을 확장합니다.
다음 Linux 명령을 실행하여 Apache 프로세스에서 사용되는 메모리를 확인할 수 있습니다.
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ 서버에서 CPU 활용도가 높으면 애플리케이션 성능이 크게 낮아질 수 있습니다. 백엔드 서버에서 Amazon EC2 인스턴스를 사용하는 경우에는 서버의 CloudWatch 지표를 검토하여 CPU 활용도를 확인합니다. 자세한 내용은 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)를 참조하십시오. 자체 서버를 사용 중인 경우에는 서버 도움말 문서에서 CPU 활용도를 확인할 수 있는 방법에 대한 지침을 참조하세요.
+ 요청의 수가 많을 때 데이터베이스 쿼리의 실행 속도가 느려지는 것과 같이 고부하 상황에서 발생할 수 있는 기타 문제들을 확인하세요.
### 리소스를 추가하고 서버 및 데이터베이스 튜닝
애플리케이션 및 서버의 응답성을 평가한 후에는 정상 부하 및 고부하 상황을 위해 충분한 리소스가 구축되어 있는지 확인합니다.
+ 자체 서버를 가지고 있는 경우에는 평가 결과를 토대로 CPU, 메모리 및 디스크 공간이 최종 사용자 요청을 처리하기에 충분한지 확인합니다.
+ Amazon EC2 인스턴스를 백엔드 서버로 사용하는 경우 인스턴스 유형에 수신 요청을 이행하기에 적절한 리소스가 있는지 확인합니다. 자세한 내용을 알아보려면 *Amazon EC2 사용 설명서*의 [인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요.
뿐만 아니라, 제한 시간을 방지하려면 다음과 같은 튜닝 조치를 고려하십시오.
+ cURL 명령이 반환한 TTFB(Time To First Byte) 값이 높은 경우에는 애플리케이션의 성능을 개선하기 위한 조치를 취합니다. 애플리케이션 응답성을 높이면 제한 시간 오류가 줄어듭니다.
+ 성능 저하 없이 많은 양의 요청을 처리할 수 있도록 데이터베이스 쿼리를 튜닝합니다.
+ 백엔드 서버에서 [연결 유지(영구)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) 연결을 설정합니다. 이 옵션은 후속 요청이나 사용자에 대해 연결을 다시 설정해야 하는 경우에 발생하는 지연을 방지하는 데 도움이 됩니다.
+ **Elastic Load Balancing를 오리진으로 사용하는 경우**, 504 오류가 발생할 수 있는 원인은 다음과 같습니다.
+ 연결 제한 시간이 만료(10초)되기 전에 로드 밸런서가 대상에 대한 연결을 설정하지 못합니다.
+ 로드 밸런서가 대상에 대한 연결을 설정하지만, 유휴 제한 시간이 끝나기 전에 대상이 응답을 하지 않습니다.
+ 서브넷의 네트워크 액세스 제어 목록(ACL)이 휘발성 포트(1024-65535)에서 대상으로부터 로드 밸런서 노드로의 트래픽을 허용하지 않습니다.
+ 대상이 개체 몸체보다 큰 콘텐츠 길이 헤더를 반환합니다. 로드 밸런서가 놓친 바이트를 기다리는 도중 시간이 초과됩니다.
+ 대상이 Lambda 함수이고 Lambda 서비스가 연결 제한 시간이 만료되기 전에 응답하지 않습니다.
지연 시간 단축에 대한 자세한 내용은 [ELB Classic Load Balancer의 지연 시간이 긴 문제를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)를 참조하세요.
+ **MediaTailor를 오리진으로 사용하는 경우**, 504 오류가 발생할 수 있는 원인은 다음과 같습니다.
+ 상대 URL을 잘못 처리하는 경우 MediaTailor는 플레이어로부터 잘못된 형식의 URL을 수신할 수 있습니다.
+ MediaPackage가 MediaTailor의 매니페스트 오리진인 경우 MediaPackage 404 매니페스트 오류로 인해 MediaTailor가 504 오류를 반환할 수 있습니다.
+ MediaTailor 오리진 서버에 대한 요청을 완료하는 데 2초 이상 걸립니다.
+ **Amazon API Gateway를 오리진으로 사용하는 경우**, 504 오류가 발생할 수 있는 원인은 다음과 같습니다.
+ 통합 요청이 API Gateway REST API 최대 통합 제한 시간 파라미터보다 오래 걸립니다. 자세한 내용은 [API Gateway의 API HTTP 504 제한 시간 오류를 해결하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/api-gateway-504-errors)를 참조하세요.
### 필요할 경우 CloudFront 제한 시간 값을 조정합니다.
애플리케이션 성능 저하, 오리진 서버 용량 및 기타 문제를 평가하고 해결했지만 최종 사용자가 여전히 HTTP 504 오류를 경험하고 있는 경우에는 오리진 응답 제한 시간에 대해 배포에 지정되어 있는 시간을 변경하는 것을 반드시 고려해봐야 합니다. 자세한 내용은 [응답 제한 시간](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout) 섹션을 참조하세요.