A reverse proxy accepts client connections and forwards requests to upstream services, often adding TLS termination, headers, caching, or policy. A load balancer distributes traffic among eligible targets and removes unhealthy ones. Products can perform both roles, so design from required behavior rather than labels.
Who this is for: Web developers and operators deploying multiple application instances behind a managed or self-hosted traffic layer.
- Select a traffic layer from protocol, routing, health, security, and availability requirements.
- Make health checks prove readiness without depending on every optional downstream service.
- Preserve trusted client and request context while preventing forged forwarding headers.
Separate the concepts from products
A reverse proxy stands between clients and origin servers. It can terminate HTTPS, choose an upstream from a path or host, normalize requests, and hide internal addresses. Load balancing is the act of distributing connections or requests across multiple targets. Managed cloud load balancers, ingress controllers, web servers, and gateways may combine these functions in different layers.
Layer 4 balancing uses connection information such as addresses and ports, while Layer 7 balancing understands application protocols such as HTTP. Application awareness enables host, path, header, and cookie rules but adds protocol behavior to review. Match the layer to requirements for WebSockets, long requests, gRPC, TLS passthrough, source addresses, and connection persistence.
Design target selection and health
Targets should register through automation and become eligible only after startup completes. Health checks need a stable path, realistic timeout, interval, and healthy or unhealthy threshold. A process responding on a port may still be unable to serve requests, while a check that calls every dependency can remove all targets during one optional dependency failure.
Distinguish liveness, readiness, and deep diagnostics. Readiness should answer whether this target can accept normal traffic now. During deployments, use connection draining or deregistration delay so active requests can finish before a target stops. Monitor healthy-target count by zone and alarm before redundancy disappears completely.
Handle identity and encryption
Decide where TLS terminates and whether upstream connections also need encryption. Keep certificates in managed, access-controlled storage and automate renewal. If the proxy sends client address, scheme, host, or request identifiers in headers, the application should trust those values only from known proxy hops and replace untrusted client-supplied versions.
Set request-size, header-size, idle-timeout, and connection limits deliberately. Defaults may not fit uploads or streaming. Rate limiting and web application firewall rules can protect origins, but test legitimate traffic and define an exception process. Do not log credentials, session values, or sensitive request bodies in proxy access logs.
Operate the request path
Track request rate, response codes, target latency, proxy latency, rejected connections, healthy targets, and bytes transferred. Use a request identifier across the proxy and application so one slow or failed request can be traced. Compare edge status codes with target status codes to learn whether failure occurred before or after forwarding.
Change routing rules through review and staged deployment. Test exact host and path precedence because broad patterns can shadow narrow rules. For a migration, send a small controlled share to the new target, compare behavior, and retain a quick route rollback. Avoid reloading a shared production proxy manually when the managed deployment path is available.
Route an API release safely
An API runs on four instances and needs HTTPS termination plus a staged move from version one to version two.
- Create separate target groups with readiness checks that verify each version can serve a harmless application request.
- Terminate HTTPS at the managed load balancer, encrypt upstream traffic if required, and configure trusted forwarding-header handling.
- Send internal test traffic to version two through an explicit route, then shift a small percentage of normal requests with monitored stop conditions.
- Compare errors, latency, and business outcomes before increasing traffic, while keeping the version-one target group ready for route rollback.
Traffic-layer configuration review
Review these fields for every listener and route before release.
- Listener protocol, port, certificate, TLS policy, client authentication, and renewal owner.
- Host or path match, precedence, target group, algorithm, persistence, and timeout behavior.
- Health path, expected response, thresholds, draining period, and minimum healthy capacity.
- Trusted proxy hops, forwarded headers, request identifiers, sensitive-log exclusions, and access policy.
- Dashboards, alarms, staged rollout, stop conditions, rollback route, and validation evidence.
Common mistakes
- Using a shallow port check that sends traffic to an application still loading required state.
- Trusting client-provided forwarding headers and recording forged addresses or schemes.
- Changing path-rule order without testing which broad rule wins for existing requests.
Try one
A load balancer reports every target unhealthy after an optional recommendation service fails. What likely went wrong, and how should the check be redesigned?
The readiness endpoint probably made an optional dependency part of basic traffic eligibility, causing a total outage from a degradable failure. A strong answer narrows readiness to requirements for serving the core request, exposes optional dependency health separately, verifies degraded behavior, and tests thresholds before production. It does not disable all health checking.
Sources
- Elastic Load Balancing documentationOfficial AWS overview of load balancer types, targets, listeners, and health checks.
- Kubernetes Services documentationOfficial Kubernetes explanation of stable network endpoints and Service discovery for Pods.