© 2008–2022 ООО «Вебхост»
Ошибка 403 означает, что доступ к ресурсу, папке или файлу запрещен (получен код 403 Forbidden). Возможно, что доступ был закрыт через файл .htaccess.
Так же ошибка может быть вызвана тем, что в папке нет index файла.
Документ по указанному URL не существует. Возможно, такой файл удален, либо вы ошиблись при наборе URL в браузере или пошли по неверной ссылке.
Появление 500 ошибки, может быть связано с неправильно указанными параметрами в файле .htaccess, который находится в папке с вашим сайтом.
Также, если файл сохранён в кодировке UTF-8, он должен быть без метки BOM. Если же файл сохранён в UTF-8 с меткой BOM, откройте файл и сохраните его без метки BOM.
Ошибка 500 у CGI скриптов, может быть вызвана из-за неправильных прав у файла-скрипта CGI (должны быть 755).
Также, это может быть ошибка непосредственно в сценарии скрипта. Точную причину можно установить, просматривая лог ошибок.
Данная ошибка означает, что сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера).
Причиной может быть некорректная работа скриптов, либо ошибка ответа шлюза веб-сервера.
Одна из наиболее частых причин ошибки 502:
скрипт сайта отправляет cookie или другие данные множество раз при каких-то определённых действиях, в результате чего объём заголовков (header) растёт больше допустимого лимита веб-сервера.
При достижении порогового значения, веб-сервер отклоняет запрос с слишком большим заголовком, отбрасывая соединение с ошибкой 502 Bad Gateway. Такое бывает, когда скрипты написаны разработчиками без должной оптимизации.
На хостинге используется связка веб-серверов nginx (front-end) + apache (back-end)
У nginx указаны оптимальные параметры для заголовков:
proxy_buffer_size 32k; proxy_buffers 16 32k;
Прочие причины:
Если используется НЕ режим работы Apache, а PHP-FPM (FastCGI), в этом случае 502 ошибка может быть вызвана достижением лимита количества рабочих pool-процессов PHP-FPM. Это тоже самое, что ошибка 503 у режима работы Apache.
В этом случае убедитесь что в настройках www-домена включено кеширование и постарайтесь оптимизировать сайт.
Ошибка 503 (Service Temporarily Unavailable) – обслуживание временно недоступно.
Многие не до конца понимают причины появления ошибки 503 и считают, что во всем виноват сервер.
5хх ошибки действительно серверные, но это не всегда значит, что проблема именно на стороне сервера.
Что же такое хостинг? Хостинг — некоторое количество аккаунтов на одном физическом или виртуальнорм сервере, в каждом аккаунте может быть не один сайт и основное ограничение — это ограничение по нагрузке аккаунта пользователя на сервер, а так же некоторые лимиты в конфиугарации веб-сервера. Со стороны веб-сервера apache, для предотвращения падения всего сервера и всех сайтов клиентов, каждому сайту устанавлен параметр MaxClientsVHost от 10 до 25 (в зависимости от тарифа).
Таким образом, в случае какого-либо аномально большого количества HTTP запросов к одному из сайтов, сработает лимит MaxClientsVHost, при достижении которого, веб-сервер на последующие запросы начнёт возвращать HTTP ошибку 503. Делать это он будет до того времени, пока предыдущая очередь рабочих процессов веб-сервера, которые уже занимаются обработкой HTTP запросов, не будет высвобождена. Это позволяет сохранить работоспособность всех остальных сайтов, в том числе других клиентов в случае каких-либо аномалий на одном сайте одного конечного клиента.
Сервер ограничен в вычислительных мощностях, поэтому есть ограничения по нагрузке для каждого аккаунта и есть лимиты через конфигурацию веб-сервера. Если серьезная нагрузка длится слишком долго — может «рухнуть» весь сервер, все аккаунты пользователей и все сайты — вот тут и возникает ошибика 503 (Service Temporarily Unavailable) говорящая о том, что веб-сервер временно не может обрабатывать больше запросов на данном сайте и необходимо подождать пока очередь текущих рабочих процессов уменьшиться и можно будет дальше обрабатывать запросы.
Мы рассмотрели, как устроен хостинг и теперь постараемся описать основные причины, при которых может расти очередь, и, по возможности, пути решений этой проблемы. Иногда это может быть очень сложной задачей и собственных знаний может не хватить, но тем не менее, рассмотрим варианты:
- Зависание скриптов при передаче больших статичных файлов через PHP.
Пример - отдача изображений миниатюр не напрямую по URL таких статичных файлов, а через php. Статичные файлы, к примеру изображения, лучше всего передавать напрямую, не используя скрипты. Почему? Скрипты работают определенное время, а не постоянно и при окончании времени работы скрипта прерывается передача файла, соответственно файл не будет передан полностью, а запрос оставит процесс веб-сервера работать ещё длительное время. Также, каждая передача файлов через PHP — это отдельный рабочий процесс веб-сервера apache (количество которых ограничено), а для передачи статичных файлов напрямую будет использоваться отдельный многопоточный процесс веб-сервера nginx, который может обрабатывать множество потоков, а значит не будет влияния передачи файла на загрузку и срабатывания лимита при отдаче статики.
- Удаленное соединение с другим сервером (сайтом и т.д.).
Удаленных соединений, по возможности, лучше избегать, но если оно необходимо, то желательно выставлять маленькие значения таймаутов ожидания ответов от другого сервера, так как удаленный сервер может быть недоступен в определенное время, что может вызывать постоянные запросы на соединение с удаленным сервером. Поэтому в таких случаях очень важна хорошая связь с этими удаленными серверами.
Также часто используют вставки отдельных функций, кодов и т.д. (include) и если эти функции располагаются в одном аккаунте — используйте только локальные пути, а не в виде вставки url-адреса (http://site.ru/file.phpinclude 'file.php';. Это не будет делать дополнительный внешний запрос на сервер и тем самым вы снизите нагрузку, уменьшите количество создаваемых процессов.
- Очень тяжелые или испорченные дополнения систем управления сайтами (при использовании CMS и прочих скриптов).
Для нахождения таковых можно отключать дополнения (плагины, хаки, модули и т.д.) по отдельности. Возможно при включении/отключении вы заметите, что сайт станет быстрее/медленнее загружаться. Далее вы сможете найти более легкую замену или исправить поврежденные дополнения. Также в дистрибутив многих CMS включены дополнения, которые лично вам могут быть не нужны, поэтому лучше их удалить.
- Задания выполняющиеся долгое время.
Иногда в самих скриптах пишут задания на выполнение чего-либо по расписанию (например в тех же mambot’ах в joomla и wp-cron в wordpress). Если их можно перенести в планировщик (cron), то лучше это сделать через cron, так как такие задания выполняются вместе с запросами пользователей и тем самым замедляют загрузку сайта и увеличивают нагрузку, а в некоторых случаях сайт вовсе перестает загружаться если задание "тяжелое" и выполняется длительное время.
- Почтовые рассылки.
Рассылки писем могут влиять на загрузку сайта, тем не менее они часто бывают необходимы и их так же лучше оптимизировать. Скрипт запуска рассылки можно добавить в планировщик (cron), как и в случае с mambot’ами в joomla. Управление планировщиком находится в панели управления хостингом и доступно при соответствующем тарифе. Запускать такие скрипты лучше во время наименьшей нагрузки, например ночью, когда на сайте меньше всего посетителей.
- Медленные или не оптимизированные запросы sql к базе данных.
Пути решения в этом случае – использование кеширования, оптимизация запросов и индексация таблицы базы данных по столбцам (сортировка, упорядочивание). Также, если все это не помогает, стоит подумать о смене скрипта на более оптимизированный.
- Большое количество запросов к серверу.
Старайтесь избегать лишних запросов. Запросы могут исходить не только от посетителей ваших сайтов, но и, например, от индексирующих ботов с поисковиков, sape-подобные биржи и т.д, также увеличивается количество запросов при использовании большого количества url на файлы (изображения, js-скрипты, css-стили), которые загружаются через отдельные запросы (при включенном только apache вместо nginx+apache кеш статики). По возможности, объединяйте большое количество css, js файлов в один файл по типу.
Также запросы могут исходить, например, от чата или какого-то участка, блока на сайте, который посылает ajax-запросы на сервер. Многие из нас любят открывать несколько вкладок в браузере — нужно учитывать, что от этого так же может увеличиваться количество запросов и соответственно процессов веб-сервера.
Вставка iframe-кодов на сайте тоже может быть причиной ошибки 503.
Еще один пример увеличения запросов — использование другими сайтами ваших ресурсов (ссылки на файлы, картинки, различные информеры). Возможный выход это использование антилич системы в борьбе с этим.
DDoS-атаки, флуд, спам в комментариях, или в других веб-формах на сайте так же могут вызывать большое количество запросов.
Если у вас все оптимизировано, используется кеширование, минимум запросов и просто не хватает ресурсов на используемом тарифе, тогда остается задуматься о переходе на другие тарифные планы.
Многие веб-мастеры хотят недорогие тарифы, при этом про оптимальное расходование ресурсов многие просто забывают или не хотят задумываться. На WebHOST1 разработаны оптимальные тарифы и нужно просто подобрать необходимый для вас тариф, что можно осуществить самостоятельно в биллинге.
Наконец, если вашим сайтам не хватает максимального тарифа и часто возникает 50х ошибка, а вы не знаете как избежать данной проблемы — значит требуется больше ресурсов и вам нужен, как минимум, виртуальный либо выделенный сервер.
Этот код ответа означает, что клиентский запрос nginx передал apache, а apache не смог в установленный лимит времени вернуть HTTP-ответ?, в рузультате сервер разрывает сетевое соединение по таймауту. Причиной может быть долгая работа процесса - сценария, запущенного скриптом веб-сайта.
Можно попробовать увеличить выделенное время для php, прописав в корне сайта в файл .htaccess код:
# время выполнения скрипта - сценария php_value max_execution_time 60 # время загрузки данных php_value max_input_time 60Однако это не избавит от таймаута веб-сервера с 504 ошибкой. Таймаут веб-сервера в рамках виртуального хостинга изменить не представляется возможным.