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

Сводка

В этой статье объясняется, почему Шлюз приложений 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 (перенаправление)

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

Постоянное перенаправление 301

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

302 — найдено

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

303 См. другие

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

Временное перенаправление 307

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

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

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

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

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

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

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

Ниже приведены некоторые распространенные причины, по которым запрос не соответствует RFC:

Категория	Примеры
Недопустимый хост в строке запроса	Хост, содержащий два двоеточия (example.com:8090:8080)
Отсутствует заголовок хоста	Запрос не содержит заголовка 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 закодированное содержимое>
Недопустимое значение в Content-Length	Длина содержимого: abc, Длина содержимого: -10

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

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

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

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

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

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

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

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

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

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

Для устранения проблем с ложными положительными срабатываниями WAF (допустимые запросы, заблокированные правилами WAF):

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

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

Другие причины, по которым клиенты получают ответы 403, включают:

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

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

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

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

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

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

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

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

Ответ HTTP 499 отображается, если запрос клиента, отправленный шлюзам приложений с использованием SKU v2, закрывается до получения ответа от сервера. Эту ошибку можно наблюдать в двух сценариях. Первый сценарий — это ситуация, когда клиенту возвращается большой объем данных, и клиент может закрыть или обновить приложение, прежде чем сервер завершит отправку большого ответа. Второй сценарий заключается в том, что время ожидания на стороне клиента низкое и не ожидает достаточно долго, чтобы получить ответ от сервера. В этом случае лучше увеличить время ожидания на стороне клиента. В шлюзах приложений с использованием SKU версии 1 код ответа HTTP 0 может быть вызван для клиента, закрывающего подключение, прежде чем сервер завершит реагирование.

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

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

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

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

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

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

NSG (группа безопасности сети), UDR (определяемый пользователем маршрут) или пользовательский DNS блокирует доступ к членам внутреннего пула.
Серверные виртуальные машины или экземпляры масштабируемых наборов виртуальных машин не отвечают на проверку работоспособности по умолчанию.
Недопустимая или неправильная конфигурация пользовательских проб работоспособности.
Azure Application Gateway backend pool не настроен или пуст.
В наборе масштабирования виртуальных машин ни одна виртуальная машина или экземпляр не работоспособны.
Время ожидания запроса или проблемы с подключением с пользовательскими запросами: шлюз приложений Azure V1 SKU отправляет ошибки HTTP 502, если время отклика серверной части превышает значение тайм-аута, настроенное в параметрах серверной части.

Для получения сведений о сценариях возникновения ошибок 502 и способах их устранения см. раздел "Устранение ошибок 502 (Плохой шлюз)".

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

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

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

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

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

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

504 — тайм-аут шлюза

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

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

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

Nginx

Если сервер, работающий в фоновом режиме, представляет собой Nginx или Nginx Ingress Controller, и если у него есть вышестоящие серверы, убедитесь, что значение nginx:proxy_read_timeout совпадает или не превышает время ожидания, установленное в настройках бэкенда.

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

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

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-03-27