Solucionar problemas comuns do Azure Front Door

  • Artigo

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

Outros cabeçalhos HTTP de depuração

Você pode solicitar ao Azure Front Door para retornar cabeçalhos de resposta HTTP de depuração extras. Para saber mais, confira os cabeçalhos de resposta opcionais.

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

Sintoma

  • As solicitações regulares enviadas ao back-end sem passar pelo Azure Front Door têm sucesso. Passar pelo Azure Front Door resulta em respostas de erro 503 ou 504.
  • A falha do Azure Front Door normalmente é mostrada após cerca de 30 segundos.
  • São exibidos erros 503 intermitentes com "ErrorInfo: OriginInvalidResponse".

Causa

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

  • A origem está demorando mais do que o tempo limite configurado para receber a solicitação do Azure Front Door. O tempo limite padrão é 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.

Etapas para solucionar problemas

  • Envie a solicitação à sua origem diretamente, sem passar pelo Azure Front Door. Veja quanto tempo a origem normalmente leva para responder.

  • Envie a solicitação por meio do Azure Front Door e veja se você está recebendo qualquer resposta 503. Caso contrário, é possível que não seja um problema de tempo limite. Crie uma solicitação de suporte para solucionar o problema detalhadamente.

  • Se as solicitações que passam pelo Azure Front Door resultarem em um código de resposta de erro 503 e, em seguida, configure o Tempo limite de resposta de origem para o Azure Front Door. Você pode aumentar o tempo limite padrão para até 4 minutos (240 segundos). Para definir a configuração, vá até a página de visão geral do perfil do Front Door. Selecione Tempo limite da resposta de origem e insira um valor entre 16 e 240 segundos.

    Observação

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

    Screenshot of the origin timeout settings on the overview page of the Azure Front Door profile.

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

    Se o cliente está enviando solicitações de intervalo de bytes com cabeçalhos Accept-Encoding, você tem duas opções. A primeira opção é desabilitar a compactação na origem ou no Azure Front Door. A segunda opção é criar um conjunto de regras para remover o cabeçalho Accept-Encoding da solicitação das solicitações de intervalo de bytes.

    Screenshot that shows the Accept-Encoding rule in a rule set.

503 respostas da porta frontal do Azure somente para HTTPS

Sintoma

  • Todas as respostas 503 só são retornadas para pontos de extremidade habilitados para HTTPS do Azure Front Door.
  • As solicitações regulares enviadas ao back-end sem passar pelo Azure Front Door têm sucesso. Passar pelo Azure Front Door resulta em respostas de erro 503.
  • São exibidos erros 503 intermitentes com "ErrorInfo: OriginInvalidResponse".

Causa

A causa desse 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 do pool de back-end do Azure Front Door.
  • O pool de back-end é um servidor de Aplicativos Web do Azure.

Etapas para solucionar problemas

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

    EnforceCertificateNameCheck deve ser desabilitado.

    O Azure Front Door tem uma opção chamada EnforceCertificateNameCheck. Por padrão, essa configuração está habilitada. Quando ela está habilitada, 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 da entidade.

    • Como desabilitar EnforceCertificateNameCheck no portal do Azure:

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

      Screenshot that shows the toggle button.

      Para a camada Standard e Premium do Azure Front Door, encontre essa configuração nas configurações de origem ao adicionar uma origem a um grupo de origens ou configurar uma rota.

      Screenshot of the certificate subject name validation checkbox.

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

    • O certificado retornado precisa corresponder ao FQDN.
    • EnforceCertificateNameCheck deve ser desabilitado.

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

    • Verifique se o aplicativo Web do Azure está configurado com o SSL baseado em IP em vez de ser baseado em SNI. 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 do certificado, uma mensagem de erro 503 será retornada. Você pode verificar a integridade dos back-ends nas portas 80 e 443. Se apenas a porta 443 não estiver íntegra, isso provavelmente será um problema com o SSL. Como o back-end está configurado para usar o FQDN, sabemos que ele está enviando o SNI.

    Use o 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 o host de front-end retorna um código de status HTTP 400.
  • Você criou um mapeamento DNS de um domínio personalizado para o host de front-end configurado. O envio de uma solicitação para o nome do host do domínio personalizado retorna um código de status HTTP 400. Ele não parece rotear para o back-end que você configurou.

Causa

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

Etapa de solução de problemas

Adicione uma regra de roteamento ao domínio personalizado para direcionar o tráfego para o pool de back-end 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 o HTTP como o protocolo.

Causa

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

Etapas para solucionar problemas

A solicitação para um nome de host de front-end retorna um código de status 411

Sintoma

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

  • Um host de front-end.
  • Um grupo de origem com, pelo menos, uma origem.
  • Uma regra de roteamento que conecta o host de front-end ao grupo de origem.

O conteúdo não parece estar disponível ao enviar uma solicitação para o host de front-end configurado, porque o 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 instrução explicativa. Um exemplo disso é o "erro HTTP 411. A solicitação precisa estar em partes ou ter um comprimento de conteúdo."

Causa

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

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

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

Etapas para solucionar problemas

  • Verifique se as solicitações estão em conformidade com os requisitos definidos nos RFCs necessários.
  • Anote qualquer corpo de mensagem HTML retornado em resposta à solicitação. Um corpo de mensagem geralmente explica exatamente como a solicitação não está em conformidade.

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

Sintoma

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

Causa

O Azure Front Door utiliza o nome do host de origem como o cabeçalho SNI durante o handshake do SSL. Como a origem está configurada como um endereço IP, a falha pode ser causada por um dos motivos a seguir:

  • A verificação do nome do certificado está habilitada na configuração de origem do Front Door. Recomenda-se deixar essa configuração habilitada. A verificação do nome do certificado exige que o nome do host de origem corresponda ao nome do certificado ou a uma das entradas na extensão de nomes alternativos da entidade.
  • Se a verificação do nome do certificado estiver desabilitada, a causa provavelmente se deve à lógica do certificado de origem rejeitando quaisquer solicitações que não tenham um cabeçalho de host válido na solicitação que corresponda ao certificado.

Etapas para solucionar problemas

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

Próximas etapas