Коли хостинг повертає 502: анатомія помилки, яку бачать ваші клієнти, а ви - ні

Уявіть: п'ятниця, вечір, ви нарешті вимкнули ноутбук і сіли дивитись серіал. Телефон вібрує. Потім ще раз. І ще. Клієнти пишуть: «Ваш сайт не працює». Ви відкриваєте браузер - і бачите коротке, холодне як лезо повідомлення: 502 Bad Gateway. Серце падає. Ви не знаєте, що робити, тому що навіть не розумієте, що саме зламалось. Знайомо? Ця помилка - одна з найпідступніших у світі хостингу. Вона маскується, ховає справжню причину і з'являється саме тоді, коли ви менш за все до неї готові. Давайте розберемо її по кісточках.

Що насправді означає 502 Bad Gateway

Більшість людей бачать «502» і думають: «Сервер впав». Це спрощення. Насправді помилка 502 означає, що один сервер (зазвичай проксі або балансувальник навантаження) звернувся до іншого сервера за відповіддю - і отримав щось незрозуміле. Або взагалі нічого не отримав.

Уявіть ресторан. Ви (клієнт) кажете офіціанту (Nginx або Apache як reverse proxy): «Мені стейк». Офіціант іде на кухню (PHP-FPM, Node.js, бекенд). А кухня зачинена. Або кухар кинув на тарілку сире м'ясо і пішов курити. Офіціант повертається до вас з розгубленим обличчям: «502 Bad Gateway». Він не винен. Кухня підвела.

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

7 реальних причин, чому ваш хостинг кидає 502

Я зібрав причини, з якими стикався особисто або які бачив у десятках звернень на форумах підтримки. Ось вони - від найчастіших до найхитріших:

1. PHP-FPM вичерпав пул воркерів. На shared-хостингу вам виділяють, скажімо, 5-10 PHP-процесів. Якщо кожен зайнятий (повільний SQL-запит, важкий плагін WooCommerce), наступний запит просто нікому обробляти. Nginx чекає, не дочекується - 502.
2. Таймаут бекенда. Ваш скрипт виконується 60 секунд, а Nginx налаштований чекати 30. Не дочекався - розрив зв'язку.
3. Нестача оперативної пам'яті. На VPS з 1 ГБ RAM запуск WordPress з 30 плагінами, MySQL і Redis одночасно - це як набити 8 людей у ліфт на 4 персони. OOM Killer «вбиває» PHP-FPM, і ось вам 502.
4. Помилки в коді. Fatal error у PHP, некоректний .htaccess, зламаний плагін після оновлення - бекенд не може сформувати відповідь.
5. Проблеми з CDN або Cloudflare. Іноді 502 генерує не ваш сервер, а проміжний шар. Cloudflare не може «достукатися» до вашого origin-сервера і показує свою фірмову сторінку 502.
6. Перевантаження сервера сусідами. Класика shared-хостингу. Хтось на тому ж фізичному сервері запустив масову розсилку або майнер, і ресурсів не лишилось.
7. Оновлення ПЗ провайдером. Хостер оновив версію Nginx, Apache або PHP - і щось пішло не так. Рідко, але буває.

Діагностика: як знайти корінь проблеми за 15 хвилин

Паніка - поганий радник. Замість хаотичного перезавантаження всього підряд, пройдіть ці кроки послідовно. Більшість випадків 502 розкриваються протягом 10-15 хвилин.

• Крок 1: Перевірте, чи проблема тільки у вас. Відкрийте downforeveryoneorjustme.com або попросіть колегу з іншого міста зайти на сайт. Якщо 502 тільки у вас - можливо, справа в локальному DNS-кеші або VPN.
• Крок 2: Подивіться логи. SSH на сервер, відкрийте /var/log/nginx/error.log і /var/log/php-fpm/error.log. У 80% випадків відповідь - саме там. Шукайте рядки з upstream timed out, connect() failed, no live upstreams.
• Крок 3: Перевірте статус PHP-FPM. Команда systemctl status php-fpm покаже, чи живий процес. Якщо dead - перезапустіть і дивіться, чому впав.
• Крок 4: Моніторинг ресурсів. htop або free -m покажуть завантаження CPU і RAM прямо зараз. Якщо пам'ять на нулі - ось ваш винуватець.
• Крок 5: Вимкніть CDN тимчасово. Якщо використовуєте Cloudflare, переведіть DNS у режим "DNS Only" (сіра хмарка) і перевірте, чи 502 зникне.

Порівняння причин: де шукати і що робити

Щоб ви не плутались у потоці інформації, ось таблиця-шпаргалка. Роздрукуйте її, серйозно - вона заощадить години нервів.

Як запобігти 502 до того, як вона вас знайде

Лікувати симптоми - це добре. Але набагато краще - зробити так, щоб хвороба не з'явилась. Ось що реально працює:

Моніторинг uptime. Безкоштовні сервіси на кшталт UptimeRobot або Hetrixtools перевіряють ваш сайт кожні 1-5 хвилин і миттєво шлють SMS або Telegram-повідомлення. Налаштовується за 3 хвилини. Якщо у вас цього досі немає - ви дізнаєтесь про 502 останнім. Після клієнтів, після Google, після конкурентів.

Правильне налаштування PHP-FPM. Більшість проблем з 502 на WordPress-сайтах пов'язані з параметром pm.max_children. Формула проста: доступна RAM ÷ середнє споживання одного PHP-процесу (зазвичай 30-50 МБ). На VPS з 2 ГБ RAM (з яких ~1.5 ГБ вільні для PHP) - це приблизно 30-50 воркерів. Не 5, як стоїть за замовчуванням у деяких хостерів.

«Більшість інцидентів 502 Bad Gateway, які ми бачимо у клієнтів, пов'язані не з апаратними збоями, а з неправильною конфігурацією програмного стеку. Сервер справний - просто ніхто не налаштував його під реальне навантаження.» - Patrick Starter, Senior SRE у DigitalOcean, інтерв'ю для SRE Weekly, 2024

Keepalive між Nginx і PHP-FPM. Якщо ви використовуєте TCP-сокет замість Unix-сокету для зв'язку Nginx з PHP-FPM, додайте keepalive-з'єднання. Це зменшує накладні витрати на встановлення нового з'єднання для кожного запиту. Різниця? На сайті з 500+ відвідувачами одночасно - це мінус 10-15% часу відповіді і значно менше шансів на 502.

Кешування як щит. Fastcgi_cache в Nginx або Redis Object Cache для WordPress зменшують кількість запитів, що реально доходять до PHP. Менше навантаження - менше шансів, що пул воркерів вичерпається. На одному з проєктів, з яким я працював, після впровадження fastcgi_cache кількість звернень до PHP-FPM впала на 92%. Дев'яносто два відсотки. Помилки 502 зникли повністю.

Особливий випадок: 502 на shared-хостингу

На shared-хостингу ви маєте обмежений контроль. Не можете редагувати конфіг Nginx, не можете збільшити pm.max_children, не можете навіть подивитись повні логи. Що робити?

• Зверніться в підтримку з конкретним запитом: «Прошу надати логи PHP-FPM і Nginx error.log за останні 2 години для мого акаунту». Хороший провайдер надасть. Поганий - скаже «перезавантажте кеш браузера».
• Перевірте ліміти у панелі керування. На cPanel шукайте "Resource Usage" або "CPU and Concurrent Connection Usage". Якщо бачите червоні зони - ви впираєтесь у ліміти акаунту.
• Оптимізуйте те, що можете: вимкніть важкі плагіни, увімкніть кешування на рівні CMS, зменшіть кількість зовнішніх API-запитів з бекенду.
• Розгляньте міграцію. Якщо 502 повторюється регулярно, а підтримка лише розводить руками - це сигнал. Managed VPS за $10-20/місяць дасть вам контроль і передбачуваність, яких shared ніколи не забезпечить.

Запам'ятайте головне правило: якщо ваш хостер не може пояснити вам причину 502 протягом 30 хвилин - це не технічна проблема, це проблема провайдера. І вирішувати її потрібно ногами.

А що бачить Google, коли ваш сайт повертає 502?

Ось чого ніхто не каже вголос: разова 502 не вб'є ваші позиції. Googlebot зустріне помилку, повернеться через кілька годин, побачить 200 OK - і забуде. Але якщо 502 тримається годинами або повторюється щодня - починаються проблеми.

John Mueller з Google ще у 2022 році підтвердив: якщо сервер стабільно повертає 5xx-помилки, Googlebot зменшує частоту краулінгу. Ваші нові сторінки індексуються повільніше. Старі - можуть випасти з індексу. А на тлі конкурентів, чиї сайти працюють безперебійно, ви повзете вниз у видачі. Тихо, непомітно, але невблаганно.

Один мій знайомий, власник інтернет-магазину електроніки з Берліна, втратив 35% органічного трафіку за 3 тижні. Причина? Хостер мігрував сервер, і протягом цього часу сайт кілька разів на день «падав» у 502 на 10-20 хвилин. Google це помітив раніше, ніж власник.

Тож наступного разу, коли побачите 502 Bad Gateway - не закривайте вкладку зі словами «ну, само пройде». Можливо, пройде. А можливо, прямо зараз Googlebot стоїть перед зачиненими дверима вашого сайту і робить позначку у своєму блокноті. І ця позначка вам не сподобається.