Як виправити помилку HTTP 500 Internal Server Error?

Помилка HTTP 500 (Internal Server Error), яку ви можете побачити у вікні браузера, це ситуація, коли віддалений сервер повідомляє нам про внутрішню помилку, але не розкриває її конкретну причину. Це відбувається тому, що HTTP 500 - це не якась конкретна окрема помилка, а універсальний статус, який об'єднує в собі найширший спектр можливих проблем. За ним можуть ховатися як банальні обмеження ресурсів, так і помилки в коді додатка або некоректна конфігурація веб-сервера. Тому з самого початку нам потрібно чітко усвідомити, що помилка 500 просто вказує на проблему на самому сервері. Ні в мережі, ні в DNS, ні на шляху до сервера на проміжних вузлах, а саме на самому кінцевому сервері.

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

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

У цій статті давайте розберемо можливі причини виникнення помилки HTTP 500, а також навчимося послідовно знаходити та усунути причини її виникнення.

 

 

 

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

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

І хоч у реальній роботі однаковий статус HTTP 500 може виникати з абсолютно різних причин, будь то помилка в PHP-коді, переповнений диск або збій backend-сервісу в Kubernetes, але все ж є місця в системі, на які в першу чергу варто звернути увагу. За статистикою, код помилки HTTP 500 найчастіше пов'язаний з:

• помилками в серверному коді (PHP, Python, Node.js);
• проблемами конфігурації веб-сервера;
• неправильними правами доступу до файлів і каталогів проєкту;
• нестачею ресурсів сервера;
• збоями при роботі з базою даних.

 

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

 

 

 

 

З чого почати

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

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

• Лог веб-сервера Nginx: /var/log/nginx/error.log;
• Лог веб-сервера Apache: /var/log/apache2/error.log;
• Логи PHP-FPM: /var/log/php*-fpm.log;
• Логи вашого додатка (Django, Laravel, Node.js): нестандартні файли ваших логів;

 

Давайте розглянемо одну типову ситуацію. У лозі PHP ми бачимо такий рядок:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

З точки зору самого сервера це означає, що на сервері просто закінчилася пам'ять і через це PHP видав помилку, а з точки зору браузера користувача - він побачить ту саму помилку HTTP 500 Internal Server Error. Саме тому логи системи завжди повинні бути відправною точкою при пошуку проблеми. А без цього ви просто будете гадати на кавовій гущі.

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

 

 

 

Помилки в коді додатка

Дуже часто код 500 Internal Server Error виникає не через проблеми сервера як такого, а через банально зламаний додаток. Вся інфраструктура може бути в повному порядку: веб-сервер відповідає, база доступна, вільні ресурси сервера є, але ось сам код додатка не впорався з обробкою запиту і впав.

Це часто відбувається, коли в додатку виникає помилка, яку ніхто не обробив. Наприклад, у PHP це може бути фатальна помилка, у Django - traceback, а в Node.js - просто падіння самого процесу. Але суть проблеми одна: код не може коректно завершити виконання завдання, і сервер повертає HTTP 500 як універсальний сигнал, що щось пішло не так.

Часто в production-режимі такі помилки майже завжди приховані від очей користувачів, а фреймворки спеціально не показують деталі проблеми користувачеві, щоб не розкривати внутрішню логіку додатка. Тому в браузері ви бачите лише суху відповідь HTTP 500 Internal Server Error, а вся реальна інформація потрапляє в логи додатка.

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

 

 

 

 

Конфігурація веб-сервера

Другою за частотою є ситуація, коли проблема не в коді, а в тому, як налаштований веб-сервер. Сам додаток може бути повністю робочим, але через помилку в конфігурації Nginx або Apache користувачі все одно отримують HTTP 500.

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

Це може бути що завгодно: неправильно вказаний fastcgi_pass, помилка в .htaccess, невдале правило rewrite або конфлікт у налаштуваннях SSL-сертифіката. Ну а зовні це завжди виглядає однаково, як внутрішня помилка сервера, хоча додаток при цьому навіть не встигає нормально запуститися.

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

nginx -t

, а для веб-сервера Apache - командою:

apachectl configtest

 

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

 

 

 

 

Права доступу

Ще одна з частих, але при цьому регулярно ігнорованих причин помилки HTTP 500 - це банальні проблеми з правами доступу до файлів і каталогів. На рівні логіки тут все просто: сервер не може прочитати або виконати файл, а отже, він не може обробити запит.

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

Перевірити це можна швидко:

ls -la /var/www/project

Якщо видно, що власники та права не відповідають, їх потрібно привести до ладу:

chown -R www-data:www-data /var/www/project

chmod -R 755 /var/www/project

 

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

 

 

 

 

База даних

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

Ззовні це виглядає, як ми вже зрозуміли, як помилка HTTP 500. При цьому веб-сервер працює, код запускається і додаток навіть може запуститися, але на якомусь етапі, коли додатку необхідно звернутися до БД - сервер падає.

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

Наведемо типовий приклад із логів бази даних:

SQLSTATE[HY000] [2002] Connection refused

 

Це означає, що додаток спробував підключитися до бази, але не зміг.

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

 

 

 

 

Ресурси сервера

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

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

Ну і, як ви розумієте, часто система натрапляє на базові обмеження:

• закінчується оперативна пам'ять, і процеси починають аварійно завершуватися;
• CPU завантажується на 100%, через що нові запити просто не встигають оброблятися;
• диск переповнюється, і система не може записувати тимчасові файли або логи;
• запускається занадто багато процесів (наприклад, PHP-FPM), і вони починають конкурувати за ресурси.

 

Щоб швидко зрозуміти, в чому справа, вам достатньо подивитися поточний стан системи за допомогою таких базових команд:

top

htop

free -m

df -h

 

Ці команди дають базове уявлення про стан системи: чи є вільна пам'ять, чи не застряг CPU на повній потужності та чи не закінчилося місце на диску. Детальніше про те, як зрозуміти, що ваша програма гальмує або вилітає саме через апаратне забезпечення, ми писали в цій статті.

Для кращого розуміння наведемо наочний приклад: Типовий сайт, що працює на WordPress, на невеликому VPS-сервері з 1 ГБ оперативної пам'яті. У звичайний час все працює нормально, але під хоч би якимось серйозним навантаженням плагіни починають споживати більше пам'яті, у результаті PHP-процеси розмножуються, і в якийсь момент сервер просто не витримує. Процеси починають падати, і замість запитуваної сторінки користувач отримує код відповіді HTTP 500 Internal Server Error.

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

 

 

 

 

CMS і плагіни

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

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

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

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

 

 

 

 

Інфраструктура

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

Сучасний базовий стек зараз виглядає так, що це не один сервер, на якому розташовані всі частини системи, а кілька шарів, кожен з яких відповідає за свою ділянку, наприклад CDN, веб-сервер (Nginx), backend-додаток, база даних, які, до того ж, можуть розташовуватися на різних серверах. У такому випадку запит проходить через весь цей ланцюжок, і збій на будь-якому етапі призведе до одного результату - Internal Server Error.

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

 

 

 

 

Спрощений алгоритм діагностики

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

Головне, що потрібно запам'ятати - ніколи не розсіюйте свою увагу і не намагайтеся виправити все й одразу. Необхідно рухатися методично, за зрозумілим і перевіреним порядком, від найбільш ймовірних причин до менш очевидних. Такий підхід економить час і позбавляє вас від зайвого хаосу в діагностиці.

Найбільш правильний процес повинен виглядати як послідовна перевірка ключових точок системи:

1. Спочатку має сенс заглянути в логи сервера і самого додатка, оскільки саме там найчастіше вже є пряма відповідь на питання, що пішло не так;
2. Потім варто переконатися, що конфігурація самого веб-сервера є коректною;
3. Після цього має сенс перевірити базові речі, такі як права доступу до файлів і каталогів;
4. Далі потрібно переконатися в коректності підключення до бази даних і взагалі перевірити її доступність;
5. Якщо до цього проблема не була локалізована, тоді варто звернути увагу на стан ресурсів самого сервера, чи вистачає пам'яті, чи не перевантажений CPU і чи не переповнений диск;
6. Нарешті, якщо нічого з цього не дало результату, тоді варто виключити вплив стороннього коду на ваш додаток або CMS, усіляких плагінів, модулів або сторонніх інтеграцій, які можуть порушувати роботу додатка.

 

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

 

 

 

 

 

FAQ

 

Чому з'являється HTTP 500, якщо, здавалося б, нічого не змінювалося?

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

 

Чи може нестача ресурсів викликати HTTP 500?

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

 

Чи може база даних бути причиною HTTP 500?

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

 

Чи може проблема бути в конфігурації сервера?

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

 

Чи може HTTP 500 бути пов'язаний із плагінами або CMS?

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

 

Чи може Cloudflare або CDN викликати HTTP 500?

Іноді так, але найчастіше ні, оскільки в більшості випадків CDN просто передає помилку від origin-сервера. Тому починати перевірку варто саме з backend і логів сервера.

 

 

 

 

Висновок

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

Але хороша новина полягає в тому, що в більшості випадків все це не Rocket Science, а цілком приземлені речі. Логи майже завжди дають відповідь про причини падіння системи, і якщо почати саме з них, а не з припущень, тоді локалізувати проблему вдасться досить швидко. Решта - це послідовна перевірка конфігурації самого сервера, прав доступу, стану бази та доступних ресурсів.

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