502 Bad Gateway 오류 원인과 해결 방법

502 Bad Gateway 오류란?

502 Bad Gateway는 응답한 서버가 게이트웨이 또는 프록시 역할을 하고 있으며, 그 뒤에 있는 서버에서 잘못된 응답을 받았다는 뜻의 HTTP 상태 코드입니다. HTTP 표준(RFC 9110, 15.6.3절)도 정확히 그렇게 정의합니다. 서버가 "게이트웨이 또는 프록시 역할을 하는 동안, 요청을 처리하려고 접근한 내부 서버로부터 잘못된 응답을 받은" 경우입니다.

대부분의 최신 웹사이트에는 최소 두 개의 계층이 있습니다. nginx, Apache, Cloudflare, 클라우드 로드 밸런서 같은 프런트 서버가 연결을 받은 뒤, PHP-FPM, Node.js 앱, Python의 Gunicorn, 컨테이너 같은 업스트림(upstream) 애플리케이션으로 요청을 넘깁니다. 업스트림이 다운되었거나 크래시했거나 프록시가 사용할 수 없는 응답을 보내면, 프록시는 돌려줄 것이 없으므로 502를 반환합니다.

중요한 점은 게이트웨이 자체는 정상 작동하고 있다는 것입니다. 요청을 받았고 응답도 했습니다. 문제는 그보다 한 단계 뒤에 있습니다.

502 오류가 표시되는 여러 가지 모습

상태 코드는 어디서나 같지만, 보이는 페이지는 어떤 프록시가 만들었는지에 따라 달라집니다:

어떤 형태로 보이든, 하단에 표시된 프록시 이름은 유용한 단서입니다. 사이트 운영자가 어느 계층을 조사해야 하는지 알려 주기 때문입니다.

502 vs 500 vs 503 vs 504: 차이점은?

5xx 코드는 모두 '서버 문제'를 뜻하지만, 각각 가리키는 계층이 다릅니다:

간단한 규칙: 502 = 업스트림이 연결을 거부했거나, 연결을 끊었거나, 잘못된 응답을 보냄, 504 = 업스트림이 제시간에 응답하지 않음. 관련 오류는 각 가이드에서 자세히 다룹니다: 500 Internal Server Error, 503 Service Unavailable, 504 Gateway Timeout.

502 Bad Gateway의 원인

• 업스트림 앱이 실행 중이 아닙니다. PHP-FPM, Node, Gunicorn 또는 컨테이너가 크래시했거나, 배포 후 시작에 실패했거나, 재시작 중입니다.
• 프록시가 잘못된 곳을 가리킵니다. proxy_pass나 fastcgi_pass가 잘못된 포트, 업그레이드 이전의 오래된 PHP 소켓 경로, 또는 Docker 컨테이너 안의 localhost를 사용합니다.
• 일부 요청에서 앱이 크래시합니다. 특정 페이지가 메모리 부족 종료나 처리되지 않은 예외를 일으켜, 응답 전에 연결이 닫힙니다.
• 모든 워커가 사용 중입니다. PHP-FPM이 pm.max_children에 도달해 새 요청이 소켓의 대기열에서 기다립니다. 대부분은 이후 504로 타임아웃되고, 대기열이 가득 차면 nginx가 (11: Resource temporarily unavailable)을 기록하고 502를 반환합니다.
• 응답 헤더가 너무 큽니다. 큰 쿠키나 긴 보안 헤더가 nginx의 proxy_buffer_size를 넘칩니다.
• 로드 밸런서 뒤의 keep-alive 불일치. 앱이 로드 밸런서가 예상하는 것보다 일찍 유휴 연결을 닫아서, 밸런서가 닫히고 있는 연결로 요청을 보냅니다.
• 네트워크 변경 후 프록시가 업스트림에 도달하지 못합니다. 프록시를 거부하는 방화벽이나 새 IP로 옮겨 간 업스트림은 502(Connection refused, No route to host)를 일으킵니다. 패킷을 조용히 버리는 방화벽은 대신 504를 일으키며, Cloudflare 뒤에서는 이런 경우가 521이나 522로 표시됩니다.

방문자로서 502 오류 해결하기

남의 서버를 고칠 수는 없지만, 다음 단계로 문제가 정말 사이트 쪽에 있는지 확인하고 드물게 있는 로컬 원인을 정리할 수 있습니다:

• 30~60초 기다린 뒤 새로고침하세요(Ctrl + R, Mac은 Cmd + R). 상당수 502는 배포나 재시작이 진행되는 동안만 지속됩니다.
• 모두에게 다운되었는지 확인하세요. DNS Robot의 사이트 접속 확인은 11곳에서 페이지를 열어 보고, HTTP 헤더 확인 도구는 저희 서버가 받는 정확한 상태 코드를 보여 줍니다. 그쪽에서도 502가 나온다면 내 문제가 아니라 사이트 문제입니다.
• 강력 새로고침하세요. Ctrl + Shift + R(Mac: Cmd + Shift + R)로 합니다. 드물게 캐시된 오류 페이지가 표시되는 경우를 위한 것입니다.
• 사이트가 최근 호스팅을 옮겼다면 DNS를 플러시하세요. 그래야 새 서버로 접속합니다. 운영체제별 DNS 플러시 방법을 참고하세요.
• VPN과 프록시를 끄세요. 특히 회사 네트워크에서는 내가 쓰는 프록시가 실패하는 '게이트웨이'일 수 있습니다.
• 다른 브라우저나 모바일 데이터로 연결한 휴대폰에서 시도하세요. 거기서 열린다면 해당 사이트의 쿠키를 지우세요.

내 서버의 502 Bad Gateway 해결하기

서버 측에서 502는 비교적 고치기 쉬운 오류입니다. 프록시가 대개 무엇이 잘못되었는지 로그로 남기기 때문입니다(로드 밸런서의 keep-alive 경합과 Cloudflare 자체의 502는 예외입니다). 다음 세 가지를 순서대로 점검하고, 네 번째 항목은 실제 사례입니다.

1. 프록시의 오류 로그 읽기

502를 재현한 뒤, 프록시의 오류 로그 마지막 50줄을 읽으세요(명령어는 표 아래에 있습니다). 다음 nginx 메시지는 각각 해결 방향이 다릅니다:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. 업스트림 앱이 실행 중인지 확인

# PHP-FPM (버전에 맞게 수정)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# PM2로 실행 중인 Node.js
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # 계속 재시작되는 컨테이너가 있는지 확인
docker logs --tail 50 <container>

# 메모리를 너무 많이 써서 종료되었나요?
sudo dmesg -T | grep -i "killed process"

서비스가 중지되어 있다면 시작하고, 왜 멈췄는지 찾으세요. 실패한 배포, 새 릴리스의 문법 오류, 또는 OOM(메모리 부족) 킬러가 흔한 원인입니다. PHP-FPM 로그의 server reached pm.max_children setting은 모든 워커가 사용 중이었다는 뜻입니다. 서버 RAM이 충분할 때만 pm.max_children을 올리고, 그렇지 않다면 워커를 붙잡고 있는 느린 요청을 찾으세요.

3. proxy_pass가 올바른 포트나 소켓을 가리키는지 확인

nginx가 연결하도록 설정된 대상과 실제로 수신 대기 중인 대상을 비교하세요:

# nginx는 어디로 프록시하고 있나요?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# 실제로 수신 대기 중인 것은?
sudo ss -tlnp            # TCP 포트와 해당 프로세스
ls -l /run/php/          # PHP-FPM 소켓 파일

전형적인 불일치 두 가지가 있습니다. PHP를 업그레이드하면 소켓이 php8.3-fpm.sock으로 바뀌는데 nginx는 여전히 php8.1-fpm.sock을 가리키는 경우, 그리고 Docker 안에서 proxy_pass http://localhost:3000이 앱이 아닌 nginx 컨테이너 자신을 가리키는 경우입니다. Docker에서는 Compose 서비스 이름(http://app:3000)을 사용하세요.

4. 실제 사례: dnsrobot.net이 502를 반환한 이유

2026년 9월 30일, 저희 사이트에서 실제로 있었던 일입니다. 새 블로그 글을 여러 개 게시한 뒤, 그중 딱 하나만 nginx 1.24를 통해 502 Bad Gateway를 반환했고 다른 페이지는 모두 정상이었습니다. nginx 뒤의 Next.js 앱에 3000 포트로 직접 요청하면 같은 페이지가 200 OK로 응답했습니다. 즉 앱은 멀쩡했고 게이트웨이가 실패하고 있었습니다.

nginx 오류 로그 한 줄에 답이 있었습니다: upstream sent too big header while reading response header from upstream. 그 페이지의 응답 헤더는 4,087바이트였는데, 대부분 긴 Content-Security-Policy 헤더와 preload Link 헤더였습니다. nginx는 모든 헤더를 포함한 응답의 앞부분을 proxy_buffer_size로 정해진 버퍼에 읽어 들이는데, 기본값은 메모리 한 페이지로 저희 서버에서는 4 KB였습니다. 남은 여유가 9바이트뿐이었고, 상태 줄까지 포함한 전체 헤더 블록이 버퍼를 넘쳤습니다.

해결책은 앱으로 프록시하는 location 블록에 세 줄을 추가하는 것이었고, nginx -t와 다시 불러오기 후 페이지는 200을 반환했습니다:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # 큰 헤더를 위한 공간 (기본값 4k에서 변경)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

교훈: 사이트의 나머지는 정상인데 일부 페이지만 502를 반환한다면, 앱을 의심하기 전에 해당 페이지의 큰 헤더나 큰 Set-Cookie 값 같은 크기 제한부터 찾아보세요.

로드 밸런서 뒤의 Node.js: 간헐적인 502

AWS Application Load Balancer나 비슷한 밸런서 뒤에서 Node.js를 운영하는데, 앱 로그에는 오류가 없는데도 가끔 502가 난다면 keep-alive 타임아웃을 확인하세요. Node의 HTTP 서버는 기본적으로 유휴 keep-alive 연결을 5초 후에 닫는 반면(Node.js 26 이하 기준 server.keepAliveTimeout; Node 24.6과 22.19에서는 여기에 1초짜리 keepAliveTimeoutBuffer가 더해졌고, 다음 메이저 릴리스에서는 기본값이 65초로 올라갑니다), AWS ALB는 유휴 연결을 60초 동안 열어 둡니다. 가끔 Node가 연결을 닫는 바로 그 순간 밸런서가 그 연결을 재사용하고, 그 요청이 502로 돌아옵니다.

해결책은 앱의 타임아웃을 밸런서의 타임아웃보다 길게 설정하는 것입니다:

const server = app.listen(3000)
// 로드 밸런서의 유휴 타임아웃보다 길어야 합니다 (ALB 기본값: 60초)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // Node 18 이전에만 필요하며, 이후에는 있어도 무방합니다

Cloudflare의 502 Bad Gateway

Cloudflare를 사용 중이라면 먼저 오류 페이지를 누가 만들었는지 확인하세요(Cloudflare의 502/504 가이드):

• Cloudflare 브랜드 페이지(Browser ✓ / Cloudflare ✓ / Host ✗): 원본 서버 자체가 Cloudflare에 502 또는 504를 반환한 것입니다. 위의 서버 측 단계로 원본에서 해결하세요. Cloudflare가 원본에 아예 연결하지 못하면 502가 아니라 521 또는 522가 표시됩니다.
• "502 Bad Gateway"라고 쓰이고 아래에 "cloudflare"가 표시된 일반 페이지: Cloudflare 자체에서 나온 것입니다. Cloudflare 문서는 두 가지 원인을 꼽습니다. 원본이 손상된 gzip 콘텐츠를 보내거나 Content-Length가 갱신되지 않은 gzip 콘텐츠를 보내는 경우(테스트하려면 원본에서 압축을 끄세요), 그리고 Cloudflare 데이터센터 한 곳에 갑자기 트래픽이 몰리는 경우(저절로 해소됩니다)입니다.
• nginx나 Apache가 표시된 페이지: 대개 요청이 Cloudflare를 거치지 않고 서버에 도달한 것입니다. DNS 레코드가 프록시되지 않았거나(회색 구름) 원본을 직접 보고 있는 경우입니다(Cache Rule에서 "Origin error page pass-through"를 켠 경우는 예외).
• 호스팅을 옮겼나요? Cloudflare DNS의 원본 A 레코드를 업데이트하세요(잘못된 원본 IP는 보통 521, 522, 523으로 나타납니다). DNS 조회는 회색 구름(DNS only) 레코드에서만 원본을 보여 주며, 프록시된 레코드는 Cloudflare 자체 IP로 응답합니다.

502 오류가 SEO에 영향을 주나요?

짧은 장애라면 영향이 없습니다. Google 문서에 따르면 5xx 서버 오류가 발생하면 크롤러가 일시적으로 크롤링 속도를 늦춥니다. 이미 색인된 페이지는 처음에는 색인에 남아 있지만, 오류가 계속되면 Google은 결국 해당 URL을 색인에서 제외합니다.

따라서 배포 중 몇 분간 나타나는 502는 무해합니다. 하지만 중요한 페이지에서 며칠씩 이어지거나 몇 주 동안 간헐적으로 나타나는 502는 크롤링을 줄이고 순위를 떨어뜨릴 수 있습니다. 핵심 URL을 모니터링하고, 장애 후에는 Search Console의 크롤링 통계 보고서를 확인하세요.