웹사이트를 운영하다 보면 갑자기 “502 Bad Gateway”라는 오류 화면이 나타나는 경우가 있습니다.
특히 Nginx나 Apache를 리버스 프록시(Reverse Proxy)로 사용하고, 뒤쪽에 Node.js, Python, PHP 또는 다른 애플리케이션 서버를 연결해 놓은 환경에서 자주 확인할 수 있습니다.
HTTP 502 오류는 단순히 웹브라우저의 문제가 아니라, 앞단의 웹서버가 뒤쪽의 백엔드 서버에서 정상적인 응답을 받지 못했다는 의미로 이해하면 쉽습니다. Apache 공식 문서도 게이트웨이 또는 프록시가 업스트림 서버로부터 유효하지 않은 응답을 받은 경우 502가 발생할 수 있다고 설명합니다.
이번 글에서는 초보자도 서버 상태를 직접 확인할 수 있도록 HTTP 502 Bad Gateway의 주요 원인과 해결 방법 5가지를 정리해보겠습니다.

HTTP 502 Bad Gateway란?
먼저 웹서비스의 구조를 간단하게 이해하면 오류 원인을 찾기 쉽습니다.
일반적인 웹서비스가 다음과 같이 구성되어 있다고 가정해보겠습니다.
사용자가 웹사이트에 접속하면 Nginx가 요청을 받아 애플리케이션 서버로 전달합니다.
이때 애플리케이션 서버가 실행되지 않았거나, 잘못된 포트로 연결하거나, 정상적인 응답을 반환하지 못하면 Nginx가 사용자에게 502 Bad Gateway를 보여줄 수 있습니다.
Nginx는 업스트림 서버의 상태를 확인하고 문제가 있는 서버를 일시적으로 사용할 수 없는 상태로 처리할 수도 있습니다.
1. 백엔드 서버가 실행되고 있는지 확인하기
HTTP 502 오류가 발생했을 때 가장 먼저 확인할 부분입니다.
예를 들어 Nginx가 다음과 같이 설정되어 있다고 가정해보겠습니다.
이 경우 Nginx는 127.0.0.1:3000에서 실행 중인 애플리케이션 서버로 요청을 전달합니다.
그런데 애플리케이션이 종료되어 있다면 Nginx가 정상적인 응답을 받을 수 없습니다.
먼저 포트를 확인해보세요.
Node.js나 Python 애플리케이션을 사용한다면 해당 프로그램의 실행 상태도 확인합니다.
예를 들어 systemd 서비스를 사용하는 경우:
서비스가 중지되어 있다면 다음과 같이 다시 시작할 수 있습니다.
502 오류가 발생하면 가장 먼저 백엔드 서버가 살아 있는지 확인하는 습관을 만드는 것이 좋습니다.
2. Nginx의 proxy_pass 주소 확인하기
백엔드 서버가 정상적으로 실행되고 있는데도 502 오류가 발생한다면 Nginx 설정을 확인해야 합니다.
설정 파일에서 다음과 같은 부분을 찾아보세요.
여기서 확인해야 할 것은 크게 세 가지입니다.
- IP 주소
- 포트 번호
- HTTP 또는 HTTPS 사용 여부
예를 들어 실제 애플리케이션이 8080번 포트에서 실행되고 있는데 Nginx가 3000번 포트로 연결하도록 설정되어 있다면 정상적으로 통신할 수 없습니다.
설정을 수정한 후에는 먼저 문법 오류가 없는지 확인합니다.
정상적으로 확인됐다면 Nginx를 다시 로드합니다.
Nginx는 proxy_pass를 이용해 요청을 백엔드 서버로 전달하는 구조를 지원합니다.
3. Nginx 에러 로그 확인하기
502 오류를 해결할 때 가장 중요한 방법 중 하나가 로그 확인입니다.
브라우저에 표시되는 502 Bad Gateway라는 문구만 보고 원인을 정확하게 판단하기는 어렵습니다.
Nginx의 에러 로그를 확인해보세요.
오류가 발생한 상태에서 다시 웹사이트에 접속하면 관련 메시지가 나타날 수 있습니다.
예를 들어 다음과 같은 메시지가 발견될 수 있습니다.
각 메시지는 서로 다른 원인을 의미할 수 있습니다.
특히 connection refused가 나타난다면 백엔드 서버가 해당 포트에서 실행되고 있는지 먼저 확인하는 것이 좋습니다.
또한 Nginx 환경에서는 업스트림 응답 헤더가 너무 큰 경우에도 502 오류가 발생할 수 있습니다. NGINX 공식 문서에서도 upstream sent too big header와 관련된 502 사례를 설명하고 있습니다.
4. 서버의 CPU와 메모리 상태 확인하기
백엔드 프로그램이 실행되고 있다고 해서 항상 정상적으로 응답하는 것은 아닙니다.
서버의 메모리가 부족하거나 CPU 사용량이 지나치게 높으면 애플리케이션의 응답이 늦어지거나 프로세스가 종료될 수 있습니다.
다음 명령어로 메모리 상태를 확인할 수 있습니다.
CPU와 프로세스 상태는 다음과 같이 확인할 수 있습니다.
Docker 환경이라면 다음 명령어도 유용합니다.
특히 작은 AWS EC2 인스턴스나 메모리가 적은 VPS에서 여러 서비스를 동시에 실행한다면 메모리 부족 여부를 꼭 확인해보는 것이 좋습니다.
Swap을 사용하는 환경이라면 다음 명령어로 상태를 확인할 수 있습니다.
단, Swap을 설정한다고 실제 RAM이 증가하는 것은 아닙니다. 지속적으로 메모리가 부족하다면 애플리케이션을 최적화하거나 서버 사양을 높이는 방법을 검토해야 합니다.
5. 백엔드 서버에 직접 접속해보기
마지막으로 상당히 유용한 방법이 있습니다.
Nginx를 거치지 않고 백엔드 서버에 직접 요청을 보내는 것입니다.
예를 들어 애플리케이션이 3000번 포트에서 실행되고 있다면:
정상적인 응답이 돌아오는지 확인해보세요.
만약 여기에서도 연결되지 않는다면 Nginx보다는 백엔드 애플리케이션 자체를 먼저 확인해야 합니다.
반대로 백엔드에는 정상적으로 접속되는데 Nginx를 통해 접속할 때만 502가 발생한다면 Nginx 설정이나 프록시 연결 부분을 집중적으로 확인하는 것이 좋습니다.
HTTP 502 오류를 빠르게 확인하는 순서
502 오류가 발생했을 때 다음 순서대로 확인하면 원인을 찾기 쉽습니다.
① 백엔드 프로세스 확인
② 포트 확인
③ 백엔드 직접 접속
④ Nginx 설정 확인
⑤ Nginx 로그 확인
이 순서대로 확인하면 단순히 Nginx만 재시작하는 것보다 어느 단계에서 문제가 발생했는지 파악하기 쉽습니다.
502 오류와 504 오류의 차이
502 오류와 함께 자주 보이는 것이 504 Gateway Timeout입니다.
둘은 비슷해 보이지만 상황이 다를 수 있습니다.
502 Bad Gateway
→ 프록시나 게이트웨이가 업스트림에서 정상적인 응답을 받지 못한 경우
504 Gateway Timeout
→ 프록시나 게이트웨이가 업스트림 서버의 응답을 기다리다가 시간 초과가 발생한 경우
따라서 502가 발생했다고 해서 무조건 서버가 다운됐다고 단정해서는 안 됩니다.
백엔드 연결 문제, 잘못된 포트 설정, 비정상적인 응답, 응답 헤더 문제 등 여러 원인을 차례대로 확인해야 합니다.
마무리
HTTP 502 Bad Gateway는 웹서버와 백엔드 서버 사이의 통신에 문제가 생겼을 때 나타나는 대표적인 오류입니다.
특히 Nginx를 리버스 프록시로 사용하는 환경에서는 다음 항목을 먼저 확인하는 것이 좋습니다.
- 백엔드 서버가 실행 중인지 확인
- Nginx의 proxy_pass 주소와 포트 확인
- Nginx 에러 로그 확인
- CPU와 메모리 사용량 확인
- 백엔드 서버에 직접 curl 요청
무작정 Nginx를 재시작하기보다는 로그 → 포트 → 백엔드 → Nginx 설정 순서로 확인하면 문제를 훨씬 빠르게 찾을 수 있습니다.
웹서버를 직접 운영한다면 502 오류가 발생했을 때 당황하기보다는 위의 다섯 가지 항목을 하나씩 확인하는 습관을 만들어보세요.