Что делать, если сайт недоступен (код 200) |
Формирование правильных кодов ответа сервера в Http заголовках является залогом успешного продвижения сайта. Проверить их можно в онлайн сервисах.
HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.
Успешные коды состояния HTTP сервера: 200, 201, 202, 203, 204, 205, 206
Привет, читатель блога ZametkiNaPolyah. ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы с тобой рассмотрим успешные коды состояния HTTP сервера, которые, как ты понимаешь, начинаются с двойки. Для начала мы посмотрим на список успешных кодов состояния и дадим и короткое пояснение, а затем мы посмотрим на то, как успешные коды состояния связаны с методами HTTP запроса. В конце этой публикации мы более подробно поговорим про каждый из успешных кодов состояния.
Успешные коды состояния HTTP сервера: 200, 201, 202, 203, 204, 205, 206
Общее описание успешных кодов состояния HTTP сервера
Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Успешные коды состояния HTTP сервера говорят клиенту о том, что его запрос успешно получен, понят, принят и обработан. Успешные коды состояния HTTP сервера всегда начинаются с двойки, давайте сведем в одну таблицу все успешные HTTP коды, как мы это делали для информационных кодов.
Перейдем к рассмотрению HTTP кодов состояний из класса 2хх (если ты еще не знаешь про классы состояния HTTP)
HTTP код состояния 200 (успешно). HTTP код состояния 201 (создано). HTTP код состояния 202 (принято)
HTTP код состояния 200 сообщает о том, что запрос клиента был успешно принят и обработан. Информация, которая будет возвращена пользователю зависит от метода HTTP запроса. Давайте составим небольшую таблицу с методами и тем, какое содержимое им вернет сервер с HTTP кодом состояния 200.
Метод HTTP запроса Содержимое HTTP ответа с кодом 200 GET В ответ на метод GET клиент получит HTTP сообщение с кодом 200 и объект, который расположен по указанному URI в запросе (URI в HTTP). POST Если клиент отправляет запрос методом POST, то в ответ он получает сообщение с кодом состояния 200 с описание объекта или результатом действия метода POST. TRACE Клиент, отправивший запрос методом TRACE, получит HTTP ответ с кодом состояния 200, который будет содержать сообщение, полученное конечным сервером. HEAD В ответ на метод HEAD клиент получит сообщение с кодом состояния 200, в котором не будет тела сообщения
HTTP код 200 мы рассмотрели, давайте перейдем к коду 201.
HTTP код состояния 201 сообщает клиенту о том, что запрос успешно выполнен и в результате этого запроса появился новый ресурс по указанному в запросе URI. Но сервер вместо кода 201 может послать код 202 в том случае, если он не может выполнить запрос клиента немедленно. Давайте перейдем к рассмотрению HTTP кода состояния 202.
HTTP код состояния 202 сообщает клиенту о том, что его запрос успешно принят на обработку, но обработка сервером еще не завершена. В итоге сервер может выполнить запрос клиента, а может его отклонить. Ответы с кодом состояния 202 уклончивы и это сделано преднамеренно, например, для того, чтобы дать серверу выполнить какой-то более важный запрос, а потом ответить клиенту, которому он отправлял HTTP сообщение с кодом состояния 202.
HTTP код состояния 203 (не авторская информация). HTTP код состояния 204 (нет содержимого). HTTP код состояния 205 (сбросить содержимое). HTTP код состояния 206 (частичное содержимое)
Перейдем к следующему успешному коду состояния HTTP сервера – код состояния 203, который говорит клиенту о том, что информация не авторская. HTTP код состояния 203 возвращает в заголовке своего сообщения информацию о том, что данное сообщение не является оригиналом, который доступен на первоначальном сервере и, возможно, информация взята из кэша HTTP сервера.
HTTP код состояния 204 говорит клиенту о том, что сервер успешно выполнил запрос, но никакой новой полезной информации нет. HTTP код состояния 204 используется чаще всего для работы с HTML формами для ввода пользовательских данных. Ответ с кодом состояния 204 не должен содержать тела сообщения.
HTTP код состояния 205 говорит браузеру о том, что ему следует (читай требования HTTP) отменить просмотр документа. Такой код состояния HTTP сервера чаще всего используется для очистки форм с целью повторного или последующего ввода и не содержит HTTP объекта.
HTTP код состояния 206 говорит о том, что был выполнен частичный метод GET. Чтобы получить такой код состояния запрос клиента должен содержать поле заголовка Range, в котором указывается диапазон в байтах, при этом ответ HTTP сервера должен содержать поле заголовка Content-Range, либо поле заголовка Content-Type.
Мы рассмотрели успешные коды состояния HTTP, давайте перейдем к кодам перенаправления. Еще есть коды ошибок клиента и коды ошибок сервера, о которых можно узнать на моём сайте. А если тебе нужна информацию обо всех кодах состояния, обратись к справочнику HTTP кодов состояния, в котором есть полное описание всех кодов.
Что делать, если сайт недоступен (код 200)
Если сайт внезапно перестал работать, диагностировать и устранить проблему поможет этот небольшой чек-лист.
Вначале рассмотрим основные проблемы на стороне сервера.
Место на диске
Это одна из самых популярных причин в остановке сервисов. Место может заполнится логами, бэкапами, если они сохраняются локально, кэшем сайта.
Если есть доступ к серверу по SSH, то достаточно запустить команды:
Они покажут, сколько места занято на диске в процентах. Если занято 100%, то службы сервера, например, mysql , не смогут создавать временные файлы и сайты перестанут работать. В этом случае необходимо освободить место на диске, либо увеличить его. Более подробно в этой статье:
Что делать, когда осталось мало места на диске
Доступность служб
Как правило, для работы сайтов необходимо, чтобы был запущен веб-сервер и сервер БД mysql . Проверить статус служб можно через отдельный пункт ISPmanager:
Раздел «Службы» в ISPmanager
Если с какой-то из служб возникла проблема, то «лампочка» не включится, и тогда необходимо будет разбираться с этой службой отдельно. Так же, в большинстве случаев, об этом скажет главная страница сайта: либо отображается код ошибки, например, 500 , 502 , 504 , либо непосредственно сам текст с отладочной информацией, если это позволяют настройки CMS, движка, на котором написан сайт.
Мы рассмотрели настройки со стороны сервера — если всё корректно по диагностике из предыдущих пунктов, но сайт по-прежнему не работает, то необходимо сужать круг поиска возможных причин ошибок и провести диагностику сайта.
Рассмотрим вариант дальнейших действий, если на сервере установлена панель управления ISPmanager.
Просмотр логов
Первым делом следует проверить:
не вносились ли изменения в код сайта,
не обновлялась ли CMS и плагины,
не была ли изменена версия PHP,
имеются ли резервные копии, на случай, если сайт не получится «реанимировать».
В последующей диагностике нам помогут логи. Если вы используете панель ISPmanager, то первым делом необходимо убедиться, включен ли лог ошибок.
WWW-домены — нужный домен — изменить:
Настройка WWW-домена в ISPmanager
Выводимые сайтом ошибки можно посмотреть по пути
например, запустив команду tail , подключившись к серверу по SSH:
Вывод логов сайта с помощью tail
Необходимо убедиться, что нужные параметры PHP для выявления ошибки, такие как:
Проверить это можно в том же ISPmanager во вкладке:
Настройки web-сервера — PHP — Настройка , выделив нужную версию.
Настройки PHP в ISPmanager
Либо можно добавить их непосредственно в код сайта — в главную (индексную) страницу index. php :
Либо прописать в файл. htaccess в корне сайта:
Тем самым, мы включили возможность вывода ошибок и логирование со стороны PHP и в большинстве случаев сообщений в логе будет достаточно, чтобы понять, в какую сторону «копать». Но бывает, что и этого мало, тогда необходимо идти дальше и включать вывод диагностической информации уже непосредственно внутри самого сайта, средствами его движка.
Включение вывода ошибок и debug
Большинство CMS поддерживают вывод отладочной информации на экран, что поможет в диагностике ошибок.
Например, если WordPress не может соединиться с базой данных, он выведет такое сообщение:
Ошибка соединения с базой данных WordPress
Если же при этом в конфигурационном файле wp-config. php , который находится в корне сайта, включить дебаг — поменять директивы:
то выводимая информация будет полнее:
Подробный вывод ошибки соединения с БД
И в этом примере выводимый текст достаточно ясно даёт понять, что указан неправильный пароль пользователя базы данных.
Подобный способ отладки применим для большинства CMS: дебаг можно включить в configuration. php у Joomla,.settings. php (скрытый файл с точкой перед названием) у Битрикс и так далее. Узнать, как это сделать, может помочь документация используемого движка.
Увы, в одной статье не охватить все возможные проблемы, влияющие на доступность сайта. Поэтому мы рассмотрим только самые распространенные случаи, с которыми чаще всего приходится иметь дело техподдержке.
Совместимость версий PHP
Одна из частых проблем — сайт работает на одной версии PHP, а на сервере используется другая. Несовместимость версий приводит к некорректной работе сайта. Если дело в этом, вы увидите синтаксические ошибки вида:
Либо явное сообщение, как например это делает WordPress:
Неправильная версия PHP в WordPress
Другая распространенная ошибка:
Говорит о том, что вы пытаетесь запустить сайт на версии 7.0 и выше, когда он работает с более ранними версиями PHP и использует устаревшее расширение php-mysql , когда как в новых версиях используется только php-mysqli .
Отсутствие расширений PHP
Также могут отсутствовать необходимые для работы сайта расширения PHP. Пример текста ошибки:
Это говорит об отсутствующих или выключенных расширениях PHP Ioncube или Curl соответственно.
Проверить их наличие можно через меню ISPmanager:
Настройки web-сервера — PHP — Расширения
Расширения PHP в ISPmanager
Посмотреть текущую версию PHP можно через меню WWW-домены в строке с нужным сайтом:
Версии PHP в разделе «WWW-домены»
Либо подложить файл info. php c содержимым в корень сайта:
затем перейти по адресу в браузере https://вашсайт. рф/phpinfo. php — в верхней части страницы увидете, какая версия используется сайтом:
Вывод файла info. php
После работ важно удалить этот файл, так как этой информацией могут воспользоваться злоумышленники.
Лимиты PHP
Другой «пласт» возможных ошибок — недостаточные лимиты, выставленные в настройках PHP. Это может проявляться как на главной странице, так и на других, где например, работает «тяжелый» скрипт, требующий больше времени и ресурсов, чем ему дозволено сейчас.
Об этом скажут сообщения:
В этом случае необходимо увеличить параметр на лимит используемой ОЗУ для одного скрипта memory_limit .
Увеличиваем время ( в секундах), поменяв параметры set_time_limit и max_execution_time .
Правим директивы на размер загружаемых файлов в мегабайтах: upload_max_filesize и post_max_size .
Используем strace
Если способы, перечисленные выше, не помогли, можно попробовать использовать утилиту strace . Но будьте готовы к тому, что вам потребуется подключаться к серверу по SSH и потратить значительное время на поиск ошибок в логах — вывод этой команды не очень удобен для восприятия.
Утилита предназначена для вывода на экран или в отдельный файл системных вызовов. Грубо говоря, показывает последовательность обращений скриптов сайта друг к другу. Это помогает отловить ошибку, если выводимого дебага недостаточно или не помогает решить проблему.
Устанавливается она yum install strace на серверах Centos или apt install strace для Debian/Ubuntu.
В общем виде подойдет такой синтаксис:
strace — s999 — вызов команды strace с максимально подробным выводом и запись его в файл /tmp/strace. txt
/opt/php71/php — адрес интерпретатора PHP
index. php — путь к вызываемому файлу.
По истории вызовов можно будет понять, к каким файлам идёт обращение и в какой момент возникает ошибка.
Заключение
В этой статье мы рассмотрели вероятные причины, почему может не работать сайт: из-за проблем «внутри» сервера — закончившихся ресурсов или неработающих служб. Разобрались, как включать логи, настраивать PHP и включать дебаг для выявления ошибок.
Если ничего не помогло, то рекомендуем не мучаться и не заниматься «самолечением» — обратитесь в техническую поддержку хостинга или к разработчику. Как правило, так получится решить проблему гораздо быстрее и без фатальных последствий.
Http — что это такое, как просмотреть заголовки и проверить код ответов сервера, что означают коды 200, 301, 302, 404 и 500
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo. ru. Сегодня я хочу поговорить в первую очередь о таком важном понятии для правильной работы любого сайта, как правильный ответ сервера. Что это такое? Сначала мы рассмотрим чуток теории о том, какие коды ответа бывают, на какие стоит обратить особое внимание, ну и как их проверить для всех страниц своего проекта.
Формирование вашим сайтом правильных http ответов при загрузке в браузер тех или иных его страниц может стать залогом успешного продвижения сайта, а вот неправильно выдаваемые коды могут здорово подорвать позиции вашего проекта вплоть до полного его исключения из индекса поисковых систем. Но давайте сначала в общих чертах разберемся в том, что это такое, зачем код нужен и почему неправильный ответ может вызвать проседание сайта в поисковиках.
Что такое http и онлайн сервисы для просмотра ответа сервера
Итак, при запросе браузером пользователя какой-либо страницы вашего сайта вместе с Html кодом этой вебстраницы, обозревателю будет передан и так называемый Http заголовок с ответом хоста, в котором помимо прочей информации будет указан код. Он представляет из себя трехзначное число (наиболее часто встречаются варианты 200, 301, 302, 404), которое обозначает ситуацию, сложившуюся на хосте при обработке запроса браузера.
Что такое HTTP ? Это протокол, по которому осуществляется обмен данными между вебсервером, на котором расположен интересующий вас сайт, и вашим браузером. Расшифровывается аббревиатура как Hypertext Transfer Protocol. Браузер пользователя обращается к серверу с запросом какого-либо документа и получает соответствующий ответ.
Если ответ на http запрос приходит положительный (200 OK), то браузер начинает загрузку нужного ему файла. Если отрицательный, то информирует об этом пользователя. Имеется еще и шифрованный протокол SHTTP, но сути дела это не меняет.
Например, при успешной загрузке страницы, в браузер будет передан Http заголовок с кодом 200 OK (кроме цифр еще приводится и поясняющая надпись). В случае, если запрошенная страница на сервере найдена не будет, то браузер получит ответ 404 Not Found. Можете сами проверить ответ главной страницы своего сайта, например, на этом сервисе.
К примеру, введя туда заведомо несуществующий адрес страницы своего ресурса (для этого после доменного имени можно написать любую ахинею, например, https://ktonanovenkogo. ru/трали-вали), будет получен примерно такой Http заголовок:
И это хорошо, ибо поисковые системы правильно обработают данный ответ сервера и не будут добавлять в индекс вашу несуществующую вебстраницу (404 страница для Joomla, 404 Not Found для Вордпресса).
Причем стоит учитывать, что несуществующие документы могут появиться как по вашей вине, так и из-за ошибки какого-либо доброжелателя, разместившего где-нибудь обратную ссылку на ваш сайт с ошибкой. Посмотреть те несуществующие документы (фактически битые ссылки), которые имеются на вашем ресурсе, вы можете в Яндекс Вебмастере или панели Google, как это было описано в статье Проверка битых ссылок.
Гораздо хуже будет, если несуществующий документ не будет выдавать в ответ 404 , ибо в этом случае на вашем сайте по разным адресам (URL) несуществующих страниц (а их может быть сколь угодно много) будет выдаваться одна и так же вебстраница ошибки 404. На лицо будет откровенное дублирование контента, которое может повлечь за собой санкции со стороны поисковиков. А оно вам надо — на ровном месте наступать на грабли.
В принципе, еще хуже ситуация может сложиться, если вместо того, чтобы создать отдельную вебстраницу 404 для своего ресурса, вы настроили переброс посетителей на главную, в случае отсутствия запрашиваемого документа на сервере. Поисковые системы, не получив кода 404, вынуждены будут проиндексировать все эти не найденные страницы, а фактически содержимое главной.
Получится совсем неприятная картина — главная будет доступна сразу по неограниченному множеству адресов, ибо при запросе или переходе по битой ссылке будет открываться все время она. Выпадение из индекса главной из-за дублирования контента может нанести очень существенный урон всему продвижению сайта, ибо она, как правило, имеет наибольший статический вес и именно на нее будет приходиться львиная доля всех обратных внешних ссылок.
Обязательно проверьте коды ответа хотя бы у некоторых вебстраниц вашего ресурса, и особенно проверьте правильность цифр, выдаваемых в ответ на запрос несуществующего документа (введите что-то типа https://vash-domen. ru/jhguytrhkfkfijd). Для этой цели можно воспользоваться приведенным выше онлайн сервисом или же рядом других, способных показать все это:
>Чтобы быть абсолютно уверенным в том, что поисковики правильно интерпретируют коды ответа вашего хоста, можете воспользоваться инструментом Яндекса Проверка ответа сервера , который, правда, будет вам доступен только после регистрации в Вебмастере, но добавиться туда, так же как и в панель Гугла, нужно будет в любом случае.
Все возможные варианты кодов ответа сервера
Обращу ваше внимание еще и на ответ сервера 301, который появляется в случае использования редиректа (перенаправление навсегда). Дело в том, что поисковые системы рекомендуют использовать 301 редирект в случае изменения адреса (URL) страницы сайта (он будет перебрасывать посетителя со старого Урла на новый) или, например, при склейке зеркал сайта с WWW или без WWW, как это было описано тут.
Если вы использовали 301 редирект, то можете проверить правильность Http ответа при обращении к склеенным Урлам. Например, при запросе www. ktonanovenkogo. ru сервер дает правильный ответ 301 Moved Permanently:
Вспомнил, что по поводу 404 ошибки я слышал довольно интересную историю. Вебмастер или оптимизатор, ведущий раскрутку определенного проекта, получил отставку и был этим сильно раздосадован. Причем, настолько сильно, что решился на то, чтобы подложить бывшему работодателю большую и жирную свинью.
Но сделал он все очень грамотно, ибо поначалу новые оптимизаторы, занимающиеся продвижением этого проекта, никак не могли понять, отчего позиции сайта резко просели. Как это реализовать на практике я не знаю, но тот вебмастер сделал так, что все страницы успешно открывались и отлично работали, но при этом в Http заголовке для всех них сервер давал ответ 404 Not Found.
Пустяк, вроде бы, абсолютно не влияющий на корректную работу ресурса, но напрочь убивающий все усилия по продвижению этого проекта. На этом примере, наверное, еще более наглядно можно увидеть важность проверки кодов ответа.
Правда в случае обнаружения неправильно формируемых кодов вам, скорее всего, придется обращаться за помощью к владельцу хостинга, в случае виртуального хоста, или же придется решать проблему самим, в случае выделенного сервера. Но главное, это вовремя диагностировать и локализовать проблему, воспользовавшись для этого соответствующими сервисами, некоторые из которых я упомянул чуть выше.
Вообще, все коды ответа сервера можно разделить на пять групп:
100-199 являются информационными, говорящими о том, что сервер обрабатывает запрос
200-299 означают, что запрашиваемые у сервера данные были успешно переданы (например, 200 — запрос был успешно выполнен и требуемые данные переданы)
300-399 означают переадресацию и необходимость выполнить дополнительные действия (например,301 — грубо говоря, документ изменил адрес навсегда; 302 — документ изменил адрес временно)
Более подробно посмотреть все возможные коды ответа в Http заголовке вы можете, например, в Википедии.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo. ru
Комментарии и отзывы (18)
У меня была поучительная история. Переименовал одну из рубрик на WP, после этого новые записи в ней упорно не индексировались Яндексом. Долго ломал голову, выяснилось, что WP не включил постоянный редирект для старых записей и они остались на сервере под теми же урлами. Проблема решилась обновлением WP.
Благодарю за статью
спасибо огромное за такую статью — было очень интересно почитать и я добавлю вас в свою рссленту
Дмитрий, еще есть плагины для определения кодов ответа, например, для FF:
— firebug, вы его раньше описывали, разноплановый инструмент.
— LiveHTTPHeaders https://livehttpheaders. mozdev. org/index. html чисто под заголовки, очень удобный.
radiomaster: спасибо большое за ценное дополнение.
А как настроить чтобы сервер отдавал вот такой ответ:
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Last-Modified: Wed, 09 Mar 2011 14:52:43 GMT
т. е. время последнего изменения, сколько хранить кэш?
Спасибо за подсказку проверил код ответа пока 200,раньше и внимания на это не оброщал.
Спасибо долго искал аналогичный материал, но хотелось бы узнать, чем наполнить страницу ошибки?
Поставил 301 редирект с WWW на без WWW. Но при проверке несуществующего адреса www. site. ru/несуществующая. html, перекидывает на главную без WWW. Как бы решить эту проблему. Спасибо.
Здравствуйте, Дмитрий. Помогите решить проблему — на моем сайте (Joomla! 1.5.23) некорректно работает обработка 404 ошибки.
Например, URL реальной страницы (свой SEF отображение):
но если поставить пробел или добавить-удалить символ в любом месте URL после «https://banketoff. com/index. php/mainmenu-halls/», и сделать, например, такой URL:
код 404 ошибки не выдается.
Все эти действия в первой части адреса приводят к нормальной 404 ошибке.
Очень прошу помочь решить проблему. Заранее спасибо.
Руслан: скорее всего этот вопрос нужно задать вашему хостеру и добиться от него вразумительного ответа.
Облазил весь интернет, так и не нашел ответа. Может Вы сможете мне помочь?
Куда конкретно нужно прописать скрипт на сайте джумла 1.5 для правильного ответа If-Modified-Since. На джумле включен модуль для создания ЧПУ.
А что делать если ответ 200ОК? И переадресация идет на главную страницу.
У меня главная страница с www и без www — обе показывают 200 OK, хотя в robots. txt указан основной хост, на яндексе прописаны зеркала и указан основной хост и в htaccess стоит редирект.
Что я сделала не так? Не подскажете?
Хороший у вас сайт, плюсогугланула ?
Ну сделала я свою страницу 404. и что это мне дало, не очень поняла из статьи. ARTIO не ставила, уже много страниц проиндексировано Яндексом, боюсь экспериментировать.
А 130 страниц 404 как висели с весны в яндекс мастере так и висят, некоторые давноудалены на сайте, а другие получились, когда я не сразу встроенный sef включила. И как с этими страницами быть? Меня накажут?
Буду очень призательна за ответы на мои вопросы. Я подписалась.
Затвитерила. Контактнула. Фэйсбукнула.
Спсибо, очень полезная статья!
Статья как всегда очень содержательна, помогла спасибо!
Кстати, ответ сервера я проверяю https://analizsaita. com/proverit-otvet-servera
У меня прото беда. Раньше были Last Modified и 304 Not Modified, а теперь нет. Пробовал плагин Add Headers — работает прекрасно (есть Last Modified и 304 Not Modified), но разваливается sitemap. xml Плагин снес.
Вствалял в файл шаблона header. php.
Устанавливал Hyper Cache — толку нет.
Ничего разумного нагуглить не смог. И что тут делать?
Здравствуйте у меня скоро экзамены и мне нужна помощь у меня онлайн тест я пытаюсь расшифровать HTML И JAVASCRIPT с целью получения правильных ответов но не получается
