Introduction

A cutover to a new load balancer can fail even when DNS, certificates, and backend health look correct on paper. The real problem is often the origin firewall still trusting only the old frontend IPs, old proxy network, or old health check source ranges. As soon as traffic starts flowing through the new balancer, the origin begins rejecting requests that should now be legitimate.

Treat this as a trusted-source problem instead of a generic site outage. Start by checking which source IPs the origin is actually receiving from the new load balancer, because a successful load balancer deployment does not help if the backend firewall still enforces the pre-cutover trust model.

Symptoms

  • The site breaks immediately after moving traffic to a new load balancer
  • Health checks fail even though the backend service works directly
  • The origin returns connection refused, timeout, or forbidden responses only through the new balancer
  • Direct access to the origin still works, but traffic through the load balancer does not
  • Some requests succeed while others fail from different frontend nodes or regions
  • The issue started after load balancer replacement, proxy migration, or frontend cutover

Common Causes

  • The origin firewall still allowlists only the old load balancer IPs or subnet
  • Health check traffic comes from different source ranges that were never trusted
  • The new balancer uses a different proxy path, NAT address, or regional egress range
  • Temporary coexistence rules were removed for the old balancer before the new one was trusted
  • The backend team validated app health directly and missed frontend-to-origin firewall enforcement
  • A security device or host firewall still applies the pre-cutover trust policy

Step-by-Step Fix

  1. Confirm the exact failure path by comparing direct origin access with access through the new load balancer, because that quickly shows whether the outage is really between the balancer and the backend.
  2. Identify the source IPs, subnets, or health check ranges the origin now sees from the new load balancer, because the active trust requirement must match the real frontend identity and not the planned one.
  3. Compare those live source ranges with the origin firewall, host firewall, security group, or WAF allowlist, because many cutovers fail when only the old balancer addresses remain trusted.
  4. Check health check behavior separately from user traffic, because many platforms send probes from different addresses or services than normal proxied requests.
  5. Review whether any regional nodes, standby balancers, or autoscaled frontend instances use additional source ranges, because partial allowlisting can create intermittent outages that look like random load balancer instability.
  6. Update the real active trust rules on the origin only after confirming every required frontend source range, because a partial firewall change often fixes one path while leaving another path blocked.
  7. Retest both health checks and live requests through the new load balancer and verify the origin logs now show accepted traffic from the intended sources, because green DNS alone does not prove the backend trust model is correct.
  8. Remove the old load balancer trust entries only after the new path is stable, because deleting legacy allowlists too early can complicate rollback and hide whether both frontends were still in use during cutover.
  9. Document the final load balancer source ranges, health check requirements, and origin firewall ownership, because trusted-source dependencies are easy to miss during future frontend migrations.