HTTP 502 Bad Gateway — 게이트웨이 오류·업스트림 문제 원인·해결·예방

HTTP 502 Bad Gateway — 게이트웨이 오류·업스트림 문제 원인·해결·예방

웹사이트에서 "502 Bad Gateway"를 만나면, 앞에서 요청을 받아주는 서버(게이트웨이·프록시)는 멀쩡한데 그 뒤에 있는 진짜 일꾼 서버(업스트림)가 제대로 답을 주지 못한 상태다. 손님을 맞은 안내 데스크는 살아 있는데, 주방이 불이 꺼져 음식을 못 내오는 상황에 가깝다.

 

502는 500과 같은 5xx 서버 오류이지만 발생 지점이 다르다. 500이 "한 서버 안에서 사고"라면, 502는 "프록시와 업스트림 사이의 문제"다. 이 글은 502의 의미, 자주 나오는 원인, 프록시·업스트림 설정 코드와 진단 명령, 단계별 해결, 그리고 504와의 차이까지 정리한다.

 

HTTP 502 Bad Gateway

이 글의 구성

 

01502 에러 메시지와 의미

02자주 나오는 발생 원인 5가지

03재현 시나리오와 프록시·진단 코드

04해결 방법과 단계별 진단

05502 vs 504 vs 500 vs 503 비교

Q&A자주 묻는 질문 5가지

---

01 502 에러 메시지와 의미

502는 HTTP 응답 상태 코드 가운데 5xx, 서버 측 오류로 분류된다. 게이트웨이나 프록시 역할을 하는 서버가 업스트림(상위) 서버에 요청을 전달했는데, 유효하지 않은(invalid) 응답을 받았을 때 반환한다. 핵심은 "프록시는 동작하는데, 그 뒤가 문제"라는 점이다.

항목	내용
상태 코드	502
영문 메시지	Bad Gateway
한글 의미	게이트웨이가 업스트림에서 잘못된 응답을 받음
분류	5xx 서버 오류
발생 지점	프록시·게이트웨이 ↔ 업스트림(백엔드) 사이

요즘 웹은 대부분 앞단에 Nginx 같은 리버스 프록시나 CDN·로드밸런서를 두고, 그 뒤에 실제 애플리케이션 서버(업스트림)를 둔다. 502는 앞단이 뒤로 요청을 넘겼는데 정상 응답을 못 받았다는 신호다. 그래서 진단의 시선은 항상 "프록시"가 아니라 "업스트림"으로 향해야 한다.

핵심 관찰 — 안내 데스크가 아니라 주방을 보라

502가 떴다는 것은 프록시(안내 데스크)가 살아서 동작 중이라는 뜻이다. 문제는 그 뒤의 업스트림(주방)이다. 따라서 프록시 설정만 들여다보면 헛수고하기 쉽다. 업스트림 프로세스가 살아 있는지, 포트·소켓이 열려 있는지부터 확인한다.

---

02 자주 나오는 발생 원인 5가지

원인 1 — 업스트림(백엔드) 다운·크래시

가장 흔하다. 실제 앱 서버 프로세스가 죽었거나, 크래시 후 재시작 중이거나, 아직 부팅이 안 끝났을 때다. 프록시가 연결을 시도해도 받아줄 상대가 없으니 502가 난다.

원인 2 — 잘못된 프록시 설정(proxy_pass·upstream)

proxy_pass의 주소·포트가 틀렸거나, upstream 정의가 잘못됐거나, 업스트림이 듣고 있는 포트와 프록시가 보내는 포트가 다르면 연결이 안 돼 502가 난다. 배포 중 포트가 바뀐 경우가 대표적이다.

원인 3 — 업스트림 과부하·비정상 응답

업스트림이 살아 있어도 과부하로 연결을 거부하거나, 프로토콜에 맞지 않는 깨진 응답을 돌려주면 프록시가 이를 유효하지 않은 응답으로 보고 502를 낸다. 워커 부족·메모리 압박 상황에서 간헐적으로 나타난다.

원인 4 — 네트워크·방화벽 차단

프록시와 업스트림이 서로 다른 서버에 있을 때, 둘 사이의 방화벽·보안그룹이 해당 포트를 막으면 연결이 안 돼 502가 난다. 업스트림 자체는 멀쩡한데 길이 막힌 경우다.

원인 5 — PHP-FPM·소켓 문제

PHP 사이트에서는 Nginx가 PHP-FPM 소켓으로 요청을 넘기는데, FPM이 죽었거나 소켓 경로가 틀렸거나 워커가 고갈되면 502가 난다. fastcgi_pass가 가리키는 소켓·포트가 실제 FPM과 일치하는지 확인해야 한다.

---

03 재현 시나리오와 프록시·진단 코드

먼저 502 응답의 모습이다. 프록시가 만들어 내보내는 응답이라 본문에는 보통 프록시 이름 정도만 보인다.

# 응답 (프록시가 생성)
HTTP/1.1 502 Bad Gateway
Server: nginx

Nginx 리버스 프록시 설정과 로그를 본다. error.log에는 업스트림 연결 실패가 그대로 찍힌다.

# Nginx 리버스 프록시 설정
upstream app {
    server 127.0.0.1:3000;
}
location / {
    proxy_pass http://app;
}

# 에러 로그 확인
tail -f /var/log/nginx/error.log
# ✗ 업스트림 연결 실패 로그
connect() failed (111: Connection refused) while connecting to upstream

진짜 원인은 업스트림 쪽에 있으니, 앱 프로세스와 포트·소켓을 직접 점검한다.

# 업스트림 프로세스 상태 확인
systemctl status myapp

# 업스트림 포트가 실제로 열려 있는지
ss -tlnp | grep 3000

# ✓ 서버 내부에서 업스트림에 직접 요청해 보기
curl -I http://127.0.0.1:3000

---

04 해결 방법과 단계별 진단

502는 거의 항상 업스트림 쪽 문제다. 그래서 진단은 "프록시 뒤"를 향한다.

의심 영역	해결 방법
업스트림 다운	앱 프로세스 상태·로그 확인 후 재시작, 크래시 원인 분석
프록시 설정	proxy_pass·upstream 주소·포트 점검, 설정 reload
과부하	워커·메모리 점검, 스케일 아웃·리소스 증설
네트워크	방화벽·보안그룹에서 업스트림 포트 허용 확인
PHP-FPM·소켓	FPM 상태 확인, fastcgi_pass 소켓·포트 일치 점검

단계별 진단 절차

01업스트림(앱) 프로세스가 살아 있는지부터 확인한다. 죽었으면 로그를 보고 재시작한다.

02서버 내부에서 업스트림에 직접 요청(curl)해 본다. 여기서도 실패면 프록시가 아니라 앱 문제다.

03프록시 error.log에서 connection refused·timeout 등 어떤 실패인지 확인한다.

04proxy_pass·upstream의 주소·포트, FPM 소켓 경로가 실제 업스트림과 맞는지 본다.

05방화벽·리소스·워커 수를 점검한다. 간헐적 502면 과부하·리소스를 우선 의심한다.

---

05 502 vs 504 vs 500 vs 503 비교

5xx는 코드만 봐도 어디를 볼지 좁혀진다. 특히 502와 504를 헷갈리지 않는 게 중요하다.

코드	의미	한 줄 구분
502	잘못된 게이트웨이 응답	업스트림이 깨진 답·연결 거부
504	게이트웨이 시간 초과	업스트림이 제때 답을 못 줌(타임아웃)
500	서버 내부 오류	앱 자체의 예기치 않은 예외
503	서비스 일시 불가	과부하·점검으로 의도적 거부

특히 502와 504의 차이를 기억해 두면 좋다. 502는 "답이 왔는데 그게 깨졌거나 연결 자체가 거부됐다"이고, 504는 "정해진 시간 안에 답이 오지 않았다(타임아웃)"이다. 502는 업스트림이 죽었거나 설정이 틀린 쪽을, 504는 업스트림이 느린(오래 걸리는) 쪽을 의심한다.

“

502는 프록시의 잘못이 아니라 그 뒤의 침묵이다. 안내 데스크가 아니라 주방을 들여다봐야 답이 나온다.

 

— 502는 연결·응답, 504는 시간(타임아웃)

---

06 자주 묻는 질문 5가지

Q1502는 제 인터넷 문제인가요?

대부분 아닙니다. 502는 서버 측, 그중에서도 프록시 뒤의 업스트림 문제라 방문자가 할 수 있는 일은 새로고침이나 잠시 후 재접속 정도입니다. 근본 해결은 사이트 운영자의 몫입니다.

Q2502와 504는 뭐가 다른가요?

502는 업스트림이 연결을 거부하거나 깨진 응답을 준 경우, 504는 업스트림이 정해진 시간 안에 응답하지 못한(타임아웃) 경우입니다. 502는 "죽었거나 틀렸다", 504는 "너무 느리다"로 기억하면 쉽습니다.

Q3운영자인데 502가 떴어요. 어디부터 보나요?

업스트림(앱) 프로세스가 살아 있는지부터 봅니다. 서버 안에서 업스트림 주소로 직접 curl을 날려 보고, 거기서도 실패하면 앱 문제, 성공하면 프록시 설정·네트워크 문제로 좁혀집니다.

Q4배포 직후부터 502가 떠요.

배포로 앱이 재시작 중이거나, 리슨 포트·소켓 경로가 바뀌었는데 프록시 설정이 옛 값을 가리키는 경우가 많습니다. 업스트림 포트와 proxy_pass·fastcgi_pass 값이 일치하는지 확인하세요.

Q5Cloudflare에서 502가 떠요.

CDN·로드밸런서도 일종의 게이트웨이라 502를 낼 수 있습니다. 이때 업스트림은 원본 서버(origin)입니다. 원본 서버가 살아 있는지, CDN과 원본 사이 연결·포트가 정상인지 확인하면 됩니다.

---

07 결론

502 Bad Gateway는 "앞단 프록시는 멀쩡한데, 뒤의 업스트림이 답을 못 줬다"는 신호다. 500이 한 서버 안의 사고였다면, 502는 서버와 서버 사이의 문제다. 그래서 시선은 늘 프록시 뒤를 향해야 한다.

실무 원칙은 다음과 같다.

첫째, 업스트림부터 본다. 앱 프로세스 생존 여부와 서버 내부 curl 테스트가 가장 빠른 길이다.

둘째, 502와 504를 구분한다. 502는 연결·응답의 문제, 504는 시간(타임아웃)의 문제다.

셋째, 헬스체크와 다중화로 예방한다. 업스트림을 여러 대 두고 헬스체크로 죽은 노드를 빼면, 하나가 죽어도 502가 사용자에게 닿지 않는다.

502 트러블슈팅 체크리스트

 

01업스트림(앱) 프로세스 생존·로그 확인, 죽었으면 재시작.

02서버 내부에서 업스트림에 직접 curl로 응답 확인.

03프록시 error.log에서 connection refused·timeout 구분.

04proxy_pass·upstream·fastcgi_pass의 주소·포트·소켓 일치 점검.

05방화벽·보안그룹에서 업스트림 포트 허용 여부 확인.

06간헐적 502면 워커·메모리 등 리소스 과부하 점검.

07헬스체크·다중 업스트림·무중단 배포로 502 노출 예방.

---

본 글은 HTTP 502 Bad Gateway 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버·프록시 설정 변경은 운영 환경에 적용하기 전 테스트 환경에서 충분히 검증한다.

 

#502에러 #BadGateway #HTTP502 #HTTP에러 #HTTP상태코드 #게이트웨이오류 #업스트림 #리버스프록시 #Nginx #proxypass #PHPFPM #502와504차이 #웹서버 #웹개발 #트러블슈팅