Коды ответов HTTP в Шлюз приложений Azure

Сводка

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

Замечание

Если подключение клиента завершается сбоем, прежде чем шлюз приложений возвращает любой HTTP-ответ, скорее всего, сбой подтверждения транспортного уровня безопасности (TLS). Распространенные причины включают несоответствия версий TLS (например, клиент использует TLS 1.0 или 1.1, а шлюз требует TLS 1.2 или более поздней версии) и неподдерживаемые наборы шифров. С 31 августа 2025 года Шлюз приложений Azure прекратил поддерживать версии TLS 1.0 и 1.1. Дополнительные сведения см. в обзоре политики TLS шлюза приложенийи настройке версий политик TLS и наборов шифров.

Коды ответов 3XX (перенаправление)

Шлюз приложений возвращает ответы HTTP 300-399, когда запрос клиента соответствует правилу шлюза приложений, для которого настроены перенаправления. Вы можете настроить перенаправления для правила as-is или с помощью правила сопоставления путей. Дополнительные сведения о перенаправлении см. в статье Общие сведения о перенаправлении для Шлюза приложений.

301 Постоянный

Шлюз приложений возвращает ответы HTTP 301 при указании правила перенаправления с постоянным значением.

302 — найдено

Шлюз приложений возвращает ответы HTTP 302 при указании правила перенаправления со значением Found .

303 — См. другое.

Шлюз приложений возвращает ответы HTTP 303 при указании правила перенаправления со значением See Other .

Временный 307

Шлюз приложений возвращает ответы HTTP 307 при указании правила перенаправления с временным значением.

Коды ответа 4XX (ошибка клиента)

Коды ответов HTTP 400-499 указывают на проблему, которую инициирует клиент. Эти проблемы могут включать запросы, отправляемые клиентом к несоответствующему имени узла, тайм-ауты запросов, неаутентифицированные запросы, вредоносные запросы и многое другое.

Шлюз приложений собирает метрики, которые фиксируют распределение кодов состояния HTTP 4xx и 5xxx и содержит механизм ведения журнала, который записывает такие сведения, как IP-адрес клиента URI с кодом ответа. Метрики и ведение журнала позволяют устранить дополнительные неполадки. Клиенты также могут получать ответы HTTP 4xx от других прокси-серверов между клиентским устройством и шлюзом приложений, включая сеть доставки содержимого (CDN) и другие поставщики проверки подлинности. Дополнительные сведения см. в приведенных ниже статьях.

400 — недопустимый запрос

Коды ответов HTTP 400 часто отображаются при:

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

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

Категория Примеры
Недопустимый хост в строке запроса Хост, содержащий два двоеточия (example.com:8090:8080)
Отсутствует заголовок Host В запросе отсутствует заголовок Host
Наличие неправильно сформированного или недопустимого символа Зарезервированные символы — &,!. Обходной путь — кодировать его в процентах. Например: %>
Недопустимая версия HTTP GET /content.css HTTP/0.3
Имя поля заголовка и URI содержат символы, отличные от ASCII GET /«úü¡»¿.doc HTTP/1.1
Отсутствует заголовок длины содержимого для запроса POST Понятно без объяснений
Недопустимый метод HTTP GET123 /index.html HTTP/1.1
Повторяющиеся заголовки Authorization:<base64 закодированное содержимое>, Authorization: <base64 закодированное содержимое>
Недопустимое значение в длине содержимого Длина содержимого: abc, content-length: -10

При настройке взаимной проверки подлинности несколько сценариев могут привести к возврату ответа HTTP 400, включая следующий список:

  • Вы можете включить взаимную проверку подлинности, но сертификат клиента не был представлен.
  • Вы включаете проверку различающегося имени (DN), а DN сертификата клиента не соответствует DN указанной цепочки сертификатов.
  • Цепочка сертификатов клиента не соответствует цепочке сертификатов, настроенной в определенной политике SSL.
  • Срок действия сертификата клиента истек.
  • Вы включаете проверку отзыва сертификата клиентом OCSP, и сертификат отозван.
  • Вы включили проверку статуса отзыва сертификата клиента через OCSP, но Application Gateway не удаётся связаться с OCSP-сервером.
  • Вы включаете проверку отзыва с помощью клиента OCSP, но OCSP-ответчик не указан в сертификате.

Дополнительные сведения об устранении неполадок с взаимной аутентификацией см. в разделе "Устранение неполадок кода ошибки".

401 — не авторизовано;

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

Application Gateway может возвращать ответ HTTP 401 "Неавторизовано" на запрос проверки работоспособности Application Gateway, если настроен серверный пул с проверкой подлинности NTLM. В этом сценарии шлюз приложений помечает серверную часть как работоспособную. Устраните эту проблему с помощью одного из следующих методов:

  • Разрешить анонимный доступ в серверном пуле.
  • Настройте пробу, чтобы отправить запрос на другой "поддельный" сайт, который не требует проверки подлинности NTLM.
  • Настройте шлюз приложений, чтобы разрешить ответы HTTP 401 как допустимые для проб. Дополнительные сведения см. в разделе "Условия сопоставления пробы".

403 — запрещено;

Application Gateway возвращает ошибку HTTP 403 Forbidden при использовании SKU Брандмауэр веб-приложений Azure (WAF), если WAF настроен в режиме предотвращения. Если этот параметр включен, наборы правил WAF или настраиваемые правила запрета WAF соответствуют характеристикам входящего запроса. Затем шлюз приложений представляет ответ HTTP 403, запрещенный для клиента.

Чтобы устранить проблему ложных срабатываний WAF (легитимные запросы, заблокированные правилами WAF), выполните следующие действия:

  1. Включите журналы диагностики WAF и просмотрите ruleId_s поле, чтобы определить, какое правило блокирует запрос.
  2. Временно переключите WAF в режим обнаружения, чтобы фиксировать совпадения правил, не блокируя трафик. Этот подход помогает подтвердить ложные положительные результаты перед внесением изменений в правила. Дополнительные сведения см. в разделе Настройки политики WAF.
  3. Создайте исключения WAF для определенных атрибутов запроса (заголовки, файлы cookie или аргументы), которые вызывают ложные срабатывания.
  4. Если управляемое правило последовательно приводит к ложным результатам, а исключения не помогают, отключите отдельное правило в политике WAF.

Подробные инструкции см. в разделе "Устранение неполадок WAF для шлюза приложений " и рекомендаций WAF.

Другие причины для клиентов, получающих ответы HTTP 403, включают:

  • Попытки обновления протокола h2c. Шлюз приложений возвращает ошибки HTTP 403 при попытке обновления клиентов с HTTP/1.1 до HTTP/2.0 с помощью протокола h2c (HTTP/2 Cleartext). Шлюз приложений поддерживает HTTP/2 только через Transport Layer Security (TLS) (в прослушивателях HTTPS). Он не поддерживает обновления протокола h2c через HTTP-лиснеры. Это поведение происходит независимо от режима WAF. Клиенты должны использовать собственные подключения HTTP/2 по протоколу HTTPS или оставаться на HTTP/1.1 без попыток обновления.
  • Вы используете Служба приложений Azure в качестве серверной части и настроили его, чтобы разрешить доступ только из шлюза приложений. Эта конфигурация может возвращать ошибку HTTP 403 служб приложений. Эта ошибка обычно возникает из-за перенаправления или href ссылок, указывающих непосредственно на службы приложений, а не на IP-адрес шлюза приложений.
  • Если вы обращаетесь к BLOB-объекту хранилища и Application Gateway и конечная точка хранилища находятся в разных регионах, то возвращается ошибка HTTP 403, если общедоступный IP-адрес Application Gateway не включён в список разрешённых. Дополнительные сведения см. в разделе "Предоставление доступа из диапазона IP-адресов Интернета".

404 — страница не найдена

Шлюз приложений (SKU v2) возвращает ответ HTTP 404 при отправке запроса с именем узла, которое не соответствует ни одному из настроенных прослушивателей для нескольких сайтов, и при этом отсутствует базовый прослушиватель. Дополнительные сведения см. в разделе "Типы прослушивателей".

408 — Истекло время ожидания запроса

Вы получаете ответ HTTP 408, когда клиентские запросы к внешнему прослушивателю Application Gateway не получают ответа в течение 60 секунд. Эта ошибка может возникнуть из-за перегрузки трафика между локальными сетями и Azure, когда виртуальные устройства проверяют трафик или сам клиент становится перегруженным.

413 – Сущность запроса слишком велика

При использовании Брандмауэр веб-приложений Azure в шлюзе приложений возникает ответ HTTP 413, а размер клиентского запроса превышает максимальный размер текста запроса. Поле "Максимальный размер текста запроса" определяет общий предельный размер запроса без учета отправляемых файлов. Значение по умолчанию для размера тела запроса — 128 КБ. Дополнительные сведения см. в ограничениях размера запроса Брандмауэр веб-приложений.

499 — клиент закрыл подключение

Ответ HTTP 499 возникает, если запрос клиента, отправленный шлюзам приложений с помощью номера SKU версии 2, закрывается до завершения ответа сервера. Эта ошибка возникает в двух сценариях:

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

Коды ответов 5XX (ошибка сервера)

Коды ответов HTTP 500-599 указывают на проблему с шлюзом приложений или сервером серверной части при выполнении запроса.

500 — внутренняя ошибка сервера

Шлюз приложений Azure не должен возвращать коды ответов 500. Откройте запрос на поддержку, если вы видите этот код, так как эта проблема является внутренней ошибкой для службы. Дополнительные сведения о том, как открыть случай поддержки, см. в разделе Создание запроса поддержка Azure.

502 — недопустимый шлюз

Ошибки HTTP 502 могут иметь несколько основных причин, в том числе:

Сведения о сценариях возникновения ошибок HTTP 502 и их устранении см. в разделе "Устранение ошибок плохого шлюза".

503 — служба недоступна

Ответы HTTP 503 указывают, что шлюз приложений или сервер серверной части временно не может обрабатывать запрос. Ниже приведены распространенные причины.

  • Все члены внутреннего пула неработоспособны, как определено пробами работоспособности, и для обработки запросов нет работоспособного сервера.
  • Сервер серверной части перегружен или проходит обслуживание и возвращает HTTP 503 непосредственно в шлюз приложений.
  • Автомасштабирование шлюза приложений версии 2 выполняется, и новые экземпляры еще не готовы обслуживать трафик.
  • Ограничения подключений достигнуты на шлюзе приложений или сервере бэкенда.

Чтобы устранить ошибки 503, выполните следующие действия.

  1. Проверьте область работоспособности серверной части на портале Azure, чтобы проверить состояние члена внутреннего пула.
  2. Проверьте конфигурацию проб мониторинга работоспособности, чтобы убедиться, что пробы не помечают работоспособные серверные узлы как неисправные. Дополнительные сведения см. в разделе "Обзор пробы работоспособности".
  3. Убедитесь, что серверное приложение работает напрямую, обходя шлюз приложений.
  4. Проверьте метрики шлюза приложений для количества подключений и использования единиц емкости в Azure Monitor.
  5. Для SKU v2 проверьте параметры автомасштабирования, чтобы минимальное число экземпляров было достаточным при всплесках трафика.

Дополнительные сведения см. в разделе "Устранение неполадок с работоспособностью серверной части" в Шлюзе приложений.

504 — Шлюз не отвечает

SKU шлюза приложений версии 2 отправляет ошибки HTTP 504, если время отклика серверной части превышает значение времени ожидания, настроенное в параметрах серверной части.

веб-сервер Internet Information Services (IIS)

Если в качестве backend-сервера используется IIS, см. Ограничения по умолчанию для веб-сайтов, чтобы задать значение тайм-аута. Дополнительные сведения см. в атрибуте connectionTimeout . Убедитесь, что время ожидания подключения в iis совпадает или не превышает время ожидания, заданное в параметрах серверной части.

Nginx

Если серверная часть использует Nginx или Nginx Ingress Controller и если у неё есть upstream-серверы, убедитесь, что значение nginx:proxy_read_timeout соответствует тайм-ауту, заданному в Backend Settings, или не превышает его.

Сценарии устранения неисправностей

Ошибка "ERRORINFO_INVALID_HEADER" в журналах доступа

Проблема.

Журнал доступа показывает ошибку ERRORINFO_INVALID_HEADER для запроса, хотя код ответа серверной части (serverStatus) равен 200. В других случаях серверная часть возвращает 500.

Причина

Клиент отправляет заголовок, содержащий символы возврата каретки (CR) и канала строк (LF).

Solution

Замените символы CR LF пробелами (SP) и повторно отправьте запрос шлюзу приложений.

  • Last updated on