Чому сайт отримує помилки 500 і як їх виправити

Чому сайт отримує помилки 500 і як їх виправити: практичний посібник з тріажу

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

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

1. Переконайтеся, що це справді серверна 500

Відкрийте сторінку в приватному вікні й зверніть увагу на точне формулювання. Звичайна помилка джерела часто пише “500 Internal Server Error” або щось настільки ж загальне, тоді як рівень проксі може показувати власний код, ID запиту або повідомлення про upstream-сервер. Ця невелика різниця важлива, бо 502 зазвичай вказує на неправильну відповідь шлюзу, а 503 — на тимчасову недоступність служби; якщо ви шукаєте internal server error що робити, почніть саме з перевірки джерела помилки.

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

Cloudflare, Fastly, nginx, Apache та ваша програма можуть по-різному позначати збій. Один сайт може показувати акуратну сторінку CDN із міткою 5xx, а інший — майже порожній білий екран і короткий рядок у HTML. Симптом той самий, але джерело різне.

2. Відтворіть помилку в контрольований спосіб

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

Повторюйте запит, змінюючи 3 параметри: браузер, пристрій і час. Якщо збій є в Chrome на десктопі, але немає в Safari на мобільному, можливо, ви маєте справу зі шляхом виконання скрипта або краєм кешу. Якщо збій виникає лише після імпорту розсилки або о 2-й ночі, сам час уже є підказкою.

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

Ведіть простий запис: URL, час, дія та відповідь. Чотирьох полів достатньо. Коли набереться 3 або 4 записи, почнуть проявлятися закономірності.

3. Перевірте журнал помилок вебсервера, щоб знайти першу точку збою

Журнал помилок зазвичай — перше місце, куди варто дивитися після того, як сторінка двічі впала. Зіставте час помилки 500 із найближчим записом у журналі, а потім прочитайте рядок перед ним і рядок після нього. Перший рядок часто каже більше, ніж будь-коли скаже сторінка помилки.

Вам потрібні назва скрипта, модуля, попередження про права доступу або тайм-аут upstream. Фатальна помилка PHP може прямо назвати файл. Помилка вебсервера може згадувати відсутній каталог, неправильну ціль rewrite або відхилене з’єднання з backend-процесом.

Корисна звичка: скопіюйте точний час невдалого запиту й порівняйте його з access-логами та error-логами. Якщо сайт завантажений, “найближча” подія все одно може відрізнятися на кілька секунд, тож перевіряйте також шлях запиту й код статусу. Один request ID, якщо ваша система його додає, може заощадити довгий пошук.

Коли журнал називає плагін, бібліотеку або модуль, ненадовго зупиніться. Прочитайте контекст навколо. Рядок про “allowed memory size exhausted” вказує на ліміти ресурсів, а “permission denied” — на проблеми з власником або режимом доступу, навіть якщо в обох випадках зовні це виглядає як 500.

4. Перевірте тригери обмежень ресурсів і тайм-аутів

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

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

Перевірте й ліміти часу виконання. Скрипт, який зависає надто довго, може дійти до тайм-ауту й залишити сервер прибирати наслідки. Так буває під час імпортів, cron-завдань або повільного API-запиту, що чекає на іншу службу. Досить одного повільного залежного сервісу.

Насичення воркерів або процесів помітити легше пропустити, бо за малого трафіку сайт може виглядати цілком здоровим. Потім одночасно приходять 20 запитів, черга переповнюється, і нові запити починають падати. Деякі хостинг-плани також накладають ліміти на рівні акаунта — CPU, entry processes або I/O, тож проблема може бути в самому тарифі, а не в коді.

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

5. Перевірте права доступу до файлів і папок поза межами CMS

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

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

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

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

6. Перевірте нещодавні зміни на сервері або в розгортанні

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

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

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

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

7. Відновіть роботу за допомогою найменшого безпечного відкату

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

Почніть з найменш ризикового елемента, який змінився останнім. Якщо нове правило редиректу з’явилося за 20 хвилин до збою, закоментуйте його й перевірте ще раз. Якщо змінювали PHP-параметр, поверніть лише це значення до попереднього й знову перевірте. Мета — відновити роботу сервісу, а не влаштувати драматичне прибирання.

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

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

8. Запобігайте повторенню тієї самої 500

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

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

Ведіть зміни в одному місці. Маємо на увазі правки конфігурацій, оновлення плагінів, зміни PHP, коригування cron і оновлення правил безпеки. Якщо ви вже відстежуєте зміни на сайті, у блозі ostohlo є пов’язані матеріали в блозі ostohlo studio, які можуть стати в пригоді, коли вам потрібен запис, а не спогад.

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