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

Сводка

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

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

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

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

Ответы HTTP 301 отображаются при указании правила перенаправления со значением Permanent.

302 — найдено

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

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

Ответы HTTP 302 отображаются при указании правила перенаправления со значением See Other .

307 — временное перенаправление.

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

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

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

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

• Метрики, поддерживаемые SKU шлюза приложений версии 2
• Журналы диагностики

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 не указан в сертификате.

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

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

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

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

Несанкционированный ответ HTTP 401 можно вернуть в запрос пробы AppGW, если серверный пул настроен с проверкой подлинности NTLM . В этом сценарии сервер отмечен как работоспособный. Есть несколько способов устранить эту проблему.

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

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

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

Другие причины, по которым клиенты получают ответы 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-адрес Шлюза приложений.
• Если вы обращаетесь к блогу хранилища и Шлюз приложений и конечная точка хранения находятся в разных регионах, возвращается ошибка 403, если общедоступный IP-адрес Шлюза приложений не внесен в список разрешенных. См. раздел "Предоставление доступа" из диапазона IP-адресов Интернета.

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

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

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

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

413 — Размер запроса слишком велик

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

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

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

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

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

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

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

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

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

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

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

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

Версия SKU шлюза приложений #REF! V2 отправляет ошибки HTTP 504, если время отклика бэкенда превышает значение таймаута, настроенное в параметрах бэкенда.

IIS (веб-сервер #REF!)

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

Nginx

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

Устранение неполадок в сценариях

Ошибка "ERRORINFO_INVALID_HEADER" в журналах Access

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

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

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

Дальнейшие шаги

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