Ошибка 503 php - Не ошибается лишь тот, кто ничего не делает!

Asked
13 years, 1 month ago

Viewed
80k times

A former developer wrote or client-server api in PHP. It simply sends messages as xml using post/response in a very simplistic fashion. The problem is that even when there is an error (ex: invalid arguments passed into the server side) we get a HTTP 200 response with a page like this

<h4>Unknown error!</h4>

In firebug I can see that the actually HTTP response is a 200. How can we send a different response (ie:503) when we programatically detect in our php code that it is appropriate to do so.

asked May 3, 2010 at 20:11

benstpierrebenstpierre

32.6k50 gold badges171 silver badges288 bronze badges

I worked on a site that had been hacked and had to use HTACCESS to do this.

<IfModule mod_rewrite.c>

 RewriteEngine on

 # let this (iescaped) IP address see the real site:
 # RewriteCond %{REMOTE_ADDR} !^123.45.67.89

 RewriteCond %{REQUEST_URI} !/maintenance.php$ [NC]

 RewriteCond %{REQUEST_URI} !.(jpe?g?|png|gif|css|js) [NC]

 RewriteRule .* /maintenance.php [R=503,L]

</IfModule>

answered Jun 28, 2014 at 22:13

Ben RacicotBen Racicot

4,98111 gold badges63 silver badges122 bronze badges

On top of your script (or really, before any output is sent as a response):

<?php header("HTTP/1.0 404 Not Found"); or any other HTTP status code.

answered May 3, 2010 at 20:15

Источник

Время на прочтение
7 мин

Количество просмотров 29K

Работа в поддержке хостинга в основном однотипная, большинство запросов от клиентов решаются по проработанной схеме, но иногда всё же приходится сталкиваться с нетривиальными проблемами. Тогда главная задача инженера — найти тот самый — единственно верный путь, который приведёт к её решению. В этой статье хочу рассказать о том, как мы столкнулись с плавающей ошибкой «HTTP Error 503. Service Unavailable» на нашем shared-хостинге, как пытались её отловить, провели диагностику и получили неожиданный финал.

Начало

Хостинг предоставляет пользователям типичный стек 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.

Методика трассировки

Консоль 1.

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

Консоль 2.

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

Консоль 3.

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;

Консоль 4.

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.: Надеюсь, Вам было интересно ознакомиться с материалом статьи, а кому-нибудь она поможет быстрее решить подобную проблему.

Источник

If your site returns this error “503 Service Temporarily Unavailable“, it usually indicates a problem with the server overloading by your PHP scripts.

Each webhosting server has preserved 5 PHP processes, which can operate simultaneously. This means that no more than 5 requirements for executing PHP script on one site at one time may be processed. To the contrary, it does not mean that the other requests were rejected – they are placed in a queue and waiting for processing. Usually, 5 PHP processes are entirely sufficient – if you have a properly optimized site and using caching, you will not find this problem.

It may happen that other requests are unable to gain free process PHP in timeout. That means that all 5 PHP processes are doing something for a long time. Then there are pending requests rejected with error 503 after some time.

Causes of the problem and the solution

The essence of the problem is that PHP scripts on your site are not able to perform requests – either because there are too much of them (too busy web), or because they have been waiting for something for a too long time and for some reason (unavailable external sources).

If you’re a programmer, try to find out which activity in your PHP scripts spend most of time (which action is blocked)

The goal is to shorten the execution time of a PHP request as much as possible. This allows you to “check in” multiple requests over time.

Possible causes and solutions:

Incorrect optimized PHP application. Your application is not adapted for a large number of requests. Determine whether you are using a CMS which allows caching. If so, turn it on. This significantly shortens the period of the script execution, often it can radically reduce the number of carried SQL queries to the database and overall significantly speed up your site – for example caching in WordPress.
Too many records in the database – a typical problem is that the application records all visitors accesses or some similar extensive statistics to the database, which is completely inappropriate, database is very busy and your site over time significantly slows.
Inappropriate database tables, incorrect or missing database indexes – PHP waiting for the results a very long time for SQL queries(viz. MySQL – optimization of performance, indexes).
PHP application trying to connect to some external resource which is unavailable – if you are downloading external data via RSS, SOAP, etc., but the destination server could not be connected or does not respond or overloaded – then your PHP script awaits too
A long time running script called by cron – also PHP script called by cron will occupy a PHP process when it is executed. If you have more cron jobs or cron runs for a long time(this may be caused when script downloading data from external source, which is slow or not availlable), could also cause blocking of all PHP processes for your web.
Files download via PHP script – If you offer to your visitors to download any large files such as the ones you refer to the PHP script that reads the file and sends it to the output (eg, ReadFile () or file_get_contents ()), then you will occupy the PHP process during the period of downloading. Therefore if something will be downloaded by 5 people at same time, there is no more free PHP process. Solve downloads by referring to direct or redirect URL adress of the file, do not use downloading via PHP.
A large number of files in the wrong directory structure – in one directory should not be located more than thousands of items. For larger numbers, especially if you have incorrectly set the caching or incorrect stored e-shop images in one directory, operations with these files and folders can be radically slowed. With hundreds of thousands or millions of items such a directory is completely unusable.
The administration of CMS is under attack in order to break the admin password. A large number of brute-force password cracking attempts burdens of applications and occupies PHP processes. This situation ыоу цан uncover in AccessLog (see below), then the attacker may be filtered out(for example, by blocking certain IP addresses in htaccess or allow just your IP address for administration).

The solution to this situation can be also upgrading to a higher version of webhosting NoLimit Extra – this tariff offers 10 PHP processes, also higher performance.

However, be warned that this option does not accelerate your scripts, ie shorten the execution time of your PHP script. Just allows running more scripts simultaneously one time (in parallel). So it can deal with the consequences, but not the causes. If the problem is that the execution time of your script is too long (eg in seconds), it is necessary to optimize the particular application.

When this error appears suddenly

Error 503 does not have to be related to the actual number of visitors or changes on the site. More frequent causes are loading some data from a slow or unavailable external source or run a cron job, something that has long retrieved, updates, performs maintenance etc. It might also be that randomly gather larger amount of complex requirements(search in extensive database).

AccessLog, errorlog and how to look for the cause

We do not recognize the cause of specific problem from error log of the server. We will only see the records about the error 503 = timeout while waiting for free process of PHP on webhosting.

For us, the PHP scripts of our customers are like black boxes. We do not know what’s going on inside, what exactly PHP scripts have been waiting for so long or what are they doing. The analyzing and solving of the problem should be done by the customer. For example, it is appropriate to introduce a PHP script with detailed logging of which requirements the are processed and how long did it run the PHP script. Then you can sequentially detect what’s taking so long and what is delaying the entire site.

In the analysis of the problem, it can be useful accesslog – to log accesses to the site. There you will see the specific requirements and period of execution. Accesslog can be activated free for 24 hours in customer administration (in additional services in detail of a particular webhosting), eventually, it can be activated permanently for an additional fee.

Zpětná vazba je dočasně nedostupná, máte-li k návodu dotaz nebo připomínku,
napište nám přes kontaktní formulář.

Источник

Themeisle content is free. When you purchase through referral links on our site, we earn a commission. Learn More

Have you encountered the 503 error on your WordPress site? It’s a common WordPress error that can be fixed by following the steps we have covered in today’s tutorial.

Some of these steps may look technical, but they actually don’t require any deep technical knowledge.

In this article, we will first discuss what caused the 503 error in WordPress, then we will show you all potential solutions and how you can prevent encountering the 503 error in the future.

Let’s dive in!

What is the 503 error? What causes it?

The 503 error occurs when your website server cannot be reached – i.e., the server is unavailable. The reasons for unavailability can be a badly coded plugin or theme, a code snippet gone rogue, a glitch in the server, a DDoS attack, or quality issues with your hosting service overall.

Let’s take a deeper look at each of the causes:

Badly coded plugin or theme:

Commonly, the 503 error appears when you install or update a badly coded plugin or theme. When the plugin or theme cannot function properly, it causes WordPress to throw the 503 error.

Code snippet gone rogue:

Customizing a WordPress site is super easy. You can add some CSS code here, upload a PHP script there, and modify the site based on your needs. But, a piece of bad custom code can cause a lot of trouble. The 503 error you are experiencing could be due to such a bad code snippet.

Technical issues of the server:

Your server could be down because it’s under maintenance, or because of some other scheduled work. Usually, any issues resulting from these reasons disappear after a couple of hours. That said, hosting providers should have mirror servers to ensure that the sites are up and running during maintenance.

A DDoS attack :

Although this does not happen very frequently, the 503 error might have been produced due to an attack made on your website. DDoS attacks, in particular, are often associated with 503 errors. That’s because, in these types of attacks, hackers send a ton of traffic to your website so that the server gets overloaded and crashes your site. Read more about DDoS attacks on WordPress sites and how to mitigate the risk here.

These are the typical reasons that cause the 503 error on WordPress sites.

It’s worth noting that there are a few different variations of the error:

“503 Service Unavailable”
“503 Service Temporarily Unavailable”
“HTTP Server Error 503”
“HTTP Error 503”
“Error 503 Service Unavailable”
“The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.”

👉 The solutions that we have covered below should fix any 503 error on a WordPress website.

The exact fix that is going to work for you depends on the root cause. The 503 error itself does not give you much information to go on. So in this section, we will show you a number of steps to follow in order to pinpoint the cause and then fix it.

Before we dive into the solutions, make sure you are carrying out the following preliminary steps:

The 503 error WordPress also occurs when you are updating a plugin or a theme. You might want to check your website again to see if it was a temporary issue. Just make sure you cleared the cache before checking the site.

As I mentioned earlier, sometimes the 503 error occurs because of maintenance work on your web server. You must have been alerted about it via email by your hosting provider. In a typical maintenance alert, you are informed about how long the server is expected to be down. So check your email.

Bluehost scheduled maintenance email

If the error appeared right after you added a code snippet to your website, then you know who the culprit is. Remove the code and your website should go back to normal. But if you’ve lost access to your dashboard, then we suggest restoring a backup of your website. Your hosting provider should be able to help you out with this.

Nothing worked? Then let’s try the steps below.

1. Deactivate plugins temporarily

503 errors are commonly caused by plugins that you have installed on your site. To determine if a plugin caused the error, you will need to disable all the plugins only temporarily.

The 503 error prevents you from accessing the dashboard, so you will have to use an FTP client like FileZilla.

Open FileZilla, connect with your site, and navigate to the public_html directory. Open the folder and navigate to the wp-content. Inside this directory, you’ll find another one called plugins. It contains all your site’s plugins (active and inactive). Rename the plugins directory to plugins_ or whatever else. This will deactivate every plugin on your site.

Disabling all plugins by renaming the main plugin directory

Go back to your site again and see if the 503 error is gone. If it is, then it’s safe to assume that a plugin was causing the error.

Now, it’s time to pinpoint the exact plugin that’s causing the issues.

Go back to FileZilla, change back the name of your plugins directory to the original (“plugins”). Go inside and start working through all your plugins one by one. Do this:

Change the name of the first plugin in the directory to something else.
Check the website to see if the error is gone.
If it is indeed gone, you’ve found your culprit. If not, change back the name of that first plugin and proceed to test the next one the same way.
Repeat until you find the plugin that’s causing the problems.

Once you find the plugin causing the error, it’s best to just delete it and look for an alternative. If none of your plugins is causing the 503 error, then try the next solution.

2. Deactivate your theme temporarily

Deactivating the theme is a bit tricky because you can’t simply rename the theme folder as we did with the plugins folder. It would lead to an error of its own.

So here’s what you need to do: log into your hosting account, go to the cPanel section and open the phpMyAdmin.

Select wp_options and go to Search. Under option_name, write template and click on Go.

Finding your current theme in PHPMyAdmin

The system will run a search and then show you your current theme under option_value. Select Edit and change the current theme to twentytwentyone.

Editing current theme in PHPMyAdmin

If this fixes the error, then you might want to try getting an earlier version of the theme (one that worked), installing it, and waiting for the theme’s developer to release an update. Or, you can switch to a different theme altogether if that’s an option.

3. Disable your CDN temporarily

Occasionally, CDNs are known to cause 503 errors, so disabling it – if you have one working on your site – can be a quick solution. All CDNs have some option that allows you to pause them manually. For instance, on Cloudflare, you need to log into your account, select your website, and click on the Pause Cloudflare on site option.

Next, check your website and if the 503 error persists, then unpause the CDN and try the next solution.

4. Limit WordPress Heartbeat API

The Heartbeat API is responsible for several essential functions, like auto-saving posts, showing plugin notifications, preventing you from accessing a post when someone else is modifying it, etc.

The API uses your server resources to carry out these functions. If your server can’t handle the API’s demands, it will throw a 503 error. To determine if the Heartbeat API is causing the error, you need to disable it temporarily.

Open your FTP client (FileZilla), connect to your website and go to public_html → wp-content → themes. Open the current theme directory and download a copy of the functions.php file, then edit it.

function.php file location - 503 error fix

Locating function.php file

Add the following code snippet right after the opening <?php tag:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat')
}

editing function.php file to fix 503 error

Inserting code snippet in function.php file

Save the file, reupload it, and check your website. If the error disappears, then you’ve caught the culprit.

But remember, the Heartbeat API is essential, so you can’t keep it disabled long term. You can slow down its frequency if you feel like it by installing the Heartbeat control plugin. Just make sure to delete the code snippet from the functions.php file before setting up the plugin.

5. Enable WP_DEBUG

When all other solutions fail, enabling the debug mode could give you answers.

You can enable the debug mode using a plugin or by modifying the wp-config file.

Since the 503 error prevents you from accessing the dashboard, installing a plugin is out of the question. So you have to modify the wp-config file manually.

Open your FTP client (FileZilla), go to public_html → wp-config.php and download a copy of the file, then edit it. Insert the following code snippet into it:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Save the file and reupload it.

Inserting code snippet in wp-config.php file

Now go to the wp-content directory, and you should find a debug.log file in there.

The log file contains errors that your website has been experiencing. It’ll show you the causes of the error along with specific lines of code that led to it. You are not going to find a direct indication of the 503 error, so we suggest showing the log to your hosting provider and seeking help with them.

👉 By now, you should have a solution to the 503 WordPress error. However, you should ensure that it never occurs on your site in the future again.

Preventing 503 error WordPress in the future

You can prevent the 503 error from appearing on your website by following the instructions below:

Use themes and plugins from the WordPress repository or trusted developers (like Themeisle). Read how to choose a theme and how to choose a plugin for more information.
Move to a better hosting plan if your site requires more resources to function properly.
Use a firewall to prevent DDoS attacks.
Install or update plugins on a staging site before carrying them out on the live site.

That’s it folks! With that, we have come to the end of this article.

I hope that you found this guide easy to follow and helpful. If you have any questions, let us know in the comments below.

Источник

Как и любая проблема с доступом к интернет-ресурсам, ошибка 503 Service Unavailable («Сервис недоступен») может быть вызвана сбоями как на стороне пользователя, так и на стороне сервера, на котором находится сайт. Поэтому первое, что нужно сделать, если вы столкнулись с таким сообщением при посещении веб-ресурса, попробовать устранить сбой своими силами. Это намного проще и быстрее, чем пытаться донести информацию о возникших сложностях до владельца сайта.

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

Мощный хостинг в подарок при заказе лицензии 1С-Битрикс

Выбирайте надежную CMS с регулярными обновлениями системы и профессиональной поддержкой. А мы подарим вам год мощного хостинга – специально для сайтов на 1С-Битрикс.

Заказать

Устранение ошибки 503 пользователем

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

Обновите вкладку браузера. Это покажется странным, но зачастую такое простое действие приводит к положительному результату. Нажмите клавишу F5 или воспользуйтесь специальной кнопкой в меню браузера.
Закройте и откройте браузер. Таким образом вы произведете сброс текущей сессии соединения и обновите его. При новом подключении скрипт браузера может не обнаружить ошибку 503, если она была воспринята им ошибочно.
Стоит убедиться, что сбой не связан именно с вашим компьютером. Это особенно актуально, если ошибки соединения с веб-ресурсами повторяются регулярно и возникают с разными кодировками на других сайтах. Для этого необходимо посетить проблемную страницу с другого устройства и желательно через новое интернет-соединение.
Зайдите на страницу, выдавшую ошибку 503, используя другой браузер. Вполне вероятно, что дефект возникает из-за некорректных настроек текущего. Если это подтвердится, стоит в них покопаться и найти источник возникновения проблемы. Самое простое, это восстановить настройки по умолчанию.
Перезагрузка компьютера. Как и любой программный сбой на уровне операционной системы или другого программного обеспечения, он может быть исправлен автоматически при новой загрузке системы.
Очистка кэша и удаление файлов cookies. В зависимости от настроек конкретного браузера в них может сохраняться много «лишней» информации при обмене web-данными. Операция довольно несложная, но стоит предварительно посмотреть help по данному вопросу, т.к. в каждом браузере она проводится по-разному.
Перезагрузка сетевого оборудования. Часто сложности при соединении с интернет-ресурсами возникают из-за некорректного поведения ПО на внешних устройствах, через которые вы получаете трафик. Это может быть роутер, раздающий интернет как по кабелю, так и через Wi-Fi. Необходимо отключить соответствующую железку по питанию, т.е. полностью обесточить ее примерно на одну минуту. Если провайдер выдает вам динамический ip-адрес, то произойдет его смена, что тоже может привести к устранению появления ошибки 503.
Смена DNS-адреса на сервере. Это решение является наиболее сложным для обычного пользователя. В большинстве интернет-соединений используется общедоступный DNS-адрес Google. Изменить его можно через «Панель управления компьютера» в «Центре управления сетями и общим доступом». Данные манипуляции довольно критичны для устойчивой работы интернета на вашем компьютере. Поэтому производить их стоит только тогда, когда вы абсолютно уверены в своей IT-подготовке.

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

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

Решение проблем с ошибкой 503 администратором веб-ресурса

При возникновении ошибки 503 Service Unavailable в любом ее проявлении администратор web-ресурса в первую очередь должен разобраться в причине ее появления. Игнорирование данной процедуры по принципу «само пройдет» может привести к тому, что сайт понесет глобальные потери в объеме пользовательского трафика и, как следствие, конверсии. Посетители, регулярно сталкивающиеся с проблемами доступа к определенному ресурсу, очень быстро занесут его в «игнор».

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

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

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

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

Как избежать появления ошибок 503

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

Уменьшение нагрузки на базу данных можно добиться следующими способами:

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

Оптимизация работы скриптов

Отключите все лишние плагины и дополнения, кроме тех, которые реально необходимы для бесперебойной работы сайта (кэширование, оптимизация базы данных, создание бэкапов, сжатие изображений).
Осуществляйте передачу файлов большого объема через FTP, т.к. использование других способов передачи данных приводит к созданию отдельного процесса.
Осуществляйте массовую почтовую рассылку в моменты отсутствия пиковой нагрузки на сайт, например, ночью или ранним утром.
При использовании удаленного сервера минимизируйте время ответа и оптимизируйте канал соединения.
Проверьте наличие проблемных запросов к базе MySQL в файле mysql-slow.log.

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

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

Заключение

Ошибка 503 Service Unavailable может возникнуть на любом сайте, управляемом одной из наиболее популярных CMS – WordPress (Вордпресс), Joomla (Джумла), DLE (ДЛЕ) и любой другой, использующей базы данных MySQL. Способов ее решения много, начиная от самых простых на уровне пользователя и заканчивая довольно сложными процедурами, которые должен выполнить администратор сайта.

Буду благодарен, если вы нашли нестандартный подход к устранению сбоя с кодировкой 503 и готовы поделиться своим опытом в комментариях!

Источник