Códigos de resposta HTTP no Gateway de Aplicações

Resumo

Este artigo explica por que o Gateway de Aplicativo do Azure retorna códigos de resposta HTTP específicos. Ele fornece causas comuns e etapas de solução de problemas para ajudá-lo a determinar a causa raiz de um código de resposta HTTP de erro. O Application Gateway pode retornar códigos de resposta HTTP para uma solicitação de cliente, independentemente de ele iniciar ou não uma conexão com um alvo de back-end.

Observação

Se uma conexão de cliente falhar antes que o Application Gateway retorne qualquer resposta HTTP, a falha provavelmente será uma falha no handshake TLS (Transport Layer Security). As causas comuns incluem incompatibilidades de versão do TLS (por exemplo, o cliente usa TLS 1.0 ou 1.1, enquanto o gateway requer TLS 1.2 ou superior) e conjuntos de criptografia sem suporte. A partir de 31 de agosto de 2025, o Gateway de Aplicativo do Azure descontinua o suporte para TLS 1.0 e 1.1. Para obter mais informações, consulte a visão geral da política TLS do Gateway de Aplicativo e configure versões de política do TLS e conjuntos de criptografia.

Códigos de resposta 3XX (redirecionamento)

O Gateway de Aplicação retorna respostas 300-399 quando uma solicitação de cliente corresponde a uma regra do gateway de aplicação que possui redirecionamentos configurados. Você pode configurar redirecionamentos em uma regra como está ou por meio de uma regra de mapeamento de rota. Confira mais informações sobre redirecionamentos em Visão geral de redirecionamento do Gateway de Aplicativo.

Redirecionamento permanente 301

O Gateway de Aplicativo retorna respostas HTTP 301 quando você especifica uma regra de redirecionamento com o valor Permanente .

302 Encontrado

O Gateway de Aplicativo retorna respostas HTTP 302 quando você especifica uma regra de redirecionamento com o valor Encontrado .

303 Ver outro

O Gateway de Aplicativo retorna respostas HTTP 303 quando você especifica uma regra de redirecionamento com o valor Ver Outro .

Redirecionamento temporário 307

O Application Gateway retorna respostas HTTP 307 quando você especifica uma regra de redirecionamento com o valor temporário.

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

Os códigos de resposta 400-499 indicam um problema iniciado pelo cliente. Esses problemas podem variar desde o cliente iniciando solicitações até um nome de host incompatível, tempo finalizado para a solicitação, solicitação não autenticada, solicitações mal-intencionadas e muito mais.

O Gateway de Aplicativo coleta métricas que capturam a distribuição de códigos de status 4xx/5xxx e tem um mecanismo de 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 adicional. Os clientes também podem receber respostas 4xx de outros proxies entre o dispositivo cliente e o Gateway de Aplicações. Por exemplo, CDN (Rede de Distribuição de Conteúdo) e outros provedores de autenticação. Consulte os artigos a seguir para obter mais informações.

400 – Solicitação incorreta

Normalmente, você vê códigos de resposta HTTP 400 quando:

  • Inicie tráfego que não seja HTTP ou HTTPS para um gateway de aplicativo usando um ouvinte HTTP ou HTTPS.
  • Inicie o tráfego HTTP para um ouvinte com HTTPS, sem nenhum redirecionamento configurado.
  • Você configura a autenticação mútua, mas o Gateway de Aplicações não consegue negociar corretamente.
  • A solicitação não está em conformidade com RFC.

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

Categoria Exemplos
Host inválido na linha de solicitação Host contendo duas colunas (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 Caracteres reservados são &,!. A solução alternativa é codificá-lo como uma porcentagem. Por exemplo: %&
Versão HTTP inválida GET /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
Cabeçalho de comprimento de conteúdo ausente para solicitação POST Auto-explicativo
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 Content-Length: abc, Content-Length: -10

Quando você configura a autenticação mútua, vários cenários podem levar a uma resposta HTTP 400 ser retornada ao cliente, incluindo:

  • Você habilita a autenticação mútua, mas o certificado do cliente não foi apresentado.
  • Você habilita a validação de DN (Nome Diferenciado) 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.
  • Você habilita a verificação de revogação pelo cliente OCSP (Protocolo de Status de Certificado Online) e o certificado é revogado.
  • Você habilita a verificação de revogação do cliente OCSP, mas o Gateway de Aplicação não consegue contatar o respondedor OCSP.
  • Habilite a verificação de revogação do cliente OCSP, mas o respondente OCSP não é fornecido no certificado.

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

401 - Não autorizado

O Gateway de Aplicativo retornará uma resposta não autorizada HTTP 401 ao cliente se o cliente não estiver autorizado a acessar o recurso. Existem vários motivos para que o 401 seja retornado. A lista a seguir fornece alguns motivos com possíveis correções.

  • Se o cliente tiver acesso, ele poderá ter um cache de navegador desatualizado. Limpe o cache do navegador e tente acessar o aplicativo novamente.

O Application Gateway poderá retornar uma resposta não autorizada HTTP 401 à solicitação de sonda do AppGW se você configurar o pool de back-end com autenticação NTLM. Nesse cenário, o Gateway de Aplicações marca o back-end como saudável. Resolva esse problema usando um dos seguintes métodos:

  • Permita acesso anônimo no pool de back-end.
  • Configure a investigação para enviar a solicitação para outro site "falso" que não exija NTLM.
  • Não recomendado, pois essa solução não nos informa se o site real por trás do gateway de aplicativo está ativo ou não.
  • Configure o gateway de aplicativos para permitir respostas 401 como válidas para as sondas: Condições de correspondência da sonda.

403 - Proibido

O Gateway de Aplicativo apresenta HTTP 403 Proibido quando você usa skus do WAF (Firewall do Aplicativo Web) e tem o WAF configurado no modo prevenção. Se os conjuntos de regras waf habilitados ou as regras de WAF de negação personalizada corresponderem às características de uma solicitação de entrada, o Gateway de Aplicativo apresentará uma resposta 403 proibida ao cliente.

Para solucionar problemas de falsos positivos do WAF (solicitações legítimas bloqueadas pelas regras do WAF):

  1. Habilite os logs de diagnóstico do WAF e examine o ruleId_s campo para identificar qual regra está bloqueando a solicitação.
  2. Alterne temporariamente o WAF para o modo de detecção para registrar regras de correspondência sem bloquear o tráfego. Essa abordagem ajuda você a confirmar falsos positivos antes de fazer alterações de regra. Para obter mais informações, confira Configurações de política do WAF.
  3. Crie exclusões de WAF para atributos de solicitação específicos (cabeçalhos, cookies ou argumentos) que geram falsos positivos.
  4. Se uma regra gerenciada causar consistentemente falsos positivos e exclusões não forem suficientes, desabilite a regra individual na política do WAF.

Para obter diretrizes detalhadas, consulte Solucionar problemas do WAF para Gateway de Aplicativo e práticas recomendadas de WAF.

Outros motivos pelos quais os clientes recebem respostas 403 incluem:

  • Tentativas de atualização de protocolo h2c: o Gateway de Aplicativo retorna 403 erros quando os clientes tentam atualizar de HTTP/1.1 para HTTP/2.0 usando o protocolo h2c (HTTP/2 Cleartext). O Gateway de Aplicativo só dá suporte a HTTP/2 por TLS (ouvintes HTTPS). Ele não dá suporte a atualizações de protocolo h2c em ouvintes HTTP. Esse comportamento ocorre independentemente do modo WAF. Os clientes devem usar conexões HTTP/2 nativas via HTTPS ou permanecer em HTTP/1.1 sem tentativas de atualização.
  • Você está usando o Serviço de Aplicativo como back-end e configurou-o para permitir o acesso somente do Gateway de Aplicativo. Essa configuração pode retornar um erro 403 pelos Serviços de Aplicativo. Esse erro normalmente ocorre devido a redirecionamentos ou links href que apontam diretamente para os Serviços de Aplicativo em vez de apontarem para o endereço IP do Gateway de Aplicativo.
  • Se você estiver acessando um blob de armazenamento e o Gateway de Aplicativo e o ponto de extremidade de armazenamento estiverem em regiões diferentes, um erro 403 será retornado se o endereço IP público do Gateway de Aplicativo não estiver listado como permitido. Consulte Conceder acesso a partir de um intervalo de IP da Internet.

404 − Página não encontrada

Uma resposta HTTP 404 é gerada quando você faz uma solicitação ao Gateway de Aplicativo (SKUs V2) com um nome de host que não corresponde a nenhum dos ouvintes de vários sites configurados e não há nenhum ouvinte Básico presente. Para saber mais, confira os tipos de ouvintes.

408 – Tempo limite da solicitação

Você pode observar uma resposta HTTP 408 quando as solicitações de um cliente para o listener de front-end do Gateway de Aplicativo não recebem resposta dentro de 60 segundos. Você pode observar esse erro devido ao congestionamento de tráfego entre redes locais e o Azure, quando o dispositivo virtual inspeciona o tráfego ou o próprio cliente fica sobrecarregado.

413 – Entidade de requisição muito grande

Você pode observar uma resposta HTTP 413 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 de tamanho de corpo da solicitação máximo controla o limite de tamanho de solicitação geral excluindo qualquer carregamento de arquivo. O valor padrão para o tamanho do corpo da solicitação é 128 KB. Para obter mais informações, consulte Web Application Firewall limites de tamanho da solicitação.

499 – Cliente fechou a conexão

Uma resposta HTTP 499 é apresentada se uma solicitação de cliente que você enviou aos gateways de aplicativo usando o sku v2 for fechada antes que o servidor termine de responder. Você pode observar esse erro em dois 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 tempo suficiente para receber a resposta do servidor. Nesse caso, é melhor aumentar o tempo limite no cliente. Em gateways de aplicativo 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)

Códigos de resposta 500-599 indicam um problema com o gateway de aplicativo ou o servidor de back-end ao executar a solicitação.

500 – Erro interno do servidor

O Gateway de Aplicativo do Azure não deve retornar 500 códigos de resposta. Abra uma solicitação de suporte se você vir esse código, porque esse problema é um erro interno ao serviço. Para obter informações sobre como abrir um caso de suporte, consulte Criar uma solicitação Azure support.

502 – Gateway incorreto

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

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

503 – Serviço indisponível

As respostas HTTP 503 indicam que o Gateway de Aplicativo ou um servidor de back-end não consegue lidar temporariamente com a solicitação. As causas mais comuns incluem:

  • Todos os membros do pool de backend estão com problemas, conforme determinado por sondas de integridade, e nenhum servidor saudável está disponível para atender solicitações.
  • O servidor de back-end está sobrecarregado ou passando por manutenção e retornando 503 diretamente para o Gateway de Aplicativo.
  • O processo de dimensionamento automático na versão V2 do Gateway de Aplicações está em andamento, e novas instâncias ainda não estão prontas para processar o tráfego.
  • Os limites de conexão são atingidos no Gateway de Aplicativo ou no servidor de back-end.

Para solucionar erros 503:

  1. Verifique o painel de saúde do back-end no portal do Azure para verificar o status dos membros do pool de back-end.
  2. Revise a configuração da sonda de integridade para garantir que as sondas não estejam marcando incorretamente back-ends saudáveis como não saudáveis. Para obter mais informações, consulte a visão geral da sonda de integridade.
  3. Verifique se o aplicativo de back-end está operacional acessando-o diretamente, ignorando o Gateway de Aplicativo.
  4. Verifique as métricas do Gateway de Aplicativo para obter a contagem de conexões e a utilização da unidade de capacidade no Azure Monitor.
  5. Para SKUs V2, revisar as configurações de dimensionamento automático para garantir uma quantidade mínima suficiente de instâncias durante picos de tráfego.

Para obter mais informações, consulte Solucionar problemas de saúde do backend.

504 – Tempo limite do gateway

Azure Application Gateway V2 SKU enviará 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 Internet Information Services)

Se o servidor de back-end for o IIS, consulte Limites padrão para sites da Web para definir o valor do tempo limite. Consulte o atributo connectionTimeout para obter detalhes. Verifique se o tempo limite de conexão no IIS coincide ou não excede o tempo limite definido nas configurações do sistema de back-end.

Nginx

Se o servidor de back-end for Nginx ou Nginx Ingress Controller e se ele tiver servidores upstream, verifique se o valor de nginx:proxy_read_timeout corresponde ou não excede o tempo limite definido na configuração de back-end.

Cenários de solução de problemas

Erro de "ERRORINFO_INVALID_HEADER" nos logs de acesso

Problema: o log do Access mostra um erro "ERRORINFO_INVALID_HEADER" para uma solicitação, mesmo que o código de resposta de back-end (serverStatus) seja 200. Em outros casos, o servidor de back-end retorna 500.

Causa: o cliente envia um cabeçalho que contém caracteres CR LF.

Solução: Substitua os caracteres CR LF por SP (espaço em branco) e reenvie a solicitação para o Gateway de Aplicações.

  • Last updated on