/엔지니어/트러블슈팅/Nginx 502 Bad Gateway 오류 해결
트러블슈팅중급UbuntuDebianCentOSNginx502Bad Gateway

Nginx 502 Bad Gateway 오류 해결 방법 - 6가지 원인 분석 및 대처법

Nginx 502 Bad Gateway가 뜨는 6가지 원인 (upstream 미실행, 소켓 경로 불일치, PHP-FPM 크래시, 타임아웃, 권한, 메모리)을 로그 기반으로 빠르게 진단하고 해결하는 가이드.

502 Bad Gateway는 Nginx가 upstream(백엔드 서버)으로부터 유효한 응답을 받지 못했을 때 발생합니다. Nginx 자체 문제가 아니라 항상 백엔드 문제입니다.


먼저 로그 확인

Bash
# Nginx 에러 로그 (가장 먼저)
sudo tail -50 /var/log/nginx/error.log

# 특정 도메인 로그가 따로 있다면
sudo tail -50 /var/log/nginx/도메인.error.log

로그에 나온 메시지로 아래 원인 중 해당 항목으로 바로 이동하세요.


원인 1 — upstream 서버가 실행 중이지 않음

로그 패턴: connect() failed (111: Connection refused)

Bash
# Node.js 앱인 경우
sudo systemctl status myapp
pm2 status

# PHP-FPM 인 경우
sudo systemctl status php8.2-fpm    # 버전 확인 후

# Gunicorn (Python) 인 경우
sudo systemctl status gunicorn

# 실제 포트가 열려 있는지 확인
sudo ss -tlnp | grep 3000   # 포트 번호에 맞게

→ 미실행 상태라면 시작 후 즉시 해결됩니다.


원인 2 — upstream 주소/포트 불일치

로그 패턴: connect() failed (111: Connection refused) while connecting to upstream

Bash
# Nginx 설정에서 upstream 주소 확인
sudo grep -rn "proxy_pass|fastcgi_pass|uwsgi_pass" /etc/nginx/
Nginx
# 예: proxy_pass가 3000인데 앱은 8080으로 실행 중
proxy_pass http://127.0.0.1:3000;   # ← 실제 앱 포트와 일치해야 함
Bash
# 앱이 실제로 어느 포트에서 듣는지 확인
sudo ss -tlnp | grep LISTEN

원인 3 — PHP-FPM 소켓 경로 불일치

로그 패턴: connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory)

Bash
# 실제 소켓 파일 위치 확인
sudo find /run/php/ -name "*.sock" 2>/dev/null
ls /var/run/php/

# PHP-FPM pool 설정에서 실제 소켓 경로 확인
sudo grep "listen" /etc/php/8.2/fpm/pool.d/www.conf

Nginx 설정과 실제 소켓 경로를 일치시킵니다:

Nginx
# /etc/nginx/sites-available/mysite
fastcgi_pass unix:/run/php/php8.2-fpm.sock;   # 실제 소켓 경로로 수정
Bash
sudo nginx -t && sudo systemctl reload nginx

원인 4 — upstream 타임아웃

로그 패턴: upstream timed out (110: Connection timed out)

백엔드 처리 시간이 Nginx 타임아웃보다 길 때 발생합니다.

Nginx
# /etc/nginx/conf.d/timeout.conf 또는 server 블록 안
proxy_connect_timeout  60s;
proxy_send_timeout     120s;
proxy_read_timeout     120s;   # 이 값을 늘려야 함
Bash
sudo nginx -t && sudo systemctl reload nginx

타임아웃을 무조건 늘리기 전에 백엔드가 왜 느린지 먼저 파악하세요. 쿼리 최적화나 캐싱이 근본 해결책입니다.


원인 5 — 소켓 파일 권한 문제

로그 패턴: connect() to unix:/run/app.sock failed (13: Permission denied)

Bash
# 소켓 파일 소유자·권한 확인
ls -la /run/app.sock

# Nginx 워커 프로세스 실행 유저 확인
sudo grep "^user" /etc/nginx/nginx.conf
# 보통 www-data 또는 nginx

# 소켓 파일 권한 수정
sudo chown www-data:www-data /run/app.sock
# 또는 그룹 쓰기 허용
sudo chmod 660 /run/app.sock

원인 6 — 서버 메모리/리소스 부족으로 upstream 크래시

확인 방법:

Bash
# OOM Killer 로그 확인
sudo dmesg | grep -i "oom|killed process" | tail -10
sudo journalctl -k | grep -i oom | tail -10

# 현재 메모리 상태
free -h

upstream 프로세스가 OOM으로 죽었다면:

  • 스왑 추가: sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile
  • 인스턴스 타입 업그레이드 검토

빠른 진단 순서

Bash
# 1. 에러 로그 확인
sudo tail -30 /var/log/nginx/error.log

# 2. upstream 프로세스 상태
sudo systemctl status php8.2-fpm    # 또는 해당 서비스

# 3. 실제 포트/소켓 리스닝 여부
sudo ss -tlnp

# 4. Nginx 설정 검증
sudo nginx -t

# 5. 설정 반영
sudo systemctl reload nginx
#Nginx#502#Bad Gateway#트러블슈팅#upstream#PHP-FPM#proxy
편집 안내 · Editorial Note

이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.

관련 공식 문서NGINX 공식 문서

질문 & 답변 (Q&A)

이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.