리눅스 서버에서 웹페이지나 API 호출 중 500 Internal Server Error가 뜨면 nginx나 Apache 같은 웹서버 문제처럼 보일 수 있습니다. 하지만 서버 운영 중 만나는 500 오류는 앞단 웹서버보다 WAS, 애플리케이션 예외, DB 연결, 설정값 누락, 배포 오류에서 발생하는 경우가 많습니다. 이번 글에서는 500 오류가 났을 때 바로 재기동하지 않고, 애플리케이션 로그와 웹서버 로그를 어떤 순서로 확인하면 안전한지 정리해보겠습니다.
500 Internal Server Error는 무슨 뜻일까?
500 Internal Server Error는 서버 내부에서 요청을 처리하다가 문제가 생겼다는 뜻입니다.
404가 “요청한 경로를 못 찾음”,
403이 “접근이 막힘”에 가깝다면,
500은 “서버 안쪽에서 처리 중 오류가 발생함”에 가깝습니다.
예를 들면 이런 상황입니다.
애플리케이션 코드에서 예외 발생
DB 연결 실패
필수 환경변수 누락
설정 파일 오류
배포 후 라이브러리 충돌
외부 API 호출 실패
파일 업로드 경로 문제
권한 문제로 내부 처리 실패그래서 500이 떴다고 바로 nginx만 보거나 웹서버를 재기동하면 원인을 놓칠 수 있습니다.
초보 운영자가 하기 쉬운 실수
500 오류가 뜨면 급한 마음에 이렇게 하고 싶어집니다.
systemctl restart nginx
systemctl restart example-app물론 재기동으로 일시 복구되는 경우도 있습니다.
하지만 운영 서버에서는 먼저 왜 500이 났는지 확인해야 합니다.
500은 보통 애플리케이션이 요청을 처리하다가 내부에서 넘어지는 오류라서,
진짜 단서는 브라우저 화면보다 로그 안에 있는 경우가 많습니다.
운영에서는 이번에도 순서가 중요합니다.
화면 확인
상태코드 확인
웹서버 로그 확인
애플리케이션 로그 확인
최근 변경사항 확인
영향 범위 확인 후 조치500 오류는 애플리케이션 내부 문제일 가능성이 크지만, 502는 앞단 웹서버와 뒤쪽 서버 연결 문제일 수 있습니다. HTTP 상태코드별로 보는 순서를 나눠두고 싶다면 “리눅스 서버 HTTP 502 Bad Gateway 뜰 때 nginx만 보지 말고 확인하는 순서” 글도 함께 보면 좋습니다.1단계. curl로 500 응답이 맞는지 확인하기
브라우저 화면만 보고 판단하지 말고 curl로 상태코드를 확인합니다.
curl -I http://example.com/api/users예시 결과입니다.
HTTP/1.1 500 Internal Server Error
Server: nginx
Content-Type: application/json여기서 볼 것은 두 가지입니다.
1. 실제 HTTP 상태코드가 500인지
2. 응답을 누가 반환하는지Server: nginx가 보인다고 해서 nginx가 원인이라는 뜻은 아닙니다.
nginx는 앞에서 응답을 전달하는 역할만 하고, 실제 500은 뒤쪽 애플리케이션에서 발생했을 수 있습니다.
2단계. 어떤 URL에서 500이 나는지 확인하기
500은 전체 서비스에서 발생할 수도 있고, 특정 API나 특정 화면에서만 발생할 수도 있습니다.
아래처럼 경로별로 확인해봅니다.
curl -I http://example.com/
curl -I http://example.com/login
curl -I http://example.com/api/users
curl -I http://example.com/api/orders예를 들어 결과가 이렇게 다를 수 있습니다.
/ → 200 OK
/login → 200 OK
/api/users → 500 Internal Server Error
/api/orders → 200 OK이 경우 서버 전체 장애라기보다 /api/users 요청을 처리하는 기능에서 문제가 생겼을 가능성이 큽니다.
초보 운영자는 “사이트가 안 된다”고 크게 느낄 수 있지만,
운영에서는 먼저 전체 장애인지, 특정 기능 장애인지를 나눠보는 게 중요합니다.
3단계. nginx access.log에서 요청 경로 확인하기
nginx를 앞단 웹서버로 사용한다면 access log를 먼저 확인합니다.
tail -n 100 /var/log/nginx/access.log500이 찍힌 요청은 이런 식으로 보일 수 있습니다.
192.0.2.10 - - [04/Jul/2026:11:00:00 +0900] "GET /api/users HTTP/1.1" 500 52 "-" "Mozilla/5.0"여기서 확인할 것은 다음입니다.
어떤 URL이 500인지
GET인지 POST인지
특정 사용자 요청에서만 발생하는지
특정 시간대에 몰려 있는지
응답 크기가 평소와 다른지access log는 “어떤 요청이 실패했는지”를 보여줍니다.
하지만 왜 실패했는지는 보통 애플리케이션 로그에서 봐야 합니다.
4단계. nginx error.log도 같이 확인하기
웹서버 로그도 확인합니다.
tail -n 100 /var/log/nginx/error.log만약 upstream 관련 메시지가 보이면 502나 504 성격이 섞여 있을 수도 있습니다.
upstream prematurely closed connection while reading response header from upstream하지만 nginx error.log가 조용한데 access.log에는 500이 찍힌다면,
애플리케이션이 정상적으로 응답은 했지만 내부 오류 상태코드 500을 반환했을 가능성이 있습니다.
이때는 nginx 재기동보다 애플리케이션 로그가 먼저입니다.
5단계. 애플리케이션 로그 확인하기
500 오류의 핵심은 대개 애플리케이션 로그에 있습니다.
예를 들어 애플리케이션 로그 위치가 /app/logs/application.log라면 아래처럼 확인합니다.
tail -n 200 /app/logs/application.logsystemd 서비스로 관리 중이면 journalctl을 볼 수도 있습니다.
journalctl -u example-app -n 200 --no-pager여기서 확인할 단서는 이런 것들입니다.
Exception
ERROR
NullPointerException
Connection refused
Connection timed out
Permission denied
No such file or directory
Database connection failedJava 애플리케이션이라면 예외 스택트레이스가 길게 찍힐 수 있습니다.
Node.js라면 TypeError, ReferenceError, DB client 오류가 보일 수 있습니다.
중요한 건 로그를 맨 아래 한 줄만 보는 게 아니라,
500이 발생한 시간대 전후를 같이 보는 것입니다.
grep -i "error\|exception\|failed" /app/logs/application.log | tail -n 50운영 서버에서는 로그가 많을 수 있으니, 시간대와 요청 URL을 같이 맞춰 보는 게 좋습니다.
6단계. DB 연결 오류인지 확인하기
500은 DB 연결 문제로도 자주 발생합니다.
애플리케이션 로그에서 이런 메시지가 보일 수 있습니다.
Database connection failed
Connection refused
Too many connections
Communications link failure이 경우 애플리케이션 코드가 아니라 DB 접속 문제일 수 있습니다.
운영 서버에서는 바로 DB를 재기동하기보다, 먼저 애플리케이션이 사용하는 DB 주소와 포트 연결이 가능한지 확인합니다.
ss -lntp | grep 3306DB가 다른 서버에 있다면 애플리케이션 서버에서 포트 연결을 확인할 수 있습니다.
nc -vz 198.51.100.10 3306단, 운영 환경에서는 보안 정책상 nc가 없거나 차단될 수 있습니다.
이럴 때는 방화벽 정책, DB 상태, 애플리케이션 설정을 함께 확인해야 합니다.
7단계. 최근 배포와 설정 변경 확인하기
500은 배포 직후 자주 발생합니다.
예를 들면 이런 경우입니다.
환경변수 누락
설정 파일 경로 변경
DB 비밀번호 변경
라이브러리 버전 충돌
권한 없는 디렉터리에 파일 쓰기
신규 API 배포 후 예외 발생
외부 연동 주소 변경그래서 500이 갑자기 발생했다면 먼저 확인할 질문은 이것입니다.
언제부터 500이 발생했는가?
그 직전에 배포나 설정 변경이 있었는가?
특정 기능에서만 발생하는가?
전체 사용자가 영향을 받는가?운영에서 시간은 꽤 좋은 탐정입니다.
장애 시점과 변경 시점을 붙여보면 로그가 갑자기 말을 하기 시작합니다.
8단계. 리소스 부족 여부도 확인하기
애플리케이션 내부 오류가 리소스 부족에서 시작될 수도 있습니다.
기본적으로 CPU, 메모리, 디스크를 확인합니다.
top
free -m
df -h메모리 부족으로 프로세스가 불안정하다면 OOM 로그도 볼 수 있습니다.
dmesg -T | grep -i "out of memory\|killed process"디스크가 꽉 차서 로그나 임시 파일을 쓰지 못해 500이 발생하는 경우도 있습니다.
df -h
du -sh /app/logs/*단, 디스크 용량이 부족하다고 바로 파일을 삭제하는 것은 조심해야 합니다.
어떤 파일이 커졌는지, 삭제해도 되는 파일인지, 애플리케이션이 잡고 있는 deleted 파일은 아닌지 확인하고 조치해야 합니다.
9단계. 권한 문제인지 확인하기
500은 내부 처리 중 파일을 읽거나 쓰지 못해서 발생하기도 합니다.
예를 들어 업로드 경로, 로그 경로, 임시 파일 경로 권한이 문제일 수 있습니다.
ls -ld /app/uploads
ls -ld /app/logs
ls -l /app/config애플리케이션 실행 계정도 확인합니다.
ps -ef | grep example-app로그에 Permission denied가 보인다면 해당 경로의 소유자와 권한을 확인해야 합니다.
하지만 이때도 바로 chmod -R 777 같은 방식은 피해야 합니다.
필요한 경로에 필요한 권한만 주는 것이 안전합니다.
10단계. 조치 전 영향 범위 확인하기
500이 발생한다고 바로 재기동하면 원인 로그가 밀리거나, 정상 요청까지 끊길 수 있습니다.
조치 전에는 최소한 아래를 확인합니다.
전체 서비스 장애인지
특정 API만 문제인지
이중화 구성이 있는지
재기동 시 사용자 영향이 있는지
최근 배포 롤백이 가능한지
현재 로그를 보존해야 하는지재기동이 필요한 경우에도 순서가 있습니다.
로그 확보
영향 범위 확인
관련 담당자 공유
재기동 또는 롤백 판단
조치 후 상태코드 재확인초보 운영자 입장에서는 빨리 고치고 싶은 마음이 먼저 올라오지만,
운영 서버에서는 빠른 손보다 차분한 순서가 더 안전할 때가 많습니다.
정리하면
500 Internal Server Error는 앞단 화면만 보고 판단하기 어려운 오류입니다.
nginx 화면에 보이더라도 실제 원인은 애플리케이션 내부 예외, DB 연결, 설정 누락, 권한 문제, 리소스 부족일 수 있습니다.
확인 순서는 이렇게 잡을 수 있습니다.
1. curl -I 로 500 상태코드 확인
2. 어떤 URL에서 500이 나는지 확인
3. nginx access.log 확인
4. nginx error.log 확인
5. 애플리케이션 로그 확인
6. DB 연결 오류 확인
7. 최근 배포와 설정 변경 확인
8. CPU, 메모리, 디스크 확인
9. 파일 권한과 경로 확인
10. 영향 범위 확인 후 조치그래서 500이 보인다고 바로 nginx나 Apache만 재기동하기보다, 애플리케이션 로그, 서버 로그, 최근 배포 여부, 설정 변경, 권한 문제를 함께 확인하는 것이 좋습니다.
500은 화면에 보이는 메시지보다 서버 안쪽 로그가 더 중요합니다.
웹서버 로그와 애플리케이션 로그를 나눠서 확인해야 원인을 좁힐 수 있습니다.
HTTP 오류 코드별 확인 순서를 한 번에 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/63
리눅스 서버 HTTP 응답 코드별 확인 순서 정리, 에러 코드만 봐도 방향이 보입니다
리눅스 서버에서 웹 장애가 발생했을 때 브라우저에 403, 404, 500, 502, 503, 504 같은 HTTP 응답 코드가 뜨면 처음에는 다 비슷한 오류처럼 보입니다. 하지만 서버 운영에서는 에러 코드만 잘 봐도 권한
opsnote.tistory.com
리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드
리눅스 서버 운영을 하다 보면 웹 장애가 났을 때 “사이트 안 됩니다”, “접속이 안 돼요”, “nginx 에러 같아요”처럼 너무 크게 뭉뚱그려서 보고하게 될 때가 있습니다. 그런데 실제 장애 대
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 504 Gateway Timeout 뜰 때 응답 지연부터 확인하는 법 (0) | 2026.07.06 |
|---|---|
| 리눅스 서버 503 Service Unavailable 뜰 때 서비스 상태부터 확인하는 법 (1) | 2026.07.05 |
| 리눅스 서버 403 Forbidden 뜰 때 nginx 설정과 디렉터리 권한 확인하는 법 (0) | 2026.07.04 |
| 리눅스 서버 404 오류가 날 때 서버 죽은 줄 알기 전 먼저 확인할 것 (0) | 2026.07.04 |
| 리눅스 서버 HTTP 502 Bad Gateway 뜰 때 nginx만 보지 말고 확인하는 순서 (0) | 2026.07.02 |