Introduction

A proxy migration can move the new forward proxy into production while clients still fetch a PAC file that sends traffic to the old server. Browsing works only on some networks, SaaS access follows the wrong egress path, or users keep seeing certificate and authentication prompts from the retired proxy because auto-config settings often outlive the proxy cutover itself.

Treat this as a client-routing problem instead of a generic internet access outage. Start by checking which PAC file and proxy host the affected client actually uses, because migrations often update the proxy cluster first while browsers, WPAD, or device policy keep distributing the previous auto-config path.

Symptoms

  • Browsers or clients still use the old proxy after migration
  • Web access works on one network or device group but not another
  • Users see prompts, certificates, or filtering behavior from the retired proxy
  • Direct access and manually configured clients work, but auto-configured clients do not
  • The new proxy is healthy, but traffic logs still appear on the old platform
  • The issue started after moving secure web gateway, proxy clusters, or egress filtering infrastructure

Common Causes

  • The PAC file still returns the old proxy hostname, port, or failover order
  • WPAD DNS or DHCP settings still direct clients to the previous auto-config endpoint
  • Browser or device policy still publishes the old PAC URL
  • PAC file content was updated on one host, but caches or CDN layers still serve the older version
  • An HTTPS inspection or authentication rule makes clients fall back to the retired proxy entry
  • Validation confirmed the new proxy accepted traffic but did not inspect what PAC or WPAD path real clients were using

Step-by-Step Fix

  1. Capture proxy settings from an affected client and record the exact PAC URL, WPAD source, and proxy host returned for a test destination, because the live auto-config path determines what server the client actually uses.
  2. Compare that active proxy result with the intended post-migration proxy target, because one stale PAC response can keep an entire device population tied to the retired gateway.
  3. Review PAC file contents, WPAD DNS or DHCP settings, browser policies, and device-management profiles for references to the old proxy, because auto-config often spans multiple delivery layers.
  4. Check whether the PAC file is cached by browsers, operating systems, CDNs, or transparent proxies, because publishing a new file does not guarantee clients fetch it immediately.
  5. Update the authoritative PAC and WPAD configuration so clients receive the correct proxy host, because replacing the proxy infrastructure alone does not retarget existing auto-config logic.
  6. Force a controlled client refresh and confirm traffic for a known destination uses the intended proxy, because successful browsing alone does not prove the new egress path is active.
  7. Verify the old proxy no longer receives connections from migrated clients, because split proxy usage can remain hidden while both environments are still available.
  8. Review authentication, SSL inspection, and explicit bypass rules if traffic still behaves inconsistently, because the destination can be correct while policy differences still send some requests elsewhere.
  9. Document which team owns PAC publication, WPAD, and browser policy so future proxy migrations validate the real client auto-config path before retiring the previous service.