Tomcat 404, 502, 503, 504 오류 차이와 원인 정리

DevVest
Tomcat 404, 502, 503, 504 오류 차이와 원인 및 해결 방법

Tomcat으로 웹 서비스를 운영하다 보면 어느 날 갑자기 사이트 접속이 되지 않으면서 404, 502, 503, 504같은 HTTP 오류가 발생하는 경우가 있습니다.

처음 장애를 접하면 숫자만 다를 뿐 비슷한 오류처럼 보이지만, 실제로는 확인해야 하는 위치가 서로 다릅니다.

예를 들어 404는 요청한 URL이나 배포 상태를 확인해야 하는 경우가 많고, 502와 504는 Nginx나 Apache에서 Tomcat으로 요청을 전달하는 과정에서 발생하는 경우가 많습니다.

이번 글에서는 Tomcat 운영 중 자주 접할 수 있는 404, 502, 503, 504 오류의 차이와 각각 어떤 부분부터 확인해야 하는지 정리해보겠습니다.

먼저 서버 구조를 확인해야 합니다

오류를 확인하기 전에 현재 서비스가 어떤 구조로 되어 있는지 먼저 알아야 합니다.

Tomcat만 사용하는 경우도 있지만 운영 환경에서는 다음과 같이 Web Server와 WAS를 함께 사용하는 경우가 많습니다.

사용자
  ↓
Nginx / Apache
(Web Server)
  ↓
Tomcat
(WAS)
  ↓
Database

이 구조에서 사용자는 Nginx나 Apache에 접속하고, Web Server가 필요한 요청을 Tomcat으로 전달합니다.

따라서 브라우저에 표시되는 오류가 반드시 Tomcat 자체에서 발생했다고 볼 수는 없습니다.

404 Not Found

404 오류는 요청한 페이지나 리소스를 찾지 못했을 때 발생합니다.

예를 들어 사용자가 다음 주소로 요청했다고 가정해보겠습니다.

https://example.com/member/login

그런데 해당 URL을 처리할 Controller나 JSP, 정적 파일 등이 존재하지 않으면 404가 발생할 수 있습니다.

주요 원인

Tomcat 환경에서 자주 확인하는 원인은 다음과 같습니다.

  • URL 주소가 잘못된 경우
  • 애플리케이션 배포가 정상적으로 되지 않은 경우
  • WAR 파일 또는 ROOT 디렉터리에 문제가 있는 경우
  • Controller Mapping이 잘못된 경우
  • Context Path가 변경된 경우
  • JSP 또는 정적 파일이 존재하지 않는 경우

예를 들어 Tomcat의 webapps디렉터리를 확인합니다.

ls -al $CATALINA_HOME/webapps

정상적으로 배포되어 있다면 다음과 같은 디렉터리를 확인할 수 있습니다.

ROOT
manager
host-manager

ROOT 서비스를 운영하는데 ROOT 디렉터리가 없거나 WAR 압축 해제가 정상적으로 되지 않았다면 404가 발생할 수 있습니다.

404 발생 시 확인 순서

URL 확인
  ↓
Tomcat 실행 여부 확인
  ↓
WAR / ROOT 배포 상태 확인
  ↓
Controller 또는 JSP 확인
  ↓
Tomcat 로그 확인

502 Bad Gateway

502는 Gateway 역할을 하는 서버가 뒤쪽 서버로부터 정상적인 응답을 받지 못했을 때 발생합니다.

Tomcat을 Nginx와 함께 사용하는 환경이라면 다음 부분을 의심할 수 있습니다.

사용자
  ↓
Nginx
  ↓
X
Tomcat

Nginx는 정상적으로 실행되고 있지만 Tomcat과 연결하지 못하고 있는 상태입니다.

주요 원인

  • Tomcat 프로세스가 종료된 경우
  • Tomcat 포트가 열려 있지 않은 경우
  • Nginx의 proxy_pass 주소가 잘못된 경우
  • Tomcat IP 또는 포트가 변경된 경우
  • 방화벽에서 연결이 차단된 경우
  • Tomcat이 비정상 종료된 경우

예를 들어 Nginx 설정이 다음과 같다고 가정해보겠습니다.

location / {
    proxy_pass http://127.0.0.1:8080;
}

이 상태에서 Tomcat의 8080 포트가 실행되지 않는다면 Nginx는 요청을 전달하지 못하고 502를 반환할 수 있습니다.

Tomcat 프로세스를 확인합니다.

ps -ef | grep tomcat

또는 포트를 확인합니다.

ss -lntp | grep 8080

직접 Tomcat에 접근할 수 있다면 다음과 같이 확인하는 것도 좋습니다.

curl http://127.0.0.1:8080

여기서 응답이 나오지 않는다면 앞단 Nginx보다 Tomcat 상태를 먼저 확인해야 합니다.

503 Service Unavailable

503 오류는 현재 서버가 요청을 처리할 수 없는 상태라는 의미입니다.

404처럼 페이지가 없는 것도 아니고, 반드시 502처럼 연결 자체가 실패한 것도 아닙니다.

서비스가 존재하지만 일시적으로 요청을 처리하지 못하는 상태에서 발생할 수 있습니다.

주요 원인

  • Tomcat이 시작 중이거나 종료 중인 경우
  • 애플리케이션이 정상적으로 초기화되지 않은 경우
  • 서버 리소스가 부족한 경우
  • 요청이 너무 많이 몰린 경우
  • 커넥션 풀이나 스레드가 부족한 경우
  • Web Server가 Backend 서버를 사용 불가 상태로 판단한 경우
  • 점검 또는 유지보수 설정이 적용된 경우

예를 들어 Tomcat 자체 프로세스는 실행되어 있어도 애플리케이션 초기화 과정에서 오류가 발생했다면 정상적인 서비스가 제공되지 않을 수 있습니다.

이런 경우에는 catalina.out을 확인합니다.

tail -f $CATALINA_HOME/logs/catalina.out

또는 날짜별 로그가 있다면 해당 로그에서 오류를 확인합니다.

grep -i "error" catalina.out
grep -i "exception" catalina.out

504 Gateway Timeout

504는 운영 중 특히 자주 만나게 되는 오류입니다.

504 Gateway Timeout은 앞단 서버가 Tomcat으로 요청을 전달했지만 정해진 시간 안에 응답을 받지 못했을 때 발생합니다.

구조는 다음과 같습니다.

사용자
  ↓
Nginx / Apache
  ↓
Tomcat
  ↓
DB

요청 자체는 Tomcat까지 전달되었지만 응답이 너무 오래 걸리는 상황입니다.

주요 원인

  • SQL 실행 시간이 너무 긴 경우
  • DB 연결 지연
  • DB Lock
  • 외부 API 응답 지연
  • Tomcat Thread 고갈
  • Connection Pool 부족
  • 애플리케이션 내부 무한 대기
  • Web Server의 Timeout 시간 초과
  • Oracle 등 DB 계정의 잠금 또는 비밀번호 만료

예를 들어 Nginx의 timeout이 60초라고 가정해보겠습니다.

Tomcat에서 어떤 요청을 처리하는 데 70초가 걸리면 Nginx는 더 이상 기다리지 않고 504를 반환할 수 있습니다.

Nginx Timeout : 60초

Tomcat 처리시간 : 70초

→ 504 Gateway Timeout

따라서 504가 발생했다고 해서 단순히 timeout 설정부터 늘리는 것은 좋은 해결 방법이 아닙니다.

왜 응답에 60초 이상이 걸렸는지 확인하는 것이 먼저입니다.

실제 사례 – Oracle DB 계정 비밀번호 만료로 발생한 504

최근 고객사에서 웹사이트 접속 시 504 Gateway Timeout이 발생한 적이 있었습니다.

처음에는 504 오류였기 때문에 Tomcat의 응답 지연이나 네트워크 문제, DB 서버의 부하 등을 먼저 의심했습니다.

Tomcat 로그를 확인해보니 요청이 정상적으로 처리되지 않고 일정 시간 동안 대기하다가 Timeout이 발생하고 있었습니다.

이후 DB 서버와 Oracle 접속 상태를 확인한 결과, 애플리케이션에서 사용하던 Oracle DB 계정의 비밀번호 유효기간이 만료된 것이 원인이었습니다.

Oracle에서는 계정에 적용된 Profile 설정에 따라 비밀번호의 유효기간이 설정될 수 있습니다. 비밀번호가 만료되면 애플리케이션에서 기존 계정으로 새로운 DB Connection을 정상적으로 생성하지 못할 수 있습니다.

서비스 구조를 단순하게 보면 다음과 같은 상황이었습니다.

사용자 요청
    ↓
Web Server
    ↓
Tomcat
    ↓
DB Connection 시도
    ↓
Oracle 계정 비밀번호 만료
    ↓
DB 연결 실패 또는 요청 처리 지연
    ↓
정해진 시간 안에 응답하지 못함
    ↓
504 Gateway Timeout

브라우저에서는 단순히 504 Gateway Timeout만 표시되기 때문에 처음부터 Oracle 계정의 문제라고 판단하기는 쉽지 않았습니다.

이 사례에서 중요한 점은 504의 실제 원인이 반드시 Web Server나 Tomcat에 있는 것은 아니라는 것입니다.

Tomcat에서 DB 조회가 필요한 요청을 처리하고 있다면 DB 계정 상태, Connection Pool, DB 접속 가능 여부까지 함께 확인해야 합니다.

Oracle 계정 상태는 다음과 같이 확인할 수 있습니다.

SELECT
    USERNAME,
    ACCOUNT_STATUS,
    EXPIRY_DATE
FROM DBA_USERS
WHERE USERNAME = '계정명';

ACCOUNT_STATUS가 EXPIRED, EXPIRED(GRACE)등으로 표시되거나 EXPIRY_DATE가 만료된 상태라면 계정의 비밀번호 정책을 확인할 필요가 있습니다.

따라서 원인을 알 수 없는 504가 발생한다면 다음 항목도 점검 대상에 포함하는 것이 좋습니다.

  • Tomcat 로그의 DB Connection 관련 오류
  • Oracle DB 접속 가능 여부
  • 애플리케이션 DB 계정 상태
  • DB 계정 비밀번호 만료 여부
  • Connection Pool 상태
  • DB Lock 및 장시간 실행 SQL

이번 사례처럼 화면에 나타나는 오류는 504지만 실제 원인은 Oracle DB 인증 문제일 수도 있습니다.

그래서 504를 확인할 때는 단순히 Timeout 값을 늘리는 것보다 요청이 Web Server -> Tomcat -> DB 중 어느 구간에서 멈췄는지를 먼저 찾는 것이 중요합니다.

504 발생 시 어디부터 확인해야 할까?

먼저 Tomcat 로그에서 해당 시간대의 요청을 확인합니다.

tail -f catalina.out

특정 오류가 있다면 검색합니다.

grep -i "timeout" catalina.out

DB 쿼리를 실행하는 서비스라면 Slow Query나 DB Lock도 확인해야 합니다.

예를 들어 요청이 다음과 같은 흐름으로 실행된다고 가정해보겠습니다.

사용자 요청
   ↓
Controller
   ↓
Service
   ↓
DB Query
   ↓
300초 이상 대기

이 경우 브라우저에서는 단순히 504만 보이지만 실제 원인은 DB일 수 있습니다.

따라서 504는 Web Server뿐 아니라 Tomcat과 DB까지 함께 확인해야 하는 오류입니다.

404, 502, 503, 504 차이 한눈에 보기

오류의미우선 확인할 곳
404요청한 페이지를 찾지 못함URL, 배포, Controller
502Backend 서버에서 정상 응답을 받지 못함Tomcat 프로세스, 포트, Proxy
503현재 서비스를 처리할 수 없음Tomcat 상태, 자원, Thread
504Backend 응답 시간이 초과됨Tomcat 로그, DB, Timeout

조금 더 단순하게 기억하면 다음과 같습니다.

404
→ 요청한 것이 없음

502
→ Tomcat과 연결이 안 됨

503
→ 서비스는 있지만 현재 처리하기 어려움

504
→ 연결은 됐지만 응답이 너무 늦음

물론 실제 환경에서는 구성에 따라 원인이 달라질 수 있으므로 위 내용은 첫 번째 점검 기준으로 보는 것이 좋습니다.

실제 장애가 발생하면 먼저 확인하는 것

사이트 접속 장애가 발생하면 에러 코드만 보고 바로 설정을 변경하기보다 순서대로 확인하는 것이 좋습니다.

1. 서버 자체에 접속 가능한지 확인

ping 서버IP

환경에 따라 ICMP가 차단되어 있을 수 있으므로 ping이 실패한다고 서버가 반드시 죽은 것은 아닙니다.

2. Web Server 프로세스 확인

Nginx라면 다음과 같이 확인할 수 있습니다.

ps -ef | grep nginx

또는

systemctl status nginx

3. Tomcat 프로세스 확인

ps -ef | grep tomcat

Java 프로세스를 직접 확인하기도 합니다.

ps -ef | grep java

4. Tomcat 포트 확인

ss -lntp

필요한 포트만 확인하려면

ss -lntp | grep 8080

5. Tomcat 직접 호출

curl http://127.0.0.1:8080

Nginx에서는 접속이 안 되는데 Tomcat 직접 호출은 정상이라면 Proxy 설정이나 Web Server 쪽을 먼저 확인할 수 있습니다.

6. 로그 확인

tail -f catalina.out

Nginx를 사용하는 경우 Nginx 로그도 함께 확인합니다.

tail -f /var/log/nginx/error.log

단순히 Tomcat을 재시작하면 해결될까?

장애가 발생하면 가장 먼저 Tomcat을 재시작하고 싶은 경우가 많습니다.

실제로 재시작으로 일시적으로 정상화되는 경우도 있습니다.

하지만 다음과 같은 문제가 원인이라면 다시 장애가 발생할 수 있습니다.

  • DB 쿼리 지연
  • 메모리 부족
  • Thread 고갈
  • Connection Pool 고갈
  • 외부 API 지연
  • 디스크 용량 부족

따라서 운영 환경에서는 재시작하기 전에 가능한 한 로그와 현재 상태를 먼저 확인하는 것이 좋습니다.

재기동으로 정상화된 경우에도 왜 문제가 발생했는지 원인을 확인해야 동일한 장애의 재발을 막을 수 있습니다.

Timeout 값을 늘리면 504가 해결될까?

Timeout 값을 늘리면 증상 자체는 사라질 수 있습니다.

하지만 처리 시간이 비정상적으로 길어지는 원인이 해결되는 것은 아닙니다.

예를 들어 SQL 하나가 5분 이상 걸리고 있는데

60초 Timeout
↓
300초 Timeout

으로 변경하면 사용자가 5분 동안 기다리는 구조가 될 뿐입니다.

따라서 먼저

어떤 요청이 느린가?

↓

Tomcat에서 어디까지 처리됐는가?

↓

DB 쿼리는 정상인가?

↓

외부 연동에서 지연되고 있지는 않은가?

를 확인해야 합니다.

정상적인 처리인데 작업 특성상 시간이 오래 걸리는 경우에만 timeout 조정을 검토하는 것이 좋습니다.

요약

Tomcat 운영 중 발생하는 404, 502, 503, 504 오류는 비슷해 보이지만 확인해야 하는 위치가 다릅니다.

404는 URL이나 애플리케이션 배포 상태를 확인해야 하고, 502는 Nginx나 Apache에서 Tomcat으로 연결이 정상적인지 확인해야 합니다.

503은 서비스가 일시적으로 요청을 처리하지 못하는 상태이므로 서버 자원과 Tomcat 상태를 확인해야 합니다.

504는 Tomcat 또는 DB 처리 시간이 길어 Web Server의 Timeout 시간을 초과한 경우가 많으므로 애플리케이션 로그와 SQL, DB 연결 상태까지 함께 확인해야 합니다.

장애가 발생했을 때 무작정 Tomcat을 재시작하거나 Timeout을 늘리기보다 오류 코드에 따라 문제 구간을 먼저 좁히는 것이 중요합니다.

자주 묻는 질문(FAQ)

Q. Tomcat에서 502 오류가 발생하면 Tomcat 문제인가요?

반드시 그런 것은 아닙니다. 502는 보통 Nginx나 Apache 같은 Gateway가 Backend 서버에서 정상적인 응답을 받지 못했을 때 발생합니다. Tomcat 프로세스와 포트, Proxy 설정을 함께 확인해야 합니다.

Q. 504 오류는 DB 문제일 수도 있나요?

가능합니다. SQL 실행 지연, DB Lock, Connection Pool 부족 등으로 Tomcat 응답이 늦어지면 앞단 Web Server에서 504가 발생할 수 있습니다.

Q. 404가 발생하면 Tomcat이 종료된 상태인가요?

그렇지 않습니다. Tomcat이 정상적으로 실행 중이어도 요청한 URL이나 Controller, JSP, 정적 파일 등이 존재하지 않으면 404가 발생할 수 있습니다.

Q. 503과 502의 차이는 무엇인가요?

502는 Gateway가 뒤쪽 서버에서 정상적인 응답을 받지 못했다는 의미이고, 503은 서버가 현재 요청을 처리할 수 없는 상태라는 의미입니다.

Q. 장애가 나면 Tomcat부터 재시작해도 되나요?

운영 서비스라면 가능하면 재시작 전에 로그와 프로세스, 메모리, DB 상태 등을 확인하는 것이 좋습니다. 재시작으로 증상이 사라지면 원인을 확인하기 어려워질 수 있습니다.

Related Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다