Gerenciando Deploys com rollback eficiente usando nginx

Quando trabalhamos com deploys, uma das maiores dores é garantir que, se algo der errado, o rollback seja rápido e sem impacto na operação. No cenário de proxy reverso com nginx, especialmente ao passar requests para portas não padrão, configurar corretamente o cabeçalho X-Forwarded-Port pode fazer toda a diferença.

Na prática, muitas equipes acabam enfrentando dificuldades ao tentar manter a configuração do nginx alinhada com o ambiente de produção, especialmente quando usam portas customizadas. Isso pode gerar problemas na hora de identificar o ponto de falha ou até mesmo afetar a experiência do usuário final. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.

Uma estratégia que ajudou bastante no meu time foi automatizar a validação do cabeçalho X-Forwarded-Port durante o deploy. Assim, a gente consegue identificar rapidamente se o nginx está enviando a porta correta, facilitando o rollback ou ajuste imediato. Além disso, sempre mantenho uma configuração de deploy com etapas claras de testes e monitoramento. A ideia é não deixar nada passar e evitar aquela sensação de 'e se der ruim?'. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.

No seu cenário, o ideal é garantir que o nginx esteja passando o cabeçalho de porta corretamente, mesmo em portas não padrão. Isso evita confusão na hora de depurar problemas ou fazer rollback, pois você consegue saber exatamente qual porta a request entrou. Como vocês costumam fazer esse controle na prática? Já passaram por situações em que um detalhe como esse complicou o rollback? O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.