502 Bad Gateway — 새로고침으로 되는 경우와 안 되는 경우 (503·504와 구분)

결제 버튼을 눌렀는데 흰 화면에 "502 Bad Gateway"가 떴습니다. 새로고침을 눌러도 되는 건지, 돈은 빠져나간 건지, 내 인터넷이 문제인지 — 이 코드 하나가 세 가지 질문을 한꺼번에 만듭니다. 답은 코드의 뜻에 다 들어 있습니다.

HTTP 상태 코드 확인 바로 하기 →

502는 서버 쪽 중간 장비가 뒤에 있는 진짜 서버에서 정상 응답을 받지 못했다는 코드입니다. 내 컴퓨터나 내 인터넷이 만든 오류가 아닙니다. 그래서 브라우저 캐시를 지우거나 와이파이를 바꿔도 대개 달라지지 않고, 반대로 몇 분 뒤에 저절로 풀리는 경우가 많습니다. 다만 결제·예약 도중이었다면 새로고침을 누르기 전에 확인할 것이 있습니다. 아래 순서대로 봅니다.

502·503·504는 무엇이 다른가요?

HTTP 표준 문서(RFC 9110)의 정의를 그대로 옮기면 이렇습니다.

셋 다 500번대, 즉 서버 쪽 문제입니다. 차이는 "뒤 서버가 이상한 답을 줬나(502)", "서버가 스스로 쉬는 중인가(503)", "뒤 서버가 답을 안 줬나(504)"입니다. 참고로 500 Internal Server Error는 "서버가 예상하지 못한 상태를 만나 요청을 완료하지 못함"이라는 더 일반적인 코드입니다.

여기서 게이트웨이란 요즘 사이트 대부분이 앞에 세워 두는 중간 서버입니다. 방문자의 요청을 먼저 받아 뒤의 앱 서버로 넘기는 역할이라, 앱 서버가 멈추거나 재시작 중이면 이 중간 서버가 502를 대신 내보냅니다. Cloudflare 같은 서비스를 앞에 둔 사이트라면 그 화면이 Cloudflare 양식으로 나옵니다.

방문자가 할 수 있는 것과 없는 것

할 수 있는 것

1. 몇 분 기다렸다가 다시 엽니다. 502·504의 흔한 원인은 앱 서버 재시작이나 순간 과부하라 짧게 끝나는 경우가 많습니다. 503에 점검 안내가 있으면 그 시간까지 기다립니다.
2. 다른 곳에서도 같은지 확인합니다. 아래 도구는 tooly 서버에서 그 주소에 접속해 코드를 받아 옵니다. 내 PC에서는 502인데 도구에서는 200이면, 내 쪽 경로(회사 프록시·VPN 등)를 의심할 차례입니다. 도구에서도 502면 서버 쪽입니다.
3. 결제·예약 중이었다면 새로고침 전에 처리 여부를 확인합니다. 502는 "요청이 뒤 서버에 들어갔는지"를 알려 주지 않습니다. 카드사 문자, 주문 내역, 예약 확인 메일을 먼저 보고, 없을 때만 다시 시도합니다. 새로고침을 연타하면 중복 결제·중복 예약이 생길 수 있습니다.

해도 소용없는 것

• 브라우저 캐시 삭제, 쿠키 삭제, 다른 브라우저 — 502는 서버가 보낸 코드라 내 저장 데이터와 무관합니다. (403·404처럼 내 요청이 문제인 코드와는 다릅니다.)
• 공유기 재시작 — 서버까지 연결 자체는 됐기 때문에 코드를 받은 것입니다. 연결이 안 됐다면 502가 아니라 "응답 없음"이 됩니다.

내 쪽인지 서버 쪽인지 전체 순서는 사이트 접속 안 될 때 — 서버 문제인지 내 문제인지에 있습니다. 이 글은 그중 500번대 뒷부분만 깊게 다룹니다.

도구로 확인하는 순서

1. 도구에 오류가 난 주소를 넣고 상태 확인을 누릅니다. https://를 안 붙여도 됩니다.
2. 결과 배지의 숫자와 구분을 읽습니다 — 200이면 정상, 300번대면 다른 곳으로 넘김, 400번대면 요청 문제, 500번대면 서버 문제, 코드 없이 "서비스를 사용할 수 없음"이면 연결 자체가 안 된 것입니다.
3. 도구 결과와 내 화면이 다르면 내 쪽 경로를, 같으면 서버 쪽을 봅니다.

실제로 돌려 본 결과입니다.

도구는 tooly 서버에서 요청을 보내고, 응답을 10초까지 기다리며, 다른 주소로 넘기는 사이트는 끝까지 따라가 마지막 코드를 보여 줍니다. 인증서에 문제가 있는 사이트도 코드 조회는 됩니다. 요청 한 번의 결과라 순간적인 502는 놓칠 수 있으니, 의심스러우면 1~2분 간격으로 두세 번 확인하는 편이 정확합니다.

운영자라면 어디부터 보나요?

방문자에게 502가 보였다면 게이트웨이(Nginx·Apache·CDN)는 살아 있고 그 뒤가 문제입니다. 순서는 이렇습니다.

1. 앱 서버 프로세스 — 죽었는지, 재시작 중인지, 포트를 제대로 듣고 있는지. 게이트웨이가 넘기는 포트와 앱이 듣는 포트가 다르면 502가 계속 납니다. 포트가 열렸는지는 포트 확인으로 밖에서도 볼 수 있습니다.
2. 게이트웨이 오류 로그 — 502·504는 게이트웨이가 만든 코드라 그 로그에 "upstream"이 어떤 응답을 줬는지 남습니다.
3. 504가 섞이면 시간 — 앱이 응답은 하는데 게이트웨이의 대기 시간을 넘긴 것입니다. 느린 쿼리나 외부 API 호출을 먼저 봅니다.
4. 503은 의도된 것인지 — 배포·점검 중 일부러 내보내는 경우가 있습니다. 그렇다면 Retry-After 헤더로 대기 시간을 알려 주는 것이 표준이 정한 방식입니다.

자주 묻는 질문

502가 내 컴퓨터 문제일 수도 있나요?
서버가 보낸 코드라 보통은 아닙니다. 예외는 내 앞에 프록시나 VPN이 있고 그 장비가 502를 만드는 경우입니다. 위 도구에서 200이 나오는데 내 화면만 502라면 그쪽을 의심합니다.

얼마나 기다려야 하나요?
정해진 시간은 없습니다. 503에 안내 시간이 있으면 그것을 따르고, 502·504는 1~2분 뒤 한 번, 그래도 안 되면 10분쯤 뒤 한 번 더 보는 정도가 무난합니다. 계속 반복되면 그 서비스의 공지나 문의 창구를 확인합니다.

Cloudflare 화면의 502·504도 같은 뜻인가요?
같습니다. Cloudflare가 게이트웨이 역할을 하기 때문에, 뒤의 원래 서버가 이상한 응답을 주거나(502) 시간 안에 답하지 않으면(504) Cloudflare 양식의 오류 페이지가 나옵니다. 원인은 여전히 원래 서버 쪽입니다.

404나 403과는 어떻게 다른가요?
404·403은 서버가 정상으로 살아 있으면서 "그 페이지가 없다", "권한이 없다"고 답한 것이라 주소나 로그인을 확인할 일입니다. 502·503·504는 서버 쪽이 답을 못 만든 상태라 방문자가 고칠 것이 없습니다.

핑은 되는데 502가 납니다. 왜 그런가요?
핑은 서버까지 신호가 닿는지만 보고, 502는 그 뒤의 앱 서버 문제라 둘은 다른 층입니다. 서버 응답 시간 자체를 보고 싶으면 핑 테스트 글이 이어집니다.

함께 보면 좋은 것

접속 문제 전체를 순서대로 가르려면 사이트 접속 안 될 때 확인 순서, 서버가 살아 있는지부터 보려면 핑 테스트 — 응답 시간 읽는 법, 특정 서비스의 문이 닫혔는지는 포트 확인 글에서 이어집니다.

HTTP 상태 코드 확인 열어 보기 →

이 글의 코드 정의는 2026년 9월 7일에 RFC 9110 원문에서 옮겼고, 도구 동작(서버 측 요청·10초 대기·리다이렉트 추적·구분 표시)은 같은 날 도구 코드와 라이브 실행으로 확인했습니다. 개별 사이트의 오류 원인은 그 서비스의 공지가 우선입니다.