502 Bad Gateway 오류 원인 분석 및 해결: DevOps 엔지니어를 위한 실전 사례와 베스트 프랙티스

최종 업데이트: 2026년 6월. 이 가이드는 HTTP/3(QUIC), Kubernetes Gateway API, eBPF 기반 관측성, 서비스 메시 등 최신 운영 환경을 반영해 보강되었습니다. 핵심 원리는 그대로 유효하며, 현재 시점에서 바로 적용 가능한 내용을 추가했습니다.

30초 요약 (TL;DR)

• 502 Bad Gateway는 게이트웨이/프록시가 업스트림으로부터 “잘못된 응답” 또는 “연결 실패/리셋”을 받았다는 신호입니다. 시간 초과가 원인이면 504, 애플리케이션 내부 오류면 500입니다.
• 가장 흔한 5대 원인: ① 업스트림 프로세스 다운·연결 거부, ② 잘못된/과대한 응답 헤더(쿠키 폭증), ③ 프로토콜 불일치(gRPC·HTTP/2를 HTTP/1.1로 프록시), ④ 타임아웃·keepalive 미정렬, ⑤ 배포 중 커넥션 드레인 미설정.
• 가장 빠른 1차 진단: 각 홉(CDN → 로드밸런서 → 프록시 → 앱)의 5xx 비율을 비교해 502가 처음 증가한 홉을 찾고, 그 홉의 로그에서 정확한 에러 문자열을 확인합니다.
• 즉시 실행할 명령: curl -v --http2 https://도메인, openssl s_client -connect origin:443 -alpn h2,http/1.1, NGINX error.log tail, aws elbv2 describe-target-health.
• 예방의 핵심: 모든 홉의 타임아웃 매트릭스 정렬 + 정확한 readiness/startup 프로브 + preStop 드레인.

왜 502 Bad Gateway가 중요한가

웹 트래픽이 복잡해진 오늘, 클라이언트 → CDN → WAF → 로드 밸런서 → 리버스 프록시 → 애플리케이션 → 내부 서비스로 이어지는 체인 어느 지점에서라도 미묘한 설정/네트워크 문제 하나로 502 Bad Gateway가 발생할 수 있습니다. 사용자에게는 단순히 “사이트가 안 된다”로 보이지만, DevOps 엔지니어에게 502는 레이어 간 경계에서 실패가 일어났다는 신호입니다. 이 글은 실전에서 자주 겪는 502 유형을 구조적으로 분해하고, 재현·진단·해결까지 바로 적용할 수 있는 실용 가이드를 제공합니다.

참고로, 502와 504의 차이는 다음과 같습니다:

• 502 Bad Gateway: 게이트웨이/프록시가 업스트림으로부터 “잘못된 응답” 혹은 “연결 실패/리셋”을 받았을 때.
• 504 Gateway Timeout: 게이트웨이/프록시가 업스트림의 응답을 제때 받지 못했을 때.

둘은 원인이 겹치기도 하지만, 대체로 502는 “프로토콜/연결/응답 형식 문제”, 504는 “시간 초과/지연”에 가깝습니다.

502가 발생하는 경로를 이해하기

전형적 요청 경로:

Client → DNS → CDN/Edge → WAF/Rate Limiter → Load Balancer (ALB/NGINX/HAProxy/Istio) → App Gateway/Ingress → Service → Pod/VM → App Server → Downstream (DB, gRPC, 내부 HTTP)

어디서 502가 발생하는지는 반환 주체의 로그와 지표로 식별합니다.

• CDN/Edge(CloudFront, Cloudflare): 502를 자체로 반환할 수 있습니다.
• L7 로드 밸런서(ALB/Envoy/NGINX/HAProxy): 업스트림이 비정상 응답/연결을 줄 때 502를 반환합니다.
• 리버스 프록시(NGINX/Apache): 업스트림이 헤더를 잘못 보냈거나 연결을 닫았을 때 502를 반환합니다.

핵심은 “각 홉마다 5xx를 측정”하고, 어디서 5xx가 증가하는지 먼저 좁히는 것입니다.

흔한 원인별 심층 분석

1) 업스트림 연결 실패/리셋/거부

• 증상: NGINX 에러 로그에 “connect() failed (111: Connection refused)”, “upstream prematurely closed connection”
• 원인: 포트 미리스닝, 보안 그룹/iptables 막힘, 프로세스 다운, SYN backlog 포화.
• 해결:
  • 포트/리스너 확인: ss -ltnp 또는 netstat -plnt
  • 방화벽/Security Group/NACL 확인
  • 커널 튜닝: net.core.somaxconn, tcp_max_syn_backlog
  • 애플리케이션 크래시 루프 해결 및 헬스체크 점검

2) 애플리케이션이 응답 헤더를 잘못 보냄

• 증상: “upstream sent invalid header while reading response header from upstream”
• 원인: 공백/개행 포함된 헤더, 헤더 크기 초과, 중복/잘못된 status line.
• 해결:
  • 애플리케이션 프레임워크에서 헤더 검증/필터
  • NGINX/Haproxy 버퍼 조정(아래 예시 참고)

3) 프로토콜/암호화 불일치

• 사례: gRPC(HTTP/2) 트래픽을 NGINX에서 proxy_pass(HTTP/1.1)로 프록시, HTTP→HTTPS 오리진, SNI/ALPN 미스매치, h2c(암호화 없는 HTTP/2)와 TLS 혼동
• 해결:
  • gRPC는 grpc_pass, h2/h2c 설정 확인
  • upstream이 HTTPS면 proxy_ssl_server_name on, SNI 설정
  • ALPN(h2) 사용 여부 확인

4) 타임아웃/Keepalive/커넥션 풀 불일치

• 증상: 간헐 502 또는 504, 피크 시간에 집중
• 원인: ELB/NGINX/애플리케이션 각 레이어의 timeout/keepalive 미정렬, idle connection 재사용 중 RST
• 해결:
  • 모든 레이어의 타임아웃을 문서화하고 호환되게 정렬
  • connection draining/keepalive 설정 조율
  • 서버/클라이언트의 idle timeout 차이를 줄이기

5) 리소스 고갈

• 증상: OOMKilled, 파일 디스크립터 고갈(EMFILE), 스레드/워크 프로세스 부족
• 해결:
  • ulimit -n 증가, 애플리케이션/웹서버 worker tuning
  • 메모리/CPU 리소스 상향, 자동 확장 조건 강화
  • 백프레셔/큐 제한

6) 배포/롤링 업데이트 중 창(空) 구간

• 증상: 롤링 업데이트 시 502 스파이크
• 원인: readinessProbe 부정확, preStop/drain 미설정, ALB deregistration delay 불일치, maxUnavailable 과도
• 해결:
  • readinessProbe 정확화, startupProbe 추가
  • preStop에서 드레인/슬립
  • PDB(Pod Disruption Budget), 롤링 파라미터 조정
  • ALB deregistration delay/connection draining 정렬

7) CDN/WAF/프록시 계층의 정책

• 증상: 특정 경로/헤더 패턴에서만 502
• 원인: 헤더 크기 제한, 차단 규칙, 오리진 TLS 핸드셰이크 오류
• 해결:
  • WAF 로그/CloudFront/Cloudflare Ray ID로 역추적
  • 오리진 인증서/암호군/프로토콜 호환성 점검

8) DNS/네트워크 문제

• 증상: upstream DNS를 못 찾거나 sporadic 실패
• 원인: /etc/resolv.conf 오류, CoreDNS/Route 53 레이턴시, MTU/PMTU 블랙홀
• 해결:
  • 애플리케이션과 프록시의 DNS 캐시 TTL 최적화
  • MTR/tracepath로 경로 진단, MTU 조정

재현과 1차 분기: 빠른 트러블슈팅 플로우

1. 사용자 영향도 파악

• 언제부터, 어느 경로/도메인/메서드/리전에서? 배포/스케일링과 상관?
• 에러율과 p50/p95 레이턴시, 트래픽 볼륨 확인

2. 각 홉의 5xx 지표 비교

• CDN → LB → 프록시 → 앱 순으로 5xx 레이트를 비교해 502가 “처음” 증가한 홉을 찾습니다.
• 분산 트레이싱에서 에러가 발생한 스팬 위치 확인

3. 재현 테스트

• 클라이언트 측:
  • curl -v https://example.com/path
  • curl -v --http2 https://example.com
  • curl -v --resolve example.com:443:ALB_IP https://example.com
• 프록시 내부에서 업스트림 직접 호출:
  • curl -v http://app:8080/health
  • grpcurl -vv -d '{}' -H 'authorization: Bearer ...' app:50051 list
• TLS/ALPN 확인:
  • openssl s_client -connect origin:443 -servername origin.host -alpn h2,http/1.1

4. 로그/메트릭 확인

• NGINX error.log, HAProxy log, ALB target health, CloudFront x-edge-result-type
• 애플리케이션 로그의 크래시/stacktrace/timeout
• 시스템 리소스: CPU, 메모리, FD, TCP 상태(ss -s)

NGINX에서 자주 보는 502와 즉시 적용 팁

에러 로그 패턴과 대응

• upstream prematurely closed connection while reading response header from upstream
  • 앱이 헤더 전송 전에 종료/크래시. 앱 타임아웃/워커 튜닝, 크래시 로그 확인.
• upstream sent too big header while reading response header from upstream
  • Set-Cookie/헤더가 큼. 버퍼 확장 또는 헤더 다이어트.

권장 설정 스니펫

http {
  # 큰 헤더/쿠키 대응
  large_client_header_buffers 4 16k;

  # 업스트림 커넥션 풀
  upstream backend {
    server app1:8080 max_fails=3 fail_timeout=10s;
    server app2:8080 max_fails=3 fail_timeout=10s;
    keepalive 64;
  }

  server {
    listen 443 ssl http2;

    proxy_http_version 1.1;
    proxy_set_header Connection "";

    proxy_connect_timeout 3s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;

    # 업스트림 헤더/바디 버퍼
    proxy_buffering on;
    proxy_buffers 16 16k;
    proxy_busy_buffers_size 64k;
    proxy_buffer_size 16k;

    # HTTPS 업스트림이면
    # proxy_pass https://backend;
    # proxy_ssl_server_name on;

    location / {
      proxy_pass http://backend;
      proxy_next_upstream error timeout http_502 http_503 http_504 non_idempotent;
    }
  }
}

gRPC 프록시 시 주의

server {
  listen 443 ssl http2;

  # gRPC는 grpc_pass 필수
  location /my.Greeter/ {
    grpc_pass grpcs://grpc-backend:443; # h2 over TLS
    grpc_read_timeout 30s;
    grpc_send_timeout 30s;
  }

  # h2c(plaintext)일 경우
  # grpc_pass grpc://grpc-backend:50051;
}

HAProxy에서의 502 대응 포인트

global
  maxconn 100000
  tune.bufsize 32768
  tune.ssl.default-dh-param 2048

defaults
  mode http
  option httplog
  timeout connect 3s
  timeout client  30s
  timeout server  30s
  option http-keep-alive
  option redispatch
  retries 3

backend app
  balance roundrobin
  option httpchk GET /health
  http-check expect status 200
  server s1 10.0.1.10:8080 check maxconn 2000
  server s2 10.0.1.11:8080 check maxconn 2000
  http-reuse safe
  # 과부하 시 연결 드랍 대신 백프레셔
  # queue 2000

• 타임아웃 정렬: timeout connect/server/client가 애플리케이션과 LB와 맞물리도록 문서화합니다.
• httpchk/expect로 헬스체크 정확도 개선.
• http-reuse로 연결 재사용 최적화, 단 idle timeout 미스매치 주의.

AWS ALB/ELB, CloudFront에서의 502

• ALB 502는 주로 타깃이 비정상 응답(잘못된 헤더/조기 종료) 또는 TLS 핸드셰이크 실패일 때 발생합니다.
• 점검 항목:
  • Target Group 헬스체크 경로와 앱 준비 상태 정렬
  • Deregistration delay와 앱 종료 그레이스 기간 일치
  • Slow start 사용 시 워밍업 트래픽 조정
  • TLS: 인증서 체인, SNI, 보안 정책(프로토콜/암호군) 호환성
• CloudFront 502:
  • Origin(예: ALB) 핸드셰이크 실패, Origin 응답 헤더 오류
  • Origin Keep-Alive와 CloudFront Origin Response Timeout 정렬
  • 특정 헤더/쿠키를 Origin에 전달할지 수동 제어하여 헤더 크기 폭발 방지

Kubernetes에서 502 줄이는 배포 운영

• readinessProbe와 startupProbe 분리:

readinessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 2
startupProbe:
  httpGet: { path: /startup, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2

• graceful shutdown:

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 10"]
terminationGracePeriodSeconds: 30

• 롤링 파라미터:

strategy:
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0

• PDB 구성으로 동시 축출 방지:

minAvailable: 90%

• Ingress/Service 타임아웃, NLB/ALB deregistration delay와 정렬

애플리케이션별 튜닝 포인트

Node.js (Express)

• 에러: “write after end” 이후 연결 종료 → NGINX가 502
• 조치:
  • http.Agent keepAlive: true, maxSockets/FreeSockets 조정
  • PM2/cluster로 워커 확장
  • 대형 헤더/쿠키 제한, 응답 스트림 시 에러 핸들링

const agent = new http.Agent({ keepAlive: true, maxSockets: 1024 });
axios.create({ httpAgent: agent, httpsAgent: agent, timeout: 30000 });

Python (Gunicorn/Uvicorn)

• gunicorn --workers (CPU*2+1) 기준, async worker는 gevent/uvicorn workers 고려
• timeout 30s 이상 필요 시 프록시/ALB와 정렬
• keepalive 2-5s, 헤더 크기 제한 시 proxy_buffers 확장

PHP-FPM

• “upstream sent too big header” → fastcgi 버퍼 조정

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

• pm = dynamic/ondemand, pm.max_children, pm.max_requests로 안정화

Java (Tomcat/Undertow)

• maxThreads, acceptCount, connectionTimeout 조정
• AJP 대신 HTTP connector 권장, HTTP/2 사용 시 thread model 점검

Go (net/http)

• Transport 튜닝:

&http.Transport{
  MaxIdleConns:        100,
  MaxIdleConnsPerHost: 100,
  IdleConnTimeout:     90 * time.Second,
  TLSHandshakeTimeout: 5 * time.Second,
  ExpectContinueTimeout: 1 * time.Second,
}

• 컨텍스트 타임아웃으로 백프레셔 구현

gRPC

• 클라이언트/서버 모두 keepalive/HTTP2 ping 설정 조정
• LB/프록시가 h2/h2c를 지원하는지 확인, NGINX는 grpc_pass 필수

실전 사례로 보는 502 원인과 해결

사례 1: gRPC를 HTTP/1.1로 프록시한 실수

• 증상: 특정 gRPC 메서드에만 502 (NGINX)
• 원인: proxy_pass 사용으로 HTTP/2 프레이밍이 깨짐
• 해결: grpc_pass로 변경, http2 리스너 보장, ALPN(h2) 활성화
• 교훈: 프로토콜 호환성부터 의심하자

사례 2: 쿠키 폭증으로 인한 헤더 초과

• 증상: 로그인 후 트래픽에서만 502 증가, “upstream sent too big header”
• 원인: 마케팅/AB 테스트 쿠키 누적
• 해결: 쿠키 범위/만료 정리, NGINX proxy_buffers 확장, 애플리케이션에서 Set-Cookie 다이어트
• 교훈: 헤더 크기 관리는 보안/성능/안정성 모두에 중요

사례 3: 롤링 업데이트 중 드레인 미설정

• 증상: 배포마다 1~2분 502 스파이크
• 원인: readinessProbe 즉시 OK, preStop 없음, ALB deregistration delay 300s로 불일치
• 해결: preStop 10s + readiness 지연, startupProbe 추가, deregistration 10~15s로 정렬
• 교훈: “준비됨”의 정의를 엄격히 관리

사례 4: TLS 체인/ALPN 불일치로 인한 Edge 502

• 증상: CloudFront에서 리전별 502
• 원인: 오리진 인증서 체인 누락, 일부 PoP에서 핸드셰이크 실패
• 해결: 중간 인증서 포함, 보안 정책/ALPN 점검
• 교훈: TLS는 “환경별” 편차가 심함. 반드시 외부 synthetic 테스트를 병행

관측 가능성(Observability)로 502를 ‘보이게’ 만들기

• 로그
  • 경계 지점(LB/프록시)과 애플리케이션 로그에 Correlation-ID/X-Request-ID 일관 적용
  • NGINX: error_log notice 이상, 업스트림 상세 에러 메시지 확인
• 메트릭
  • 계층별 5xx, p95/p99 레이턴시, 연결 수, 재시도/리다이렉션 비율
  • 시스템: FD, TCP ESTABLISHED/CLOSE_WAIT, 메모리, GC
• 트레이싱
  • 요청이 끊기는 스팬 위치를 확인해 특정 홉을 지목
• 시냅틱 모니터링
  • 외부/내부 synthetic 체크로 경로별 가시성 확보
• 경보
  • 단순 5xx 알람 대신 “폭/지속 시간” 기반, 배포 이벤트와 상관 분석

타임아웃/리트라이라인먼트 베스트 프랙티스

• 원칙: 가까운 곳에서 짧게 타임아웃, 멀리 갈수록 조금 넉넉히. 리트라이는 멱등 요청만.
• 예시(참고값):
  • CDN Origin timeout: 3~5s
  • LB connect: 23s, read: 1530s
  • 프록시 read/send: 30s
  • 앱 내부 HTTP/gRPC: 2~5s
  • DB: 서비스 특성에 맞춰 별도 설계
• 리트라이
  • 502/503/504에 대해 idempotent 메서드(GET, HEAD)만, 지수 백오프 + Jitter
  • X-Retry-Attempt 헤더로 재시도 횟수 전파
• 회로 차단기(Circuit Breaker)
  • 연쇄 장애 방지, 히스토리 기반 열림/반개방 상태
• 연결 드레인
  • 롤링/축출/스케일인 시 활성 연결이 자연 종료되도록 확보

즉시 사용할 수 있는 502 트러블슈팅 러ン북

1. 장애 감지

• 5xx 알람 → 대시보드에서 CDN/LB/프록시/앱 5xx 비교

2. 재현 및 스코핑

• curl -v, --http2, --resolve로 경로별 재현
• 내부에서 업스트림 직접 호출, grpcurl/openssl로 프로토콜 검증

3. 로그/메트릭 수집

• NGINX/HAProxy/ALB 로그에서 최초 에러 발생 지점 확인
• 애플리케이션 크래시/타임아웃 로그 수집
• 시스템 리소스, FD, TCP 상태

4. 원인 규명 빠른 체크리스트

• 배포/스케일링/구성 변경 있었는가?
• 인증서/ALPN/프로토콜 변경?
• 헤더/쿠키 크기 증가?
• 헬스체크/프루브 실패/지연?
• 타임아웃/keepalive 불일치?

5. 조치

• 설정 수정(버퍼/타임아웃/프로토콜), 롤백 또는 핫픽스
• 트래픽 셰이핑(레이트 리미트), 캐시 우회/활성화
• 재시도/서킷 브레이커 파라미터 조정

6. 사후 분석

• 재발 방지 액션 등록: 테스트 케이스/룰/대시보드/런북 업데이트
• SLO/에러 버짓 소모 평가, 최적화 항목 우선순위화

진단에 유용한 명령어 모음

• curl: 프로토콜/헤더/리다이렉션 확인
  • curl -v https://example.com
  • curl -v --http2 https://example.com
  • curl -v --resolve example.com:443:1.2.3.4 https://example.com
• openssl: TLS/ALPN
  • openssl s_client -connect origin:443 -servername origin.host -alpn h2,http/1.1
• grpcurl: gRPC 엔드포인트 검사
  • grpcurl -vv origin:50051 list
• 네트워크/FD:
  • ss -s; ss -ltnp; lsof -p $PID | wc -l
  • ulimit -n
• DNS/경로:
  • dig +trace example.com
  • mtr -rwz example.com
• 쿠버네티스:
  • kubectl describe ing/svc/pod
  • kubectl logs -f deploy/app -c app
  • kubectl get ev --sort-by=.lastTimestamp
• AWS:
  • aws elbv2 describe-target-health
  • aws cloudfront get-distribution-config

배포 전략과 카오스 엔지니어링으로 502 예방

• 카나리/블루-그린: 5xx/레이트 격리 관찰 후 점진 확장
• 기능 플래그: 서버 응답 경로를 점진적으로 개방
• 카오스 테스트:
  • 업스트림 RST, 헤더 초과, TLS 실패 시나리오 주입
  • 자동화된 리트라이/서킷 브레이커 동작 검증
• 구성 검증
  • NGINX -t/HAProxy -c 검증을 CI에 포함, staging에서 synthetic 테스트

보안/정책 레이어 고려사항

• WAF/봇 차단/레이팅 제한이 502를 유발하는지 로그로 상관 분석
• 헤더 필터링 정책이 Set-Cookie, Authorization 등을 변형하지 않는지 확인
• MTLS/클라이언트 인증서 사용 시 체인/CRL/만료/서명 알고리즘 호환성 검증

502와 친척 에러 구분하기

• 500 Internal Server Error: 업스트림 애플리케이션 자체 오류(정상 연결/정상 형식 응답)
• 502 Bad Gateway: 게이트웨이에서 업스트림의 응답이 “잘못되었거나” 연결 자체가 문제
• 503 Service Unavailable: 임시 과부하/메인터넌스, 헬스체크 실패
• 504 Gateway Timeout: 업스트림 응답 지연으로 시간 초과
• 520/521/522(Cloudflare), 5xx 다양: 벤더별 내부 사유 코드. 원인 맵핑 문서화 필요

최종 체크리스트: 운영 환경에 바로 적용

• 타임아웃/keepalive 매트릭스 문서화(모든 홉)
• 헬스체크/프로브 경로와 실제 준비 상태 정합
• 배포 드레인(preStop, deregistration delay), 롤링 파라미터 검증
• 헤더/쿠키 크기 상한 관리, 프록시 버퍼 조정
• 프로토콜(gRPC/h2/h2c/HTTPS/SNI/ALPN) 호환성 테스트
• 관측성(로그/메트릭/트레이싱) 표준화 및 Correlation-ID 일관성
• 리트라이/서킷 브레이커/백프레셔 설정
• 용량 계획과 자동 확장 정책 점검(HPA, max surge/unavailable, queue length)
• CDN/WAF 정책과 오리진 설정 합치
• 카오스/시뮬레이션 테스트 정기화

2026 운영 관점 업데이트: 최신 환경에서의 502

기존 원인 분석은 그대로 유효합니다. 다만 최근 2년간 프록시·오케스트레이션·관측성 스택이 빠르게 바뀌면서 502가 나타나는 “새로운 표면”이 생겼습니다. 아래는 현재(2026년) 환경에서 추가로 점검해야 할 항목입니다.

HTTP/3(QUIC) 환경에서의 502

CDN(CloudFront·Cloudflare·Fastly)과 브라우저가 HTTP/3(QUIC, UDP 443)을 기본 협상하면서, 엣지는 HTTP/3로 받고 오리진은 HTTP/1.1·HTTP/2로 다시 연결하는 프로토콜 다운그레이드 구간이 새로운 502 지점이 되었습니다.

• 증상: 특정 네트워크(모바일·기업 방화벽)에서만 간헐 502/연결 실패. UDP 443이 차단된 환경에서 QUIC 폴백이 깔끔하지 않을 때 발생.
• 점검: 엣지–오리진 간 프로토콜을 명시적으로 고정(예: 오리진은 HTTP/2 keep-alive). curl --http3 https://도메인 으로 재현, Alt-Svc 헤더 확인.
• 권장: 오리진 keep-alive 타임아웃을 엣지의 origin keep-alive보다 길게 설정해 idle 재사용 중 RST로 인한 502를 방지.

Kubernetes Gateway API와 Ingress의 전환

Ingress는 동결(frozen) 상태이고, 신규 표준은 Gateway API(GA)입니다. Envoy Gateway·Istio·Cilium·NGINX Gateway Fabric으로 마이그레이션하는 과정에서 502가 자주 발생합니다.

• 흔한 함정: 기존 Ingress 어노테이션(타임아웃·버퍼·백엔드 프로토콜)이 Gateway API의 HTTPRoute/BackendTrafficPolicy로 자동 이전되지 않음 → 기본값으로 떨어지며 타임아웃·헤더 버퍼 축소로 502.
• 점검: BackendTrafficPolicy의 connection/timeout 설정, gRPC는 appProtocol: grpc 또는 별도 GRPCRoute 사용 여부.
• 권장: 마이그레이션 시 양쪽을 병행 운영(shadow)하며 5xx를 비교.

eBPF·OpenTelemetry로 502를 ‘보이게’ 만들기

2026년에는 사이드카 없이 커널 레벨에서 L7 트래픽을 관측하는 흐름이 표준화됐습니다.

• Cilium/Hubble, Pixie: eBPF로 파드 간 HTTP/gRPC 상태 코드를 코드 수정 없이 수집 → 502가 어느 파드/노드/연결에서 시작됐는지 즉시 식별.
• OpenTelemetry: 트레이스/메트릭/로그를 단일 파이프라인으로. 게이트웨이와 앱이 같은 trace_id를 공유하면 502가 끊긴 스팬을 바로 지목.
• 실무 팁: 경계(LB/프록시)와 앱 양쪽에 traceparent(W3C Trace Context)를 일관 전파하세요. 과거의 X-Request-ID만으로는 멀티 홉 상관이 부족합니다.

서비스 메시(Istio Ambient / Linkerd)에서의 502

• 사이드카 모델: 앱보다 프록시(Envoy)가 먼저 뜨거나 늦게 종료되면 배포 중 502. holdApplicationUntilProxyStarts: true, preStop 정렬 필요.
• Ambient 메시(사이드카 없는 ztunnel/waypoint): 트래픽 경로가 바뀌며 mTLS 핸드셰이크 실패가 502로 표면화. PeerAuthentication(STRICT) 적용 순서와 waypoint 배치를 점검하세요.

Cloudflare 5xx 코드 빠른 매핑

엣지에 Cloudflare가 있으면 표준 502 외에 벤더 코드가 섞입니다. 원인 축소에 유용합니다.

팁: Cloudflare 응답의 Ray ID를 로그와 함께 보관하면 엣지–오리진 상관 추적이 빨라집니다.

AI/LLM 백엔드 특유의 502 (신규)

LLM API 게이트웨이나 스트리밍(SSE) 백엔드가 늘면서 새로운 패턴이 보입니다.

• 긴 스트리밍 응답을 프록시가 버퍼링하려다 헤더/타임아웃 한계를 넘김 → proxy_buffering off + 충분한 read_timeout 필요.
• 토큰 단위 SSE에서 업스트림이 연결을 일찍 닫으면 502. keep-alive와 proxy_http_version 1.1 확인.

자주 묻는 질문 (FAQ)

Q. 502와 504의 차이는 정확히 무엇인가요? 502는 게이트웨이가 업스트림으로부터 잘못된 응답이나 끊긴 연결을 받은 경우이고, 504는 업스트림이 제때 응답하지 않아 시간이 초과된 경우입니다. 502는 “프로토콜/연결/형식” 문제, 504는 “지연” 문제에 가깝습니다.

Q. 새로고침하면 가끔 풀리는 502는 왜 그런가요? 대개 idle keep-alive 커넥션 재사용 중 RST, 롤링 배포 중 일시적 드레인 누락, 또는 일부 백엔드 인스턴스만 비정상일 때입니다. 헬스체크/프로브와 deregistration delay, 타임아웃 정렬을 우선 점검하세요.

Q. 사용자 입장에서 502가 뜨면 무엇을 할 수 있나요? 새로고침, 브라우저 캐시/쿠키 삭제(쿠키 폭증이 원인일 때 효과), 다른 네트워크로 시도 정도입니다. 근본 원인은 서버/인프라 측에 있어 운영자의 조치가 필요합니다.

Q. 배포할 때마다 502가 잠깐 뜹니다. 0으로 만들 수 있나요? 네. 정확한 readinessProbe + startupProbe, preStop 드레인(sleep), maxUnavailable: 0, 로드밸런서 deregistration delay와 앱 종료 그레이스의 정렬로 무중단 배포가 가능합니다.

Q. gRPC 서비스에서만 502가 납니다. NGINX 등에서 proxy_pass 대신 grpc_pass를 사용해야 하며, h2(ALPN) 리스너가 필요합니다. HTTP/2 프레이밍이 HTTP/1.1 프록시를 거치면 깨집니다.

Q. CDN(Cloudflare/CloudFront)을 쓰는데 오리진은 정상입니다. 어디를 봐야 하나요? 오리진 TLS 체인/ALPN/SNI, 오리진 keep-alive와 엣지 origin timeout 정렬, 헤더 크기 제한, 그리고 벤더별 5xx 코드(520~524, x-edge-result-type)를 확인하세요.

마무리

502 Bad Gateway는 “경계”에서 발생하는 복합 장애입니다. 해결의 핵심은 각 홉의 역할과 설정을 구조적으로 정렬하고, 관측 가능한 신호로 빠르게 최초 실패 지점을 찾아내는 것입니다. 본문에 제시한 설정 스니펫, 러ン북, 체크리스트, 명령어 모음을 팀의 표준 운영 문서에 통합하세요. 배포 전략(카나리/블루-그린)과 카오스 엔지니어링을 곁들이면 502는 재난이 아닌 예측 가능한 이벤트가 됩니다. 이제 여러분의 환경에서 타임아웃과 프로토콜, 헬스체크를 재점검해보세요. 작은 정렬이 큰 가용성을 만듭니다.