Ошибка 500 это фронт или бэк

В статье мы расскажем, как исправить ошибку (код состояния) 500 со стороны пользователя и администратора сайта, а также подробно разберём, что такое ошибка запроса 500.

Что такое внутренняя ошибка сервера 500

Код ошибки 5хх говорит о том, что браузер отправил запрос корректно, но сервер не смог его обработать. Что значит ошибка 500? Это проблема сервера, причину которой он не может распознать.

Сообщение об ошибке сопровождается описанием. Самые популярные варианты:

• Внутренняя ошибка сервера 500,
• Ошибка 500 Internal Server Error,
• Временная ошибка (500),
• Внутренняя ошибка сервера,
• 500 ошибка сервера,
• Внутренняя ошибка HTTP 500,
• Произошла непредвиденная ошибка,
• Ошибка 500,
• HTTP status 500 internal server error (перевод ― HTTP статус 500 внутренняя ошибка сервера).

Дизайн и описание ошибки 500 может быть любым, так как каждый владелец сайта может создать свою версию страницы. Например, так выглядит страница с ошибкой на REG.RU:

Как ошибка 500 влияет на SEO-продвижение

Для продвижения сайта в поисковых системах используются поисковые роботы. Они сканируют страницы сайта, проверяя их доступность. Если страница работает корректно, роботы анализируют её содержимое. После этого формируются поисковые запросы, по которым можно найти ресурс в поиске.

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

Проверить, осталась ли страница на прежних позициях, можно с помощью Google Search Console. Если робот исключил страницу из поисковой выдачи, её можно добавить снова.

Код ошибки 500: причины

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

• ошибки в файле .htaccess,
• неподходящая версия PHP,
• некорректные права на файлы и каталоги,
• большое количество запущенных процессов,
• большие скрипты,
• несовместимые или устаревшие плагины.

Решить проблему с сервером можно только на стороне владельца веб-ресурса. Однако пользователь тоже может выполнить несколько действий, чтобы продолжить работу на сайте.

Что делать, если вы пользователь

Если на определённом ресурсе часто возникает ошибка 500, вы можете связаться с владельцем сайта по инструкции.

Перезагрузите страницу

Удаленный сервер возвращает ошибку не только из-за серьёзных проблем на сервере. Иногда 500 ошибка сервера может быть вызвана небольшими перегрузками сайта.

Чтобы устранить ошибку, перезагрузите страницу с помощью сочетания клавиш:

• на ПК — F5,
• на ноутбуке — Fn + F5,
• на устройствах от Apple — Cmd + R.

Обратите внимание! Если вы приобретаете товары в интернет-магазине и при оформлении заказа появляется 500 Internal Server Error (перевод — внутренняя ошибка сервера), при перезагрузке страницы может создаться несколько заказов. Поэтому сначала проверьте, оформился ли ваш предыдущий заказ. Если нет, попробуйте оформить заказ заново.

Очистите кэш и cookies браузера

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

Если ни одно из этих действий не решило проблему, значит, некорректно работает сам сервер сайта. Вернитесь на страницу позже, как только владелец решит проблему.

Что делать, если вы владелец сайта

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

Ниже рассмотрим самые популярные причины и способы решения.

Ошибки в файле .htaccess

Неверные правила в файле .htaccess — частая причина возникновения ошибки. Чтобы это проверить, найдите .htaccess в файлах сайта и переименуйте его (например, в test). Так директивы, прописанные в файле, не повлияют на работу сервера. Если сайт заработал, переименуйте файл обратно в .htaccess и найдите ошибку в директивах. Если вы самостоятельно вносили изменения в .htaccess, закомментируйте новые строки и проверьте доступность сайта.Также может помочь замена текущего файла .htaccess на стандартный в зависимости от CMS.

Найти директиву с ошибкой можно с помощью онлайн-тестировщика. Введите содержимое .htaccess и ссылку на сайт, начиная с https://. Затем нажмите Test:

Произошла непредвиденная ошибка

На экране появится отчёт. Если в .htaccess есть ошибки, они будут выделены красным цветом:

500 ошибка nginx

Активирована устаревшая версия PHP

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

Установлены некорректные права на файлы и каталоги сайта

В большинстве случаев корректными правами для каталогов являются «755», для файлов — «644». Проверьте, правильно ли они установлены, и при необходимости измените права на файлы и папки.

Запущено максимальное количество процессов

На тарифах виртуального хостинга REG.RU установлены ограничения на количество одновременно запущенных процессов. Например, на тарифах линейки «Эконом» установлено ограничение в 18 одновременно запущенных процессов, на тарифах «+Мощность» ― 48 процессов. Если лимит превышен, новый процесс не запускается и возникает системная ошибка 500.

Такое большое число одновременных процессов может складываться из CRON-заданий, частых подключений с помощью почтовых клиентов по протоколу IMAP, подключения по FTP или других процессов.

Чтобы проверить количество процессов, подключитесь по SSH. Выполните команду:

ps aux | grep [u]1234567 |wc -l

Вместо u1234567 укажите ваш логин хостинга: Как узнать логин хостинга.

Чтобы посмотреть, какие процессы запущены, введите команду:

Вместо u1234567 укажите логин услуги хостинга.

Командная строка отобразит запущенные процессы:

Код ошибки 500

Где:

• u1234567 — логин услуги хостинга,
• 40522 — PID процесса,
• S — приоритет процесса,
• /usr/libexec/sftp-server — название процесса.

Процесс можно завершить командой kill, например:

Вместо 40522 укажите PID процесса.

Чтобы решить проблему, вы также можете:

• увеличить интервал запуска заданий CRON,
• ограничить количество IMAP-соединений в настройках почтового клиента. Подробнее в статье Ограничение IMAP-соединений,
• проанализировать запущенные процессы самостоятельно или обратившись за помощью к разработчикам сайта.

Если вам не удалось самостоятельно устранить ошибку 500, обратитесь в техподдержку.

Скрипты работают слишком медленно

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

У пользователей VPS есть возможность увеличить максимальное использование оперативной памяти на процесс, но лучше делать скрипты меньшего размера.

Ошибка 500 на сайте, созданном на WordPress

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

Для начала проверьте, нужно ли обновить плагины. Часто устаревшие плагины перестают работать и вызывают проблемы работы сайта. Если все плагины обновлены, но 500 Internal Server Error остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.

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

Ошибка с кодом 500 выдается в том случае, когда причину сбоя нельзя отнести ни к какой другой категории ошибок (502, 503 и т. д.). По сути она означает «что-то произошло, а что — непонятно». В сообщении об ошибке 500, которое выдается на странице браузера, стандартно также нет сведений о ее причинах.

Как же без наличия информации определить и исправить ошибку? На практике чаще всего она вызывается сбоями в одном из основных компонентов сайта:

• в правах доступа к файлам и каталогам;
• в файле .htaccess;
• в скриптах;
• в CMS (движке сайта).

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

Для определения причины ошибки:

• смотрим логи сервера — часто по ним можно понять, на каком этапе произошел сбой;
• если логи не добавили ясности, или вы не можете их посмотреть — перебирайте все возможные варианты, начиная с тех, которые кажутся наиболее вероятными в вашем случае. Например, если вы не трогали перед возникновением ошибки файл .htaccess, но устанавливали новые плагины на сайт, начать нужно с проверки последнего.

Некорректные права доступа

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

Рекомендуется выставлять права не выше 750 — для папок, и 640 — для исполняемых файлов.

Если вы недавно создавали новый каталог на сервере или загружали новые файлы, у них могут быть слишком широкие права доступа. Проверьте и исправьте их.

Как определить, что ошибка 500 возникла именно из-за этого?

Во-первых, посмотрите, какой вид имеет ошибка на экране браузера. Если вы видите текст «Internal Server Error» — то, скорее всего, дело именно в .htaccess. В случаях сбоев в работе скриптов или CMS текст ошибки обычно выглядит как «HTTP ERROR 500».

Во-вторых, попробуйте добавить в конец наименования файла .htaccess любые символы. Например, переименуйте его в .htaccess2233. Сервер не будет использовать переименованный файл, и сайт будет запускаться без него. Перезагрузите страницу, на которой была ошибка. Если она исчезла — значит, причина в .htaccess.

Что может быть неверным в файле и как это исправить?

Самый простой способ устранить ошибку 500 из-за .htaccess — отменить последние изменения в нем или загрузить файл из бекапа. Если это невозможно или нежелательно, проверьте эти варианты:

• наличие невидимых неразрывных пробелов (BOM). Если вы изменяли файл, используя не совсем подходящий редактор или кодировку, в него могли быть добавлены такие символы. Пересохраните файл в кодировке UTF-8 и загрузите на сервер;
• знак # не в начале строки. Этот знак ставится перед началом комментария. Некоторые пытаются добавить комментарий в .htaccess в конце строки, но последние версии Apache не поддерживают такой синтаксис, и в результате вы видите ошибку 500. Для комментария нужно выделять целую строку;
• некорректные директивы Options. В зависимости от версии серверного ПО, можно их либо полностью закомментировать, либо попробовать исправить Options All -Indexes на директиву Options -Indexes, а Options +FollowSymLinks на директиву Options +SymLinksIfOwnerMatch;
• некорректные директивы +ExecCGI, IfVersion, AddHandler, php_value, php_flag, MultiViews. Если в вашем файле встречаются такие, попробуйте поочередно их удалить (или закомментировать), проверяя, исчезла ли ошибка.

Сбои в скриптах

Ошибка 500 здесь может вызываться двумя основными причинами:

• Неверный синтаксис или права доступа скрипта.
• Слишком долгое выполнение скрипта.

В первом случае:

• включите отображение ошибок в настройках сервера (или обратитесь к техподдержке, они помогут это сделать). Тогда при перезагрузке страницы вы увидите надпись, в которой будет имя файла и конкретная строка в нем, вызывающая ошибку;
• проверьте, правильно ли вы загружали файлы скриптов через FTP , а лучше перезагрузите их правильным образом — в режиме ASCII. Хотя для некоторых FTP-клиентов, например, для FileZilla, лучше включать двоичный режим передачи: так содержимое файлов будет передано корректно и без искажений;
• проверьте права доступа к файлу скриптов — они должны быть выставлены на уровне 750 или 755.

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

Ошибки в CMS

• Довольно часто ошибка 500 возникает после установки плагинов и дополнений к CMS<. Особенно это актуально на WordPress. Сайт на этом движке, как конструктор, собирается из базы и десятков различных плагинов. При этом плагины могут конфликтовать между собой. Решение простое — отключите дополнения, которые вы недавно устанавливали, и посмотрите, исчезнет ли ошибка. Если да — дело в плагине и лучше поставить другой.
• Устаревшая версия PHP. Она может конфликтовать с новыми скриптами или плагинами. Для обновления версии обратитесь к специалисту.
• Обновление версии движка. Такие работы также лучше проводить при поддержке специалистов, которые комплексно проверят совместимость скриптов и дополнений с новой версией. Иначе можем получить конфликт и ошибку 500.

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

Что значит ошибка 500

Ошибка 500, или 500 Internal Server Error — это внутренняя серверная проблема, ее возникновение обусловлено тем, что от клиента (браузера, десктопной программы и т. п.) в сторону сервера поступает запрос, а сервер не может корректно его обработать.

В итоге возникает сообщение вида:

Популярная причина возникновения 500-й ошибки— ошибки в синтаксисе файла.htaccess. Также она появляется, если на сервере некорректно выполняются скрипты или же есть проблемы с правами доступа к файлам и папкам.

Обратите внимание, что за 500-ю ошибку (как и другие ошибки, начинающиеся с «пятерки») несут ответственность либо администраторы сервера, либо веб-разработчики. И только в исключительных случаях — пользователи.

Что не поможет, если возникла 500-я ошибка

1. Перезагрузка компьютера. В сетевой архитектуре он является клиентом, т.е. не он вызывает проблему.
2. Смена браузера. Даже если до этого Google Chrome всегда помогал, когда подводил Firefox, в этот раз он едва ли поможет. Еще и на программу просто так обидитесь!
3. Переустановка программного обеспечения. Это будет иметь призрачный шанс на успех, если только у вас установлено совсем старое ПО, которой разработчики в принудительном порядке закрыли доступ в интернет.
4. Перезагрузка роутера / перетыкание проводов. Это решение для неисправности сети в целом — и то не всегда.

Как действовать, если ошибка 500 появилась на чужом сайте

1. Выждать. Если вы не являетесь администратором ресурса, то не сможете посмотреть и изменить файл настроек, покопаться в сайте и попытаться исправить что-то там и т. п. Ждем, когда администратор решит проблему, и через некоторое время повторяем попытку открыть нужную страницу.
2. Связаться с техподдержкой. Конечно, здорово, когда за сайтом следят в режиме 24/7, но бывает и так, что администратор просто отсутствовал на месте и не знает, что сайт уже 2 часа как «лежит».

Если вам позарез нужна нужная страница, можно открыть ее сохраненную копию:

Как действовать, если ошибка 500 появилась на вашем сайте

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

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

Посмотрите, что в файле .htaccess

У всех сайтов на Apache при получении FTP-доступа можно увидеть в корневой папке файл .htaccess, содержащий все серверные настройки.

Этот файл с моего сайта выглядит следующим образом:

Чаще всего сайты могут функционировать и без него. То есть вы можете добавить в имя файла какой-то символ (например, .htaccess 1) и потом снова зайти на проблемную страницу.

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

Также в ряде случаев можно найти строку, которая начинается с Options (вы можете увидеть ее на изображении выше) и закомментировать ее с помощью символа решетки — «#». Если не помогло, комментируйте другие строки в файле, а потом по очереди снимайте «решетку» — возможно, так вы выявите ошибочную запись.

Также дело может быть в разграничении прав доступа при внесении изменений в файл. У хостера может стоять запрет на изменение содержимого файла. Надо скачать файл на свой ПК и через «Блокнот», Notepad++ или любой другой текстовый редактор изменить .htaccess и загрузить на сайт с заменой предыдущей версии файла.

Изучите лог ошибок сервера

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

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

Удалите или отключите недавно установленные плагины или компоненты

Если у вас на сайте (WordPress — ярчайший пример) установлено много плагинов, они могут вступить в конфликт и блокировать действия друг друга. Такое может привести к уже ставшей родной ошибке 500 и прочим неприятностям.

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

Оптимизируйте скрипты

Если на сайте есть исполняемые скрипты и они начали ненормально долго выполняться или требовать большее количество ресурсов, надо посмотреть их содержимое. Может быть просто банальное нагромождение кода, который нужно очистить от мусора и тем самым достичь экономии оперативной памяти и ресурсов процессора.

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

Решением будет блочное разделение скрипта с проверкой качества работы каждого блока. Вас должно насторожить, если запрашиваемые объемы памяти растут и / или к серверу поступает чересчур много вызовов.

Увеличьте объем оперативной памяти сервера

Время на пару с информационными технологиями несется вдаль, а значит и оптимизированные скрипты могут запрашивать много памяти. Если вам очень важна стабильность, надо просто выбрать более дорогой тариф, где сервер выделит вам в 2–3 раза больше памяти, чем сейчас. Также надо смотреть на опции того или иного тарифного предложения, чтобы убрать по возможности то, что вам не требуется.

Запросите поддержку

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

• Русскоязычный форум Mozilla.
• IT-форум вебмастеров и разработчиков.
• Киберфорум.
• Форум сайтостроения.

Если поддержка все же долго отвечает, можно посмотреть нужную ветку форума: найти там ответ или же задать свой вопрос.

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

Итоги. 6 рекомендаций по исправлению 500 Server Internal Error

Напомним, что пятисотая ошибка возникает на стороне сервера, т.е. проблему надо искать и устранять не на собственном ПК или ноутбуке, а на веб-сервере.

Тем не менее, вы можете попробовать сделать эти шаги, чтобы ускорить устранение ошибки:

1. Просто перезагрузите нужную страницу с помощью клавиши F5 или клавиатурного сочетания Ctrl-К. Также можно повторить ввод адреса в строку браузера (иногда одно это снимает проблему, потому что вы просто ошиблись с его содержимым).
2. Серверная ошибка может быть оперативно устранена техподдержкой сервера. Порой сбойная страница спокойно загружается уже через пять минут. Свяжитесь с представителями ресурса. Если там работают ответственные люди, они наверняка в курсе возникшей проблемы и пытаются ее решить. Если же не в курсе, вы можете стать «спасителем» и косвенно способствовать восстановлению работоспособности страницы. Если сайт весь ушел в 500-ю ошибку, можно узнать владельцев сайта через специальный сервис и попробовать написать им по электронной почте или даже позвонить.
3. Из сферы ecommerce: допустим, вы оформляете заказ на маркетплейсе, а в это время на странице появляется 500 Internal Server Error. Если не остановиться и продолжать делать заказ, очень может статься, что вы создадите и подтвердите сразу несколько заказов одного и того же товара, причем все они будут оплачены. Да, почти все площадки онлайн-торговли имеют защиту от дублирующихся транзакций, но все же нужно иметь подобное в виду и не пытаться завершить заказ, если такая ошибка возникла во время его совершения.
4. Проведите чистку браузера. Дело в том, что целевая страница может закешироваться и все время отдавать 500-ю ошибку. Конечно, проблемы со стороны сервера редко связаны с кешированием, но все же стоит воспользоваться встроенным инструментарием браузера для очистки кеша или специализированным ПО типа CCleaner или Reg Organizer.
5. Удалите все cookie-файлы. Иногда это также помогает устранить неполадки, которые связаны с 500-ой ошибкой. Это можно сделать с помощью озвученных в предыдущем пункте программ. Главное, чтобы браузер был закрыт. После этого нужно снова его открыть и заново загрузить нужную страницу.
6. Просто выждите некоторое время. Почти всегда дело не в вас, и остается просто перетерпеть неприятность. Можно также посмотреть похожие на целевую страницы, если это возможно.

Содержание:

• Что означает код ошибки 500 и почему она возникает?
• Где можно встретить ошибку 500?
• Все причины возникновения ошибки
• Что делать при появлении ошибки? 
  • Подождать
  • Сообщить администратору
• Что делать администратору при появлении ошибки? 
  • Проверить файл htaccess
  • Проверить лог ошибок
  • Проверить содержимое CGI-скриптов
  • Проверить плагины и компоненты
  • Увеличить объем оперативной памяти сервера

Что означает код ошибки 500 и почему она возникает?

Коды состояния HTTP сообщают браузеру интернет-пользователя (клиенту), успешно ли выполнен запрос (получение доступа к сайту). К примеру, если браузер получает код состояния 200, то все прошло успешно. Это сообщение не видно пользователю — вместо него появляется запрошенный контент.

С кодами состояния 400 и 500 дело обстоит иначе. Первый означает, что ошибка связана с клиентом, а второй — с сервером.

Internal Server Error 500 — общий код состояния для ошибок со стороны сервера. По этой причине невозможно сразу определить, где именно возникла проблема: известно лишь то, что сервер сообщил о ней. Когда это происходит, сайт отображает посетителям страницу с сообщением об ошибке.

Где можно встретить ошибку 500?

Поскольку эта ошибка является частью спецификации HTTP для сайтов, она может появляться в любом браузере и на любом компьютере, в том числе на мобильных устройствах.

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

• 500 Internal Server Error;
• HTTP 500 — Internal Server Error;
• Temporary Error (500);
• Internal Server Error;
• HTTP 500 Internal Error;
• 500 Error;
• HTTP Error 500;
• 500. That’s an error.

Обычно эта ошибка отображается в окне браузера, как стандартная веб-страница.

Все причины возникновения ошибки

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

Вот несколько типичных источников проблем.

• Доступ запрещен — разрешения основных файлов и папок заданы неправильно.
• Тайм-аут сеанса PHP — скрипт пытается получить доступ к внешнему ресурсу и сталкивается с задержкой.
• Некорректный код в htaccess — структура htaccess, файла для локальной настройки сервера Apache, может быть неправильной.
• Ошибка в синтаксисе и коде скриптов CGI и Perl — в этих скриптах могут встречаться неточности, в частности несогласованность путей.
• Лимит памяти PHP — процесс превышает пределы памяти и поэтому не может быть выполнен правильно.

Если сайт работает на WordPress или другой системе управления контентом, причиной ошибки может стать неисправное или несовместимое расширение. Плагины и темы — особенно от сторонних провайдеров — могут повлиять на весь сайт.

Если ошибка сохраняется в течение длительного времени, это может негативно повлиять на SEO сайта. К счастью, большинство из этих проблем можно исправить.

Что делать при появлении ошибки?

Если вы попытались открыть веб-страницу, но увидели Internal Server Error 500, можно сделать следующее.

Подождать

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

Также можно заглянуть на сайт downforeveryoneorjustme.com и вставить в поисковую строку URL-адрес страницы, на которой произошла внутренняя ошибка сервера.

Сервис сообщит, возникла ли проблема только у вас или же у всех пользователей.

Сообщить администратору

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

У большинства сайтов и сервисов есть аккаунты в социальных сетях, а на некоторых даже указаны email-адреса и номера телефона.

Что делать администратору при появлении ошибки?

Если ошибка 500 появилась на вашем сайте, попробуйте следующие способы.

Проверить файл htaccess

Загляните в файл htaccess: даже небольшая синтаксическая ошибка может вызывать внутреннюю ошибку сервера. Не менее часто случается так, что этот файл неправильно отформатирован. Его нужно создавать в формате ASCII или ANSI, а не в Unicode. Следовательно, писать его следует в текстовом редакторе, например в Notepad, Notepad++ и Sublime Text, а не в Microsoft Word.

Чтобы проверить, является ли файл htaccess причиной ошибки, можно временно переименовать его и перезагрузить сайт. После этого сервер не будет обращаться к htaccess при загрузке страницы. Если сообщение об ошибке больше не появляется, значит стоит исправить этот файл или создать новый.

Проверить лог ошибок

Загляните в лог-файл, например для серверов Linux его можно найти по адресу /var/log/httpd/error_log. Попробуйте перезагрузить сайт, чтобы воспроизвести код ошибки 500, и посмотреть, как создается лог-файл. Это поможет быстро найти источник проблемы.

Проверить содержимое CGI-скриптов

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

• read (r) — чтение;
• write (w) — запись;
• execute (x) — выполнение.

Эти разрешения можно предоставлять трем типам пользователей:

• владельцу файла;
• группе пользователей;
• все остальным.

Права указываются либо с помощью сокращений r, w и x, либо с помощью числовых значений: 4 — для чтения, 2 — для записи и 1 — для выполнения. Они добавляются для каждого типа пользователей и идут один за другим: rwxr-xr-x (rwx — для владельца, r-x — для группы и r-x — для всех остальных) или 755.

По умолчанию должна быть установлена конфигурация 755. Если разрешения предоставляются иначе, может возникнуть ошибка. Эту настройку можно изменить с помощью команды: chmod 755 filename.

Если проблема не решится, можно также провести тестирование, предоставив все права для каждой группы: chmod 777 filename. Однако к этой настройке следует прибегать только для определения проблемы — если любой пользователь сможет переписывать файл, безопасность сайта окажется под угрозой.

Проверить плагины и компоненты

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

И напротив, если вы недавно обновили ПО, текущие плагины и темы могут оказаться несовместимы с обновлением. Деактивация дополнений по порядку — лучший способ найти основную причину проблемы.

Увеличить объем оперативной памяти сервера

Лимит памяти определяет, какой ее объем может задействовать процесс. Если какой-либо процесс требует больше памяти, чем доступно, может возникать ошибка 500.

Чтобы это исправить, можно временно увеличить лимит памяти. Для этого добавьте в php.ini команду, подобную этой: memory_limit = 512M. Этот пример устанавливает лимит на 512 МБ.

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

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

В статье использовались материалы следующих источников:

Blog.hubspot.com 

Ionos.com

Businessinsider.com

Lifewire.com

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

В ожидании комбинаторного взрыва

Я работаю в команде сервиса расписания занятий, который оркестрирует весь процесс подбора преподавателя в Skyeng. Когда новый клиент хочет найти учителя, нам приходит запрос: «ID ученика такой-то хочет заниматься с такого-то числа и в такое-то время». Чтобы подобрать преподавателя, мы идем в сервисы других команд:

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

На самом деле, сервисов больше, но даже на этом масштабе можно отследить проблему. Каждый сервис пишет своя команда: и ее разработчики возвращают ошибки, как придумали.

Гипотетическая ситуация, когда все сервисы упали сразу, может обернуться такими ответами.

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

Бывает и такое — бизнес приходит и просит «А добавьте тут…» Допустим, у нас есть форма ввода данных, в ней 10 полей, мы валидируем девять, а десятое — это комментарий, он опционален. В один день нас просят добавить валидацию на комментарий. Фронт говорит: «Если придет такой-то код, я у себя доработаю». Ты пишешь новую обработку: и вот на 10 ошибок у фронта появляется 10 обработчиков, а еще у тебя есть разные вариации if-ов, else-ов и т.д.

При этом сами ошибки возникают редко — и это тоже проблема.

При взаимодействии между сервисами мы используем REST, а он как таковой не регламентирует нам форматы, кроме того, что основан на HTTP.

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

Давайте попробуем решить эту проблему

Мы c командой посмотрели обсуждения в комьюнити, посмотрели ролики на ютубе, статьи на хабре (вот интересный хабра-холивар про 200-й ответ). Похоливарили внутри. Пришли к выводу, что серебряной пули не существует… и пошли своим путем. Ввели единый формат, при котором у нас есть:

1. Поле «data» для полезной нагрузки — скажем, вот так может выглядеть успешный ответ:

{
    "data": [
        {
            "field1": 1
        },
        {
            "field2": 2
        }
    ],
    "errors": null
}

2. И поле «errors» для ошибок.

...
"data": null,
"errors": [
    {
        "property": null,
        "error": {
            "message": "The selected time is alr...",
            "code": "selected_time_already_taken"
        }
    }
]
…

Поля data и errors в ответе не могут быть заполнены одновременно.

У нас большое разнообразие ошибок, поэтому на каждую вариацию мы добавили свои правила.

Ошибки бизнес-логики возвращают код 200 и список ошибок в поле errors. Мы не должны падать, например, если у преподавателя превышено количество учеников, которых он может вести. Поэтому решили отображать на фронт полезную ошибку.

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

• Непредвиденные ошибки: где-то что-то забыли, линтер не допроверил — всякое бывает.
• Инфраструктурные ошибки — например, ошибки Redis Cluster, ошибка связанности или если приложение не дождалось чего-нибудь другого. Мы понимаем, что у сервиса что-то произошло в эту секунду, и можем отреагировать с помощью retry. Такие ошибки удобно обрабатывать с помощью воркера, который периодически ходит по сервисам и опрашивает их: прошел, собрал метрики, хоп — что-то отвалилось, сделали retry.
• Ошибки валидации входных данных. Они вылазят где-то на тестингах, на dev-режиме, — и должны быть максимально полезными для разработчика. Мы используем Symfony serializer и validator, чтобы маппить все, что пришло на вход: чтобы не просто узнать, что Error validation, а понять, что именно не так, мы выделили отдельный класс ошибок, которые выдаются массивом.

Пример ошибок, которые используем

Первое, что нам нужно четко понимать, — у нас произошла, скажем, ошибка валидации или ошибка инфраструктуры? Нужно как-то разделять это на уровне кода — и не бесконечными if в бизнес-логике, а именно на уровне инструмента языка.

Мы создали иерархию Exception. Например, делаем базовый класс ValidationException и от него наследуем всё, что зависит от валидации. Это может быть TeacherValidationException. А у него свои наследники — NicknameException, AgeException и так далее.

Дальше делаем Exception, который хранит подробную информацию о бизнес-ошибке. Бывают ситуации, когда нам важно понимать, на каком слое что-то пошло не так. Тогда каждого слоя мы получаем свои Exception: есть API-репозиторий с APIRepositoryException, выше идет сервис, у него есть ServiceException, потом идёт Exception контроллера и т.д.

Остается сделать единую точку выхода из приложения, которая позволит отлавливать все исключения и выдавать код формате с data и errors. Это просто — сейчас так или иначе все фреймворки позволяют отлавливать Exception ивентами.

Вот как это выглядит на практике:

class ValidationException extends Exception
interface HttpExceptionInterface extends Throwable

ValidationException — бросаем, если Symfony validator собрал что-то, что не позволяет нам продолжить дальше. Здесь же есть HttpExceptionInterface, который кидает Guzzle, дабы мы понимали, какой ответ http, какой response, какие headers и так далее нам пришли.

class SomeServiceException extends Exception

SomeServiceException — у каждого сервиса есть FeaturesException или какой-нибудь ещё Exception, которые позволяют нам пробрасывать информацию между слоями приложения. Мы можем понять, что у нас произошла бизнес-ошибка, и вывести ее на фронт, либо подавить и отдать ответ о том, что мы ответим позже. Это дает вариативность в нашей логике.

interface ConventionalResponseExceptionInterface extends Throwable
{
    public function getConventionalCode(): string;
    public function getProperty(): ?string;
}

ConventionalResponseExceptionInterface — есть интерфейс бизнес-ошибки, фронту нужно получить информацию и вывести текст. Мы на бэкенде рулим тем, что увидит пользователь. В поле Property у нас может быть запись teacher — то есть, что-то произошло на стороне учителя. А ConventionalCode — это какой это уникальный код ошибки. Допустим, это может быть «Selected time have already taken» — выбранное время уже занято. Фронт по факту пишет один обработчик на такие типы ошибок, а мы просто бросаем Exception, который наследует такой интерфейс. Он возвращает все нужные данные, а фронт добавляет в обработку ошибок этот код. Больше ничего дорабатывать не нужно.

Как внедрить на практике

Самое главное — мы не можем сказать бизнесу, что «решили всё переписать, чтобы у нас все работало». Такие вещи делаются с сохранением обратной совместимости: вы вводите API версии 2, которое теперь работает с нужным форматом, и делаете доработки на уровне middleware, либо OnKernelRequest, чтобы каждый раз не проверять, новая это апишка или старая.

Подключаем единый обработчик исключений. Так как мы используем Symfony, то просто сконфигурировали listener, который подписан на события onKernelException. По факту, он перехватывает и обрабатывает любое исключение, которое возникает в системе — при версиях PHP старше семёрки проблем не возникает.

kernel.listener.conventional:
  class: ConventionalApiExceptionListener
  tags:
   - {
      name: kernel.event_listener,
      event: kernel.exception,
      method: onKernelException
   }

Сам код listener-а очень большой, покажу интересный кусок: приходит event, он содержит в себе instance Exception-а, мы проверяем, к какому типу ошибки это относится, и в зависимости от этого формируем список наших ошибок.

switch (true) {
            case $exception instanceof ConventionalResponseExceptionInterface:
               ...
                break;
            case $exception instanceof ValidationException:
               ...
                break;
            case $exception instanceof BadRequestHttpException:
               ...
                break;
            case $exception instanceof HttpExceptionInterface:
               ...
                break;
            case $exception instanceof SomeServiceException:
              ...
                break;
            default:
            ...
        }

В случае, если приходит ConventionalResponseException, мы знаем, что есть уникальный код и текст ошибки, какая-то подробная информация, — упаковываем это и выводим так, чтобы фронт тоже это понимал. А если пришёл ValidationException, он уже содержит в себе весь список ошибок, — и нам нужно просто преобразовать его в наш формат.

В логах есть три уровня приоритета — info, warning и critical. В зависимости от приоритета, ошибки попадают в разные хранилища: не критичное в файлы, критичное в Slack. Бизнес-ошибки уходят в info, всё остальное у нас либо warning, либо critical.

Отдельно скажу про 500-е. Мы проверяем environment, и на дев-стенде и тестингах позволяем себе вывести весь стэктрейс пятисотки. Если это прод, мы просто меняем ошибку на текст Internal Error и делаем проброс в Sentry, а Sentry стучится в Slack к разработчику: «Бросай все, горим».

А теперь нам нужно как-то отличить ошибки от других сервисов по нашему регламенту на нашей стороне.

К старым апишкам мы проверки, о которых расскажу, не применяем, — только к тем, о которых договорились. Допустим, у нас есть какой-то service class, который ходит на чужой API, с котором договорились.

Проверяем, корректен ли ответ: если пришел не JSON — сразу бросаем Exception.

try {
    $decodedResponse = json_decode($contents, true, 512, JSON_THROW_ON_ERROR);
} catch (Throwable $exception) {
   return false;
}

Также проверяем HTTP-статусы: есть 4 варианта, о которых мы договорились, что это корректная ситуация.

$isHttpStatusOk = in_array(
    $code,
    [
           Response::HTTP_OK,
           Response::HTTP_CREATED,
           Response::HTTP_ACCEPTED,
           Response::HTTP_NO_CONTENT,
    ],
    true
);

if ($isHttpStatusOk === false) {
    return false;
}

Если отсутствуют ключи data или errors, — тоже считаем, что это не по регламенту. В остальном — главное, чтобы ошибок не было: если в поле errors не пришло ошибок, значит все ок.

if (!array_key_exists('errors', $decodedResponse)
    ||
    !array_key_exists('data', $decodedResponse)
) {
    return false;
}
return $decodedResponse['errors'] === null;

Положив этот код в trait, мы используем его в фасадах нескольких API-репозиториев: и теперь нам не нужно добавлять новый обработчик на каждый чих, а затем тыкать все апишки — упадут или нет.

В каких случаях подход дает выгоду, в чем минусы, как поддерживать

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

Но есть нюансы, которые мы уже увидели на практике:

• Подход требует ответственного отношения от старших разработчиков и тимлидов: мы должны поддерживать при разработке единый формат. В каждом код-ревью нужно вникать и понимать, тот ли тип Exception-а вернулся, если что — создать новый, назвать его корректно, наследовать его от нужного типа ошибки. А когда регламент поменяется (его придется менять), потому что у вас появилась новая договоренность с другими командами, нужно не полениться сходить к соседям и сделать pull request.
• Регламент усложнит онбординг новичков: но зато когда человек вник, увидев ошибку в логах, он будет четко понимать, что произошло и куда бежать.

Но несмотря на эти трудности — мы довольны. Экономим время при обнаружении ошибки и добавление новых однотипных ошибок. А как устроено у вас?