500 Internal Server Error: причини, логи і відмінність від 502

Чому 500 говорить так мало

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

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

500 проти 502, 503 і 504

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

• 500 походить від самого застосунку. Щось виконалося і впало з винятком. У логу застосунку є стек-трейс.
• 502 походить від проксі перед застосунком, який отримав недійсну відповідь чи закрите з'єднання від бекенду. Бекенд часто нічого не логує, бо так і не завершив обробку запиту. Дивіться посібник про 502.
• 503 - це відмова, а не збій. Сервер перевантажений чи на обслуговуванні і навмисно відхиляє роботу, зазвичай із заголовком Retry-After.
• 504 - це таймаут. Бекенд був доступний, але не відповів у межах ліміту проксі. Часто запит усе ще виконується десь за лаштунками.

Груба підказка: 500 означає, що зламався ваш код, 502 означає, що ваш бекенд мертвий чи поводиться неправильно, 503 означає, що ваш сервер навмисно відмовляє, 504 означає, що ваш бекенд занадто повільний. Уся родина порівнюється в огляді 5xx.

Що спричиняє 500

• Необроблені винятки в коді застосунку. Найбільша окрема категорія. Значення null, невдале перетворення типу, вихід індексу масиву за межі, ділення на нуль на шляху, який ніхто не тестував.
• Збої бази даних. Вичерпаний пул з'єднань, змінені облікові дані, перезапуск бази даних, запит, що потрапляє в дедлок чи таймаут.
• Відсутні чи зламані залежності після деплою. Пакет, що не встановився, файл, який збірка не скопіювала, змінна середовища, що є на staging, але відсутня в production.
• Синтаксичні помилки конфігурації. На Apache одна неправильна директива у файлі .htaccess дає 500 на кожен запит у цій директорії.
• Права доступу до файлів і власник. Застосунок не може прочитати файл конфігурації або записати в кеш, сесію чи каталог завантажень.
• Ліміти ресурсів. Ліміт пам'яті, ліміт часу виконання чи заповнений диск. Зазвичай саме вони дають переривчасті 500, що корелюють із трафіком.
• Збої сторонніх API, які код викликає без запасного варіанта, тож чужий збій стає вашою сторінкою помилки.

Як діагностувати 500

1. Підтвердьте код і хто його видав. Брендована сторінка помилки може приховувати справжній статус:

   curl -sS -o /dev/null -D - https://example.com/failing-page

   Перевірте рядок статусу і будь-який заголовок Server чи CDN. Якщо помилку підписала edge-мережа, а origin-сервер відповідає 200, ви взагалі дивитеся не на 500 від вашого застосунку.
2. Спершу відкрийте лог застосунку. Саме там стек-трейс. Логи фреймворку, потік логів платформи чи stdout контейнера - залежно від вашого стеку - і зіставте за міткою часу та шляхом запиту.
3. Потім лог помилок веб-сервера. Apache error_log, nginx error.log, або журнал подій Windows для IIS. Якщо застосунок узагалі нічого не залогував, збій стався до того, як запрацював ваш код, а це вказує на конфігурацію чи середовище виконання.
4. Відтворіть його свідомо. З'ясуйте, чи 500 стосується однієї адреси, одного HTTP-методу, одного користувача чи всього. 500 тільки на POST зазвичай означає обробку форми чи шлях запису. 500 для одного користувача зазвичай означає його дані.
5. Увімкніть детальні помилки в непублічному середовищі. Ніколи в production. Відтворіть на staging із повним виводом помилок, що перетворює загальний 500 на конкретний номер рядка.
6. Перевірте, що змінилося. Останній деплой, пуш конфігурації, оновлення сертифіката, оновлення залежності чи міграція бази даних. Якщо годину тому сайт працював нормально, відповідь майже завжди в останній зміні.
7. Перевірте ресурси хоста. Місце на диску, пам'ять і кількість з'єднань. Диск, заповнений логами, дає 500, які виглядають зовсім не пов'язаними з кодом.

500, які повертає лише одна сторінка

Більшість 500 не кладуть увесь сайт. Один маршрут, одна форма чи один регіон ламається, поки головна сторінка продовжує завантажуватися, тож ззовні нічого не виглядає неправильним, а помилки проявляються через дні як втрачені реєстрації. Запланована HTTP-перевірка сторінок, що мають значення, а не лише головної, порівнює отриманий код з очікуваним і сповіщає в момент, коли маршрут починає відповідати 500. Сповіщення можуть надходити електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами, тож нічний збій дійде до чергового, а не чекатиме до ранку. HostTracker моніторить сайти з 2004 року.