База знаний и IT-инструменты DIEG

Что делать, если упал сервер или сайт недоступен: пошаговая диагностика

Если сайт недоступен, а веб-сервер не отвечает на запросы, главное — быстро определить причину сбоя до того, как пострадает бизнес или просядут позиции в поисковиках.

Реальные причины падения сервера, сайта

1. Переполнение дискового пространства или лимита Inodes (No space left on device)

Самая частая причина скрытых сбоев. Переполнение диска — коварная проблема: она редко заявляет о себе напрямую, а провоцирует каскад “фантомных” ошибок во всей системе:

• Базы данных (MySQL / PostgreSQL): Сбои авторизации, аварийная остановка служб mysqld / postgres из-за невозможности записать WAL-логи, транзакции или временные таблицы.
• Веб-сервер (Nginx / PHP-FPM): Ошибки 500 Internal Server Error, 502 Bad Gateway, отказ записи PHP-сессий, пустые страницы и сбои кэширования.
• Inodes: Переполнение лимита индексных дескрипторов (миллионы мелких файлов сессий, кэша или логов) при формальном наличии свободного места на диске. Часто забывают про Inodes. Диск может быть свободен, но лимит на количество файлов исчерпан (например, из-за миллионов мелких файлов сессий PHP).

Диагностика:

# Проверка свободного места на дисках
df -h
# Проверка использования Inodes
df -iT
# Сколько inode какие папки занимают в папке с сайтами (/var/www/)
ls -d1 /var/www/* | while read i; do echo -en "$i\t"; find "$i" -name "*" | wc -l; done;
# или через du котрый спецаильно предназначен для поиска каталогов, расходующих inode
du --inodes -x --max-depth=1 /var/www/ | sort -n

2. Пришел OOM Killer (Out of Memory, Killed)

Нехватка оперативной памяти — классика жанра. Ядро Linux начинает убивать процессы, чтобы спасти систему. Также OOM возможен при достижении лимита памяти группы процессов — даже если на сервере ещё есть доступная память. Это предусмотрено механизмом cgroups. Для диагностики лучше искать несколько характерных сообщений:

# Сообщения ядра за последние сутки на системе с systemd
sudo journalctl -k --since "24 hours ago" --no-pager |
  grep -Ei 'out of memory|oom-kill|killed process'

# Альтернатива: текущий кольцевой буфер ядра
sudo dmesg -T | grep -Ei 'out of memory|oom-kill|killed process'

# Текущее состояние RAM и swap
free -h

3. Просроченный SSL-сертификат (Certificate expired, Certificate verify failed)

Сайт работает, но при попытке открыть его браузер выводит предупреждение безопасности, а скрипты отваливаются с ошибками ssl error certificate verify failed или error certificate has expired. Основные причины:

• Не сработал Cron-задача автообновления Certbot / Let’s Encrypt.
• Неполная цепочка промежуточных сертификатов (CA Bundle).
• В панели (например, FastPanel) имя VPS совпадает с доменов сайта, и в /etc/hosts домен зациклен на 127.0.0.1.

Для сертификатов, которыми уже управляет Certbot, полезна проверка процедуры продления, SSL-сертификатов без применения изменений:

sudo certbot renew --dry-run

4. Неправильная AAAA-запись: сайт недоступен через IPv6

Основные причины приводящие к ошибкам:

• AAAA-запись указывает на неправильный или старый IPv6.
• Адрес правильный, но не настроен на сервере.
• Веб-сервер не принимает подключения по IPv6 на портах 80/443.
• Firewall разрешает IPv4, но блокирует IPv6.

Проверка — замени example.com своим доменом:

# Какой IPv6 опубликован в DNS
dig +short AAAA example.com

# Проверка сайта через IPv4
curl -4 -I --connect-timeout 10 https://example.com/

# Проверка сайта через IPv6
curl -6 -I --connect-timeout 10 https://example.com/

Примечание: Тестировать IPv6 необходимо с устройства или VPS, у которого настроено рабочее IPv6-подключение.