Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приводятся причины, по которым Шлюз приложений 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 — запрещено;
HTTP 403 Запрещенный доступ возникает, когда клиенты используют WAF (брандмауэр веб-приложений) и если WAF настроен в режиме предотвращения. Если включенные наборы правил WAF или пользовательские правила блокировки WAF соответствуют характеристикам входящего запроса, клиент получает ответ 403 с запретом.
Другие причины, по которым клиенты получают ответы 403, включают:
- Вы используете службу приложений в качестве серверной части, и она настроена разрешать доступ только из шлюза приложений. Это может возвращать ошибку 403 от Службы приложений. Это обычно происходит из-за перенаправлений или href-ссылок, которые указывают непосредственно на Службы приложений вместо того, чтобы указывать на IP-адрес Шлюза приложений.
- Если вы обращаетесь к блогу хранилища и Шлюз приложений и конечная точка хранения находятся в разных регионах, возвращается ошибка 403, если общедоступный IP-адрес Шлюза приложений не внесен в список разрешенных. См. раздел "Предоставление доступа" из диапазона IP-адресов Интернета.
404 — страница не найдена
Ответ HTTP 404 генерируется при выполнении запроса к шлюзу приложений (SKU версии 2) с именем узла, который не соответствует ни одному из настроенных многосайтовых прослушивателей, и отсутствует базовый прослушиватель. Дополнительные сведения о типах прослушивателей.
408 — время ожидания запроса
Ответ HTTP 408 возникает, когда клиентские запросы к интерфейсному прослушивателю шлюза приложений не отвечают в течение 60 секунд. Эта ошибка может наблюдаться из-за перегрузки трафика между локальными сетями и Azure, когда виртуальное устройство проверяет трафик или сам клиент становится перегруженным.
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 Application Gateway не настроен либо пуст.
- В наборе масштабирования виртуальных машин ни одна виртуальная машина или экземпляр не работоспособны.
- Время ожидания запроса или проблемы с подключением при запросах пользователей — SKU шлюза приложений Azure версии 1 отправляет ошибки HTTP 502, если время отклика сервера превышает значение тайм-аута, настроенное в параметрах сервера.
Для получения сведений о сценариях возникновения ошибок 502 и способах их устранения см. раздел "Устранение ошибок 502 (Плохой шлюз)".
504 — тайм-аут шлюза
Шлюз приложений Azure SKU V2 отправляет ошибки HTTP 504, если время отклика серверной части превышает тайм-аут, настроенный в настройках серверной части.
IIS (веб-сервер служб Internet Information Services)
Если внутренний сервер — IIS, см. сведения о ограничениях по умолчанию для веб-сайтов, чтобы задать значение времени ожидания. Дополнительные сведения см. в атрибуте connectionTimeout
. Убедитесь, что время ожидания подключения в службах IIS совпадает или не превышает время ожидания, заданное в параметре серверной части.
Nginx
Если сервер Nginx или Nginx Ingress Controller, и если он имеет вышестоящие серверы, убедитесь, что значение nginx:proxy_read_timeout
совпадает или не превышает время ожидания, установленное в настройках серверной части.
Устранение неполадок в сценариях
Ошибка "ERRORINFO_INVALID_HEADER" в журналах Access
Проблема: В журнале доступа отображается ошибка "ERRORINFO_INVALID_HEADER" для запроса, несмотря на код ответа серверной части (serverStatus) 200. В других случаях сервер может вернуть ошибку 500.
Причина: клиент отправляет заголовок, содержащий символы CR LF.
Решение. Замените символы CR LF на sp (пробелы) и повторно отправьте запрос шлюзу приложений.
Следующие шаги
Если сведения в этой статье не помогают устранить проблему, отправьте запрос в службу поддержки.