Устранение распространенных проблем с Azure Front Door

В этой статье описывается, как устранять распространенные проблемы, которые могут возникнуть при использовании Azure Front Door.

Ответ 503 или 504 из Azure Front Door через несколько секунд

Симптом

• Регулярные запросы, отправляемые на серверную часть без прохождения через входную дверь Azure, выполняются успешно. Прохождение через Azure Front Door приводит к возникновению сообщений об ошибках 503 или 504.
• Обычно сбой Azure Front Door происходит примерно через 30 секунд.
• Периодически появляются ошибки 503 с сообщением "ErrorInfo: OriginInvalidResponse".

Причина

Причина этой проблемы может быть одной из трех вещей:

• Чтобы получить запрос от Azure Front Door, вашему источнику требуется больше времени, чем настроенное время ожидания. По умолчанию время ожидания составляет 30 секунд.
• Время, необходимое для отправки ответа на запрос от входной двери Azure, превышает значение времени ожидания.
• Клиент отправил запрос диапазона байтов с заголовком Accept-Encoding. Это означает, что включено сжатие.

Действия по устранению неполадок

• Отправьте запрос в источник напрямую, не перейдя через Azure Front Door. Узнайте, сколько времени обычно занимает ответ от вашего источника.

• Отправьте запрос через Azure Front Door и проверьте, получаете ли вы какие-либо ответы 503. В противном случае проблема может быть не в тайм-ауте. Создайте запрос на поддержку для дальнейшего устранения проблемы.

• Если запросы, выполняемые через Azure Front Door, приводят к коду ответа на ошибку 503, настройте время ожидания ответа Источника для Azure Front Door. Вы можете увеличить используемое по умолчанию время ожидания до 4 минут (240 секунд). Чтобы настроить этот параметр, перейдите на страницу обзора профиля Front Door. Выберите Время ожидания отклика источника и введите значение от 16 до 240 секунд.

  Примечание.

  Возможность настройки времени ожидания ответа источника доступна только в Azure Front Door Standard/Premium.

  

• Если увеличение времени ожидания не устраняет проблему, используйте средство, например Fiddler или средство разработчика браузера, чтобы проверить, отправляет ли клиент запросы диапазона байтов с заголовками Accept-Encoding . Из-за этого параметра источник отправляет ответы с разной длиной содержимого.

  Если клиент отправляет запросы диапазона байтов с заголовками Accept-Encoding, у вас есть два варианта. Первым вариантом является отключение сжатия в Origin или Azure Front Door. Второй вариант — создать правило набора правил для удаления Accept-Encoding из запроса на запросы диапазона байтов.

  

Ответы типа 503 от Azure Front Door только для HTTPS

Симптом

• Все ответы 503 возвращаются только для конечных точек Azure Front Door с поддержкой HTTPS.
• Регулярные запросы, отправляемые на серверную часть без прохождения через входную дверь Azure, выполняются успешно. Переход через входную дверь Azure приводит к сообщениям об ошибках типа 503.
• Периодически появляются ошибки 503 с сообщением "ErrorInfo: OriginInvalidResponse".

Причина

Причин данной проблемы может быть три:

• Серверная часть — это IP-адрес.
• Серверный сервер возвращает сертификат, который не соответствует полному доменному имени (FQDN) серверной части Azure Front Door.
• Серверная часть — это сервер Azure Web Apps.

Действия по устранению неполадок

• Серверная часть — это IP-адрес.

  EnforceCertificateNameCheck должен быть отключен.

  У Azure Front Door есть коммутатор с именем EnforceCertificateNameCheck. По умолчанию эта настройка включена. При включении Azure Front Door проверяет, совпадает ли полное доменное имя внутреннего узла сертификата внутреннего сервера или одно из записей в расширении альтернативных имен субъектов.

  • Чтобы отключить EnforceCertificateNameCheck на портале Azure, сделайте следующее:

    На портале используйте переключатель для включения или выключения этого параметра в панели Design Azure Front Door (классическая версия).

    

    В Azure Front Door уровня "Стандартный" и "Премиум" этот параметр можно найти в настройках источника при добавлении источника в группу источников или при конфигурации маршрута.

    

• Серверная часть возвращает сертификат, который не соответствует полному доменному имени серверной части Azure Front Door. Есть два способа решения этой проблемы:

  • Возвращенный сертификат должен соответствовать полному доменному имени.
  • EnforceCertificateNameCheck должен быть отключен.

• Серверная часть — это сервер Azure Web Apps.

  • Проверьте, настроено ли веб-приложение Azure с использованием SSL на основе IP-адресов, а не на основе SNI (указание имени сервера). Если веб-приложение настроено на основе IP-адреса, его следует изменить на SNI.
  • Если внутренний сервер не работает из-за сбоя сертификата, возвращается сообщение об ошибке типа 503. Вы можете проверить работоспособность внутренних серверов на портах 80 и 443. Если порт 443 не работает, проблема, скорее всего, заключается в SSL. Так как внутренний сервер настроен на использование полного доменного имени, мы понимаем, что он отправляет SNI.

  С помощью OPENSSL проверьте возвращаемый сертификат. Для этого подключитесь к бэкенду с помощью -servername. Он должен возвращать SNI, который соответствует полному доменному имени серверного пула:

  openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Запросы, отправленные в личный домен, возвращают код состояния 400

Симптом

• Вы создали экземпляр Azure Front Door. Запрос к домену или интерфейсному узлу возвращает код состояния HTTP 400.
• Вы создали сопоставление DNS (сервера доменных имен) для пользовательского домена к интерфейсному узлу, который вы настроили. При отправке запроса на имя хоста личного домена возвращается код состояния HTTP 400. Кажется, что запрос не направляется к внутреннему сервису, который вы настроили.

Причина

Проблема возникает, если вы не настроили правило маршрутизации для пользовательского домена, который был добавлен в качестве внешнего хоста. Для данного внешнего хоста необходимо явным образом добавить правило маршрутизации. Необходимо создать правило, даже если правило маршрутизации уже настроено для внешнего узла в поддомене Azure Front Door, которое равно *.azurefd.net.

Действие по устранению неполадок

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

Служба Azure Front Door не перенаправляет HTTP на HTTPS

Симптом

У Azure Front Door есть правило маршрутизации, которое перенаправляет HTTP на HTTPS, но доступ к домену по-прежнему поддерживает HTTP в качестве протокола.

Причина

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

Действия по устранению неполадок

Запрос к имени хоста внешнего интерфейса возвращает код состояния 411

Симптом

Вы создали экземпляр Azure Front Door уровня "Стандартный" или "Премиум" и настроили:

• сервер интерфейса;
• Группа источников, в которой есть хотя бы один источник.
• правило маршрутизации, которое подключает фронтенд-хост к группе серверов-источников.

Ваше содержимое кажется недоступным, когда запрос отправляется на настроенный интерфейсный хост, потому что возвращается код состояния HTTP 411.

Ответы на такие запросы также могут содержать страницу ошибки в формате HTML с объяснительным заявлением. Пример ошибки: HTTP Error 411. Запрос должен быть разделен на части или иметь указанный размер содержимого.

Причина

Существует несколько возможных причин данного симптома. Общая причина заключается в том, что ваш HTTP-запрос не полностью соответствует RFC.

Примером несоответствия выступает запрос POST, отправленный без заголовка Content-Length или Transfer-Encoding. Пример: curl -X POST https://example-front-door.domain.com. Данный запрос не соответствует требованиям, изложенным в RFC 7230. Azure Front Door заблокирует запрос посредством ответа HTTP 411. Такие запросы не регистрируются.

Подобный алгоритм действий отличается от функциональности брандмауэра веб-приложения (WAF) в Azure Front Door. В настоящее время отключить это поведение невозможно. Все HTTP-запросы должны соответствовать требованиям, даже если функция WAF не используется.

Действия по устранению неполадок

• Убедитесь, что ваши запросы соответствуют требованиям, изложенным в необходимых RFC.
• Запишите любой текст HTML-сообщения, возвращаемый в ответ на запрос. Текст сообщения часто объясняет, почему запрос не соответствует требованиям.

Мой источник настроен как IP-адрес.

Симптом

Источник настраивается в качестве IP-адреса. Источник работоспособен, но отклоняет запросы из Azure Front Door.

Причина

Azure Front Door использует имя узла источника в качестве заголовка SNI во время подтверждения SSL. Так как источник настроен в качестве IP-адреса, сбой может быть одной из следующих причин:

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

Действия по устранению неполадок

Измените источник из IP-адреса на полное доменное имя, на которое выдан действительный сертификат, соответствующий сертификату источника.

429 ответов из Azure Front Door

Симптом

• Процент запросов начинает отображать ошибки с ответом 429: слишком много запросов.

Причина

• Azure Front Door имеет ограничения скорости платформы по умолчанию. Если ваш трафик превышает предел, Front Door начнет ограничение скорости трафика и будет возвращать 429 ответов.

Действия по устранению неполадок

• Если вы начнете видеть 429 ответов на допустимый трафик и требуется более высокий предел квоты, создайте запрос в службу поддержки Azure.

Связанный контент

• Узнайте, как создать Front Door.
• Узнайте, как создать Front Door стандартного или премиум уровня.