База знань та 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 необхідно з комп’ютера або сервера з робочим IPv6-підключенням.