Помилки 500, 502, 504: як швидко відновити роботу сайту та усунути причини

Помилки 5xx на сайті зазвичай виникають через нездатність сервера обробити запит, некоректну взаємодію проміжних ланок або перевищення часу очікування. Помилка 500 — це загальна внутрішня помилка програми чи конфігурації сервера; 502 свідчить, що проксі-шлюз отримав недійсну відповідь від серверної частини; а 504 вказує на те, що відповідь від серверної частини не надійшла вчасно. Для остаточного вирішення проблеми необхідно правильно визначити код помилки, проаналізувати серверні логи, виміряти споживання ресурсів, налагодити PHP/програмний код, усунути вузькі місця в базі даних та масштабувати хостингову інфраструктуру відповідно до потреб трафіку.

Для відвідувача ці помилки означають лише порожню сторінку або недоступний сайт; для бізнесу ж — це втрачені продажі, зниження довіри та погіршення SEO-сигналів. Особливо для проєктів, які не толерують простоїв, як-от інтернет-магазини, корпоративні сайти, новинні портали чи системи бронювання, помилки 5xx можуть обернутися фінансовими втратами за лічені хвилини. У цьому посібнику ми покроково розглянемо, як розрізняти помилки 500, 502 і 504, швидко проводити діагностику та вживати дієвих заходів, щоб вони не повторювалися.

Чому не можна ігнорувати помилки сервера на сайті

Падіння сайту — це не просто технічний збій. Це прямий вплив на користувацький досвід, коефіцієнт конверсії, сприйняття бренду та видимість у пошукових системах. Google зазвичай лояльно ставиться до короткочасних перебоїв; однак регулярні помилки 5xx призводять до марнотратства краулінгового бюджету, рідшого сканування важливих сторінок та коливань у видачі.

На практиці помилки 5xx слід розглядати на двох рівнях. Перший — екстрене втручання: повернути сайту доступність. Другий — аналіз першопричини: з'ясувати, чому помилка повторюється під час пікового трафіку, виконання cron-завдань, після оновлення плагінів або зі зростанням навантаження на базу даних. Просте перезавантаження сервісу іноді дає тимчасове полегшення, але якщо не усунути корінь проблеми, помилка може повернутися за кілька годин.

Наприклад, якщо під час рекламної кампанії в магазині на WooCommerce використання CPU сягає 95%, черга PHP-FPM переповнюється, а база даних блокується через повільні запити, відвідувачі можуть побачити помилку 500 або 504. У такому разі самого лише встановлення плагіна кешування може бути недостатньо; потрібна комплексна оцінка оптимізації запитів, потужнішого тарифного плану хостингу, CDN, об'єктного кешу та лімітів ресурсів. Аналізуючи варіанти розміщення для проєктів, що зростають, варто порівняти Hostragons пакети веб-хостингу та, для потреб у більших ресурсах, Hostragons Серверні рішення VPS.

Ключові відмінності між помилками 500, 502 і 504

Хоча 500, 502 і 504 належать до однієї родини 5xx, вони означають різні речі. Неправильна діагностика веде до неправильного втручання. Таблиця нижче швидко підсумовує найпоширеніші відмінності.

Це розмежування особливо важливе в архітектурах з використанням Nginx, Apache, LiteSpeed, PHP-FPM, Node.js, зворотного проксі, CDN та балансувальника навантаження. Коли користувач бачить у браузері 502, справжньою проблемою може бути падіння сервісу PHP-FPM. Так само помилка 504 може бути спричинена не веб-сервером, а зовнішнім платіжним API, який відповідає довше 30 секунд.

500 Internal Server Error: причини та кроки до вирішення

Що означає помилка 500?

500 Internal Server Error вказує, що сервер не зміг обробити запит, але не може пояснити помилку більш конкретним кодом. Через це помилка 500 має широкий спектр можливих причин. Вона може виникати з різних причин у WordPress, Laravel, самописному PHP-коді, проєктах на Python або Node.js. Оскільки повідомлення про помилку дає користувачеві обмежену інформацію, основні підказки слід шукати у файлах логів.

Найпоширеніші причини помилки 500

• Некоректні правила .htaccess: Помилковий RewriteRule, нескінченне перенаправлення або непідтримувані директиви можуть спричинити помилку 500.
• Фатальна помилка PHP: Відсутня функція, несумісна версія PHP, перевищення ліміту пам'яті або несправна тема/плагін можуть зупинити сайт.
• Права доступу до файлів і папок: Робота PHP-файлів з небезпечними або неправильними правами, як-от 777, може блокуватися сервером.
• Відсутні залежності: Можуть бути відсутні пакети Composer, модулі PHP або файли кешу фреймворку.
• Ліміти ресурсів сервера: Перевищення лімітів CPU, RAM, entry process або I/O може призвести до переривання запиту.

Як виправити помилку 500?

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

• 1. Перевірте логи: У cPanel, Plesk або панелі керування сервером перегляньте файл error_log. Рядки на кшталт Fatal error, memory exhausted, permission denied або syntax error прямо вказують на джерело проблеми.
• 2. Скасуйте останню зміну: Вимкніть щойно встановлений плагін, тему або фрагмент коду. Для WordPress тимчасове перейменування папки плагінів дозволяє швидко протестувати це.
• 3. Протестуйте файл .htaccess: Тимчасово збережіть файл під іншим ім'ям та згенеруйте стандартні правила. Якщо помилка зникла, проблема в правилах перенаправлення або rewrite.
• 4. Перевірте версію та ліміти PHP: Якщо ваша програма несумісна з PHP 8.2, це може викликати помилку 500. Збалансуйте значення memory_limit, max_execution_time та post_max_size відповідно до потреб проєкту.
• 5. Виправте права доступу до файлів: Загальна практика — використовувати права 755 для папок та 644 для файлів. Для особливих потреб дотримуйтесь інструкцій вашого хостинг-провайдера.
• 6. Заплануйте відновлення з бекапу: Якщо робочий сайт повністю недоступний, повернення до останньої працездатної резервної копії може відновити сервіс до проведення аналізу першопричин. У цей момент регулярне резервне копіювання набуває критичної важливості.

Якщо помилка 500 часто повторюється, зосереджуватися лише на рівні програми недостатньо. Необхідно проаналізувати метрики: скільки PHP-процесів одночасно працює на сервері, яке середнє споживання пам'яті, скільки з'єднань з базою даних, чи є затримка дискового I/O. Особливо в середовищах віртуального хостингу ліміти ресурсів можуть не встигати за темпами зростання сайту. У таких випадках варто розглянути Hostragons WordPress хостинг або пакети, що пропонують більш ізольовані ресурси.

502 Bad Gateway: розуміння помилок проксі та серверної частини

Що означає помилка 502?

502 Bad Gateway вказує, що шлюз або проксі-шар між клієнтом і серверним сервісом не отримав дійсної відповіді. У сучасних хостингових архітектурах Nginx часто працює як зворотний проксі, спрямовуючи PHP-запити до PHP-FPM, а Node.js-запити — до порту програми або іншого серверного сервісу. Якщо один із сервісів у цьому ланцюжку вимкнено, перевантажено або налаштовано на неправильний порт, може виникнути помилка 502.

Типові причини помилки 502

• Зупинка сервісу PHP-FPM або неможливість доступу до файлу сокета.
• Програма Node.js, Python або Java не працює на потрібному порту.
• Використання неправильної IP-адреси, порту або шляху до сокета у визначенні upstream в Nginx.
• CDN або брандмауер не отримує очікуваної відповіді від сервера-джерела.
• Переповнення оперативної пам'яті сервера та завершення процесів, що призводить до падіння серверних сервісів.

План дій для усунення помилки 502

При помилці 502 перша мета — знайти, яка ланка в ланцюжку не відповідає. Наступна послідовність є одним із найшвидших підходів у реальних процесах підтримки:

• Перевірте стан сервісів: Переконайтеся, що PHP-FPM, веб-сервер, база даних та сервіси програми працюють. На VPS або виділеному сервері можна виконати перевірку командами systemctl status.
• Порівняйте логи upstream: Проаналізуйте лог помилок Nginx та логи PHP-FPM або програми за одним часовим штампом. Вирази connection refused, upstream prematurely closed connection або no live upstreams є критичними підказками.
• Перевірте використання ресурсів: Якщо RAM заповнена понад 90% і активно використовується swap, сервіси можуть не відповідати. Значення CPU load, що значно перевищує кількість ядер, також створює чергу.
• Перевірте налаштування сокета та порту: Якщо конфігурація Nginx спрямована на адресу 127.0.0.1:9000, а PHP-FPM слухає інший сокет, помилка 502 неминуча.
• Протестуйте рівень CDN: Тимчасово обійдіть CDN і зверніться безпосередньо до сервера-джерела. Якщо проблема виникає лише через CDN, слід перевірити налаштування DNS, SSL або підключення до джерела.

Іноді на помилку 502 також впливає конфігурація SSL. Якщо між CDN та джерелом використовується HTTPS, але сертифікат джерела прострочений або належить неправильному домену, можуть виникати помилки шлюзу. Для безпечного та правильного налаштування рівня SSL можна ознайомитися з опціями на сторінці Hostragons SSL сертифікати та посібник з встановлення сертифіката SSL.

504 Gateway Timeout: остаточне вирішення проблем із тайм-аутом

Що означає помилка 504?

504 Gateway Timeout вказує, що проксі або шлюз не отримав відповіді від серверного сервісу протягом визначеного часу. При цьому сервіс не обов'язково повністю вимкнений; він може просто відповідати надто повільно. Тому помилка 504 здебільшого вказує на проблеми з продуктивністю, базою даних, зовнішніми API або тривалими процесами.

Поширені причини помилки 504

• Повільні запити до бази даних: Відсутність індексів, сканування великих таблиць або блокування збільшують час відповіді.
• Затримки зовнішніх API: Коли платіжні, логістичні, CRM або складські сервіси відповідають повільно, веб-запит може залишатися в режимі очікування.
• Мережева затримка: Якщо програма та база даних знаходяться в різних локаціях, затримка стає критичною.
• Тривалі cron-завдання або імпорт: Імпорт CSV, масова розсилка електронних листів або формування звітів можуть сповільнювати обробку активних запитів.
• Недостатні налаштування тайм-ауту: Значення тайм-аутів Nginx, Apache, PHP-FPM та програми можуть бути неузгодженими між собою.

Як усунути помилку 504?

При помилці 504 просте збільшення значень тайм-ауту часто лише приховує симптом. Наприклад, надання 120 секунд замість 30 для запиту, що не завершується, може зменшити кількість помилок, але не покращить користувацький досвід. Правильний підхід — виміряти та прискорити вузьке місце.

• 1. Розкладіть час відповіді: Окремо виміряйте час виконання програми, час бази даних, час зовнішнього API та час очікування сервера.
• 2. Увімкніть журнал повільних запитів: У MySQL або MariaDB реєструйте запити, що тривають довше 1 секунди. Додайте індекси до частих повільних запитів або змініть структуру запиту.
• 3. Перенесіть важкі процеси у фон: Такі завдання, як генерація звітів, обробка зображень, відправка листів та синхронізація залишків, повинні виконуватися у фоновому режимі через систему черг.
• 4. Використовуйте кешування: Кешування сторінок, об'єктне кешування та OPcache значно зменшують обчислювальне навантаження в динамічних програмах.
• 5. Узгодьте значення тайм-аутів: Значення proxy_read_timeout, fastcgi_read_timeout, max_execution_time та тайм-ауту програми не повинні суперечити одне одному.
• 6. Встановіть обмеження для зовнішніх API: Не змушуйте запит користувача чекати нескінченно, якщо API не відповідає. Використовуйте стратегії повторних спроб (retry), резервного варіанту (fallback) та короткого тайм-ауту.

У реальному сценарії, якщо сторінка зі списком товарів фільтрує 60 тисяч позицій, а в полі категорії відсутній індекс, під час трафіку рекламної кампанії кількість помилок 504 може зрости. Додавання індексу, кешування результатів фільтрації та оптимізація важких запитів можуть вирішити проблему навіть без збільшення ресурсів. Однак, якщо зростання трафіку є постійним, може знадобитися масштабування ресурсів.

Чек-лист із 10 кроків для швидкої діагностики

Коли сайт раптово падає, хаотичне втручання призводить до втрати часу. Наведений нижче чек-лист можна використовувати для системного підходу до помилок 500, 502 і 504:

• 1. Перевірте, чи помилка у всіх, чи тільки у вас: Протестуйте з різних мереж, мобільного зв'язку та за допомогою зовнішніх інструментів моніторингу доступності.
• 2. Перевірте код стану HTTP: Використовуйте інструменти розробника в браузері або команду на кшталт curl -I https://vashdomen.com, щоб побачити реальний код.
• 3. Складіть список останніх змін: Чи було розгортання коду, оновлення плагінів, зміна DNS, оновлення SSL, зміна версії PHP або налаштувань сервера?
• 4. Перегляньте логи веб-сервера: Записи помилок Apache, Nginx або LiteSpeed — це перше джерело для аналізу.
• 5. Проаналізуйте логи програми: Журнал налагодження WordPress, логи сховища Laravel або логи процесу Node.js покажуть джерело помилки.
• 6. Виміряйте ресурси сервера: Слід одночасно оцінити CPU, RAM, дисковий простір, inode, дисковий I/O та кількість з'єднань.
• 7. Перевірте базу даних: Чи вичерпано ліміт з'єднань, чи є заблоковані запити, чи зросла кількість повільних запитів?
• 8. Протестуйте брандмауер та CDN: Правила WAF, фільтри ботів або з'єднання CDN з джерелом можуть працювати некоректно.
• 9. Тримайте бекап напоготові: Якщо критичний файл пошкоджено або оновлення виконано з помилкою, у вас має бути план швидкого відновлення.
• 10. Створіть звіт про першопричину: Після усунення помилки задокументуйте час, вплив, причину, рішення та кроки для запобігання повторенню.

Цей список особливо цінний для розподілу відповідальності в команді. Коли ви звертаєтесь до служби підтримки хостингу, надання часу виникнення помилки, прикладу URL, коду помилки, останніх змін та, за можливості, скріншоту значно скорочує час вирішення. Для проблем із доступом, пов'язаних із доменом, DNS та перенаправленнями, такі ресурси, як Hostragons перевірка домену та реєстрація та Посібник з управління DNS, також сприятимуть процесу діагностики.

Як правильно аналізувати ресурси сервера

Значна частина помилок 5xx пов'язана з нестачею ресурсів. Однак високе завантаження CPU не завжди означає поганий код; іноді систему може перевантажувати неочікувано високий органічний трафік, бот-атака, некоректне cron-завдання або процес резервного копіювання. Тому метрики слід розглядати не ізольовано, а в часовій динаміці.

Основні метрики для моніторингу

• Використання CPU: Постійне завантаження понад 80% збільшує ризик черг і затримок.
• RAM та swap: Якщо використання swap зростає, процеси сповільнюються, що може спровокувати помилки 502 і 504.
• Дисковий I/O: Особливо інтенсивне записування логів, великі бекапи або операції з базою даних можуть спричинити очікування I/O.
• Entry process та concurrent connection: На віртуальному хостингу ліміти одночасних процесів можуть призвести до помилки 500.
• З'єднання з базою даних: Наближення до ліміту max_connections збільшує кількість помилок програми.
• TTFB: Регулярне збільшення часу до отримання першого байта є раннім попередженням перед появою помилки 504.

Ви можете використовувати простий підхід на основі порогових значень: якщо у звичайний час TTFB становить 300-600 мс, а під час кампанії зростає до 5-10 секунд, слід планувати потужності ще до появи помилки. Спільне використання моніторингу доступності, аналізу логів та вимірювання продуктивності дозволяє виявити проблему до її загострення.

Довгострокові заходи на рівні програми, бази даних та хостингу

Що робити на рівні програми

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

• Не показуйте інформацію для налагодження користувачам на робочому сайті, записуйте її у файл логу.
• Робіть повний бекап файлів та бази даних перед оновленням.
• Відокремлюйте тривалі процеси від запитів користувачів.
• Оптимізуйте зображення та зменшуйте навантаження від зайвих скриптів.
• Аналізуйте бот-трафік; обмежуйте шкідливих або надмірних ботів за допомогою WAF.

Що робити на рівні бази даних

Продуктивність бази даних відіграє критичну роль, особливо в WordPress, WooCommerce, на форумах та в системах членства. На сайтах із тисячами товарів, замовлень, коментарів або записів логів розростання таблиць може збільшити кількість повільних запитів. Регулярне обслуговування, перевірка індексів та очищення непотрібних записів знижують ризик помилки 504.

• Знаходьте найважчі запити за допомогою журналу повільних запитів.
• Додавайте правильні індекси до стовпців, за якими часто фільтрують.
• Очищайте непотрібні параметри, що завантажуються автоматично.
• Періодично архівуйте старі ревізії, тимчасові записи та таблиці логів.
• Запускайте резервне копіювання бази даних у години низької продуктивності.

Що робити на рівні хостингу

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

• Для малих і середніх сайтів може бути достатньо простих в управлінні тарифів хостингу.
• Сайти з інтенсивними динамічними процесами краще працюють на VPS з ізольованими CPU/RAM.
• Для корпоративних проєктів регулярне резервне копіювання, SSL, WAF та моніторинг доступності мають бути стандартом.
• DNS-записи слід підтримувати в чистоті, прибираючи зайві ланцюжки перенаправлень.
• Якщо використовується CDN, необхідно правильно налаштувати сервер-джерело, SSL та правила кешування.

Оцінюючи це, орієнтуватися лише на дисковий простір оманливо. Сайт, що використовує 2 ГБ диска, може споживати більше CPU через високу кількість одночасних користувачів, ніж інший сайт, що використовує 20 ГБ диска. Тому вибір тарифу слід робити на основі реального трафіку та обчислювального навантаження.

Що робити з помилками 5xx з точки зору SEO?

Пошукові системи не карають миттєво за тимчасові помилки 5xx, але регулярні перебої впливають на ефективність сканування та індексації. Якщо Googlebot часто отримує відповідь 500, 502 або 504 на важливих сторінках, він може знизити частоту їх сканування. Крім того, якщо користувачі переходять із органічної видачі та бачать помилку, це призводить до втрати довіри та конверсії.

Щоб зменшити SEO-ризики, використовуйте моніторинг доступності для критичних сторінок, перевіряйте статистику сканування в Search Console, аналізуйте коди стану запитів Googlebot у серверних логах. Якщо планується технічне обслуговування, використання коректно налаштованої відповіді 503 Service Unavailable на короткий час є кращим, ніж незапланована помилка 500. Використання заголовка Retry-After на сторінці обслуговування підкаже пошуковим системам, коли спробувати знову.

Особливо під час перенесення сайту, зміни домену або переходу на SSL неправильні перенаправлення та проблеми з сертифікатами можуть спричинити проблеми з доступом, схожі на 5xx. Стандартною хорошою практикою є зниження TTL DNS перед перенесенням, створення бекапу, перевірка на тестовому домені та моніторинг логів після переходу.

Коли слід звертатися до служби підтримки хостингу?

Деякі помилки адміністратор сайту може вирішити самостійно, тоді як інші потребують доступу до сервера та спеціальних знань. У наступних випадках варто негайно звернутися до підтримки хостингу:

• Помилка впливає на весь сайт, і доступ до панелі керування також відсутній.
• У логах видно рядки permission denied, upstream failed або resource limit exceeded.
• Сервіс PHP-FPM, веб-сервер або база даних постійно падають.
• При вимкненому CDN сайт відкривається, а при увімкненому — видає 502 або 504.
• Ліміти ресурсів постійно вичерпуються, і незрозуміло, який тарифний план підійде.
• Доступ порушився після зміни SSL, DNS або брандмауера.

Створюючи запит до підтримки, додавання наступної інформації значно скорочує час вирішення: час початку помилки, URL-адреси, яких вона торкнулася, код помилки, останні зроблені зміни, скріншот, за можливості — рядки логів, а також інформація про те, чи є помилка постійною, чи виникає періодично. Ці дані допомагають технічній команді відтворити ту саму проблему та проаналізувати правильний рівень системи.

Часті питання

Чи означає помилка 500, що мій сайт зламали?

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

Чи може помилка 502 Bad Gateway виникати з вини користувача?

Зазвичай ні. Помилка 502 найчастіше вказує на проблему зв'язку на рівні сервера, проксі, CDN або серверного сервісу. Користувач може очистити кеш браузера та протестувати з іншої мережі, але якщо помилку бачать усі, рішення слід шукати на стороні сервера.

Чи достатньо збільшити значення тайм-ауту для помилки 504 Gateway Timeout?

Іноді це дає тимчасове полегшення, але не є остаточним рішенням. Головна мета при помилці 504 — знайти першопричину, таку як повільний запит, затримка зовнішнього API, інтенсивне використання CPU або тривалий процес. Збільшення тайм-ауту слід обережно застосовувати разом з оптимізацією продуктивності.

Чи відразу помилки 5xx знижують мої позиції в SEO?

Короткочасні та рідкісні перебої зазвичай не призводять до постійної втрати позицій. Однак, якщо помилки 5xx часто повторюються, важливі сторінки залишаються недоступними тривалий час або Googlebot регулярно отримує помилку сервера, це може негативно вплинути на частоту сканування та органічну ефективність.

Яка найважливіша звичка для запобігання проблемам із падінням сайту?

Найважливіша звичка — це регулярний моніторинг та управління змінами. Коли відстеження доступності, резервне копіювання, перевірка логів, тестування в staging-середовищі, використання актуального програмного забезпечення та моніторинг метрик ресурсів застосовуються разом, більшість помилок 500, 502 і 504 можна запобігти ще до їх загострення.

Короткий підсумок і наступний крок

Хоча помилки 500, 502 і 504 належать до однієї родини, вони вказують на різні рівні: 500 — це переважно помилка програми або конфігурації, 502 — проблема зв'язку проксі з серверною частиною, а 504 — тайм-аут і вузьке місце продуктивності. Правильне рішення полягає в тому, щоб верифікувати код помилки, прочитати логи, виміряти ресурси, проаналізувати останні зміни та виконати довгострокову оптимізацію.

Якщо на вашому сайті часто виникають проблеми з падінням, корисно буде комплексно оцінити ваші поточні ресурси хостингу, конфігурацію SSL і DNS, а також продуктивність програми. Щоб ознайомитися з відповідною інфраструктурою для розміщення або обговорити варіанти з технічною командою, ви можете переглянути рішення Hostragons; мета — створити швидший, безпечніший та стійкий до перебоїв веб-досвід.