Помилка 504 Gateway Timeout означає, що один сервер не дочекався своєчасної відповіді від іншого. Для відвідувача це зазвичай виглядає як порожня сторінка або повідомлення про перевищення часу очікування. Найчастіше проблема виникає не через сам браузер користувача, а на рівні хостингу, вебсервера, PHP, бази даних або зовнішнього сервісу.
Важливо відрізняти 504 від повного падіння сайту. Сервер може бути доступним, але окремий запит виконується надто довго. Через це головна сторінка, адміністративна панель WordPress, оформлення замовлення або конкретний API-запит можуть не відкриватися, тоді як інші частини сайту працюють.
Що означає тайм-аут сервера
Під час відкриття сторінки запит проходить кілька етапів: браузер звертається до вебсервера, той передає завдання PHP або іншому застосунку, застосунок звертається до бази даних і формує відповідь. Якщо один із компонентів не відповідає в межах встановленого часу, проміжний сервер повертає помилку 504.
Типові симптоми:
- сайт періодично відкривається, а потім знову видає 504;
- помилка з’являється лише на важких сторінках або під час пошуку;
- адмінпанель WordPress не завантажується;
- оформлення замовлення або імпорт товарів зависає;
- після оновлення плагіна чи теми сайт почав відповідати значно повільніше.
Спочатку варто перевірити, чи проблема відтворюється з різних пристроїв і мереж. Якщо 504 бачать усі користувачі, а не лише один комп’ютер, причину потрібно шукати на сервері або в коді сайту. Не слід багаторазово натискати кнопку надсилання форми чи оплати: запит міг виконатися на сервері, навіть якщо сторінка не встигла показати результат.
Повільні запити та плагіни
У WordPress помилку 504 часто спричиняє операція, яка виконує надто багато роботи за один запит. Це може бути імпорт великого каталогу, генерація звіту, пошук по значній кількості записів, очищення кешу або створення мініатюр для сотень зображень.
Окрему увагу слід приділити плагінам, які:
- підключають складні фільтри та пошук;
- синхронізують товари, замовлення або залишки з іншою системою;
- виконують резервне копіювання на сервері;
- збирають статистику та журнали відвідувань;
- додають захист, сканування або перевірку кожного запиту.
Безпечна перевірка передбачає перегляд часу появи помилки в журналах сервера та WordPress, аналіз навантаження, а також порівняння роботи сайту після тимчасового вимкнення підозрілого компонента. Перед деактивацією плагінів, зміною коду або масовим видаленням даних потрібно створити резервну копію. Деякі плагіни зберігають налаштування у базі даних, тому необережне видалення може ускладнити подальше відновлення.
Якщо після вимкнення одного з плагінів сайт починає працювати, це ще не доводить, що проблема повністю вирішена. Причиною може бути конфлікт версій, неправильна конфігурація, пошкоджені дані або недостатні ресурси для виконання операції.
Ліміти PHP і хостингу
Навіть оптимізований сайт може не встигати відповісти, якщо для нього встановлено занадто низькі ліміти. На результат впливають maxexecutiontime, memory_limit, ліміти процесів PHP, кількість одночасних з’єднань, доступна оперативна пам’ять і навантаження на процесор.
Потрібно також враховувати налаштування вебсервера та проксі: час очікування Nginx, Apache, балансувальника або CDN може відрізнятися від ліміту PHP. Якщо PHP продовжує виконувати запит, але проксі вже припинив очікування, користувач побачить 504.
Під час діагностики перевіряють:
- журнали PHP та вебсервера;
- графіки використання CPU, RAM і дискового простору;
- кількість одночасних PHP-процесів;
- стан бази даних і час виконання SQL-запитів;
- чи збігся початок помилки зі зміною тарифу, конфігурації або перенесенням сайту.
Просте збільшення тайм-ауту не завжди є рішенням. Воно може лише дозволити проблемному запиту довше споживати ресурси та погіршити доступність сайту для всіх відвідувачів. Зміни конфігурації хостингу краще виконувати після резервного копіювання та з урахуванням обмежень конкретного тарифу.
Зовнішні API
Сайт може чекати відповідь від платіжної системи, служби доставки, CRM, сервісу обміну товарами, карт, авторизації або іншого API. Якщо зовнішній сервіс працює повільно чи недоступний, а в коді не встановлено правильний тайм-аут, запит до вашого сайту також може завершитися помилкою 504.
Ознакою такої причини є нормальна робота звичайних сторінок і проблеми лише в окремій функції: оплаті, синхронізації, вході через соціальну мережу або відправленні заявки. У журналах можуть бути повідомлення про перевищення часу очікування, помилки DNS, SSL або невдале підключення до віддаленого домену.
Не варто одразу змінювати ключі доступу чи повторно запускати масову синхронізацію. Спочатку потрібно перевірити статус зовнішнього сервісу, адресу API, сертифікат, обмеження частоти запитів і коректність відповіді. Для критичних операцій бажано передбачити обмежений час очікування, повторні спроби з паузою та постановку завдань у чергу, щоб відвідувач не чекав завершення тривалої операції у браузері.
Тимчасові й постійні рішення
Тимчасові заходи можуть допомогти повернути сайт до роботи: перезапуск PHP-процесів, очищення безпечного кешу, призупинення важкої синхронізації або тимчасове вимкнення проблемного плагіна. Однак такі дії не усувають першопричину, якщо сайт перевантажує сервер, має неефективні запити або регулярно звертається до недоступного API.
Постійне виправлення зазвичай включає оптимізацію SQL-запитів і коду, налаштування кешування, оновлення або заміну конфліктного плагіна, перенесення тривалих операцій у фонові черги, коректне налаштування PHP та вебсервера. Іноді потрібен потужніший тариф або окремий сервер, але це рішення варто приймати після аналізу фактичного навантаження.
Якщо помилка з’явилася після змін, спочатку зафіксуйте, що саме оновлювалося, і не виконуйте додаткових хаотичних правок. Перевірте резервну копію, журнали та доступність хостинг-панелі. За відсутності доступу до сервера, повторенні 504 на всіх сторінках, ризику втрати замовлень або необхідності редагувати базу даних краще залучити спеціаліста. Терміново потрібна допомога з сайтом? 🛠️