Nginx 502 ошибка html

While @Larsenal’s answer is technically correct for the minimum configuration, there are common configurations that will make it not work. @Jack Desert’s answer touches on this but doesn’t provide a full explanation of why that’s needed.

Suppose we have this configuration (simplified from @Jack).

error_page 502 504 /my-error-page.html;

What this is saying is, in the case of a 502 or 504 error internally, rewrite the original URI as /my-error-page.html.

What I think most people miss is that this then goes through the same processing chain that happens as if you requested that page directly. This means that it goes through all the same location block checks.

Since a common method of doing a reverse proxy on nginx is to configure a location / { block, that location matches /my-error-page.html and thus nginx tries to use the proxy to serve the error file. Since a common use case is serving a static file in the case that the backend is down, serving this error page from the backend will likely also fail, making nginx default to serving its own internal error page that we were trying to replace in the first place.

So, a common solution, the one @Jack Desert suggests, is to include another location block that will match the /my-error-page.html URL before the location / block. Note that the order of location blocks in nginx configuration has no effect; There is a very specific set of rules for picking precedence of location blocks based on the URL. That location block needs to have whatever is necessary to serve that file like any other static file that nginx might serve. This means a root directive is needed somewhere and that /my-error-page.html will be loaded relative to that (root can be set at nearly any level of the nginx configuration).

Начинающие веб-мастера и системные администраторы временами сталкиваются с ошибкой 502 bad gateway nginx. Nginx — это не просто один из лучших веб-серверов, в то же время, он проектировался как отличный прокси. Логически можно предположить, что эта ошибка возникает, когда что-то не так со шлюзом.

И необязательно чтобы вы использовали Nginx в качестве прокси для доступа к сети. Нет, для работы большинства сайтов требуется генерация динамического контента, например, на php. Поэтому Nginx часто выступает в прокси для Apache или php-fpm. В этой статье мы рассмотрим что означает 502 bad gateway Nginx, как исправить ее.

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

Вот основные причины:

• Nginx используется в качестве прокси для Apache или php-fpm, но эти сервисы не запущены;
• Nginx используется качестве прокси для php-fpm, но параметры доступа к сокету неверно настроены;
• Неверно настроены значения размера буфера и таймаута для php-fpm в nginx.conf;
• Ошибки в конфигурации Nginx.

Как исправить ошибку 502 bad gateway Nginx

1. Анализ логов и перезапуск

Чтобы исправить ошибку нужно выяснить что случилось со шлюзом. Лучший способ сделать это — посмотреть логи Nginx, там обязательно должно быть что-то написано и намного подробнее, чем в выводе браузера:

tail -f /var/log/nginx/error.log

Это уже должно дать вам некоторые подсказки что делать дальше. Еще в первую очередь не помешает проверить файл конфигурации Nginx на ошибки:

nginx -t

Допустим, у нас в качестве шлюза для генерации динамического содержимого используется php-fpm. Тогда нужно проверить запущен ли вообще этот сервис:

ps aux | grep php

Если все процессы уже запущены, попробуйте перезапустить их с помощью systemd:

sudo systemctl restart php-fpm

Если процесс остановлен, то его нужно запустить:

sudo systemctl start php-fpm

Это самая распространенная причина, вызывающая ошибку 502 Bad Gateway и обычно после перезапуска сервиса все будет работать, вам осталось выяснить только почему он завершился. В этом вам может помочь просмотр лога php-fpm:

sudo tail -f /var/log/php7.0-fpm.log

Но если такой рецепт не помог, и ошибка 502 bad gateway nginx нужно идти дальше. Внимательно пересмотрите лог, возможно, там уже есть ответ.

2. Доступность php-fpm и владелец

Также эта ошибка может возникать при проблемах доступа к файлу сокета php-fpm, например, когда этот файл называется по другому или для него выставлены неверные права. Сначала убедитесь, что в конфигурационном файле /etc/nginx/nginx.conf указан правильный адрес файла сокета php-fpm:

location ~ .php$ {
fastcgi_pass unix:/var/run/php7.0-fpm.sock;
include fastcgi_params;
}

Файл /var/run/php7.0-fpm.sock должен действительно существовать в файловой системе. Дальше нужно убедиться, что у сокета правильный владелец, это должен быть тот же пользователь, от имени которого запускается Nginx, группа тоже должна соответствовать. Откройте файл /etc/php7.0/fpm/pool.d/www.conf и найдите строчки user и group. Они должны иметь такое же значение, как строчка user в конфиге nginx.conf:

listen = /var/run/php7.0-fpm.sock
listen.owner = www-data
listen.group = www-data

После того как выставите правильные параметры, перезапустите сервисы:

sudo service php5-fpm restart
$ sudo service nginx restart

3. Время отклика и размер буфера

Возможно, размер буфера и время ожидания ответа от fastcgi настроены неверно и программа просто не успевает обработать большой запрос. Попробуйте увеличить такие параметры в /etc/nginx/nginx.conf. Если таких строк не существует, добавьте их в блок http, как здесь:

sudo vi /etc/nginx/nginx.conf

http {
...
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
...
}

Выводы

В этой статье мы рассмотрели 502 bad gateway nginx что это значит и как исправить эту ошибку. Как видите, может быть достаточно много причин ее возникновения, но решить все достаточно просто если внимательно посмотреть логи и понять в чем там действительно проблема. Надеюсь, информация была полезной для вас.

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Об авторе

Поддерживать сервер сложно.

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

Одной из таких распространённых ошибок на серверах Nginx является 502 Bad Gateway.

Сообщение об ошибке загадочно.

Итак, многие веб-мастера засучивают рукава и смотрят error.log:

2017/04/04 08:34:43 [error] 949#949: *7 connect() failed (111: Connection refused) while connecting to upstream, client: XXX.XXX.XXX.XXX, server: myserver.com, request: "GET /myurl-this/ HTTP/1.0", subrequest: "/redis-fetch", upstream: "redis://127.0.0.1:6379", host: "refserver.com", referrer: "http://referalsite.com/myurl-this/"

Да, ещё больше непонятного…

Вы понимаете, что что-то напутано, потому что он сообщает failed (сбой) и refused (отказ).

Но что это означает?

Вот решение. Мы перечислили пять основных причин возникновения ошибки Nginx 502 Bad Gateway и способы их решения.

Сбой серверной службы

Nginx зависит от серверных служб, таких как PHP-FPM, служб баз данных и серверов кэша для запуска веб-приложений.

Таким образом, если какой-либо из этих сервисов выйдет из строя или зависнет, Nginx не получит никаких данных, что приведёт к ошибке 502 Bad Gateway.

Службы, которые, как мы видели, сбоили — это:

• PHP-FPM
• Apache
• Cache
• Database

Причины сбоя службы могут варьироваться от всплесков трафика и ограничений ресурсов до ошибок диска и DDoS-атак.

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

Например, вот один из способов убить нефункционирующие процессы PHP-FPM и перезапустить службу.

$ kill -9 $(pgrep php-fpm)
$ /etc/init.d/php-fpm restart
* Restarting PHP FastCGI Process Manager php-fpm        [ OK ]

Внимание: Не запускайте эти команды, если не знаете, как они работают.

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

Высокая нагрузка на сервер

Вторая наиболее распространённая причина ошибки Nginx 502 Bad Gateway является высокая средняя загрузка серверов.

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

• Внезапный всплеск посещаемости сайта (может быть сезонным или маркетинговым/рекламным).
• Заражение вредоносным программным обеспечением (вирусы/трояны/майнеры/сканеры и т.д.) на сервере.
• Рассылка спама в комментариях или использование других уязвимостей.
• Брут форс атаки на веб-приложения.
• Ошибки приложений, вызывающие утечку памяти или перегрузку ресурсов.

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

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

Неправильная конфигурация сервиса

Сервер Nginx и серверные службы зависят от многих подсистем. Таких, как DNS resolver, процессы Apache, службы PHP, сервер базы данных и т.д. Если даже одна из этих служб имеет неправильную конфигурацию, эта служба не сможет ответить, и Nginx покажет ошибку 502 Bad Gateway.

Проблемы с конфигурацией, с которой мы сталкивались:

• DNS resolver неправильно настроен в Nginx, что приводит к сбою поиска домена.
• Данные логина БД настроены неправильно после недавней миграции, восстановления или обновления.
• Синтаксическая ошибка настроек брандмауэра Apache (mod-security), вызывающая сбой Apache.
• Для приложений PHP установлены неправильные ограничения памяти или файлов.
• Ограничения пропускной способности (например, количество подключений на IP-адрес) установлены слишком строго, что приводит к сбою легальных посетителей.
• …и многое другое.

Не существует простого способа обнаружения ошибки конфигурации. Вам нужно просмотреть error.log и обратить внимание на то, что написано об ошибке.

Например, эта ошибка сообщает, что приложение PHP достигло максимально допустимого предела процессов (определяемого параметром pm.max_children).

WARNING: [mysite.com] server reached max_children setting (30), consider raising it
ERROR: unable to read what child say: Bad file descriptor (9)

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

Порт сервиса заблокирован в брандмауэре

Брандмауэры/файрволлы — основа безопасности сервера. Но если их неправильно настроить, это может привести к блокировке запросов или сбою служб.

Например, на серверах Linux, на которых работает пакет автоматизации Plesk, Nginx работает на 80 порту, а Apache на 7080. Но брандмауэры/файрволлы по умолчанию блокируют необычные порты, и это приведёт к том, что Nginx не сможет подключиться к Apache.

Результат? Ошибка 502 Bad Gateway.

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

Чтобы исправить это, мы смотрим, на каком порту работает каждая служба с помощью следующей команды:

$ netstat -lpn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      19785/nginx
tcp6       0      0 :::80                   :::*                    LISTEN      19785/nginx

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

Ошибки веб-приложений

Редким случаем ошибки 502 Bad Gateway является ошибка приложения.

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

[notice] child pid 27831 exit signal Segmentation fault (11)

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

Итог

Ошибка 502 Bad Gateway в Nginx обычно возникает, когда Nginx работает как обратный прокси и не может подключиться к серверным службам. Это может быть связано со сбоями службы, сетевыми ошибками, проблемами конфигурации и т.д. Мы рассмотрели пять основных причин этой ошибки и способы её устранения.

As a system administrator, you know how annoying getting paged at (mostly) the wrong time whenever a site under your able hand produces errors. Indeed, you’ve seen the NGINX 502 errors, one of the most annoying errors to deal with. But no worries. This tutorial has got you covered!

In this tutorial, you’ll learn how to fix the NGINX 502 errors in this practical, scenario-based tutorial featuring NGINX and a PHP-FPM upstream app server.

Read on and save the day from NGINX 502 errors!

Prerequisites

• Two Linux machines to host NGINX and PHP-FPM – This tutorial uses Fedora 35 on both machines with hostnames wbserver and appserver.
• PHP-FPM installed on the appserver machine to serve as an upstream server – This tutorial uses PHP-FPM 8.1.

Installing NGINX and Configuring a 502 Error Page

With all the prerequisites in place, it’s time to install NGINX and enable the service to start at bootup. You’ll later configure an error page to demonstrate how to fix the NGINX 502 error.

1. Log in to the NGINX-hosting machine (wbserver).

2. Execute the dnf install command below to install nginx and its dependencies.

sudo dnf install -y nginx

You’ll see an output like the one below, signifying that the installation of NGINX version 1.22.0 is starting.

3. After installing NGINX, run the following systemctl command to start the nginx service –now and enable the service to start at bootup.

sudo systemctl enable --now nginx.service

4. Now, open your favorite web browser, and navigate to http://localhost, which will be your test browser for the rest of the tutorial.

As shown below, you’ll see the default Fedora Webserver Test Page if all goes well.

5. Create an HTML file with your favorite text in the /usr/share/nginx/html directory called 502.html. Populate the code below to the HTML file, which prints a 502 error message.

By default, NGINX uses a single error page for all server-related errors. But this HTML file enables you to identify 502 errors.

<html>
  <head>
    <title>502: Error</title>
    <meta charset="utf-8">
  </head>
  <body>
    <h1 style="text-align:center" >Error 502: Bad gateway</h1>
    <p style="text-align:center">Sorry, but the web server received an invalid response while contacting the upstream server.</p>
  </body>
</html>

6. Run the bash commands below, which don’t provide output, but perform the following:

• Append (>>) the IP address of wbserver to the hosts file (/etc/hosts) for local DNS resolution.

• Append the appserver IP address to the hosts file. Doing so enables you to refer to the machines by domain names as if using an external DNS service.

Be sure to replace 192.168.8.171, and 192.168.8.176 with your own IP addresses throughout this tutorial.

sudo bash -c "echo '192.168.8.171 wbserver' >> /etc/hosts"
sudo bash -c "echo '192.168.8.176 appserver' >> /etc/hosts"

7. Create a new file (ata-block.conf) in the custom configuration directory for NGINX (/etc/nginx/conf.d/).

vi /etc/nginx/conf.d/ata-block.conf

8. Finally, add the following code into the ata-block.conf file.

The code below configures the NGINX webserver to forward all requests for .php files to appserver’s port 9000 and serve the 502.html file for all 502 errors.

server {
  listen 0.0.0.0:80;
  server_name wbserver;
  
  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
  }

  # send all .php requests to external php-fpm server
  location ~ .php$ {
    fastcgi_pass appserver:9000;
    fastcgi_index index.php;
    include fastcgi.conf;
  }
  
  # redirect 502 errors to /502.html
  error_page   502  /502.html;
  location = /502.html {
    root   /usr/share/nginx/html;
  }
  
  # redirect other server error to the static page /50x.html
  error_page   500 503 504  /50x.html;
  location = /50x.html {
    root   /usr/share/nginx/html;
  }
}

Configuring PHP-FPM as Upstream Server

Now that NGINX is installed, you must set up PHP-FPM. You don’t want incoming requests from your NGINX server to be a mess, so you need an upstream server to handle requests properly.

1. Log in to the appserver, open PHP-FPM’s configuration file (/etc/php-fpm.d/www.conf) in your text editor, and add the following directives.

These directives allow PHP-FPM to serve requests from wbserver only on port 9000 with default configuration settings

[www]
user = nginx
listen = 9000
listen.allowed_clients = 192.168.8.171
listen.acl_users = apache,nginx
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
slowlog = /var/log/php-fpm/www-slow.log
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path]    = /var/lib/php/session
php_value[soap.wsdl_cache_dir]  = /var/lib/php/wsdlcache

2. Create a new file named hello.php in the /usr/share/nginx/html/ directory, and add the following line. This hello.php page will be requested throughout this tutorial to confirm that the fixes have taken effect.

<?php echo "Hello from ATA"; ?>

3. Next, run the systemctl enable command below to set up php-fpm as a service –now, and enable the service to start at bootup.

sudo systemctl enable --now php-fpm

If you get errors while trying to start the service, double-check the configuration file for typos.

4. Ultimately, execute the following command, which doesn’t provide output but appends (>>) the IP address of wbserver to the hosts file (/etc/hosts) for local DNS resolution.

sudo bash -c "echo '192.168.8.171 wbserver' >> /etc/hosts"

Fixing the Unavailable Upstream Server 502 Error

All the pieces are in place, and you’re almost ready to investigate and fix your first 502 error. But first, you’ll create a scenario where the upstream server is unavailable due to a crash or power cycle.

1. Execute the shutdown command below on appserver to turn off the machine immediately (now) to mimic an unavailable server.

2. Next, log in to wbserver and navigate to http://wbserver/hello.php in the test web browser. You’ll be greeted with a 502 error, as shown below.

3. Run the below tail command to view the last (-n) five (5) lines of error.log to investigate the cause of the error.

sudo tail -n 5 /var/log/nginx/error.log

You’ll see error log entries containing the text connect() failed (113:No route to Host) while connecting to upstream, as shown below.

This log message indicates that the issue lies in the connection to the upstream node, not in NGINX itself.

4. Lastly, turn the upstream server (appserver) back on to fix the 502 error.

Refresh the browser page in wbserver to confirm the issue has been fixed, as shown below.

Ensuring PHP-FPM is Running in the Upstream Server

Another common cause of NGINX 502 errors is when the PHP-FPM service is down on a reachable server. For this tutorial, you’ll kill the PHP-FPM process to replicate a 502 error and how to fix the error.

1. Log in to appserver, and execute the pkill command, which doesn’t provide output, but kills all PHP-related services.

2. Next, navigate to the hello.php page in wbserver, and you’ll get a 502 error in your test browser, as shown below.

3. Run the systemctl command below to confirm the status of the php-fpm service.

sudo systemctl status php-fpm.service

Below, you’ll notice that the PHP-FPM service is inactive and has 0 active processes.

This status is the result of when you manually killed the underlying processes. But the service may crash and die in the wild for several reasons.

4. Now, execute the systemctl status command again to display more information about the stopped php-fpm service.

sudo systemctl status php-fpm.service

Pay attention to the log section of the output below. If errors affect the start or continuous running of the service, deal with those errors.

Check the default log file(/var/log/php-fpm/error.log) for further pointers about why the service cannot start.

5. Run the systemctl start command, which doesn’t have an output, but starts the php-fpm service.

sudo systemctl start php-fpm.service

6. Next, rerun the systemctl status command to confirm the state of the php-fpm service.

sudo systemctl status php-fpm.service

As you can see below, the PHP-FPM service is now active (running).

7. Finally, reload your test browser page in wbserver to confirm the 502 error is resolved, as shown below.

Modifying Firewall Rules to Fix NGINX 502 Errors

A properly configured and running NGINX and PHP-FPM services is not all you need to dodge NGINX 502 errors. A misconfigured firewall can also be a source of 502 errors.

To see how you can fix this error, you’ll first recreate a firewall-caused 502 error condition:

1. Run the firewall-cmd command below to show the firewall’s state. Fedora 35 uses firewall-cmd as a command-line interface for its firewall solution, Firewalld.

By default, on a Fedora system, the firewall is running, as shown below.

2. Next, execute the below firewall-cmd command to remove access to port 9000 over Transmission Control Protocol (TCP).

Blocking port 9000 makes PHP-FPM inaccessible to external machines, including the NGINX host, wbserver.

sudo firewall-cmd --remove-port 9000/tcp

3. Refresh your test browser page. Once again, you’ll get a 502 error, as shown below.

4. Now, run the following firewall-cmd command to add port 9000 to the list of allowed ports over TCP.

sudo firewall-cmd --add-port 9000/tcp

You should receive a success notification as in the screenshot below.

5. Run the firewall-cmd command to make the current runtime configuration permanent. Doing so prevents further 502 errors caused by blocked firewall ports, especially after reboots.

sudo firewall-cmd --runtime-to-permanent

The output below indicates the 502 error has been fixed. But you can never be too sure, right?

6. Lastly, reload the test browser page in wbserver to confirm the issue has been resolved, as shown below.

Changing DNS Resolution Target for the Upstream Server

By now, all should be working fine, but what will you do if you get another 502 error? An error in DNS resolution can also cause NGINX 502 errors.

To fix a DNS-caused NGINX 502 error:

1. Log in to the NGINX host machine (wbserver).

2. Edit the hosts file (/etc/hosts) in your text editor.

3. Change the IP address for the PHP-FPM server (appserver) to an incorrect IP.

Choose an IP that is not assigned to any machine, save the changes and close the editor. This tutorial uses the IP address 192.168.8.156.

4. Now, refresh the test web page (http://wbserver/hello.php).

As shown below, you’ll get the 502 error since PHP-FPM is not listening at 192.168.8.156.

5. Run nslookup to view the result of DNS resolution for the domain name appserver.

As expected, DNS queries for appserver return the wrong IP address, as shown below.

6. Edit the hosts file on wbserver with your text editor, and put the correct IP address for the appserver.

This step varies depending on how you’re performing DNS resolution. This tutorial uses local hosts files, so this step suffices.

In a typical enterprise setting, DNS resolution is provided by Active Directory or a hosting provider. Whatever the case, NGINX expects to be directed to a socket on the PHP-FPM server when it has to deal with PHP requests.

Talk to your DNS administrator (if that’s not you). For NGINX hosted on servers on the internet, you might have to look at your hosting provider’s CPANEL or similar tool.

7. Rerun the nslookup command to confirm the fix has taken effect.

8. Ultimately, refresh your test browser page in wbserver to confirm the issue has been resolved.

Below, you can see that you’re no longer getting 502 errors.

Conclusion

By making it this far, you’ve learned about dealing with 502 errors in an NGINX setup. Whether a service or server is down or a firewall is blocking ports, you can now confidently fix NGINX 502 errors.

This newfound knowledge is just another milestone, so why not check out more NGINX-related tutorials to deepen your skills.

Загружая страницу, браузер отправляет кучу запросов другим серверам. Они обрабатывают все запросы, затем возвращают код ответа HTTP с определенным результатом. Если в процессе этого возникнет какой-то сбой, на экране браузера отобразится ошибка. И одна из таких ошибок – 502 Bad Gateway. Я расскажу, что она означает, по каким причинам выходит, а еще опишу способы ее устранения.

Что означает ошибка 502 Bad Gateway

Ошибки, принадлежащие серии 5xx, означают появление проблем на стороне сервера. Если взять конкретно ошибку 502 Bad Gateway, то ее появление будет означать получение неправильного ответа сервера. «Виновниками» в такой ситуации обычно являются прокси, DNS или хостинг-серверы.

Что делать, если вы пользователь

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

Перезагрузить страницу

Возможно, на момент загрузки число запросов на сайт превышает определенный лимит, устанавливаемый владельцем сайта. Если это действительно так, тогда простая перезагрузка страницы вполне будет уместна. Я рекомендую обновить страницу как минимум три раза в течение 2-3 минут и только потом приступать к следующим способам.

Проверить подключение к интернету

Стоит проверить работу модема и попробовать загрузить другие страницы. Убедитесь, что подключение к интернету стабильное. Еще вариант – перезапустить маршрутизатор и попробовать снова загрузить проблемный сайт.

Очистить кэш и cookies

Нередко причиной появления данной ошибки могут быть неверно загруженные cookies и кэш. В таких случаях необходимо просто очистить данные в настройках интернет-обозревателя.

Для любого браузера актуально – зайти в историю просмотров и найти ссылку «Очистить историю». В новом окне отметить пункты с кэшем и cookies, затем подтвердить действие. Как только данные будут удалены, надо вновь попробовать загрузить страницу. Не помогло? Идем дальше!

Очистить кэш DNS

Допустимо, что в кэше установлено неправильное значение IP-адреса. Для таких случаев можно использовать сброс DNS кэша. В ОС Windows необходимо открыть инструмент «Командная строка» (вводим в поисковую строку название программы и выбираем запуск от имени администратора).

Далее следует ввести вот такую команду и активировать ее нажатием на клавишу Enter:

ipconfig /flushdns

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

Для Linux действие примерно схоже, но команда выглядит иначе. Открываю утилиту «Терминал» и ввожу в поле вот такой запрос:

Для Ubuntu:

sudo service network-manager restart

Для других дистрибутивов:

sudo /etc/init.d/nscd restart

Попробовать зайти с другого браузера

Проблема 502 Bad Gateway может быть актуальна и для конкретного браузера. Если у вас на компьютере есть другой интернет-обозреватель, попробуйте открыть сайт через него. 

Отключить плагины и расширения

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

Зайти на страницу позже

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

Что делать, если вы администратор сайта

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

Проверка журнала ошибок

Актуально в случаях, при которых ошибка 502 Bad Gateway появляется после внесения изменений или обновления. Определить это очень просто, нужно лишь проверить журнал ошибок. В CMS WordPress можно включить запись возникающих ошибок, добавив в файл wp-config.php вот такие строки:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

После этого все записи начнут отображаться в файле debug.log. Храниться он будет в директории wp-content. Понадобится некоторое время, чтобы причины ошибок были записаны. Потом можно тщательно изучить записи и уже на основе их предпринимать конкретные изменения.

Проверка плагинов

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

Проверка сети CDN

Сети CDN и службы предотвращения DoS тоже могут влиять на работу сайта. Обычно виновник проблемы указывается на странице с кодом ошибки. Например, если под кодом 502 Bad Gateway есть строка cloudflare-nginx, значит, для исправления ошибки надо обратиться в службу поддержки CloudFlare. Можно отключить данный сервис, но потом придется долго ждать обновления DNS (это может занять несколько часов).

Ошибка 502 на виртуальном хостинге VPS/VDS

Ошибка 502 Bad Gateway возникает из-за превышения лимита трафика пользователей, «шалостей» бота, скачивания сайта или даже DoS‑атаки. Решение данной проблемы кроется в ограничениях памяти.

Запустить команду top

Данный запрос в терминале поможет установить наличие свободной памяти. Этим же способом можно проверить, работает ли Apache.

Посмотреть логи Apache и nginx

Обычно в этих логах отображается активность пользователей. Если есть что-то подозрительное, можно предпринять действия. К примеру, забанить определенные IP-адреса, настроить Fail2ban или подключить систему защиты от DoS-атак.

Если после этого количество запросов к серверу снизилось, необходимо перезапустить Apache.

Увеличить объем памяти

Бывает, что с логами все нормально, но памяти на обработку запросов все равно не хватает. Узнать об этом просто – при проверке командой top будет выдана ошибка OOM (out of memory). В таких случаях можно просто увеличить ее объем. Можно просто заказать другой тариф, в котором количество предоставляемой памяти больше. Подробнее об этом.

Проверить лимиты на php-cgi процессы

Если после проверки командой top показано, что свободной памяти еще достаточно, значит, на php-cgi процессы установлены лимиты. Для решения надо открыть конфигурационный файл Apache – httpd.conf, найти секцию модуля FastCGI (mod_fascgi или mod_fastcgid) и увеличить лимит.

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

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