서버 다운: 가장 먼저, 어떤 순서로 확인할까요

이 가이드는 서버 자체를 다룹니다. 직접 운영하는 VPS, 전용 서버 또는 클라우드 서버입니다. 웹사이트 하나만 실패하고 머신의 나머지는 정상이거나 사이트가 공유 호스팅에 있다면, 대신 가이드 웹사이트 다운: 해야 할 일부터 시작하세요. 여기서는 머신을 살펴봅니다. 응답은 하는지, 접속할 수 있는지, 무엇이 멈췄는지입니다.

1단계: 정확히 무엇이 다운되었나요?

“서버가 다운되었다”는 전혀 다른 세 가지를 뜻할 수 있고, 각각 해결 방법이 다릅니다. 먼저 내 것이 아닌 네트워크에서 외부로부터 확인하세요. 서버의 웹사이트라면 웹사이트 다운 확인 도구가 이름이 확인되는지, 포트가 응답하는지, 어떤 상태 코드가 돌아오는지 몇 초 안에 알려 줍니다. 머신에 대해서는 내 컴퓨터에서 핑과 포트 테스트를 사용하세요.

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

결과를 함께 해석하세요.

• 핑 없음, SSH 없음, 웹 포트 없음: 머신이 꺼졌거나, 멈췄거나, 앞단의 네트워크가 다운되었습니다. 2단계로 가세요.
• 핑은 응답하고 SSH는 응답하지 않음: 머신은 실행 중이지만 SSH가 차단되었거나, 중지되었거나, 서버가 너무 과부하되어 응답하지 못합니다. 3단계로 가세요.
• SSH는 작동하는데 웹사이트는 작동하지 않음: 서버는 정상이고 서비스가 정상이 아닙니다. 4단계로 가세요.

일부 서버는 일부러 핑을 차단합니다. 핑이 원래 되지 않았다면 포트 테스트를 기준으로 삼으세요.

2단계: 아무것도 응답하지 않음

무엇보다 먼저 제공업체의 제어판이나 클라우드 콘솔을 여세요. 세 가지 질문으로 대부분의 경우 1분 안에 정리됩니다.

1. 서버가 실행 중인가요? 중지된 인스턴스, 정지된 계정, 실패한 결제는 외부에서 보면 장애와 똑같아 보입니다.
2. 알려진 장애가 있나요? 제공업체의 상태 페이지에서 내 리전이나 데이터 센터를 확인하세요.
3. 콘솔에 무엇이 표시되나요? 웹 또는 시리얼 콘솔은 네트워크가 없어도 머신의 화면을 보여 줍니다. 커널 패닉, 반복되는 “Out of memory: Killed process”, 파일 시스템 검사에서 멈춘 부팅은 각각 문제가 어디에 있는지 알려 줍니다.

머신이 멈췄다면 콘솔에서 재부팅하면 대개 복구됩니다. 재부팅하기 전에 콘솔의 스크린샷을 찍어 두세요. 다시 시작하면 증거가 사라집니다. 부팅되지 않는다면 대부분의 제공업체가 복구 시스템을 제공하며, 그곳에서 디스크를 마운트하고, 로그를 읽고, /etc/fstab이나 망가진 네트워크 설정을 수리할 수 있습니다.

3단계: 핑은 응답하지만 SSH는 응답하지 않음

머신이 살아 있으므로 원인은 머신 안에 있습니다. 콘솔로 로그인한 후 흔한 원인을 확인하세요.

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

서둘러 추가한 방화벽 규칙, 비밀번호를 몇 번 틀려서 차단된 내 IP 주소, 테스트에 실패한 SSH 설정 변경이 가장 흔한 잠금 원인입니다. sudo fail2ban-client set sshd unbanip YOUR_IP로 내 주소의 차단을 해제하고, SSH를 재시작하기 전에는 항상 sudo sshd -t를 실행하세요. SSH는 실행 중인데 매우 느릴 뿐이라면 서버가 과부하된 것입니다. 4단계로 가세요.

4단계: 접속했다면, 네 가지 수치를 읽으세요

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• 부하(uptime): CPU 코어 수를 훨씬 넘으면 머신이 과부하된 것입니다. top 또는 htop이 어떤 프로세스가 원인인지 보여 줍니다.
• 메모리(free -m): 여유 메모리도 스왑도 없고 dmesg에 “Killed process”가 있으면, 커널이 살아남기 위해 프로세스를 종료한 것입니다. 대개 데이터베이스나 PHP였습니다.
• 디스크(df -h): 가득 찬 디스크는 서버 문제의 가장 빈번한 원인입니다. 데이터베이스가 쓰기를 멈추고, 로그가 멈추고, 세션이 실패합니다. df -i는 inode를 확인합니다. 수백만 개의 작은 파일이 모든 inode를 소진하면 몇 기가바이트가 남아 있어도 디스크가 “가득 찬” 상태가 될 수 있습니다.
• I/O 오류 또는 읽기 전용 파일 시스템이 dmesg에 있으면: 디스크 자체에 문제가 있습니다. 쓰기를 멈추고, 가능하다면 백업을 만든 후 제공업체에 문의하세요.

공간을 안전하게 확보하려면 시스템 저널과 오래된 아카이브부터 시작하세요.

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

공간을 만들기 위해 데이터베이스 파일이나 웹사이트 파일을 삭제해서는 안 됩니다.

5단계: 어떤 서비스가 왜 중지되었나요

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed는 오류와 함께 중지된 모든 서비스를 나열합니다. 해당 서비스의 저널이 이유를 알려 줍니다. 이미 사용 중인 포트, 설정 파일의 구문 오류, 누락된 인증서, 남은 공간 없음 등입니다. 재시작하기 전에 항상 설정을 테스트하고(nginx -t, apachectl configtest, php-fpm -t), sudo systemctl restart SERVICE로 시작하세요. 테스트 없이 재시작하면 반쯤 작동하던 서비스까지 내려갈 수 있습니다.

6단계: 무엇이 바뀌었나요?

장애에는 원인이 있고, 원인은 대개 마지막 변경입니다. 찾아보세요.

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

자동 업데이트, 재부팅을 기다리는 새 커널, 배포, 백업으로 디스크를 가득 채운 Cron 작업, 만료된 인증서, 다른 사람의 설정 수정. 이 중 하나가 장애 시작 시각과 맞아떨어지면 단서를 찾은 것입니다.

같은 서버 문제가 반복될 때

가득 찬 디스크나 중지된 데이터베이스 때문에 한 번 다운된 서버는 또 그럴 것입니다. 외부에서 확인하면 다운되었을 때 알 수 있고, 내부에서 확인하면 그 전에 알 수 있습니다. 서버 에이전트는 머신 내부에서 부하, 메모리, 디스크, 서비스를 보고하며, 디스크가 설정한 임계값을 넘거나 선택한 서비스가 중지되면 아직 조치할 시간이 있을 때 알림을 보냅니다. 에이전트를 이용한 서버 모니터링은 유료 요금제에 포함됩니다.

새벽 3시에 이 작업을 하고 싶지 않다면

서버가 다운되었고 직접 디버깅하기보다 복구를 맡기고 싶다면, Quick Fix가 흔한 원인을 고정 가격으로 처리합니다. 설정 테스트를 통과한 후 중지된 서비스를 재시작하고, 가득 찬 디스크를 비우고, 만료된 인증서를 갱신하며, 먼저 백업을 만듭니다. 그것으로 부족하면 Deep Fix가 24시간 맡아 처리하며 15분 단위로 청구되고, 주문 전에 가격을 확인할 수 있습니다. 둘 다 Responder, root 권한의 SSH 또는 웹 공간에 대한 SSH 접근으로 작동합니다. 자세한 내용은 서버 다운 복구 및 긴급 서버 지원 페이지에서 확인하세요.