Laboratório de Troubleshooting: Implement rules, URL rewrite, and URL redirect
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe reporta que o Azure Application Gateway está ignorando uma rewrite rule recém-criada. O gateway está em produção há seis meses sem incidentes. A regra foi criada para remover o cabeçalho X-Forwarded-Host das respostas do backend antes de entregá-las aos clientes. O engenheiro responsável confirma que a regra está corretamente definida com a condição e a ação de remoção de cabeçalho. O SKU utilizado é o Standard V2. O gateway possui três regras de roteamento: duas do tipo Basic e uma do tipo Path-based.
Após investigação inicial, o engenheiro coleta as seguintes informações:
Rewrite Rule Set: rrs-remove-header
Rule: remove-x-forwarded-host
Condition: (none)
Action: Response Header - Delete - X-Forwarded-Host
Routing Rules associadas à rrs-remove-header:
(nenhuma associação encontrada)
Backend Health: Healthy
WAF Policy: Disabled
Usuários que acessam via HTTPS relatam o mesmo comportamento. O certificado SSL foi renovado na semana anterior sem problemas.
Qual é a causa raiz do problema?
A) A rewrite rule foi configurada para agir sobre respostas, mas o Application Gateway só suporta reescrita em requisições de entrada
B) A rewrite rule set não está associada a nenhuma regra de roteamento, portanto nunca é acionada
C) O SKU Standard V2 não suporta remoção de cabeçalhos de resposta, apenas de requisição
D) A ausência de condição na regra impede sua execução, pois o Application Gateway exige ao menos uma condição para aplicar a ação
Cenário 2 — Decisão de Ação
A causa de um incidente foi identificada: uma regra de redirecionamento no Azure Application Gateway está configurada com o tipo Temporary (302) quando deveria ser Permanent (301). O redirecionamento aponta de http://loja.contoso.com para https://loja.contoso.com. O time de SEO reporta que o Google está reindexando as páginas de forma inconsistente, pois alguns crawlers retornam ao endpoint HTTP antes de serem redirecionados. O gateway atende a 4,5 milhões de requisições por dia e está em produção ativa.
A alteração do tipo de redirecionamento de 302 para 301 no portal do Azure exige que a regra de roteamento seja salva novamente, o que causa uma reinicialização das instâncias do gateway, estimada em 2 a 4 minutos de indisponibilidade parcial.
O próximo período de manutenção aprovado é em 72 horas. O gerente de produto solicita uma correção imediata por pressão da equipe de SEO.
Qual é a ação correta a tomar neste momento?
A) Aplicar a alteração imediatamente, pois a diferença entre 301 e 302 é apenas semântica e o impacto real de 2 a 4 minutos é aceitável em qualquer momento
B) Aguardar o período de manutenção aprovado em 72 horas para aplicar a alteração sem risco de impacto não autorizado
C) Criar uma nova regra de redirecionamento com tipo 301 e desativar a regra atual, evitando a reinicialização
D) Escalar para o time de infraestrutura a solicitação de um segundo gateway em paralelo para aplicar a mudança sem downtime
Cenário 3 — Causa Raiz
Uma empresa configurou o Azure Front Door para reescrever URLs antes de encaminhar ao backend. A configuração foi aplicada conforme abaixo:
Route: rt-api
Origin Group: og-api-backend
Patterns to match: /api/*
URL Rewrite:
Source pattern: /api/
Destination: /v2/
Preserve unmatched path: false
Desenvolvedores reportam que chamadas para /api/orders/pending estão retornando HTTP 404 do backend. O time de backend confirma que o endpoint correto é /v2/orders/pending e que o serviço está saudável. Logs do origin group mostram que as requisições estão chegando ao backend.
Informações adicionais coletadas:
Front Door Health Probe: Healthy
WAF Policy: Detection mode (sem bloqueios registrados)
Protocolo do origin: HTTPS
Certificado do backend: Válido, renovado há 10 dias
Qual é a causa raiz do comportamento observado?
A) O WAF em modo Detection está bloqueando silenciosamente as requisições com o novo caminho
B) Com Preserve unmatched path definido como false, o segmento /orders/pending é descartado e o backend recebe apenas /v2/, causando o 404
C) O protocolo HTTPS no origin exige que a reescrita de URL seja desabilitada para funcionar corretamente
D) O padrão /api/* no campo "Patterns to match" entra em conflito com o source pattern /api/, fazendo a reescrita ser ignorada
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: usuários que acessam http://app.contoso.com/dashboard estão sendo redirecionados para https://app.contoso.com sem o caminho /dashboard. O Azure Application Gateway foi recentemente reconfigurado para forçar HTTPS.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se a opção Include path está habilitada na regra de redirecionamento
- Confirmar que o listener HTTP está ativo e recebendo requisições na porta 80
- Identificar qual regra de roteamento está associada ao listener HTTP
- Verificar se o certificado HTTPS do listener de destino é válido e está ativo
- Inspecionar a configuração da regra de redirecionamento associada ao listener HTTP
Qual é a sequência correta de investigação para diagnosticar a causa raiz?
A) 4 → 2 → 3 → 5 → 1
B) 2 → 3 → 5 → 1 → 4
C) 1 → 5 → 3 → 2 → 4
D) 3 → 2 → 1 → 4 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está nos dados coletados pelo próprio enunciado: Routing Rules associadas à rrs-remove-header: (nenhuma associação encontrada). Uma rewrite rule set no Application Gateway nunca é aplicada automaticamente a todo o tráfego. Ela precisa ser explicitamente vinculada a uma ou mais regras de roteamento. Sem essa associação, a rule set existe na configuração mas nunca é invocada durante o processamento das requisições.
A informação sobre renovação do certificado SSL é irrelevante e foi inserida para simular a pressão de investigar o evento mais recente, que é um erro de diagnóstico clássico.
- A alternativa A é falsa: o Application Gateway suporta reescrita tanto de cabeçalhos de requisição quanto de resposta.
- A alternativa C é falsa: o SKU Standard V2 suporta ambos os tipos de reescrita.
- A alternativa D é falsa: condições são opcionais em rewrite rules; a ausência de condição significa que a ação é aplicada a todas as requisições que passam pela rule set.
O distrator mais perigoso é A, pois um diagnóstico incorreto levaria o engenheiro a concluir que o recurso não existe, quando na verdade a regra simplesmente não está conectada ao fluxo de processamento.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é que a alteração exige uma reinicialização das instâncias do gateway, causando indisponibilidade parcial em um serviço de alta demanda. Essa ação não está aprovada para o momento atual. O processo de gestão de mudanças existe exatamente para proteger ambientes de produção de impactos não autorizados, independentemente da pressão externa.
- A alternativa A ignora a restrição de processo e subestima o impacto: 2 a 4 minutos de indisponibilidade parcial em 4,5 milhões de requisições diárias representa um risco operacional real e não autorizado.
- A alternativa C parece atraente, mas é tecnicamente incorreta: não é possível ter duas regras de redirecionamento ativas para o mesmo listener ao mesmo tempo sem conflito, e desativar a regra atual durante a criação da nova geraria uma janela sem redirecionamento.
- A alternativa D é desproporcional ao problema e não resolveria a necessidade dentro do prazo.
O princípio fundamental aqui é que a correção correta aplicada no momento errado pode ser pior do que o problema original. A janela de 72 horas é a ação segura e aprovada.
Gabarito — Cenário 3
Resposta: B
Com Preserve unmatched path definido como false, o Azure Front Door substitui completamente o caminho correspondido pelo destino configurado, descartando qualquer segmento adicional da URL. No caso da requisição /api/orders/pending, o segmento correspondido é /api/ e o restante (orders/pending) é a parte não correspondida. Com a opção desabilitada, esse segmento é descartado. O backend recebe apenas /v2/, que não é um endpoint válido, resultando em HTTP 404.
As informações sobre o certificado renovado e o WAF em modo Detection são irrelevantes e foram incluídas para induzir o leitor a investigar eventos recentes em vez de focar na configuração da reescrita.
- A alternativa A é incorreta: WAF em modo Detection registra mas não bloqueia; além disso, os logs confirmam que as requisições chegam ao backend.
- A alternativa C é tecnicamente infundada: o protocolo do origin não afeta o comportamento da reescrita de URL.
- A alternativa D confunde dois campos distintos com finalidades diferentes; "Patterns to match" define quando a rota é ativada, enquanto "Source pattern" define o que é reescrito dentro dessa rota. Eles coexistem sem conflito.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 2 → 3 → 5 → 1 → 4.
O raciocínio diagnóstico deve seguir o fluxo da requisição, do ponto de entrada até o ponto de falha:
- Passo 2: confirmar que o listener HTTP está ativo e recebendo tráfego na porta 80. Se o listener não estiver operacional, todos os passos seguintes são irrelevantes.
- Passo 3: identificar qual regra de roteamento está associada a esse listener. Sem saber qual regra está ativa, não é possível saber qual configuração de redirecionamento está sendo aplicada.
- Passo 5: inspecionar a configuração da regra de redirecionamento associada. É aqui que se verifica o tipo, o destino e as opções da regra.
- Passo 1: verificar a opção Include path. Este é o passo que responde diretamente ao sintoma relatado (perda do caminho
/dashboard). - Passo 4: verificar o certificado HTTPS. Embora relevante para a saúde geral do gateway, a validade do certificado não afeta a preservação do caminho no redirecionamento e é o passo de menor prioridade neste diagnóstico específico.
- A alternativa A começa pelo certificado, que é o detalhe menos relevante para o sintoma descrito.
- A alternativa C começa pelo passo 1 sem antes confirmar qual regra está ativa, o que seria diagnosticar a solução antes de confirmar o contexto.
- A alternativa D altera a ordem de identificação da regra antes de confirmar que o listener está funcional, pulando a base do fluxo.
Árvore de Troubleshooting: Implement rules, URL rewrite, and URL redirect
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Ponto de verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o comportamento inesperado está na camada de redirecionamento ou de reescrita. Siga as perguntas fechadas respondendo sim ou não com base no que você observa diretamente na configuração ou nos logs do gateway. Cada caminho vermelho indica uma causa concreta que pode ser corrigida; o nó verde de validação sinaliza que a configuração está estruturalmente correta e o problema exige investigação mais profunda via logs e testes de requisição.