The remote server returned an error 503 server unavailable

Cause of HTTP Error 503

HTTP Error 503 is another very common error you might face with an IIS-hosted website in addition to the 500 – Internal server error.

The primary reason for this error is a stopped or disabled application pool. The application pool is the IIS component that initiates a worker process, which then allows the web server to process incoming requests for a website. When something is wrong with the application pool, the web server throws an HTTP Error 503.

Rapid-Fail Protection

There can be various reasons for an application pool failure, such as an unhandled exception in the code, an expired password for the application pool identity, or something else. By default, IIS is configured to disable a malfunctioning application pool if its worker process faces five consecutive crashes within a period of five minutes. This setting is known as Rapid-Fail Protection, which is available under the Advanced Settings of an application pool. This is shown in the following screenshot:

• Enabled—The value True indicates that the rapid-fail protection feature is active, which is the default. Set the value to False to disable it.
• Failure Interval (minutes)—The time interval to specify the number of minutes (by default, 5) to count the failures for a process.
• Maximum Failures—The maximum number of failures that are allowed within the time interval mentioned above (by default, 5).

While troubleshooting an application pool-related problem, you can modify these parameters, if needed.

Debugging HTTP Error 503

To determine the exact reason why the application pool is disabled or stopped, open the Event Viewer, navigate to the System log, and look for error or warning events whose source is Windows Process Activation Service (WAS). WAS is responsible for starting/stopping the application pool and keeping track of worker processes in the IIS.

The following screenshot shows that the application pool is disabled because its identity is invalid:

If you couldn’t find anything in the System log, take a look in the Application log since the ASP.Net-related exceptions are logged there. As discussed above, when a worker process experiences five fatal errors or exceptions within five minutes, rapid-fail protection kicks in and automatically disables the faulting application pool.

Based on event logs, if you conclude that the reason for application pool failure is a bug in the application code, but you still want to keep the application pool running until your developer fixes it, you could temporarily adjust the behavior of rapid-fail protection, either by increasing the Maximum Failures or the Failure Interval to a higher value. You could even disable this feature by using the following PowerShell command:

(Get-IISAppPool awesomewebsite.com).failure.rapidFailProtection
Set-WebConfigurationProperty '//*[@name="awesomewebsite.com"]//failure' -Name rapidFailProtection -Value $False

Remember that the rapid-fail protection feature is there for the safety of the web server, so disabling it shouldn’t be considered a solution to the problem. Instead, fixing the underlying cause (or bug causing the behavior) in the application code is really important. Anyway, disabling it sometimes comes in handy if developers are taking longer to fix the bug; meanwhile, you want to keep the web application up and running. Once rapid-fail protection is disabled, the web server won’t disable the faulting application pool, and visitors will no longer see HTTP Error 503.

Fixing HTTP Error 503

A simple resolution for HTTP Error 503 is to start the application pool corresponding to your website. If you get an application pool identity-related error or warning, make sure the username and password for the identity are correct. If a custom username is used, make sure its password is not expired. If possible, set the password to never expire for that user.

If the application pool stops repeatedly but there is no application pool identity-related error in the system log, the issue is likely due to some fatal error or unhandled exception in the code. In that case, the application log can give you some useful insights. The following screenshot shows a typical error logged in the application log that occurred due to an unhandled exception:

If you see such errors or warnings, notify your application developers, and ask them to fix the exception. If needed, share the detailed error message recorded in the event log.

Common 503 substatus codes

The following table covers the common HTTP 503 substatus codes, along with their possible causes and troubleshooting advice:

%SystemRoot%System32inetsrvappcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

%SystemRoot%System32inetsrvappcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:100000

Subscribe to 4sysops newsletter!

Conclusion

You can see that, like most IIS errors, HTTP Error 503 can be fixed with the help of detailed errors and failed request tracing. However, in the event of application pool-related errors, the HTTP.sys driver throws the 503.0 error because the application pool isn’t available to handle the request. Thus, the detailed error or failed request tracing rule is not even triggered. In such situations, you can rely on Windows event logs to troubleshoot.

Imagine someone searches for a topic and finds your website on page one of Google. When they click through to your website, though, their eyes land on a bland webpage that says «Service Unavailable».

What do you think they’ll do when they find your website on Google again? Odds are, they’ll skip over it and click on the next link. If visitors are looking for answers and you’re promising them those answers, but you can’t deliver because something’s wrong with your website, they’ll lose trust in your brand.

Unfortunately, if your website experiences a 503 Service Unavailable Error, there’s no silver bullet solution. You have to investigate what’s actually causing the issue, because even though these types of errors indicate what happened to your website, they don’t tell you why it happened.

To help you fix your 503 Service Unavailable Error and avoid losing potential customers, check out our guide on what exactly the issue is and its most common solutions.

When your website is experiencing a 503 Service Unavailable Error, your site’s visitors will land on an error page. Fortunately, Airbrake recommends five common solutions for troubleshooting most 503 Service Unavailable Errors.

1. Restart your server.

Sometimes, there will be congestion in the server chain that hosts your website. One of the most effective ways to open up and refresh it is to simply restart your web server. If your website is hosted on multiple servers, make sure you restart all of them to get it running again.

2. Check to see if your web server is going through maintenance.

Most web servers shut down when they’re going through maintenance. If you can access your server’s administration settings, check the configuration options to see when automatic maintenance sessions are scheduled. If you’d rather have complete control over your server’s maintenance, you can disable these automatic updates in the configuration options, too.

3. Fix faulty firewall configurations.

Your firewall is your website’s gatekeeper, protecting your site from malicious visitors or distributed denial-of-service (DDoS) attacks. Sometimes, a faulty firewall configuration will cause your firewall to deem requests from a content delivery network as an attack on your server and reject them, resulting in a 503 Service Unavailable Error. Check your firewall configuration to pinpoint and fix the issue.

4. Sift through your server-side logs.

There are two types of server-side logs — applications logs and server logs. Application logs recount your website’s entire history, letting you see the web pages requested by visitors and the servers it connected to. Server logs provide information about the hardware running your server, revealing details about its health and status. Sift through both types of server-side logs to uncover any alarming information about your server or website.

5. Comb through your website’s code to find bugs.

If there’s a mistake in your website’s code, your web server might not be able to correctly answer requests from a content delivery network. Comb through your code to find bugs or copy your code into a development machine. It’ll perform a thorough debug process that will simulate the exact situation your 503 Service Unavailable Error occurred in and allow you to find the exact moment things went wrong.

Any time there’s an error on your site, it’s important to fix it as soon as you can. If customers get errors, they probably won’t come back to your page.

Editor’s note: This post was originally published in January 2019 and has been updated for comprehensiveness.

Ошибка 503 (ERROR Service Unavailable с англ. «Сервис временно недоступен») — это код ответа сервера, который говорит о том, что по техническим причинам сервер не в состоянии обработать текущий запрос. Простыми словами, ошибка 503 — это ответ сервера при его медленной работе, большом количестве запросов или подвисания определенных скриптов на сайте.

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

Почему возникает ошибка 503

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

Группа 1. Излишнее количество запросов, отправляемых к серверу

Здесь можно выделить как минимум пять источников ошибки.

1. Хакерские атаки. Подобная техника вывода сайта из строя характерна, например, для DDoS-атак.

Решение: установите на свой сайт CloudFlare или другой защитный экран.

2. Разобщение ресурсов. Необходимые для отображения страницы компоненты загружаются в качестве самостоятельных запросов. Вместо того чтобы загружать медиафайлы (например, изображения или анимации), JavaScript и «стили» одним файлом, все эти компоненты разрознены. И, соответственно, они отправляются по разным запросам.

Решение: удалите лишние неиспользуемые скрипты, внедрите кэширование страниц, уменьшите размер изображений, обязательно продиагностируйте CSS.

3. Внедрение скриптов или URL. Если вы пытаетесь задействовать JavaScript на чужом сайте, будьте готовы, что сервер выдаст 503-й ответ. То же самое касается попыток внедрения информеров или любых URL на изображения сайта.

Решение: установка антилич-плагина для используемой CMS или же самостоятельное прописывание такого кода в файле htaccess:

   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?ваш сайт.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.yandex.ru
   [NC]RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.com [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.ru [NC]
   RewriteCond %{REQUEST_URI}

   !^/название_изображения_которое_будет_выводиться_на_других_сайтах.png [NC]
   RewriteRule .(gif|jpg|jpeg|png|swf)$ http://

   Ваш_сайт.ру/название_изображения_которое_будет_выводиться_на_других_сайтах.png [R,NC]


Вам понадобится кастомизировать этот код под свои нужды. Например, так:

   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?http://ваш_сайт.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.yandex.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.com [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.ru [NC]
   RewriteCond %{REQUEST_URI} !^/antipic.jpg [NC]
   RewriteRule .(gif|jpg|jpeg|png|swf)$ http:/ваш_сайт.ru/antipic.png [R,NC]

4. Определенный компонент сайта постоянно отправляет запросы на веб-сервер. Это вредно, бесполезно и ухудшает быстродействие сервера + увеличивает скорость загрузки вашего сайта. В качестве такого компонента могут выступать разные элементы: виджет, установленная тема или какой-либо плагин. Допустим, вы захотели внедрить на коммерческую страницу окно с чатом. Если оно создано на базе AJAX — а это весьма распространенный сценарий — готовьтесь к бесконечному количеству запросов и увеличению нагрузки на сервер.

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

5. Нагрузка, создаваемая краулерами поисковых систем или других сервисов. Пауки «Гугла», «Яндекса» и других поисковых систем автоматически обходят все сайты в интернете. Да, вы можете добавить рекомендательные директивы в файл robots.txt, но чаще всего краулеры их не соблюдают. Еще более серьезную нагрузку могут создавать пауки сторонних сервисов, например, краулеры Netpeak, Megaindex, Serpstat.



Решение: в robots.txt укажите конкретных user-agent’ов, которые создают серьезную нагрузку на сайт. Если это не помогло, попробуйте заблокировать конкретные IP-адреса. В случае с краулерами такой подход чаще всего не сработает: у них обычно не статические IP.

6. Плагины вCMS. Если вы вебмастер и проблема возникает на вашем сайте, обращайте внимание на установленные в CMS плагины: часто они конфликтуют друг с другом или, например, с темой сайта.

Решение: Попробуйте отключить те плагины, которые вы устанавливали недавно и понаблюдайте за проблемной страницей. Если она открылась, значит причина была именно в каком-то из плагинов, а точнее — внутренних ошибках, которые создавал такой плагин. Если вы не знаете, какой именно плагин является причиной ошибки, отключите их все. Затем начните включать поэтапно, а затем проверяйте доступность проблемной страницы. Если дело было в плагине, рано или поздно страница откроется без ошибки. После нахождения плагина-виновника удалите его через административную панель вашей CMS или замените другим с аналогичным функционалом.

7. Отключение сервера. Еще одна причина, о которой мы не сказали выше — временное отключение сервера (например, при возникновении хакерских атак на хостинг или на время выполнения регламентных работ по обслуживанию машин).

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

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

В этой группе можно выделить 5 причин появления сбоя.

1. «Тяжелые» запросы, отправляемые к базе данных MySQL. Если число таких запросов велико, ошибка может появляться время от времени. Решение для вебмастера — глобальная оптимизация запросов, отправляемых в SQL.

Решение: индексация таблицы базы данных непосредственно по колонкам из выборки. MySQL хорош тем, что все «тяжелые» запросы автоматически фиксируются в папке logs:



Вы без проблем найдете все «медленные» запросы и сможете оптимизировать их в дальнейшем, либо просто заменить.

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

Обязательно убедитесь, что проблемная страница может установить соединение с БД MySQL. В противном случае и будет возникать 503 ответ сервера.

2. Слишком «тяжелые» скрипты. Даже 1-2 плохо оптимизированных скрипта могут создавать колоссальную нагрузку на сервер.

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



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

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

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

4. Регулярное использование почтовых сервисов. Каждый раз, когда скрипт e-mail-рассылки инициализируется, возрастает нагрузка на сервер.

Решение: изучайте лимиты по суммарному числу емейлов, которые допустимо отправлять через используемый вами хостинг.

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

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



5. Взаимодействия с программным сервером. Самый частый сценарий — подключение к удаленному серверу. Это сулит дополнительные сложности: совершение ненужных HTTP-запросов, появление тайм-аутов, обрывы связи, излишнее ожидание ответа.

Решение: соединение с таким веб-сервером нужно минимизировать, а лучше вообще избавиться от него.

Как еще исправить ошибку 503: дополнительные советы пользователю

1. Напишите в саппорт сайта и уточните, почему не открывается страница. Обычно email для технических вопросов вынесен отдельно на странице контактов.



2. Отключите сетевое оборудование (например, Wi-Fi роутер) примерно на 2-3 минуты. Это поможет, если ошибка возникает на уровне IP-адреса. При перезагрузке сетевого оборудования вашему устройству будет присвоен новый IP, а проблемы с открытием страницы будут решены. Этот способ сработает только в том случае, если ваш интернет-провайдер присваивает вам динамический, а не статический адрес.
3. Обновите проблемную страницу с очисткой кэша. Для этого используйте сочетание горячих клавиш Control + F5. Полезно также целиком очистить все временные файлы в используемом браузере.



При такой очистке вы автоматически выйдете из всех аккаунтов (на всех сайтах), где прошли авторизацию ранее.

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

Резюме

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