Помилка 500 на сайті: як знайти причину за 10 хвилин

Коротка відповідь

Не перевстановлюйте CMS і не відкочуйте бекап у першу хвилину. Спершу відкрийте Error log домену в DirectAdmin і прочитайте останні рядки. Далі - за тим, що там написано:

• Invalid command або .htaccess у рядку - зламаний .htaccess. Перейменуйте його і перевірте сайт.
• PHP Fatal error з шляхом до plugins, themes чи extension - винен конкретний плагін чи модуль. Вимкніть саме його.
• Call to undefined function - код не сумісний з версією PHP. Або оновіть модуль, або тимчасово перемкніть версію.
• Allowed memory size ... exhausted - скрипту не вистачило пам'яті, піднімайте memory_limit.
• Permission denied - права або власник файлів.

Якщо лог порожній, а 500 є - помилка не в PHP. Тоді дивіться на ліміти акаунта, базу даних і місце на диску, про це нижче окремий розділ.

Чому 500 не каже нічого, а лог каже все

На серверах Hosturm PHP працює з display_errors = Off. Так і має бути: текст помилки містить шляхи до файлів і назву бази, і показувати його відвідувачам - готова підказка для зломщика. Тому браузер отримує голе «500 Internal Server Error», а вся конкретика йде в лог.

Звідси головне правило: код 500 - це не діагноз, а лише сигнал «подивись у лог». Схожі коди виглядають для відвідувача так само страшно, але означають інше:

Крок 0. Дві хвилини на контекст

Перш ніж відкривати панель, дайте собі відповідь на три запитання. Вони звужують пошук сильніше, ніж будь-який інструмент:

1. Що змінювалось перед падінням? Оновлення плагіна, нова тема, правка .htaccess, зміна версії PHP, перенесення з іншого хостингу. У переважній більшості випадків 500 з'являється одразу після дії, а не на рівному місці.
2. Падає весь сайт чи одна сторінка? Якщо лише кошик, форма чи адмінка - шукайте модуль, що відповідає за цю сторінку. Якщо все, включно зі статичними файлами на кшталт /robots.txt, - майже напевно .htaccess.
3. Коли саме почалось? Час до хвилини - кожен рядок логу має мітку часу.

Крок 1. Відкрити лог помилок (хвилини 2-4)

Через DirectAdmin

Панель: Site Summary / Statistics / Logs → потрібний домен → Error Log. Відкриється поточний журнал Apache для цього домену, свіжі записи внизу. Хто відкриває панель уперше, орієнтуйтесь за інструкцією з перших кроків у DirectAdmin.

Через файловий менеджер або FTP

У домашній теці акаунта є domains/ваш-домен/logs/. Там архіви журналів за попередні дні - знадобляться, якщо помилка плаваюча. Деякі CMS ще й пишуть власний error_log прямо в public_html, його теж варто відкрити. Як підключитись до файлів, розписано в матеріалі FTP чи файловий менеджер.

Швидкий прийом: оновіть сторінку з помилкою, потім одразу лог - рядок, що з'явився щойно, і є вашою 500.

Як читати типові рядки:

Крок 2. Перевірити .htaccess (хвилини 4-5)

Найшвидша перевірка з усіх: у файловому менеджері перейменуйте public_html/.htaccess на .htaccess-off і оновіть сайт. Головна запрацювала, а внутрішні сторінки видають 404 - отже, винен саме цей файл. Повертайте назву і шукайте рядок, доданий останнім.

Одна причина трапляється на міграціях постійно. На старому хостингу PHP міг працювати як модуль Apache, і там у .htaccess спокійно жили рядки php_value memory_limit 256M чи php_flag display_errors off. У мене на серверах PHP працює через PHP-FPM, окремим пулом для кожного акаунта, і Apache таких директив не розуміє: один рядок php_value кладе весь сайт у 500. Лікування просте - видалити ці рядки з .htaccess, а ті ж налаштування перенести у файл .user.ini (про нього в кроці 5).

Друга класика - редирект по колу: правило «усе на HTTPS» дублюється в CMS чи Cloudflare, і Apache обриває запит на десятому переході.

Крок 3. Вимкнути плагін чи модуль (хвилини 5-7)

Якщо лог вказує на файл усередині plugins, themes, extension чи modules - винуватець знайдений, лишилось його вимкнути. В адмінку при цьому часто не зайти, бо вона теж падає, тому працюємо з файлами:

• WordPress. Перейменуйте теку конкретного плагіна, наприклад wp-content/plugins/назва → назва-off. WordPress сам його деактивує. Не знаєте, який саме, - перейменуйте всю теку plugins, зайдіть в адмінку, поверніть назву і вмикайте по одному. Для детального журналу додайте в wp-config.php рядки define('WP_DEBUG', true); і define('WP_DEBUG_LOG', true); - записи підуть у wp-content/debug.log, а не на екран. Після пошуку вимкніть.
• OpenCart. Після встановлення модуля через OCMOD помилка часто сидить у згенерованих файлах модифікацій. Очистіть теку storage/modification (або system/storage/modification у старіших версіях) і оновіть модифікації в адмінці. Не допомогло - вимкніть останній встановлений модуль.
• PrestaShop. Перейменуйте теку модуля в modules/ і очистіть var/cache.

Крок 4. Звірити версію PHP (хвилини 7-8)

За замовчуванням сайти в мене працюють на PHP 8.3, для старих проєктів доступна 7.4. Версія перемикається в панелі для кожного домену окремо, без звернення в підтримку.

Типова історія: тема або модуль написані років сім тому і використовують функції, яких у PHP 8 немає - each(), create_function(), фігурні дужки для доступу до символу рядка. На 7.4 такий код ще працює, на 8.3 падає з Call to undefined function.

Перемкнути на 7.4, щоб сайт ожив сьогодні, - нормальне рішення на кілька днів. Лишатися там надовго - ні: для PHP 7.4 перестали випускати навіть виправлення безпеки ще в листопаді 2022 року. Тож 7.4 - це час, щоб оновити модуль або знайти йому заміну, а не постійний стан.

Крок 5. Пам'ять і час виконання (хвилини 8-9)

Базові значення PHP на сервері: memory_limit = 128M і max_execution_time = 30 секунд на один запит. Звичайній сторінці цього досить. Упираються в ці межі імпорт прайсу на кілька тисяч товарів, генерація мініатюр, конструктори сторінок з десятками блоків і плагіни резервного копіювання.

Підняти межі можна самостійно: створіть у public_html файл .user.ini з рядками

memory_limit = 256M
max_execution_time = 120

Нюанс: PHP перечитує .user.ini приблизно раз на 5 хвилин, тож помилка після збереження може протриматись ще кілька хвилин - це не означає, що не спрацювало.

І чесна примітка про тариф. memory_limit - це межа для одного PHP-процесу, а не для всього сайту. На «Старті» акаунту доступно 2 GB RAM, і якщо поставити 512M, чотири паралельні запити з'їдять усе. Тому підіймайте рівно настільки, щоб зник рядок exhausted, а не «з запасом».

Крок 6. Права і власник файлів (хвилини 9-10)

Якщо в лозі Permission denied - PHP не може прочитати або записати файл. Норма для сайту на DirectAdmin: 644 для файлів, 755 для тек, власник - ваш користувач панелі. Ламається це зазвичай після розпакування архіву з іншого сервера або «підкрутки» прав на 777 за порадою з форуму. У файловому менеджері права змінюються правою кнопкою на файлі чи теці. Якщо ж проблема у власнику (файли належать не вашому користувачу), самостійно це не виправити - тут потрібен адміністратор сервера.

Коли лог мовчить: 500 не від коду

Буває, що свіжих записів у журналі немає, а помилка є. Тоді причина поза кодом сайту:

• Акаунт уперся в ліміт. PHP-процеси не встигають обслужити всі запити, і частина відвідувачів отримує 500 чи 503. Що перевірити і як відрізнити бота від реального росту, розібрано в статті «Перевищено ліміт ресурсів»: що це означає і що робити.
• Закінчилось місце. Коли диск заповнений, сесії й кеш не записуються, і CMS падає в найнесподіваніших місцях. На «Старті» це 10 GB NVMe, і їх найчастіше з'їдають логи та пошта, а не контент.
• База даних. Змінили пароль користувача бази, а в конфігу сайту лишився старий, - отримаєте «Error establishing a database connection» або 500. Звірте логін, пароль і назву бази в wp-config.php чи config.php з тим, що в панелі; процедура описана в матеріалі як створити базу і користувача в DirectAdmin.
• Сайт зламали. Незнайомі PHP-файли з випадковими назвами, змінений index.php, редирект на сторонні сайти - це вже не 500 як така, а її симптом. Тут порядок дій інший: сайт зламали - що робити.

Якщо щось не працює

1. Прочитали останні рядки Error log домену і знайшли запис із часом падіння.
2. Перейменували .htaccess і прибрали з нього php_value / php_flag.
3. Вимкнули плагін чи модуль, на який показує лог, очистили кеш CMS.
4. Звірили версію PHP з вимогами теми і модулів.
5. Підняли memory_limit через .user.ini і зачекали 5 хвилин.
6. Перевірили права 644/755 і наявність вільного місця.
7. Звірили доступ до бази в конфігу сайту.
8. Нічого не допомогло - відновили сайт із бекапу на момент до падіння. Щоденні копії зберігаються поза сервером, як ними користуватись - у статті про бекапи сайту.

Якщо пройшли список, а 500 лишилась, або в лозі рядок, який не вдається розшифрувати, - скиньте його в підтримку в Telegram разом з адресою сторінки і часом помилки. Я бачу серверні журнали, до яких у панелі доступу немає, і часто можу назвати причину без довгого листування.

Підсумок

Помилка 500 лякає тим, що нічого не пояснює, але лікується вона майже завжди швидко, бо сервер пам'ятає причину. Правильний порядок - лог, .htaccess, плагін, версія PHP, пам'ять, права - і на кожен крок вистачає хвилини-двох. Бекап - останній засіб, а не перший: відкат без розуміння причини часто повертає ту саму помилку після наступного оновлення.

Якщо ж 500 з'являються регулярно без жодних правок з вашого боку, варто подивитись на сам хостинг: чи є доступ до логів у панелі, яка версія PHP, скільки ядер і пам'яті реально виділено. У мене це прописано прямо в кожному плані - від 1 ядра і 2 GB RAM на «Старті» (142 грн/міс при оплаті за рік, 479 грн помісячно) до 4 ядер і 8 GB на «Pro». Порівняння всіх планів - у блоці тарифів, умови і відповіді на часті питання - на сторінці хостингу.