You may use the following function to send a status change:
function header_status($statusCode) {
static $status_codes = null;
if ($status_codes === null) {
$status_codes = array (
100 => 'Continue',
101 => 'Switching Protocols',
102 => 'Processing',
200 => 'OK',
201 => 'Created',
202 => 'Accepted',
203 => 'Non-Authoritative Information',
204 => 'No Content',
205 => 'Reset Content',
206 => 'Partial Content',
207 => 'Multi-Status',
300 => 'Multiple Choices',
301 => 'Moved Permanently',
302 => 'Found',
303 => 'See Other',
304 => 'Not Modified',
305 => 'Use Proxy',
307 => 'Temporary Redirect',
400 => 'Bad Request',
401 => 'Unauthorized',
402 => 'Payment Required',
403 => 'Forbidden',
404 => 'Not Found',
405 => 'Method Not Allowed',
406 => 'Not Acceptable',
407 => 'Proxy Authentication Required',
408 => 'Request Timeout',
409 => 'Conflict',
410 => 'Gone',
411 => 'Length Required',
412 => 'Precondition Failed',
413 => 'Request Entity Too Large',
414 => 'Request-URI Too Long',
415 => 'Unsupported Media Type',
416 => 'Requested Range Not Satisfiable',
417 => 'Expectation Failed',
422 => 'Unprocessable Entity',
423 => 'Locked',
424 => 'Failed Dependency',
426 => 'Upgrade Required',
500 => 'Internal Server Error',
501 => 'Not Implemented',
502 => 'Bad Gateway',
503 => 'Service Unavailable',
504 => 'Gateway Timeout',
505 => 'HTTP Version Not Supported',
506 => 'Variant Also Negotiates',
507 => 'Insufficient Storage',
509 => 'Bandwidth Limit Exceeded',
510 => 'Not Extended'
);
}
if ($status_codes[$statusCode] !== null) {
$status_string = $statusCode . ' ' . $status_codes[$statusCode];
header($_SERVER['SERVER_PROTOCOL'] . ' ' . $status_string, true, $statusCode);
}
}
You may use it as such:
<?php
header_status(500);
if (that_happened) {
die("that happened")
}
if (something_else_happened) {
die("something else happened")
}
update_database();
header_status(200);
but when I encounter a 500 Internal Server Error, it gives the default Internal Server Error
The problem is that custom 500 error documents defined «late» in .htaccess simply don’t get triggered for the majority of server errors — which is what’s likely happening here. As Aakash has already quoted, this may come under the realm of a «malformed request». If you check your error log it should state: «core:error».
You stand a better chance of the custom 500 error document being served if it is defined «early» in the main server config (or VirtualHost container).
In fact, it is a bit tricky to simulate a real error that will trigger the custom 500 error document defined in .htaccess.
However, you can manually trigger a 500 error, which will call your custom error handler with something like the following:
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^ - [R=500]
The check against the REDIRECT_STATUS env var ensures that the internal request for the error document itself does not trigger another 500 error, but a direct request for the error document would also trigger a 500 error. This check is not necessary if you already have an exception in place for error documents.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
This does literally mean that in addition to the 500 error that resulted from the initial request, another 500 error was encountered when trying to serve the custom error document (that is called via an internal subrequest).
The custom error document itself is also processed by the Apache config/.htaccess.
Generally, exceptions need to be made for custom error documents so they can be served without additional processing.
More info: I can get it to throw 500 if I type a trailing slash on a .html page that has had the «.html» removed…
Not sure that this is really part of your question, but this 500 error is the result of a rewrite loop. Specifically:
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+)$ $1.html [L,QSA]
Request: http://example.com/test/ (with the extra slash)
In this case the %{REQUEST_FILENAME} is /path/to/test (no trailing slash), so the condition %{REQUEST_FILENAME}.html -f is true (/path/to/test.html does exist).
However, the URL-path that is captured by the RewriteRule pattern does contain the trailing slash ie. test/ — it is not the same as the REQUEST_FILENAME in this instance. So the URL gets incorrectly rewritten to test/.html.
And the rewriting starts over again from the top (because the URL has changed)… test/.html.html, test/.html.html.html, etc. (Because the REQUEST_FILENAME is always /path/to/test.)
but when I encounter a 500 Internal Server Error, it gives the default Internal Server Error
The problem is that custom 500 error documents defined «late» in .htaccess simply don’t get triggered for the majority of server errors — which is what’s likely happening here. As Aakash has already quoted, this may come under the realm of a «malformed request». If you check your error log it should state: «core:error».
You stand a better chance of the custom 500 error document being served if it is defined «early» in the main server config (or VirtualHost container).
In fact, it is a bit tricky to simulate a real error that will trigger the custom 500 error document defined in .htaccess.
However, you can manually trigger a 500 error, which will call your custom error handler with something like the following:
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^ - [R=500]
The check against the REDIRECT_STATUS env var ensures that the internal request for the error document itself does not trigger another 500 error, but a direct request for the error document would also trigger a 500 error. This check is not necessary if you already have an exception in place for error documents.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
This does literally mean that in addition to the 500 error that resulted from the initial request, another 500 error was encountered when trying to serve the custom error document (that is called via an internal subrequest).
The custom error document itself is also processed by the Apache config/.htaccess.
Generally, exceptions need to be made for custom error documents so they can be served without additional processing.
More info: I can get it to throw 500 if I type a trailing slash on a .html page that has had the «.html» removed…
Not sure that this is really part of your question, but this 500 error is the result of a rewrite loop. Specifically:
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+)$ $1.html [L,QSA]
Request: http://example.com/test/ (with the extra slash)
In this case the %{REQUEST_FILENAME} is /path/to/test (no trailing slash), so the condition %{REQUEST_FILENAME}.html -f is true (/path/to/test.html does exist).
However, the URL-path that is captured by the RewriteRule pattern does contain the trailing slash ie. test/ — it is not the same as the REQUEST_FILENAME in this instance. So the URL gets incorrectly rewritten to test/.html.
And the rewriting starts over again from the top (because the URL has changed)… test/.html.html, test/.html.html.html, etc. (Because the REQUEST_FILENAME is always /path/to/test.)
- Предыдующая статья: Делаем собственную страницу ошибки 404
2019-12-01
Здравствуйте, уважаемый посетитель!
Сегодня в рамах рассмотрения системы обработки ошибок выполним необходимые действия по выводу пользователю сообщения о возникновении внутренней ошибки сервера Internal Server Error, соответствующей статусу HTTP 500.
Это необходимо сделать, так как никто не застрахован от возникновения подобных проблем. В таких случаях, если не предпринять соответстующих мер, пользователь в своем браузере будет видеть только лишь какой-нибудь ущербный, неполноценный вариант веб-страницы. Либо вообще пустой экран или страницу в несколько строк с непонятными для него техническими терминами.
И вот для того, чтобы упорядочить работу сайта, обеспечивая пользователя при любых ситуациях необходимой информацией, мы создадим собственную страницу 500.
А затем, для обеспечения на нее перенаправления, сформируем пользовательский обработчик фатальных ошибок PHP. Который в дальнейшем поможет нам обеспечить и другие возможности создаваемого механизма, такие как сохранение логов и отправка сообщений по email.
- Создание страницы 500
- Перехват и обработка фатальных ошибок PHP
- Буферизация вывода в PHP
- Дополнение файла .htaccess
- Проверка работы сайта при внутренней ошибке сервера
- Исходные файлы сайта
Создание страницы 500
В первую очередь создадим в корне сайта новый файл с соответствующим именем, например «page_500.php». И поместим в него код страницы, которая будет отображаться при возникновении ошибки 500. А выполним это аналогично тому, как мы это делали в предыдущей статье при создании страницы 404.
Правда, сделаем это с некоторым отличием, заключающимся в том, что в этот раз при ее формировании будем использовать только разметку HTML, исключая какое-либо использование PHP.
Ведь не логично применять фрагменты кода, которые в случае возникновения фатальной ошибки PHP могут повлиять на отправку страницы, предназначенную, как раз, для обработки таких нестандартных ситуаций.
Конечно, это не относится к применению функции header(), с помощью которой отправляется HTTP заголовок с кодом 500, соответствующий внутренней ошибки сервера (строка 2 в приведенном ниже коде).
kak-vyvesti-stranicu-oshibki-500_1
Рис.1 Файл «page_500.php» с HTML-кодом страницы 500
Как видно, данный вариант по структуре полностью соответствует предыдущей странице 404, но выполнен на чистом HTML. Причем все общие блоки: шапка, меню, основное содержание и футер включены непосредственно, без применения подключающих инструкций PHP.
Что касается оформления, то в данном случае этого не требуется, так HTML-код страницы мало чем отличается от предыдущей. И как следствие, все необходимые свойства уже ранее назначены и добавлены в таблицу стилей CSS.
И в этом можно убедиться, если сейчас открыть созданную страницу через адресную строку браузера, добавив к доменному имени ее адрес /page_500.php. Как и в предыдущем случае в начале сделаем это в обычном, десктопном варианте пользовательского устройства.
Рис.2 Вид созданной страницы 500
А теперь посмотрим как это будет выглядеть при малом разрешении экрана в одно колоночном исполнении.
Рис.3 Вид страницы 500 при малом разрешении экрана
Как видно, полученная страница по форме схожа с предыдущей 404. За исключением содержания, отражающего теперь информацию о возникновении внутренней ошибки сервера, соответствующей статусу 500 протокола HTTP.
Таким образом необходимая страница создана. И теперь осталось только обеспечить на нее перенаправление.
Перехват и обработка фатальных ошибок PHP
Как ранее отмечалось, внутренняя ошибка сервера наиболее часто возникает в следствии фатальных ошибок PHP. Причем такие случаи обычно сопровождаются остановкой скрипта. Отчего идентифицировать такую ошибку с помощью того же самого скрипта не получится. Так как в этом случае выполнение в нем каких-либо последующих действий не представляется возможным.
Как вариант решения этой проблемы — применение встроенной функции обратного вызова register_shutdown_function(), предназначенной для регистрации специальной пользовательской функции, не связанной с работой скрипта. И, следовательно, способной выполнить дальнейшие преобразования, несмотря на то, что сам скрипт остановлен.
И таким образом, в случае возникновения фатальной ошибки управление передается этой зарегистрированной функции, являющейся в данном случае обработчиком.
Как может выглядеть регистрация пользовательской функции и перехват в ней последней ошибки, остановившей работу скрипта, показано в следующем фрагменте PHP-кода.
-
//—-Перехват и обработка фатальных ошибок PHP—-
-
function fatal_php(){ //Пользовательская функция
-
$error = error_get_last(); //Получение информации о последней произошедшей ошибке
-
if ($error !== NULL && in_array($error[‘type’], array(E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR))){ //Если ошибка произошла и ее тип соответствует фатальной ошибке
-
$domen = ‘http://’.$_SERVER[‘SERVER_NAME’]; //Домен сайта
-
header(«Location: $domen/page_500.php»); //Редирект на страницу 500
-
exit; //Прекращение выполнения текущего скрипта
-
}
-
}
-
register_shutdown_function(‘fatal_php’); //Регистрация пользовательской функции обработчика фатальных ошибок PHP
-
?>
Рис.4 Перехват и обработка фатальных ошибок PHP
Здесь все строки кода сопровождаются комментариями, поэтому подробно описывать каждую из них, нет смысла.
Можно лишь отметить, что регистрация пользовательской функции выполняется, как ранее было отмечено, с помощью register_shutdown_function(), расположенной в строке 11.
А сама функция обработчика с именем fatal_php() (поз.3÷10) в начале возвращает ассоциативный массив с описанием последней произошедшей ошибки (функция error_get_last() поз.4). А затем в случае, если выявленная ошибка относится к одному из четырех необходимых типов (E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR), то с помощью функции отправки HTTP-заголовка header() (поз.7) выполняется редирект по указанному аргументом «Location» адресу, соответствующему странице 500.
В случае, если фатальная ошибка PHP возникает в процессе формирования тела страницы при отправленном HTTP-заголовке, то при установках по умолчанию, в соответствии с протоколом HTTP должна возникнуть ошибка Cannot modify header information — headers already sent by (), означающая невозможность изменения заголовка после его отправки. Более подробно об этом и о том, как решить эту проблему мы посмотрим в следующем разделе статьи.
Таким образом при использовании созданной пользовательской функции, в случае, если из-за какой-то критической ошибки PHP-скрипт остановлен, обработчик ее обнаружит и выполнит необходимые действия по ее идентификации и дальнейшей обработке.
В данном случае обработка заключается всего лишь в выполнении редиректа на страницу 500. Но в дальнейшем, когда мы перейдем к сохранению логов и оправке сообщений по email, то здесь же будем использовать и другие, необходимые для этого преобразования.
И последнее, на что необходимо обратить внимание, функция обработчика должна быть расположена в самом начале кода шаблона главной страницы файла index.php. Иными словами, чтобы все остальные PHP-инструкции, используемые при формировании веб-страницы, выполнялись только после ее регистрации. В противном случае при остановке скрипта обработчик не будет вызван и, соответственно, не сможет выполнить свою задачу.
Буферизация вывода в PHP
В созданном обработчике фатальных ошибок PHP (рис.2) с помощью функции HTTP-заголовка header() (поз.7) предусматривается редирект на страницу 500.
Однако, здесь следует учесть одно обстоятельство, а именно: в случае редиректа, выполняемого в момент формирования тела веб-страницы, уже после отправки HTTP-заголовка, непременно должна последовать ошибка Cannot modify header information — headers already sent by ().
Обусловлено это следующим. По умолчанию сервер отправляет в браузер данные веб-страницы по мере их готовности, в процессе выполнения PHP-скрипта. При этом в соответствии с протоколом HTTP, сервер в ответ на запрос должен в первую очередь отправить служебные заголовки, а уж только потом код самого тела страницы. И протоколом HTTP не допускается ситуация, когда в момент передачи тела страницы производится повторная оправка HTTP-заголовка. О чем и говорит описание вышеуказанной ошибки.
В подтверждение этому можно проверить работу созданного обработчика по состоянию на данный момент, с заведомо внесенной критической ошибкой PHP.
На скриншоте показан вариант вывода страницы «Получить скидку», у которой в код PHP файла poluchit-skidku.php специально внесена синтаксическая ошибка.
Рис.5 Ошибка при изменении заголовка после его отправки
Как видно, здесь в области основного содержания, при обнаружении в ней фатальной ошибки Parse error и остановки скрипта, присутствует также и ошибка Cannot modify header information — headers already sent by (), означающая невозможность изменения заголовка в момент передачи кода данного блока веб-страницы.
А для того, чтобы решить эту проблему и иметь возможность изменять в любой момент HTTP-заголовки, применяется, так называемая буферизация вывода в PHP.
Суть ее в том, что в этом случае при выполнении PHP, сервер не оправляет страницу по мере ее готовности, а складывает полученный код в определенный буфер, параллельно формируя HTTP-заголовки, которые в обычном режиме не допускается оправлять в момент передачи тела страницы.
И только после того, как скрипт выполнит все заложенные в него операции, то всё, что в конечном итоге оказалось в буфере, разом отправляется в браузер пользователя в правильном порядке, как это определенно протоколом HTTP — сначала заголовки, а уж потом страница, сформированная скриптом.
В PHP существуют несколько функций, предназначенных для работы с буфером. Но для данной задачи мы будем использовать только две из них ob_start() — для включения буферизации вывода и ob_end_flush() — для отправки данных из буфера и отключения буферизации.
Схематично для генерируемой HTML-страницы это можно представить следующим образом.
kak-vyvesti-stranicu-oshibki-500_2
Рис.6 Буферизация вывода в PHP
А ниже показано, как в итоге будет выглядеть код шаблона главной страницы в файле index.php после дополнения его обработчиком фатальных ошибок PHP и элементами буферизации вывода PHP (светлым фоном обозначены дополнительные фрагмента кода).
kak-vyvesti-stranicu-oshibki-500_3
Рис.7 Файл index.php с обработчиком ошибок и буферизацией вывода
Следует отметить, что для оптимизации файла index.php, ранее размещенный в начале шаблона главной страницы PHP-код, предназначенный для получения данных при формировании динамической страницы, перенесен в файл start.php, который подключается соответствующей инструкцией в строке 13.
Таким образом буферизацию вывода HTML-страницы, генерированной скриптом PHP, мы выполнили. Однако, для полноценной работы сайта при обработке ошибки 500 необходимо сделать еще одно небольшое дополнение, которые мы сейчас и рассмотрим.
Дополнение файла .htaccess
Приведенные выше преобразования предназначены для выполнения редиректа на страницу 500 в случае прерывания работы скрипта при фатальных ошибках PHP.
Но для того, чтобы это происходило и в других случаях внутренней ошибки сервера, необходимо в файл .htaccess добавить директиву ErrorDocument, аналогичную той, которую мы использовали ранее при редиректе на страницу 404. Только теперь в ней должен быть указан соответствующий адрес /page_500.php.
А заодно, в целях безопасности полезно будет вообще отключить отображение системных сообщений на экране пользователя. Так как теперь возникающие по каким-либо причинам ошибки будут фиксироваться собственным механизмом обработки ошибок и нет необходимости их выводить в браузер. Тем более, что в определенных случаях такая излишняя для пользователя информация может быть использована недоброжелателями в качестве уязвимости сайта.
В итоге файл .htaccess следует дополнить следующими директивами, которые обеспечат выполнение вышеперечисленных действий.
-
ErrorDocument 500 /page_500.php
-
php_flag display_errors 0
Рис.8 Редирект 500 в файле .htaccess
Таким образом мы сделали все необходимые преобразования для вывода страницы 500. И теперь можно проверить, как это в реальности будет работать.
Проверка работы сайта при внутренней ошибке сервера
Проверку обработки внутренней ошибки сервера выполним на примере возникновения фатальной ошибки PHP, что позволит удостовериться в корректной работе, как созданного обработчики фатальных ошибок, так и процесса буферизации вывода генерируемой страницы и редиректа на страницу 500.
Для этого в код PHP временно внесем ту же самую синтаксическую ошибку, которую ранее мы делали на промежуточном этапе (рис.5). И посмотрим, как теперь будет обработана такая ситуация.
Рис.9 Вывод страницы 500 при фатальной ошибке PHP
Как видно, теперь критическая ошибка отработана должным образом, с перенаправлением на страницу ошибки 500.
При желании, можно проверить работу сайта и при других искусственно созданных фатальных ошибках. И во всех случаях результат должен быть один — отображение собственной страницы 500. Что в итоге и требовалось получить.
В следующей статье мы создадим механизм обработки не фатальных ошибок PHP, где с помощью собственного обработчика будет обеспечиваться их перехват и сохранение сообщений в соответствующем журнале.
.
Исходные файлы сайта
Исходные файлы сайта с обновлениями, которые были сделаны в данной статье, можно скачать из прилагаемых дополнительных материалов:
- Файлы каталога www
- Таблицы базы данных MySQL
Дополнительные материалы бесплатно предоставляются только зарегистрированным пользователям.
Для скачивания исходных файлов необходимо авторизоваться под своим аккаунтом через соответствующую форму.
Для тех кто не зарегистрирован, можно это сделать на вкладке Регистрация.
С уважением,
- Следующая сатья: Перехват и обработка не фатальных ошибок PHP
Если у Вас возникли вопросы, или есть какие-либо пожелания по представлению материала, либо заметили какие-нибудь ошибки, а быть может просто хотите выразить свое мнение, пожалуйста, оставьте свои комментарии. Такая обратная связь очень важна для возможности учета мнения посетителей.
Буду Вам за это очень признателен!
В статье мы расскажем, как исправить ошибку (код состояния) 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 остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.
Как отключить плагин в WordPress
- 1.
-
2.
Перейдите во вкладку «Плагины» ― «Установленные».
-
3.
Нажмите Деактивировать у плагина, который, как вам кажется, повлиял на работу сайта:
Если все ваши действия не решили проблему или вы не уверены в своих технических знаниях, обратитесь к службе технической поддержки. Сообщите время обнаружения проблемы и опишите все действия, которые вы предприняли перед обращением. Специалисты сделают детальную проверку настроек вашего сайта и при необходимости обратятся к администраторам сервера на стороне хостинг-провайдера.
#1
IgorZip
-
- Members
-
- 8 сообщений
Новый участник
- ФИО:Igor Zip
Отправлено 28 января 2019 — 14:19
Есть поле для вставки ссылки на картинку. После вставки ссылки она парсится и подтягивается изображение в соседнее поле. Как мне можно вызвать 500 ошибку связаную с этим полем. Пробовал много-много символов вводить- ничего
-
0
- Наверх
#2
baruk
baruk
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 28 января 2019 — 14:42
Интересно, с чего вы решили, что это вообще возможно? Если сервис написан нормально, то не получится =)
А так вариантов масса, считай любая негативная проверка может дать подобное поведение.
Например, битая ссылка, совсем не ссылка, слишком большое изображение (допустим, файлик на пару гигов), нулевой размер, неправильное расширение (например, ссыль на jpeg, хотя файл на самом деле архив) и т.д.
Если есть доступ к коду, то можно посмотреть, какие проверки не предусмотрены в нем и при каких условиях выкинется необработанное исключение
-
0
- Наверх
#3
IgorZip
IgorZip
-
- Members
-
- 8 сообщений
Новый участник
- ФИО:Igor Zip
Отправлено 28 января 2019 — 14:57
Интересно, с чего вы решили, что это вообще возможно? Если сервис написан нормально, то не получится =)
А так вариантов масса, считай любая негативная проверка может дать подобное поведение.
Например, битая ссылка, совсем не ссылка, слишком большое изображение (допустим, файлик на пару гигов), нулевой размер, неправильное расширение (например, ссыль на jpeg, хотя файл на самом деле архив) и т.д.
Если есть доступ к коду, то можно посмотреть, какие проверки не предусмотрены в нем и при каких условиях выкинется необработанное исключение
Спасибо)
-
0
- Наверх
#4
Spock
Отправлено 28 января 2019 — 15:50
делается легко
устанавливаем перехватывающий прокси типа ZAP
и перехватываем ответ сервера и меняем код ответа на 500 и тело ответа меняем на что угодно, например «123»
-
0
- Наверх
#5
baruk
baruk
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 28 января 2019 — 19:07
перехватываем ответ сервера и меняем код ответа на 500 и тело ответа меняем на что угодно, например «123»
Не опасно ли так, не зная как реально возвращаются 500ые? Подсунем стандартный ответ веб-сервера, а реально в ответ прилетит какой-нить json, со структурой, отличной от всего что видели.
И вот он, потенциально пропущенный дефект
-
0
- Наверх
#6
Spock
Отправлено 28 января 2019 — 19:17
Не опасно ли так, не зная как реально возвращаются 500ые? Подсунем стандартный ответ веб-сервера, а реально в ответ прилетит какой-нить json, со структурой, отличной от всего что видели.
И вот он, потенциально пропущенный дефект
почитайте выше, я написал что в тело подставляем «что угодно», например «123» — вот вам и «прилетает» структура которую мы не ожидаем
-
0
- Наверх
#7
baruk
baruk
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 28 января 2019 — 19:40
почитайте выше, я написал что в тело подставляем «что угодно», например «123» — вот вам и «прилетает» структура которую мы не ожидаем
Именно. А зачем нам такая структура? Ну начнут разрабы ловить ошибки при попадании «чего угодно», а прилетит реальная 500 и тут все упадет.
Я к тому, что при подмене данных нужно использовать правильную структуру ответа, иначе, как мне кажется, бессмысленно.
-
0
- Наверх
#8
Spock
Отправлено 28 января 2019 — 19:59
Именно. А зачем нам такая структура? Ну начнут разрабы ловить ошибки при попадании «чего угодно», а прилетит реальная 500 и тут все упадет.
Я к тому, что при подмене данных нужно использовать правильную структуру ответа, иначе, как мне кажется, бессмысленно.
смотрите как подменять надо чтобы «все ловилось»:
кейс 1: подмена ответа на «ожидаемую» ошибку
подменяем хттп-код на например 403 либо что у вас там считается ошибкой, тело ответа подменяем на ошибку в вашем формате, например джейсон, с текстом например «баланс ниже нуля». смотрим система распарсила ошибку и отобразила в интерфейсе текст «баланс ниже нуля»
кейс 2: подмена ответа на «неожидаемую» ошибку
подменяем хтпп-код на например 500 и тело на что-то не по вашей структуре например «123». Смотрим что обработчик отобразил какую-то общую ошибку типа «Something went wrong»
-
0
- Наверх
#9
baruk
baruk
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 28 января 2019 — 20:13
В таком виде согласен с вами.
-
0
- Наверх
#10
77juli77
77juli77
-
- Members
-
- 1 сообщений
Новый участник
Отправлено 21 мая 2021 — 15:20
Здравствуйте — можно но ли получить ошибку 500 или другую ошибку ( симитировать) — банк требует скриншот, а я его не сделала — не могла зайти вовремя списали 60 000 которые копились год. Буду признательна и готова заплатить если можно что то сделать — спасибо
-
0
- Наверх
#11
Snap
Snap
- ФИО:Роман
- Город:Москва
Отправлено 30 августа 2021 — 08:04
Здравствуйте — можно но ли получить ошибку 500 или другую ошибку ( симитировать) — банк требует скриншот, а я его не сделала — не могла зайти вовремя списали 60 000 которые копились год. Буду признательна и готова заплатить если можно что то сделать — спасибо
Нет. Если банк честный и у них есть лог ошибок (например, на моем проекте есть), то если вы назовете им свой IP (правда IP у вас уже мог измениться) и точное время, они смогут посмотреть, была ли ошибка.
Еще, если не ошибаюсь, сейчас провайдер обязан хранить историю посещений сайтов полгода, можно попробовать обратиться к нему.
-
0
- Наверх
|
11 / 11 / 5 Регистрация: 27.09.2013 Сообщений: 278 |
|
|
1 |
|
|
01.07.2014, 16:38. Показов 5060. Ответов 6
Подскажите пожалуйста, как можно гарантированно получать ошибку 500. Каким скриптом это можно сделать? Это необходимо для тестирования.
__________________
0 |
|
Programming Эксперт 94731 / 64177 / 26122 Регистрация: 12.04.2006 Сообщений: 116,782 |
01.07.2014, 16:38 |
|
Ответы с готовыми решениями:
Подскажите как вызвать ошибку 500? Сайт надо убить до… Ошибка HTTP 500 Joomla — ошибка 500 в администраторе Ошибка 500 и время выполнения скрипта 6 |
Ошибка 500|
pav1uxa 1943 / 1768 / 825 Регистрация: 23.01.2014 Сообщений: 6,230 |
||||
|
01.07.2014, 17:28 |
2 |
|||
|
Dzvene,
1 |
|
Dzvene 11 / 11 / 5 Регистрация: 27.09.2013 Сообщений: 278 |
||||||||
|
01.07.2014, 17:54 [ТС] |
3 |
|||||||
В браузере выходит сообщение: Warning: Cannot modify header information — headers already sent by (output started at Z:homelocalhostwwwtestindex.php:8) in Z:homelocalhostwwwtestindex.php on line 9 Test Добавлено через 6 минут
Сделал так, сообщение не выходит, но и ошибки нет, что может быть не так?
0 |
|
alexsamos33 669 / 640 / 335 Регистрация: 26.04.2014 Сообщений: 2,121 |
||||
|
01.07.2014, 18:23 |
4 |
|||
|
Решение Я бы взял файл .htaccess Добавлено через 3 минуты
1 |
|
11 / 11 / 5 Регистрация: 27.09.2013 Сообщений: 278 |
|
|
01.07.2014, 18:42 [ТС] |
5 |
|
Да, получилось, спасибо
0 |
|
25 / 25 / 8 Регистрация: 18.09.2011 Сообщений: 130 |
|
|
01.07.2014, 18:57 |
6 |
|
Сделал так, сообщение не выходит, но и ошибки нет, что может быть не так? А какое сообщение вы хотите увидеть? И как смотрите ошибку? 500 — это, честно говоря, не ошибка PHP или Apache, а код состояния HTTP.
1 |
|
11 / 11 / 5 Регистрация: 27.09.2013 Сообщений: 278 |
|
|
02.07.2014, 12:17 [ТС] |
7 |
|
А какое сообщение вы хотите увидеть? И как смотрите ошибку? 500 — это, честно говоря, не ошибка PHP или Apache, а код состояния HTTP. Сообщение об ошибке сервера, получилось ваш вариант + в .htaccess (alexsamos33 ) прописал набор символов.
0 |