Compartilhar via

Códigos de resposta HTTP no Gateway de Aplicativo

  • Artigo

Este artigo fornece motivos sobre por que o Gateway de Aplicativo do Azure 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 a uma solicitação de cliente, independentemente de uma conexão ter sido iniciada ou não para um destino de back-end.

Códigos de resposta 3XX (redirecionamento)

As respostas 300-399 são apresentadas quando uma solicitação de cliente corresponde a uma regra de gateway de aplicativo que tenha redirecionamentos configurados. Os redirecionamentos podem ser configurados em uma regra como está ou por meio de uma regra de mapa de caminho. Confira mais informações sobre redirecionamentos em Visão geral de redirecionamento do Gateway de Aplicativo.

301 Redirecionamento Permanente

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

302 Encontrado

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

303 Ver Outro

As respostas HTTP 302 são apresentadas quando uma regra de redirecionamento é especificada com o valor Ver 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 de cliente)

Os códigos de resposta 400-499 indicam um problema iniciado pelo cliente. Esses problemas podem variar desde as solicitações de início do cliente até um nome do host não correspondente, tempo limite de solicitação, solicitação não autenticada, solicitação mal-intencionada, e muito mais.

O Gateway de Aplicativo coleta métricas que capturam a distribuição de códigos de status 4xx/5xx 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 resposta 4xx de outros proxies entre o dispositivo cliente e o Gateway de Aplicativo. Por exemplo, CDN e outros provedores de autenticação. Consulte os artigos a seguir para obter mais informações.

Métricas suportadas pelos logs de SKUdiagnóstico do Gateway de Aplicativo V2

400 – Solicitação incorreta

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

  • O tráfego não HTTP/HTTPS é iniciado em um gateway de aplicativo com um ouvinte HTTP ou HTTPS.
  • O tráfego HTTP é iniciado em um ouvinte com HTTPS, sem redirecionamento configurado.
  • A autenticação mútua está configurada e não pode 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:

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 caráter malformado ou ilegal 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
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

Para casos em que a autenticação mútua é configurada, vários cenários podem levar a uma resposta HTTP 400 retornando 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 de 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 de 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 de Cliente OCSP está habilitada, 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

Uma resposta não autorizada HTTP 401 será retornada ao cliente se o cliente não estiver autorizado a acessar o recurso. Há várias razões para que 401 seja retornado. A seguir estão 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.

Uma resposta não autorizada HTTP 401 pode ser retornada à solicitação de investigação AppGW se o pool de back-end estiver configurado com autenticação NTLM de segurança. Nesse cenário, o back-end é marcado como íntegro. Há várias maneiras de resolver esse problema:

  • 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 isso não nos informará se o site real por trás do gateway de aplicativo está ativo ou não.
  • Configure o gateway de aplicativo para permitir 401 respostas como válidas para as investigações: Condições de correspondência de investigação.

403 - Proibido

HTTP 403 − Proibido é apresentado quando os clientes estão utilizando skus WAF e têm o WAF configurado no modo de Prevenção. Se os conjuntos de regras do WAF habilitados ou as regras de negação de WAF personalizadas corresponderem às características de uma solicitação de entrada, será apresentada ao cliente uma resposta proibida 403.

Outros motivos para os clientes que recebem respostas 403 incluem:

  • Você está usando o Serviço de Aplicativo como back-end e ele está configurado para permitir acesso somente a partir do Gateway de Aplicativo. Isso pode retornar um erro 403 pelos Serviços de Aplicativos. Isso geralmente acontece devido a redirecionamentos/links href que apontam diretamente para os Serviços de Aplicativos em vez de apontar para o endereço IP do Gateway de Aplicativos.
  • Se você estiver acessando um blog de armazenamento e o Gateway de Aplicativo 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 Gateway de Aplicativo não estiver na lista de permitidos. Consulte Conceder acesso a partir de um intervalo de IP da Internet.

404 − Página não encontrada

Uma resposta HTTP 404 pode ser retornada se uma solicitação for enviada para um gateway de aplicativo que seja:

408 – Tempo limite de solicitação

Uma resposta HTTP 408 pode ser observada quando as solicitações do cliente para o ouvinte front-end do gateway de aplicativo não respondem dentro de 60 segundos. Esse erro pode ser observado 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 solicitação muito grande

Uma resposta HTTP 413 pode ser observada ao usar o Azure Web Application Firewall 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 limites de tamanho de solicitação do Firewall do aplicativo Web.

499 – Cliente fechou a conexão

Uma resposta HTTP 499 é apresentada se uma solicitação de cliente enviada para gateways de aplicativo usando sku v2 for fechada antes que o servidor termine 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 suficiente para receber a resposta do servidor. Neste caso, é melhor aumentar o tempo limite no cliente. Em gateways de aplicativo usando sku v1, um código de resposta HTTP 0 pode ser gerado para o cliente fechando 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 gateway de aplicativo ou o servidor de back-end durante a execução da solicitação.

500 – Erro de servidor interno

O Gateway de Aplicativo do Azure não deve exibir 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 mais informações sobre como abrir um caso de suporte, consulte Criar uma solicitação de Suporte do Azure.

502 – Gateway incorreto

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

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.

504 – Tempo Limite do Gateway

A SKU do Gateway de Aplicativo V2 do Azure 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 back-end for IIS, consulte Limites padrão para sites para definir o valor de tempo limite. Consulte o atributo connectionTimeout 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 back-end for controlador de entrada nginx ou nginx e se tiver servidores upstream, certifique-se de que o valor de nginx:proxy_read_timeout corresponda ou não exceda com o tempo limite definido na configuração de back-end.

Próximas etapas

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