웹서버 로그로 404·5xx 원인 찾는 법
- 404는 요청 경로와 실제 파일·라우팅을 대조해 원인을 찾습니다.
- 5xx는 access log와 error log를 시간·요청 기준으로 연결합니다.
- 로그 집계 후 재현과 조치 전후 비교까지 해야 원인을 좁힐 수 있습니다.
웹서버 로그에서 404·5xx 원인을 분석할 때는 먼저 요청 시각, URL, 상태 코드를 기준으로 access log(요청·응답 기록)를 찾고, 같은 시각의 error log(처리 중 진단 메시지)와 대조합니다. 404는 서버가 요청한 리소스를 찾지 못한 응답이고, 5xx는 서버나 중간 게이트웨이가 요청 처리에 실패했다는 신호입니다. 상태 코드만 보고 원인을 단정하지 말고, 같은 URL의 반복 여부와 배포·설정 변경 시점을 함께 확인하세요.
먼저 로그에서 확인할 항목
상태 코드와 요청 경로를 한 묶음으로 보기
access log에서 발생 시각, HTTP 메서드(GET·POST 등), 요청 경로, 상태 코드, 응답 크기, 클라이언트 주소와 가능하다면 요청 ID를 확인합니다. Nginx의 기본 combined 형식은 요청과 상태 코드 등을 기록하며, 설정에 따라 필드가 달라질 수 있습니다. Apache도 로그 형식을 직접 정할 수 있으므로, 아래 예시의 필드 위치가 모든 서버에 똑같이 적용된다고 가정하지 마세요. Nginx 공식 로그 모듈 문서와 Apache 공식 로그 문서에서 현재 설정을 확인할 수 있습니다.
access log와 error log의 역할 구분
access log는 어떤 요청이 어떤 응답 코드로 끝났는지 보여주고, error log는 파일 접근 실패, 리라이트 처리, 프록시 연결 실패, 애플리케이션 오류 등의 단서를 제공합니다. 두 로그의 시각대를 맞춘 다음 같은 초 또는 수 초 범위의 항목을 비교하세요. Apache에서는 기본 로그 수준 설정에 따라 일부 404 관련 메시지가 error log에 표시되지 않을 수 있습니다. 따라서 error log에 관련 문구가 없다는 이유만으로 오류가 없었다고 판단하면 안 됩니다.
핵심: 상태 코드는 결과를 보여줄 뿐 원인을 설명하지 않습니다. 요청 경로·시각·요청 ID를 기준으로 access log와 error log를 함께 읽어야 합니다.
웹서버 로그 분석 4단계
1단계: 오류가 재현되는 요청을 특정합니다
브라우저 개발자 도구나 curl 등으로 문제가 난 URL, 요청 방식, 발생 시각을 기록합니다. 로그인 여부, 쿼리 문자열, 특정 사용자나 지역에서만 발생하는지도 함께 남기세요. 개인정보가 포함될 수 있는 쿠키나 인증 헤더는 로그에 복사하거나 공유하지 않습니다. 프록시나 CDN을 거치는 구조라면 어느 구간의 로그를 보는지 먼저 정해야 합니다.
2단계: access log에서 코드와 URL을 집계합니다
로그 포맷이 일반적인 Combined 형식이고 상태 코드가 9번째 필드에 있는 경우, 다음 명령으로 404와 5xx 응답 수를 빠르게 확인할 수 있습니다. 실제 필드 위치가 다르거나 JSON 로그라면 그 형식에 맞춰 파싱해야 합니다.
awk '$9 == 404 {count++} END {print "404", count+0}' access.log
awk '$9 ~ /^5[0-9][0-9]$/ {count[$9]++} END {for (code in count) print code, count[code]}' access.log전체 건수만으로는 우선순위를 정하기 어렵습니다. 동일 URL에서 계속 발생하는지, 특정 시간대에 몰리는지, 배포 직후 새로 생겼는지 확인하세요. 로그가 여러 파일로 회전되었다면 장애 시간대가 포함된 파일을 빠뜨리지 않도록 합니다.
3단계: 같은 요청의 error log와 주변 지표를 맞춥니다
요청 시각과 경로를 기준으로 error log를 좁혀 보고, 프록시를 쓰는 경우 upstream(요청을 넘겨받는 뒷단 서버) 상태 코드와 응답 시간도 확인합니다. Nginx에서는 기본 로그에 upstream 정보가 없을 수 있으므로 필요한 변수를 로그 포맷에 기록하도록 구성해야 합니다. 애플리케이션 로그, 데이터베이스 연결 오류, CPU·메모리·디스크 여유, 배포 내역도 같은 시간대에 비교합니다.
4단계: 가설을 하나씩 검증하고 전후를 비교합니다
원인 후보를 정한 뒤 해당 요청을 다시 보내거나 같은 조건에서 재현하고, 한 번에 한 가지 설정이나 코드만 변경합니다. 오류 코드가 사라졌는지뿐 아니라 정상 요청도 계속 처리되는지 살핍니다. 조치 전후의 URL별 오류 수와 발생 시간대를 비교하고, 동일 오류가 재발하는지 관찰해야 일시적 회복과 실제 해결을 구분할 수 있습니다.
404와 5xx는 이렇게 원인을 좁힙니다
404: 잘못된 경로인지, 존재하는 콘텐츠인지 확인
먼저 URL 오타, 대소문자 차이, 인코딩, 끝 슬래시, 쿼리 문자열을 확인합니다. Linux 기반 파일 시스템은 대소문자를 구분할 수 있으며, 웹 애플리케이션은 실제 파일이 아니라 라우팅 규칙으로 페이지를 제공할 수도 있습니다. 그러므로 파일 존재 여부만 확인하지 말고 가상 호스트, document root, rewrite 규칙, 애플리케이션 라우트도 대조하세요. 특정 Referer에서만 404가 반복되면 그 링크를 만든 내부 페이지나 외부 유입 링크가 잘못되었는지 살펴봅니다.
콘텐츠가 영구적으로 이동했고 대체 페이지가 명확하면 301 리다이렉트를 고려합니다. 삭제된 페이지에 적절한 대체 콘텐츠가 없다면 404 또는 410 응답을 유지하는 편이 맞을 수 있습니다. 모든 오류 URL을 홈페이지로 보내면 사용자는 찾던 콘텐츠를 찾지 못하고 검색엔진에는 존재하지 않는 페이지가 정상인 것처럼 보일 수 있습니다. Google은 내용상 오류 페이지인데 200을 반환하는 경우 soft 404로 분류할 수 있다고 안내합니다. Google 검색 크롤링 오류 안내를 참고하세요.
5xx: 오류 코드만으로 서버 내부 원인을 단정하지 않기
500은 애플리케이션 예외나 설정 문제, 502는 게이트웨이와 뒷단 서버 간 응답 문제, 503은 일시적인 처리 불가, 504는 시간 초과와 연관될 수 있습니다. 다만 실제 의미는 프록시·로드밸런서·애플리케이션 중 어느 계층이 응답했는지에 따라 달라질 수 있습니다. access log의 상태와 upstream 상태가 다르면 오류가 발생한 구간을 찾는 단서가 됩니다. 예를 들어 프록시는 502를 반환했지만 upstream 연결 기록이 없다면 연결 경로나 대상 서버 상태부터 확인할 수 있습니다.
검색 노출 주의: Google은 5xx와 429 응답을 크롤링 속도를 낮추는 신호로 다루며, 지속되는 서버 오류는 색인에 영향을 줄 수 있습니다. 단기 장애를 임시로 숨기려고 오류 페이지에 200을 반환하지 말고 실제 응답 상태와 복구 상황을 확인하세요.
결과를 운영 조치로 연결하기
| 로그에서 보이는 패턴 | 먼저 확인할 곳 | 다음 조치 |
|---|---|---|
| 일부 URL의 404 반복 | URL, 링크, 라우팅·리라이트 | 링크 수정 또는 적절한 리다이렉트 |
| 정적 파일에서만 404 | 배포 산출물, 파일 경로·대소문자 | 파일 배포와 참조 경로 대조 |
| 특정 시각에 5xx 급증 | 배포 내역, 리소스, 앱·DB 로그 | 변경점과 포화·의존성 오류 검증 |
| 프록시 응답과 upstream 불일치 | 프록시 연결, upstream 상태·시간 | 뒷단 서버와 타임아웃 설정 점검 |
운영 보고에는 발생 시간대, 영향을 받은 URL, 코드별 건수, 재현 여부, 원인으로 확인된 증거, 조치와 재발 여부를 남기세요. 원인 미확정 상태라면 추정과 확인된 사실을 구분합니다. 오류율이나 복구 시간을 지속적으로 추적하려면 서비스 수준 지표(SLI, 서비스 상태를 측정하는 지표)와 목표(SLO, 지표의 목표 기준)를 정하는 방법도 도움이 됩니다. 서비스 SLI·SLO 지표 정하는 방법에서 지표 설계 흐름을 확인할 수 있습니다.
자주 묻는 질문
Q. 404가 error log에 없으면 로그 설정이 잘못된 건가요?
반드시 그렇지는 않습니다. 서버 설정에 따라 404 세부 메시지가 error log에 기록되지 않을 수 있으므로 access log에서 상태 코드와 요청 경로를 먼저 확인하세요.
Q. access log의 상태 코드가 502면 애플리케이션이 원인인가요?
단정할 수 없습니다. 프록시나 게이트웨이가 반환했을 수 있으므로 upstream 상태, 연결 오류, 응답 시간과 애플리케이션 로그를 함께 대조해야 합니다.
Q. 404 URL은 모두 301로 보내면 되나요?
아닙니다. 의미가 가까운 대체 페이지가 실제로 있을 때 영구 이동을 고려합니다. 대체 콘텐츠가 없다면 404나 410을 반환하고, 사이트 내부의 잘못된 링크는 원본 링크를 수정하는 것이 적절합니다.
Q. 로그 분석 결과를 공유할 때 주의할 점은 무엇인가요?
로그에는 IP 주소, URL 매개변수, 사용자 입력값 등 민감한 정보가 섞일 수 있습니다. 분석에 필요하지 않은 식별 정보를 제거하고 접근 권한을 제한한 뒤 공유하세요.
