Ошибка 200 http как исправить

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

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

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

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

Если есть доступ к серверу по 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 парсер и всё!

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

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

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

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

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

Типы ошибок

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

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

Всего существует 4 типа кодов (хх — сочетание любых цифр):

• 2xx — запрос выполнен успешно;
• 3xx — запрос успешно перенаправлен (тоже положительный код);
• 4xx — ошибка — документ не был отправлен пользователю, так как произошла критическая ошибка. Класс кодов 4xx предназначен для указания ошибок со стороны клиента;
• 5xx — ошибка сервера — критическая ошибка на сервере. Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.

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

Ошибка 400

Bad Request

При переходе на сайт браузер может выдавать “400 Bad Request”. Это означает, что сервер обнаружил синтаксическую ошибку в запросе, который ввел пользователь. Однако подобная ошибка может появляться не только, когда вы вводите адрес сайта, но и, например, при входе в панель управления вашим сайтом. Причин возникновения может быть несколько:

• блокировка браузера антивирусом;
• блокировка брендмауэра Windows браузером;
• большое количество файлов cookies и данных в сache;
• перебои в работе интернета.

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

Блокировка браузера

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

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

Блокировка брендмауэра Windows

• Попробуйте отключить брендмауэр на время: меню Пуск — Панель управления — Система и безопасность — Брандмауэр Windows — Включение и отключение.
• Очистите кэш и куки.
• Обновите страницы с ошибкой.
• Если проблема устранена, то для завершения добавьте в брандмауэр разрешенные программы: Пуск — Панель управления — Система и безопасность — Брандмауэр — Разрешение запуска программы через брандмауэр.

Если проблема осталась — продолжайте проверку.

Cache и cookies

• Удалите cookies и очистите cache: нажмите Shift + Ctrl + Delete в то время, когда браузер открыт.
• Удалите ненужные файлы.
• Проверьте работу вашего браузера.

Перебои в работе интернета

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

Ошибка 403

Forbidden

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

• Индексный файл index.html не загружен в директорию public_html вашего сайта или является некорректным. Для устранения этой ошибки создайте файл с именем index.html или переименуйте уже имеющийся файл. Возможные варианты для имени файла: index.html, index.htm или index.php.
• Для директории, в которой находится запрашиваемый файл, установлены такие права, что веб-сервер Apache не смог прочитать файл на диске сервера. Для устранения этой ошибки попробуйте изменить права доступа в разделе, отвечающем за настройку прав.
• Файлы сайта загружены в неправильную директорию. Для устранения этой ошибки проверьте, располагаются ли файлы сайта в директории site/public_html, где site — название вашего сайта.

Ошибка 404

Not Found

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

• Некорректный URL, введенный в адресное поле браузера. Для устранения данной ошибки проверьте, корректно ли указана ссылка.
• Файл, запрашиваемый по URL, отсутствует на сервере. Для устранения этой ошибки необходимо проверить наличие запрашиваемого файла в директории public_html вашего сайта.

Ошибка 500

Internal Server Error

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

• Невозможно запустить скрипт. Скорее всего, указаны неправильные права доступа на папки и файлы. Если на PHP файлы скриптов, размещенных на вашем хостинге, стоят права доступа 777, то исполнение данных скриптов может быть заблокировано сервером. Происходит это из-за того, что права доступа 777 позволяют всем производить любые изменения с данным файлом, что существенно влияет на безопасность и целостность вашего сайта. Для устранения этой ошибки следует проверить права доступа на папки и файлы сайта. Для папок рекомендовано установить права доступа 755, для исполняемых скриптов 600, а для всех остальных файлов 644.
• Неправильная инструкция в файле .htaccess или наличие в нём неподдерживаемых директив. Возможно, вы ошиблись в написании названия нужной директивы или параметров к ней. Данную ошибку можно устранить, включив лог ошибок error.log. Веб-сервер укажет вам, какую конкретно директиву он посчитал ошибочной — ее нужно будет исправить.

Ошибка 502

Bad Gateway

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

• Проблемы в работе прокси-сервера. Для устранения этой ошибки попробуйте набрать в адресной строке браузера ссылку на какой-либо другой сайт. Тем самым вы можете проверить, есть ли доступ в Интернет вообще. Если вы обнаружили, что доступ в Интернет есть, но ваше обращение к конкретному сайту все равно дает ошибку 502, попробуйте удалить файлы cookies в браузере.
• Нехватка ресурсов сервера. Это может означать, что нагрузка на сервер превышает ресурсы, доступные на выбранном тарифе хостинга. Уточните у своего хостинг-провайдера информацию о тарифах с большим объемом ресурсов и, в случае необходимости, увеличьте оперативную память или доступный объем диска.

Ошибка 503

Service Temporarily Unavailable

У каждого аккаунта на сервере хостинга есть определенное количество рабочих процессов, выделенное в соответствии с выбранным тарифным планом. Работа с запросами ведется в порядке очереди, они поступают на сервер, где легкие запросы обрабатываются мгновенно, а тяжелые – медленно. Всякая очередь ограничена тем или иным количеством запросов. Если новый запрос находится за пределами этой границы, принят он не будет, и вместо результата браузер выдаст оповещение “Сервис временно недоступен”.

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

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

• Проверить все компоненты и плагины вашей CMS, отключая их по очереди, и найдите самые тяжёлые или испорченные, при работе которых загрузка сайта замедляется. По возможности откажитесь от таких компонентов или поищите более быстрый аналог.
• Проверить наличие у вас медленных запросов — в папке logs вашего аккаунта создается файл mysql-slow.log. Информация в этом файле обновляется раз в сутки и содержит только самые проблемные SQL-запросы.
• Если в PHP-скриптах используются Include-функции, загружающие части движка, расположенные на одном аккаунте, убедитесь, что в них используется локальный путь, а не URL вида «http://…». Наличие URL заставляет сервер делать дополнительный HTTP-запрос — это занимает лишнее время и сильно замедляет загрузку сайта.

2. Большое количество запросов к серверу. Причин возникновения таких запросов несколько:

• Загружаемый ресурс разбит/содержит ссылки на слишком больше число файлов (картинки, таблицы стилей JS-скрипты), которые подгружаются через отдельные запросы. В этом случае следует объединить ресурсы в один файл, где это возможно.
• DDoS-атаки, флуды, спамы в комментарии также могут вызывать большое количество запросов. В случае DDoS-атаки необходимо определить ее тип, и, согласно ее уровню, предпринять действия по устранению. Подробнее про DDoS-атаки вы можете прочитать в статье «DDoS-атаки: взгляд со стороны Timeweb».

---

---

Код 200 относится к информационным ответам сервера и сообщает, что запрос был принят и успешно обработан.

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

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

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

Разновидности кода 200

Существует несколько видов ответов. К ним относят:

• Response 200 OK — стандартный ответ, означающий, что запрос успешно обработан. Этот ответ дают все страницы, доступные для просмотра и проиндексированные поисковыми роботами.
• 201 — означает созданное что-либо новое в результате действий пользователя, например, страницу.
• 202 — запрос был принят в обработку, но еще не выполнен до конца из-за каких-либо причин. Этот запрос при желании можно отклонить, если вы считаете, что обработка займет слишком много времени.
• 203 — операция была выполнена успешно, но данные были получены не из заданного пользователем первоисточника, а из другого, например, бэкапа сервера. Этот код также может свидетельствовать о том, что информация могла уже устареть.
• 204 — запрос был выполнен, но сервер не может отправить контент в ответ. Как правило, такой код ответа содержит только HTTP-заголовки.
• 205 — запрос был успешно выполнен, но клиенту нужно обновить введенные данные. При этом обновлять сам документ не нужно, поскольку сервер не передает тело сообщения.
• 206 — в ответе возвращается только тот контент, который необходимо получить пользователю. Этот код ответа получает пользователь, заходя, например, на кэшированную страницу.
• 207 — используется сервером, который выполнил сразу несколько отдельных операций. Результаты появляются в мультистатусном XML-документе.
• 226 — используется для принятых IM-заголовков. Свидетельствует о том, что операция была успешно выполнена.