Introduction

An egress migration can move the new forward proxy or secure web gateway into service while outbound traffic still leaves through the old internet path. SaaS allowlists fail, audit logs appear on the wrong platform, or one office shows the new public IP while another still exits through the retired egress because upstream proxy chains, NAT rules, or routing policy did not fully move during the change.

Treat this as an outbound-path problem instead of a generic proxy outage. Start by checking which public egress IP and upstream path the affected traffic actually uses, because migrations often validate inbound connectivity and the new proxy itself while real client traffic still follows the previous outbound route.

Symptoms

  • Outbound traffic still exits through the old public IP after migration
  • SaaS providers continue seeing the retired egress address on allowlists or audit logs
  • One office or subnet uses the new egress while another still uses the previous path
  • Proxy logs look healthy, but downstream services still identify requests as coming from the old environment
  • The issue starts after moving forward proxy, NAT gateways, or internet breakout infrastructure
  • Security or compliance reporting remains split between old and new platforms

Common Causes

  • The forward proxy still chains to the old upstream proxy or egress gateway
  • NAT, policy-based routing, or firewall egress rules still direct traffic to the previous internet path
  • One proxy node or site was updated while another still uses the retired upstream
  • DNS, load balancing, or explicit proxy configuration sends only part of the traffic to the new path
  • The new proxy accepts traffic, but its outbound interface or route table still prefers the old egress
  • Validation checked client-to-proxy connectivity but did not verify the final public source IP seen by external services

Step-by-Step Fix

  1. Capture one affected outbound request and record the proxy node, upstream path, and public source IP it actually uses, because the live egress path matters more than the migration design on paper.
  2. Compare that active source IP and route with the intended post-migration egress target, because one stale upstream or NAT policy can keep all outbound traffic pinned to the retired path.
  3. Review proxy chaining settings, NAT rules, route tables, firewall policy, and site-specific egress configuration for references to the old environment, because outbound routing often spans several network layers.
  4. Check each site, proxy cluster member, or policy group separately if results differ, because migrations frequently fix one egress segment while another still uses the previous route.
  5. Update the authoritative upstream and egress policy so traffic from affected clients leaves through the intended path, because replacing the proxy node alone does not change downstream routing decisions.
  6. Send a controlled request to an external service that reports source IP and confirm it shows the intended egress, because successful internet access alone does not prove the right outbound path is in use.
  7. Verify the old egress no longer handles traffic from migrated clients, because mixed outbound routing can stay hidden until allowlists or compliance checks fail.
  8. Review SSL inspection, authentication, and bypass policies if some traffic still follows the old path, because selective rules can override the primary egress change.
  9. Document which team owns proxy chaining, NAT policy, and migration validation so future egress cutovers verify the real public source path before retiring the previous environment.