Что означает ошибка 500 Internal Server Error и кто в этом виноват

Ошибка 500 Internal Server Error - это сервер, на котором работает сайт, признающий, что что-то пошло не так в его собственном коде, и что из-за этого он не может показать вам страницу. Не “страница не существует”, не “вам не разрешено”, не “вернитесь позже” - просто честное и бесполезное “что-то сломалось здесь, и это не ваша вина”.

Обратите внимание на слово internal. Сервер говорит о себе, а не о сети, разрешении или том, что вы сделали. Он выполнил ваш запрос, столкнулся с ошибкой, которую не знал, как обработать, и единственное честное, что оставалось сказать, это 500. Вот почему сообщение такое расплывчатое: сервер не скрывает детали из-за вредности, он отказывается раскрывать свои внутренние данные незнакомцу.

Почему это ничего вам не сообщает

Ошибка 500 - это самая универсальная ошибка в интернете, и это сделано специально. Когда приложение падает способом, который оно не предусмотрело - необработанное исключение, упавший запрос, null вместо объекта - безопасное решение показать внешнему миру это пустая стена. Конкретные детали того, что сломалось, трассировка стека, номер строки, запрос, который не удался - все это остается на сервере, в журнале, где его могут прочитать только люди, управляющие сайтом.

Итак, ошибка 500, которую вы видите, и причина ее находятся в двух разных местах. В браузере есть код; на сервере есть причина. Этот разрыв - вся сложность ошибки 500, и вот почему “я получил 500” - это отчет, который почти ничего не сообщает разработчику.

500 и 502, 504, которые выглядят одинаково снаружи

Все три - это семейство сервера “что-то пошло не так с нашей стороны”, и их различие указывает на совершенно разные причины.

500 Internal Server Error

Приложение выполнялось, и его собственный код не сработал - необработанное исключение, сбой внутри запроса. Сервер ответил; ответ был ошибкой, которую он сделал сам

502 Bad Gateway

Фронтальный сервер получил непригодный ответ от приложения позади него - упал, отказался, неправильный формат. Сбой между двумя серверами

504 Gateway Timeout

Приложение не ответило вовремя вообще. Фронтальный сервер перестал ждать

Грубо говоря: 500 - это сбой приложения во время его работы, 502 - это сбой прокси при получении хорошего ответа от него, а 504 - это то, что приложение отвечает слишком медленно. Если вы получили 500, код выполнялся и сломался; если вы получили 502 или 504, он часто вообще не закончил выполняться. Это различие - первое, что стоит знать, потому что оно решает, смотрите ли вы в журналы приложения или в коммунальные трубы перед ними.

Если вы посетитель

Перезагрузитесь один раз, потому что довольно много ошибок 500 - это единый плохой момент - один запрос, который попал в гонку, один запрос, который истек времени при всплеске - и следующая попытка приземляется где-то здоровой. Если это сработало, нечего преследовать.

Если это сохраняется, вина лежит на стороне сайта, и в вашем браузере действительно ничего не достигает ошибку в их коде. Очистка кэша, попытка режима инкогнито, переключение браузеров - ничего из этого не касается сервера, и каждое - это распространенные полчаса, потраченные на обращение с 500, как если бы это была проблема, которую вы можете исправить со своего места. Единственное полезное, что вы можете сделать, это сказать им с достаточной информацией, чтобы они могли найти совпадающую строку в своем журнале: что вы делали и примерно когда.

Если это ваш сайт

Ошибка 500 означает, что ваш код выбросил что-то, чего он не обработал, поэтому вопрос только в том, что, и ответ находится в ваших журналах, а не в ответе, который видел пользователь. Несколько причин составляют большинство из них.

Необработанное исключение в запросе. Самое распространенное, безусловно. Метод, вызванный на nil, ключ, которого там не было, тип, который был не тем, что предполагал код. Запрос достиг вашего кода, ваш код вызвал, и ничто его не поймало. Журнал вашего приложения имеет трассировку стека; 500 пользователя - нет.

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

Проблема конфигурации или окружения. Отсутствующая переменная окружения, секрет, который не был установлен, служба, которую приложение ожидает достичь и не может. Это те, которые превращают каждый запрос в 500 сразу, обычно сразу после развертывания или изменения инфраструктуры, и они выглядят тревожно именно потому, что ничего в коде не изменилось - земля под ним изменилась.

Плохое развертывание. Новый код, который вызывает на пути, который тесты не охватили, или загружается с схемой, которой там еще нет. Если 500 начались с выпуска, это первое место для поиска, и откат быстрее диагностики.

Причина, по которой ошибка 500 так сложна в отслеживании впоследствии

Ошибка, которую видел пользователь, не содержит никакой причины, поэтому 500, о котором сообщается час спустя, по памяти, почти бесполезен: у вас есть универсальный код и примерное время, и вы ищете в журнале иголку, которую можете описать только как “около трех часов”. Трассировка стека, которая назвала бы ошибку, находится в строке журнала, которую никто не захватил в соответствии с запросом, который ее произвел.

Что закрывает 500 быстро, так это запрос, который его вызвал, его точное время и то, что делал человек - захвачено, пока это происходило, так что вы можете сопоставить это с одной строкой журнала, которая содержит реальную ошибку в этом. Это разница между ошибкой, которую вы находите за минуту, и журналом, по которому вы прокручиваетесь целый день.

В сетевом журнале хранится неудачный запрос с его 500 и точный момент, когда это произошло, поэтому тот, кто подбирает отчет, может совместить его с журналом сервера и прочитать реальную ошибку - вместо того, чтобы сначала воспроизвести все это, чтобы узнать, что скрывал универсальный код.

В одном абзаце

Ошибка 500 Internal Server Error означает, что приложение выполнило ваш запрос, и его собственный код не сработал способом, который оно не обработало, поэтому оно показало единственный безопасный, универсальный ответ, который имело - что отличает его от 502, где прокси не смог получить хороший ответ от приложения, и 504, где приложение отвечало слишком медленно. Если вы посещаете, перезагрузитесь один раз, а затем предположите, что это их сторона. Если это ваш, причина находится в ваших журналах, а не в ответе: подозревайте необработанное исключение, неудачный запрос, отсутствующую конфигурацию или последнее развертывание - и захватите неудачный запрос, пока вы его имеете, потому что 500 ничего вам не сообщает само по себе.