Resolver problemas comuns do Azure Front Door

  • Artigo

Este artigo descreve como solucionar problemas comuns de roteamento que você pode enfrentar para sua configuração do Azure Front Door.

Outros cabeçalhos HTTP de depuração

Você pode solicitar que o Azure Front Door retorne cabeçalhos de resposta HTTP de depuração extras. Para obter mais informações, consulte cabeçalhos de resposta opcionais.

Resposta 503 ou 504 do Azure Front Door após alguns segundos

Sintoma

  • As solicitações regulares enviadas para seu back-end sem passar pela Porta da Frente do Azure estão sendo bem-sucedidas. Passar pela Porta da Frente do Azure resulta em 503 ou 504 respostas de erro.
  • A falha do Azure Front Door normalmente aparece após cerca de 30 segundos.
  • Erros intermitentes 503 aparecem com "ErrorInfo: OriginInvalidResponse".

Motivo

A causa desse problema pode ser uma das três coisas:

  • Sua origem está demorando mais do que o tempo limite configurado para receber a solicitação da Porta da Frente do Azure. O tempo limite padrão é de 30 segundos.
  • O tempo necessário para enviar uma resposta à solicitação do Azure Front Door está demorando mais do que o valor de tempo limite.
  • O cliente enviou uma solicitação de intervalo de bytes com um cabeçalho Accept-Encoding , o que significa que a compactação está habilitada.

Passos de resolução de problemas

  • Envie a solicitação para sua origem diretamente sem passar pela Porta da Frente do Azure. Veja quanto tempo a sua origem normalmente demora a responder.

  • Envie a solicitação pelo Azure Front Door e veja se você está recebendo 503 respostas. Caso contrário, o problema pode não ser um problema de tempo limite. Crie uma solicitação de suporte para solucionar o problema ainda mais.

  • Se as solicitações que passam pelo Azure Front Door resultarem em um código de resposta de erro 503, configure o tempo limite de resposta do Origin para o Azure Front Door. Pode aumentar o tempo limite predefinido para até 4 minutos (240 segundos). Para configurar a definição, vá para a página de descrição geral do perfil do Front Door. Selecione Tempo limite de resposta do Origin e insira um valor entre 16 e 240 segundos.

    Nota

    A capacidade de configurar o tempo limite de resposta do Origin só está disponível no Azure Front Door Standard/Premium.

    Captura de ecrã das definições de tempo limite de origem na página de descrição geral do perfil do Azure Front Door.

  • Se aumentar o tempo limite não resolver o problema, use uma ferramenta como o Fiddler ou a ferramenta de desenvolvedor do seu navegador para verificar se o cliente está enviando solicitações de intervalo de bytes com cabeçalhos Accept-Encoding . O uso dessa opção leva a origem a responder com diferentes comprimentos de conteúdo.

    Se o cliente estiver enviando solicitações de intervalo de bytes com cabeçalhos Accept-Encoding , você terá duas opções. A primeira opção é desativar a compressão na origem ou no Azure Front Door. A segunda opção é criar uma regra de conjunto de regras para remover Accept-Encoding da solicitação de solicitações de intervalo de bytes.

    Captura de tela que mostra a regra Accept-Encoding em um conjunto de regras.

503 respostas de Azure Front Door only for HTTPS

Sintoma

  • Quaisquer 503 respostas são retornadas somente para pontos de extremidade habilitados para HTTPS do Azure Front Door.
  • As solicitações regulares enviadas para seu back-end sem passar pela Porta da Frente do Azure estão sendo bem-sucedidas. Passar pela Porta da Frente do Azure resulta em 503 respostas de erro.
  • Erros intermitentes 503 aparecem com "ErrorInfo: OriginInvalidResponse".

Motivo

A causa deste problema pode ser uma de três coisas:

  • O pool de back-end é um endereço IP.
  • O servidor back-end retorna um certificado que não corresponde ao FQDN (nome de domínio totalmente qualificado) do pool de back-end da Porta da Frente do Azure.
  • O pool de back-end é um servidor do Azure Web Apps.

Passos de resolução de problemas

  • O pool de back-end é um endereço IP.

    EnforceCertificateNameCheck deve ser desativado.

    O Azure Front Door tem um switch chamado EnforceCertificateNameCheck. Por predefinição, esta definição está ativada. Quando habilitado, o Azure Front Door verifica se o FQDN do nome do host do pool de back-end corresponde ao nome do certificado do servidor de back-end ou a uma das entradas na extensão de nomes alternativos de entidade.

    • Como desativar EnforceCertificateNameCheck a partir do portal do Azure:

      No portal, use um botão de alternância para ativar ou desativar essa configuração no painel Design da Porta da Frente do Azure (clássico).

      Captura de tela que mostra o botão de alternância.

      Para a camada Standard e Premium do Azure Front Door, essa configuração pode ser encontrada nas configurações de origem quando você adiciona uma origem a um grupo de origem ou configura uma rota.

      Captura de ecrã da caixa de verificação de validação do nome da entidade do certificado.

  • O servidor back-end retorna um certificado que não corresponde ao FQDN do pool de back-end da Porta da Frente do Azure. Para resolver esse problema, você tem duas opções:

    • O certificado retornado deve corresponder ao FQDN.
    • EnforceCertificateNameCheck deve ser desativado.

  • O pool de back-end é um servidor de Aplicativos Web do Azure:

    • Verifique se o aplicativo Web do Azure está configurado com SSL baseado em IP em vez de ser baseado em SNI (indicação de nome do servidor). Se o aplicativo Web estiver configurado como baseado em IP, ele deverá ser alterado para SNI.
    • Se o back-end não estiver íntegro devido a uma falha de certificado, uma mensagem de erro 503 será retornada. Você pode verificar a integridade dos back-ends nas portas 80 e 443. Se apenas 443 não estiver saudável, é provável que seja um problema com o SSL. Como o back-end está configurado para usar o FQDN, sabemos que ele está enviando SNI.

    Use OPENSSL para verificar o certificado que está sendo retornado. Para fazer essa verificação, conecte-se ao back-end usando -servername. Ele deve retornar o SNI, que precisa corresponder ao FQDN do pool de back-end:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

As solicitações enviadas para o domínio personalizado retornam um código de status 400

Sintoma

  • Você criou uma instância do Azure Front Door. Uma solicitação para o domínio ou host frontend retorna um código de status HTTP 400.
  • Você criou um mapeamento DNS (servidor de nomes de domínio) para um domínio personalizado para o host frontend que você configurou. O envio de uma solicitação para o nome de host de domínio personalizado retorna um código de status HTTP 400. Ele não parece rotear para o back-end que você configurou.

Motivo

O problema ocorre se você não configurou uma regra de roteamento para o domínio personalizado que foi adicionado como host frontend. Uma regra de roteamento precisa ser explicitamente adicionada para esse host frontend. Você precisa criar a regra mesmo que uma regra de roteamento já tenha sido configurada para o host front-end no subdomínio Azure Front Door, que é *.azurefd.net.

Etapa de solução de problemas

Adicione uma regra de roteamento para o domínio personalizado para direcionar o tráfego para o grupo de origem selecionado.

O Azure Front Door não redireciona HTTP para HTTPS

Sintoma

O Azure Front Door tem uma regra de roteamento que redireciona HTTP para HTTPS, mas o acesso ao domínio ainda mantém HTTP como protocolo.

Motivo

Esse comportamento pode acontecer se você não configurou as regras de roteamento corretamente para o Azure Front Door. Sua configuração atual não é específica e pode ter regras conflitantes.

Passos de resolução de problemas

A solicitação para o nome do host frontend retorna um código de status 411

Sintoma

Você criou uma instância do Azure Front Door Standard/Premium e configurou:

  • Um host frontend.
  • Um grupo de origem com pelo menos uma origem.
  • Uma regra de roteamento que conecta o host frontend ao grupo de origem.

Seu conteúdo não parece estar disponível quando uma solicitação vai para o host frontend configurado porque um código de status HTTP 411 é retornado.

As respostas a essas solicitações também podem conter uma página de erro HTML no corpo da resposta que inclui uma declaração explicativa. Um exemplo é "HTTP Error 411. A solicitação deve ser fragmentada ou ter um comprimento de conteúdo."

Motivo

Existem várias causas possíveis para este sintoma. O motivo geral é que sua solicitação HTTP não é totalmente compatível com RFC.

Um exemplo de não conformidade é uma POST solicitação enviada sem um cabeçalho Content-Length ou Transfer-Encoding . Um exemplo seria a utilização do curl -X POST https://example-front-door.domain.com. Esta solicitação não atende aos requisitos estabelecidos no RFC 7230. O Azure Front Door bloquearia com uma resposta HTTP 411. Essas solicitações não são registradas.

Esse comportamento é separado da funcionalidade de firewall de aplicativo Web (WAF) do Azure Front Door. Atualmente, não há como desabilitar esse comportamento. Todas as solicitações HTTP devem atender aos requisitos, mesmo que a funcionalidade WAF não esteja em uso.

Passos de resolução de problemas

  • Verifique se suas solicitações estão em conformidade com os requisitos estabelecidos nas RFCs necessárias.
  • Anote qualquer corpo de mensagem HTML que seja retornado em resposta à sua solicitação. O corpo da mensagem geralmente explica exatamente como sua solicitação não está em conformidade.

A minha origem está configurada como um endereço IP.

Sintoma

A origem é configurada como um endereço IP. A origem é íntegra, mas rejeitando solicitações do Azure Front Door.

Motivo

O Azure Front Door usa o nome do host de origem como o cabeçalho SNI durante o handshake SSL. Como a origem é configurada como um endereço IP, a falha pode ser um dos seguintes motivos:

  • Se a verificação do nome do certificado estiver desativada, é possível que a causa do problema esteja na lógica do certificado de origem. Essa lógica pode estar rejeitando quaisquer solicitações que não tenham um cabeçalho de host válido correspondente ao certificado.

Passos de resolução de problemas

Altere a origem de um endereço IP para um FQDN para o qual é emitido um certificado válido que corresponde ao certificado de origem.

Próximos passos