로드 밸런서(Load Balancer, LB)에서 발생하는 502 Bad Gateway 오류는 LB가 백엔드 서버(타겟)와 통신하는 과정에서 연결이 거부되거나, 타겟이 LB에 유효하지 않은 응답을 반환했을 때 발생합니다. 502 오류는 LB가 서버에 도달하는 경로 자체에 문제가 있거나, 프로토콜 및 보안 설정이 일치하지 않을 때 발생하는 치명적인 서비스 장애입니다. 이러한 오류를 해결하기 위해서는 헬스 체크(Health Check)와 SSL/TLS 설정을 중심으로 문제를 진단해야 합니다.
1. 헬스 체크 실패로 인한 502 오류
LB는 헬스 체크를 통해 타겟 인스턴스가 요청을 처리할 준비가 되었는지 확인합니다. 인스턴스가 Unhealthy 상태가 되면 LB는 해당 인스턴스로 트래픽을 보내지 않는데, 모든 인스턴스가 Unhealthy 상태이거나, 인스턴스 복구 과정 중에 오류가 발생하면 502 오류가 발생할 수 있습니다.
1.1. 헬스 체크 경로 및 포트 불일치
가장 흔한 원인으로, 헬스 체크 설정이 실제 애플리케이션 상태를 반영하지 못하거나, 잘못된 포트를 지정한 경우입니다.
- 진단: LB의 타겟 그룹(Target Group) 설정에서 헬스 체크의 프로토콜, 포트, 경로(Path)를 확인합니다.
- 경로 불일치: 헬스 체크 경로(예:
/health)가 실제로 서버에서 HTTP 200 상태 코드를 반환하는 엔드포인트와 일치하는지 확인해야 합니다. 만약/경로를 사용하는데 애플리케이션이 아직 완전히 로드되지 않아 5xx 코드를 반환하면 실패합니다. - 포트 불일치: 애플리케이션이 8080 포트에서 실행 중인데 헬스 체크가 80 포트를 확인하도록 설정되어 있으면 실패합니다. 타겟 그룹의 헬스 체크 포트는 반드시 애플리케이션이 리스닝하는 포트와 일치해야 합니다.
- 경로 불일치: 헬스 체크 경로(예:
1.2. 타겟 인스턴스 연결 거부 (Connection Refused)
LB가 헬스 체크 요청을 보냈을 때 타겟 인스턴스가 연결을 거부하는 경우입니다.
- 원인: 타겟 인스턴스(EC2)의 보안 그룹(Security Group) 인바운드 규칙에 LB의 트래픽을 허용하는 규칙이 누락된 경우입니다. LB는 자신의 사설 IP 대역(또는 LB 자체의 보안 그룹 ID)을 통해 헬스 체크를 수행합니다.
- 조치: 타겟 인스턴스의 보안 그룹 인바운드 규칙에 LB가 속한 서브넷의 CIDR 또는 LB의 보안 그룹 ID를 소스로 하여, 헬스 체크 포트(예: 8080)에 대한 접근을 명시적으로 허용해야 합니다.
2. SSL/TLS 핸드셰이크 오류 (ALB만 해당)
Application Load Balancer (ALB)를 사용하고 LB와 타겟 간에 HTTPS 통신을 설정했을 때, 인증서나 프로토콜 불일치로 인해 502 오류가 발생할 수 있습니다.
2.1. 타겟 그룹의 HTTPS 프로토콜 문제
ALB 리스너는 HTTPS로 설정했더라도, 타겟 그룹에서 HTTPS를 사용하는 경우 설정 문제가 발생합니다.
- 원인: 타겟 그룹이 HTTPS를 사용하도록 설정되어 있지만, 타겟 인스턴스의 웹 서버에 유효하지 않은(만료되거나 신뢰할 수 없는) SSL/TLS 인증서가 설치되어 있을 경우, LB는 타겟과의 통신을 중단하고 502 오류를 반환합니다. LB는 타겟 서버의 인증서를 신뢰할 수 있는지 확인합니다.
- 조치: 타겟 인스턴스에 설치된 인증서가 유효하고, 체인 인증서(Certificate Chain)**까지 완벽하게 설치되었는지 확인합니다. 자체 서명 인증서(Self-Signed Certificate)를 사용하는 경우, ALB의 타겟 그룹 설정에서 명시적으로 무시(InsecureSkipVerify)하도록 설정해야 합니다.
2.2. SSL 암호화 스위트 불일치
ALB가 타겟과 SSL/TLS 핸드셰이크를 시도할 때, LB와 타겟 서버가 공통으로 지원하는 암호화 스위트(Cipher Suite)가 없을 경우 연결이 실패합니다.
- 조치: 타겟 서버(예: Nginx, Apache)의 SSL 설정 파일을 확인하여, AWS의 기본 설정(예:
ELBSecurityPolicy-2016-08)에서 지원하는 TLS 프로토콜 버전과 암호화 스위트를 타겟 서버가 지원하도록 구성해야 합니다. TLS 1.0, 1.1과 같이 오래된 버전을 비활성화한 경우, LB의 보안 정책도 이에 맞게 조정해야 합니다.
3. 고급 진단: CloudWatch 및 Access Log 분석
CloudWatch 및 Access Log 분석 위에서 다룬 기본적인 설정 점검(헬스 체크, 타겟 그룹, 보안 그룹, 타임아웃 등)을 모두 완료했음에도 불구하고 502 Bad Gateway 오류가 지속적으로 발생하거나 간헐적으로 나타나는 경우, 단순한 구성 오류를 넘어선 복잡한 네트워크, 애플리케이션, 또는 인프라 수준의 문제가 존재할 가능성이 높습니다. 이러한 고난도 502 오류는 로그 기반의 정밀한 진단을 통해서만 근본 원인을 파악하고 해결할 수 있습니다. 특히 AWS 환경에서는 Amazon CloudWatch와 Elastic Load Balancer(ELB)의 Access Log가 핵심 진단 도구로 활용되며, 이 두 로그를 체계적으로 분석함으로써 오류 발생 시점, 패턴, 그리고 세부 원인을 정확히 추적할 수 있습니다. 아래에서는 CloudWatch 지표와 Access Log를 활용한 고급 진단 기법을 단계별로 상세히 설명하고, 실제 로그 필드 해석법과 함께 실전 대응 방안을 제시합니다.
3.1. CloudWatch 지표 분석: 오류 발생 시점과 패턴 파악
AWS CloudWatch는 Application Load Balancer(ALB), Network Load Balancer(NLB), Classic Load Balancer(ELB)의 다양한 메트릭을 실시간으로 수집하며, 502 오류의 발생 패턴과 근원지를 구분하는 데 필수적인 지표를 제공합니다. 단순히 오류가 발생했다는 사실을 넘어, ‘로드 밸런서 자체에서 발생했는지’, ‘타겟 인스턴스에서 발생했는지’, ‘네트워크 레벨에서 차단되었는지’ 를 정량적으로 판단할 수 있습니다.
주요 CloudWatch 지표 해설
| 지표 이름 | 설명 | 502 오류 진단 시 의미 |
|---|---|---|
| HTTPCode_Target_5XX_Count | 타겟(EC2, ECS, Lambda 등)이 5xx 응답을 반환했을 때 증가 | 이 값이 증가하면 애플리케이션 레벨 오류(예: 502, 503, 504)가 타겟에서 발생. 애플리케이션 로그 확인 필수. |
| HTTPCode_ELB_5XX_Count | 로드 밸런서 자체에서 5xx 오류를 생성했을 때 증가 | 주로 503(용량 초과) 발생. 502는 여기에 포함되지 않음. 따라서 502 오류가 발생했는데 이 값이 0이라면, 타겟 연결 실패가 원인. |
| HealthyHostCount / UnHealthyHostCount | 헬스 체크 통과/실패한 타겟 수 | UnHealthyHostCount가 증가하면 헬스 체크 실패 → 502 유발 가능. |
| TargetConnectionErrorCount | LB가 타겟과 TCP 연결 수립 실패 시 증가 | 502의 주요 원인. 보안 그룹, NACL, 타겟 종료 상태 확인 필요. |
| TargetResponseTime | 타겟 응답 시간 | 응답 지연이 길면 타임아웃 → 502 또는 504로 변환될 수 있음. |
실전 진단 예시
- 상황: 502 오류 발생, HTTPCode_Target_5XX_Count = 0, HTTPCode_ELB_5XX_Count = 0, TargetConnectionErrorCount > 0
- 해석: 로드 밸런서와 타겟 간 TCP 연결 자체가 실패 → 보안 그룹 인바운드 규칙 누락, 타겟 인스턴스 종료, 포트 차단, NACL 차단 등이 의심됨.
- 조치: aws elbv2 describe-target-health 명령어로 타겟 상태 확인 → Reason: Target.ConnectionError 확인 시 네트워크 점검.
- 상황: HTTPCode_Target_5XX_Count > 0, 애플리케이션 로그에 502 기록 없음
- 해석: 타겟이 유효하지 않은 HTTP 응답(예: 빈 바디, 잘못된 헤더, 연결 중단)을 반환 → LB가 502로 변환.
- 조치: 애플리케이션 로그(Nginx, Apache, Node.js 등)에서 upstream prematurely closed connection 확인.
3.2. 로드 밸런서 Access Log 분석: 세부 오류 원인 추적
ALB/NLB의 Access Log는 S3 버킷에 저장되며, 클라이언트 요청 ~ LB ~ 타겟 간 상호작용의 모든 세부 정보를 기록합니다. 특히 502 오류 발생 시, 일반적인 웹 서버 로그에서는 볼 수 없는 LB-타겟 간 통신 실패 원인을 정확히 진단할 수 있는 가장 강력한 도구입니다.
Access Log 활성화 방법 (필수!)
- ALB 콘솔 → Attributes → Access logs → S3 버킷 지정 및 활성화
- 로그 형식: 텍스트 기반, 공백으로 구분된 필드 (공식 문서 참조)
핵심 진단 필드 해설
| 필드 | 설명 | 502 오류 시 진단 포인트 |
|---|---|---|
| target_status_code | 타겟이 반환한 HTTP 상태 코드 | 비어 있거나 – 또는 000 → LB가 타겟과 TCP 연결조차 수립하지 못함 → 보안 그룹, NACL, 타겟 포트 미수신, 인스턴스 다운 |
| error_reason (ALB 전용) | 502/504 오류 발생 시 구체적인 실패 사유 코드 | 가장 중요한 진단 필드. 아래에서 상세 해설. |
| target_processing_time | 타겟 응답 처리 시간 | -1이면 타겟 응답 없음 → 타임아웃 또는 연결 실패 |
| elb_status_code | LB가 클라이언트에게 반환한 코드 | 502 확인 |
| target:port | 연결 시도한 타겟 포트 | 포트 불일치 여부 확인 |
error_reason 필드 상세 해설 (ALB 전용)
ALB Access Log에서 error_reason은 502 오류의 정확한 기술적 원인을 코드 형태로 제공합니다. 아래는 자주 발생하는 코드와 대응 방안입니다.
| error_reason 코드 | 의미 | 주요 원인 | 해결 방안 |
|---|---|---|---|
| Target_TLS_Error | TLS 핸드셰이크 실패 | – 타겟의 SSL 인증서 만료/신뢰 불가 – 암호화 스위트(Cipher Suite) 불일치 – SNI 불일치 | – ACM 또는 타겟 서버 인증서 갱신 – ALB와 타겟 간 지원 암호화 스위트 확인 – aws acm list-certificates로 상태 점검 |
| Target_Timeout | 타겟 응답 지연 | – 애플리케이션 처리 지연 – DB 쿼리 타임아웃 – 헬스 체크와 응답 타임아웃 설정 불일치 | – TargetResponseTime 지표 확인 – 애플리케이션 성능 튜닝 – ALB 타임아웃 값 증가 (Idle timeout 조정) |
| Target_InvalidResponse | 타겟이 유효하지 않은 HTTP 응답 반환 | – 빈 응답, 잘못된 헤더, 프로토콜 위반 – Nginx proxy_read_timeout 초과 후 연결 종료 | – 웹 서버 로그에서 upstream 오류 확인 – keepalive 설정 조정 |
| Target_ConnectionError | TCP 연결 수립 실패 | – 보안 그룹 인바운드 규칙 누락 – NACL 차단 – 타겟 인스턴스 종료/재부팅 중 | – aws ec2 describe-instances로 상태 확인 – 보안 그룹 인바운드: ALB SG → 타겟 SG, 포트 허용 |
| Target_Unhealthy | 헬스 체크 실패 | – 헬스 체크 경로 오류 – 타겟이 2xx/3xx 응답 반환 안 함 | – 헬스 체크 경로 /health, 응답 코드 200 설정 – 애플리케이션 헬스 엔드포인트 구현 |
실전 로그 분석 예시 (S3에서 다운로드한 로그 라인)
text
time=2025-04-05T10:23:45.123Z elb=app/my-alb/abc123 type=https elb_status_code=502 target_status_code=- error_reason=Target_ConnectionError target=10.0.1.100:8080 target_processing_time=-1.0해석:
- target_status_code=- → 타겟과 연결 실패
- error_reason=Target_ConnectionError → TCP 레벨 연결 불가
- 원인 후보: 보안 그룹, NACL, 타겟 인스턴스 다운, 포트 미수신
- 조치:
- aws ec2 describe-instances –instance-ids i-xxx → 인스턴스 상태 확인
- 보안 그룹: ALB SG → 타겟 SG, 8080 포트 인바운드 허용 여부
- telnet 10.0.1.100 8080 또는 nc -zv로 연결 테스트
추가 고급 팁
- CloudWatch Logs Insights로 Access Log 쿼리 sql
fields @timestamp, elb_status_code, target_status_code, error_reason | filter elb_status_code = 502 | stats count(*) by error_reason, bin(5m)→ 5분 단위로 error_reason별 502 오류 추이 시각화 - 헬스 체크와 Access Log 연계 분석
- UnHealthyHostCount 증가 시점과 Access Log의 Target.ConnectionError 동기화 여부 확인
- VPC Flow Logs 활성화
- 네트워크 레벨 차단 여부 확인 (REJECT 로그 탐지)
결론: 로그 기반 진단의 중요성
502 Bad Gateway 오류는 겉으로는 단순해 보이지만, 내부적으로는 네트워크, 보안, 애플리케이션, SSL 등 다층적 원인이 얽혀 있는 복합 장애입니다. 따라서 CloudWatch 지표로 패턴을 파악하고, Access Log의 error_reason으로 정밀 진단하는 두 단계 접근법이 필수입니다. 이 과정을 자동화하기 위해 CloudWatch 알람 + SNS 알림 + Lambda 자동 분석 스크립트를 구축하면, 장애 발생 즉시 근본 원인을 파악하고 신속히 대응할 수 있습니다. 궁극적으로, 로그 기반의 체계적인 진단 체계를 구축하는 것이 고가용성 아키텍처의 핵심이라 할 수 있습니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.