Ошибка сервера 503 что это такое и что означает ошибка сервера 503 и как ее исправить

Начало

Хостинг предоставляет пользователям типичный стек Linux + Apache + Mysql + PHP и оболочку для управления. В нашем случае это ISP Manager 5 business на базе Centos 7 с конвертацией в CloudLinux. Со стороны административной части, CloudLinux предоставляет инструменты для управления лимитами, а так же PHP-селектор с различными режимами работы (CGI, FastCGI, LSAPI).

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

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

Типичные ситуации, при которых мы получаем следующие ошибки:

• 500 Internal Server Error — довольно часто связана либо с синтаксическими ошибками в коде сайта, либо с отсутствующими библиотеками / не поддерживаемой версией PHP. Так же могут быть проблемы с подключением к базе данных сайта или неверными правами на файлы / каталоги
• 502 Bad Gateway — например, если Nginx ссылается на неправильный порт веб-сервера Apache или процесс Apache по какой-то причине перестал работать
• 504 Gateway Timeout — ответ от Apache не был получен в течение заданного в конфигурации веб-сервера времени
• 508 Resource limit is reached — превышен лимит, выделяемых пользователю ресурсов

В данном списке приведены лишь некоторые, наиболее распространённые случаи. Также стоит отметить, что при превышении лимитов пользователь может получить как 500, так и 503 ошибку.

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

Касаемо 503 ошибки в нашем случае, в логах мы видели запись:

[lsapi:error] [pid 49817] [client x.x.x.x:6801] [host XXX.XX] Error on sending request(GET /index.php HTTP/1.0); uri(/index.php) content-length(0): ReceiveAckHdr: nothing to read from backend (LVE ID 8514), check docs.cloudlinux.com/mod_lsapi_troubleshooting.html

На основании только этого лога, определить в чём может быть проблема не представлялось возможным.

Первичная диагностика

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

Так же мы изучили рекомендации CloudLinux, по приведённой в журналах ошибок ссылке.
Изменение каких-либо параметров результата не принесло.

Сайт использовал базу данных на сервере Mysql 5.7, который работает на этом же сервере в контейнере Docker. В логах контейнера присутствовали сообщения:

[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)

Как раз, среди этих сообщений были сообщения о прерванном подключении исследуемого сайта. Это дало предположение, о том, что подключение к СУБД выполняется некорректно. Для проверки мы развернули копию сайта на тестовом домене, сконвертировали базу данных сайта под нативную в Centos 7 версию СУБД 5.5.65-MariaDB. На тестовом сайте выполнили несколько сотен запросов с помощью утилиты curl. Ошибку воспроизвести не удалось. Но этот результат был предварительным и после конвертации БД на рабочем сайте проблема так и осталась.

Таким образом, проблема некорректного подключения к СУБД была исключена.

Следующим предположением было проверить — нет ли проблем с самим сайтом. Для этого подняли отдельный виртуальный сервер, на нём подняли максимально схожее окружение. Единственное существенное отличие — отсутствие CloudLinux. На тестовом сервере проблему воспроизвести не удалось. Итак, мы определили, что в коде сайта всё в порядке. Тем не менее, пробовали так же отключать плагины WordPress, но проблема так же сохранялась.

В результате, пришли к тому, что проблема на нашем хостинге.

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

/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99

В ходе тестирования обнаружили, что только что установленная чистая CMS WordPress также периодически выдаёт ошибку 503.

Примерно за 2 месяца до этого мы проводили работы по модернизации сервера, в частности изменили режим работы Apache с Worker на Prefork, с целью получить возможность использовать PHP в режиме LSAPI, вместо медленного CGI. Было предположение, о том, что это могло повлиять, либо требуются какие-то дополнительные настройки Apache, но вернуть обратно режим Worker мы уже не могли. В ходе изменения режима работы Apache выполняется изменение всех конфигов сайтов, процесс не быстрый и не всё могло пройти гладко.

Корректировка настроек Apache так же не дала желаемого результата.

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

На данном этапе мы собрали имеющуюся информацию и результаты проведённых работ. С ними обратились в поддержку CloudLinux.

Детальная диагностика

В течение нескольких дней сотрудники поддержки CloudLinux вникали в проблему. В основном рекомендации были относительно установленных лимитов пользователей. Этот вопрос мы так же проверяли. При отключенных лимитах (Опция CageFS для пользователя) и с включенными лимитами в режиме PHP как модуль Apache проблема не наблюдалась. Исходя из этого, было сделано предположение, что каким-то образом оказывает влияние CloudLinux. В итоге, к концу недели запрос был эскалирован на 3-ий уровень поддержки, но решения пока не было.

Попутно изучали документацию Apache по режимам работы CGI и LSAPI, подняли второй экземпляр Apache на сервере хостинга на другом порту с тестовым сайтом, исключили влияние Nginx, отправляя запросы напрямую к Apache и получая те же коды ошибок.

Сдвинуться с мёртвой точки помогла документация LSAPI, как раз по диагностике 503 ошибки:
www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:php:503-errors
В секции Advanced Troubleshooting предлагается выполнять трассировку найденных в системе процессов:

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done

Команда была доработана, с целью записи всех процессов в файлы с указанием их идентификаторов.

При просмотре файлов трассировок, мы видим в некоторых одинаковые строки:

cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...

Если взглянуть на описание структуры сигналов, отправляемых процессами, то увидим, что

pid_t    si_pid;       /* Sending process ID */

Указывает на идентификатор процесса, отправившего сигнал.

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

tail -f /var/www/httpd-logs/sitename.error.log

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep "sitename" | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid -o /tmp/strace/trace.$mypid; fi ; done

while true; do if mypid=`cat /tmp/strace/trace.* | grep si_pid | cut -d '{' -f 2 | cut -d'=' -f 4 | cut -d',' -f 1`; then ps -aux | grep $mypid; fi; done;

seq 1 10000 | xargs -i sh -c "curl -I http://sitename/"

Ждём пока в консоли 1 появятся сообщения, при этом в консоли 4 видим статус запроса с кодом ответа 503, прерываем выполнение в консоли 4.

В итоге, получили название процесса /opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini

Данный процесс выполнялся в системе с периодичностью раз в минуту.

Делаем трассировку нескольких процессов cagefsctl, чтобы отследить хотя бы один от начала до конца:

for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;

Далее изучаем что он делал, например:

cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP

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

Полученные данные были переданы в поддержку CloudLinux с целью уточнить легитимность данного процесса и должен ли он работать с такой периодичностью.

Позже получили ответ, что работа команды /usr/sbin/cagefsctl --rebuild-alt-php-ini выполняется корректно, единственный нюанс в том, что команда выполняется слишком часто. Обычно вызывается при системном обновлении или изменении параметров PHP.

Единственная зацепка в данном случае осталась — проверить, кто является родительским процессом cagefsctl.

Результат не заставил себя долго ждать и какого же было наше удивление — родительским процессом для cagefsctl являлся процесс ispmgrnode. Это было немного странно, потому что уровень журналирования для ISP Manager был задан максимальным и в ispmgr.log не увидели вызов cagefsctl.

Теперь данных было достаточно, чтобы обратиться и в поддержку ISP System.

Итоги

Проблема была спровоцирована после выполнения обновления ISP Manager. В целом, обновление ISP Manager — штатная ситуация, но она привела к запуску процесса синхронизации, который завершался с ошибкой и перезапускался ежеминутно. Процесс синхронизации вызывал за собой процесс cagefsctl, который в свою очередь завершал процессы PHP.

Причиной зависания процесса синхронизации стали проведённые на хостинге работы по модернизации оборудования. За несколько месяцев до возникновения проблемы, в сервер был установлен PCI-e NVMe-накопитель, создан раздел XFS и смонтирован в каталог /var. На него были перенесены в том числе и файлы пользователей, но не обновились дисковые квоты. Опций монтирования было не достаточно, требовалось так же изменить тип файловой системы в параметрах ISP Manager, т.к. она вызывает команды обновления дисковых квот. Для Ext4 и XFS эти команды отличаются.

Таким образом, проблема дала о себе знать спустя несколько месяцев после проведения работ.

Выводы

Мы сами создали проблему, но это было не ясно до последнего момента. На будущее, будем стараться учесть как можно больше нюансов. Благодаря помощи более подготовленных коллег из поддержки CloudLinux и ISP System, проблема была решена. Теперь наш хостинг работает стабильно. А нами был получен опыт, который пригодится нам в будущей работе.

P.S.: Надеюсь, Вам было интересно ознакомиться с материалом статьи, а кому-нибудь она поможет быстрее решить подобную проблему.

Сообщение на странице сайта 503 Service Temporary Unavailable – «сервис временно недоступен» может появляться из-за технических сбоев как на сервере, так и на компьютере пользователя. Последнее случается реже.

Наиболее распространенная причина проблемы – перегруженность сервера запросами. Он не успевает их обрабатывать, и всем клиентам в очереди выдает ошибку с кодом 503. Такая картина может наблюдаться, например, во время DDoS-атаки.

Обнаружив ошибку 503, лучше всего ничего не делать. Подождите 3-5 минут. Очередь запросов в большинстве случаев – временное явление, и вскоре сайт станет доступен. Чего точно не нужно делать,– это постоянно перезагружать страницу с ошибкой. Так вы только увеличиваете число запросов в очереди.

Как устранить ошибку 503 на стороне пользователя?

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

• Проверьте доступность сайта с помощью специальных сервисов. Например, https://2ip.ru/site-availability/. Если проверка показала, что из вашей страны сайт доступен – исправить ошибку 503 нужно на вашей стороне.
• Перезагрузите страницу с помощью клавиш Ctrl F5 (в браузерах macOS используйте сочетание Cmd + R или Cmd + Alt + E в Safari.
• Попробуйте открыть страницу в другом браузере, на другом компьютере. Так вы определите уровень возникновения проблемы – у вас в браузере или у вас на компьютере – и будете действовать исходя из этого. Если страница везде выдает Error 503 – то причина все же на самом сайте.
• Закройте браузер и откройте заново. Иногда это помогает сбросить неправильные настройки сессий.
• ​Почистите кэш и cookies браузера. Большое количество сохраненной старой информации может мешать браузеру обрабатывать соединение правильно.
• Откройте страницу в режиме инкогнито или просто отключите все работающие в браузере дополнения и расширения – возможно, какое-то некорректно работает и приводит к появлению ошибки 503.
• Это самый простой и быстрый способ исправить сбой в работе ПО.
• Если не помогла перезагрузка компьютера – перезагрузите также роутер.

Что делать, если ошибка 503 – на стороне веб-ресурса?

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

Распространенные причины возникновения ошибки 503 и их исправление

В основном, ошибка 503 Service Unavailable вызывается следующими категориями причин:

• Слишком много запросов к веб-серверу.
• Много медленных запросов к MySQL.
• На сайте много устаревших, нерабочих, конфликтующих плагинов и модулей CMS.
• Неоптимизированная работа скриптов.

Также ошибка 503 может быть вызвана тем, что ваш сайт «перерос» возможности вашего хостингового тарифного плана. В этом случае стоит подумать над тем, чтобы выбрать более производительный тариф виртуального хостинга или же VPS/VDS, выделенный сервер.

Как исправить причины ошибки

Уменьшаем число запросов к веб-серверу

Устранение ошибки 503 прежде всего подразумевает снижение нагрузки на веб-сервер. Для этого:

• установите антилич-систему. Она не позволит скачивать ваши файлы и картинки по ссылке на сторонних ресурсах – ведь так увеличивается нагрузка на ваш сервер и может возникать ошибка 503;
• ограничьте деятельность различных ботов и роботов. При сканировании они создают множество запросов;
• проверьте, чтобы на сайте было как можно меньше ссылок на внешние ресурсы. Оставьте только необходимые и важные. Например, иногда можно встретить большое количество информеров на странице. Каждый информер — ссылка на другой сайт, соединение с чужим сервером. Это создает дополнительную нагрузку на сервер;
• по возможности объедините обращения к большому числу мелких файлов (скриптов, картинок, таблиц стилей), чтобы они обрабатывались одним запросом, а не множеством.

Оптимизируем работу с MySQL

• Включите кеширование – так время обработки запроса существенно уменьшится.
• Объединяйте запросы к БД (базе данных), чтобы один запрос обрабатывал сразу множество строк или столбцов, а не по одному.
• Используйте индексирование по столбцам, которые часто используются в выборках.
• Старайтесь не вкладывать один запрос в другой, так как в этом случае MySQL часто не может использовать индексы и будет долго возвращать результат.

Исправляем проблемы с CMS

Ошибка 503 Service Unavailable может быть вызвана некорректно работающими или «тяжелыми» компонентами движка вашего сайта. Чтобы выявить это, отключайте последовательно плагины или модули. Так вы найдете компонент, после выключения которого все начнет нормально работать. Оптимизируйте его или замените на более современный и быстрый.

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

Оптимизируем работу скриптов

• В скриптах поставьте локальные ссылки вместо глобальных. В глобальных указывается полный URL вместе с http, https. Они обрабатываются как отдельные запросы к внешнему ресурсу, и это гораздо большая нагрузка, чем при использовании ссылок локального вида.
• Не передавайте файлы большого размера с помощью скриптов. Во-первых, такая передача задействует рабочие процессы сервера, нагружает его. Во-вторых, она может давать сбои, так как работа скрипта ограничена по времени,и процесс зависает.
• Выполнение «тяжелых», масштабных скриптов и операций (почтовой рассылки, например) запланируйте на то время, когда на сайте меньше всего посетителей.

Что можно сделать для предотвращения проблемы?

В заключение дадим несколько советов – как предотвратить возникновение ошибки 503 Service Unavailable:

• При выборе тарифа хостинга не ориентируйтесь на среднюю нагрузки вашего сайта. Закладывайте небольшой запас мощностей, чтобы в часы пик ресурсов сервера хватало на обработку запросов.
• Установите защиту от DDoS-атак.
• Обновляйте плагины, темы и модули CMS, отключайте то, что не используете.
• Регулярно анализируйте работу компонентов сайта: сервера, базы MySQL, скриптов – и вовремя оптимизируйте их, не доводя ситуацию до критической.
• Ограничьте сканирование сайта ботами и User-агентами. Оставьте только то, что необходимо, например, боты поисковых систем, остальные заблокируйте. Обычно хостер сам блокирует большинство ненужных User-агентов, но вы можете добавить и свои кастомные настройки.

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

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

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

Ошибки 4xx (400-414)

Ответы с кодами от 400 до 414 называют «ошибками на стороне клиента». Сервер дает понять, что что-то не так с самим запросом. Несмотря на классификацию, такие ошибки часто необходимо исправлять вебмастеру, а не пользователю. Их причиной могу быть неправильные настройки веб-сервера, скриптов сайта и т. п.

Ошибка 400

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

• передача данных блокируется антивирусом или брандмауэром Windows;
• данные искажаются при нестабильном соединении;
• клиент (браузер или приложение) пытается загрузить слишком большой файл;
• повреждены или устарели куки на стороне пользователя.

Ошибка 401

Ошибка 403

Ответ означает «Запрещено». У пользователя нет прав на доступ к файлам или папкам по ссылке. Чаще всего вебмастеру исправлять ничего не нужно, все настроено верно. А вот пользователю необходимо проверить, правильно ли он указал адрес страницы. Иногда из-за опечатки ссылка ведет в запрещенную для просмотра папку, а не на страницу сайта.

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

Ошибка 404

Самый популярный код ошибки – 404. Переводится как «не найдено». Такой ответ сервер отсылает, если не находит документ, файл или страницу по указанному пользователем адресу. Возможные причины:

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

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

Ошибка 405

Расшифровка – «метод не поддерживается». Для каждого типа операций (загрузка, передача данных) http-протокол предусматривает использование своего метода (GET, POST и т. д.). Ошибка означает, что запрос на сервер выполнен с использованием неправильного метода. От клиента здесь мало что зависит, причины – в настройках веб-сервера. Например:

• происходит попытка обработки файлов с помощью метода POST, тогда как файлы этого формата должны обрабатываться непосредственно сервером Apache;
• PHP-скрипт не справляется с большим объемом импорта данных, такую операцию лучше проводить другими способами. Время, отведенное на работу скрипта, превышается, и возникает ошибка 405;
• некорректно настроено взаимодействие метода POST и модуля FastCGI.

Ошибка ​406

Расшифровывается как «неприемлемо». Достаточно редкий ответ. Возникает, если сервер отдает информацию в виде, который не может распознать клиент (ваш браузер, или поисковый робот – если ошибка появляется при индексации страниц сайта). Чаще всего контент не распознается из-за сжатия или неподдерживаемого формата, иногда – неправильной кодировки.

Причина может быть в:

• установленном на хостинге брандмауэре ModSecurity. Он блокирует запросы, которые считает зловредными. Иногда «под раздачу» попадают и вполне безобидные обращения. Часто ошибка 406 появляется после установки плагинов, кодов рекламных баннеров;
• неверных заголовках Content-Type или Content-Encoding;
• отправке в ответ на запрос поискового робота сжатого контента, тогда как требуются данные без сжатия.

Ошибка 407

Пояснение переводится как «нужна аутентификация прокси». Возникает, если доступ в сеть или к определенным сайтам осуществляется через прокси-сервер, но в запросе нет данных для авторизации на нем. Пользователю нужно пройти аутентификацию. Обычно в тексте ответа с кодом 407 содержатся подсказки – как это сделать.

Ошибка 408

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

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

Ошибка 409

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

В некоторых случаях причиной может быть:

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

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

Ошибка 410

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

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

Ошибка 411

Расшифровывается как «требуется длина». Такая ситуация может возникнуть при передаче файлов определенными методами и выставленных ограничениях на передаваемый объем. В этих случаях серверу нужен параметр Content-Length, и он ожидает увидеть его в запросе.

Ошибка 412

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

Самая простая причина – проблема в браузере пользователя. Достаточно почистить кеш и куки, чтобы ошибка исчезла.

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

Ошибка 413

Означает «слишком большое тело запроса». Объем запроса больше, чем веб-сервер может обработать. Чаще всего возникает при загрузке слишком большого файла. Ограничения по объему файлов могут быть выставлены по умолчанию (например, в Nginx это 1 МБ) или веб-мастером. Чтобы увеличить допустимый объем, измените настройки веб-сервера, директивы .htaccess или скрипты php, которые отвечают за загрузку.

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

• загрузить файл меньшего размера (сжать изображение или видео);
• архивировать загружаемый файл (при архивации будет применено сжатие и размер файла уменьшится);
• не загружать несколько файлов одновременно​.

Ошибка 414

Перевод пояснения – «URL слишком длинный». Сервер не может взять в обработку слишком длинный веб-адрес, и поэтому отклоняет запрос.

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

Часто наличие таких ошибок и переходов по длинным URL свидетельствуют о попытках взломать сайт.

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

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

Ошибка 500

Перевод пояснения – «внутренняя ошибка сервера». Ответ с кодом 500 выдается в том случае, когда ошибку нельзя отнести ни к каким другим типам – сервер не может определить, в чем проблема. Часто причина в неверных настройках .htaccess.

Ошибка 501

Означает «не реализовано». Сервер не понимает метод запроса, или не имеет функциональности для его обработки. Не стоит путать с 405 ошибкой – в ее случае метод просто используется неправильно (не к тем данным или неправильным способом), однако сервер его знает.

Ошибка 502

Означает «ошибка шлюза». Если запрос проходит через несколько серверов (через прокси), и какой-то из них не может обработать запрос, то первый сервер отдает такую ошибку. Возможные причины:

• блокировка запроса файерволом сервера;
• нет связи между какими-то участками в пути следования запроса;
• имеет место неправильная настройка сервера- «виновника» или конфликт настроек между серверами;
• сервер неисправен и т. п.

Ошибка 503

Пояснение переводится как как «сервис недоступен». Возможные причины:

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

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

Ошибка 504

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

Ошибка 505

Означает «версия http не поддерживается». Здесь причина понятна из названия ошибки. Такой ответ можно получить, если на сервере или клиенте работает устаревшее программное обеспечение, а также из-за некорректных настроек обработки запросов на стороне сервера.

Ошибка 506

Можно расшифровать как «сервер подвергается цензуре». Сервер, к которому отправлен запрос, запрещен для доступа из-за цензурных ограничений.

Когда сервер временно не может обработать запрос пользователя, он передает в браузер ответ об ошибке 503. Отсутствие доступа к сайту имеет негативные последствия как для посетителя, который не может просматривать нужный контент, так и для владельца веб-ресурса, рискующего потерять трафик и конверсию. Чаще всего причиной ошибки являются неправильные настройки сервера или движка, с помощью которого создан сайт (CMS). Их исправлением занимается администратор веб-ресурса. Однако иногда уведомление с кодом 503 возникает из-за сбоев на стороне пользователя. Такие неполадки легче и быстрее исправить, и сделать это может посетитель веб-ресурса самостоятельно. В данной статье мы разберем несколько способов устранения ошибки 503, которые могут предпринять администратор и пользователь сайта.

Что значит ошибка 503 Service Unavailable

Ошибка 503 Service Unavailable — это уведомление, которое отправляет сервер, чтобы сообщить о появлении технических неполадок и временной невозможности обработать запрос пользователя. Сообщение появляется на веб-странице, которую пытался открыть посетитель, если на сайте есть проблемный скрипт, на сервер поступает больше запросов, чем он может обработать, или на устройстве и сетевом оборудовании пользователя возникли проблемы с настройками.

Ошибка 503 на сайте означает, что сервер в порядке, но в данный момент недоступен. Чтобы хостинг-компьютер снова начал корректно отвечать браузеру, необходимо найти причину поломки. Это поможет выбрать правильное решение проблемы. Перечислим возможные источники «Error 503»:

• DDoS-атаки и вирусы, приводящие к перегрузке сервера;
• несогласованная работа компонентов веб-страницы (медиаконтента, стилей и скриптов) — элементы каждого уровня запрашиваются и отправляются отдельно;
• последствия хотлинка — сервер тратит трафик и другие вычислительные ресурсы на ответ посетителям других сайтов (если в чужие веб-страницы встроены файлы, хранящиеся на вашем сервере);
• непрерывное обращение к веб-серверу одного из элементов сайта — плагина, виджета, темы;
• сканирование сайта поисковыми роботами и парсерами;
• конфликты плагинов CMS;
• отключение сервера для обслуживания;
• направление большого количества тяжелых запросов к базе данных;
• наличие недостаточно оптимизированных скриптов;
• отправка объемных статичных файлов при помощи скриптов;
• работа почтового сервера — регулярная рассылка большого количества сообщений;
• подключение к удаленному серверу — может привести к лишним HTTP-запросам, тайм-аутам, обрывам связи и т. д.

Пользователю не стоит сразу отказываться от попыток восстановить работоспособность сайта и искать новый сервис. Error 503 может возникнуть из-за проблем с его компьютером, модемом, операционной системой, программным обеспечением и браузером. Если не устранить причину сбоя, ошибка будет систематически возникать и при посещении других веб-ресурсов. К тому же от него не требуется выполнения сложных действий или больших временных затрат — проверка наличия проблем на стороне пользователя займет всего несколько минут.

Как исправить ошибку 503 владельцу сайта

К ошибке HTTP 503 чаще всего приводят сбои, происходящие на сервере. Их исправление — ответственность владельца веб-сайта. Решение некоторых проблем не требует особых навыков, для других придется обратиться к вебмастеру или техническому специалисту с опытом в администрировании серверов.

Перезагрузка сервера

1. Выберете нужный заказ и откройте вкладку «Администрирование».

2. Перейдите в пункт «Управление операционной системой» и нажмите кнопку «Перезагрузить».

На перезапуск системы уйдет всего несколько минут.

Автоматическое обслуживание

Даже хорошо оптимизированный веб-ресурс не может работать 100% времени. Сервер и расположенный на нем сайт могут стать временно недоступными при выполнении некоторых видов технических работ:

• установке обновлений операционной системы и приложений;
• проверке безопасности системы и поиске вредоносных программ;
• автоматическом обновлении CMS и ее компонентов (тем, плагинов) и так далее.

График проведения мероприятий по автоматическому обслуживанию сообщается администраторам сайтов заранее. Если предупредить пользователей о возможном появлении проблем с доступом к веб-ресурсу в определенный период времени, можно сократить количество отказов от просмотра сайта при появлении ошибки 503.

Проверка настроек конфигурации брандмауэра

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

Если сайт недоступен и установить причину своими силами не удалось, обратитесь в службу технической поддержки хостинга. Специалист саппорта сообщит о технических работах и времени их окончания или поможет установить другой источник ошибки 503. В Интернет Хостинг Центре обратиться за помощью можно через раздел «Задать вопрос» в панели управления хостингом или через чат. При создании тикета необходимо подробно описать проблему и приложить скриншот.

Снижение нагрузки на сервер

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

1. Установка защитного экрана, например, CloudFlare, для защиты от хакерских атак и других угроз безопасности.
2. Оптимизация и удаление лишних скриптов для быстрой обработки запросов.
3. Выбор антилич-плагина, поддерживаемого вашей CMS, для защиты от хотлинка.
4. Удаление компонентов, постоянно обращающихся к серверу.
5. Запись в robots.txt пользовательских приложений (user agent), создающих нагрузку на сайт.
6. Проверка совместимости плагинов и тем друг с другом путем их попеременного отключения и тестирования работы сайта без них.
7. Обмен объемными файлами большого размера по протоколу FTP.
8. Организация рассылки в период сниженной нагрузки на сервер, например, ранним утром.
9. Контроль над количеством email-сообщений, отправляемых одновременно.

Как решить проблему, если вы — пользователь

Ошибка 503 происходит на сервере, и если ее обнаружил пользователь веб-ресурса, он может сообщить об этом владельцу сайта и подождать устранения проблемы. В получении контактов поможет сервис Whois, который проверяет регистрационные данные домена и содержит информацию о его арендаторе. Однако такое решение может занять большое количество времени, кроме того, не часто, но код 503 может появляться из-за ошибок на компьютере и сетевом оборудовании пользователя. Что пользователь может предпринять самостоятельно, чтобы убедиться, что он не является причиной временно отсутствия доступа к веб-ресурсу:

1. Отключите от питания сетевое оборудование на три минуты. Если ошибка происходила из-за проблем с IP пользователя, после включения роутера адрес поменяется и сайт снова станет доступным.
2. Перезагрузите модем. Если причина в ПО внешних устройств, передающих вам трафик, может помочь перезагрузка сетевого оборудования.
3. Очистите кэш и другие временные файлы в браузере. Для этого воспользуйтесь сочетанием клавиш Ctrl+F5.
4. Смените браузер или перезапустите его. Это поможет избавиться от ошибок в текущей сессии и понять, является ли браузер источником ошибки.
5. Перезагрузите операционную систему. Сбой в ОС и программном обеспечении будет исправлен автоматически при новом запуске компьютера.

Заключение

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

Информационные

Upgrade:

RFC 8297 (Experimental)

Успешные

• GET: «ПОЛУЧИТЬ». Запрошенный ресурс был найден и передан в теле
  ответа.
• HEAD: «ЗАГОЛОВОК». Заголовки переданы в ответе.
• POST: «ПОСЫЛКА». Ресурс, описывающий результат действия сервера на
  запрос, передан в теле ответа.
• TRACE: «ОТСЛЕЖИВАТЬ». Тело ответа содержит тело запроса полученного
  сервером.

Сообщения о перенаправлениях

«Перемещён на постоянной основе». Этот код ответа значит, что URI
запрашиваемого ресурса был изменён. Возможно, новый URI будет
предоставлен в ответе.

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

302 Found

POST

POST

«Перенаправление на постоянной основе». Это означает, что ресурс
теперь постоянно находится в другом URI, указанном в заголовке
Location: HTTP Response. Данный код ответа имеет ту же
семантику, что и код ответа 301 Moved Permanently, за
исключением того, что агент пользователя не должен изменять
используемый метод HTTP: если POST использовался в первом
запросе, POST должен использоваться и во втором запросе.

Примечание: Это экспериментальный код ответа,
Спецификация которого в настоящее время находится в черновом виде.

draft-reschke-http-status-308

Клиентские

GET

HEAD

HTTP механизмы предварительного соединения

баг 634278

Этот ответ отсылается, когда запрос конфликтует с текущим состоянием
сервера.

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

Запрос отклонён, потому что сервер требует указание заголовка
Content-Length, но он не указан.

Размер запроса превышает лимит, объявленный сервером. Сервер может
закрыть соединение, вернув заголовок Retry-After

Range

Expect

Серверные

GET

HEAD

Retry-After: