Как исправить ошибку ошибка в 200

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

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

Однако, в случае 301 ошибки, браузер клиента получает уведомление о том, что запрошенный URL был перемещен в новый адрес (постоянно). Такая ошибка может возникнуть при переносе вебсайта на новый домен, изменении URL адресов страниц, перемещении страниц в папки на сервере и т.д.

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

301 и 302 ошибки: в чем различия?

301 и 302 ошибки являются редиректами, которые перенаправляют пользователей на другую страницу. Но они имеют различное назначение и влияют на SEO-оптимизацию страниц.

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

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

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

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

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

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

Что такое 301-ошибка?

Код HTTP 301 «Перемещено» — это статусный код, отправляемый сервером клиенту, который запрашивает информацию о ресурсе. Когда сервер получает этот запрос, он сообщает клиенту, что страница, которую он запрашивает, была перемещена на новый адрес.

Код 301 может использоваться в следующих случаях:

• Перемещение сайта на новый домен
• Перемещение начальной страницы на новый адрес
• Удаление страницы и перенаправление трафика на новую страницу

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

Если вы хотите перенести свой сайт на новый домен или перенести страницы на новые адреса, то самый простой способ это сделать — использовать 301-код именно в контексте редиректа страницы на новое место. Однако, перед использованием этого кода необходимо убедиться в правильности исправлений.

Почему возникают ошибки 200 и 301?

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

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

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

• Ошибка 200 означает, что запрашиваемая страница успешно загружена
• Ошибка 301 сообщает, что запрашиваемая страница была перемещена на новое место
• Оба вида ошибок могут привести к проблемам при использовании сайта
• Ошибка 200 может возникнуть, когда сервер не имеет доступа к запрашиваемой странице или когда файлы на сервере были повреждены
• Ошибка 301 может возникнуть, когда страница была перемещена на новый URL, но сервер не получил параметры для перенаправления на новый адрес

Ошибка 200	Ошибка 301
— страница успешно загружена	— страница была перемещена на новое место
— файлы на сервере могут быть повреждены	— необходимо установить правильный редирект на новый URL
— сервер не имеет доступа к запрашиваемой странице	— пользователи и поисковые роботы могут не найти страницу на новом месте

Может ли сайт функционировать нормально с ошибками 200 и 301?

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

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

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

Как исправить ошибки 200 и 301?

Ошибки 200 и 301 могут возникать на сайте и могут привести к потере трафика и рейтинга в поисковых системах. Исправить их необходимо как можно скорее.

Ошибка 200:

Ошибка 200 означает успешное выполнение запроса и является нормальным ответом сервера. В некоторых случаях ошибка может быть связана с отсутствием контента на странице. Для ее исправления можно:

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

Ошибка 301:

Ошибка 301 свидетельствует о том, что запрашиваемая страница перемещена на другой адрес. Для исправления ошибки можно:

• Провести редирект со старой страницы на новую через .htaccess или другие инструменты;
• Изменить ссылки на новую страницу во всех внутренних и внешних ресурсах;
• Обновить sitemap и отправить изменения в поисковую систему;
• Проверить наличие циклических ссылок на странице и удалить их.

Исправление ошибок 200 и 301 позволит улучшить опыт пользователей и сохранить позиции сайта в поисковой выдаче.

Как отслеживать ошибки и контролировать их число на сайте?

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

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

Если Google Analytics не установлен, можно использовать специальные инструменты для мониторинга сайта. Например, можно воспользоваться сервисами проверки кода сайта, такими как Screaming Frog. В этом случае возможно получение отчетов о всех найденных ошибках и их классификациями по типам, что ориентирует в работе над их исправлением.

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

Вопрос-ответ

Что такое 200 ошибка?

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

Что такое 301 ошибки и как их исправлять?

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

Каким образом 301 ошибка влияет на SEO-оптимизацию сайта?

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

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

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

Место на диске

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

Если есть доступ к серверу по SSH, то достаточно запустить команды:

df -i

df -h

Они покажут, сколько места занято на диске в процентах. Если занято 100%, то службы сервера, например, mysql, не смогут создавать временные файлы и сайты перестанут работать. В этом случае необходимо освободить место на диске, либо увеличить его. Более подробно в этой статье:

Доступность служб

Как правило, для работы сайтов необходимо, чтобы был запущен веб-сервер и сервер БД mysql. Проверить статус служб можно через отдельный пункт ISPmanager:

Если с какой-то из служб возникла проблема, то «лампочка» не включится, и тогда необходимо будет разбираться с этой службой отдельно. Так же, в большинстве случаев, об этом скажет главная страница сайта: либо отображается код ошибки, например, 500, 502, 504, либо непосредственно сам текст с отладочной информацией, если это позволяют настройки CMS, движка, на котором написан сайт.

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

Рассмотрим вариант дальнейших действий, если на сервере установлена панель управления ISPmanager.

Просмотр логов

Первым делом следует проверить:

• не вносились ли изменения в код сайта,
• не обновлялась ли CMS и плагины,
• не была ли изменена версия PHP,
• имеются ли резервные копии, на случай, если сайт не получится «реанимировать».

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

Сайты — нужный домен — изменить:

Выводимые сайтом ошибки можно посмотреть по пути

/var/www/http-logs/имя-сайта.error.log

например, запустив команду tail, подключившись к серверу по SSH:

Необходимо убедиться, что нужные параметры PHP для выявления ошибки, такие как:

error_reporting

display_errors

display_startup_errors 

log_errors 

включены.

Проверить это можно в том же ISPmanager во вкладке:

Настройки — Настройки PHP — Расширенные настройки, выделив нужную версию. 

Либо можно добавить их непосредственно в код сайта — в главную (индексную) страницу index.php:

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

error_reporting(E_ALL);

Либо прописать в файл  .htaccess в корне сайта:

php_flag display_startup_errors on

php_flag display_errors on

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

Включение вывода ошибок и debug

Большинство CMS поддерживают вывод отладочной информации на экран, что поможет в диагностике ошибок.

Например, если WordPress не может соединиться с базой данных, он выведет такое сообщение:

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

define('WP_DEBUG', false);

define('WP_DEBUG', true);

то выводимая информация будет полнее:

И в этом примере выводимый текст достаточно ясно даёт понять, что указан неправильный пароль пользователя базы данных.

Подобный способ отладки применим для большинства CMS: дебаг можно включить в configuration.php у Joomla, .settings.php(скрытый файл с точкой перед названием) у Битрикс и так далее. Узнать, как это сделать, может помочь документация используемого движка.

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

Совместимость версий PHP

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

Parse error: syntax error, unexpected T_STRING

Либо явное сообщение, как например это делает WordPress:

Другая распространенная ошибка:

Extension ‘mysql’ is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead

Говорит о том, что вы пытаетесь запустить сайт на версии 7.0 и выше, когда он работает с более ранними версиями PHP и использует устаревшее расширение php-mysql, когда как в новых версиях используется только php-mysqli.

Отсутствие расширений PHP

Также могут отсутствовать необходимые для работы сайта расширения PHP. Пример текста ошибки:

Ioncube Loader is NOT installed at your server to run this application

или

Uncaught Error: Call to undefined function curl_init()

Это говорит об отсутствующих или выключенных расширениях PHP Ioncube или Curl соответственно.

Проверить их наличие можно через меню ISPmanager:

Настройки — Настройки PHP — Управление расширениями

Посмотреть текущую версию PHP можно через меню Сайты в строке с нужным сайтом:

Либо подложить файл info.php c содержимым в корень сайта:

<?php

phpinfo();

?>

затем перейти по адресу в браузере http://вашсайт.рф/phpinfo.php — в верхней части страницы увидете, какая версия используется сайтом:

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

Лимиты PHP

Другой «пласт» возможных ошибок — недостаточные лимиты, выставленные в настройках  PHP. Это может проявляться как на главной странице, так и на других, где например, работает «тяжелый» скрипт, требующий больше времени и ресурсов, чем ему дозволено сейчас.

Об этом скажут сообщения:

PHP Fatal error: Allowed memory size of 8388608 bytes exhausted

В этом случае необходимо увеличить параметр на лимит используемой ОЗУ для одного скрипта  memory_limit.

The process *** exceeded the timeout of 60 seconds или PHP EXECUTION TIMEOUT ERROR

Увеличиваем время ( в секундах), поменяв параметры set_time_limit и max_execution_time.

The uploaded file exceeds the upload_max_filesize directive in php.ini

Правим директивы на размер загружаемых файлов в мегабайтах: upload_max_filesize и post_max_size.

Используем strace

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

Утилита предназначена для вывода на экран или в отдельный файл системных вызовов. Грубо говоря, показывает последовательность обращений скриптов сайта друг к другу. Это помогает отловить ошибку, если выводимого дебага недостаточно или не помогает решить проблему.

Устанавливается она yum install strace на серверах Centos или apt install strace для Debian/Ubuntu.

В общем виде подойдет такой синтаксис:

strace -s999 -o /tmp/strace.txt /opt/php71/php index.php

Где:

• strace -s999— вызов команды strace с максимально подробным выводом и запись его в файл  /tmp/strace.txt
• /opt/php71/php — адрес интерпретатора PHP
• index.php — путь к вызываемому файлу.

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

Заключение

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

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

Время на прочтение
2 мин

Количество просмотров 48K

В этой трехминутной статье я хочу затронуть наболевшую тему.

Речь пойдет о статус коде HTTP 200 и ошибках в ответе.

HTTP/1.1 200 OK

{
  "error": {
    code: 2019,
    message: "Validation failed: field 'size' is invalid: the value is not a number"
  }
}

Нормально ли возвращать такой код, если возникла ошибка?

Нет? Да? Ну-ка давайте разберемся.

Случай 1. HTTP 200 и batch операция

Допустим отправляется один запрос. Запрос выполняется успешно. Возвращаем код 200. Ответ не содержит информации об ошибке. С этим случаем всё предельно просто и понятно. А что делать если требуется выполнить batch операцию?

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

Запрос выглядит примерно так:

{
  "sources": [
    {"image": "http://myserver.com/image1.jpg"},
    {"image": "http://myserver.com/image2.jpg"},
    {"video": "http://myserver.com/video.jpg"}
  ]
}

Предположим, по какой-то причине (например, кончилось место на сервере) видео загрузить не удалось. Что бы вы вернули в таком случае? 2xx или 4xx или 5xx? Сервер, отвечает примерно вот так:

HTTP/1.1 200 OK

{
  "results": [
    { "status": "ok", "id": 312 },
    { "status": "ok", "id": 313 },
    { "status": "fail", "error": "NO SPACE" }
  ]
}

Некоторые сервисы (и вполне известные) действуют также. Отвечают 200. А в ответе возвращают список команд, которые выполнить не получилось.

Случай 2. HTTP 200 и ошибки в ответе

Пришёл запрос. Запрос зафейлился. Например, мы забыли указать какое-то поле. Или дату отправили не в миллисекундах, а как строку. Тут-то точно не надо возвращать 200! Но увы и нет.

Где-то на просторах интернета я встречал проекты на github и bitbucket, которые специально предназначены для таких вот случаев. В них просто вшиты возможные варианты и шаблоны. Можно их достаточно легко встроить в свой проект и как бы быть готовым к разного рода «падениям» запросов. Но есть одно но.

В такие моменты твой код становится уродливым. Ты ему говоришь:

— Cлушай, у нас тут есть один внешний API. Он в целом нормальный. Только надо внимательно смотреть что в ответе приходит. Если там ответ содержит поле «error», то значит запрос сломался.
— Но ведь для этого же есть 4xx и 5xx! Да кто вообще так делает?!
— Тише-тише. Не надо так громко. Он может услышать. Пожалуйста, будь добрее к нему. И просто смотри не только на статус код, но и на ответ, пожалуйста.
— Ладно…

HTTP 200 — это просто статус

Ну 200 и 200. Ну не запилили. Или не успели. Или вообще не будут. Ну и что?! Написал json парсер и всё!

Как бы да, но я хочу знать почему. Забыли? Забили? Не успели? Не знали?

Возможно я что-то упускаю. Или не знаю. Хочу ваше мнение. Срочно. Всем добра и выходных на выходных.

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

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

Место на диске

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

Если есть доступ к серверу по SSH, то достаточно запустить команды:

df -i

df -h

Они покажут, сколько места занято на диске в процентах. Если занято 100%, то службы сервера, например, mysql, не смогут создавать временные файлы и сайты перестанут работать. В этом случае необходимо освободить место на диске, либо увеличить его. Более подробно в этой статье:

Что делать, когда осталось мало места на диске

Доступность служб

Как правило, для работы сайтов необходимо, чтобы был запущен веб-сервер и сервер БД mysql. Проверить статус служб можно через отдельный пункт ISPmanager:

Если с какой-то из служб возникла проблема, то «лампочка» не включится, и тогда необходимо будет разбираться с этой службой отдельно. Так же, в большинстве случаев, об этом скажет главная страница сайта: либо отображается код ошибки, например, 500, 502, 504, либо непосредственно сам текст с отладочной информацией, если это позволяют настройки CMS, движка, на котором написан сайт.

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

Рассмотрим вариант дальнейших действий, если на сервере установлена панель управления ISPmanager.

Просмотр логов

Первым делом следует проверить:

• не вносились ли изменения в код сайта,
• не обновлялась ли CMS и плагины,
• не была ли изменена версия PHP,
• имеются ли резервные копии, на случай, если сайт не получится «реанимировать».

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

Сайты — нужный домен — изменить:

Выводимые сайтом ошибки можно посмотреть по пути

/var/www/http-logs/имя-сайта.error.log

например, запустив команду tail, подключившись к серверу по SSH:

Необходимо убедиться, что нужные параметры PHP для выявления ошибки, такие как:

error_reporting

display_errors

display_startup_errors 

log_errors 

включены.

Проверить это можно в том же ISPmanager во вкладке:

Настройки — Настройки PHP — Расширенные настройки, выделив нужную версию. 

Либо можно добавить их непосредственно в код сайта — в главную (индексную) страницу index.php:

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

error_reporting(E_ALL);

Либо прописать в файл  .htaccess в корне сайта:

php_flag display_startup_errors on

php_flag display_errors on

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

Включение вывода ошибок и debug

Большинство CMS поддерживают вывод отладочной информации на экран, что поможет в диагностике ошибок.

Например, если WordPress не может соединиться с базой данных, он выведет такое сообщение:

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

define('WP_DEBUG', false);

define('WP_DEBUG', true);

то выводимая информация будет полнее:

И в этом примере выводимый текст достаточно ясно даёт понять, что указан неправильный пароль пользователя базы данных.

Подобный способ отладки применим для большинства CMS: дебаг можно включить в configuration.php у Joomla, .settings.php(скрытый файл с точкой перед названием) у Битрикс и так далее. Узнать, как это сделать, может помочь документация используемого движка.

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

Совместимость версий PHP

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

Parse error: syntax error, unexpected T_STRING

Либо явное сообщение, как например это делает WordPress:

Другая распространенная ошибка:

Extension ‘mysql’ is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead

Говорит о том, что вы пытаетесь запустить сайт на версии 7.0 и выше, когда он работает с более ранними версиями PHP и использует устаревшее расширение php-mysql, когда как в новых версиях используется только php-mysqli.

Отсутствие расширений PHP

Также могут отсутствовать необходимые для работы сайта расширения PHP. Пример текста ошибки:

Ioncube Loader is NOT installed at your server to run this application

или

Uncaught Error: Call to undefined function curl_init()

Это говорит об отсутствующих или выключенных расширениях PHP Ioncube или Curl соответственно.

Проверить их наличие можно через меню ISPmanager:

Настройки — Настройки PHP — Управление расширениями

Посмотреть текущую версию PHP можно через меню Сайты в строке с нужным сайтом:

Либо подложить файл info.php c содержимым в корень сайта:

<?php

phpinfo();

?>

затем перейти по адресу в браузере http://вашсайт.рф/phpinfo.php — в верхней части страницы увидете, какая версия используется сайтом:

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

Лимиты PHP

Другой «пласт» возможных ошибок — недостаточные лимиты, выставленные в настройках  PHP. Это может проявляться как на главной странице, так и на других, где например, работает «тяжелый» скрипт, требующий больше времени и ресурсов, чем ему дозволено сейчас.

Об этом скажут сообщения:

PHP Fatal error: Allowed memory size of 8388608 bytes exhausted

В этом случае необходимо увеличить параметр на лимит используемой ОЗУ для одного скрипта  memory_limit.

The process *** exceeded the timeout of 60 seconds или PHP EXECUTION TIMEOUT ERROR

Увеличиваем время ( в секундах), поменяв параметры set_time_limit и max_execution_time.

The uploaded file exceeds the upload_max_filesize directive in php.ini

Правим директивы на размер загружаемых файлов в мегабайтах: upload_max_filesize и post_max_size.

Используем strace

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

Утилита предназначена для вывода на экран или в отдельный файл системных вызовов. Грубо говоря, показывает последовательность обращений скриптов сайта друг к другу. Это помогает отловить ошибку, если выводимого дебага недостаточно или не помогает решить проблему.

Устанавливается она yum install strace на серверах Centos или apt install strace для Debian/Ubuntu.

В общем виде подойдет такой синтаксис:

strace -s999 -o /tmp/strace.txt /opt/php71/php index.php

Где:

• strace -s999— вызов команды strace с максимально подробным выводом и запись его в файл  /tmp/strace.txt
• /opt/php71/php — адрес интерпретатора PHP
• index.php — путь к вызываемому файлу.

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

Заключение

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

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

Как правильно написать запрос в службу технической поддержки

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

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

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

100	301	405	417	450
101	302	406	418	451
102	303	407	422	500
200	304	408	423	501
201	305	409	424	502
202	306	410	425	503
203	307	411	426	504
204	400	412	428	505
205	401	413	429	506
206	402	414	431	507
207	403	415	444	509
300	404	416	449	510

1xx Информационные коды

• 100 Continue Server Code

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

• 101 Switching Protocols

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

Когда этот код может использоваться? При переключении на новую версию HTTP с протокола старого типа. Этот запрос выполняется только при наличии более подходящего протокола (иными словами, при наличии более свежей версии HTTP).
Вернуться в начало

• 102 Processing

Так как WebDAV-запрос (протокол передачи) может содержать не только один запрос, но также множество подзапросов, включая операции с файлами, он зачастую может затребовать более длительного времени для завершения запроса.

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

2xx Success

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

• 200 OK

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

• 201 Created

• 202 Accepted

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

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

• 203 Non-Authoritative Information

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

Когда этот код может использоваться? Этот код может быть использован вместо 200, когда у отправителя есть причина полагать, что заголовки ответа от постороннего источника могут отличаться от того, что предоставил бы исходный сервер.
Вернуться в начало

• 204 No Content

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

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

• 205 Reset Content

Сервер успешно обработал запрос, но при этом не возвращает какой-либо контент. В отличие от 204, этот ответ требует от запрашиваемого обновить документ.

Когда этот код может использоваться? Обычно он используется тогда, когда пользователь заполняет форму, а сервер посылает браузеры запрос на очистку формы. Он схож с кодом 204, но просит пользователя сбросить документ после завершения – например, очистить HTML-форму после подтверждения.
Вернуться в начало

• 206 Partial Reset

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

Когда этот код может использоваться? Этот кода обычно используется вследствие запрос If-Range, который применяется в мощных валидаторах кэша. Запрос также должен включать заголовки области, которые используется в качестве параметров диапазона возвратной информации.
Вернуться в начало

• 207 Multi-Status

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

3хх Перенаправление

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

• 300 Multiple Choices

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

• 301 Moved Permanently

Это довольно распространенный пользовательский запрос. Он означает, что запросы для данного ресурса (а также все последующие запросы) должны быть перенаправлены на заданный URL.

• 302 Found

Этот код сообщает пользователю, что расположение запрашиваемого ресурса временно изменено, и 302 код состояния должен содержать информацию о новом месторасположении, которое пользователь и должен запросить.

Когда этот код может использоваться? У этого кода есть несколько применений, многие из которых не являются тем, для чего код был изначально предназначен. Изначально он представлял собой основной способ создания временного перенаправления. Тем не менее, сегодня существуют и другие – этичные, и неэтичные – способы его применения.
Вернуться в начало

• 303 See Other

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

Когда этот код может использоваться? Этот метод главным образом существует для того, чтобы позволить выводу данных POST-активированного скрипта перенаправить агента пользователя к выбранному ресурсу.
Вернуться в начало

• 304 Not Modified

Этот код означает, что пользователь запрашивает документ/ресурс только в том случае, если он подвергался изменениям с момента последнего обновления кэша данного документа.

Когда этот код может использоваться? Если в ответе от сервера сообщается о том, что параметры документа If-Modified-Since или If-Match не менялись с момента создания последнего кэша, то нет необходимости в повторной отправке ресурса.
Вернуться в начало

• 305 Use Proxy

Этот код сообщает пользователю, что доступ к запрашиваемому ресурсу возможен только посредством прокси, указанного в ответе.

Когда этот код может использоваться? Этот код часто отображается в связи с мерами безопасности, и предоставляет доступ к запрашиваемым URL-ресурсам.
Вернуться в начало

• 306 Switch Proxy

Этот код изначально означал «последующие запросы должны использовать указанный прокси», но в данный момент не используется и зарезервирован.
Вернуться в начало

• 307 Temporary Redirect

Этот код возвращается, если ресурс на данный момент временно доступен по другому URL, который также предоставляется в ответе. Этот код немного отличается от кода 302 – он представляет собой более определенную версию кода 302.

Когда этот код может использоваться? Он используется практически в тех же случаях, что и 302, но пользователь должен продолжить запросы по исходному URL при следующих запросах, либо до тех пор, пока не будет применен новых код ответа.
Вернуться в начало

4хх Ошибка клиента

Класс кодов 4xx предназначен для указания ошибок со стороны клиента, либо на то, что локации никогда (или уже) не существовало. Эти коды состояния применимы к любому методу запроса.

• 400 Bad Request

Запрос не может быть исполнен ввиду синтаксической ошибки.

Когда этот код может использоваться? Когда пользователь запрашивает информацию, но делает это, пренебрегая правилами протокола передачи гипертекста. Запрос не следует повторять без изменения синтаксиса.
Вернуться в начало

• 401 Unauthorized

Этот код связан с запросом к ресурсу, который требует авторизации. Ответ 401 указывает на то, что попытка авторизации была отклонена по тем данным, которые предоставил пользователь.

Когда этот код может использоваться? Когда пользователь совершает запрос к серверу, используя неправильные данные авторизации (имя пользователя и/или пароль).
Вернуться в начало

• 402 Payment Required

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

Когда этот код может использоваться? Старый сервис MobileMe от Apple выдавал ошибку 402, если аккаунт пользователя в MobileMe подозревался в злоупотреблении сервисом. Кроме того, Youtube использует это состояние, если конкретный IP-адрес уличен в совершении чрезмерного числа запросов, и тогда пользователю необходимо ввести CAPTHA.
Вернуться в начало

• 403 Forbidden

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

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

• 404 Not Found

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

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

• 405 Method Not Allowed

Метод, при помощи которого совершается запрос к ресурсу, не доступен. Другими словами, ошибка возникает при попытке использовать GET на форме, которая требует ввод данных посредством POST, либо использовании метода PUT на ресурсе, который предназначен только для чтения.

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

• 406 Not Acceptable

Запрошенный ресурс способен генерировать только тот контент, который не применим к Accept-заголовкам в самом запросе. Браузер способен указывать серверу характеристики данных, которые данные будут принимать от сервера

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

• 407 Proxy Authentication Required

Как и код состояния 401, код 407 означает, что клиент сначала должен авторизоваться через прокси. Чтобы сделать это и авторизоваться, прокси должен вернуть поле с заголовком proxy-authenticate, который отвечает требованиям, представленным сервером.

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

• 408 Request Timeout

Время ожидания сервером передачи от клиента истекло.

Когда этот код может использоваться? Руководствуясь спецификацией W3 HTTP: «Клиент не сделал запрос в отведенный промежуток времени, который сервер был готов ждать. Клиент МОЖЕТ повторить запрос когда угодно».
Вернуться в начало

• 409 Conflict

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

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

• 410 Gone

Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Пользователю не следует повторять идентичный запрос.

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

• 411 Length Required

Запрос не указывает длину контента, и это было затребовано в совершенном запросе.

Когда этот код может использоваться? Когда браузер не определяет длину запрашиваемого контента в заголовке запроса. Сервер не примет запрос без валидного поля заголовка content-length.
Вернуться в начало

• 412 Precondition Failed

Сервер не отвечает одному из предварительных условий, которые отправитель указал в запросе. Другими словами, один или более заголовок запроса был возвращен с атрибутом false.

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

• 413 Request Entity Too Large

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

Когда этот код может использоваться? При использовании в форме метода POST с контентом, по размеру большим, нежели сервер способен обработать.
Вернуться в начало

• 414 Request-URL Too Long

Этот код отображается, когда сервер не может обработать запрос из-за слишком длинного указанного URL.

Когда этот код может использоваться? Когда POST-запрос конвертируется в GET-запрос. POST-запрос поддерживает отправку безграничного объема данных, связывая их с самим запросом. Тем не менее, если запрос должен быть конвертирован в GET-запрос, то запрос позволяет привязать данные формы к URL, что позволяет проводить информацию в больших размерах, чем это было доступно.
Вернуться в начало

• 415 Unsupported Media-Type

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

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

• 416 Requested Range Not Satisfiable

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

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

• 417 Expectation Failed

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

Когда этот код может использоваться? Все вполне и так понятно. Когда один из заголовков запроса, заголовок «Expect», имеет запрос, на который сервер не может предоставить ответ.
Вернуться в начало

• 418 I’m a teapot

Этот код был создан в 1998 году как одна из традиционных первоапрельских шуток IETF, в RFC 2324, Hyper Text Coffee Pot Control Protocol, и вряд ли будет обрабатываться современными HTTP-серверами.

• 422 Unprocessable Entity

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

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

• 423 Locked

Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Чтобы ресурс стал доступным, необходимо снять блокировку или предоставить правильные данные авторизации.

Когда этот код может использоваться? Когда ресурс… закрыт. Обычно это случается из соображений безопасности.
Вернуться в начало

• 424 Failed Dependency

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

• 425 Unordered Collection

Этот код отображается, когда ресурс определен в черновиках «WebDAV Advanced Collections Protocol», но не присутствует в «Web Distributed Authoring and Versioning Ordered Collections Protocol».
Вернуться в начало

• 426 Upgrade Required

Этот код отображается, когда сервер указывает клиенту на необходимость обновить (переключиться на другой, более новый) протокол. Когда этот код может использоваться? Обычно когда браузер использует устаревшие протоколы.
Вернуться в начало

• 428 Precondition Required

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

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

• 429 Too Many Requests

Этот ответ посылается, если клиент попытался отправить слишком много запросов за короткое время.

Когда этот код может использоваться? Когда пользователь посылает слишком много запросов за короткий промежуток времени.
Вернуться в начало

• 431 Request Header Fields Too Large

Происходит, когда сервер не собирается обрабатывать запрос, так как какое-то из полей заголовка (или все поля заголовков) слишком большое.

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

• 444 No Response

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

Когда этот код может использоваться? Обычно использовался в качестве сдерживающего фактора против вредоносного ПО.
Вернуться в начало

• 449 Retry With (Microsoft)

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

Когда этот код может использоваться? Этот код зачастую генерируется, когда выставленные параметры запроса не соответствуют тем, что может принять сервер.
Вернуться в начало

• 450 Blocked by Windows Parental Controls (Microsoft)

Расширение Microsoft. Эта ошибка выдается, когда параметры Windows Parental Controls выставлены на блокировку доступ к определенным веб-страницам.

Когда этот код может использоваться? Когда родители (зная об этой функции) используют родительский контроль, и id-доступа запросил доступ к заблокированному ресурсу.
Вернуться в начало

• 451 Unavailable For Legal Reasons

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

5xx Ошибка сервера

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.

Эти серверные ответы зачастую отображаются, когда пользователь делает запрос, который сервер не в состоянии обработать по той или иной причине. Сервер должен включать сообщение для браузера, которое должно быть показано пользователю – в нем сообщается, что сервер (и по каким причинам) не способен обработать запрос.

• 500 Internal Server Error

Данная ошибка говорит о любой внутренней ошибке сервера, которая не входит в рамки остальных ошибок класса.

Когда этот код может использоваться? Когда ресурс или ссылка создаются на сервере (вроде календаря в системе бронирования), которые технически не существуют в виде ссылки или доступного ресурса, но показывается пользователю в виде ссылки.
Вернуться в начало

• 501 Not Implemented

Сервер либо не понимает метод в запросе, либо не поддерживает возможностей, необходимых для обработки запроса

Когда этот код может использоваться? Вы можете столкнуться с этим, когда сервер не поддерживает нормальные протоколы запроса, вроде GET, OPTIONS, HEAD, POST и т.д.
Вернуться в начало

• 502 Bad Gateway

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

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

• 503 Server Unavailable

Сервер временно не имеет возможности обрабатывать запросы по техническим причинам. В основном, это состоянии является временным.

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

• 504 Gateway Timeout

Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса.

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

• 505 HTTP Version Not Supported

Сервер не поддерживает указанную в запросе версию протокола HTTP.

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

• 506 Variant Also Negotiates

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

Когда этот код может использоваться? Когда сервер настроен некорректно, и не способен обработать запрос.
Вернуться в начало

• 507 Insufficient Storage

Когда сервер не способен разместить данные, так как не хватает места для выполнения текущего запроса.

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

• 509 Bandwidth Limit Exceeded

Этот код ответа используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика.

Когда этот код может использоваться? Когда на сервере Apache выполняется корректное расширение, и в ISP установлен уровень пропускного канала, который скоро может быть превышен. Существует несколько опций предела.
Вернуться в начало

• 510 Not Extended

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

• 511 Network Authentication Required

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

Когда этот код может использоваться? Когда пользователь предварительно должен дать свое согласие на условия использования, перед тем, как он получит доступ к интернету (например, к Wi-fi точке доступа).

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

Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.

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

Немного теории

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

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

Сперва определимся с терминами.

• Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
• Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

• 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
• 4** – сбой на стороне юзера.
• 3** – обнаружен редирект на другой адрес (не ошибка).
• 2** – запрос обработан успешно (не ошибка).
• 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

203 – данные получены не из первоисточника (возвращаемые данные идут не от исходного сервера, а от какого-то другого) и могут быть устаревшими.

204 – запрос был обработан правильно, но отсутствует содержимое. Есть заголовок ответа, но содержимое для него отсутствует. Обновлять и актуализировать содержимое не нужно.

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

206 – ошибка частичного содержимого. Если клиент хочет выполнить загрузку данных в несколько потоков, а сервер выполняет только часть GET-запроса, будет возникать 206-ая ошибка.

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

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

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Трехсотые – запросы на редирект

300 – не удалось идентифицировать точный URL. Такой ответ возникает, когда существует множественный выбор, и краулер не знает, к какой именно странице относится ресурс.

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

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

303 – нужно направить пользователя на иной URL. 303-ый код можно получить исключительно GET-запросом. В идеале, этот код нужно отдавать, когда требуется редиректнуть посетителя на близкорелевантую, но не идентичную странице.

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) – он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

307 – документ был временно перемещен на иной URL. Идеальный вариант, если требуется временно редиректнуть посетителя, но оставить техническую возможность отправки POST-запросов.

Четырехсотые – сбои на стороне клиента

400 – ошибка синтаксиса. Сервер не может идентифицировать запрос, так как была допущена опечатка в синтаксисе. Проверьте корректность отправляемого запроса.

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так – просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

405 – некорректный метод (указывается в запросной строке клиента) для выбранного документа. Метод запроса определяет точное действие, которое должно быть выполнено для указанного ресурса.

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

410 – ресурс более не существует по указанному URL. Если страница удаляется целенаправленно, лучше делать так, чтобы она отдавала именно 410-ый. Краулер обойдет такую страницу, получит этот код и больше никогда на нее не вернется, так как поймет, что она удалена навсегда. Если речь о веб-странице, которая была удалена временно, гораздо эффективнее использовать 404-ый ответ. Если страница удалена намерено и навсегда, но в SERP имела хорошие места и приносила трафик, лучше сделать редирект на максимально релевантную существующую страницу.

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

416 – некорректное значение Range (диапазон). Ответ возникает в случаях, когда в самом HTTP-заголовке прописывается некорректный байтовый диапазон. 416-ый отдается в случаях, когда сервер не может взаимодействовать с запрашиваемыми диапазонами. Причина – отсутствие диапазона в необходимом документе или опечатка в синтаксисе.Сервер просто не имеет возможности работать с запрашиваемыми диапазонами. Проверьте синтаксис значения Range – он должен обязательно соблюдаться. Скорее всего, документ просто не имеет запрашиваемых диапазонов. Обновите страницу.

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

422 – существует определенная логическая ошибка. Какая именно, данный код не указывает. Копайте в сторону ошибок в семантике документа.

423 – используемый ресурс был заблокирован для выбранного HTTP—метода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

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

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

Пятисотые – серверные сбои

500 – серверу не удается полностью обработать запрос. Такой код отдается, когда существует непредвиденное условие, мешающее выполнению запроса. Чаще всего внутренняя ошибка сервера может появляться при серверных сбоях. Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess), нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

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

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

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

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

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config.php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

• mainspy;
• 2ip;
• cy-pr;
• wwhois;
• 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

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