Microsoft Edge is scheduled to change the route probes it uses when a proxy auto-config script asks for the device’s local IP address, a small implementation detail that can alter proxy decisions on multi-homed Windows endpoints. Microsoft’s Microsoft 365 Roadmap entry 568787 places the change in General Availability during September 2026 and adds two enterprise policies—
For most Edge users, this will be invisible. For administrators whose PAC files branch on
A PAC file is JavaScript evaluated by the browser to choose a proxy—or a direct connection—for a requested URL. Legacy PAC logic commonly uses
The problem is that a device often has more than one usable address. A Windows laptop may simultaneously have Ethernet, Wi-Fi, a corporate VPN, Hyper-V virtual adapters, WSL networking, a cellular interface, and IPv6 addresses. A PAC function that returns only one local address must make a choice, and the choice can decide whether a request takes the corporate proxy, a local proxy, or a direct route.
Chromium’s public proxy documentation describes the default behavior Microsoft is aligning with. For IPv4, Chromium first identifies the local interface that would route traffic toward
If the public-route test does not produce a suitable address, Chromium falls back to resolving the machine hostname, then tries private-network destinations including
Microsoft’s roadmap wording says Edge’s “default IPv4 and IPv6 probe destinations now match Chromium’s defaults.” That makes the intended behavior clear enough: Edge is standardizing on Chromium’s public-route heuristics. What remains unclear is the meaningful migration detail—what Edge used before this change. Microsoft has not disclosed the former probe addresses or said whether the change corrects a Windows-specific divergence, an Edge-specific regression, or a long-standing compatibility gap.
Consider a laptop with a corporate VPN that installs routes only for private company networks, while normal Internet traffic continues through the user’s home or hotel connection. If a PAC script uses
The reverse scenario is also possible in environments with full-tunnel VPNs or secure web gateway clients. If the VPN becomes the preferred route toward the public probe address, the PAC engine may identify the VPN-connected interface as the relevant local address. A script that was written around an earlier Edge selection rule can start choosing a different proxy list, bypass list, or
That is why the feature should not be dismissed as a cosmetic Chromium-alignment update. PAC deployments frequently contain accumulated assumptions from Internet Explorer, WinINet, legacy Edge, Chrome, and browser-specific extensions. The function name suggests it reports the local address; on a modern managed device, that premise is false.
Chromium’s own documentation calls
There is a related limitation for administrators who expect
In a controlled enterprise network, an administrator could point the IPv4 probe at a stable address whose route reliably selects the intended internal interface, and do the same independently for IPv6. This is particularly relevant for:
Microsoft has not yet documented whether these policies accept literal IP addresses only, whether hostnames are permitted, how invalid values are handled, whether policy refresh takes effect without restarting Edge, or whether the controls apply to all desktop operating systems supported by Edge. Those are not trivial omissions. They determine whether admins can deploy a concise cross-platform policy or need separate Windows, macOS, and Linux handling.
The roadmap also labels the platform as “Web,” which is standard Microsoft 365 Roadmap metadata rather than evidence that this is a browser-only cloud-side switch. Route probing and PAC evaluation occur in the Edge client. Administrators should expect a browser update and policy-template documentation before they can validate or configure the behavior.
Administrators should identify PAC rules that use local address ranges, hostname-derived address assumptions, or direct comparisons against a specific subnet. They should test at least a wired office endpoint, remote Wi-Fi endpoint, full-tunnel VPN session, split-tunnel VPN session, and a device with IPv6 enabled. Where the PAC script’s actual intent is network identification, replacing local-IP inference with resolution of a controlled internal test name is likely to survive routing changes better than setting a permanent custom probe override.
For organizations that cannot change a mature PAC file quickly, the two new Edge policies offer a bridge. But Microsoft’s September 2026 target leaves a narrow window to establish the current baseline, identify affected routing branches, and decide whether Chromium’s defaults already select the intended interface.
The most important unanswered item is Edge’s old probe behavior. Until Microsoft documents it, administrators cannot predict the delta from a configuration guide alone; they need to record what their deployed Edge builds return today and compare it with the September build before broad deployment.
PacMyIpAddressIPv4ProbeAddress and PacMyIpAddressIPv6ProbeAddress—for organizations that need to preserve routing-specific behavior.
The feature is still marked In development, not rolling out. Microsoft has not published the Edge version, supported desktop platforms, policy value format, or the exact prior probe destinations that will be replaced. No independent outlet appears to have reported the roadmap item yet, so the operational detail comes from Microsoft’s roadmap language and Chromium’s public proxy implementation documentation.For most Edge users, this will be invisible. For administrators whose PAC files branch on
myIpAddress() or myIpAddressEx(), however, it is a compatibility change worth testing before the September release window.
Chromium’s defaults favor the interface used for Internet routing
A PAC file is JavaScript evaluated by the browser to choose a proxy—or a direct connection—for a requested URL. Legacy PAC logic commonly uses myIpAddress() to identify the client’s presumed local network and then directs internal addresses, branch-office traffic, cloud services, or Internet-bound requests to different proxy paths.The problem is that a device often has more than one usable address. A Windows laptop may simultaneously have Ethernet, Wi-Fi, a corporate VPN, Hyper-V virtual adapters, WSL networking, a cellular interface, and IPv6 addresses. A PAC function that returns only one local address must make a choice, and the choice can decide whether a request takes the corporate proxy, a local proxy, or a direct route.
Chromium’s public proxy documentation describes the default behavior Microsoft is aligning with. For IPv4, Chromium first identifies the local interface that would route traffic toward
8.8.8.8; for IPv6, it does the equivalent test against 2001:4860:4860::8888. Those are Google Public DNS addresses, but the probes are not ordinary browser requests to a DNS service. They are route lookups used to ask the operating system which local source address and interface would be selected for a destination in that address family.If the public-route test does not produce a suitable address, Chromium falls back to resolving the machine hostname, then tries private-network destinations including
10.0.0.0, 172.16.0.0, 192.168.0.0, and fc00::. Chromium skips link-local and loopback addresses unless it cannot find another candidate. Its documentation also says the single-address myIpAddress() result favors IPv4 where possible.Microsoft’s roadmap wording says Edge’s “default IPv4 and IPv6 probe destinations now match Chromium’s defaults.” That makes the intended behavior clear enough: Edge is standardizing on Chromium’s public-route heuristics. What remains unclear is the meaningful migration detail—what Edge used before this change. Microsoft has not disclosed the former probe addresses or said whether the change corrects a Windows-specific divergence, an Edge-specific regression, or a long-standing compatibility gap.
PAC files can treat a changed address as a changed location
The practical risk is not that Edge suddenly sends all traffic to Google. It does not. The risk is that an existing PAC script may receive a different answer frommyIpAddress() after Edge adopts the new probes, even while the endpoint’s adapters and IP addresses remain unchanged.Consider a laptop with a corporate VPN that installs routes only for private company networks, while normal Internet traffic continues through the user’s home or hotel connection. If a PAC script uses
myIpAddress() as a shorthand for “is this device on the corporate network?”, a public-route probe can return the physical Wi-Fi adapter’s address rather than the VPN adapter’s address. The PAC file may then select its external path rather than its internal proxy rule.The reverse scenario is also possible in environments with full-tunnel VPNs or secure web gateway clients. If the VPN becomes the preferred route toward the public probe address, the PAC engine may identify the VPN-connected interface as the relevant local address. A script that was written around an earlier Edge selection rule can start choosing a different proxy list, bypass list, or
DIRECT fallback.That is why the feature should not be dismissed as a cosmetic Chromium-alignment update. PAC deployments frequently contain accumulated assumptions from Internet Explorer, WinINet, legacy Edge, Chrome, and browser-specific extensions. The function name suggests it reports the local address; on a modern managed device, that premise is false.
Chromium’s own documentation calls
myIpAddress() inherently ambiguous on multi-homed hosts. It recommends that PAC authors use dnsResolve() or dnsResolveEx() against controlled test names when the real question is which network the device is connected to. A controlled internal name that resolves only while on a particular network is generally a more direct signal than inferring network location from whichever interface owns the route to a public address.There is a related limitation for administrators who expect
myIpAddressEx() to solve the problem. That Microsoft PAC extension can return multiple addresses, whereas myIpAddress() returns one, but Chromium intentionally limits what PAC code can see. It does not turn a PAC file into a complete local-interface inventory, and it does not eliminate ambiguity about which route should govern a given request.The new policies are a containment tool, not a PAC redesign
Microsoft is adding thePacMyIpAddressIPv4ProbeAddress and PacMyIpAddressIPv6ProbeAddress policies so organizations can substitute probe destinations that better represent their own routing model. The separate IPv4 and IPv6 controls matter because dual-stack routing is often asymmetric: an endpoint can have corporate IPv4 access through one adapter while IPv6 traffic uses another, or it may have IPv6 configured without usable external IPv6 connectivity.In a controlled enterprise network, an administrator could point the IPv4 probe at a stable address whose route reliably selects the intended internal interface, and do the same independently for IPv6. This is particularly relevant for:
- Devices using split-tunnel VPNs where private and Internet routes deliberately leave through different interfaces.
- Networks that use multiple gateways, SD-WAN overlays, or per-application routing.
- PAC files that make routing choices based on RFC 1918 address ranges or an expected corporate client subnet.
- Virtual desktop, developer, and lab machines with VPN clients, virtual switches, or multiple active adapters.
- Dual-stack environments where IPv4 and IPv6 paths do not follow the same egress design.
Microsoft has not yet documented whether these policies accept literal IP addresses only, whether hostnames are permitted, how invalid values are handled, whether policy refresh takes effect without restarting Edge, or whether the controls apply to all desktop operating systems supported by Edge. Those are not trivial omissions. They determine whether admins can deploy a concise cross-platform policy or need separate Windows, macOS, and Linux handling.
The roadmap also labels the platform as “Web,” which is standard Microsoft 365 Roadmap metadata rather than evidence that this is a browser-only cloud-side switch. Route probing and PAC evaluation occur in the Edge client. Administrators should expect a browser update and policy-template documentation before they can validate or configure the behavior.
September testing should start with the PAC functions, not the proxy server
The right pre-deployment test is to inspect the logic that consumesmyIpAddress() and myIpAddressEx(), then compare Edge’s returned value and final proxy decision on representative endpoint states. Testing only whether the PAC URL downloads or whether the proxy accepts connections will miss the failure mode: the PAC file can evaluate successfully while selecting the wrong branch.Administrators should identify PAC rules that use local address ranges, hostname-derived address assumptions, or direct comparisons against a specific subnet. They should test at least a wired office endpoint, remote Wi-Fi endpoint, full-tunnel VPN session, split-tunnel VPN session, and a device with IPv6 enabled. Where the PAC script’s actual intent is network identification, replacing local-IP inference with resolution of a controlled internal test name is likely to survive routing changes better than setting a permanent custom probe override.
For organizations that cannot change a mature PAC file quickly, the two new Edge policies offer a bridge. But Microsoft’s September 2026 target leaves a narrow window to establish the current baseline, identify affected routing branches, and decide whether Chromium’s defaults already select the intended interface.
The most important unanswered item is Edge’s old probe behavior. Until Microsoft documents it, administrators cannot predict the delta from a configuration guide alone; they need to record what their deployed Edge builds return today and compare it with the September build before broad deployment.
References
- Primary source: Microsoft 365 Roadmap
Published: 2026-08-05T22:47:32.7900752Z
Microsoft 365 Roadmap | Microsoft 365
The Microsoft 365 Roadmap lists updates that are currently planned for applicable subscribers. Check here for more information on the status of new features and updates.www.microsoft.com
- Related coverage: learn.microsoft.com
Plan your deployment of Microsoft Edge | Microsoft Learn
Plan your deployment of Microsoft Edgelearn.microsoft.com - Related coverage: learn.microsoft.com
Microsoft Edge Proxy Support | Microsoft Learn
This document establishes basic proxy terminology and describes Edge-specific proxy behaviorslearn.microsoft.com - Related coverage: chromium.googlesource.com
- Related coverage: chromium.googlesource.com
- Related coverage: cdn-dynmedia-1.microsoft.com
- Related coverage: cdn-dynmedia-1.microsoft.com