Partilhar via

Códigos de resposta HTTP no Application Gateway

Este artigo apresenta razões pelas quais o Azure Application Gateway retorna códigos de resposta HTTP específicos. Causas comuns e etapas de solução de problemas são fornecidas para ajudá-lo a determinar a causa raiz do código de resposta HTTP de erro. Os códigos de resposta HTTP podem ser retornados para uma solicitação de cliente, independentemente de uma conexão ter sido iniciada ou não com um destino de back-end.

Códigos de resposta 3XX (redirecionamento)

300-399 respostas são apresentadas quando uma solicitação de cliente corresponde a uma regra de gateway de aplicações que tem redirecionamentos configurados. Os redirecionamentos podem ser configurados em uma regra tal como está ou por meio de uma regra de mapeamento de caminho. Para obter mais informações sobre redirecionamentos, consulte Visão geral do redirecionamento do Application Gateway.

301 Redirecionamento permanente

As respostas HTTP 301 são apresentadas quando uma regra de redirecionamento é especificada com o valor Permanente .

302 Encontrados

As respostas HTTP 302 são apresentadas quando uma regra de redirecionamento é especificada com o valor Found .

303 Ver outros

As respostas HTTP 302 são apresentadas quando uma regra de redirecionamento é especificada com o valor Consulte Outro .

307 Redirecionamento temporário

As respostas HTTP 307 são apresentadas quando uma regra de redirecionamento é especificada com o valor Temporário .

Códigos de resposta 4XX (erro do cliente)

Os códigos de resposta 400-499 indicam um problema iniciado a partir do cliente. Esses problemas podem variar desde o cliente a iniciar solicitações até um nome de host não correspondido, tempo limite de solicitação, solicitação não autenticada, solicitação maliciosa e muito mais.

Application Gateway coleta métricas que capturam a distribuição de códigos de status 4xx/5xx e possui um mecanismo de registro em log que captura informações como o endereço IP do cliente URI e o código de resposta. As métricas e o registro em log permitem a solução de problemas adicionais. Os clientes também podem receber uma resposta 4xx de outros proxies situados entre o dispositivo cliente e o Application Gateway. Por exemplo, CDN (Content Delivery Network) e outros provedores de autenticação. Consulte os seguintes artigos para obter mais informações.

Métricas suportadas pelo SKU do Application Gateway V2Logs de diagnóstico

400 – Pedido Inválido

Os códigos de resposta HTTP 400 são comumente observados quando:

  • O tráfego não-HTTP/HTTPS é enviado para um gateway de aplicação com um listener HTTP ou HTTPS.
  • O tráfego HTTP é iniciado para um listener com HTTPS, sem redirecionamento configurado.
  • A autenticação mútua está configurada, mas o processo de negociação não consegue ser realizado corretamente.
  • A solicitação não é compatível com RFC.

Alguns motivos comuns para a solicitação não estar em conformidade com a RFC são:

Categoria Exemplos
Host inválido na linha de solicitação Host contendo dois pontos (example.com:8090:8080)
Cabeçalho de Host ausente A solicitação não tem cabeçalho de host
Presença de caractere malformado ou ilegal Os caracteres reservados são &,!. A solução alternativa é codificá-lo como uma porcentagem. Por exemplo: %&
Versão HTTP inválida Obtenha /content.css HTTP/0.3
O nome do campo de cabeçalho e o URI contêm caracteres não-ASCII GET /«úü¡»¿.doc HTTP/1.1
Falta o cabeçalho Content-Length na solicitação POST Autoexplicativo
Método HTTP inválido GET123 /index.html HTTP/1.1
Cabeçalhos duplicados Autorização:<conteúdo codificado em base64>, Autorização: <conteúdo codificado em base64>
Valor inválido em Content-Length Comprimento do Conteúdo: abc, Comprimento do Conteúdo: -10

Para casos em que a autenticação mútua é configurada, vários cenários podem levar a uma resposta HTTP 400 sendo retornada ao cliente, como:

  • A autenticação mútua está habilitada, mas o certificado do cliente não foi apresentado.
  • A validação de DN (Nome Distinto) está habilitada e o DN do certificado do cliente não corresponde ao DN da cadeia de certificados especificada.
  • A cadeia de certificados do cliente não corresponde à cadeia de certificados configurada na Política SSL definida.
  • O certificado do cliente expirou.
  • A verificação de revogação do cliente OCSP (Online Certificate Status Protocol) está habilitada e o certificado é revogado.
  • A verificação de revogação do Cliente OCSP (Online Certificate Status Protocol) está ativada, mas não é possível contactar.
  • A verificação de revogação do cliente OCSP (Online Certificate Status Protocol) está ativada, mas o OCSP responder não é fornecido no certificado.

Para obter mais informações sobre como solucionar problemas de autenticação mútua, consulte Solução de problemas de código de erro.

401 – Não autorizado

Uma resposta HTTP 401 não autorizada é retornada ao cliente se o cliente não estiver autorizado a acessar o recurso. Há várias razões para que 401 sejam devolvidos. A seguir estão algumas razões com possíveis correções.

  • Se o cliente tiver acesso, pode ter uma cache do browser desatualizada. Limpe a cache do browser e tente aceder novamente à aplicação.

Uma resposta HTTP 401 não autorizada pode ser devolvida à solicitação de teste do AppGW caso o grupo de back-end esteja configurado com autenticação NTLM. Neste cenário, o back-end é marcado como em bom estado de funcionamento. Existem várias formas de resolver este problema:

  • Permitir acesso anónimo no conjunto de backend.
  • Configure a sonda para enviar o pedido para outro site "falso" que não requeira NTLM.
  • Não recomendado, pois isso não nos dirá se o site real por trás do gateway de aplicativo está ativo ou não.
  • Configure o gateway da aplicação para permitir respostas 401 como válidas para sondas: Condições de correspondência de sonda.

403 – Proibido

HTTP 403 Forbidden é apresentado quando os clientes estão utilizando WAF (Web Application Firewall) skus e têm WAF configurado no modo de prevenção. Se os conjuntos de regras WAF habilitados ou as regras WAF de negação personalizada corresponderem às características de uma solicitação de entrada, será apresentada ao cliente uma resposta 403 proibida.

Outras razões para os clientes receberem 403 respostas incluem:

  • Você está usando o Serviço de Aplicativo como back-end e ele está configurado para permitir acesso somente do Application Gateway. Isso pode retornar um erro 403 pelos Serviços de Aplicativo. Isso geralmente acontece devido a redirecionamentos/links href que apontam diretamente para os Serviços de Aplicativo, em vez de apontar para o endereço IP do Application Gateway.
  • Se estiver a aceder a um blog de armazenamento e o Application Gateway e o ponto de extremidade de armazenamento estiverem em regiões diferentes, será retornado um erro 403 se o endereço IP público do Application Gateway não estiver na lista autorizada. Consulte Conceder acesso a partir de um intervalo de endereços IP da Internet.

404 – Página não encontrada

Uma resposta HTTP 404 é gerada quando uma solicitação é feita ao Application Gateway (SKUs V2) com um nome de host que não corresponde a nenhum dos ouvintes multissite configurados e não há nenhum ouvinte básico presente. Saiba mais sobre os tipos de ouvintes.

408 – Tempo limite de solicitação

Uma resposta HTTP 408 pode ser observada quando as solicitações do cliente para o ouvinte de frontend do gateway de aplicação não respondem dentro de 60 segundos. Esse erro pode ser observado devido ao congestionamento de tráfego entre as redes locais e o Azure, quando o dispositivo virtual inspeciona o tráfego ou o próprio cliente fica sobrecarregado.

413 – Entidade de solicitação muito grande

Uma resposta HTTP 413 pode ser observada ao usar o Firewall de Aplicativo Web do Azure no Gateway de Aplicativo e o tamanho da solicitação do cliente excede o limite máximo de tamanho do corpo da solicitação. O campo Tamanho máximo do corpo do pedido controla o limite geral do tamanho do pedido, excluindo todos os carregamentos de ficheiros. O valor predefinido para o tamanho do corpo do pedido é 128 KB. Para obter mais informações, consulte Limites de tamanho de solicitação do Web Application Firewall.

499 – Cliente fechou a conexão

Será apresentada uma resposta HTTP 499 se um pedido do cliente enviado para os gateways de aplicação com um SKU v2 for encerrado antes de o servidor terminar de responder. Este erro pode ser observado em 2 cenários. O primeiro cenário é quando uma resposta grande é retornada ao cliente e o cliente pode ter fechado ou atualizado o aplicativo antes que o servidor termine de enviar uma resposta grande. O segundo cenário é quando o tempo limite no lado do cliente é baixo e não espera o tempo suficiente para receber a resposta do servidor. Neste caso, é melhor aumentar o tempo limite no cliente. Em gateways de aplicativos que usam sku v1, um código de resposta HTTP 0 pode ser gerado para o cliente fechar a conexão antes que o servidor termine de responder também.

Códigos de resposta 5XX (erro do servidor)

Os códigos de resposta 500-599 indicam que ocorreu um problema com o Application Gateway ou o servidor back-end durante a execução da solicitação.

500 – Erro interno do servidor

O Gateway de Aplicação do Azure não deverá apresentar 500 códigos de resposta. Abra um pedido de suporte se vir este código, uma vez que este problema é um erro interno do serviço. Para obter informações sobre como abrir um caso de suporte, consulte Criar uma solicitação de suporte do Azure.

502 – Porta de entrada ruim

Os erros HTTP 502 podem ter várias causas raiz, por exemplo:

Para obter informações sobre cenários em que ocorrem erros 502 e como solucioná-los, consulte Solucionar erros de gateway incorreto.

504 – Tempo limite do gateway

O SKU do Gateway de Aplicativo do Azure V2 enviou erros HTTP 504 se o tempo de resposta do Back-end exceder o valor de tempo limite configurado na Configuração de Back-end.

IIS (servidor Web dos Serviços de Informações da Internet)

Se o servidor de retaguarda for o IIS, consulte Limites padrão para sites para definir o valor do tempo limite. Consulte o connectionTimeout atributo para obter detalhes. Verifique se o tempo limite de conexão no IIS corresponde ou não excede o tempo limite definido na configuração de back-end.

Nginx

Se o servidor de back-end for Nginx ou Nginx Ingress Controller, e se tiver servidores upstream, certifique-se de que o valor de nginx:proxy_read_timeout corresponda ou não exceda o limite de tempo definido na configuração de back-end.

Cenários de solução de problemas

Erro "ERRORINFO_INVALID_HEADER" nos registos do Access

Problema: o log do Access exibe um erro "ERRORINFO_INVALID_HEADER" para uma solicitação, apesar do código de resposta de back-end (serverStatus) ser 200. Em outros casos, o servidor back-end pode retornar 500.

Causa: O cliente envia um cabeçalho contendo caracteres CR LF.

Solução: Substitua os caracteres CR LF pelo SP (espaço em branco) e reenvie a solicitação para o Application Gateway.

Próximos passos

Se as informações neste artigo não ajudarem a resolver o problema, envie um pedido de suporte.