Why Your PAC File Picks the Wrong Network Adapter

The laptop is on office Wi-Fi, the Ethernet cable is attached, and a VPN adapter is still present. Your PAC file asks myIpAddress() which network it is on. That sounds reasonable until it gets an address belonging to the wrong adapter.

The missing detail is that the function returns one address. It is not an inventory of every interface, and it does not contact a website to discover your public IP. A private address, or even a loopback fallback, does not tell you which exit address a proxied request will use.

One answer for a machine with several addresses

Network-interface selection belongs to the PAC implementation. Old advice to reorder Windows adapters may describe a particular browser and operating-system version, but it is a poor universal fix. Chromium documents its own selection algorithm and multihomed limitations; another client need not make the same choice.

Start by identifying the value the affected browser actually supplied, then compare it with the subnet checks in your script. Do this separately on Wi-Fi, Ethernet, and the approved VPN connection. An address that looks surprising can still satisfy the implementation's rules.

Make the decision depend on less guesswork

Where practical, select a proxy from the destination hostname rather than from an assumed client interface. If network detection is necessary, use a deliberate, documented signal that your organization controls. DNS-based detection also has failure modes, so define what happens when that signal is unavailable.

Some implementations offer myIpAddressEx(). Check its support and return format before adopting it; it is not a drop-in replacement for a single IPv4 string. Finally, verify the resulting request route independently. Correctly recognizing the office subnet and reaching the intended proxy are two separate outcomes.