Apache에서 404/500이 갑자기 늘어나면, 설정 파일부터 수정하고 싶어지지만 먼저 로그 위치를 확인하고 실제로 어떤 요청이 어떤 에러를 내는지부터 잡는 게 가장 빠릅니다.
로그를 보면 “무엇이 문제인지”가 보이고, 그 다음에 “어디를 고칠지”가 정해집니다.
이 글은 증상 → 점검 순서(체크리스트) → 해결 단계 흐름으로 정리합니다.
증상: 이런 상태면 로그부터 봐야 합니다
다음 중 하나라도 해당되면 접근 순서를 “로그 확인 → 원인 분리”로 두는 게 안전합니다.
- 특정 URL만 404가 나오거나, 전체적으로 404 비율이 갑자기 증가
- 간헐적으로 500이 뜨고 새로고침하면 정상으로 보이기도 함
- 배포 이후부터 에러가 늘었는데, 재현이 일정하지 않음
- 리버스 프록시(Nginx)나 CDN 뒤에 있어 원인이 Apache인지 애매함
브라우저(Chrome)에서 보이는 메시지는 힌트가 제한적이라, 서버 로그를 먼저 잡는 편이 결론이 빠릅니다.
로그 위치/확인법: 먼저 “지금 이 vhost”의 로그가 어디인지 찾기
Apache는 환경에 따라 로그 경로가 다릅니다. 가장 먼저 해야 할 일은 현재 트래픽을 받는 VirtualHost의 access/error 로그가 어디로 쓰이는지 확인하는 겁니다.
대표적인 기본 위치는 아래 중 하나입니다(배포판/설정에 따라 다름).
- Debian/Ubuntu 계열: /var/log/apache2/access.log, /var/log/apache2/error.log
- RHEL/CentOS 계열: /var/log/httpd/access_log, /var/log/httpd/error_log
하지만 운영에서는 vhost별로 분리되어 있는 경우가 흔합니다.
- apache2ctl -S 또는 httpd -S 로 어떤 vhost가 매핑되는지 확인
- vhost 설정에서 CustomLog(access), ErrorLog(error) 지시어 확인
- systemd 사용 시: journalctl -u apache2 또는 journalctl -u httpd 로 서비스 레벨 로그도 병행 확인
당장 필요한 건 “지금 발생한 요청 1건”을 access_log에서 찾고, 그 직후 시각의 error_log를 따라가는 겁니다.
점검 순서(체크리스트): 로그를 보면서 원인을 좁히는 루틴
아래 체크리스트는 access_log → error_log → 설정/파일/업스트림 순으로 좁히는 흐름입니다.
- 1) access_log: 문제 요청의 URI, status(404/500), 응답 크기, referer, user-agent 확인
- 2) 같은 시각 error_log: “File does not exist”, “Permission denied”, “AH0…” 코드, upstream 관련 메시지 확인
- 3) vhost 매칭: Host 헤더가 기대한 vhost로 들어가는지(기본 vhost로 떨어지면 404가 쉬움)
- 4) DocumentRoot/Directory: 실제 경로 존재 여부, Alias/Rewrite로 경로가 바뀌는지
- 5) 권한/소유권: Apache 실행 사용자(www-data, apache 등)가 읽을 수 있는지
- 6) Rewrite/Redirect: 무한 리다이렉트나 잘못된 rewrite로 404/500 유발 여부
- 7) 모듈/업스트림: PHP-FPM/ProxyPass/백엔드 오류가 500으로 표면화되는지
핵심은 “404냐 500이냐”보다도, error_log에 어떤 문장이 찍히는지입니다.
해결 단계 1: 404가 늘어났을 때(경로/호스트/Rewrite 중심)
404는 보통 “파일이 없거나(경로), 엉뚱한 vhost로 들어갔거나(Host/DNS), rewrite가 잘못된” 경우가 많습니다.
- vhost가 맞는지 확인: ServerName/ServerAlias가 요청 Host와 일치하는지, 기본 vhost로 떨어지지 않는지 점검
- DocumentRoot 실제 경로 확인: 배포 디렉터리가 바뀌었는데 설정만 그대로인 경우가 흔함
- Alias/Rewrite 규칙 재검토: 특정 경로만 404면 해당 Location/Directory 블록부터 확인
- .htaccess 영향 분리: AllowOverride 설정에 따라 .htaccess가 무시되거나, 반대로 예상치 못한 rewrite를 만들 수 있음
- 정적 파일 캐시/배포 누락: 빌드 산출물이 빠졌다면 access_log에서 특정 파일 확장자(css/js/png) 404가 집중되는 패턴이 보임
로그에서 “어떤 URI가 404인지”를 먼저 뽑아 리스트업하면, 수정은 의외로 단순해지는 편입니다.
해결 단계 2: 500이 늘어났을 때(권한/프로세스/업스트림 중심)
500은 Apache가 내부적으로 예외를 만났다는 뜻이라, error_log가 사실상 정답지입니다.
- 권한 문제: error_log에 “Permission denied”가 보이면 파일/디렉터리 권한과 Apache 실행 사용자부터 확인
- 설정 문법/모듈: 재시작 직후부터 500이면 conf 변경 이력과 apachectl configtest 결과를 우선 확인
- ProxyPass/백엔드 장애: “AH01102”, “connection refused”, “timeout”류면 백엔드(예: app server, PHP-FPM) 상태/타임아웃을 점검
- 리소스 부족: 동시 요청이 늘 때만 500이면 worker/thread, ulimit, 메모리 부족(OOM) 가능성을 같이 확인
500은 브라우저에서 보이는 정보가 거의 없으니, 요청 시각 기준으로 error_log 한 줄을 정확히 매칭하는 게 가장 중요합니다.
해결 단계 3: 수정 후 검증(재발 방지까지)
원인을 고쳤다면 “됐네”로 끝내지 말고, 같은 유형이 재발하지 않도록 최소한의 검증을 붙이는 게 좋습니다.
- 재현 요청 3회: 같은 URI를 2~3번 호출해 status가 안정적으로 200/301 등 기대값인지 확인
- 로그 패턴 확인: 수정 이후에도 같은 error 문구가 반복되는지 error_log에서 검색
- 롤백 포인트 기록: 어떤 설정/파일을 바꿨는지 짧게 기록(다음 장애 때 속도가 달라짐)
- 로그 로테이션 확인: logrotate 설정으로 로그가 잘 순환되는지(디스크 full로 500 유발 방지)
특히 디스크 사용량은 종종 놓치는데, 로그가 쌓여 파티션이 가득 차면 예상치 못한 500으로 번질 수 있습니다.
마무리
Apache에서 404/500이 늘었을 때는 “설정 추측”보다 로그 위치를 먼저 확정하고, 문제 요청을 access_log에서 찾은 다음 error_log로 따라가는 흐름이 가장 효율적입니다.
원인 문구만 정확히 잡히면, 대부분은 vhost 매칭/경로/권한/업스트림 중 하나로 깔끔하게 좁혀집니다.