기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Classic Load Balancer 문제 해결
다음 표에는 Classic Load Balancer를 사용할 때 유용하게 참조할 수 있는 문제 해결 리소스가 나와 있습니다.
**API 오류**
| 오류 |
| --- |
| [CertificateNotFound: 정의되지 않음](ts-elb-error-api-response.md#ts-elb-error-message-certificate) |
| [OutofService: 일시적인 오류가 발생함](ts-elb-error-api-response.md#ts-elb-error-message-service) |
**HTTP 오류**
| 오류 |
| --- |
| [HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400) |
| [HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405) |
| [HTTP 408: 요청 제한 시간](ts-elb-error-message.md#ts-elb-errorcodes-http408) |
| [HTTP 502: 잘못된 게이트웨이](ts-elb-error-message.md#ts-elb-errorcodes-http502) |
| [HTTP 503: 서비스 사용 불가](ts-elb-error-message.md#ts-elb-errorcodes-http503) |
| [HTTP 504: 게이트웨이 제한 시간](ts-elb-error-message.md#ts-elb-errorcodes-http504) |
**응답 코드 지표**
| 응답 코드 지표 |
| --- |
| [HTTPCode\$1ELB\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_4XX) |
| [HTTPCode\$1ELB\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_5XX) |
| [HTTPCode\$1Backend\$12XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_2XX) |
| [HTTPCode\$1Backend\$13XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_3XX) |
| [HTTPCode\$1Backend\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_4XX) |
| [HTTPCode\$1Backend\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_5XX) |
**상태 확인 문제**
| 문제 |
| --- |
| [상태 확인 대상 페이지 오류](ts-elb-healthcheck.md#ts-elb-healthcheck-targetpage) |
| [인스턴스 연결 시간 초과](ts-elb-healthcheck.md#ts-elb-healthcheck-failed) |
| [퍼블릭 키 인증이 실패함](ts-elb-healthcheck.md#ts-elb-healthcheck-publickey) |
| [인스턴스가 로드 밸런서에서 트래픽을 수신하지 않음](ts-elb-healthcheck.md#ts-elb-healthcheck-securitygroup) |
| [인스턴스의 포트가 열려 있지 않음](ts-elb-healthcheck.md#ts-elb-healthcheck-ports) |
| [Auto Scaling 그룹의 인스턴스가 ELB 상태 확인에 실패함](ts-elb-healthcheck.md#ts-elb-healthcheck-autoscaling) |
**연결 문제**
| 문제 |
| --- |
| [클라이언트가 인터넷 경계 로드 밸런서에 연결할 수 없음](ts-elb-connection-failed.md#client-cannot-connect) |
| [사용자 지정 도메인으로 전송된 요청은 로드 밸런서에 수신되지 않습니다.](ts-elb-connection-failed.md#custom-domain-request) |
| [로드 밸런서로 전송된 HTTPS 요청은 “NET: :ERR\$1CERT\$1COMMON\$1NAME\$1INVALID”를 반환합니다.](ts-elb-connection-failed.md#https-cert-invalid) |
**인스턴스 등록 문제**
| 문제 |
| --- |
| [EC2 인스턴스를 등록하는 데 너무 오래 걸림](ts-elb-register-instance.md#ts-elb-register-too-long) |
| [유료 AMI에서 시작된 인스턴스를 등록할 수 없음](ts-elb-register-instance.md#ts-elb-paid-ami-instance) |
# Classic Load Balancer 문제 해결: API 오류
다음은 Elastic Load Balancing API, 잠재적인 원인 및 문제를 해결하기 위해 수행할 수 있는 단계에서 반환되는 오류 메시지입니다.
**Topics**
+ [CertificateNotFound: 정의되지 않음](#ts-elb-error-message-certificate)
+ [OutofService: 일시적인 오류가 발생함](#ts-elb-error-message-service)
## CertificateNotFound: 정의되지 않음
**원인 1**: AWS Management Console을 사용하여 인증서를 생성할 때 인증서를 모든 리전에 전달하는 데 지연이 있습니다. 이러한 지연이 발생하면 로드 밸런서 생성 과정의 마지막 단계에서 오류 메시지가 표시됩니다.
**솔루션 1**: 약 15분간 기다린 후 다시 시도합니다. 문제가 계속되면 [AWS Support 센터](https://console.aws.amazon.com/support/home#/)로 이동하여 지원을 요청합니다.
**원인 2**: AWS CLI 또는 API를 직접 사용하는 경우 존재하지 않는 인증서에 Amazon 리소스 이름(ARN)을 제공하면이 오류가 발생할 수 있습니다.
**솔루션 2**: AWS Identity and Access Management (IAM) 작업 [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html)를 사용하여 인증서 ARN을 가져오고 ARN에 올바른 값을 제공했는지 확인합니다.
## OutofService: 일시적인 오류가 발생함
**원인**: Elastic Load Balancing 서비스 또는 기본 네트워크 내에 일시적인 내부 문제가 있습니다. 이 일시적인 문제는 Elastic Load Balancing이 로드 밸런서 및 등록된 인스턴스의 상태를 쿼리할 때에도 발생할 수 있습니다.
**솔루션**: API 호출을 다시 시도합니다. 문제가 계속되면 [AWS Support 센터](https://console.aws.amazon.com/support/home#/)로 이동하여 지원을 요청합니다.
# Classic Load Balancer 문제 해결: HTTP 오류
HTTP 메서드(*동사*라고도 불림)는 HTTP 요청을 수신하는 리소스에서 수행할 작업을 지정합니다. HTTP 요청에 대한 표준 메서드는 RFC 2616 [Method Definitions](http://tools.ietf.org/html/rfc2616#section-9)에 정의되어 있습니다. 표준 메서드에는 GET, POST, PUT, HEAD 및 OPTIONS가 포함됩니다. 일부 웹 애플리케이션은 HTTP/1.1 메서드의 확장 메서드를 필요로 하며 때에 따라 이를 적용합니다. HTTP 확장 메서드의 일반적인 예에는 PATCH, REPORT, MKCOL, PROPFIND, MOVE 및 LOCK이 포함됩니다. Elastic Load Balancing은 모든 표준 및 비표준 HTTP 메서드를 허용합니다.
HTTP 요청 및 응답은 헤더 필드를 사용하여 HTTP 메시지에 대한 정보를 보냅니다. 헤더 필드는 콜론으로 구분된 이름-값 페어이며 CR(캐리지 리턴) 및 LF(줄 바꿈)로 구분됩니다. HTTP 헤더 필드의 표준 집합은 RFC 2616 [Message Headers](http://tools.ietf.org/html/rfc2616#section-4.2)에 정의되어 있습니다. 자세한 내용은 [HTTP 헤더 및 Classic Load Balancer](x-forwarded-headers.md) 단원을 참조하십시오.
로드 밸런서는 HTTP 요청을 받으면 잘못된 형식의 요청 및 메서드 길이를 확인합니다. 로드 밸런서에 대한 HTTP 요청의 전체 메소드 길이는 127자를 초과할 수 없습니다. HTTP 요청이 두 가지 확인을 모두 통과하면 로드 밸런서는 요청을 EC2 인스턴스로 전송합니다. 요청의 메소드 필드가 잘못된 형식인 경우 로드 밸런서는 [HTTP 400: BAD\$1REQUEST](#ts-elb-errorcodes-http400) 오류로 응답합니다. 요청의 메소드 길이가 127자를 초과하는 경우 로드 밸런서는 [HTTP 405: METHOD\$1NOT\$1ALLOWED](#ts-elb-errorcodes-http405) 오류로 응답합니다.
EC2 인스턴스는 요청에 메소드를 구현하고 응답을 클라이언트에 다시 전송하는 방식으로 유효한 요청을 처리합니다. 인스턴스는 지원되는 메소드와 지원되지 않는 메소드를 모두 처리하도록 구성되어야 합니다.
다음은 로드 밸런서, 잠재적인 원인 및 문제를 해결하기 위해 수행할 수 있는 단계에서 반환되는 오류 메시지입니다.
**Topics**
+ [HTTP 400: BAD\$1REQUEST](#ts-elb-errorcodes-http400)
+ [HTTP 405: METHOD\$1NOT\$1ALLOWED](#ts-elb-errorcodes-http405)
+ [HTTP 408: 요청 제한 시간](#ts-elb-errorcodes-http408)
+ [HTTP 502: 잘못된 게이트웨이](#ts-elb-errorcodes-http502)
+ [HTTP 503: 서비스 사용 불가](#ts-elb-errorcodes-http503)
+ [HTTP 504: 게이트웨이 제한 시간](#ts-elb-errorcodes-http504)
## HTTP 400: BAD\$1REQUEST
**설명**: 클라이언트가 잘못된 요청을 전송했다는 것을 나타냅니다.
**원인 1**: 클라이언트가 HTTP 사양을 충족하지 않는 잘못된 형식의 요청을 전송했습니다. 예를 들어 요청에 URL 공백이 없어야 합니다.
**원인 2**: 클라이언트가 사용한 HTTP CONNECT 방법은 Elastic Load Balancing에서 지원하지 않습니다.
**솔루션**: 인스턴스에 직접 연결하고 클라이언트 요청의 세부 사항을 캡처합니다. 잘못된 형식의 요청에 대해 헤더와 URL을 검토합니다. 요청이 HTTP 사양에 부합하는지 확인합니다. HTTP CONNECT를 사용하지 않는지 확인하십시오.
## HTTP 405: METHOD\$1NOT\$1ALLOWED
**설명**: 메서드 길이가 잘못되었다는 것을 나타냅니다.
**원인**: 요청 헤더의 메서드 길이가 127자를 초과합니다.
**솔루션**: 메서드 길이를 확인합니다.
## HTTP 408: 요청 제한 시간
**설명**: 클라이언트가 요청을 취소했거나 전체 요청을 전송하지 못했다는 것을 나타냅니다.
**원인 1**: 네트워크 중단 또는 부분적으로 형성된 헤더 같은 잘못된 요청, 지정된 콘텐츠 크기가 전송된 실제 콘텐츠 크기와 일치하지 않는 상황 등이 있습니다.
**솔루션 1**: 요청을 하는 코드를 검사하고, 실제 요청을 검사할 수 있는 권한을 가진 등록된 인스턴스(또는 개발/테스트 환경)로 직접 보내 봅니다.
**원인 2**: 클라이언트에 대한 연결이 종료되었습니다(로드 밸런서가 응답을 보낼 수 없음).
**솔루션 2**: 요청을 하는 머신에서 패킷 스니퍼를 사용하여 응답을 보내기 전에 클라이언트가 연결을 종료하지 않는지 확인합니다.
## HTTP 502: 잘못된 게이트웨이
**설명**: 로드 밸런서가 등록된 인스턴스에서 보낸 응답을 구문 분석할 수 없다는 것을 나타냅니다.
**원인**: 인스턴스의 응답이 잘못된 형식이거나 로드 밸런서의 문제일 수 있습니다.
**솔루션**: 인스턴스에서 보낸 응답이 HTTP 사양을 준수하는지 확인합니다. [AWS Support 센터](https://console.aws.amazon.com/support/home#/)로 이동하여 지원을 요청합니다.
## HTTP 503: 서비스 사용 불가
**설명**: 로드 밸런서 또는 등록된 인스턴스가 오류의 원인이라는 것을 나타냅니다.
**원인 1**: 요청을 처리할 로드 밸런서의 용량이 부족합니다.
**솔루션 1**: 이는 일시적인 문제여야 하며 몇 분 이상 지속되어서는 안 됩니다. 문제가 계속되면 [AWS Support 센터](https://console.aws.amazon.com/support/home#/)로 이동하여 지원을 요청합니다.
**원인 2**: 등록된 인스턴스가 없습니다.
**솔루션 2**: 로드 밸런서가 응답하도록 구성된 모든 가용 영역에 인스턴스를 하나 이상 등록합니다. CloudWatch의 `HealthyHostCount` 지표를 보고 확인합니다. 인스턴스가 각 가용 영역에 등록되어 있는지 확인할 수 없는 경우 교차 영역 로드 밸런싱을 활성화하는 것이 좋습니다. 자세한 내용은 [Classic Load Balancer에서 교차 영역 로드 밸런성을 구성](enable-disable-crosszone-lb.md) 단원을 참조하십시오.
**원인 3**: 정상적인 인스턴스가 없습니다.
**솔루션 3**: 로드 밸런서가 응답하도록 구성된 모든 가용 영역에 정상적인 인스턴스가 있는지 확인합니다. `HealthyHostCount` 지표를 보고 확인합니다.
**원인 4**: 서지 대기열이 가득 찼습니다.
**원인 4**: 인스턴스에 요청 빈도를 처리할 충분한 용량이 있는지 확인합니다. `SpilloverCount` 지표를 보고 확인합니다.
## HTTP 504: 게이트웨이 제한 시간
**설명**: 유휴 제한 시간 내에 요청이 완료되지 않았기 때문에 로드 밸런서가 연결을 종료했다는 것을 나타냅니다.
**원인 1**: 애플리케이션은 구성된 유휴 제한 시간보다 응답하는 데 더 오래 걸립니다.
**솔루션 1**: `HTTPCode_ELB_5XX` 및 `Latency` 지표를 모니터링합니다. 이러한 지표가 증가하면 유휴 제한 시간 내에 애플리케이션이 응답하지 않을 수 있습니다. 시간이 초과된 요청에 대한 세부 정보에 대해 로드 밸런서에서 액세스 로그를 활성화하고 Elastic Load Balancing이 생성한 로그의 504 응답 코드를 검토합니다. 필요한 경우 용량을 늘리거나 구성된 유휴 제한 시간을 늘려 오래 걸리는 작업(예: 대용량 파일 업로드)을 완료할 수 있습니다. 자세한 내용은 [Classic Load Balancer에 대한 유휴 연결 제한 시간 구성](config-idle-timeout.md) 및 [Elastic Load Balancing 높은 지연 시간을 어떻게 해결합니까?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)를 참조하세요.
**원인 2**: 등록된 인스턴스가 Elastic Load Balancing에 대한 연결을 닫습니다.
**솔루션 2**: EC2 인스턴스에서 연결 유지 설정을 활성화하고 연결 유지 제한 시간이 로드 밸런서의 유휴 제한 시간 설정보다 큰지 확인합니다.
# Classic Load Balancer 문제 해결: 응답 코드 지표
로드 밸런서는 클라이언트에 전송된 HTTP 응답 코드에 대한 지표를 Amazon CloudWatch로 전송하여 오류의 원인을 로드 밸런서 또는 등록된 인스턴스로 식별합니다. 로드 밸런서에 대해 CloudWatch가 반환한 지표를 사용하여 문제를 해결할 수 있습니다. 자세한 내용은 [Classic Load Balancer의 CloudWatch 지표](elb-cloudwatch-metrics.md) 단원을 참조하십시오.
다음은 로드 밸런서, 잠재적인 원인 및 문제를 해결하기 위해 수행할 수 있는 단계에 대해 CloudWatch가 반환한 응답 코드 지표입니다.
**Topics**
+ [HTTPCode\$1ELB\$14XX](#ts-elb-error-metrics-ELB_4XX)
+ [HTTPCode\$1ELB\$15XX](#ts-elb-error-metrics-ELB_5XX)
+ [HTTPCode\$1Backend\$12XX](#ts-elb-error-metrics-Backend_2XX)
+ [HTTPCode\$1Backend\$13XX](#ts-elb-error-metrics-Backend_3XX)
+ [HTTPCode\$1Backend\$14XX](#ts-elb-error-metrics-Backend_4XX)
+ [HTTPCode\$1Backend\$15XX](#ts-elb-error-metrics-Backend_5XX)
## HTTPCode\$1ELB\$14XX
**원인**: 클라이언트의 잘못된 형식 요청 또는 요청 취소.
**Solutions**
+ [HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400)을(를) 참조하세요.
+ [HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405)을(를) 참조하세요.
+ [HTTP 408: 요청 제한 시간](ts-elb-error-message.md#ts-elb-errorcodes-http408)을(를) 참조하세요.
## HTTPCode\$1ELB\$15XX
**원인**: 로드 밸런서 또는 등록된 인스턴스가 오류의 원인이거나 로드 밸런서가 응답을 구문 분석할 수 없습니다.
**Solutions**
+ [HTTP 502: 잘못된 게이트웨이](ts-elb-error-message.md#ts-elb-errorcodes-http502)을(를) 참조하세요.
+ [HTTP 503: 서비스 사용 불가](ts-elb-error-message.md#ts-elb-errorcodes-http503)을(를) 참조하세요.
+ [HTTP 504: 게이트웨이 제한 시간](ts-elb-error-message.md#ts-elb-errorcodes-http504)을(를) 참조하세요.
## HTTPCode\$1Backend\$12XX
**원인**: 등록된 인스턴스의 정상적이고 성공적인 응답.
**솔루션**: 없음.
## HTTPCode\$1Backend\$13XX
**원인**: 등록된 인스턴스에서 보낸 리디렉션 응답.
**솔루션**:인스턴스에서 액세스 로그 또는 오류 로그를 보고 원인을 판단합니다. 응답을 보려면 인스턴스에 직접 요청을 보냅니다(로드 밸런서 우회).
## HTTPCode\$1Backend\$14XX
**원인**: 등록된 인스턴스에서 보낸 클라이언트 오류 응답.
**솔루션**:인스턴스에서 액세스 또는 오류 로그를 보고 원인을 판단합니다. 응답을 보려면 인스턴스에 직접 요청을 보냅니다(로드 밸런서 우회).
**참고**
클라이언트가 `Transfer-Encoding: chunked` 헤더로 시작된 HTTP 요청을 취소하는 경우, 클라이언트가 요청을 취소했더라도 로드 밸런서가 요청을 인스턴스로 전달하는 문제가 알려진 바 있습니다. 이는 백엔드 오류의 원인이 될 수 있습니다.
## HTTPCode\$1Backend\$15XX
**원인**: 등록된 인스턴스에서 보낸 서버 오류 응답.
**솔루션**:인스턴스에서 액세스 로그 또는 오류 로그를 보고 원인을 판단합니다. 응답을 보려면 인스턴스에 직접 요청을 보냅니다(로드 밸런서 우회).
**참고**
클라이언트가 `Transfer-Encoding: chunked` 헤더로 시작된 HTTP 요청을 취소하는 경우, 클라이언트가 요청을 취소했더라도 로드 밸런서가 요청을 인스턴스로 전달하는 문제가 알려진 바 있습니다. 이는 백엔드 오류의 원인이 될 수 있습니다.
# Classic Load Balancer 문제 해결: 상태 확인
로드 밸런서는 Elastic Load Balancing이 제공하는 기본적인 상태 확인 구성이나 사용자가 지정한 상태 확인 구성을 사용하여 등록된 인스턴스의 상태를 확인합니다. 상태 확인 구성에는 프로토콜, ping 포트, ping 경로, 응답 시간 초과 및 상태 확인 간격과 같은 정보가 있습니다. 상태 확인 간격 내에 200 응답 코드가 반환되면 해당 인스턴스는 정상으로 간주됩니다. 자세한 내용은 [Classic Load Balancer의 인스턴스 상태 확인](elb-healthchecks.md) 단원을 참조하십시오.
일부 또는 모든 인스턴스의 현재 상태가 `OutOfService`이고 설명 필드에 `Instance has failed at least the Unhealthy Threshold number of health checks consecutively` 메시지가 표시되는 경우, 인스턴스가 로드 밸런서 상태 확인에 실패한 것입니다. 다음은 살펴봐야 할 문제, 잠재적인 원인 및 문제를 해결하기 위해 수행할 수 있는 단계입니다.
**Topics**
+ [상태 확인 대상 페이지 오류](#ts-elb-healthcheck-targetpage)
+ [인스턴스 연결 시간 초과](#ts-elb-healthcheck-failed)
+ [퍼블릭 키 인증이 실패함](#ts-elb-healthcheck-publickey)
+ [인스턴스가 로드 밸런서에서 트래픽을 수신하지 않음](#ts-elb-healthcheck-securitygroup)
+ [인스턴스의 포트가 열려 있지 않음](#ts-elb-healthcheck-ports)
+ [Auto Scaling 그룹의 인스턴스가 ELB 상태 확인에 실패함](#ts-elb-healthcheck-autoscaling)
## 상태 확인 대상 페이지 오류
**문제**: 지정된 ping 포트 및 ping 경로(예: HTTP:80/index.html)의 인스턴스에 발행된 HTTP GET 요청은 200이 아닌 응답 코드를 수신합니다.
**원인 1**: 인스턴스에 대상 페이지가 구성되어 있지 않습니다.
**솔루션 1**: 등록된 각 인스턴스에서 대상 페이지(예: `index.html`)를 만들고 해당 경로를 ping 경로로 지정합니다.
**원인 2**: 응답의 Content-Length 헤더 값이 설정되어 있지 않습니다.
**솔루션 2**: 응답에 본문이 포함되어 있으면 0보다 크거나 같은 값으로 Content-Length 헤더를 설정하거나 Transfer-Encoding 값을 'chunked'로 설정합니다.
**원인 3**: 애플리케이션이 로드 밸런서에 요청을 받거나 200 응답 코드를 반환하도록 구성되어 있지 않습니다.
**솔루션 3**: 인스턴스에서 애플리케이션을 확인하여 원인을 검사합니다.
## 인스턴스 연결 시간 초과
**문제**: EC2 인스턴스에 대한 로드 밸런서의 상태 확인 요청이 시간 초과되거나 간헐적으로 실패합니다.
먼저 인스턴스와 직접 연결하여 문제를 확인합니다. 인스턴스의 프라이빗 IP 주소를 사용하여 네트워크 내에서 인스턴스에 연결하는 것이 좋습니다.
TCP 연결에 대해 다음 명령을 사용합니다.
```
telnet private-IP-address-of-the-instance port
```
HTTP 또는 HTTPS 연결에 대해 다음 명령을 사용합니다.
```
curl –I private-IP-address-of-the-instance:port/health-check-target-page
```
HTTP/HTTPS 연결을 사용하고 있고 200이 아닌 응답을 받고 있는 경우 [상태 확인 대상 페이지 오류](#ts-elb-healthcheck-targetpage) 단원을 참조하십시오. 직접 연결할 수 있는 경우 다음 사항을 확인합니다.
**원인 1**: 인스턴스가 구성된 응답 제한 시간 내에 응답하지 않습니다.
**솔루션 1**: 로드 밸런서 상태 확인 구성에서 응답 제한 시간을 조정합니다.
**원인 2**: 인스턴스에 상당한 로드가 발생했으며 구성된 응답 제한 시간보다 응답을 하는 데 오래 걸립니다.
**솔루션 2**:
+ CPU의 과다 사용에 대한 모니터링 그래프를 확인합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [특정 EC2 인스턴스에 대한 통계 가져오기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html)를 참조하세요.
+ EC2 인스턴스에 연결하여 메모리 또는 한도 같은 다른 애플리케이션 리소스의 사용률을 확인합니다.
+ 필요에 따라 인스턴스를 더 추가하거나 Auto Scaling을 활성화합니다. 자세한 내용은 [Amazon EC2 Auto Scaling 사용 설명서](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)를 참조하세요.
**원인 3**: HTTP 또는 HTTPS 연결을 사용 중이며 ping 경로 필드에 지정된 대상 페이지(예: `HTTP:80/index.html`) 상태 확인이 수행되고 있는 경우, 대상 페이지가 응답하는 데 구성된 제한 시간보다 오래 걸릴 수 있습니다.
**솔루션 3**: 더 간단한 상태 확인 대상 페이지를 사용하거나 상태 확인 간격 설정을 조정합니다.
## 퍼블릭 키 인증이 실패함
**문제**: 백엔드 인증이 활성화된 HTTPS 또는 SSL 프로토콜을 사용하도록 구성된 로드 밸런서가 퍼블릭 키 인증을 실패합니다.
**원인**: SSL 인증서의 퍼블릭 키가 로드 밸런서에 구성된 퍼블릭 키와 일치하지 않습니다. `s_client` 명령을 사용하여 인증서 체인에 있는 서버 인증서 목록을 확인합니다. 자세한 내용은 OpenSSL 설명서의 [s\$1client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html)를 참조하십시오.
**솔루션**: SSL 인증서를 업데이트해야 할 수 있습니다. SSL 인증서가 최신 상태인 경우 로드 밸런서에 SSL 인증서를 다시 설치해 봅니다. 자세한 내용은 [Classic Load Balancer를 위한 SSL 인증서 교체](elb-update-ssl-cert.md) 단원을 참조하십시오.
## 인스턴스가 로드 밸런서에서 트래픽을 수신하지 않음
**문제**: 인스턴스에 대한 보안 그룹이 로드 밸런서의 트래픽을 차단하고 있습니다.
인스턴스에서 패킷을 캡처하여 문제를 확인합니다. 다음 명령을 사용합니다.
```
# tcpdump port health-check-port
```
**원인 1**: 인스턴스와 연결된 보안 그룹에서 로드 밸런서의 트래픽을 허용하지 않습니다.
**솔루션 1**: 로드 밸런서의 트래픽을 허용하도록 인스턴스 보안 그룹을 편집합니다. 로드 밸런서 보안 그룹의 모든 트래픽을 허용하는 규칙을 추가합니다.
**원인 2**: 로드 밸런서의 보안 그룹은 EC2 인스턴스에 대한 트래픽을 허용하지 않습니다.
**솔루션 2**: 로드 밸런서의 보안 그룹을 편집하여 서브넷 및 EC2 인스턴스에 대한 트래픽을 허용합니다.
보안 그룹 관리에 대한 자세한 내용은 [Classic Load Balancer 보안 그룹 구성](elb-vpc-security-groups.md)을(를) 참조하세요.
## 인스턴스의 포트가 열려 있지 않음
**문제**: 로드 밸런서가 EC2 인스턴스로 전송한 상태 확인이 포트 또는 방화벽에 의해 차단됩니다.
다음 명령을 사용하여 문제를 확인합니다.
```
netstat –ant
```
**원인**: 지정된 상태 확인 포트 또는 리스너 포트(다르게 구성된 경우)가 열려 있지 않습니다. 상태 확인을 위해 지정된 포트와 리스너 포트는 모두 열려 있어야 하며 수신 대기해야 합니다.
**솔루션**: 인스턴스의 상태 확인 구성에 지정된 리스너 포트 및 포트를 열고(다르게 구성된 경우) 로드 밸런서 트래픽을 수신합니다.
## Auto Scaling 그룹의 인스턴스가 ELB 상태 확인에 실패함
**문제**: Auto Scaling 그룹의 인스턴스는 기본 Auto Scaling 상태 확인을 통과했지만 ELB 상태 확인은 통과하지 못했습니다.
**원인** :Auto Scaling은 EC2 상태 확인을 사용하여 인스턴스의 하드웨어 및 소프트웨어 문제를 감지하지만, 로드 밸런서는 인스턴스에 요청을 보내고 200 응답 코드를 기다리거나 인스턴스와 TCP 연결을 설정(TCP 기반 상태 확인)하여 상태 확인을 수행합니다.
인스턴스에서 실행 중인 애플리케이션에는 로드 밸런서가 인스턴스를 서비스에서 제외시키는 것을 고려하게 하는 문제가 있기 때문에 인스턴스가 ELB 상태 확인을 실패할 수 있습니다. 이 인스턴스는 Auto Scaling 상태 확인을 통과할 수 있습니다. 즉, EC2 상태 확인을 기반으로 정상적으로 간주되기 때문에 Auto Scaling 정책에 의해 대체되지 않습니다.
**솔루션**: Auto Scaling 그룹에 대해 ELB 상태 확인을 사용합니다. ELB 상태 확인을 사용하면 Auto Scaling은 인스턴스 상태 확인과 ELB 상태 확인의 결과를 점검하여 인스턴스의 상태를 판단합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [Auto Scaling 그룹에 Elastic Load Balancing 상태 확인 추가](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)를 참조하세요.
# Classic Load Balancer 문제 해결: 클라이언트 연결
## 클라이언트가 인터넷 경계 로드 밸런서에 연결할 수 없음
로드 밸런서가 요청에 응답하지 않는 경우에는 다음 문제를 점검하세요.
**인터넷 경계 로드 밸런서가 프라이빗 서브넷에 연결됩니다.**
로드 밸런서를 위한 퍼블릭 서브넷을 지정해야 합니다. 퍼브릭 서브넷은 가상 프라이빗 클라우드(VPC)를 위한 인터넷 게이트웨이로 연결되는 경로를 가지고 있습니다.
**보안 그룹이나 네트워크 ACL이 트래픽을 허용하지 않음**
로드 밸런서를 위한 보안 그룹과 로드 밸런서 서브넷을 위한 모든 네트워크 ACL은 클라이언트에서의 인바운드 트래픽과 리스너 포트의 클라이언트로의 아웃바운드 트래픽을 허용해야 합니다. 자세한 내용은 [Classic Load Balancer 보안 그룹 구성](elb-vpc-security-groups.md) 단원을 참조하십시오.
## 사용자 지정 도메인으로 전송된 요청은 로드 밸런서에 수신되지 않습니다.
로드 밸런서가 커스텀 도메인에 보낸 요청을 받지 않는 경우에는 다음 문제를 점검하세요.
**사용자 지정 도메인 이름이 로드 밸런서 IP 주소로 확인되지 않음**
+ 명령줄 인터페이스를 사용하여 사용자 지정 도메인 이름이 어떤 IP 주소로 변환되는지 확인합니다.
+ **Linux, macOS 또는 Unix** — 터미널에서 `dig` 명령을 사용할 수 있습니다. Ex.`dig example.com`
+ **Windows** — 명령 프롬프트에서 `nslookup` 명령을 사용할 수 있습니다. Ex.`nslookup example.com`
+ 명령줄 인터페이스를 사용하여 로드 밸런서 DNS 이름이 어떤 IP 주소로 변환되는지 확인합니다.
+ 두 출력의 결과를 비교합니다. IP 주소는 일치해야 합니다.
## 로드 밸런서로 전송된 HTTPS 요청은 “NET: :ERR\$1CERT\$1COMMON\$1NAME\$1INVALID”를 반환합니다.
HTTPS 요청이 로드 밸런서에서 `NET::ERR_CERT_COMMON_NAME_INVALID`을 받는 경우 다음과 같은 가능한 원인을 확인하세요.
+ HTTPS 요청에 사용된 도메인 이름이 리스너 관련 ACM 인증서에 지정된 대체 이름과 일치하지 않습니다.
+ 로드 밸런서의 기본 DNS 이름이 사용되고 있습니다. `*.amazonaws.com` 도메인에 공개 인증서를 요청할 수 없으므로 기본 DNS 이름을 사용하여 HTTPS 요청을 할 수 없습니다.
# Classic Load Balancer 문제 해결: 인스턴스 등록
인스턴스를 로드 밸런서에 등록하면 로드 밸런서가 인스턴스에 요청을 보내기 시작할 때까지 여러 가지 단계가 수행됩니다.
다음은 EC2 인스턴스를 등록할 때 로드 밸런서에서 발생할 수 있는 문제, 잠재적인 원인 및 문제를 해결하기 위해 수행할 수 있는 단계입니다.
**Topics**
+ [EC2 인스턴스를 등록하는 데 너무 오래 걸림](#ts-elb-register-too-long)
+ [유료 AMI에서 시작된 인스턴스를 등록할 수 없음](#ts-elb-paid-ami-instance)
## EC2 인스턴스를 등록하는 데 너무 오래 걸림
**문제**: 등록된 EC2 인스턴스가 `InService` 상태가 되는 데 예상보다 오래 걸립니다.
**원인**: 인스턴스가 상태 확인에 실패할 수 있습니다. 초기 인스턴스 등록 단계가 완료되면(최대 약 30초 소요될 수 있음) 로드 밸런서가 상태 확인 요청을 보내기 시작합니다. 인스턴스는 한 번이라도 상태 확인을 통과할 때까지 `InService` 상태가 되지 않습니다.
**솔루션**: [인스턴스 연결 시간 초과](ts-elb-healthcheck.md#ts-elb-healthcheck-failed) 섹션을 참조하세요.
## 유료 AMI에서 시작된 인스턴스를 등록할 수 없음
**문제**: Elastic Load Balancing은 유료 AMI를 사용하여 시작된 인스턴스를 등록하지 않습니다.
**원인**: 인스턴스가 [Amazon DevPay](https://aws.amazon.com/devpay/)의 유료 AMI를 사용하여 시작되었을 수 있습니다.
**솔루션**: Elastic Load Balancing은 [Amazon DevPay](https://aws.amazon.com/devpay/)의 유료 AMI를 사용하여 시작된 인스턴스 등록을 지원하지 않습니다. [AWS Marketplace](https://aws.amazon.com/marketplace)의 유료 AMI를 사용할 수 있다는 점에 유의하세요. 에서 이미 유료 AMI를 사용하고 AWS Marketplace 있고 해당 유료 AMI에서 시작된 인스턴스를 등록할 수 없는 경우 [AWS Support 센터로](https://console.aws.amazon.com/support/home#/) 이동하여 지원을 받으세요.