LEARN. PRACTICE. GROW.Concept and mechanism
A load balancer selects targets using available information and configured rules. With TCP forwarding and TLS terminated only at the backend, HTTP content remains protected. Path-based selection requires an authorized component with HTTP visibility. NGINX ssl_preread can observe supported ClientHello metadata, such as SNI when available, without terminating TLS; this does not reveal HTTP path or body. Architecture must identify where each connection ends and where decisions occur. Multiple targets do not remove a single entry point as a dependency. If the only load-balancer host fails, backends can remain healthy yet unreachable through the intended path.
Guided application
Also validate each implementation semantics. AWS ALB documents TLS to HTTPS targets without verifying those target certificates; do not turn encryption into universal proof of verified identity. Other proxies have their own trust and name options. In HTTP, an IP and port can serve several virtual hosts, so a check with a different Host can validate a default page while missing its objective. In an exercise, the portal is unavailable on one backend but a generic check remains green. Compare name, path, status, and representative content before concluding health. Topology and the business contract should guide tests, including internal hops and entry points.
Several backends behind one load balancer still depend on that entry point.
Common pitfalls
Opaque TCP as path routing; SNI as HTTP body; TLS as universal verification; default virtual host as the application.
Related topics: Algorithms, affinity, and state · Health checks and readiness · Retries, limits, and client origin
Draw the path and identify information, protection, and dependencies at each hop.
Reference: NGINX transport-stream upstreams · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior