Laboratório de Troubleshooting: Configure an Azure Front Door, including routing, origins, and endpoints
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação global é servida pelo Azure Front Door Standard. O endpoint está configurado com um domínio personalizado validado e uma rota /* apontando para um grupo de origens com duas instâncias de Azure App Service, uma na região East US e outra na West Europe. A session affinity está desativada.
Nos últimos dois dias, o time de suporte recebe relatos esporádicos de usuários na Europa que, ao autenticarem na aplicação, são redirecionados para a tela de login novamente após alguns cliques. Usuários nos Estados Unidos não relatam o problema. O time verifica que ambas as origens estão marcadas como Healthy nas sondas de integridade. Os logs do App Service mostram sessões sendo criadas e destruídas repetidamente para os mesmos usuários europeus.
Informações adicionais coletadas pelo time:
- O certificado TLS do domínio personalizado foi renovado há três semanas sem incidentes
- A latência média das sondas para West Europe é de 12ms, dentro do esperado
- O estado de autenticação da aplicação é armazenado em memória no processo do App Service, sem cache distribuído
- O SKU do Front Door foi migrado de Classic para Standard há 45 dias
Qual é a causa raiz do comportamento observado?
A) O certificado TLS renovado não foi propagado corretamente para a origem West Europe, causando renegociação de sessão TLS intermitente.
B) O roteamento por latência do Front Door direciona requisições do mesmo usuário europeu para origens diferentes entre requests, e o estado de sessão não é compartilhado entre elas.
C) A migração do SKU Classic para Standard alterou o comportamento das sondas de integridade, que agora validam o conteúdo da resposta e estão causando failover silencioso.
D) O domínio personalizado perdeu o vínculo com o endpoint durante a renovação do certificado, e o Front Door está roteando alguns requests diretamente para a origem sem processar cookies de sessão.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que uma Rule Set configurada no Azure Front Door está bloqueando requisições legítimas de uma parceira de negócios. A regra em questão avalia o cabeçalho User-Agent e rejeita valores associados a crawlers, mas o sistema automatizado da parceira usa um User-Agent que corresponde ao padrão bloqueado.
A causa está confirmada: a condição da regra é ampla demais e captura tráfego legítimo. A parceira precisa que o acesso seja restaurado em no máximo 30 minutos. O ambiente é de produção. A Rule Set afeta todas as rotas do perfil. Não há ambiente de staging disponível para teste prévio.
Nenhuma outra regra no Rule Set depende da regra problemática. O time tem acesso completo ao perfil do Front Door no portal Azure.
Qual é a ação correta a tomar neste momento?
A) Excluir a Rule Set completa do perfil para remover imediatamente o bloqueio, e recriar as demais regras após restaurar o acesso da parceira.
B) Editar a condição da regra problemática para adicionar uma exceção baseada em um cabeçalho ou IP específico da parceira, salvar e validar o comportamento.
C) Desassociar a Rule Set de todas as rotas do perfil, restaurar o acesso e reagendar a correção da regra para uma janela de manutenção planejada.
D) Criar uma nova rota dedicada para o IP da parceira com prioridade maior, sem Rule Set associada, e manter a rota original inalterada.
Cenário 3 — Causa Raiz
Um engenheiro configura um novo perfil Azure Front Door Premium para uma API interna. A origem é um Azure API Management (APIM) implantado em modo interno (internal VNet). O engenheiro habilita Private Link na configuração da origem dentro do grupo de origens e aguarda a aprovação da conexão.
Após aprovação e deploy completo, testes externos via https://api-global.contoso.com retornam HTTP 200 corretamente. Porém, as sondas de integridade no painel do Front Door mostram a origem como Unhealthy de forma persistente, mesmo com a API respondendo normalmente.
Logs coletados durante a investigação:
[Front Door Health Probe] GET /health
Host: api-global.contoso.com
Response: Connection refused (TCP)
Probe interval: 30s
Probe protocol: HTTPS
Probe path: /health
O engenheiro verifica que:
- O endpoint
/healthexiste no APIM e retorna HTTP 200 quando chamado manualmente via curl de dentro da VNet - O Private Endpoint foi aprovado e está com status Succeeded
- O certificado TLS do APIM é emitido por uma CA interna corporativa
- O registro DNS público de
api-global.contoso.comaponta corretamente para o endpoint do Front Door
Qual é a causa raiz do status Unhealthy nas sondas?
A) O path /health não está exposto publicamente no APIM; como as sondas partem de IPs do Front Door e não atravessam o Private Link, elas tentam conexão direta e são bloqueadas.
B) O certificado TLS emitido por uma CA interna não é confiável pelo Front Door, que rejeita a conexão TLS durante a sonda e registra o erro como recusa de conexão TCP.
C) As sondas de integridade do Azure Front Door Premium não suportam origens acessadas via Private Link; elas sempre tentam conexão direta pelo IP público da origem.
D) O modo interno do APIM bloqueia qualquer conexão de entrada que não origine de dentro da VNet, e o Private Link aprovado não cobre o tráfego de sondas de saúde.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta em produção:
"Usuários reportam HTTP 404 em
https://loja.contoso.com/checkout. Todas as demais rotas da aplicação respondem normalmente."
O perfil Azure Front Door tem a seguinte estrutura:
Endpoint: loja.contoso.com
Rotas configuradas:
- Rota A: domínio=loja.contoso.com, path=/* → Origin Group: BackendGeral
- Rota B: domínio=loja.contoso.com, path=/checkout* → Origin Group: BackendCheckout
Os passos de investigação disponíveis são:
- Verificar se o Origin Group BackendCheckout tem ao menos uma origem Healthy
- Confirmar se a Rota B está habilitada e associada ao endpoint correto
- Testar
https://loja.contoso.com/checkoutdiretamente via curl com headerHostcorreto - Verificar nos logs do Front Door se as requisições para
/checkoutestão sendo roteadas para a Rota A ou para a Rota B - Acessar o backend do
BackendCheckoutdiretamente e confirmar que o path/checkoutexiste e retorna 200
Qual é a sequência correta de diagnóstico para esse sintoma?
A) 3 -> 1 -> 5 -> 2 -> 4
B) 4 -> 2 -> 1 -> 5 -> 3
C) 2 -> 4 -> 1 -> 5 -> 3
D) 1 -> 5 -> 2 -> 4 -> 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O sintoma central é a destruição repetida de sessão para usuários europeus com estado armazenado em memória no processo do App Service. Isso é o diagnóstico completo: sem cache distribuído e sem session affinity, o Front Door pode enviar requests consecutivos do mesmo usuário para origens diferentes. Como cada instância do App Service mantém seu próprio estado em memória, a sessão criada na primeira instância não existe na segunda, forçando nova autenticação.
A pista decisiva no enunciado é a combinação de dois fatos: estado em memória e session affinity desativada. Usuários americanos não reportam o problema possivelmente porque, por latência, tendem a ser roteados de forma mais consistente para a mesma origem, enquanto usuários europeus estão geograficamente mais próximos de West Europe mas podem oscilar entre as duas origens.
A informação sobre o certificado TLS renovado é propositalmente irrelevante; a renovação ocorreu há três semanas sem incidentes relatados. O distrator A tenta explorar esse detalhe.
O distrator C é tecnicamente incorreto: a migração de SKU altera configurações disponíveis, mas não muda o comportamento de failover silencioso de sondas de forma que destruiria sessões. O distrator D descreve um cenário de desvinculação de domínio que quebraria o acesso para todos os usuários, não apenas os europeus.
Agir com base no distrator A levaria o time a investigar TLS por horas sem encontrar o problema real, enquanto usuários continuam deslogando.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e confirmada: a condição da regra é ampla demais. A restrição crítica é o prazo de 30 minutos em produção. A ação correta é a cirurgia mínima: editar apenas a regra problemática para adicionar uma exceção precisa (por cabeçalho personalizado, IP de origem ou combinação de condições), salvar e validar. Isso resolve o problema sem afetar as demais regras e sem remover proteções existentes.
O distrator A é o mais perigoso: excluir a Rule Set completa remove todas as outras regras de segurança do perfil em produção. Mesmo que temporariamente, isso expõe a aplicação. A palavra "recriar" indica uma operação demorada e sujeita a erro.
O distrator C também é perigoso em menor grau: desassociar a Rule Set de todas as rotas remove todas as proteções, não apenas a regra problemática, e adia a correção para uma janela indefinida.
O distrator D é tecnicamente inválido nesse contexto: o Front Door não usa IP de origem do cliente como critério de seleção de rota; as rotas são baseadas em domínio e path, não em IP do requisitante.
Gabarito — Cenário 3
Resposta: A
O log é a chave diagnóstica: Connection refused (TCP). Isso indica que a sonda não consegue nem iniciar o handshake TCP com a origem, ou seja, o problema ocorre antes de qualquer validação TLS. Se o problema fosse o certificado (distrator B), o log mostraria erro de TLS ou handshake falho, não recusa TCP.
A causa real é a arquitetura do APIM em modo interno: ele não tem interface pública. As sondas de integridade do Azure Front Door são disparadas a partir de infraestrutura da Microsoft e, mesmo com Private Link configurado para o tráfego de dados, as sondas de saúde percorrem um caminho diferente. Nesse cenário, as sondas tentam alcançar a origem pelo hostname configurado, que não resolve para um IP público acessível, resultando em recusa TCP.
O distrator C é falso como afirmação absoluta: o Front Door Premium com Private Link suporta sondas via Private Link, mas requer configuração correta do hostname e do caminho de sonda compatível com o endpoint privado. O distrator D é parcialmente verdadeiro (APIM interno bloqueia conexões externas), mas a explicação técnica de "Private Link não cobre sondas" é imprecisa; o problema real é que as sondas ainda tentam conexão direta quando o hostname não está resolvendo para o endpoint privado correto.
A informação sobre o DNS público apontando para o Front Door é irrelevante para o diagnóstico das sondas: o DNS público serve o tráfego do cliente, não o tráfego de sonda.
Gabarito — Cenário 4
Resposta: C
A sequência correta é: confirmar se a Rota B está ativa (2), verificar nos logs para qual rota os requests estão sendo roteados (4), checar se o grupo de origens tem origem saudável (1), validar se o backend responde no path correto (5), e por fim confirmar via curl externo (3).
O raciocínio diagnóstico progressivo parte do componente de controle (roteamento) para o componente de dados (origem) e termina na validação externa. Começar pelo curl (alternativa A) ou pelo backend (alternativa D) sem antes confirmar se o roteamento está correto é investigar no lugar errado: o 404 pode vir do Front Door (rota inexistente ou desativada) ou da origem (path não existe), e essa distinção determina onde atuar.
A alternativa B começa pelos logs (4), o que seria razoável, mas pular direto para os logs antes de verificar se a rota está sequer habilitada (2) significa que você pode estar analisando logs de um componente que o sistema nem está usando corretamente. A sequência C garante que você valida a camada de configuração antes de interpretar comportamento observado.
O passo 3 (curl externo) é a validação final porque confirma o comportamento end-to-end após todas as hipóteses internas terem sido descartadas ou confirmadas.
Árvore de Troubleshooting: Configure an Azure Front Door, including routing, origins, and endpoints
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão baseada em observação) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o erro é visível ao cliente ou está restrito às sondas internas. Siga cada ramificação respondendo às perguntas com base no que você consegue observar diretamente: código HTTP retornado, logs do Front Door, comportamento da origem acessada diretamente, e estado das sondas de integridade. Cada nó vermelho indica onde concentrar a correção. Nós laranja indicam que você ainda precisa coletar mais dados antes de agir. Nunca pule etapas em direção a uma causa antes de responder à pergunta do nó anterior.