Помилка 500 на хостингу: як перестати панікувати і знайти причину за 15 хвилин
Уявіть: п'ятниця, 18:00, ви нарешті збираєтесь закрити ноутбук - і тут клієнт скидає скріншот. Білий екран, лаконічний напис "500 Internal Server Error". Серце падає кудись у район шлунка. Телефон починає вібрувати. Ще один клієнт. Ще один скріншот. Знайомо? Помилка 500 - це як лихоманка у людини: вона сигналізує, що щось не так, але не каже, що саме. І поки ви не поставите діагноз, лікування буде навмання. Давайте розберемося, як системно шукати корінь проблеми, а не тикати пальцем у небо.
Чому 500-та помилка така підступна
Більшість HTTP-помилок досить красномовні. 404 - сторінки немає. 403 - доступ заборонено. 502 - шлюз не відповідає. А ось 500 Internal Server Error - це, по суті, сервер каже: "Мені погано, але я не скажу чому". Ні конкретної причини, ні підказки. Просто біль.
Причин може бути десятки:
- Зламаний .htaccess після невдалого редагування або оновлення плагіна
- Перевищення лімітів пам'яті PHP на shared-хостингу
- Синтаксична помилка у коді після "швидкого фіксу" о третій ночі
- Несумісність версій PHP з якимось старим плагіном чи темою
- Проблеми з правами доступу до файлів або директорій
І найгірше - помилка може з'являтися спорадично. Вранці все працює, ввечері - лежить. Ви перезавантажуєте сервер, сайт оживає на годину, а потім знову падає. Це не магія. Це просто симптом, який потрібно правильно прочитати.
Перші 5 хвилин: що робити, коли все горить
Не чіпайте код. Серйозно. Я бачив, як люди у паніці починають видаляти файли, відкочувати бекапи, перевстановлювати CMS - і перетворюють одну проблему на п'ять. Ось чіткий алгоритм перших дій:
- Відкрийте логи помилок - у cPanel це Error Log, у Plesk - Logs. Через SSH: tail -f /var/log/apache2/error.log або аналогічний шлях для nginx. Лог - це ваша головна зброя.
- Перевірте, чи помилка на всіх сторінках - якщо тільки на одній, проблема локалізована: конкретний скрипт, шаблон або запит до бази.
- Подивіться, що змінилось - оновлення плагіна? Редагування файлу? Зміна версії PHP у панелі? 90% випадків помилка 500 виникає після того, як хтось щось "трошки поправив".
- Перейменуйте .htaccess - просто додайте до імені _backup. Якщо сайт ожив - ви знайшли винуватця за 30 секунд.
- Перевірте використання ресурсів - у панелі хостингу подивіться на CPU, RAM, кількість процесів. Можливо, ви просто вперлися у ліміт.
Правило номер один: спочатку дивимось у логи, потім робимо будь-що інше. Без логів ви - хірург із зав'язаними очима.
Головні винуватці: розбираємо топ-причини з прикладами
За 15 років роботи з хостингом я бачив сотні випадків помилки 500. І знаєте що? Приблизно 80% з них вкладаються у п'ять категорій. Ось вони з реальними прикладами та рішеннями:
| Причина | Як виглядає в логах | Рішення | Час на фікс |
|---|---|---|---|
| Битий .htaccess | Invalid command або Syntax error | Перейменувати файл, створити чистий | 1-2 хв |
| Ліміт пам'яті PHP | Allowed memory size exhausted | Збільшити memory_limit у php.ini або ini_set | 3-5 хв |
| Помилка у коді | Parse error або Fatal error з вказівкою рядка | Виправити синтаксис або відкотити зміни | 5-15 хв |
| Права доступу | Permission denied | chmod 644 для файлів, 755 для директорій | 2-5 хв |
| Несумісність PHP | Uncaught Error або Deprecated function | Змінити версію PHP або оновити код | 10-30 хв |
Один мій колега три дні шукав причину 500-ї помилки на WordPress-сайті клієнта. Виявилося, що безкоштовний плагін для SEO додав у .htaccess рядок з директивою, яку Apache на цьому хостингу просто не розумів. Три дні. А потрібно було лише заглянути у error.log.
Коли проблема не у вас, а у хостингу
Ось про що рідко говорять у туторіалах: іноді помилка 500 - це не ваша вина. Взагалі. Сервер провайдера може бути перевантажений. Модуль Apache може "впасти". Оновлення на рівні ОС сервера може зламати сумісність.
"Shared hosting - це комунальна квартира. Ваш сусід запустив криво написаний крон, і тепер увесь сервер ледве дихає. А ви думаєте, що проблема у вашому коді." - Дмитро Котенко, DevOps-інженер з 12-річним досвідом
Як зрозуміти, що проблема на стороні хостера?
- Помилка з'являється і зникає хаотично, без жодних змін з вашого боку
- Логи або порожні, або показують лише загальний "Premature end of script headers"
- Інші сайти на цьому ж акаунті теж лежать
- Статус-сторінка провайдера показує інциденти
У такому разі - пишіть у підтримку. Але не просто "у мене 500", а з конкретикою: час виникнення, URL, витяг з логів, що ви вже перевірили. Тікети з такою інформацією вирішуються в 3-4 рази швидше. Перевірено на власному досвіді.
Профілактика: як не зустрічатися з 500-ю помилкою щомісяця
Знаєте різницю між адміністратором-новачком та досвідченим? Новачок гасить пожежі. Досвідчений робить так, щоб вони не виникали. Ось що реально працює:
- Увімкніть логування помилок PHP - у wp-config.php або php.ini. Завжди. Навіть на продакшені. Без логів ви сліпі.
- Тестуйте оновлення на staging - особливо великі: WordPress, WooCommerce, мажорні плагіни. Оновлення на бойовому сервері без тестування - це російська рулетка.
- Моніторте аптайм - сервіси на кшталт UptimeRobot (безкоштовний) або Better Uptime перевіряють сайт кожні 5 хвилин. Ви дізнаєтесь про проблему раніше за клієнтів.
- Тримайте бекап .htaccess та wp-config.php окремо - ці два файли ламаються найчастіше. Мати їхню чисту копію - це як тримати запасний ключ від квартири у сусіда.
- Не ставте 20 плагінів "на всяк випадок" - кожен плагін - це потенційна точка відмови. Менше коду - менше шансів на помилку.
Правильно налаштований моніторинг + staging-середовище скорочують кількість інцидентів з помилкою 500 на 70-80%. Це не магічні цифри - це статистика з реальних проєктів, де я допомагав налаштовувати інфраструктуру.
Коли 500-та помилка - це симптом чогось більшого
Іноді помилка 500, що постійно повертається - це не баг, а знак. Знак того, що ваш проєкт переріс свій хостинг. Якщо ви щомісяця стикаєтесь з лімітами пам'яті, якщо кожне оновлення WooCommerce кладе сервер, якщо ваш shared-тариф за $3 обслуговує магазин з 10 000 товарів - проблема не в .htaccess. Проблема в архітектурі.
Переїзд на VPS або хмарний хостинг не вирішить кривий код. Але він дасть вам головне - контроль. Доступ до повних логів, можливість налаштувати PHP під свої потреби, виділені ресурси замість "скільки залишилось від сусідів". І якщо помилка 500 виникне знову - ви знайдете її за хвилини, а не за дні.
Запитайте себе чесно: ви лагодите симптоми чи вирішуєте проблему? Бо сервер, як і організм - довго терпить, а потім падає одразу і серйозно. І зазвичай це відбувається в п'ятницю о 18:00.