503 ошибка сервера что значит на какой стороне ошибка
Ошибки 500, 502, 503 и 504 в картинках: что означают и как исправить
Коды ошибок, которые начинаются с цифры 5, говорят о проблемах на стороне сервера. Но это не значит, что советы по их исправлению будут интересны только администраторам выделенных серверов. Узнаем, что нужно делать с пятисотыми ошибками и владельцу VPS, и пользователю виртуального хостинга.
500 Internal Server Error (Внутренняя ошибка сервера)
1. Проверьте сайт, созданный с помощью CMS, на наличие проблем с плагинами или ошибок в коде. В этом вам могут лог-файлы. При обнаружении проблемного плагина обновите его или верните прежнюю версию. Если это не помогло, откажитесь от него. Если ошибка произошла после обновления CMS, проведите обновление повторно.
3. Убедитесь, что права доступа к файлам, папкам и скриптам выставлены верно. Для папок рекомендуется значение 755, для скриптов — 600, а для других файлов — 644. При других вариантах прав доступ к сайту может блокироваться в целях безопасности.
4. Проверьте, всё ли в порядке со скриптами. Возможно, какой-то из скриптов слишком медленный или время ожидания ответа от сервера слишком мало. Если при просмотре лог-файлов выяснится, что какой-то из скриптов незапланированно требует слишком много памяти, оптимизируйте его или удалите. А если обнаружится, что какой-то из скриптов вовсе не запускается, убедитесь, что функция прописана верно, поддерживается сервером и соответствует используемой версии PHP.
5. Отдельно обратите внимание на CGI-скрипты: вероятно, строки в них имеют не те окончания, что исправляется загрузкой скриптов через FTP в режиме ASCII. Также некорректная работа CGI-скриптов может быть причиной ошибок в HTTP-заголовках, что тоже приводит к ошибке 500. Либо же имеются ошибочные директивы, предназначенные для работы со скриптами.
502 Bad Gateway (Ошибочный шлюз)
Разбираться с этой ошибкой нужно лишь тогда, когда она появляется регулярно. А говорит она о перегруженности сервера или о неполадках в его работе, в связи с чем он посылает недопустимые для продолжения работы ответы.
1. Перезагрузите страницу. Зайдите на любой другой сайт, которой точно должен работать в данный момент. Это поможет узнать, есть ли у вас доступ к интернету в принципе. Если доступ есть, очистите файлы cookies в браузере, а затем посетите сайт снова.
2. Убедитесь, что на ваш сайт не совершается DDoS-атака. В противном случае обратитесь к хостинг-провайдеру.
3. Если на вашем ресурсе фиксируется значительный рост посещаемости, то подберите более продвинутые условия хостинга, чтобы ошибка не появлялась вновь.
4. Проверьте нагрузку на сервер. Если лимит превышается, необходимо увеличить объём оперативной памяти.
5. Посмотрите настройки сервера. Возможными поводами для появления ошибки 502 могут быть:
• неполадки после установки обновлений;
• превышение лимитов на число обращений к внешним ресурсам и на время ответа сервера;
• некорректные лимиты в файлах конфигурации ini;
• превышение лимита на число php-cgi-процессов;
• недостаточная оптимизация скриптов;
• недостаточная оптимизация запросов;
• неправильная работа модулей (если ошибка возникает при обращении к скриптам конкретного расширения).
6. Если ошибка продолжает появляться и если вы пользуетесь виртуальным хостингом, уточните у хостинг-провайдера, не создают ли другие сайты на сервере чрезмерную нагрузку.
503 Service Unavailable (Сервис недоступен)
Сервер не работает из-за перегрузок. Либо же происходит плановая перезагрузка или отключение сервера: в этом случае вместе с сообщением об ошибке после слов «Retry-After» должно отображаться время, когда сервер вернётся в работу. Если же ошибка 503 появляется часто и не по причине плановых работ, то это говорит о неполадках, которые следует устранить.
1. Сначала просто подождите. Возможно, причина в длинной очереди запросов к серверу, что не требует вмешательства.
2. Как и в случае с ошибкой 502, удостоверьтесь, что на сайт не производится DDoS-атака.
3. Если используется связь с удалённым сервером, убедитесь, что она стабильная, а тайм-аут ожидания ответа невысокий.
4. Проверьте, не слишком ли активно посещают ваш сайт поисковые роботы. Если это имеет место быть, ограничьте их активность.
5. Удалите тяжёлые или вовсе ненужные плагины и компоненты.
6. Если возможно, оптимизируйте подгрузку файлов сайта, чтобы снизить число запросов.
7. Организуйте передачу больших статичных файлов напрямую, а не через скрипты.
8. Оптимизируйте почтовую рассылку: распределяйте отправку писем по времени, запускайте рассылку в часы наименьшей нагрузки.
9. Оптимизируйте SQL-запросы, выявите самые медленные из них с помощью лог-файлов.
504 Gateway Timeout (Шлюз не отвечает)
Один из серверов не дождался ответа от вышестоящего сервера, о чём сообщает кодом 504.
1. Перезагрузите страницу, убедитесь в стабильности работы сетевых устройств.
2. Как и в предыдущих случаях, проверьте работу скриптов. Важно, чтобы они выполнялись не слишком долго, а внешние соединения происходили успешно.
3. При чрезмерной нагрузке на сервер увеличьте его ресурсы или оптимизируйте сайт.
4. Если возможно, увеличьте время ожидания при использовании nginx как прокси-сервера для Apache. Для этого добавьте эти строки в блоке server в файле nginx.conf:
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
5. Если у вас нет возможности менять настройки сервера, обратитесь к хостинг-провайдеру.
Также посмотрите ответы на вопросы из нашего раздела FAQ:
Кстати, недавно мы в целом рассказали о кодах состояния сервера, к которым относятся в том числе и коды ошибок.
Ошибка 503 на сайте
В этой статье мы рассмотрим возможные причины возникновения 503 ошибки на сайте и способы её устранения.
Что такое ошибка 503 Service Unavailable
Эта ошибка означает, что сервер не готов обработать запрос в данный момент. Подразумевается, что это временно и нужно повторить попытку позже. Но это не всегда так.
503 Service Temporarily Unavailable
HTTP 503 — это код состояния, который содержится в ответе веб-сервера и показывает, успешно ли выполнен запрос. Коды 5XX принадлежат классу серверных ошибок. В спецификации RFC 7231 указано, что код 503 сообщает о том, что сервер в настоящее время не может обработать запрос из-за временной перегрузки или планового технического обслуживания.
Если вы встретили эту ошибку, скорее всего, веб-сервер не успевает обрабатывать все поступающие на него запросы из-за нехватки ресурсов или технического обслуживания. Однако бывает, что ошибка 500 возникает не со стороны сервера, а со стороны клиента. Поэтому сначала стоит определить, на чьей стороне проблема.
503 Сервис недоступен со стороны посетителя
Если вы не являетесь администратором сайта, на котором встретили ошибку, проверьте, нет ли проблем с вашей стороны. Для этого:
Если после нескольких перезагрузок страницы ошибка всё равно возникает, попробуйте открыть сайт через другой браузер. Если в другом браузере ошибка не воспроизводится, очистите кэш на своем браузере. Например, в Google Chrome нажмите комбинацию клавиш Ctrl+Shift+Delete:
Эти действия помогут понять, с чьей стороны проблема. Если вам самостоятельно не удалось решить проблему, то остаётся только ждать решения проблемы владельцем сайта. Скорее всего, это массовая проблема, и её решением уже занимаются. Попробуйте открыть сайт позже.
Ошибка недоступности, если вы владелец сайта
Частые ошибки 503 на вашем сайте могут негативно сказаться на позициях в поисковых системах и привести к снижению трафика. Посетители могут просто не вернуться на ваш сайт. Не игнорируйте проблему и сразу приступайте к её решению. Вот несколько вариантов решения:
На любом хостинге есть ограничения и лимиты, которые не стоит превышать. Их устанавливает хостинг-провайдер. Превышение лимитов может привести к возникновению проблем на сайте, в том числе и к ошибке 503. Изучить характеристики вашего тарифного плана вы можете на сайте хостинг-провайдера. Для хостинга REG.RU действуют следующие технические ограничения.
Хостинг может не справляться с большим количеством посетителей на сайте. В этом случае может помочь смена тарифного плана или переезд к новому хостинг-провайдеру.
Бывает, что неактуальные версии плагинов и других компонентов движка нарушают работу сайта. Попробуйте по очереди отключать установленные плагины вашей CMS и проверять работоспособность сайта после каждого. Если ошибка не возникает после отключения очередного плагина, обновите этот плагин до последней версии. Возможно, что в новой версии разработчик уже внёс исправления. Если обновление не помогло, плагину нужно искать альтернативу.
Регулярно обновляйте CMS и её компоненты. Зачастую обновления направлены на оптимизацию работы движка, устранение уязвимостей, борьбу с багами, повышение безопасности и быстродействия. Удалите все ненужные компоненты, которыми не пользуетесь. Оставьте только самые необходимые, чтобы уменьшить нагрузку на сервер.
Проанализируйте скрипты сайта. К HTTP Error 503 может привести неправильная работа скриптов на сайте. Выполните их диагностику и убедитесь, что на сайте не включен режим технических работ.
Не загружайте крупные файлы при помощи PHP. Очень часто хостинг-провайдер ограничивает время выполнения скрипта, и вы можете не уложиться в этот лимит. Ещё одним минусом передачи файлов через PHP является создание отдельного PHP-процесса, который будет занят загрузкой файла, а не обработкой запросов посетителей. Загружайте файлы по FTP, чтобы уменьшить нагрузку на хостинг.
Запускайте массовые почтовые рассылки в периоды минимальной активности на вашем сайте. Точно так же стоит поступить и с техническими работами на сайте и сервере.
Поисковые роботы могут генерировать большое количество обращений к сайту. Проанализируйте статистику по User-Agent и выясните, какие роботы создают нагрузку. При помощи файла robots.txt задайте временной интервал обращений.
Настройте кэширование средствами CMS или хостинга. В WordPress вы можете настроить кэширование с помощью нашей инструкции: Что такое кэширование и как управлять им в WordPress. В панели управления хостингом тоже часто имеются встроенные инструменты по настройке кэширования.
Запросы к сторонним ресурсам могут замедлять генерацию и отдачу контента, что в итоге может привести к 503 ошибке. Если удалённый сервер недоступен, ваш сайт потратит больше времени на ожидание ответа. Уменьшите тайм-аут ожидания ответа от стороннего ресурса или вовсе откажитесь от таких запросов. Работоспособность сторонних сервисов невозможно контролировать.
Не всегда проблему можно решить самостоятельно. Иногда лучше сразу обратиться за помощью к опытным специалистам. Если считаете, что вашего опыта и умений недостаточно для решения проблемы, свяжитесь со службой поддержки вашего хостинг-провайдера.
Ошибка 503 на хостинге REG.RU
Ошибка может возникнуть из-за превышения лимита на количество PHP-процессов. Согласно техническим ограничениям, на тарифных планах Host максимальное количество процессов PHP составляет 4, на тарифных планах VIP — 32.
Чтобы посмотреть запущенные PHP-процессы, подключитесь по SSH и выполните следующую команду:
Чтобы завершить текущие php-процессы, измените версию PHP на отличную от текущей. Затем включите версию PHP, которая была установлена ранее.
Максимальное количество процессов на тарифных планах Host составляет 18, а на VIP — 48. Если общее количество процессов (PHP, IMAP, Cron и др.) будет превышено, то может возникнуть ошибка «503 временно недоступен».
Чаще всего причиной является большое количество процессов IMAP из-за многочисленных подключений к ящикам. В качестве решения проблемы попробуйте подключаться к почтовому серверу по протоколу POP3. Это позволит уменьшить общее количество процессов.
Что означает недоступность службы с ошибкой 503
Ошибка 503 Service Unavailable Error возникает, когда веб-сервер временно не может обработать запрос, который был отправлен пользователем. Почти всегда ошибка возникает на самом сайте, и вы ничего не можете с этим поделать, но попробуйте обратиться к сервису ещё раз позже. Тем не менее, есть несколько быстрых решений, которые можно попробовать реализовать, чтобы решить ошибку.
Что такое ошибка недоступности службы 503
Ошибка недоступности службы 503 указывает на то, что веб-серверу временно не удается обработать запрос. Это может быть веб-сервер, к которому Вы пытаетесь получить доступ напрямую, или другой сервер, к которому веб-сервер пытается получить доступ.
Это называется ошибкой 503, потому что это код состояния HTTP, который веб-сервер использует для определения такого рода ошибки. Ошибка может возникать по ряду причин, но две наиболее распространенные причины – это перегрузка сервера запросами или выполнение технического обслуживания.
Ошибка с кодом 503 отличается от внутренней ошибки сервера с кодом 500. Ошибка 500 возникает, когда что-то мешает серверу обработать ваш запрос, в то время как ошибка 503 означает, что сервер в порядке – он способен обработать ваш запрос, но позже.
Как и в случае других ошибок сервера, веб-дизайнеры могут настроить оформление страницы ошибки 503. Веб-сайты также могут использовать несколько отличные имена для этой ошибки.
Например, вы можете увидеть такие варианты:
Важно помнить, что ошибка 503 является ошибкой на стороне сервера. Это означает, что проблема с веб-сайтом, к которому вы пытаетесь получить доступ, а не с вашим компьютером. Это и хорошая, и плохая новость. Хорошая новость, потому что с вашим компьютером всё в порядке, а плохая, потому что обычно вы ничего не можете сделать, чтобы решить проблему.
Тем не менее, вот несколько быстрых решений, которые вы можете попробовать.
Обновите страницу
Как мы уже упоминали, ошибка 503 указывает на временную проблему, и иногда эта проблема очень временная. Например, сайт может быть перегружен трафиком. Таким образом, обновление страницы всегда стоит попробовать.
Большинство браузеров используют клавишу F5 для обновления, а также кнопку обновления можно найти в адресной строке. Это часто не решает проблему, но занимает всего секунду, так что стоит попробовать.
Предупреждение: обратите особое внимание, если ошибка возникает, когда вы совершаете платеж. Обновление страницы может привести к двойному платежу.
Проверьте, работает ли сайт у других людей
Всякий раз, когда вы не можете открыть сайт (по какой-либо причине), вы можете проверить, есть ли проблемы с подключением у других людей. Существует много инструментов для этого, но один из любимых – https://ping-admin.ru/free_test/. Просто укажите URL, который хотите проверить, и выберите точки доступа.
Если вы получите отчет о том, что сайт не работает для всех, Вам следует подождать восстановления доступности. Если отчет показывает, что сайт работает, то проблема может быть на вашей стороне.
Перезагрузите устройство
Если Вы уже использовали инструмент проверки доступности сайта и он определил, что сайт не доступен только для Вас. Попробуйте зайти через другой браузер.
Вполне возможно, что возникли какие-то проблемы с вашим компьютером или сетевым оборудованием (Wi-Fi, маршрутизатор, модем и т.д.). Простой выполните перезапуск компьютера и ваших сетевых устройств – это может помочь устранить проблему.
Свяжитесь с владельцем веб-сайта
Другой вариант – связаться с владельцем сайта напрямую. Посмотрите контактную информацию на веб-сайте и свяжитесь с ним, передав информацию о проблемах доступности. Если нет контактной формы, Вы можете попробовать связаться с автором веб-сайта в социальных сетях.
HTTP Error 503. Service Unavailable: случай в поддержке хостинга
Начало
Хостинг предоставляет пользователям типичный стек Linux + Apache + Mysql + PHP и оболочку для управления. В нашем случае это ISP Manager 5 business на базе Centos 7 с конвертацией в CloudLinux. Со стороны административной части, CloudLinux предоставляет инструменты для управления лимитами, а так же PHP-селектор с различными режимами работы (CGI, FastCGI, LSAPI).
В этот раз к нам обратился клиент со следующей проблемой. Его сайт на движке WordPress периодически начал отдавать 503 ошибку, о чём он нам и сообщил.
Коды ответа, начинающиеся с 50х, относятся к проблемам на стороне сервера. Это могут быть проблемы как самого сайта, так и веб-сервера, который их обслуживает.
Типичные ситуации, при которых мы получаем следующие ошибки:
При выполнении диагностики данных ошибок, первым делом проверяем журналы веб-сервера. Обычно, этого достаточно, чтобы определить виновника и исправить проблему.
Касаемо 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. В логах контейнера присутствовали сообщения:
Как раз, среди этих сообщений были сообщения о прерванном подключении исследуемого сайта. Это дало предположение, о том, что подключение к СУБД выполняется некорректно. Для проверки мы развернули копию сайта на тестовом домене, сконвертировали базу данных сайта под нативную в Centos 7 версию СУБД 5.5.65-MariaDB. На тестовом сайте выполнили несколько сотен запросов с помощью утилиты curl. Ошибку воспроизвести не удалось. Но этот результат был предварительным и после конвертации БД на рабочем сайте проблема так и осталась.
Таким образом, проблема некорректного подключения к СУБД была исключена.
Следующим предположением было проверить — нет ли проблем с самим сайтом. Для этого подняли отдельный виртуальный сервер, на нём подняли максимально схожее окружение. Единственное существенное отличие — отсутствие CloudLinux. На тестовом сервере проблему воспроизвести не удалось. Итак, мы определили, что в коде сайта всё в порядке. Тем не менее, пробовали так же отключать плагины WordPress, но проблема так же сохранялась.
В результате, пришли к тому, что проблема на нашем хостинге.
В ходе анализа журналов других сайтов было обнаружено, что проблема наблюдается на многих из них. Порядка 100 шт. на момент проверки:
В ходе тестирования обнаружили, что только что установленная чистая 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 предлагается выполнять трассировку найденных в системе процессов:
Команда была доработана, с целью записи всех процессов в файлы с указанием их идентификаторов.
При просмотре файлов трассировок, мы видим в некоторых одинаковые строки:
Если взглянуть на описание структуры сигналов, отправляемых процессами, то увидим, что
Указывает на идентификатор процесса, отправившего сигнал.
На момент изучения трассировок, процесса с PID 42053 в системе уже нет, поэтому в процессе захвата трассировок решили отслеживать так же процессы, отправившие сигнал SIGHUP.
Под спойлером описаны действия, которые позволили определить что это за процесс, а так же получить его трассировку и дополнительную информацию, о том, каким процессам он отправляет сигнал SIGHUP.
Ждём пока в консоли 1 появятся сообщения, при этом в консоли 4 видим статус запроса с кодом ответа 503, прерываем выполнение в консоли 4.
Данный процесс выполнялся в системе с периодичностью раз в минуту.
Делаем трассировку нескольких процессов cagefsctl, чтобы отследить хотя бы один от начала до конца:
Далее изучаем что он делал, например:
Так же были получены идентификаторы процессов, которые были завершены сигналом SIGHUP. Завершённые процессы были процессами PHP, выполняющимися в данный момент.
Полученные данные были переданы в поддержку CloudLinux с целью уточнить легитимность данного процесса и должен ли он работать с такой периодичностью.
Единственная зацепка в данном случае осталась — проверить, кто является родительским процессом 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, проблема была решена. Теперь наш хостинг работает стабильно. А нами был получен опыт, который пригодится нам в будущей работе.