APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um balanceador seleciona destinos segundo informação disponível e regras configuradas. Em encaminhamento TCP com TLS terminado apenas no backend, o conteúdo HTTP permanece protegido. Escolher pelo caminho exige um componente autorizado com visibilidade HTTP. NGINX ssl_preread pode observar metadados suportados do ClientHello, como SNI quando disponível, sem terminar TLS; isso não revela o caminho ou corpo HTTP. A arquitetura deve indicar onde termina cada ligação e onde são tomadas decisões. Ter vários destinos não elimina um único ponto de entrada como dependência. Se o único host do balanceador falhar, os backends podem continuar saudáveis mas inacessíveis pelo percurso previsto.
Aplicação guiada
Valida também a semântica de cada implementação. AWS ALB documenta TLS para targets HTTPS sem validar os certificados desses targets; não transformes encriptação numa prova universal de identidade verificada. Outros proxies têm opções próprias de confiança e nome. Em HTTP, IP e porta podem servir vários virtual hosts, pelo que um check com Host diferente pode validar uma página predefinida e falhar o objetivo. Num exercício, o portal está indisponível num backend mas o check genérico continua verde. Compara nome, caminho, estado e conteúdo representativo antes de concluir saúde. A topologia e o contrato funcional devem orientar os testes, incluindo saltos internos e pontos de entrada.
Vários backends atrás de um único balanceador continuam dependentes desse ponto de entrada.
Armadilhas comuns
TCP opaco como routing por caminho; SNI como corpo HTTP; TLS como validação universal; virtual host predefinido como aplicação.
Tópicos relacionados: Algoritmos, afinidade e estado · Health checks e prontidão · Retries, limites e origem do cliente
Desenha o percurso e identifica informação, proteção e dependências em cada salto.
Referência: NGINX transport-stream upstreams · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior