Помилка 502 Bad Gateway: причини та покрокове вирішення

Помилка 502 Bad Gateway з’являється тоді, коли запит дійшов до сервера, але один із серверів на його шляху не отримав коректної відповіді від іншого. Сторінка при цьому не відкривається, хоча інтернет у відвідувача працює, а домен вказано правильно. Найчастіше причина на боці сайту, і саме тому повідомлення однаково турбує і відвідувачів, і власників ресурсів.

Код помилки 502 не називає конкретну несправність, він лише вказує місце, де обірвався обмін даними. Розбираємо, що означає 502 Bad Gateway, як відрізнити локальний збій від серверного, що може зробити відвідувач і в якій послідовності шукати причину власнику сайту.

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

502 Bad Gateway – це код стану протоколу HTTP (status code 502) із групи 5xx, тобто з групи серверних помилок. Дослівно назва перекладається як «поганий шлюз», тому її ще називають помилкою шлюзу. Сервер, який працює як шлюз або проксі, передав запит далі, але у відповідь отримав щось некоректне або зіткнувся з обривом з’єднання до отримання коректної відповіді. Якщо ж відповідь не надійшла у встановлений час, зазвичай застосовується код 504 Gateway Timeout.

Щоб зрозуміти зміст помилки, варто уявити шлях запиту. Сучасний сайт рідко складається з одного сервера. Перед застосунком зазвичай стоїть зворотний проксі, найчастіше Nginx, який приймає з’єднання від відвідувачів і пересилає запити обробнику: PHP-FPM, серверу застосунку на Node.js чи Python або іншому вебсерверу. Ще раніше в цьому ланцюжку можуть стояти CDN, балансувальник навантаження та мережевий екран.

Помилку 502 повертає шлюз або проксі, який не зміг отримати коректну відповідь від наступного сервера. Тому текст на екрані буває різним: «502 Bad Gateway nginx», «502 Bad Gateway openresty», «HTTP Error 502», «502 Proxy Error», «Не вдалося виконати запит (HTTP 502)» або фірмова сторінка CDN. Оформлення сторінки може підказати, який компонент сформував повідомлення, але не завжди однозначно визначає джерело несправності.

Сам по собі код 502 не доводить втрати даних, злому сайту чи несправності домену, але й не виключає супутніх проблем. Для встановлення причини потрібно перевірити стан серверів, мережевих з’єднань і журнали помилок. Після усунення збою доступність сторінок зазвичай відновлюється.

Відмінність 502 від помилок 500, 503 і 504

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

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

Код 500, навпаки, найчастіше пов’язаний із самим застосунком: помилкою у скрипті, неправильною директивою чи правами на файли. Водночас код 500 може формуватися й іншими компонентами, тому діагностика має спиратися на журнали, а не лише на номер помилки. Тому точне зчитування коду ще до початку перевірок економить час і звужує коло пошуку.

Деякі сервіси доповнюють стандартний перелік власними кодами. Cloudflare, наприклад, використовує коди групи 52x для ситуацій, коли його вузол не зміг нормально зв’язатися із сервером власника сайту: з’єднання відхилено, час очікування вичерпано, сертифікат не пройшов перевірку. За змістом вони близькі до 502 і 504, але точніше називають етап, на якому стався збій.

Причини помилки 502

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

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

Перевантаження сервера

Коли серверу бракує оперативної пам’яті або процесорного часу, обробник не встигає приймати нові з’єднання. Черга запитів заповнюється, і проксі отримує відмову замість відповіді. Таке трапляється під час різкого зростання відвідуваності, роботи важких фонових завдань, обходу сайту агресивними ботами або через неоптимальні запити до бази даних.

Окремий випадок – повне вичерпання пам’яті. Операційна система в такій ситуації примусово завершує процеси, які споживають найбільше, і серед них часто опиняються процеси PHP або бази даних. Для відвідувача це виглядає як раптова помилка 502, яка зникає після автоматичного перезапуску сервісу і повертається за наступного сплеску навантаження.

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

Збій PHP-FPM або сервера застосунку

Обробник може бути зупинений, завислий або зайнятий повністю. У PHP-FPM кількість одночасних процесів обмежена параметром pm.max_children. Коли всі процеси зайняті повільними запитами, нові запити очікують на вільний процес. Залежно від конфігурації та характеру відмови це може завершитися 502, 504 або іншим кодом.

Процес також може аварійно завершитися під час виконання скрипта: через збій розширення, нестачу системної пам’яті чи примусове завершення за параметром request_terminate_timeout. Звичайне перевищення PHP memory_limit не обов’язково завершує процес і саме по собі не означає 502. З’єднання розривається до того, як відповідь сформована, і проксі отримує обірвані дані. Подібно поводяться сервери застосунків на Node.js, Python чи Java, якщо процес упав і не був перезапущений.

Ще одне джерело зависань – зовнішні сервіси. Сторінка може очікувати відповіді від платіжної системи, CRM, служби доставки чи іншого API. Якщо такий запит виконується під час формування сторінки й не має власного обмеження часу, процес обробника залишається зайнятим, доки зовнішній сервіс не відповість. Кілька таких запитів одночасно здатні зайняти всі вільні процеси.

Характерна ознака цього сценарію – перезапуск сервісу допомагає, але ненадовго. Сайт працює кілька годин або днів, після чого помилка повертається. Це означає, що процеси поступово накопичують пам’ять або зависають на певному типі запитів. Тимчасово ситуацію згладжує обмеження кількості запитів, після якої процес перезапускається, проте справжню причину все одно потрібно шукати в коді або в журналі повільних запитів.

Конфігурація Nginx і тайм-аути

Помилка може бути закладена в самих налаштуваннях. Проксі звертається не на ту адресу чи порт, шлях до сокета PHP-FPM змінився після оновлення версії PHP, а конфігурацію не поправили. До того ж результату призводять замалі буфери для заголовків відповіді: якщо застосунок передає великі cookie або довгі заголовки, Nginx відкидає таку відповідь як некоректну.

Із тайм-аутами ситуація менш очевидна. Коли Nginx сам не дочекався відповіді, він повертає 504, а не 502. Проте якщо час виконання обмежено на боці обробника, той завершує процес і розриває з’єднання, і тоді виникає саме 502. Тому збільшення тайм-аутів допомагає не завжди: воно лише приховує повільний запит і довше утримує зайняті процеси.

До цієї ж групи належить невідповідність протоколів. Якщо проксі звертається до обробника через HTTPS, а той очікує звичайний HTTP, виникає помилка протоколу. Проблеми із сертифікатом внутрішнього сервера також можуть порушити з’єднання, коли налаштовано перевірку TLS. Обробник при цьому працює справно, і без перегляду журналу проксі зрозуміти причину відмови складно.

Окремої перевірки потребує зв’язка, у якій вебсервери Apache та Nginx працюють разом: один приймає запити, другий їх обробляє, і помилка в налаштуваннях будь-якого з них дає той самий код 502.

CDN, файрвол і захист від DDoS

Якщо сайт підключено до мережі доставки контенту, одним із проміжних шлюзів може бути вузол CDN. Він звертається до сервера, на якому розміщено сайт, і за невдалої спроби сам показує сторінку з кодом 502. Деякі CDN надають додаткову діагностику, але сторінка помилки не завжди точно встановлює винний компонент. Це допомагає зрозуміти, куди звертатися.

Буває й так, що сервер працює, але не пускає до себе вузли CDN. Мережевий екран або система захисту сприймає велику кількість запитів з однакових адрес як підозрілу активність і блокує їх. Схожий ефект дає справжня атака: під час DDoS-атаки обробник захлинається запитами, і легітимні відвідувачі бачать 502. Тому правила фільтрації потрібно узгоджувати зі схемою, за якою трафік потрапляє на сайт.

Ще одна причина пов’язана з адресами. Після перенесення сайту на інший сервер у налаштуваннях CDN або балансувальника може залишитися стара IP-адреса. Проміжний сервіс продовжує звертатися туди, де сайту вже немає, і отримує відмову. Те саме трапляється, коли запис у DNS оновлено, а частина мережі ще користується попереднім значенням із кешу.

Масштаб проблеми з помилкою 502

Перше, що варто з’ясувати, – чи бачать помилку всі відвідувачі, чи лише хтось один. Для цього достатньо відкрити сайт з іншого пристрою та через іншу мережу, наприклад через мобільний інтернет. Якщо сторінка відкривається лише з іншої мережі, варто перевірити кеш DNS, VPN, проксі та маршрутизацію. Відмінність також може бути пов’язана з CDN, регіональним вузлом або правилами фільтрації на сервері.

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

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

Власнику сайту варто додатково перевірити відповідь сервера без браузера, наприклад командою curl -I з адресою сторінки. Вона показує код стану та заголовки, які іноді допомагають визначити проміжний компонент, але не гарантують встановлення джерела збою. Для адрес, що не підтримують метод HEAD, варто перевірити звичайний GET-запит. Якщо сайт розміщено у провайдера, корисно також переглянути сторінку стану його сервісів і повідомлення про планові роботи, щоб не шукати несправність там, де її немає.

Дії користувача при помилці 502

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

1. Оновити сторінку через хвилину-дві. Короткі збої під час перезапуску сервісів минають самі.
2. Відкрити сайт у режимі інкогніто або в іншому браузері. Так виключаються кеш, cookie та розширення.
3. Очистити кеш і cookie для цього сайту, якщо в приватному вікні сторінка відкривається.
4. Вимкнути VPN або проксі та спробувати іншу мережу.
5. Очистити кеш DNS, якщо не відкривається лише цей сайт і лише на вашому пристрої. У Windows для цього в командному рядку виконують ipconfig /flushdns, у macOS у терміналі – sudo killall -HUP mDNSResponder.
6. Перезавантажити роутер і перевірити, чи відкриваються інші сайти.

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

На телефоні порядок дій той самий, лише коротший. Варто оновити сторінку, перемкнутися з Wi-Fi на мобільний інтернет або навпаки, відкрити сайт в іншому браузері та очистити дані браузера для цього сайту. Якщо помилку показує не сайт, а застосунок, допомагає його перезапуск, а коли збій масовий, залишається дочекатися, доки сервіс відновить роботу.

Окремо варто згадати форми оплати та замовлення. Якщо помилка з’явилася одразу після надсилання форми, не слід повторювати дію кілька разів поспіль. Запит міг бути оброблений, хоча відповідь не дійшла. Краще перевірити пошту, особистий кабінет або виписку і лише потім повторювати операцію.

Діагностика помилки 502 для власника сайту

Коли помилка 502 на сайті не зникає сама, власнику або адміністратору потрібна послідовність, яка веде від симптому до причини. Перезапуск сервісів часто повертає сайт до роботи, але без з’ясування причини помилка повторюється.

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

Журнали Nginx і PHP-FPM

Найточнішу відповідь дають журнали сервера. У типовій конфігурації Nginx записує помилки у файл /var/log/nginx/error.log, а розташування журналу PHP-FPM залежить від дистрибутива та версії PHP. Шукати потрібно записи за той час, коли відвідувачі бачили помилку, і звертати увагу на слово upstream, яким Nginx позначає сервер-обробник.

Формулювання запису прямо вказує на характер збою. Рядок «connect() failed (111: Connection refused)» означає, що обробник не приймає з’єднань: він зупинений або слухає іншу адресу. Запис «upstream prematurely closed connection» свідчить, що процес завершився під час обробки запиту. Повідомлення «upstream sent too big header» вказує на замалі буфери.

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

На сайтах із WordPress додаткову інформацію дає власний журнал системи. Він вмикається у файлі wp-config.php параметрами WP_DEBUG та WP_DEBUG_LOG, а параметр WP_DEBUG_DISPLAY зі значенням false не дає повідомленням потрапляти на сторінки. Записи зберігаються у файлі debug.log у теці wp-content і можуть допомогти виявити проблемний компонент. Журнал слід захистити від публічного доступу та вимкнути докладне налагодження після перевірки. Не кожна PHP-помилка спричиняє 502.

Корисно зіставити журнал помилок із журналом доступу. У ньому видно, які саме адреси отримували відповідь 502, скільки таких запитів було і з яких джерел вони надходили. Концентрація помилок на певних URL може вказувати на конкретну операцію чи модуль, а масові збої – на спільний компонент інфраструктури. Остаточний висновок роблять після зіставлення журналів.

Ресурси сервера під навантаженням

Другий напрям – стан самого сервера. Утиліти top або htop показують завантаження процесора та процеси, які споживають найбільше, команда free -m – стан оперативної пам’яті та підкачки, а df -h – вільне місце на диску. Заповнений диск нерідко стає неочевидною причиною: сервіси не можуть записати тимчасові файли чи сесії та завершуються з помилкою.

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

За результатами стає зрозуміло, чого саме бракує. Іноді достатньо узгодити кількість процесів PHP-FPM з доступною пам’яттю, щоб сервер не брав на себе більше, ніж здатен обробити. В інших випадках потрібна оптимізація запитів до бази даних або кешування. Якщо ж оптимізований застосунок стабільно впирається в доступні ресурси, доцільно переглянути конфігурацію сервера.

Останні зміни на сайті

Третій напрям – усе, що змінювалося незадовго до появи помилки. Це оновлення PHP, CMS, плагінів і тем, правки конфігурації Nginx, нові правила мережевого екрана, підключення або переналаштування CDN. Після оновлення версії PHP, наприклад, часто змінюється шлях до сокета, а в конфігурації вебсервера залишається старий.

Правильність конфігурації Nginx перевіряє команда nginx -t, а стан сервісів показує systemctl status. Якщо конфігурація коректна і всі сервіси запущені, увагу переносять на сам сайт: оновлені плагіни, теми та модулі системи керування.

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

Плагіни, теми та модулі CMS

На сайтах із готовою системою керування причиною часто стає розширення, яке після оновлення зависає або завершується з критичною помилкою. У WordPress спершу зіставляють час збою з оновленнями та журналами PHP. Якщо є підозра на плагін, його тимчасово вимикають через адміністративну панель або WP-CLI, а за відсутності доступу – обережно перейменовують теку після резервного копіювання. Масове вимкнення плагінів і зміна теми на робочому сайті можуть порушити функціональність, тому такі дії бажано перевіряти на тестовій копії.

Далі переглядають журнал помилок PHP, перевіряють ліміт пам’яті та очищають кеш об’єктів. Коли сайт запрацював, розширення повертають по одному й після кожного кроку оновлюють сторінку. Модуль, після ввімкнення якого помилка повернулася, оновлюють, замінюють аналогом або повертають до попередньої версії.

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

Вплив помилки 502 на SEO

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

Ризик з’являється тоді, коли збій триває довго або регулярно повторюється. Сторінки, які стабільно повертають серверну помилку, з часом можуть бути вилучені з індексу, а нові матеріали потрапляють у пошук із затримкою. Стан сканування видно у звітах Google Search Console, де серверні помилки винесено в окрему категорію.

Для планових робіт існує коректніший спосіб повідомити про недоступність. На час коротких планових робіт сервер можна налаштувати на відповідь 503 із заголовком Retry-After, який указує рекомендований час повторної спроби. Тривала недоступність навіть із кодом 503 шкодить скануванню та індексації. Так пошуковик отримує однозначний сигнал про тимчасовий характер перерви, а не про несправність сайту.

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

Профілактика помилки 502

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

• Моніторинг. Зовнішня перевірка доступності та сповіщення про помилки 5xx дозволяють дізнатися про збій раніше за відвідувачів.
• Запас ресурсів. Сервер має витримувати пікове навантаження, а не лише середнє, і мати резерв пам’яті для фонових завдань.
• Узгоджені ліміти. Кількість процесів обробника, тайм-аути та буфери проксі мають відповідати одне одному й обсягу пам’яті.
• Кешування. Готові сторінки та результати важких запитів знімають частину навантаження з обробника.
• Контроль змін. Оновлення та правки конфігурації спершу перевіряються на тестовій копії та мають план відкату.
• Фільтрація трафіку. Обмеження для ботів і захист від атак не дають стороннім запитам вичерпати ресурси.
• Обмеження для зовнішніх сервісів. Запити до сторонніх API мають власний тайм-аут і за можливості виконуються у фоні.
• Перевірка перед піком. Навантажувальне тестування перед рекламною кампанією чи розпродажем заздалегідь визначає межу сервера.

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

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

Якщо ж сайт регулярно впирається у межі тарифу, має прогнозовані піки відвідуваності або потребує власних налаштувань обробника, варто розглянути перехід на сервер з гарантованими ресурсами. Hostpark пропонує SSD VDS у Польщі на інфраструктурі Atman із KVM-віртуалізацією. Такий формат дає змогу підібрати ресурси під потреби застосунку й адмініструвати сервер відповідно до обраної конфігурації. Для архітектур із кількома вузлами може бути корисним балансування навантаження, яке потребує окремого проєктування. Для мережевої фільтрації в інфраструктурі Atman доступний окремий керований сервіс Atman Firewall; він не є автоматичною складовою VDS і не замінює усунення причин помилки 502.

Висновок

Помилка 502 Bad Gateway означає, що проксі або шлюз не отримав коректної відповіді від сервера, якому передав запит. Для відвідувача це привід перевірити браузер і мережу та повернутися на сайт пізніше. Для власника ресурсу це сигнал про те, що обробник запитів недоступний, перевантажений або неправильно пов’язаний із вебсервером.

Надійний спосіб усунення один: з’ясувати масштаб, прочитати журнали, оцінити ресурси та перевірити останні зміни. Перезапуск сервісів іноді тимчасово відновлює роботу, але не обов’язково усуває причину. Журнали Nginx та обробника допомагають звузити коло пошуку, а результати слід зіставляти з метриками та змінами конфігурації.

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