ALB 502 Bad Gateway 주요 원인 분석'
1. 타겟의 연결 조기 종료 (Keep-Alive Timeout) [가장 흔한 원인]
ALB와 백엔드 서버(Apache, Nginx, Tomcat 등)는 성능을 위해 연결을 유지(Keep-Alive)합니다. 그런데 서버가 ALB보다 먼저 연결을 끊어버리면, ALB는 살아있는 줄 알고 패킷을 보냈다가 거절당해 502를 뱉습니다.
원인: 백엔드 서버의 Keep-Alive Timeout 설정값이 ALB의 유휴 제한 시간(Idle Timeout, 기본 60초)보다 짧을 때 발생합니다.
해결: 백엔드 서버(Nginx 등)의 Keep-Alive Timeout을 ALB의 유휴 제한 시간보다 크게(예: 65~70초) 설정하세요.
2. 애플리케이션의 비정상적 응답
타겟 서버는 살아있지만, 보내온 데이터가 HTTP 규격에 맞지 않는 경우입니다.
원인: 애플리케이션이 응답 헤더(Header)를 제대로 생성하지 못함.
헤더 크기가 ALB가 허용하는 범위를 초과함.
서버가 응답을 보내는 도중에 프로세스가 크래시(Crash)됨.
해결: 애플리케이션 로그를 확인하여 특정 요청에서 에러가 나는지 확인하고, 필요하다면 타겟 그룹의 'Attributes'에서 헤더 크기 제한을 조정하세요.
3. TLS/SSL 핸드셰이크 실패 (Backend HTTPS 사용 시)
ALB와 타겟 사이의 통신을 HTTPS(443)로 설정했을 때 발생합니다.
원인: 타겟 서버의 인증서가 만료됨.
ALB가 지원하지 않는 암호화 알고리즘(Cipher Suite)을 서버가 사용함.
해결: 타겟 서버의 인증서 유효성을 확인하고, ALB와 서버 간의 TLS 버전을 일치시키세요.
3단계 트러블슈팅
단계 | 작업 내용 | 확인 포인트 |
1단계: Access Log 분석 | S3에 저장된 ALB Access Log를 확인합니다. |
|
2단계: 타겟 상태 확인 | Target Group의 Health Check 상태를 봅니다. |
|
3단계: 패킷 캡처 | 필요하다면 타겟 서버에서 | TCP 연결이 |
Tip
502 에러가 간헐적으로 발생한다면 99%는 Keep-Alive Timeout 설정 미스입니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.