SERVER ERROR CLINIC
응답을 만든 서버가 요청을 처리할 수 없는 예상 밖의 상황을 만났습니다. 프록시 구성에서는 앱이 만든 경우가 흔하지만 코드만으로 생성 계층을 확정할 수는 없습니다.
이 도구는 여러분의 서버에 접속하지 않습니다. 답한 내용만으로 확인할 순서를 정해주는 도구이며, 실제 로그를 대신하지 않습니다.
어느 로그를 볼까 응답을 실제로 만든 계층의 오류 로그를 봅니다. 앱이 생성했다면 요청 식별자와 같은 시각의 앱 로그를 찾고, 로그가 비어 있으면 오류 처리·출력 경로도 확인합니다.
원인 후보 3개
고장은 대개 마지막으로 바꾼 것에서 옵니다.
가장 먼저 확인할 것
처리되지 않은 오류가 그대로 500이 되어 나왔습니다. 값이 없는데 꺼내 쓰는 경우가 압도적으로 많습니다.
다른 후보가 하나씩 제외되면서 남은 원인입니다.
앱 로그에서 예외가 난 지점을 찾습니다.
journalctl -u <서비스이름> -n 100 --no-pager | grep -i -A20 'error\|exception'그다음 스택 트레이스의 맨 윗줄이 아니라, 내가 쓴 파일이 처음 나오는 줄을 봅니다. 거기가 실제 원인입니다.
아니라면 다음
환경변수나 비밀값이 배포 환경에만 빠져 있습니다. 내 컴퓨터에선 되는데 서버에서만 500이 나는 전형적인 이유입니다.
앱이 실제로 받은 환경변수를 확인합니다.
systemctl show <서비스이름> -p Environment그다음 빠진 값을 채우되, 앱이 시작할 때 필수 설정이 없으면 곧바로 멈추고 이름을 찍도록 만들어 두면 다음부터 1분 안에 찾습니다.
아니라면 다음
연결은 되는데 쿼리가 실패합니다. 마이그레이션이 안 돌아 컬럼이 없는 경우가 많습니다.
데이터베이스 쪽에 남은 오류 메시지를 봅니다.
docker compose logs --tail 50 db그다음 마이그레이션이 실제로 적용됐는지 확인합니다. 배포는 됐지만 마이그레이션만 빠지는 일이 자주 있습니다.
실험을 마쳤다면