Содержание

Ошибка 502 «bad gateway» как ее исправить — База знаний

Ошибка 502 «bad gateway» как ее исправить — База знаний — AdminVPS

Ошибка 502 на виртуальном хостинге «Bad Gateway»

Ошибка 502 возникает когда Apache работает в связке с Nginx. Запрос от пользователя прошел через NGINX к Apache но тот в свою очередь вернул нулевой результат прокси-серверу NGINX.

Причины возникновения и способы устранения ошибки 502:

  • Дочерний процесс Apache не смог обработать поступивший к нему запрос и завершился досрочно. Зачастую это связано с ошибкой в скрипте сайта или нехваткой памяти для выполнения процесса. Начните свой поиск error 502, в таком случае с логов ошибок сайта. Вполне возможно там будет информация, которая привела к возникновению этой ошибки. Но зачастую лог не содержит ничего полезного по этой проблеме, поскольку процесс Apache завершился досрочно. Если это так, разбейте свой скрипт на участки, и выполняйте их поочередно. Это должно помочь найти 502 error. В другом случае, вы можете самостоятельно завершить работу зависших обработчиков и перезапустить их, подробнее см. Завершение работы процессов. 
  • Процесс Apache завершился по таймауту и не вернул в поток вывода никаких данных. Обычно это связано с длительным выполнением скрипта, либо зацикливанием в нем. Чтоб не получать 502 bad gateway, когда скрипт выполняется длительное время, лучше его запускать из консоли, а в случае если скрипт запускается регулярно, поставить его на CRON. 
  • Скрипты сайта превышают ограничения, накладываемые на них условиями нашего хостинга, и автоматически завершаются. Для устранения ошибки достаточно провести оптимизацию ваших скриптов. 
  • При использовании CMS Bitrix ошибка может возникать из-за некорректного названия директории для хранения кэшированных файлов. Проблема решается переименованием данной директории. 
  • Ошибка при включенном APC (Alternative PHP Cache). Проблема решается отключением APC при помощи добавления в файл .
    htaccess вашего сайта следующей строки: php_flag apc.cache_by_default Off 
  • Технический сбой на сервере. Проблема максимально быстро диагностируется нашими специалистами и оперативно устраняется.

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

Если 502 ошибка возникает регулярно, напишите заявку в службу поддержки. В заявке укажите:

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

Ошибка 502 на VPS

Чаще всего на VPS используется связка: Nginx + бэкенд-сервер (Apache, PHP-FPM, Gunicorn, NodeJS). Ошибка 502 возникает в случае, если Nginx не может получить ответ от этих сервисов. 

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

  • Какой-то из сервисов выключен. Необходимо перезапустить веб-сервер Apache, PHP-FPM либо другой сервис, с которым работает Nginx.
  • Между Nginx и бэкенд-сервером некорректно настроена связь. Например, Nginx производит обращение к порту 8080, а веб-сервер Apache «слушает» на 8081. В этом случае необходимо скорректировать настройки веб-сервера. 

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

  • 6 Пользователи нашли это полезным

Помог ли вам данный ответ?

Похожие статьи

Ошибка 500 «internal server error» на сервере

Ошибка 500 на виртуальном хостинге «Internal Server Error» Когда возникает и что такое. ..

Ошибки 500, 502, 503, 504 на сайте

Ошибка 500 на виртуальном хостинге «Internal Server Error» Когда возникает и что такое…

Как устранить ошибку 503 «service temporarily unavailable»

Ошибка 503 на виртуальном хостинге «Service Temporarily Unavailable» У каждого аккаунта на…

Ошибка 504 «gateway timeout»

Ошибка 504 на виртуальном хостинге «Gateway timeout» Эта ошибка может возникнуть в случае, если…

Ошибка 403 forbidden

Ошибка 403 Как правило, ошибка 403 возникает из-за неточностей при размещении сайта на хостинге….

Powered by WHMCompleteSolution


Загрузка…

Ошибка 502 Bad Gateway nginx.

Как исправить HTTP Error 502. Хостинг в деталях

Эта статья поможет разобраться, почему на сайтах время от времени появляется ошибка 502 Bad Gateway nginx (HTTP Error 502) и как эту проблему решить.

Если вы посетитель

Если вы не можете попасть на сайт из-за ошибки 502, сделать можно не так много:

  • Перезагрузить страницу, сбросив кеш (Ctrl+Shift+R, Ctrl+F5 или Shift+F5). К сожалению, это помогает не так часто, как хотелось бы.
  • Зайти попозже. Через минуту, через полчаса, ночью или рано утром. Скорее всего сервер перегружен. Исправить это вы не сможете, этим должен заняться администратор сайта. Если сайт для вас важный, и у вас есть время, напишите администратору письмо. Чем больше обращений, тем вероятнее, что на проблему обратят внимание и серьезно ей займутся.

Если вы администратор сайта

Если эта ошибка возникает, значит HTTP-запросы от посетителей к вашему сайту идут через так называемый «шлюз», программу-посредник. Например, если на хостинге перед веб-сервером Apache стоит веб-сервер nginx, то nginx будет шлюзом.

502-ая ошибка означает, что запрос от клиента прошел nginx, попал к Apache, и Apache не смог запрос обработать, о чем сообщил nginx’у. В результате nginx отдает клиенту ошибку.

Если PHP работает в режиме FastCGI, то любой веб-сервер перед ним будет шлюзом.

Почему Apache не смог обработать запрос? Как это исправить?

Скорее всего, если сайт раньше работал, а теперь не открывается, дело не в ошибках конфигурации среды. Причина может быть в нехватке ресурсов сервера, и, следовательно, в невозможности обслужить всех клиентов. В частности, проблема может быть в нехватке оперативной памяти. Или вы можете упираться в какое-то ограничение, например, на количество процессов. Иногда Apache или ваше приложение могут периодически падать/перезапускаться, в эти моменты фронт-серверу тоже ничего не остаётся, кроме как отдавать ошибку 502. Такое может случиться и на VPS, и на shared-хостинге.

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

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

Если у вас VPS

Если PHP работает через FastCGI, то на сервере может не хватать php-cgi процессов в моменты, когда на сайте много посетителей, пришел прожорливый бот, кто-то скачивает ваш сайт целиком или идёт DoS-атака. Веб-серверу нужно бы запустить дополнительные процессы, но памяти под них уже нет. Значит, нужно добавить памяти либо оптимизировать расход доступной

  • Запустите команду top. Посмотрите, есть ли свободная память и запущен ли Apache.
  • Посмотрите логи Apache и nginx (ошибки 502 попадают в него). Есть паразитная активность? Если есть, баньте по ip, настраивайте Fail2ban, подключайте защиту от DdoS.
  • Если получилось ограничить количество запросов к серверу, перезапустите Apache.
  • Если в логах всё нормально, но мало свободной памяти, и есть возможность ее оперативно добавить, попробуйте это сделать. Сейчас у многих провайдеров это делается в биллинге буквально за пару минут.
  • Если же команда top показывает, что свободная память есть, возможно, дело в установленных лимитах на количество php-cgi процессов. Нужно смотреть конфигурационные файлы Apache (httpd.conf), особенно секцию модуля, отвечающего за FastCGI (mod_fascgi или mod_fastcgid), и увеличивать лимиты.

Если дело в нехватке памяти, то в логах будут ошибки OOM (out of memory). Когда ОС очень нужна память, то ядро может попытаться освободить её при помощи механизма OOM killer, просто убивая активные процессы. Например, здесь пришлось пожертвовать Апачем:
Out of memory: kill process 1718 (apache2) score 56789 or a child
Killed process 22504 (apache2)

Другой случай — когда, Apache периодически падает/перезапускается независимо от текущей нагрузки на сайт.

В error.log может быть написано:

[core:notice] [pid 5795] AH00052: child pid 5858 exit signal Segmentation fault (11)
[mpm_prefork:notice] [pid 5795] AH00169: caught SIGTERM, shutting down

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

Теги: Apache · FastCGI · HTTP-ошибки · Nginx · PHP · VPS · Виртуальный хостинг · Ошибка 502

Как исправить ошибку 502 Bad Gateway в WordPress

Если вы являетесь владельцем сайта, мало что может вызвать у вас тошноту, как попытка загрузить свой веб-сайт только для получения загадочного сообщения об ошибке. Вы, наверное, знакомы с ошибкой 404 Page Not Found, но как насчет проблемы 502 Bad Gateway?

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

В этой статье мы рассмотрим различные причины ошибки 502. Затем мы покажем вам, как изолировать и решить проблему.

Что вызывает ошибку «502 Bad Gateway» в WordPress?

Коды ошибок серии 500, также известные как коды состояния HTTP, используются для диагностики ошибок связи между веб-браузером и сервером веб-сайта. По сути, когда браузер пытается подключиться к веб-сайту, он связывается с сервером веб-сайта, чтобы запросить доступ. Если этот запрос не может быть выполнен, обычно возвращается ошибка серии 500, объясняющая, что пошло не так.

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

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

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

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

Как исправить проблему «502 Bad Gateway» в WordPress

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

1. Обновите страницу

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

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

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

2. Очистите кеш и DNS

В редких случаях полный кеш на стороне клиента может имитировать ошибки сервера, поскольку он не может получать новые данные по запросу. Хотя это вряд ли приведет к ошибке 502 Bad Gateway, очистка кеша — это быстрое и простое решение, которое может помочь вам исключить проблему.

Давайте рассмотрим, как очистить кеш в Google Chrome. Большинство других браузеров будут следовать аналогичному процессу.

Сначала щелкните значок с тремя точками в правом верхнем углу окна браузера и выберите Настройки . Затем перейдите к Безопасность и конфиденциальность слева.

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

Затем просто нажмите кнопку Очистить данные , и ваш кеш будет очищен. Это освободит место для новых данных.

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

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

 C:/Users/example>
C:/Users/example>ipconfig /flushdns 

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

3. Деактивируйте ваши плагины и тему

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

Чтобы узнать, так ли это, вам нужно деактивировать ваши плагины. Если у вас все еще есть доступ к вашему сайту, перейдите в админ-панель WordPress и перейдите к Плагины . Затем выберите и деактивируйте все новые установленные вами плагины:

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

Если вы не можете получить доступ к панели администратора WordPress, вам нужно пройти через черный ход, чтобы вручную деактивировать ваши плагины. У вас есть два варианта: подключиться к вашему веб-сайту через файловый менеджер в вашей учетной записи хостинга или использовать клиент протокола передачи файлов (FTP), такой как FileZilla.

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

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

Затем откройте папку wp-content и найдите папку plugins .

Затем переименуйте папку из plugins во что-то другое, например plugins_old . Это нарушит путь, и все плагины на вашем сайте будут деактивированы.

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

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

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

Аналогичным образом можно проверить свои темы. Они расположены в папке themes внутри wp-content .

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

4. Проверяйте свои обновления

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

Некоторые темы и плагины предназначены только для совместимости с определенными версиями WordPress. При установке нового инструмента вы захотите проверить требуемую версию WordPress.

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

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

Вы можете проверить текущую версию WordPress, перейдя на страницу Главная → Обновления на панели инструментов.

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

5. Отключите CDN или брандмауэр

Если вы используете сеть доставки контента (CDN) для WordPress, это может увеличить вероятность ошибки 502 Bad Gateway, поскольку данные передаются с нескольких серверов и через них. Если есть проблема с любым из этих шлюзов, это может привести к ошибке.

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

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

6. Свяжитесь с вашим хостинг-провайдером

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

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

7. Восстановить резервную копию

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

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

Кроме того, Jetpack поставляется с журналом действий, который отслеживает каждое изменение, которое вы вносите на свой сайт. Таким образом, вы можете легко определить любые недавние изменения, которые могли вызвать ошибку 502 Bad Gateway.

Как избежать ошибки статуса 502 в будущем

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

1. Проверка новых плагинов и тем

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

Некоторые темы и плагины совместимы только с определенными версиями WordPress. В идеале вы будете устанавливать только те плагины, которые регулярно обновляются.

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

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

2.

Перейдите на более мощное решение для хостинга

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

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

Поэтому вы можете перейти на более продвинутый уровень. Кроме того, вы можете подумать о переходе на другой план хостинга, например, на выделенный или виртуальный частный сервер (VPS).

3. Проверьте журналы ошибок WordPress

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

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

Если вы не можете найти этот файл, вам может потребоваться активировать журнал ошибок. Затем вы можете открыть файл, чтобы найти и исправить ошибку.

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

Не бывает слишком подготовленных

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

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

В качестве альтернативы вы можете восстановить резервную копию своего сайта. Используя такой сервис, как Jetpack Backup, вы можете легко восстановить предыдущие версии своего контента. Если ошибка исчезнет, ​​то причиной, скорее всего, было изменение, внесенное с момента резервного копирования. Затем вы можете использовать журнал активности Jetpack, чтобы отслеживать эти изменения и решать проблему.

Эта запись была размещена в ЖЖ. Добавьте постоянную ссылку в закладки.


Саймон Китинг

Саймон работал в области маркетинга и разработки продуктов более 10 лет, ранее в HubSpot, Workday, а теперь в Automattic (Jetpack). У него разностороннее образование, степень в области химического машиностроения и степень магистра компьютерных наук. Его страсть — помогать людям и их бизнесу расти.

Узнайте о преимуществах Jetpack

Узнайте, как Jetpack может помочь вам защитить, ускорить и расширить ваш сайт WordPress.

Попробуйте за 15 турецких лир в первый месяц.

Сравнить планы

Примерно так:

Нравится Загрузка…

Устранение неполадок с неверным шлюзом — Шлюз приложений Azure

  • Статья
  • 7 минут на чтение

Узнайте, как устранять ошибки неверного шлюза (502), возникающие при использовании шлюза приложений Azure.

Примечание

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. раздел Установка Azure PowerShell. Чтобы узнать, как перейти на модуль Az PowerShell, см. статью Миграция Azure PowerShell из AzureRM в Az.

Обзор

После настройки шлюза приложений может появиться одна из ошибок: Ошибка сервера: 502 — веб-сервер получил неверный ответ, работая в качестве шлюза или прокси-сервера . Эта ошибка может возникать по следующим основным причинам:

  • NSG, UDR или Custom DNS блокируют доступ к членам серверного пула.
  • Внутренние виртуальные машины или экземпляры масштабируемого набора виртуальных машин не отвечают на проверку работоспособности по умолчанию.
  • Недопустимая или неправильная конфигурация пользовательских тестов работоспособности.
  • Серверный пул Шлюза приложений Azure не настроен или пуст.
  • Ни одна из виртуальных машин или экземпляров в масштабируемом наборе виртуальных машин не является работоспособной.
  • Истечение времени ожидания запроса или проблемы с подключением к пользовательским запросам.

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

Причина

Если доступ к серверной части заблокирован из-за NSG, UDR или пользовательской DNS, экземпляры шлюза приложений не могут получить доступ к серверному пулу. Эта проблема вызывает сбои проверки, что приводит к ошибкам 502.

NSG/UDR может присутствовать либо в подсети шлюза приложений, либо в подсети, в которой развернуты виртуальные машины приложений.

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

Решение

Проверьте конфигурацию NSG, UDR и DNS, выполнив следующие действия:

  1. Проверьте группы безопасности сети, связанные с подсетью шлюза приложений. Убедитесь, что связь с серверной частью не заблокирована. Дополнительные сведения см. в разделе Группы безопасности сети.

  2. Проверьте UDR, связанный с подсетью шлюза приложений. Убедитесь, что UDR не направляет трафик из внутренней подсети. Например, проверьте маршрутизацию к сетевым виртуальным устройствам или маршруты по умолчанию, объявляемые в подсеть шлюза приложений через ExpressRoute/VPN.

     $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
    Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
     
  3. Проверить действующую NSG и маршрут с серверной виртуальной машиной

     Get-AzEffectiveNetworkSecurityGroup - NetworkInterfaceName nic1 - ResourceGroupName testrg
    Get-AzEffectiveRouteTable - NetworkInterfaceName nic1 - ResourceGroupName testrg
     
  4. Проверьте наличие пользовательского DNS в виртуальной сети. DNS можно проверить, просмотрев сведения о свойствах виртуальной сети в выходных данных.

     Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
    Варианты DHCP: {
                               "Днссерверы": [
                                 "х. х.х.х"
                               ]
                             }
     
  5. Если присутствует, убедитесь, что DNS-сервер может правильно разрешить полное доменное имя члена внутреннего пула.

Проблемы с пробой работоспособности по умолчанию

Причина Ошибки

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

Когда экземпляр шлюза приложений подготовлен, он автоматически настраивает пробу работоспособности по умолчанию для каждого BackendAddressPool, используя свойства BackendHttpSetting. Для установки этого датчика не требуется никаких действий пользователя. В частности, при настройке правила балансировки нагрузки создается ассоциация между BackendHttpSetting и BackendAddressPool. Зонд по умолчанию настраивается для каждой из этих ассоциаций, и шлюз приложений запускает периодическое соединение для проверки работоспособности с каждым экземпляром в BackendAddressPool на порту, указанном в элементе BackendHttpSetting.

В следующей таблице перечислены значения, связанные с пробой работоспособности по умолчанию:

Свойство пробы Значение Описание
URL-адрес зонда http://127.0.0.1/ URL-адрес
Интервал 30 Интервал проверки в секундах
Тайм-аут 30 Тайм-аут зонда в секундах
Неисправный порог 3 Счетчик повторных попыток зонда. Внутренний сервер помечается как неработоспособный после того, как количество последовательных сбоев проверки достигает порога неработоспособности.

Решение

  • Значение узла запроса будет установлено на 127.0.0.1. Убедитесь, что сайт по умолчанию настроен и прослушивается по адресу 127.0.0.1.
  • Протокол запроса определяется протоколом BackendHttpSetting.
  • Путь URI будет установлен на /.
  • Если BackendHttpSetting указывает порт, отличный от 80, сайт по умолчанию должен быть настроен для прослушивания на этом порту.
  • Вызов протокола : //127.0.0.1:порт должен вернуть код результата HTTP 200. Этот код должен быть возвращен в течение 30-секундного периода ожидания.
  • Убедитесь, что настроенный порт открыт и нет правил брандмауэра или групп сетевой безопасности Azure, блокирующих входящий или исходящий трафик на настроенный порт.
  • . Если классические виртуальные машины Azure или облачная служба используются с полным доменным именем или общедоступным IP-адресом, убедитесь, что соответствующая конечная точка открыта.
  • Если виртуальная машина настроена с помощью Azure Resource Manager и находится за пределами виртуальной сети, в которой развернут шлюз приложений, необходимо настроить группу безопасности сети, чтобы разрешить доступ к нужному порту.

Проблемы с настраиваемой пробой работоспособности

Причина

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

Добавлены следующие дополнительные свойства:

.
Свойство зонда Описание
Имя Имя зонда. Это имя используется для ссылки на зонд в настройках внутреннего HTTP.
Протокол Протокол, используемый для отправки зонда. Зонд использует протокол, определенный в настройках HTTP серверной части
Хост Имя хоста для отправки зонда. Применимо, только если на шлюзе приложений настроено несколько сайтов. Это отличается от имени хоста виртуальной машины.
Путь Относительный путь зонда. Допустимый путь начинается с ‘/’. Зонд отправляется на <протокол>://<хост>:<порт><путь>
Интервал Интервал проверки в секундах. Это временной интервал между двумя последовательными зондами.
Тайм-аут Время ожидания зонда в секундах. Если допустимый ответ не получен в течение этого времени ожидания, зонд помечается как не пройденный.
Неисправный порог Счетчик повторных попыток зонда. Внутренний сервер помечается как неработоспособный после того, как количество последовательных сбоев проверки достигает порога неработоспособности.

Решение

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

  • Убедитесь, что датчик правильно указан в соответствии с руководством.
  • Если шлюз приложений настроен для одного сайта, по умолчанию имя хоста должно быть указано как 127.0.0.1 , если иное не настроено в пользовательском зонде.
  • Убедитесь, что вызов http://: возвращает код результата HTTP 200.
  • Убедитесь, что Interval, Timeout и UnhealtyThreshold находятся в допустимых пределах.
  • При использовании зонда HTTPS убедитесь, что внутреннему серверу не требуется SNI, настроив резервный сертификат на самом внутреннем сервере.

Превышение времени запроса

Причина

При получении запроса пользователя шлюз приложений применяет настроенные правила к запросу и направляет его в экземпляр внутреннего пула. Он ожидает в течение настраиваемого интервала времени ответа от внутреннего экземпляра. По умолчанию этот интервал равен 20 секунд. В Шлюзе приложений версии 1, если шлюз приложений не получает ответ от серверного приложения в течение этого интервала, запрос пользователя получает ошибку 502. В Шлюзе приложений версии 2, если шлюз приложений не получает ответ от серверного приложения в течение этого интервала, запрос будет отправлен второму члену серверного пула. Если второй запрос завершается неудачей, запрос пользователя получает ошибку 502.

Решение

Шлюз приложений позволяет настроить этот параметр с помощью BackendHttpSetting, который затем можно применить к различным пулам. Различные серверные пулы могут иметь разные настройки BackendHttpSetting и другое время ожидания запроса.

 New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60
 

Пусто BackendAddressPool

Причина

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

Решение

Убедитесь, что пул серверных адресов не пуст. Это можно сделать либо через PowerShell, CLI, либо через портал.

 Get-AzApplicationGateway — Name «SampleGateway» — ResourceGroupName «ExampleResourceGroup»
 

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

BackendAddressPoolsText:

 [{
 "БэкендАдрес": [{
 "IP-адрес": "10.0.0.10",
 "IP-адрес": "10.0.0.11"
 }],
 «Конфигурации BackendIp»: [],
 "ProvisioningState": "Выполнено",
 "Имя": "Пул01",
 "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
 "Id": "/subscriptions/<идентификатор подписки>/resourceGroups/<имя группы ресурсов>/providers/Microsoft.Network/applicationGateways/<имя шлюза приложений>/backendAddressPools/pool01"
}, {
 "БэкендАдрес": [{
 «Fqdn»: «xyx.cloudapp.net»,
 "Fqdn": "abc.cloudapp.net"
 }],
 «Конфигурации BackendIp»: [],
 "ProvisioningState": "Выполнено",
 "Имя": "Пул02",
 "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
 "Id": "/subscriptions/<идентификатор подписки>/resourceGroups/<имя группы ресурсов>/providers/Microsoft.