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 aplicativo que tem redirecionamentos configurados. Os redirecionamentos podem ser configurados em uma regra no estado em que se encontra ou por meio de uma regra de mapa 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 iniciando solicitações até um nome de host incomparável, tempo limite de solicitação, solicitação não autenticada, solicitação maliciosa e muito mais.

O Application Gateway coleta métricas que capturam a distribuição de códigos de status 4xx/5xx, tem um mecanismo de registro em log que captura informações como o endereço IP do cliente URI com 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 resposta 4xx de outros proxies entre o dispositivo cliente e o Application Gateway. Por exemplo, CDN e outros provedores de autenticação. Consulte os seguintes artigos para obter mais informações.

Métricas suportadas pelos logs de diagnóstico de SKUdo Application Gateway V2

400 – Mau Pedido

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

• O tráfego não HTTP/HTTPS é iniciado num gateway de aplicação com um serviço de escuta HTTP ou HTTPS.
• O tráfego HTTP é iniciado para um listener com HTTPS, sem redirecionamento configurado.
• A autenticação mútua está configurada e não consegue negociar 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:

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:

• O certificado do cliente não é apresentado, mas a autenticação mútua está habilitada.
• A validação de DN 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 está habilitada e o certificado é revogado.
• A verificação de revogação do cliente OCSP está habilitada, mas não pode ser contatada.
• A verificação de revogação do cliente OCSP está habilitada, mas o respondente OCSP 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 não autorizada HTTP 401 pode ser retornada à solicitação de teste AppGW se o pool de back-end estiver 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 back-end.
• Configure a pesquisa para enviar o pedido para outro site "falso" que não exija 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 do aplicativo para permitir 401 respostas como válidas para as sondas: condições de correspondência de sonda.

403 – Proibido

HTTP 403 Forbidden é apresentado quando os clientes estão utilizando skus WAF 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 você estiver acessando um blog de armazenamento e o Application Gateway e o ponto de extremidade de armazenamento estiverem em uma região diferente, um erro 403 será retornado se o endereço IP público do Application Gateway não estiver na lista de permissões. Consulte Conceder acesso a partir de um intervalo de IP da Internet.

404 – Página não encontrada

Pode ser devolvida uma resposta HTTP 404 se um pedido for enviado para um gateway de aplicação que esteja:

• Usando um sku v2.
• Sem uma correspondência de nome de host definida em qualquer ouvinte multissite.
• Não configurado com um ouvinte básico.

408 – Tempo limite de solicitação

Uma resposta HTTP 408 pode ser observada quando as solicitações do cliente para o ouvinte frontend do gateway de aplicativo não respondem em 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 fechado 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:

• NSG, UDR ou DNS personalizado está bloqueando o acesso aos membros do pool de back-end.
• VMs de back-end ou instâncias de conjuntos de dimensionamento de máquinas virtuais não estão respondendo à investigação de integridade padrão.
• Configuração inválida ou incorreta das pesquisas do estado de funcionamento personalizadas.
• O pool de back-end do Azure Application Gateway não está configurado ou vazio.
• Nenhuma das VMs ou instâncias no conjunto de dimensionamento de máquina virtual está íntegra.
• Problemas de tempo limite de solicitação ou conectividade com solicitações de usuário - O SKU do Gateway de aplicativo do Azure V1 enviou erros HTTP 502 se o tempo de resposta de back-end exceder o valor de tempo limite configurado na Configuração de Back-end.

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

A 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

Se o servidor de back-end for o IIS, consulte Limites Predefinidos para Sites para definir o valor do tempo limite. Consulte o connectionTimeout atributo para obter detalhes. Certifique-se de que o limite de tempo da ligação no IIS corresponde ou não excede o tempo limite definido na definição de back-end.

nginx

Se o servidor back-end for nginx ou nginx ingress controller, e se tiver servidores upstream, certifique-se de que o valor de corresponde ou não excede com o tempo limite definido na configuração de nginx:proxy_read_timeout back-end.

Próximos passos

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