“연결을 거부했습니다” 오류 해결기: Django 서비스 접속 불가 디버깅 사례(Feat. Nginx)

사내에서 운영 중인 여러 Django 기반 서비스가 있는데 주말을 지내고 출근해서 확인해 보니 모든 서비스가 접속이 안 되는 상황을 겪었다. 서버 환경에서의 에러는 다양한 환경과 변수에 의해 발생하기 때문에 정확한 분석이 중요하다. 이번 글을 통해 문제를 해결해 나가는 과정을 기록하고 공유하고자 한다.

초기 문제 분석

먼저, 접속이 안 되는 이유가 포트가 닫혀 있어서일 가능성을 염두에 두었다. 서버가 재부팅되면서 iptables 설정이 초기화된 것이라 생각 했고 이를 확인하기 위해 last 명령어로 시스템의 재부팅 기록을 확인하려 했다. 하지만 last 명령어가 정상적으로 동작하지 않았다.

원인 분석

지난주 다른 서비스 배포 과정에서 용량 확보를 위해 로그 파일들을 다른 디스크로 백업했었는데, 이 과정에서 log 파일을 통째로 옮겼던 것이 문제였다. log 파일이 참조되지 않으면서 시스템 로그를 확인할 수 없게 된 것이었고 로그 파일을 원래 위치로 옮겨주고 나서야 시스템 로그를 확인할 수 있었다.

재부팅 기록을 확인한 결과, 시스템이 부팅된 적이 없었다. 또한 netstat 으로 확인해 본 결과 포트도 정상적으로 열려있었다. 그렇다면 다른 원인이 있을 것이라고 생각했다.

심층 분석: Nginx 로그 확인

서비스는 Nginx를 통해 프락시 설정이 되어있었고 따라서 0.0.0.0:포트번호로 접근이 가능해야 했는데 Nginx 로그를 확인해 보니 로그 파일을 통째로 옮기면서 로그를 저장할 디렉터리가 없어 Nginx가 정상적으로 동작하지 않았다.

문제 해결

Nginx 로그를 저장할 디렉터리를 생성해 주었다.

디렉터리를 생성하니 Nginx가 정상적으로 동작하기 시작했고 모든 서비스가 정상적으로 복구되었다.

교훈

1. 로그 파일을 관리할 때, 파일을 통째로 옮기기보다는 백업 후 원본 파일을 압축 혹은 비우는 방식으로 용량을 확보해야 한다. 예를 들어, logrotate와 같은 도구를 사용해 자동으로 파일을 순환하고 백업할 수 있다.
2. 문제가 발생했을 때, 가능한 원인을 단계별로 분석하고 확인해야 한다. 네트워크 설정 -> 서버 로그 -> 애플리케이션 로그 순으로 혹은 역순으로 점검해 보면 원인을 찾을 수가 있다.