How to Stop Your Laptop Auto-Joining an Old Hotspot

The device joins an old hotspot before the VPN starts, and the tunnel then comes up over a network nobody chose. That order of events is the whole problem. Which network the device joins is an operating system decision, and whether the tunnel is up first is a client policy decision. They live in different places, and fixing one does not fix the other.

Decide which of the two you actually need to change before you start clicking.

Which layer owns the join decision

Saved networks and auto-join belong to the OS: the Wi-Fi settings on macOS, the saved-networks list on Android, the known-network list on Windows. A VPN client can influence this only where the vendor ships an explicit integration, and most do not. Assuming the tunnel controls the join order leads to changing VPN settings that were never involved in the first place.

The tunnel's job starts after the link is up. It does not get a vote on which link that is.

Clear the saved network properly

Remove the entry rather than ranking it lower. On most platforms a forgotten network will not rejoin automatically, while a deprioritised one still will when nothing better is available. Confirm the intended home or work connection is still present before you finish, and do not remove managed entries without the owner's process. On a managed device the entry may be pushed by policy and reappear after removal, which is a support question rather than a settings question.

The platform's own documentation is the reference here, not a third-party guide written for a different release. Apple's note on forgetting a Wi-Fi network is the short version for macOS.

A remembered SSID is not the venue you trusted

A saved name is a string. An access point can broadcast the same name from somewhere else entirely, which is how a device joins something that merely looks familiar. Check the network before you enter portal credentials, and treat an unexpected captive page on a known SSID as a signal rather than an annoyance. That risk is separate from auto-join, though forgetting the network reduces both. Chain venues reuse the same SSID in every branch, so the name can be genuine in two cities and hostile in a third.

Name matching is convenience, not authentication.

Check the VPN startup separately

Automatic connection and blocking outside the tunnel are two different policies, and a client can have one without the other. A device may join a network, stay online for a while, and only then establish the tunnel. Test with non-sensitive traffic to observe the startup order and what happens on an ordinary network change. A profile that reconnects later tells you nothing about the interval before it did.

If that interval matters, the blocking policy is the control you need, not the auto-connect setting.

What to do about captive portals

Strict blocking breaks captive portals by design, because the portal needs traffic the tunnel would otherwise capture. Use an approved bootstrap procedure, keep it documented, and do not disable unrelated settings every time a page fails to load.

That procedure is a decision with an owner. Without one, people invent their own version, and the invented version usually disables the protection permanently.