리눅스 서버에서 웹페이지 접속 중 HTTP 502 Bad Gateway 오류가 뜨면 처음에는 nginx 설정 문제처럼 보일 수 있습니다. 하지만 실제 운영 서버에서는 nginx 자체보다 뒤쪽 WAS, 애플리케이션, 포트, upstream 연결 문제 때문에 502가 발생하는 경우가 많습니다. 이번 글에서는 502 오류가 났을 때 바로 nginx 재기동부터 하지 않고, 어떤 순서로 확인하면 안전한지 정리해보겠습니다.
502 Bad Gateway는 무슨 뜻일까?
502 Bad Gateway는 쉽게 말하면 앞단 서버가 뒤쪽 서버와 제대로 통신하지 못했다는 뜻입니다.
예를 들어 사용자가 브라우저로 접속하면 흐름은 대략 이렇게 이어질 수 있습니다.
사용자 브라우저
↓
nginx
↓
WAS 또는 애플리케이션 서버이때 nginx는 정상적으로 요청을 받았지만, 뒤쪽 애플리케이션 서버로 요청을 넘기는 과정에서 문제가 생기면 502가 발생할 수 있습니다.
그래서 502 화면에 nginx라는 문구가 보인다고 해서 무조건 nginx만 문제라고 보면 위험합니다.
nginx는 단지 “뒤쪽 서버랑 대화가 안 된다”고 알려주는 안내판 역할을 하고 있을 수도 있습니다.
초보 운영자가 하기 쉬운 실수
502 오류가 뜨면 급한 마음에 이런 조치를 먼저 하고 싶어집니다.
systemctl restart nginx또는 애플리케이션을 바로 재기동하고 싶을 수도 있습니다.
하지만 운영 서버에서는 재기동이 항상 정답은 아닙니다.
원인을 확인하지 않고 재기동하면 일시적으로 증상은 사라질 수 있지만, 왜 발생했는지 놓치게 됩니다. 더 나쁜 경우에는 정상 요청까지 끊기거나, 같은 장애가 다시 반복될 수 있습니다.
특히 502는 nginx 설정, upstream 포트, WAS 프로세스, 애플리케이션 오류, 방화벽, 타임아웃 등 원인이 여러 갈래로 나뉩니다.
그래서 먼저 해야 할 일은 재기동이 아니라 어디까지 정상인지 경계선을 찾는 것입니다.
1단계. nginx가 응답하는지 먼저 확인하기
먼저 서버 안에서 curl로 응답 상태를 확인합니다.
curl -I http://example.com예시 결과입니다.
HTTP/1.1 502 Bad Gateway
Server: nginx
Date: Thu, 02 Jul 2026 10:00:00 GMT
Content-Type: text/html여기서 중요한 것은 502가 뜬다는 사실뿐 아니라, 응답을 누가 주고 있는지입니다.
Server: nginx가 보인다면 nginx는 요청을 받고 응답을 반환하고 있습니다.
즉, nginx 프로세스 자체가 완전히 죽은 상황은 아닐 가능성이 있습니다.
이 단계에서 바로 nginx 재기동으로 뛰어들기보다, nginx 뒤쪽으로 연결되는 대상이 살아 있는지 확인해야 합니다.
2단계. nginx 설정에서 upstream 대상 확인하기
nginx는 보통 proxy_pass 설정을 통해 뒤쪽 애플리케이션 서버로 요청을 넘깁니다.
설정 파일에서 upstream 또는 proxy_pass를 확인합니다.
grep -R "proxy_pass" /etc/nginx/conf.d/또는 환경에 따라 아래 경로를 볼 수도 있습니다.
grep -R "proxy_pass" /etc/nginx/예시 설정입니다.
location / {
proxy_pass http://127.0.0.1:8080;
}이 경우 nginx는 요청을 받아서 내부의 127.0.0.1:8080으로 넘기고 있습니다.
그렇다면 다음 확인 대상은 nginx가 아니라 8080 포트에서 애플리케이션이 정상적으로 떠 있는지입니다.
3단계. upstream 포트가 실제로 열려 있는지 확인하기
서버에서 해당 포트가 열려 있는지 확인합니다.
ss -lntp | grep 8080예시 결과입니다.
LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("java",pid=12345,fd=120))이런 결과가 보이면 8080 포트에서 프로세스가 떠 있는 상태입니다.
반대로 아무 결과도 나오지 않는다면, nginx가 넘기려는 뒤쪽 애플리케이션이 떠 있지 않을 수 있습니다. 이 경우 502의 원인은 nginx 자체보다 WAS 또는 애플리케이션 프로세스 쪽일 가능성이 커집니다.
운영 서버에서는 여기서도 바로 재기동하기 전에, 해당 서비스가 원래 어떤 계정으로 실행되는지, 어떤 방식으로 구동되는지 확인해야 합니다.
ps -ef | grep java
ps -ef | grep node
ps -ef | grep tomcat서비스마다 프로세스명은 다를 수 있으니 실제 운영 환경에 맞게 확인해야 합니다.
4단계. upstream으로 직접 curl 테스트하기
nginx를 거치지 않고 뒤쪽 서버에 직접 요청을 보내봅니다.
curl -I http://127.0.0.1:8080또는 실제 서비스 경로가 있다면 아래처럼 확인할 수 있습니다.
curl -I http://127.0.0.1:8080/health여기서 200, 302, 404처럼 어떤 응답이라도 온다면 애플리케이션이 최소한 HTTP 응답은 하고 있는 상태입니다.
하지만 아래처럼 연결 실패가 나오면 문제가 다릅니다.
curl: (7) Failed to connect to 127.0.0.1 port 8080: Connection refused이 경우는 nginx가 뒤쪽 서버로 요청을 넘기려 했지만, 해당 포트에서 받아주는 프로세스가 없다는 뜻일 수 있습니다.
반대로 응답이 너무 오래 걸리거나 timeout이 발생한다면 애플리케이션이 멈췄거나, DB 연결 대기, 외부 API 지연 같은 문제가 숨어 있을 수 있습니다.
5단계. nginx 에러 로그 확인하기
502 원인을 볼 때 nginx 에러 로그는 꼭 확인해야 합니다.
tail -n 100 /var/log/nginx/error.log자주 볼 수 있는 메시지는 이런 형태입니다.
connect() failed (111: Connection refused) while connecting to upstream이 메시지는 nginx가 upstream에 연결하려 했지만 거부되었다는 뜻입니다.
보통 뒤쪽 포트가 안 떠 있거나, proxy_pass 대상이 잘못됐을 때 볼 수 있습니다.
또 다른 예시는 timeout입니다.
upstream timed out while reading response header from upstream이 경우 nginx가 뒤쪽 서버에 연결은 했지만, 응답을 제때 받지 못했다는 뜻입니다.
애플리케이션 처리 지연, DB 지연, 외부 연동 지연, 리소스 부족 등을 함께 봐야 할 수 있습니다.
로그를 볼 때는 한 줄만 보지 말고, 502가 발생한 시간대 전후를 같이 보는 것이 좋습니다.
grep "upstream" /var/log/nginx/error.log | tail -n 306단계. 애플리케이션 로그도 같이 확인하기
nginx 로그에 upstream 문제가 보이면, 뒤쪽 애플리케이션 로그도 같이 봐야 합니다.
예를 들어 Java, Tomcat, Node.js 같은 서비스라면 각 서비스 로그 위치가 다를 수 있습니다.
tail -n 100 /app/logs/application.log또는 systemd로 관리되는 서비스라면 journalctl을 볼 수 있습니다.
journalctl -u example-app -n 100 --no-pager여기서는 이런 내용을 확인합니다.
애플리케이션이 기동 중인지
포트 바인딩에 실패하지 않았는지
DB 연결 오류가 있는지
메모리 부족으로 종료되지 않았는지
외부 API 호출에서 지연이 발생했는지502는 겉으로는 웹 오류처럼 보이지만, 실제 원인은 애플리케이션 내부 오류일 수 있습니다.
7단계. 최근 변경사항 확인하기
502가 갑자기 발생했다면 최근 변경사항도 중요합니다.
예를 들면 다음과 같습니다.
nginx 설정 변경
애플리케이션 배포
WAS 재기동
방화벽 정책 변경
서버 재부팅
인증서 변경
DB 또는 외부 연동 장애운영 중에는 명령어 결과만 보는 것보다 “언제부터 발생했는지”를 같이 보는 것이 중요합니다.
장애 대응에서 시간은 단서입니다.
502가 10분 전부터 발생했다면, 10분 전후에 변경된 작업이나 로그를 먼저 확인해야 합니다.
운영 서버에서 조심할 점
502가 났다고 해서 아래 작업을 바로 실행하는 것은 조심해야 합니다.
systemctl restart nginx
systemctl restart example-app
kill -9 <PID>특히 kill -9는 마지막 수단에 가깝습니다.
프로세스가 정말 멈췄는지, 정상 종료가 가능한지, 이중화가 되어 있는지, 재기동 시 영향 범위가 어디까지인지 확인한 뒤 진행해야 합니다.
초보 운영자 입장에서는 “빨리 고쳐야 한다”는 압박이 크지만, 운영 서버에서는 빠른 조치보다 안전한 순서가 더 중요할 때가 많습니다.
정리하면
HTTP 502 Bad Gateway가 발생했을 때는 nginx 화면만 보고 nginx 문제로 단정하지 않는 것이 좋습니다.
확인 순서는 이렇게 잡을 수 있습니다.
1. curl -I로 502 응답 확인
2. nginx proxy_pass 또는 upstream 설정 확인
3. ss -lntp로 뒤쪽 포트 확인
4. upstream 주소로 직접 curl 테스트
5. nginx error.log 확인
6. 애플리케이션 로그 확인
7. 최근 변경사항 확인
8. 영향 범위 확인 후 조치502는 “앞단과 뒤쪽 서버 사이의 연결 문제”를 알려주는 신호일 수 있습니다.
그래서 nginx만 보는 것이 아니라, nginx가 어디로 요청을 넘기고 있는지, 그 뒤쪽 서버가 실제로 응답하고 있는지를 차분히 확인해야 합니다.
운영 서버에서는 항상 확인 → 판단 → 조치 순서가 먼저입니다.
하지만 502만 보고 nginx만 재기동하면 원인을 놓칠 수 있습니다.
포트 연결, upstream 상태, 애플리케이션 로그, HTTP 응답을 나눠서 확인하는 것이 좋습니다.
HTTP 오류 코드별 확인 순서를 한 번에 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/63
리눅스 서버 HTTP 응답 코드별 확인 순서 정리, 에러 코드만 봐도 방향이 보입니다
리눅스 서버에서 웹 장애가 발생했을 때 브라우저에 403, 404, 500, 502, 503, 504 같은 HTTP 응답 코드가 뜨면 처음에는 다 비슷한 오류처럼 보입니다. 하지만 서버 운영에서는 에러 코드만 잘 봐도 권한
opsnote.tistory.com
웹 장애 상황을 보고할 때 HTTP 코드를 어떻게 정리하면 좋은지는 아래 글에서 이어서 볼 수 있습니다. https://opsnote.tistory.com/64
리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드
리눅스 서버 운영을 하다 보면 웹 장애가 났을 때 “사이트 안 됩니다”, “접속이 안 돼요”, “nginx 에러 같아요”처럼 너무 크게 뭉뚱그려서 보고하게 될 때가 있습니다. 그런데 실제 장애 대
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 403 Forbidden 뜰 때 nginx 설정과 디렉터리 권한 확인하는 법 (0) | 2026.07.04 |
|---|---|
| 리눅스 서버 404 오류가 날 때 서버 죽은 줄 알기 전 먼저 확인할 것 (0) | 2026.07.04 |
| 리눅스 서버 Connection timed out 원인 확인하는 법 (0) | 2026.06.30 |
| 리눅스 서버 Connection refused 에러? 방화벽 탓하기 전 포트와 프로세스 상태 확인하는 법 (1) | 2026.06.29 |
| 리눅스 서버 안에서는 접속되는데 외부 접속이 안 될 때 방화벽 보기 전 Listen IP와 라우팅 경로 확인하는 법 (0) | 2026.06.28 |